Test delle prestazioni delle app mobili

⚡ Riepilogo intelligente

I test di performance delle app per dispositivi mobili misurano la velocità di avvio di un'applicazione, il consumo di batteria e memoria, la rapidità di risposta delle sue API e la sua fluidità di funzionamento su reti instabili.

  • 🔘 Tre categorie: Le prestazioni del dispositivo, le prestazioni del server o dell'API e le prestazioni della rete, considerate insieme, coprono ogni possibile collo di bottiglia nei dispositivi mobili.
  • ☑️ Segnali del dispositivo: I controlli principali del dispositivo includono tempo di avvio, consumo della batteria, consumo di memoria, variazioni hardware e ripristino in background.
  • Segnali del server: Dimensioni del payload, numero di chiamate API per azione e un piano di failover documentato per i tempi di inattività del server.
  • 🧪 Segnali di rete: Jitter, perdita di pacchetti e variazioni di velocità devono tutti produrre un messaggio chiaro e non uno schermo bloccato.
  • Tooling: RobotiumMonkeyRunner e Automator compaiono qui, sebbene i primi due non siano più supportati.
  • 📊 Prontezza: Una checklist che comprende RAM, tempo di risposta, concorrenza e resistenza ai crash decide se una build può essere distribuita.

Test delle prestazioni delle app mobili a livello di dispositivo, server e rete.

Per qualsiasi app mobile, le prestazioni sono fondamentali. Se la tua app non funziona bene, l'utente finale la disinstallerà e cercherà un'altra applicazione con prestazioni migliori.

La tua applicazione mobile deve essere testata accuratamente prima di rilasciarla all'utente finale.

Strategia di test delle applicazioni mobili

Le prestazioni delle applicazioni su un telefono cellulare o su qualsiasi dispositivo intelligente vengono solitamente misurate in base alle tre categorie seguenti.

  • Prestazioni del dispositivo
  • Prestazioni server/API
  • Prestazioni di rete

Il diagramma sottostante associa questi tre livelli ai relativi controlli.

Schema strategico per il test delle applicazioni mobili, con suddivisione dei controlli delle prestazioni in base al dispositivo, al server e alla rete.

Prestazioni del dispositivo

Quando il cliente sperimenta un'app lenta, si arrabbia.

Per valutare le prestazioni del dispositivo, si procederà ai seguenti controlli:

  • Avvio dell'app: Quanto tempo impiega la tua app per avviarsi? È il primo parametro prestazionale giudicato dall'utente. Come regola generale, dopo che l'utente ha toccato l'icona dell'app, la prima schermata dovrebbe essere visualizzata entro 1-2 secondi.
  • Durata della batteria durante l'utilizzo di un'app: Con un utilizzo costante, alcune app per dispositivi mobili consumano molta batteria e surriscaldano il telefono. Questo accade in genere quando l'app utilizza più risorse del necessario, sovraccaricando il processore.
  • Consumo di memoria: Quando Collaudo un'app, è necessario controllare il consumo di memoria di un'app. Implementando determinate funzionalità nell'app aumenta anche il consumo di memoria. Ad esempio, nel Android app quando vengono implementate le notifiche push, il consumo di memoria aumenta.

    In alcuni casi, è stato osservato che l'utilizzo della memoria da parte dell'intero sistema operativo è solo del 14%, ma una nuova app consuma l'11%. Pertanto, questi fattori devono essere gestiti prima di distribuire l'app nel mondo reale o fornirla al cliente.

  • Variante hardware/software: Quando si testa un'app mobile, è obbligatorio controllare le app su dispositivi diversi. È possibile che l'app funzioni correttamente su un dispositivo ma non su un altro. Come per diversi fornitori di Android dispositivi, possiamo controllare l'app sui telefoni Samsung, HTC e Lenovo. Allo stesso modo, l'app deve essere testata con diverse specifiche di RAM e processore come 1 GB o 2 GB.
  • Utilizzo con altre app: Quando l'app in prova viene eseguita in parallelo con altre app, non dovrebbero esserci interferenze. Il modo migliore per verificarlo è cambiare l'app in fase di test e altre app.
  • Applicazione in background: Quando un'app in esecuzione in background viene recuperata, dovrebbe rimanere nello stesso stato di prima. Se questo scenario non viene gestito correttamente, i dati vengono persi. Casi del ciclo di vita correlati sono trattati in test di interruzione.

Prestazioni server/API

Quando l'app interagisce con il server tramite API, il tempo di risposta diventa fondamentale per le prestazioni. Per valutare le prestazioni del server, è necessario verificare:

  • Dati da e verso il server: L'app deve gestire in modo efficiente i dati inviati dal server. Il caricamento dei dati non deve richiedere troppo tempo. In alcune app, i dati vengono inviati in un formato specifico, quindi prima di visualizzarli nell'app, devono essere convertiti in un formato compatibile. Durante questo processo, le app a volte rallentano e i tempi di risposta si allungano.
  • Chiamate API generate dall'app: Il numero di chiamate dall'app in prova al server generato dall'app dovrebbe essere inferiore. In alcuni casi, vengono effettuate più chiamate API per la stessa funzionalità. Per prestazioni migliori, questo dovrebbe essere gestito con un numero inferiore di chiamate.
  • Tempo di inattività del server: Se per qualsiasi motivo il server non è disponibile o non raggiungibile, possiamo salvare i dati nel database nativo. Pertanto, anche in caso di inattività del server, possiamo visualizzare i dati memorizzati nel database nativo. Un'altra soluzione potrebbe essere l'utilizzo di server di database di failover: se uno dei server non è disponibile o è in fase di manutenzione, il server di backup deve essere pronto a subentrare. Il server di failover/backup deve essere in costante replica e sincronizzazione con il server principale.

Prestazioni di rete

È necessario misurare le prestazioni dell'app su diverse reti e proprietà di rete.

Per le prestazioni della rete, dovrai controllare i seguenti elementi.

  • Nervosismo: Quando si verifica un ritardo nella ricezione delle informazioni sulla rete, si parla di nervosismo. È un problema con le reti senza connessione o le reti a commutazione di pacchetto. Poiché le informazioni vengono distribuite in pacchetti, i pacchetti possono viaggiare lungo un percorso diverso dal mittente al destinatario. Quando i dati arrivano nella posizione prevista, vengono criptati rispetto a quando sono stati originariamente inviati. Nel caso di Jitters, l'app mobile dovrebbe essere sufficientemente in grado di gestirlo.

    È necessario mostrare all'utente finale le notifiche appropriate, chiedendogli di reinviare la richiesta o di attendere una nuova risposta dal sistema.

  • Perdita di pacchetti: In caso di perdita completa del pacchetto, l'app dovrebbe essere in grado di inviare nuovamente la richiesta di informazioni o generare avvisi di conseguenza. Se i dati non sono completi, l'utente non sarà in grado di comprendere le informazioni visualizzate nell'app. Questo può essere stressante per l'utente. Pertanto, è meglio visualizzare un messaggio appropriato o chiedere all'utente di riprovare.
  • Velocità di rete: L'app deve essere testata su diverse reti con velocità variabili. È necessario testarla su reti 3G, 4G e 5G, incluse sia le reti Wi-Fi che quelle mobili. Inoltre, è fondamentale monitorare il comportamento dell'app, soprattutto quando entrambe le reti sono disponibili e si verifica un passaggio da una all'altra.

    Ad esempio, potrebbe verificarsi un problema in un'app quando gli utenti passano dalla rete 4G al Wi-Fi e viceversa. In questo caso, l'app smette di rispondere e potrebbe essere necessario riavviarla per poterla utilizzare.

Risoluzione dei problemi relativi alle prestazioni delle applicazioni mobili

Dopo aver scoperto i problemi/problemi while Test di Performance. È ora di farlo trace correggere i guasti.

Problema 1) Ritardo o risposta lenta dell'app mobile.

La causa di questo ritardo potrebbe essere la RAM, la cache, ecc.

È necessario terminare i processi non necessari o svuotare la cache. La risoluzione dei problemi di connettività può risolvere alcuni dei problemi che creano ritardi

Problema 2) Riavvio, blocco, blocco o mancata risposta dell'app.

Potrebbe essere risolto tramite alcuni dei seguenti passaggi

  • Ottimizzazione dei codici applicativi
  • Il software dovrebbe essere patchato e aggiornato.
  • Ripristini automatici
  • Gestione della RAM o in alcuni casi della ROM durante l'utilizzo di schede esterne
  • Wiping partizionamento della cache
  • Verifica della compatibilità dell'app con altre app e API di terze parti
  • Mappaping l'applicazione mobile in base al dispositivo

Strumenti utili per testare le app mobili

Strumenti di test delle app mobili variano a seconda dei dispositivi o del sistema operativo mobile. Alcuni strumenti comuni di test delle prestazioni delle app mobili sono

ANDROID

  • Robotium È proprio come Selenium per le app mobili. Il tester può registrare e riprodurre diversi passaggi necessari per eseguire il test.
  • Scimmia Runner MonkeyRunner può eseguire test su dispositivi reali collegati a un PC o emulatori. Lo strumento dispone di un'API che consente di controllare uno smartphone, un tablet o un emulatore dall'esterno Android codice.

⚠️ Nota sulla versione: Entrambi i progetti editoriali di Android Le voci sono obsolete. Robotium non ha avuto alcuna pubblicazione dal 2016 e Google contrassegna MonkeyRunner non più mantenuto, indirizzando i team a UI Automator e al suo uiautomatorviewer ispettore invece.

APPLE

  • Automator (Mac) Automator è un'applicazione sviluppata da Apple per macOSImplementa la creazione di flussi di lavoro tramite interfaccia grafica (con trascinamento) per automatizzare le attività ripetitive e raggrupparle in batch, consentendo modifiche più rapide. Ciò permette di risparmiare tempo e fatica rispetto all'intervento umano necessario per modificare manualmente ogni singolo file.

Le sfide

Le principali sfide affrontate durante i test delle prestazioni includono

  • Organizzazione di diverse piattaforme mobili e dei relativi sistemi operativi
  • Simulazione di connettività come 3G, 4G, 5G o Wi-Fi, ecc.
  • Vincoli dei dispositivi mobili come il consumo di batteria e risorse
  • Usabilità del telefono cellulare
  • Le dimensioni assortite dei dispositivi mobili per eseguire la stessa app

Configurare l'ambiente di test delle prestazioni dell'app mobile

Per configurare l'ambiente di test, è necessario-

  • Comprensione dell'app mobile che deve essere testata
  • Identificazione del diverso sistema operativo su cui deve essere eseguita l'app
  • Costruire la configurazione del test
  • Costruisci gli emulatori o i simulatori
  • Prototipoping dell'attuale configurazione
  • Selezione dello strumento appropriato per il test

Elenco di controllo per il test delle prestazioni delle app mobili

Testare le prestazioni delle app mobili è una misura importante prima del rilascio. Il test delle prestazioni viene eseguito per verificare

  • Quanta RAM è necessaria per utilizzare questa app?
  • Per verificare la velocità e i tempi di risposta dell'APP in diverse reti e circostanze.
  • Garantisci un'esperienza utente realistica in diverse condizioni di rete
  • Garantire che i risultati richiesti siano raggiunti in caso di connettività multiple
  • Assicurati che l'applicazione non subisca arresti anomali.
  • Garantire che le applicazioni mobili funzionino bene durante l'utilizzo di dati, Wi-Fi o altra connettività
  • Monitoraggio dell'uptime e dei colli di bottiglia nell'utilizzo delle API mobili
  • Per garantire il numero massimo di utenti simultanei
  • Infine, per verificare i limiti dell'app mobile

DOMANDE FREQUENTI

Un tempo di risposta inferiore a due secondi su un dispositivo di fascia media è l'obiettivo usuale, in linea con la regola sopracitata. È preferibile misurare il 95° percentile piuttosto che la media, poiché i reclami reali riguardano principalmente i dispositivi lenti.

Un ANR è un evento di Applicazione non rispondente, generato quando l'applicazione non risponde. Android blocchi del thread principale. Il tasso di sessioni senza arresti anomali è la percentuale di sessioni che terminano senza un arresto anomalo. Google Play declassa le app che superano le soglie pubblicate per entrambi.

Sessanta fotogrammi al secondo è il valore di base per lo scorrimento e le animazioni, mentre i display più recenti puntano a novanta o più. La perdita di fotogrammi, detta "jank", si traduce in una scarsa qualità anche in assenza di crash.

L'apprendimento automatico definisce una base di riferimento per ogni metrica per modello di dispositivo, in modo che una regressione venga segnalata rispetto ad hardware simile piuttosto che a un singolo numero globale. Inoltre, raggruppa i rallentamenti. tracsì, classificando quale collo di bottiglia influisce sul maggior numero di sessioni.

Copilot genera in modo efficace la struttura ripetitiva, come ad esempio lo scheletro di uno script di caricamento o un ciclo che acquisisce campioni di memoria. Le soglie e la selezione dei dispositivi rispecchiano il tuo prodotto, quindi rivedi ogni asserzione generata prima di considerarla attendibile.

Utilizzateli entrambi. Gli emulatori offrono test di rete e API economici e ripetibili all'interno di una pipeline. I dispositivi reali sono necessari per riprodurre fedelmente il consumo della batteria, la limitazione termica e i comportamenti specifici del fornitore, aspetti che gli emulatori non sono in grado di replicare.

JMeter è la scelta open-source più comune per gestire le richieste simultanee agli stessi endpoint utilizzati dall'applicazione. Misura la capacità del server, che gli strumenti lato dispositivo non vedono mai.

Un limite preimpostato per il tempo di avvio, la memoria o la dimensione del pacchetto che il processo di compilazione verifica automaticamente. Il superamento di tale limite causa l'interruzione della compilazione, consentendo di individuare le regressioni in fase di unione anziché dopo il rilascio.

Riassumi questo post con: