Hoe je 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 in het recente verleden zijn verschenen, vereisen dat je door een tijdlijn naar beneden 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 de gemiddelde gebruiker.
Met de overvloed aan mobiele applicaties die beschikbaar zijn in de appwinkel, komt de grote verantwoordelijkheid voor het testen van mobiele apps en het opschalen van regressietestinspanningen. Daar komen de tools voor mobiel testen goed van pas.
Ik was een van de eerste gebruikers van raamwerken voor mobiel testen en vanuit mijn ervaring hebben de focus op automatisering, vormfactoren en prestatietests een even belangrijke rol gespeeld bij het opschalen en vergroten van de impact in de mobiele wereld. In dit artikel deel ik de meest effectieve technieken voor het automatiseren van tests voor mobiele applicaties.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
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 aanvullende parameters waarmee je rekening moet houden. Of je nu handmatig test of testautomatisering gebruikt, naast functioneel testen moeten je testgevallen zich richten op:
Connectiviteit
Het is belangrijk om te testen wat er gebeurt als een gebruiker zijn mobiele apparaat in vliegtuigmodus of offline gebruikt, wat er gebeurt als de bandbreedte fluctueert enzovoort, om te garanderen dat de app werkt.
Locatie
Vooral bij mobiele applicaties die afhankelijk zijn van GPS of locatiegebaseerde services moet het testen worden uitgevoerd door de locatie te simuleren met tools zoals MobileSpy, Location Spoofer enzovoort. Anders zou het moeilijk zijn om te testen—bijvoorbeeld: als je een testscenario wilt simuleren voor een mobiele applicatie voor ritdelen, waarbij iemand een rit aanvraagt vanuit NYC en er wijzigingen zijn aangebracht in de microservices in de backend die specifiek zijn voor 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 testen op alle beschikbare OS-versies vrijwel onmogelijk. Hoe bepaal je dan je prioriteiten? Bij iOS heb je aanvullende uitdagingen door de vereisten van Apple met betrekking tot Xcode-versies die gekoppeld zijn aan wijzigingen in de OS-versies.
Tegenwoordig maken bedrijven gebruik van externe aanbieders zoals BrowserStack voor het leveren van simulatoren/emulators voor verschillende besturingssystemen, apparaattests en tests voor meerdere browsers.
De UI-pictogrammen verschillen per besturingssysteemplatform: Windows, iOS en Android. Bij testautomatisering gebruiken de meesten van ons uiteindelijk simulatoren: die voor Android doen er veel langer over om te laden, terwijl iOS-apparaten sneller zijn.
De verschillende toetscombinaties op mobiele apparaten die je op basis van verschillende typen besturingssystemen gebruikt 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 moet je rekening houden met 5 belangrijke vormfactoren voor de verschillende OS-versies, naast de staande of liggende modus 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
Rekening houden met vormfactoren bij het bouwen van mobiele applicaties betekent zorgen voor responsiviteit 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 oorspronkelijke Android- of iOS-ontwikkeling.
Als ze dat niet doen, zullen bedrijven later tijd en moeite 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 voor zowel iOS als Android hoeft te onderhouden.
Er zijn verschillende manieren om mobiele applicaties te ontwikkelen. Sommige bedrijven kiezen voor native programmeertalen zoals Java en Objective C voor respectievelijk Android- en iOS-applicaties. Het voordeel van native talen is dat ze uitgebreide functionaliteit aan hun applicaties kunnen bieden.
Aan de andere kant zullen de element-id's op beide platforms verschillend zijn, wat betekent dat we afzonderlijke native testframeworks nodig hebben om hetzelfde te testen, zoals Espresso op Android, XCUITest op iOS, enz.
React Native is een andere veelgebruikte programmeertaal voor het ontwikkelen van responsieve mobiele applicaties, die door Facebook als opensource beschikbaar is gesteld. 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, waardoor slechts één testframework zoals Appium nodig is om de mobiele applicaties te testen.
Als het gaat om het automatiseren van tests voor mobiele applicaties, 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 mobiele iOS-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, enz. |
| Expliciete wachttijden die een voorwaarde toepassen. | Impliciete wachttijden waarbij sleep() wordt gebruikt, waardoor tests onbetrouwbaar worden. |
| Backend-API-responsen nabootsen 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 kunnen worden geschreven in talen zoals Java, Python, enz., 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 de backend-aanroepen na te bootsen en uitsluitend de gebruikersinterface te testen, als volgt door een basisklasse te maken:
Nu de basisklasse klaar is, voeg ik de daadwerkelijke test toe met behulp van het ontwerppatroon voor paginaobjecten, als volgt:
Zo automatiseer je het testen van mobiele Android-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 benoemen bedrijven expliciet welke versies ze ondersteunen. Dit zorgt ook voor een betere gebruikerservaring.
Frameworks voor Android-automatisering helpen testprocessen zoals Robotium en Selendroid zeker te versnellen. Voor deze bespreking beperken we ons tot de automatiseringstools Espresso en Appium:
| Espresso | Appium |
| Native framework dat binnen de Android-broncode kan worden ondergebracht. | Afzonderlijk testframework dat buiten de broncode is gebouwd. |
| Geschreven in Java en Kotlin | Geschreven in Java, Python enzovoort. |
| Expliciete wachttijden, asynchrone bewerkingen ondersteund door de mogelijkheid van inactieve bronnen | Impliciete wachttijden waarbij sleep() wordt gebruikt, waardoor tests onbetrouwbaar worden. |
| Backendreacties simuleren met opensourcelibraries zoals Mockito en de Retrofit-builder | Ondersteunt het gebruik van een mockserver. |
| Omdat dit een native 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 native appframeworks is dat je mockservers kunt gebruiken om de backend-API-aanroepen te simuleren en zo uitsluitend de gebruikersinterface te testen. Hier is een voorbeeld van code waarin je kunt zien hoe ik dit heb laten werken:
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. Vervolgens 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 als volgt het page-objectpatroon in het framework toegepast:
Tools voor het testen van mobiele apps
Er zijn verschillende testtools in de sector en de keuze hangt af van meerdere factoren:
- Vaardigheden van het team
- Doel van de automatisering
- Doelgroep voor de automatisering: productmanagers/verkopers/engineers/testers
- Compatibiliteit van het testframework en de native broncode
- Aantal hybride apps
Verschillende tools die veel in de sector 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 de focus op automatisering om onze testinspanningen op te schalen, ook prioriteit geven aan prestatietests. Deze spelen namelijk een cruciale rol bij het bepalen of een gebruiker onze applicatie zal blijven gebruiken.
Als het laden van een scherm langer dan 2 seconden duurt, worden mensen onrustig. Dat sluit aan bij ons onderzoek naar de aandachtsspanne. Om gebruikers daarom te behouden, moeten we investeren in prestatietests.
Bij het testen van de appprestaties moeten we de KPI's identificeren en hieraan benchmarken:
- Maximale reactietijd
- Gemiddelde reactietijd
- Gemiddelde verwerkingscapaciteit
- 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 volgen en uitgebreide prestatierapporten leveren voor alle belangrijke prestatieparameters.
Voor het monitoren van de prestaties van mobiele applicaties kunnen we Firebase-prestatiebewaking gebruiken, die controle biedt over prestatiegegevens door inzicht te delen in hoe je app presteert, met een uitsplitsing van trace- en netwerkgegevens naar dimensies zoals app-versie, land, apparaat en netwerktype.
Er zijn andere tools, zoals Appium Studio, Sauce Labs, Testdroid enzovoort, die vergelijkbare mogelijkheden voor prestatiebewaking bieden.
Ik hoop dat dit artikel je een eerste kennismaking met het testen van mobiele applicaties en de belangrijkste factoren die daarmee samenhangen heeft gegeven!
Abonneer je op de nieuwsbrief van The QA Lead voor meer beste werkwijzen en tips om je ontwikkelproces vorm te geven.
Gerelateerd artikel:
Bekijk dit ook:
- WAT IS TESTGEAR? OVERZICHT & RONDLEIDING DOOR DE FUNCTIES
- METRIEKEN VOOR SERVERBEWAKING DIE JE MOET BIJHOUDEN VOOR SYSTEEMGEZONDHEID EN -PRESTATIES
Gerelateerde lijst met hulpmiddelen:
