La oss referere at Android OS markedsandel diagram som vi så tidligere. Det er urealistisk å nærme testing tenker at du vil støtte hver enhet og hver smaken av Android.

Mitt poeng er at vi trenger å tenke på fordelingen. Hva gjør vår app gjør og hvordan ser målgruppe ut? Er det et spill eller et verktøy program?

Hvis det er et spill, kan fokuset trolig være bare nyere og høyere-end utstyr. Et verktøy program, men kan brukes av et bredere publikum og trenger for å fungere på et bredere utvalg av enheter.

2. Tilnærming

Et problem jeg føler de fleste av oss kjører inn er at vi er for nær våre prosjekter. Vi vet hvordan vi kan gjøre vår app mislykkes, og hvordan du får det til å fungere. Av denne grunn, jeg prøver bevisst å sette meg inn i det for en bruker. Jeg satte brukere i to hovedkategorier, Button Masher
og Brukeranmeldelser.

Button Masher

The Button Masher er den type bruker som vil bare begynne å peke på skjermen, en knapp her, en knapp der. "Det siste knappen ikke gjorde noe. Jeg vil treffe en annen."

Hva vi kan lære av denne brukeren typen er der vi har intensive prosesser i vår app. Hvis noe skjer, og en ny forespørsel eller handling opptrer, gjør vi pigge prosessoren eller fylle opp enhetens minne? Betyr det føre til at programmet krasjer?

Det andre spørsmålet som flater er "Hvor godt kjenner vi informere brukeren om hva som skjer." Hvorfor gjorde de treffer en annen knapp i stedet for å vente? Kan vi bøte på dette ved å vise en lasteskjerm?

Brukeranmeldelser

Brukeren har intensjon. En bedre måte å forklare denne typen bruker ville være å se på bruksmåter. Det er en spesifikk oppgave som de ønsker å oppnå og en bestemt flyt de vil prøve å følge.

Vi kan lære hvordan klare app er på guiding en person gjennom en prosess eller handling. Det vil vise oss hvor en bruker blir borte og hvilke områder krever mer oppmerksomhet eller raffinering.

Vi har snakket gjennom vårt formål og ulike brukertyper, men hva er
våre alternativer og hvordan bør vi teste dem? Heldigvis finnes det mye. Og jeg anbefaler deg å gjøre så mange som mulig.

3. Alternativer

Telefon en venn

Hvis du ikke har den luksusen av å være i stand til å gå ned til QA avdeling eller en testlab, kan du ringe en venn. Du trenger øyne, og du trenger enheter

Når det gjelder testing av mobile apps, volum kan gjøre en forskjell, spesielt hvis du kan få en rekke enheter

Verktøy &..; Unit Testing

Automatisert testing er din venn. Selv om ingenting vil slå hands-on tid med en komplett søknad, er det også viktig å se hva som skjer under panseret og hvordan din app vil reagere programma på visse situasjoner eller når satt under stress.

Enda viktigere, enhet testing kan du teste som du går, noe som kan spare mye tid på testing og QA, før utgivelse.

Android SDK

Android SDK kommer med Android testing rammeverk, som består av en testing API basert på JUnit og monkeyrunner.

Android JUnit utvidelsen lar utviklere å skrive enhet tester mot Android-komponenter og Android API med forhåndsbygde komponentspesifikke test case klasser.

Monkeyrunner er et Python-basert API som lar deg skrive programmer som styrer en enhet fra en brukers perspektiv. Dette betyr at du kan lage tester for å kjøre på en rekke enheter eller emulatorer som vil samhandle med din app, sender den tastetrykk og fange screenshots.

Annet Testing Rammeverk

Det er mye testing rammeverk tilgjengelig. Noen av de mer populære de er Robolectric og Robotium.

Robolectric er en enhet test rammeverk som kjører i IDE. Dette er flott for revisjon koden pre-build. Robotium kjører tester mot Android API i emulatorer. Mens det tar mer tid å fullføre testene, vil søknaden din kode bli satt gjennom mye mer av en reell test mot enhetene og API.

En annen interessant alternativ er Espresso. Det serverer en veldig bestemt formål sammenlignet med de to foregående alternativene. Det er en API for å kjøre tester mot Android UI.

Alle de ovennevnte alternativene er stor, men hvis du bygger en hybrid app, kan du ikke være i stand til å bruke dem. Appium er et kryssplattform automatisering rammeverk som gjør det mulig å bygge tester med det språket du ønsker for både store mobile plattformer.

Rapportering og Analytics

Det er også veldig nyttig å kunne å se noen statistikker og, enda viktigere, samle feil og krasjlogger. Dette er spesielt nyttig hvis du har mange mennesker testing søknaden din, fordi det kan bli tungvint å samle logger fra hver enkelt bruker.

Bortsett fra sporing app bruk, Google Analytics kan også sende deg unntak. Flurry er et annet testet alternativ. De har eksistert i lang tid og sine rapporterings- og krasjrapporter er litt mer detaljert.

Selv om det ikke hjelper i utviklingsfasen av programmet, samler Google også topprapporter for apps i Play Store.

4. Tredjeparts alternativer

Vi vil alle gjerne ha 400 enheter for å teste på, som de massive testlaboratorier vi har sett på nettet. Men det er ikke realistisk. For å svare på dette problemet, er det mange tjenester tilgjengelig hvis du er villig til å investere i testing.

Disse tjenestene varierer fra én-mot-én real-menneskelige tester til helautomatiske testings på hundrevis av enheter. Hvis du er villig til å betale for det, det er tilgjengelig.

Jeg har ikke erfaring med de fleste av disse, men den jeg har brukt er brukertesting. Det er veldig nyttig å se en person følge test script som de trykker gjennom søknaden din og gi deg sine tanker.

Dette er noen tjenester til consider:


AppThwack

uTest/Applause

TestObject

testdroid


Conclusion

Too mange ganger jeg har kommet over situasjonen der QA og testing virket som en ettertanke. I virkeligheten er det trolig den viktigste delen av utviklingsprosessen.

Android, med sine mange smaker, kan virke skremmende, men når det nærmet nesten programmatisk, egentlig bare blir det en del av prosessen. Det er verdt den ekstra tid og krefter. Kvalitet apps ikke bare skje.