Sådan automatiserer du test af mobilapplikationer

Det gennemsnitlige opmærksomhedsspænd for et menneske er mindre end 9 sekunder! Har du nogensinde undret dig over hvorfor? De fleste mobilapplikationer, der er dukket op i den seneste tid, kræver, at du scroller ned gennem et nyhedsfeed, hvor hjernen er finjusteret til ikke at se på noget i mere end et par sekunder. Dette har ført til en markant reduktion af den gennemsnitlige brugers opmærksomhedsspænd.

Med det væld af mobilapplikationer, der er tilgængelige i appbutikken, følger et stort ansvar for mobilapptest og skalering af regressionstestindsatsen. Det er her, værktøjer til mobiltest er nyttige. 

Jeg var en af de tidlige brugere af rammeværker til mobiltest, og efter min erfaring har fokus på automatisering, formfaktorer og ydeevnetest spillet en lige så vigtig rolle i at skalere og øge effekten i den mobile verden. I denne artikel vil jeg dele de mest effektive teknikker til automatisering af test af dine mobilapplikationer.

Test af mobilapplikationer: Komponenter, der skal overvejes

Test på enhver specifik platform har sine egne udfordringer, men med mobil har du disse ekstra parametre, som du skal tage højde for. Uanset om du udfører manuel test eller testautomatisering, skal dine testcases ud over funktionel test fokusere på:

Forbindelse

Det er vigtigt at håndtere, hvad der sker, hvis en bruger anvender sin mobilenhed i flytilstand eller offline, hvad der sker, hvis båndbredden svinger osv., for at sikre, at appen fungerer. 

Placering 

Især for mobilapplikationer, der er afhængige af GPS eller placeringsbaserede tjenester, skal test udføres ved at simulere placeringen ved hjælp af værktøjer som MobileSpy, Location Spoofer osv.; ellers vil det være svært at teste—f.eks. hvis du vil simulere et testscenarie for en mobilapplikation til samkørsel, hvor en person bestiller en tur fra NYC, og der er foretaget ændringer i de backend-mikrotjenester, der specifikt bruges til at finde chaufføren på den pågældende placering. Uden simulering ville testene ikke give dig nøjagtige resultater. 

Operativsystem

Især med det antal Android-telefoner, vi har på markedet i dag, er det næsten umuligt at teste på alle tilgængelige OS-versioner – så hvordan prioriterer du? Med iOS har du yderligere udfordringer, som Apple medfører i forbindelse med Xcode-versioner, der er knyttet til ændringer i OS-versionerne. 

I dag benytter virksomheder sig af tredjepartsudbydere som BrowserStack til at levere simulatorer/emulatorer til forskellige OS'er, enhedstest og test på tværs af browsere. 

Brugergrænsefladens ikoner er forskellige afhængigt af operativsystemerne: Windows, iOS og Android, og når det gælder testautomatisering, ender de fleste af os med at bruge simulatorer—Android-simulatorerne tager meget længere tid at indlæse, mens iOS-enhederne er hurtigere.

De forskellige tastekombinationer på mobilen, der skal bruges afhængigt af operativsystemtypen til at tage skærmbilleder ved fejlfinding, er et vigtigt input for alle, der tester mobilapplikationer. 

Formfaktor

Ved udvikling af mobilapplikationer er der 5 primære formfaktorer, der skal tages i betragtning for de forskellige OS-versioner, ud over stående eller liggende tilstand på hver af disse enhedstyper: 

Sådan vælger du det rigtige rammeværk til mobilautomatisering

At tage højde for formfaktorer ved udvikling af mobilapplikationer betyder, at man sikrer responsivitet, når den samme app åbnes på forskellige mobilenheder og OS-typer. Når appen anvendes over hele verden, og virksomheder ønsker at øge deres brugerbase, er de nødt til at træffe denne beslutning tidligt i udviklingsprocessen og vælge React Native-rammeværker frem for indbygget Android- eller iOS-udvikling.

Hvis ikke ender virksomheder med senere at bruge tid og kræfter på at refaktorere og redesigne apps for at skifte til React Native-rammeværker. Dette påvirker direkte antallet af teams og vedligeholdelsesarbejdet, da React Native-rammeværker understøtter udvikling af både iOS- og Android-applikationer. 

Når mobilapplikationer udvikles ved hjælp af React Native-rammeværker, reducerer det også byrden ved testautomatisering, da du kun behøver at vedligeholde ét rammeværk til testautomatisering for både iOS og Android. 

Der er forskellige måder at udvikle mobilapplikationer på. Nogle virksomheder vælger at bruge platformspecifikke programmeringssprog som Java og Objective C til henholdsvis Android- og iOS-applikationer. Fordelen ved at bruge platformspecifikke sprog er, at de kan tilbyde omfattende funktionalitet i deres applikationer.

På den anden side vil element-id'erne være forskellige på de to platforme – hvilket betyder, at vi skal have separate platformspecifikke testrammer til at teste det samme, såsom Espresso på Android, XCUITest på iOS osv. 

React Native er et andet almindeligt anvendt programmeringssprog til udvikling af responsive mobilapplikationer, som blev gjort tilgængeligt som åben kildekode af Facebook. Målet var at samle udviklingsindsatsen for mobil på begge platforme, så der kunne være ét team, og så element-id'erne i begge apps ville være de samme – hvilket kun kræver én testramme som Appium til at hjælpe med at teste mobilapplikationerne. 

