Hoe u het testen van mobiele applicaties automatiseert
De gemiddelde aandachtsspanne van een mens is minder dan 9 seconden! Heb je je ooit afgevraagd waarom? De meeste mobiele applicaties die de afgelopen tijd zijn verschenen, vereisen dat je door een nieuwsoverzicht scrolt, waarbij de hersenen erop zijn afgestemd om niet langer dan een paar seconden naar iets te kijken. Dit heeft geleid tot een aanzienlijke afname van de aandachtsspanne van een gemiddelde gebruiker.
Met de overvloed aan mobiele applicaties die beschikbaar zijn in de appstore, komt ook de grote verantwoordelijkheid voor het testen van mobiele apps en het opschalen van regressietests. Daar komen de tools voor het testen van mobiele apps goed van pas.
Ik was een van de eerste gebruikers van raamwerken voor het testen van mobiele apps en naar mijn ervaring zijn automatisering, vormfactoren en prestatietests allemaal even belangrijk geweest om op te schalen en meer impact te creëren in de mobiele wereld. In dit artikel deel ik de meest effectieve technieken voor het automatiseren van tests voor mobiele applicaties.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Testen van mobiele applicaties: componenten om rekening mee te houden
Testen op elk specifiek platform brengt zijn eigen uitdagingen met zich mee, maar bij mobiele apparaten heb je deze extra parameters waarmee je rekening moet houden. Of je nu handmatig test of testautomatisering toepast, naast functioneel testen moeten je testgevallen zich richten op:
Connectiviteit
Het is belangrijk om vast te stellen wat er gebeurt als een gebruiker zijn mobiele apparaat in vliegtuigmodus of offline gebruikt, wat er gebeurt als de bandbreedte fluctueert, enzovoort, om ervoor te zorgen dat de app werkt.
Locatie
Vooral bij mobiele applicaties die afhankelijk zijn van GPS of locatiegebaseerde diensten, moet het testen worden uitgevoerd door de locatie te simuleren met tools zoals MobileSpy, Location Spoofer enzovoort. Anders is het moeilijk om te testen—bijvoorbeeld: als je een testsituatie wilt simuleren voor een mobiele applicatie voor rit delen, waarbij iemand een rit aanvraagt vanuit NYC en er wijzigingen zijn aangebracht in de back-endmicroservices die specifiek gericht zijn op het vinden van de chauffeur op die locatie. Zonder simulatie zouden de tests geen nauwkeurige resultaten opleveren.
Besturingssysteem
Vooral gezien het aantal Android-telefoons dat tegenwoordig op de markt is, is het vrijwel onmogelijk om op alle beschikbare besturingssysteemversies te testen—hoe bepaal je dan je prioriteiten? Bij iOS heb je extra uitdagingen door zaken die Apple introduceert met betrekking tot Xcode-versies die gekoppeld zijn aan wijzigingen in de besturingssysteemversie.
Tegenwoordig maken bedrijven gebruik van externe aanbieders zoals BrowserStack voor het leveren van simulatoren en emulators voor verschillende besturingssystemen, het testen van apparaten en tests in meerdere browsers.
De pictogrammen in de gebruikersinterface verschillen afhankelijk van het besturingssysteemplatform: Windows, iOS en Android. Bij testautomatisering gebruiken de meesten van ons simulatoren—de Android-simulatoren hebben veel meer tijd nodig om te laden, terwijl iOS-apparaten sneller zijn.
De verschillende toetscombinaties die je op mobiele apparaten moet gebruiken, afhankelijk van het type besturingssysteem, om schermafbeeldingen te maken voor het debuggen van problemen, zijn belangrijke informatie voor iedereen die mobiele applicaties test.
Vormfactor
Bij het ontwikkelen van mobiele applicaties zijn er 5 belangrijke vormfactoren waarmee rekening moet worden gehouden voor de verschillende besturingssysteemversies, naast de portret- of landschapsmodus op elk van deze apparaattypen:
| Apparaat | Schermgrootte |
| Kleine mobiele apparaten | 3.5 inch of kleiner |
| Gemiddelde mobiele apparaten | 3.5 tot 5 inch |
| Tablets | 5 tot 7 inch |
| Kleine tablets | 7 tot 8.5 inch |
| Tablets van volledig formaat | 8.5 inch of groter |
Het juiste raamwerk voor mobiele automatisering kiezen
Bij het bouwen van mobiele applicaties houdt rekening houden met vormfactoren in dat je ervoor zorgt dat de applicatie responsief is wanneer dezelfde app wordt geopend op verschillende mobiele apparaten en typen besturingssystemen. Wanneer de app wereldwijd wordt gebruikt en bedrijven hun gebruikersbestand willen uitbreiden, moeten ze deze beslissing al vroeg in het ontwikkelingsproces nemen en kiezen voor React Native-raamwerken in plaats van native Android- of iOS-ontwikkeling.
Als bedrijven dat niet doen, zullen ze later tijd en moeite moeten besteden aan het herstructureren en opnieuw ontwerpen van de apps om over te stappen op React Native-raamwerken. Dit heeft rechtstreeks invloed op het aantal teams en de onderhoudsoverhead, omdat React Native-raamwerken de ontwikkeling van zowel iOS- als Android-applicaties ondersteunen.
Wanneer mobiele applicaties worden ontwikkeld met React Native-raamwerken, vermindert dit ook de belasting van testautomatisering, omdat je slechts één raamwerk voor testautomatisering hoeft te onderhouden voor zowel iOS als Android.
Er zijn verschillende manieren om mobiele applicaties te ontwikkelen. Sommige bedrijven kiezen ervoor om native programmeertalen zoals Java en Objective C te gebruiken voor respectievelijk Android- en iOS-applicaties. Het voordeel van het gebruik van native talen is dat ze uitgebreide functionaliteit aan hun applicaties kunnen bieden.
Aan de andere kant verschillen de element-id's op beide platforms. Dat betekent dat we afzonderlijke native testframeworks nodig hebben om hetzelfde te testen, zoals Espresso op Android, XCUITest op iOS, enzovoort.
React Native is een andere veelgebruikte programmeertaal voor het ontwikkelen van responsieve mobiele applicaties, die door Facebook als opensource is vrijgegeven. Het doel was om de inspanningen voor mobiele ontwikkeling op beide platforms te verenigen, zodat er één team kan zijn en de element-id's in beide apps hetzelfde zijn. Daardoor is slechts één testframework nodig, zoals Appium, om de mobiele applicaties te testen.
Als het gaat om het automatiseren van tests voor je mobiele applicatie, kan het kiezen van de juiste QA-automatiseringstools een aanzienlijk verschil maken in de efficiëntie van je tests.
Zo automatiseer je het testen van iOS-mobiele applicaties
Bij handmatig testen moet aan een aantal criteria worden voldaan: de meeste bedrijven die iOS-apps ontwikkelen, specificeren duidelijk welke besturingssystemen en SDK-versies worden ondersteund. Dit helpt om je testinspanningen te beperken.
Om testinspanningen voor software op te schalen, moeten we investeren in automatisering. Er zijn veel populaire frameworks die geautomatiseerd testen van mobiele iOS-apps ondersteunen. Voor deze bespreking beperken we de scope tot de volgende 2 automatiseringstools:
- XCUITest
- Appium
| XCUITest | Appium |
| Framework voor native apps dat binnen de iOS-broncodebasis kan worden opgenomen. | Afzonderlijk testframework dat buiten de broncodebasis is gebouwd. |
| Geschreven in Objective C of Swift | Geschreven in Java, Python, enzovoort. |
| Expliciete wachttijden die een voorwaarde toepassen. | Impliciete wachttijden waarbij sleep() wordt gebruikt, waardoor tests onbetrouwbaar worden. |
| Backend-API-reacties simuleren met opensourcelibraries zoals Mockingjay | Ondersteunt het gebruik van een mockserver. |
| Omdat dit een framework voor native apps is, kan het alleen worden gebruikt om iOS-applicaties te testen. | Omdat de tests buiten de broncodebasis staan en in talen zoals Java, Python enzovoort kunnen worden geschreven, kan het worden gebruikt om platformonafhankelijke applicaties zoals Windows-, iOS- en Android-apps te testen, zolang de element-id's op beide platforms hetzelfde zijn. |
Ik heb mockservers gebruikt om backend-aanroepen te simuleren en uitsluitend de gebruikersinterface te testen door als volgt een basisklasse te maken:
Nu de basisklasse klaar is, voeg ik de daadwerkelijke test toe door gebruik te maken van het ontwerppatroon voor page objects, als volgt:
Zo automatiseer je het testen van Android-mobiele applicaties
Er zijn wereldwijd meer dan 2 miljard actieve Android-apparaten. Je Android-applicatie testen op verschillende typen apparaten en besturingssystemen is vrijwel onmogelijk! Daarom geven bedrijven expliciet aan welke versies ze ondersteunen. Dit zorgt ook voor een betere gebruikerservaring.
Frameworks voor Android-automatisering helpen testprocessen zoals Robotium en Selendroid zeker versnellen. Voor deze bespreking beperken we ons tot de automatiseringstools Espresso en Appium:
| Espresso | Appium |
| Systeemeigen framework dat binnen de Android-broncode kan worden gebruikt. | Afzonderlijk testframework dat buiten de broncode is gebouwd. |
| Geschreven in Java en Kotlin | Geschreven in Java, Python enzovoort |
| Expliciete wachttijden; asynchrone bewerkingen worden ondersteund door de mogelijkheid van inactieve bronnen | Impliciete wachttijden waarbij sleep() wordt gebruikt, waardoor tests onbetrouwbaar worden. |
| Backendreacties nabootsen met open-sourcebibliotheken zoals Mockito en de Retrofit-builder | Ondersteunt het gebruik van een nagebootste server. |
| Omdat dit een systeemeigen framework is, kan het alleen worden gebruikt om Android-applicaties te testen. | Omdat de tests buiten de broncode staan en kunnen worden geschreven in talen zoals Java, Python enzovoort, kan het worden gebruikt om platformonafhankelijke applicaties op zowel iOS als Android te testen, zolang de element-ID's op beide platforms hetzelfde zijn. |
Een van de voordelen van het gebruik van systeemeigen appframeworks is dat je nagebootste servers kunt gebruiken om backend-API-aanroepen na te bootsen en zo uitsluitend de gebruikersinterface te testen. Hier is een voorbeeld van een codefragment waarin ik dit heb toegepast:
Afhankelijk van de manier waarop je microservicearchitectuur is ontwikkeld, haal je de reactie op uit het netwerktabblad van je browser of rechtstreeks bij de ontwikkelaars en verwijs je er in je test als volgt naar:
Zoals je in het bovenstaande voorbeeld kunt zien, wordt HomeTabPage binnen de test aangeroepen, in plaats van dat elk element expliciet moet worden gecontroleerd. Ik heb het page-objectpatroon als volgt in het framework toegepast:
Tools voor het testen van mobiele apps
Er zijn verschillende testtools in de branche en de keuze hangt af van meerdere factoren:
- Vaardigheden van het team
- Doel van automatisering
- Doelgroep voor automatisering: productmanagers/verkopers/technici/testers
- Compatibiliteit van het testframework en de systeemeigen broncode
- Aantal hybride apps
Verschillende tools die in de branche veel worden gebruikt, zijn onder andere:
- Selendroid
- Robotium
- Appium
- Testdroid
- UiAutomator
Geen zin om zelf intern te testen? Je kunt ook diensten voor het testen van mobiele apps inschakelen om dit voor je te doen.
Prestatietests voor mobiele applicaties
Bij het testen van mobiele applicaties moeten we, naast het focussen op automatisering om testinspanningen op te schalen, ook prioriteit geven aan prestatietests, omdat deze een cruciale rol spelen bij het bepalen of een gebruiker onze applicatie zal blijven gebruiken.
Als het scherm meer dan 2 seconden nodig heeft om te laden, worden mensen ongeduldig. Dit sluit aan bij ons onderzoek naar de aandachtsspanne. Om gebruikers daarom te behouden, moeten we investeren in prestatietests.
Bij het testen van de app-prestaties moeten we de KPI's identificeren en hieraan toetsen:
- Maximale reactietijd
- Gemiddelde reactietijd
- Gemiddelde doorvoersnelheid
- Piek aantal actieve gebruikers voor elk besturingssysteem en apparaat
Het gebruik van een tool voor het testen van mobiele apps kan prestatietests vereenvoudigen. Apptim kan bijvoorbeeld prestatiestatistieken van eindgebruikers bijhouden en uitgebreide prestatierapporten leveren voor alle belangrijke prestatieparameters.
Voor het monitoren van de prestaties van mobiele applicaties kunnen we Firebase Performance monitoring gebruiken, waarmee we controle krijgen over prestatiegegevens door inzicht te bieden in hoe je app presteert, met een uitsplitsing van trace- en netwerkgegevens naar dimensies zoals app-versie, land, apparaat en netwerktype.
Er zijn ook andere tools, zoals Appium Studio, Sauce Labs, Testdroid enzovoort, die vergelijkbare mogelijkheden voor prestatiemonitoring bieden.
We hopen dat dit artikel je een eerste inzicht heeft gegeven in het testen van mobiele applicaties en de kritieke factoren die daarbij komen kijken!
Abonneer je op de nieuwsbrief van The QA Lead voor meer best practices en tips om je ontwikkelproces vorm te geven.
Gerelateerde informatie:
Bekijk ook dit:
- WAT IS TESTGEAR? OVERZICHT EN RONDLEIDING DOOR DE FUNCTIES
- METRIEKEN VOOR SERVERMONITORING OM DE SYSTEEMGEZONDHEID EN -PRESTATIES TE VOLGEN
Gerelateerde lijst met tools:
