Slik automatiserer du testing av mobilapplikasjoner

Den gjennomsnittlige oppmerksomhetsspennet til et menneske er mindre enn 9 sekunder! Har du noen gang lurt på hvorfor? De fleste mobilapplikasjoner som har dukket opp i den senere tiden, krever at du blar nedover i en innholdsstrøm der hjernen er finjustert til ikke å se på noe i mer enn noen få sekunder. Dette har ført til en betydelig reduksjon i den gjennomsnittlige brukerens oppmerksomhetsspenn.

Med det store utvalget av mobilapplikasjoner som er tilgjengelige i appbutikken, følger et stort ansvar for testing av mobilapper og oppskalering av regresjonstestingen. Det er her verktøy for testing av mobilapper kommer til nytte. 

Jeg var en av de tidlige brukerne av rammeverk for testing av mobilapper, og etter min erfaring har fokus på automatisering, formfaktorer og ytelsestesting spilt en like viktig rolle for å skalere og øke effekten i mobilverdenen. I denne artikkelen deler jeg de mest effektive teknikkene for å automatisere testene av mobilapplikasjonen din.

Testing av mobilapplikasjoner: Komponenter du bør vurdere

Testing på en bestemt plattform har sine egne utfordringer, men med mobil får du disse ekstra parameterne som du må ta hensyn til. Enten du utfører manuell testing eller testautomatisering, må testtilfellene dine, i tillegg til funksjonell testing, fokusere på:

Tilkobling

Det er viktig å ta høyde for hva som skjer hvis en bruker benytter mobilenheten sin i flymodus eller uten nettilkobling, hva som skjer hvis båndbredden varierer, og så videre, for å sikre at appen fungerer. 

Posisjon 

Dette gjelder spesielt mobilapplikasjoner som er avhengige av GPS eller posisjonsbaserte tjenester. Testingen må utføres ved å simulere posisjon ved hjelp av verktøy som MobileSpy, Location Spoofer og så videre. Ellers vil det være vanskelig å teste – for eksempel hvis du vil simulere et testscenario for en mobilapplikasjon for samkjøring, der noen ber om en kjøretur fra NYC og det er gjort endringer i mikrotjenestene på serversiden som gjelder å finne sjåføren på dette stedet. Uten simulering vil testene ikke gi deg nøyaktige resultater. 

Operativsystem

Med tanke på hvor mange Android-telefoner som finnes på markedet i dag, er det nesten umulig å teste på alle tilgjengelige operativsystemversjoner – hvordan prioriterer du da? Med iOS har du ytterligere utfordringer knyttet til Xcode-versjoner som Apple introduserer i forbindelse med endringer i operativsystemversjonene. 

I dag benytter selskaper seg av tredjepartsleverandører som BrowserStack for å tilby simulatorer/emulatorer for ulike operativsystemer, enhetstesting og testing på tvers av nettlesere. 

Brukergrensesnittikonene er forskjellige avhengig av operativsystemplattformen: Windows, iOS og Android, og når det gjelder testautomatisering, ender de fleste av oss opp med å bruke simulatorer – Android-simulatorene bruker mye lengre tid på å laste inn, mens iOS-enhetene er raskere.

De ulike tastekombinasjonene på mobilen som skal brukes, avhengig av operativsystemtype, for å ta skjermbilder ved feilsøking av problemer, er avgjørende informasjon for alle som tester mobilapplikasjoner. 

Formfaktor

Ved utvikling av mobilapplikasjoner er det fem hovedformfaktorer som må vurderes for de ulike operativsystemversjonene, i tillegg til stående eller liggende modus på hver av disse enhetstypene: 

Slik velger du riktig rammeverk for mobilautomatisering

Å ta hensyn til formfaktorer ved utvikling av mobilapplikasjoner innebærer å sikre responsivitet når den samme appen åpnes på forskjellige mobilenheter og operativsystemtyper. Når appen brukes over hele verden og selskaper ønsker å øke brukerbasen sin, må de ta denne beslutningen tidlig i utviklingsprosessen og velge React Native-rammeverk fremfor utvikling med innebygd Android eller iOS.

Hvis ikke vil selskapene ende opp med å bruke tid og ressurser senere på å refaktorere og redesigne appene for å bytte til React Native-rammeverk. Dette påvirker direkte antallet team og vedlikeholdsarbeidet, ettersom React Native-rammeverk støtter utvikling av både iOS- og Android-applikasjoner. 

Når mobilapplikasjoner utvikles ved hjelp av React Native-rammeverk, reduseres også belastningen på testautomatiseringen, ettersom du bare trenger å vedlikeholde ett enkelt rammeverk for automatisert testing av både iOS og Android. 

Det finnes ulike måter å utvikle mobilapplikasjoner på. Noen selskaper benytter opprinnelige programmeringsspråk som Java og Objective C for henholdsvis Android- og iOS-applikasjoner. Fordelen med å bruke opprinnelige språk er at de kan tilby omfattende funksjonalitet i applikasjonene sine.

På den annen side vil element-ID-ene være forskjellige på de to plattformene – noe som betyr at vi må ha separate opprinnelige testrammeverk for å teste det samme, som Espresso på Android, XCUITest på iOS osv. 

React Native er et annet vanlig programmeringsspråk for utvikling av tilpasningsdyktige mobilapplikasjoner, og ble gjort tilgjengelig som åpen kildekode av Facebook. Målet var å samle utviklingsarbeidet for mobil på begge plattformene, slik at det kunne være ett enkelt team, og slik at element-ID-ene i begge appene ville være de samme – noe som bare krever ett enkelt testrammeverk som Appium for å teste mobilapplikasjonene. 

Når det gjelder automatisering av tester av mobilapplikasjoner, kan det å velge de riktige verktøyene for QA-automatisering ha stor betydning for hvor effektiv testingen blir.

Slik automatiserer du testing av iOS-mobilapplikasjoner 

Ved manuell testing er det en rekke kriterier som må oppfylles: De fleste selskaper som utvikler iOS-apper, spesifiserer tydelig hvilke operativsystemer og SDK-versjoner som støttes. Dette bidrar til å begrense testarbeidet. 

For å skalere testarbeidet for programvare må vi investere i automatisering. Det finnes mange populære rammeverk som støtter automatisert testing av mobilapper på iOS. For å avgrense diskusjonen begrenser vi den til følgende to automatiseringsverktøy:

• XCUITest
• Appium

Jeg har brukt simuleringsservere til å simulere kall til baksystemet og teste brukergrensesnittet utelukkende på følgende måte ved å opprette en basisklasse: 

Nå som basisklassen er klar, legger jeg til selve testen ved å bruke sideobjektmønsteret på følgende måte: 

Slik automatiserer du testing av Android-mobilapplikasjoner

Det finnes over 2 milliarder aktive Android-enheter i verden. Det er nesten umulig å teste Android-applikasjonen på tvers av ulike enhets- og operativsystemtyper! Derfor oppgir selskaper tydelig hvilke versjoner de støtter. Dette sikrer også en bedre brukeropplevelse.

Rammeverk for Android-automatisering vil definitivt bidra til å fremskynde testprosesser, som Robotium, Selendroid osv. Når det gjelder omfanget av diskusjonen vår, begrenser vi oss til automatiseringsverktøyene Espresso og Appium:

En av fordelene ved å bruke innebygde app-rammeverk er å bruke simuleringsservere til å simulere API-kallene til serverdelen og dermed teste brukergrensesnittet utelukkende. Her er et eksempel på et kodeutdrag som viser hvordan jeg har fått dette til å fungere:

Avhengig av hvordan mikrotjenestearkitekturen din er utviklet, henter du enten svaret fra nettverksfanen i nettleseren eller direkte fra utviklerne, og bruker det som følger i testen:

Som du kan se i eksempelet ovenfor, kalles HomeTabPage i testen i stedet for at hvert element må valideres eksplisitt – jeg har brukt sideobjektmønsteret i rammeverket slik:

Verktøy for testing av mobilapper

Det finnes ulike testverktøy i bransjen, og valget avhenger av flere faktorer: 

• Teamets kompetanse
• Formålet med automatiseringen
• Målgruppe for automatiseringen: produktledere/salgsmedarbeidere/ingeniører/testere
• Kompatibilitet mellom testrammeverket og den innebygde kildekoden
• Antall hybridapper

Ulike verktøy som er mye brukt i bransjen, inkluderer:

• Selendroid
• Robotium
• Appium
• Testdroid
• UiAutomator

og mange flere. 

Har du ikke lyst til å utføre testingen internt? Du kan også benytte testtjenester for mobilapper til å gjøre det for deg.

Ytelsestesting av mobilapplikasjoner

Når vi tester mobilapplikasjoner, bør vi i tillegg til å fokusere på automatisering for å skalere testinnsatsen også prioritere ytelsestesting, siden dette spiller en avgjørende rolle for å avgjøre om en bruker kommer til å fortsette å bruke applikasjonen vår.

Hvis det tar mer enn 2 sekunder å laste inn skjermen, blir folk rastløse – dette henger sammen med undersøkelsene våre om oppmerksomhetsspenn, og for å beholde brukerne må vi derfor investere i ytelsestesting. 

Når vi tester appens ytelse, må vi identifisere KPI-ene og sammenligne dem med referanseverdier: 

• Maksimal responstid
• Gjennomsnittlig responstid
• Gjennomsnittlig gjennomstrømning
• Maksimalt antall aktive brukere for hvert operativsystem og hver enhet

Bruk av et testverktøy for mobilapper kan forenkle ytelsestestingen. Apptim kan for eksempel spore ytelsesmålinger for sluttbrukere – det gir omfattende ytelsesrapporter for alle viktige ytelsesparametere.

For å overvåke ytelsen til mobilapplikasjonen kan vi bruke Firebase-ytelsesovervåking, som gir kontroll over ytelsesdata ved å dele innsikt i hvordan appen fungerer, med en oppdeling av sporings- og nettverksdata etter dimensjoner som appversjon, land, enhet og nettverkstype. 

Det finnes andre verktøy som Appium Studio, Sauce Labs, Testdroid osv. som tilbyr lignende funksjoner for ytelsesovervåking. 

Vi håper denne artikkelen ga deg en innføring i testing av mobilapplikasjoner og de kritiske faktorene som er knyttet til dette! 

For flere beste praksiser og tips til hvordan du kan forme utviklingsprosessen din, abonner på nyhetsbrevet til The QA Lead.

Relatert lesning:

• HVA ER ZEPHYR SCALE?
• YTELSESTESTINGSPROGRAMVARE FOR QA-TEAM

Sjekk dette ut:

• HVA ER TESTGEAR? OVERSIKT OG GJENNOMGANG AV FUNKSJONENE
• SERVEROVERVÅKINGSMÅLINGER DU BØR FØLGE MED PÅ FOR SYSTEMHELSE OG YTELSE

Relatert verktøyliste:

• Programvare for testtilfellehåndtering
• VERKTØY FOR AUTOMATISERING AV ETL-TESTING FOR QA-TEAM
• ÅPENKILDEVERKTØY FOR ETL FOR QA-TEAM