Mobile App Performance Test

Af: Thomas Hamilton Thomas Hamilton
Hours Opdateret

⚡ Smart opsummering

Mobile App Performance Testing measures how quickly an application starts, how much battery and memory it consumes, how fast its APIs respond, and how gracefully it behaves on unreliable networks.

  • 🔘 Three categories: Device performance, server or API performance, and network performance together cover every mobile bottleneck.
  • ☑️ Device signals: Start-up time, battery drain, memory consumption, hardware variation and background restore are the core device checks.
  • ✅ Server signals: Payload size, the number of API calls per action, and a documented failover plan for server downtime.
  • 🧪 Netværkssignaler: Jitter, packet loss and speed changes must all produce a clear message rather than a frozen screen.
  • 🛠️ Værktøj: Robotium, MonkeyRunner and Automator appear here, though the first two are no longer maintained.
  • 📊 Beredskab: A checklist covering RAM, response time, concurrency and crash resistance decides whether a build ships.
Læs mere

Mobile app performance testing across device, server and network layers

For any mobile app, performance is very critical. If your Mobile App does not perform well, the end user will uninstall your app and find another application that performs better.

Din mobilapplikation skal testes grundigt, før den frigives til slutbrugeren.

Mobilapplikationsteststrategi

Applikationsydelse på en mobiltelefon eller en hvilken som helst smart enhed måles normalt i følgende tre kategorier.

  • Enhedens ydeevne
  • Server/API ydeevne
  • Netværkets ydeevne

The diagram below maps those three layers to their checks.

Mobile application testing strategy chart splitting device, server and network performance checks

Enhedens ydeevne

Når klienten oplever langsom app, bliver de irriterede.

For device performance, you will check following:

  • App Start-Up: Hvor lang tid tager din app at starte op? Det er den første præstationsparameter, der bedømmes af brugeren. Som en tommelfingerregel, efter at brugeren trykker på app-ikonet, skal den første skærm vises om 1-2 sekunder.
  • Battery Time while using an app: On constant use, some mobile apps consume a high amount of battery life and heat the phone. This normally happens when your app is using more resources than required, which creates a burden on the processor.
  • Hukommelsesforbrug: Når Test en app, skal hukommelsesforbruget af en app kontrolleres. Ved at implementere visse funktionaliteter i appen, øges hukommelsesforbruget også. For eksempel i Android apps, når push-meddelelser implementeres, øges hukommelsesforbruget.

    I nogle tilfælde er det blevet observeret, at hukommelsesforbruget af hele OS kun er 14%, men en ny app bruger 11%. Så disse faktorer skal håndteres, før du implementerer appen til den virkelige verden eller giver den til klienten.

  • Hardware/Software Variation: Når du tester en mobilapp, er det obligatorisk at tjekke apps på forskellige enheder. Det kan være tilfældet, at appen kører problemfrit på én enhed, men ikke på en anden. Gerne for forskellige leverandører af Android enheder, kan vi tjekke appen på Samsung-, HTC- og Lenovo-telefoner. På samme måde skal appen testes med forskellige RAM- og processorspecifikationer som 1 GB eller 2 GB.
  • Usage with Other Apps: Når den testede app kører parallelt med andre apps, bør der ikke være nogen interferens. Den bedste måde at kontrollere det på er ved at skifte app under test og andre apps.
  • App in background: When an app that is running in the background is retrieved, it should remain in the same state as it was before. If this scenario is not handled properly, then data get lost. Related lifecycle cases are covered in interrupt testing.

Server/API ydeevne

When the app is interacting with the server via API, the response time becomes critical to performance. For Server performance, you will check:

  • Data to and from server: The app should handle data efficiently that is sent from the server. It must not take too much time while loading data. In certain apps, data is sent in a specified format, so before displaying it in the app, it should be converted to a relevant format. In this process, apps sometimes become slower and response time becomes longer.
  • API Calls Generated from App: Antallet af opkald fra appen under test til serveren, der genereres fra appen, bør være mindre. I nogle tilfælde foretages der flere API-kald for den samme funktionalitet. For bedre ydeevne bør dette håndteres med færre opkald.
  • Server Down Time: Due to any reason if the server is down or unreachable we can save data in the native database. So, whenever the server is down, we can show data stored in the native database. Another solution could be the failover database servers, i.e. if one of the servers is down or in maintenance phase the backup server should be available to switch over. The failover/backup server should be in continuous replication and synchronization with the main server.

Netværkets ydeevne

Appens ydeevne på forskellige netværk og netværksegenskaber skal måles.

For netværksydelse vil du kontrollere følgende ting.

  • Rystelser: Når der er en forsinkelse i at modtage information på netværket, betegnes det som jitters. Det er et problem med de forbindelsesløse netværk eller pakkeswitch-netværk. Da informationen distribueres i pakker, kan pakker rejse ad en forskellig vej fra afsender til modtager. Når data ankommer til det tilsigtede sted, bliver det krypteret, end det oprindeligt blev sendt. I tilfælde af Jitters bør mobilappen være i stand nok til at håndtere det.

    You need to show the appropriate notifications to the end user, either to resend the request or wait till the system responds again.

  • Pakketab: I tilfælde af fuldstændigt pakketab bør appen være i stand til at sende anmodningen om oplysningerne igen eller generere advarslerne i overensstemmelse hermed. Hvis data ikke er fuldstændige, vil brugeren ikke være i stand til at forstå de oplysninger, der vises i appen. Dette kan være stressende for brugeren. Så det er bedre at vise en passende besked eller bede brugeren om at prøve igen.
  • Netværkshastighed: The app needs to be checked on a variety of networks with variable speed. The app should be tested on 3G, 4G, and 5G networks. Both Wi-Fi and mobile networks are included in this. Also, the behavior of app should be monitored, especially when both networks are available and switching occurred from one network to another.

    For example, an issue may arise in an app for the users while switching phone network from 4G to Wi-Fi and vice versa. In this case, the app becomes unresponsive and may require restarting the app for use.

RELATEREDE ARTIKLER

Fejlfinding af mobilapplikationers ydeevne

Efter at have opdaget problemerne/problemerne mens Test af ydeevneDet er tid til at trace og rette fejl.

Problem 1) Forsinket eller trægt svar fra mobilappen.

Årsagen til denne forsinkelse kan være RAM, cache osv.

Du skal dræbe unødvendige processer eller rydde cachen. Fejlfinding af forbindelsesproblemet kan løse nogle af de problemer, der skaber forsinkelser

Problem 2) Genstart af app, låsning, frysning eller manglende respons.

Det kan løses ved nogle af de følgende trin

  • Optimering af applikationskoder
  • Software skal lappes og opdateres.
  • Automatiske gendannelser
  • Håndtering af RAM eller i nogle tilfælde ROM, mens du bruger eksterne kort
  • Wiping cache-partitioneringen
  • Verifying the app working with other third-party apps and APIs
  • Kortping mobilapplikationen i henhold til enhed

Nyttige værktøjer til test af mobilapps

Værktøjer til test af mobilapps varierer afhængigt af enheder eller mobil OS. Nogle almindelige mobilapps Ydelsestestværktøjer er

ANDROID

  • Robotium Det er ligesom Selenium til mobilapps. Testeren kan optage og afspille flere trin, der er nødvendige for at udføre test.
  • Abeløber MonkeyRunner kan køre test på rigtige enheder forbundet til en pc eller emulatorer. Værktøjet har en API, som gør det muligt at styre en smartphone, en tablet eller en emulator udefra Android kode.

⚠️ Versionsnotat: Både Android entries are legacy. Robotium has had no release since 2016, and Google marks MonkeyRunner unmaintained, pointing teams to UI Automator and its uiautomatorviewer inspector instead.

ÆBLE

  • Automatiser (Mac) Automator is an application developed by Apple for macOS. It implements point-and-click (or drag and drop) creation of workflows for automating repetitive tasks into batches for quicker alteration. This saves time and effort over human intervention to manually change each file separately.

Udfordringer

Nøgleudfordringer, der står over for, mens præstationstestning omfatter

  • Organisering af forskellige mobile platforme og deres operativsystemer
  • Simulating connectivities like 3G, 4G, 5G or Wi-Fi, etc.
  • Begrænsninger for mobile enheder som batteri- og ressourceforbrug
  • Mobiltelefon anvendelighed
  • De forskellige størrelser af mobile enheder til at køre den samme app

Konfigurer Mobile App Performance Test Environment

For at konfigurere testmiljøet skal du-

  • Forståelse af den mobile app, som skal testes
  • Identifikation af forskellige OS, som appen skal køre på
  • Opbygning af testopsætningen
  • Byg emulatorerne eller simulatorerne
  • Prototyping af den faktiske opsætning
  • Valg af det passende værktøj til testen

Tjekliste til test af mobilapps ydeevne

Test af ydeevnen af ​​mobilapps er en vigtig foranstaltning før udgivelse. Ydelsestest udføres for at kontrollere

  • Hvor meget af RAM'en kræves for at bruge denne app?
  • For at verificere hastighed og responstid for APP under forskellige netværk og omstændigheder.
  • Sikre realistisk brugeroplevelse under flere netværksforhold
  • Sørg for, at de nødvendige resultater opnås i tilfælde af flere tilslutningsmuligheder
  • Sørg for, at applikationen ikke går ned.
  • Sikre, at de mobile applikationer fungerer godt, mens de bruger data, Wi-Fi eller anden forbindelse
  • Overvågning af oppetiden og flaskehalse for mobil API-brug
  • For at sikre det maksimale antal samtidige brugere
  • Til sidst, for at kontrollere mobilappen til dens grænser

Ofte Stillede Spørgsmål

Under two seconds on a mid-range device is the usual target, matching the rule stated above. Measure the 95th percentile rather than the average, because slow devices dominate real complaints.

An ANR is an Application Not Responding event, raised when the Android main thread blocks. Crash-free rate is the share of sessions ending without a crash. Google Play deprioritises apps that exceed its published thresholds for either.

Sixty frames per second is the baseline for scrolling and animation, and newer displays target ninety or higher. Dropped frames, called jank, read as poor quality even when nothing crashes.

Machine learning baselines each metric per device model, so a regression is flagged against similar hardware rather than one global number. It also clusters slow traces, ranking which bottleneck affects the most sessions.

Copilot drafts the repetitive scaffolding well, such as a load script skeleton or a loop that captures memory samples. Thresholds and device selection reflect your product, so review every generated assertion before trusting it.

Use both. Emulators give cheap, repeatable network and API runs inside a pipeline. Real devices are required for battery drain, thermal throttling and vendor-specific behaviour, which emulators cannot reproduce faithfully.

JMeter is the common open-source choice for driving concurrent requests at the same endpoints the application uses. It measures server capacity, which device-side tools never see.

A recorded limit for start-up time, memory or bundle size that the build checks automatically. Exceeding it fails the build, so regressions are caught at merge time instead of after release.

Opsummer dette indlæg med: