Share
Testing av en app på Android eller iOS er ikke så forskjellig. Formålet er det samme, det ønskede resultatet er det samme, og prosessen er lik. Den største forskjellen kommer når vi begynner å se på detaljene. Det er det jeg planlegger å gjøre i denne artikkelen.
Før vi dykker inn, la oss snakke om noen testprinsipper. Det er umulig å gjennomgå alternativene våre med mindre vi forstår og forstår det komplette bildet.
Det som gjør Android skiller seg ut er det mylder av muligheter. På IOS er det iPhone, iPad og iPod Touch. De er forskjellige, men den vanlige faktoren mellom iOS-enheter er pixeldensitet, skjermoppløsning, prosessorhastigheter, minnestørrelse osv.
For Android er det tusenvis av kombinasjoner når vi ser på de samme faktorene, skjermoppløsningen og størrelsen, prosessorhastigheter, minnestørrelse og kirsebær på kaken, fragmenteringen av operativsystemet.
Når det gjelder operativsystemversjoner, er det ikke uvanlig for bærere og telefonprodusenter å stoppe å skyve ut oppdateringer ikke for lenge etter at produktets utgivelse. Er dette et problem? Ja. Ta en titt på Googles offisielle Android-markedsandelstatistikk for å få en ide om problemets skala.
I nedadgående rekkefølge av markedsandel har vi Jelly Bean (4.1-4.3), Gingerbread (2.3) og Ice Cream Sandwich (4.0).
Sammenlign det med adopteringshastigheten til Apples IOS 7. I slutten av januar i år dro 80% av iOS-enhetene iOS 7. Husk at IOS 7 ble utgitt i september 2013. Det er en stor forskjell.
Har du noen gang brukt en veldig dårlig Android-applikasjon? Verre enn en rett og slett dårlig applikasjon er en virkelig flott en som har noen vedvarende feil.
Jeg føler meg en stor faktor i god testing, og legger merke til det du bruker, liker og hater. Had er et sterkt ord, men jeg er sikker på at det er noe som alltid skiller seg ut.
Spør deg selv følgende spørsmål:
La oss referere til Android OS markedsandel diagram som vi så tidligere. Det er urealistisk å nærme seg testingstanker som du vil støtte hver enhet og enhver smak av Android.
Mitt poeng er at vi må tenke på distribusjonen. Hva gjør appen vår, og hvordan ser målmarkedet ut? Er det et spill eller et verktøy program?
Hvis det er et spill, kan fokuset sannsynligvis bare være nyere og høyere enheter. Et verktøyprogram kan imidlertid brukes av et bredere publikum og må fungere på et bredere utvalg av enheter.
Et problem jeg føler at de fleste av oss går inn i, er at vi er for nær våre prosjekter. Vi vet hvordan vi kan få appen til å feile og hvordan vi får den til å fungere. Av denne grunn forsøker jeg med vilje å tenke på det som en bruker har. Jeg legger brukere i to brede kategorier, den Button Masher og Bruker.
Button Masher er typen bruker som bare skal begynne å trykke på skjermen, en knapp her, en knapp der. "Den siste knappen gjorde ikke noe. Jeg skal slå en annen."
Det vi kan lære av denne brukertypen er hvor vi har intensive prosesser i appen vår. Hvis noe skjer og en annen forespørsel eller handling oppstår, spiser vi prosessoren eller fyller enhetens minne? Går det til at programmet krasjer?
Det andre spørsmålet som flater er "Hvor godt informerer vi brukeren om hva som skjer." Hvorfor slo de en annen knapp i stedet for å vente? Kan vi avhjelpe dette ved å vise en laste skjerm?
Brukeren har intensjon. En bedre måte å forklare denne typen bruker ville være å se på brukstilfeller. Det er en bestemt oppgave de ønsker å oppnå, og en bestemt flyt de vil prøve å følge.
Vi kan lære hvor klart appen er å veilede en person gjennom en prosess eller handling. Det vil vise oss hvor en bruker blir tapt og hvilke områder krever mer oppmerksomhet eller raffinering.
Vi har snakket gjennom vår hensikt og forskjellige brukertyper, men hva er våre alternativer og hvordan skal vi teste dem? Heldigvis er det mye. Og jeg anbefaler at du gjør så mange du muligens kan.
Hvis du ikke har lyst til å kunne gå ned til QA-avdelingen eller et testlaboratorium, kan du ringe til en venn. Du trenger øyne og du trenger enheter.
Når det gjelder å teste mobilapper, kan volumet gjøre en forskjell, spesielt hvis du kan få en rekke enheter.
Automatisert testing er din venn. Mens ingenting vil slå hands-on tid med en komplett søknad, er det også viktig å se hva som skjer under hetten og hvordan appen din vil reagere programmatisk til bestemte situasjoner eller når du legger stress.
Enda viktigere, kan enhetstesting tillate deg å teste når du går, noe som kan spare mye tid under testing og QA, før du slipper ut.
Android SDK kommer med Android testing rammeverk, som består av en testing API basert på JUnit og monkeyrunner.
Android JUnit-utvidelsen tillater utviklere å skrive enhetstester mot Android-komponenter og Android API med forhåndsbygde komponentspesifikke testcase klasser.
Monkeyrunner er en Python-basert API som lar deg skrive programmer som styrer en enhet fra brukerens perspektiv. Dette betyr at du kan opprette tester for å kjøre på mange enheter eller emulatorer som vil samhandle med appen din, sende den tastetrykk og fange skjermbilder.
Det er mange testrammer tilgjengelig. Noen av de mest populære er Robolectric og Robotium.
Robolectric er en enhetstestramme som går i din IDE. Dette er flott for å revidere kodens pre-build. Robotium kjører tester mot Android API i emulatorer. Selv om det tar mer tid å fullføre testene, blir søknadskoden din lagt gjennom mye mer av en sannteststest mot enheter og API.
Et annet interessant alternativ er Espresso. Det tjener en svært spesiell hensikt sammenlignet med de to foregående alternativene. Det er en API for å kjøre tester mot Android-brukergrensesnittet.
Alle alternativene ovenfor er flotte, men hvis du bygger en hybrid-app, kan du kanskje ikke bruke dem. Appium er et automatiseringsramme på tverrplattform som lar deg bygge tester med hvilket språk du liker for begge store mobile plattformene.
Det er også veldig nyttig å kunne se statistikk og, enda viktigere, samle feil- og krasjlogger. Dette er spesielt nyttig hvis du har mange som tester programmet, fordi det kan bli tungvint å samle logger fra hver enkelt bruker.
Bortsett fra sporing av appbruk, kan Google Analytics også sende deg unntak. Flurry er et annet testet alternativ. De har eksistert lenge, og rapporterings- og krasjrapporter er litt mer detaljerte.
Selv om det ikke hjelper under utviklingsfasen av søknaden din, samler Google også krasjrapporter for apper i Play-butikken.
Vi vil gjerne ha 400 enheter til å teste på, som de massive testlaboratoriene vi har sett på nettet. Det er imidlertid ikke realistisk. For å svare på dette problemet, er det mange tjenester tilgjengelig hvis du er villig til å investere i testing.
Disse tjenestene spenner fra en-mot-en ekte-menneskelige tester til helautomatiske testinger på hundrevis av enheter. Hvis du er villig til å betale for den, er den tilgjengelig.
Jeg har ikke erfaring med de fleste av disse, men den jeg har brukt er User Testing. Det er veldig nyttig å se at en person følger testskriptet ditt når de klikker gjennom søknaden din og gir deg sine tanker.
Disse er noen tjenester å vurdere:
For mange ganger har jeg kommet over situasjonen hvor QA og testing virket som en ettertanke. I virkeligheten er det sannsynligvis den viktigste delen av utviklingsprosessen.
Android, med sine mange smaker, kan virke skremmende, men når det nærmer seg nesten programmatisk, blir det egentlig bare en del av prosessen. Det er verdt ekstra tid og krefter. Kvalitetsapplikasjoner skjer ikke bare.
Accentsconagua