Prestatietesten van mobiele apps

โšก Slimme samenvatting

Bij prestatietests voor mobiele apps wordt gemeten hoe snel een applicatie opstart, hoeveel batterij en geheugen deze verbruikt, hoe snel de API's reageren en hoe goed deze presteert op onbetrouwbare netwerken.

  • ๐Ÿ”˜ Drie categorieรซn: De prestaties van het apparaat, de server of API en het netwerk samen dekken alle knelpunten in mobiele apparaten.
  • โ˜‘๏ธ Apparaatsignalen: Opstarttijd, batterijverbruik, geheugenverbruik, hardwarevariaties en herstel op de achtergrond zijn de belangrijkste apparaatcontroles.
  • โœ… Serversignalen: De payloadgrootte, het aantal API-aanroepen per actie en een gedocumenteerd failoverplan voor serveruitval.
  • ๐Ÿงช Netwerksignalen: Jitter, pakketverlies en snelheidsveranderingen moeten allemaal een duidelijke melding opleveren in plaats van een bevroren scherm.
  • ๏ธ tooling: RobotiumMonkeyRunner en Automator verschijnen hier, hoewel de eerste twee niet meer worden onderhouden.
  • ๐Ÿ“Š Gereedheid: Een checklist met betrekking tot RAM, responstijd, gelijktijdigheid en crashbestendigheid bepaalt of een build wordt uitgebracht.

Prestatietesten van mobiele apps op apparaat-, server- en netwerkniveau.

Voor elke mobiele app is de prestatie cruciaal. Als uw app niet goed presteert, zal de gebruiker deze verwijderen en een andere app zoeken die beter presteert.

Uw mobiele applicatie moet grondig worden getest voordat deze aan de eindgebruiker wordt vrijgegeven.

Strategie voor het testen van mobiele applicaties

De prestaties van applicaties op een mobiele telefoon of een ander slim apparaat worden doorgaans gemeten in de volgende drie categorieรซn.

  • Apparaatprestaties
  • Server-/API-prestaties
  • Netwerkprestaties

Het onderstaande diagram toont de koppeling tussen die drie lagen en hun controles.

Strategieoverzicht voor het testen van mobiele applicaties, met een onderverdeling in prestatiecontroles voor apparaat, server en netwerk.

Apparaatprestaties

Wanneer de klant ervaart dat de app traag is, raakt hij of zij geรฏrriteerd.

Voor de prestaties van het apparaat kunt u het volgende controleren:

  • App-opstart: Hoeveel tijd heeft het nodig om uw app op te starten? Het is de eerste prestatieparameter die door de gebruiker wordt beoordeeld. Als vuistregel geldt dat nadat de gebruiker op het app-pictogram heeft getikt, het eerste scherm binnen 1-2 seconden moet worden weergegeven.
  • Batterijduur tijdens gebruik van een app: Bij constant gebruik verbruiken sommige mobiele apps veel batterij en wordt de telefoon warm. Dit gebeurt meestal wanneer de app meer resources gebruikt dan nodig, waardoor de processor overbelast raakt.
  • Geheugenverbruik: . Testen een app, moet het geheugenverbruik van een app worden gecontroleerd. Door bepaalde functionaliteiten in de app te implementeren, neemt ook het geheugengebruik toe. Bijvoorbeeld, binnen Android apps wanneer pushmeldingen worden geรฏmplementeerd, neemt het geheugengebruik toe.

    In sommige gevallen is waargenomen dat het geheugengebruik door het hele besturingssysteem slechts 14% bedraagt, terwijl een nieuwe app 11% verbruikt. Deze factoren moeten dus worden afgehandeld voordat de app in de echte wereld wordt geรฏmplementeerd of aan de klant wordt gegeven.

  • Hardware/software-variant: Bij het testen van een mobiele app is het verplicht om apps op verschillende apparaten te controleren. Het kan zijn dat de app op het ene apparaat soepel werkt, maar op het andere niet. Zoals voor verschillende leveranciers van Android apparaten, we kunnen de app controleren op Samsung-, HTC- en Lenovo-telefoons. Op dezelfde manier moet de app worden getest met verschillende RAM- en processorspecificaties, zoals 1 GB of 2 GB.
  • Gebruik met andere apps: Wanneer de geteste app parallel met andere apps wordt uitgevoerd, mag er geen interferentie zijn. De beste manier om dit te controleren is door tussen de app die wordt getest en andere apps te wisselen.
  • App op de achtergrond: Wanneer een app die op de achtergrond draait wordt opgehaald, moet deze in dezelfde staat blijven als voorheen. Als dit scenario niet correct wordt afgehandeld, gaan er gegevens verloren. Gerelateerde levenscyclusscenario's worden behandeld in onderbrekingstests.

Server-/API-prestaties