Når det gælder automatisering af test af dine mobilapplikationer, kan valget af de rigtige værktøjer til QA-automatisering gøre en betydelig forskel for effektiviteten af din test.

Sådan automatiseres test af mobile iOS-applikationer 

Ved manuel test er der en række kriterier, der skal overholdes: De fleste virksomheder, der udvikler iOS-apps, angiver tydeligt, hvilke operativsystemer og SDK-versioner der understøttes. Det hjælper med at begrænse din testindsats. 

For at kunne skalere testindsatsen for software skal vi investere i automatisering. Der findes mange populære testrammer, der understøtter automatiseret test af mobilapps på iOS, hvoraf vi begrænser omfanget af vores diskussion til følgende 2 automatiseringsværktøjer:

• XCUITest
• Appium

Jeg har anvendt mock-servere til at simulere backend-kald og udelukkende teste brugergrænsefladen på følgende måde ved at oprette en basisklasse: 

Nu hvor basisklassen er klar, tilføjer jeg den faktiske test ved at anvende designmønstret med sideobjekter på følgende måde: 

Sådan automatiseres test af mobile Android-applikationer

Der findes over 2 milliarder aktive Android-enheder i verden. Det er næsten umuligt at teste din Android-applikation på tværs af forskellige enheds- og operativsystemtyper! Derfor angiver virksomhederne eksplicit, hvilke versioner de understøtter. Det sikrer også en bedre brugeroplevelse.

Testrammer til Android-automatisering vil bestemt hjælpe med at fremskynde testprocesserne, såsom Robotium og Selendroid osv., og inden for rammerne af vores diskussion begrænser vi os til automatiseringsværktøjerne Espresso og Appium:

En af fordelene ved at bruge frameworks til indbyggede apps er, at man kan bruge mock-servere til at simulere backend-API-kald og dermed udelukkende teste brugergrænsefladen. Her er et eksempel på et kodestykke, der viser, hvordan jeg har fået det til at fungere:

Afhængigt af hvordan din mikroservicearkitektur er udviklet, henter du enten svaret fra netværksfanen i din browser eller direkte fra udviklerne og refererer til det som følger i din test:

Som du kan se i eksemplet ovenfor, kaldes HomeTabPage i testen, så det ikke er nødvendigt eksplicit at kontrollere hvert element – jeg har anvendt sidemønsteret i frameworket som følger:

Værktøjer til test af mobilapps

Der findes forskellige testværktøjer i branchen, og valget afhænger af flere faktorer: 

• Teamets kompetencer
• Formålet med automatiseringen
• Målgruppe for automatiseringen: produktchefer/salgsmedarbejdere/ingeniører/testere
• Testframeworkets og den indbyggede kildekodes kompatibilitet
• Antallet af hybridapps

Forskellige værktøjer, der er populære i branchen, omfatter:

• Selendroid
• Robotium
• Appium
• Testdroid
• UiAutomator

og mange flere. 

Har du ikke lyst til selv at stå for testningen internt? Du kan også benytte testtjenester til mobilapps til at gøre det for dig.

Ydeevnetest af mobilapplikationer

Når vi tester mobilapplikationer, bør vi ud over at fokusere på automatisering for at skalere testindsatsen også prioritere ydeevnetest, da det spiller en afgørende rolle for, om en bruger fortsat vil benytte vores applikation.

Hvis skærmen er mere end 2 sekunder om at indlæse, bliver folk rastløse – det hænger sammen med vores undersøgelse af opmærksomhedsspændet, og derfor er vi nødt til at investere i ydeevnetest for at fastholde brugerne. 

Når vi tester appens ydeevne, skal vi identificere KPI'erne og sammenligne med dem: 

• Maksimal svartid
• Gennemsnitlig svartid
• Gennemsnitlig gennemstrømning
• Det højeste antal aktive brugere for hvert operativsystem og hver enhed

Brug af et testværktøj til mobilapps kan forenkle ydeevnetest. Apptim kan for eksempel spore ydeevnemålinger for slutbrugere – det leverer omfattende ydeevnerapporter for alle vigtige ydeevneparametre.

Til overvågning af mobilapplikationens ydeevne kan vi bruge Firebase Performance Monitoring, som giver kontrol over ydeevnedata ved at dele indsigt i, hvordan din app fungerer, med en opdeling af sporings- og netværksdata efter dimensioner som appversion, land, enhed og netværkstype. 

Der findes andre værktøjer som Appium Studio, Sauce Labs, Testdroid osv., som tilbyder lignende funktioner til overvågning af ydeevne. 

Vi håber, at denne artikel gav dig en introduktion til test af mobilapplikationer og de kritiske faktorer, der er forbundet med det! 

Hvis du vil have flere bedste praksisser og tips til at forme din udviklingsproces, så tilmeld dig nyhedsbrevet fra The QA Lead.

Relateret læsning:

• HVAD ER ZEPHYR SCALE?
• SOFTWARE TIL YDEEVNESTEST TIL QA-TEAM

Se dette ud:

• HVAD ER TESTGEAR? OVERSIGT OG GENNEMGANG AF FUNKTIONER
• MÅLINGER TIL SERVEROVERVÅGNING, DER SKAL FØLGES FOR SYSTEMETS SUNDHED OG YDEEVNE

Relateret liste over værktøjer:

• Software til håndtering af testtilfælde
• VÆRKTØJER TIL AUTOMATISERING AF ETL-TEST TIL QA-TEAM
• ETL-VÆRKTØJER MED ÅBEN KILDEKODE TIL QA-TEAM