Wanneer de app via een API met de server communiceert, is de reactietijd cruciaal voor de prestaties. Voor serverprestaties kunt u het volgende controleren:

  • Gegevens van en naar de server: De app moet de gegevens die van de server worden verzonden efficiรซnt verwerken. Het laden van gegevens mag niet te lang duren. In sommige apps worden gegevens in een specifiek formaat verzonden, dus voordat ze in de app worden weergegeven, moeten ze worden geconverteerd naar een relevant formaat. Door dit proces kunnen apps soms trager worden en kan de reactietijd langer worden.
  • API-aanroepen gegenereerd vanuit de app: Het aantal oproepen van de geteste app naar de server gegenereerd door de app zou lager moeten zijn. In sommige gevallen worden meerdere API-aanroepen gedaan voor dezelfde functionaliteit. Voor betere prestaties moet dit met een kleiner aantal oproepen worden afgehandeld.
  • Serveruitval: Mocht de server om welke reden dan ook niet beschikbaar of onbereikbaar zijn, dan kunnen we de gegevens opslaan in de eigen database. Zo kunnen we, zelfs wanneer de server uitvalt, de gegevens uit de eigen database weergeven. Een andere oplossing zou het gebruik van failover-databaseservers kunnen zijn. Dit betekent dat als een van de servers uitvalt of in onderhoud is, de back-upserver beschikbaar moet zijn om de taken over te nemen. De failover-/back-upserver moet continu repliceren en synchroniseren met de hoofdserver.

Netwerkprestaties

De prestaties van de app op verschillende netwerken en netwerkeigenschappen moeten worden gemeten.

Voor netwerkprestaties controleert u de volgende zaken.

  • Zenuwen: Wanneer er een vertraging optreedt bij het ontvangen van informatie op het netwerk, wordt dit jitter genoemd. Het is een probleem met verbindingsloze netwerken of pakketgeschakelde netwerken. Omdat de informatie in pakketten wordt verdeeld, kunnen pakketten via een verschillend pad van de zender naar de ontvanger reizen. Wanneer gegevens op de beoogde locatie aankomen, worden deze gecodeerd dan oorspronkelijk verzonden. In het geval van kriebels zou de mobiele app capabel genoeg moeten zijn om dit aan te kunnen.

    Je moet de eindgebruiker de juiste meldingen tonen, bijvoorbeeld om het verzoek opnieuw te verzenden of te wachten tot het systeem weer reageert.

  • Pakketverlies: In het geval van volledig pakketverlies moet de app het verzoek om informatie opnieuw kunnen verzenden of de waarschuwingen dienovereenkomstig kunnen genereren. Als de gegevens niet compleet zijn, kan de gebruiker de informatie die in de app wordt weergegeven, niet begrijpen. Dit kan stressvol zijn voor de gebruiker. Daarom is het beter om een โ€‹โ€‹passend bericht weer te geven of de gebruiker te vragen het opnieuw te proberen.
  • Netwerksnelheid: De app moet worden getest op verschillende netwerken met wisselende snelheden. De app moet worden getest op 3G-, 4G- en 5G-netwerken. Zowel wifi als mobiele netwerken vallen hieronder. Ook moet het gedrag van de app worden gemonitord, met name wanneer beide netwerken beschikbaar zijn en er wordt overgeschakeld tussen de netwerken.

    Een voorbeeld hiervan is een probleem dat zich kan voordoen bij gebruikers van een app wanneer ze overschakelen van een 4G- naar een wifi-verbinding en vice versa. In dat geval reageert de app niet meer en moet deze mogelijk opnieuw worden opgestart om weer te kunnen functioneren.

Problemen met de prestaties van mobiele applicaties oplossen

Na het ontdekken van de problemen/problemen tijdens Performance Testing. Het is tijd om tracen fouten corrigeren.

Probleem 1) Trage of trage reactie van de mobiele app.

De oorzaak van deze vertraging kan het RAM-geheugen, de cache, enz. zijn.

U moet onnodige processen beรซindigen of de cache wissen. Het oplossen van het connectiviteitsprobleem kan een aantal van de problemen oplossen die vertragingen veroorzaken

Probleem 2) App opnieuw opstarten, vastlopen, vastlopen of niet reageren.

Het kan worden opgelost door een van de volgende stappen

  • Het optimaliseren van de applicatiecodes
  • Software moet worden gepatcht en bijgewerkt.
  • Automatisch herstel
  • Beheer van RAM of in sommige gevallen ROM tijdens gebruik van externe kaarten
  • Wiping de cachepartitionering
  • Controleren of de app samenwerkt met andere apps en API's van derden.
  • Wereldmapping de mobiele applicatie afhankelijk van het apparaat

Handige testtools voor mobiele apps

Testtools voor mobiele apps variรซren afhankelijk van de apparaten of het mobiele besturingssysteem. Enkele veelgebruikte prestatietesttools voor mobiele apps zijn:

ANDROID

  • Robotium Het is net als Selenium voor mobiele apps. De tester kan verschillende stappen opnemen en afspelen die nodig zijn om het testen uit te voeren.
  • Aap Runner MonkeyRunner kan tests uitvoeren op echte apparaten die zijn aangesloten op een pc of emulators. De tool beschikt over een API, waarmee je een smartphone, tablet of emulator van buitenaf kunt besturen Android code.

โš ๏ธ Versie-opmerking: Beiden Android Invoergegevens zijn verouderd. Robotium heeft sinds 2016 geen nieuwe release meer gehad, en Google geeft aan dat MonkeyRunner niet langer wordt onderhouden en verwijst teams naar UI Automator en zijn uiautomatorviewer inspecteur in plaats daarvan.

APPLE

  • Automaat (Mac) Automator is een applicatie ontwikkeld door Apple voor macOSHet maakt het mogelijk om met een muisklik (of sleep-en-drop) workflows te creรซren voor het automatiseren van repetitieve taken in batches, waardoor aanpassingen sneller kunnen worden uitgevoerd. Dit bespaart tijd en moeite in vergelijking met handmatige tussenkomst, waarbij elk bestand afzonderlijk moet worden gewijzigd.

Challenges

De belangrijkste uitdagingen waarmee u te maken krijgt tijdens prestatietests zijn onder meer:

  • Het organiseren van verschillende mobiele platforms en hun besturingssystemen
  • Het simuleren van verbindingen zoals 3G, 4G, 5G of Wi-Fi, enz.
  • Beperkingen voor mobiele apparaten, zoals het verbruik van batterijen en hulpbronnen
  • Gebruiksvriendelijkheid van mobiele telefoons
  • De verschillende formaten mobiele apparaten waarop dezelfde app kan worden uitgevoerd

Prestatietestomgeving voor mobiele apps instellen

Om de testomgeving te configureren, moet u:

  • Inzicht in de mobiele app die getest moet worden
  • Identificatie van verschillende besturingssystemen waarop de app moet draaien
  • Het bouwen van de testopstelling
  • Bouw de emulators of simulators
  • Prototypeping de daadwerkelijke opstelling
  • Het selecteren van het juiste hulpmiddel voor het testen

Controlelijst voor prestatietesten van mobiele apps

Het testen van de prestaties van de mobiele apps is een belangrijke maatregel vรณรณr de release. Om dit te controleren worden prestatietests uitgevoerd

  • Hoeveel RAM is vereist voor het gebruik van deze app?
  • Om de snelheid en responstijd van APP onder verschillende netwerken en omstandigheden te verifiรซren.
  • Zorg voor een realistische gebruikerservaring onder verschillende netwerkomstandigheden
  • Zorg ervoor dat de vereiste resultaten worden bereikt in het geval van meerdere connectiviteiten
  • Zorg ervoor dat de applicatie niet crasht.
  • Ervoor zorgen dat de mobiele applicaties goed presteren tijdens het gebruik van data, Wi-Fi of andere connectiviteit
  • Het monitoren van de uptime en de knelpunten in het mobiele API-gebruik
  • Om het maximale aantal gelijktijdige gebruikers te garanderen
  • Tot slot, om de mobiele app tot het uiterste te controleren

Veelgestelde vragen

Een reactietijd van minder dan twee seconden op een apparaat uit het middensegment is doorgaans het streefdoel, conform de hierboven vermelde regel. Meet het 95e percentiel in plaats van het gemiddelde, omdat trage apparaten de meest voorkomende klachten vormen.

Een ANR is een gebeurtenis waarbij de applicatie niet reageert. Deze gebeurtenis treedt op wanneer de applicatie niet reageert. Android De hoofdthread blokkeert. Het crashvrije percentage is het aandeel sessies dat zonder crash eindigt. Google Play geeft minder prioriteit aan apps die de gepubliceerde drempelwaarden voor een van beide overschrijden.

Zestig frames per seconde is de standaard voor scrollen en animatie, en nieuwere schermen streven naar negentig of meer. Frames die worden overgeslagen, ook wel 'jank' genoemd, worden als slechte kwaliteit ervaren, zelfs als er niets vastloopt.

Machine learning maakt voor elke meetwaarde een basislijn per apparaatmodel, waardoor een regressie wordt geconstateerd op basis van vergelijkbare hardware in plaats van รฉรฉn algemeen getal. Het clustert ook langzame processen. tracDat wil zeggen, rangschikken welke bottleneck de meeste sessies beรฏnvloedt.

Copilot ontwerpt de herhalende basisstructuur goed, zoals een sjabloon voor een laadscript of een lus die geheugenmonsters vastlegt. Drempelwaarden en apparaatselectie zijn afgestemd op uw product, dus controleer elke gegenereerde bewering voordat u deze vertrouwt.

Gebruik ze allebei. Emulators bieden goedkope, herhaalbare netwerk- en API-uitvoeringen binnen een pipeline. Echte apparaten zijn nodig voor batterijverbruik, thermische throttling en fabrikantspecifiek gedrag, eigenschappen die emulators niet nauwkeurig kunnen reproduceren.

JMeter is de meest gebruikte open-source oplossing voor het afhandelen van gelijktijdige verzoeken op dezelfde eindpunten die de applicatie gebruikt. Het meet de servercapaciteit, iets wat tools aan de apparaatzijde nooit zien.

Een vastgelegde limiet voor opstarttijd, geheugen of bundelgrootte die automatisch door het buildproces wordt gecontroleerd. Overschrijding van deze limiet leidt tot een buildfout, waardoor regressies tijdens het samenvoegen worden opgespoord in plaats van na de release.

Vat dit bericht samen met: