Test di interruzione nell'applicazione mobile

⚡ Riepilogo intelligente

Il test di interruzione verifica il comportamento di un'applicazione mobile quando viene interrotta da una chiamata, una sveglia, una notifica o una perdita di rete, e se l'applicazione ritorna esattamente al suo stato precedente una volta terminata l'interruzione.

🔘 Scopo: Questa tecnica appartiene al settore del test delle applicazioni mobili, ma è applicabile anche al web e ai software autonomi.
☑️ Fonti di interruzione: Le chiamate in arrivo, gli SMS, le sveglie, la batteria scarica, gli eventi di ricarica, gli aggiornamenti delle app e i cambiamenti di rete coprono la maggior parte degli scenari reali.
✅ Quattro possibili risultati: Esegui in background, mostra un avviso, una call to action o nessun impatto: ogni applicazione definisce quale opzione applicare.
🧪 Progettazione del test: Il test di interruzione è un sottoinsieme del test funzionale, quindi si applicano gli stessi framework, casi di test e processi di esecuzione.
️ simulazione: I controlli estesi dell'emulatore, le impostazioni del dispositivo e le funzionalità cloud del dispositivo reale riproducono chiamate, avvisi e perdite di connettività su richiesta.
📊 Non si tratta di un test di ripristino: Il test di ripristino convalida il ripristino dopo un errore, mentre un'interruzione è solo un'interruzionetracuna zione, non un difetto.

Scopri di più

Cos'è il test di interruzione?

Test di interruzione È una branca del test delle applicazioni mobili che si occupa di come un'applicazione reagisce a un'interruzione e riprende il suo stato precedente. L'interruzione proviene dall'esterno dell'applicazione (sistema operativo, hardware o un'altra app) e il test verifica che nessun dato, stato dello schermo o transazione in corso venga perso al ripristino del controllo.

Il test di interruzione si applica a qualsiasi tipo di applicazione: web, mobile, standalone e così via. La varietà di dispositivi, reti e configurazioni lo rende molto più importante per mobile applicazioni rispetto alle altre.

Perché hai bisogno del test di interruzione?

Qual è la cosa che accade quasi sempre durante una riunione? Si viene interrotti, giusto? Quando succede, alcuni non battono ciglio, altri hanno bisogno di un minuto per riprendersi e altri ancora perdono completamente il filo del discorso. In parole semplici, il test di interruzione cerca di scoprire quale comportamento manifesta la tua applicazione in queste situazioni.

Mettiamo da parte per un attimo le formulazioni e consideriamo un'altra situazione reale. Supponiamo di avere una torcia elettrica e di accenderla. La batteria si scarica, interrompendo il suo stato di funzionamento. Sostituiamo le batterie e riaccendiamo la torcia. Questa dovrebbe tornare ad accendersi normalmente. Questo è il caso d'uso. Una disciplina di test che si concentra sul verificare se ciò accade o meno è il test di interruzione.

Il ragionamento alla base è semplice. Un'interruzione si verifica nel momento peggiore possibile – a metà di un pagamento, di un caricamento o di un modulo – e un utente che perde il lavoro svolto raramente ci riprova. Arresti anomali alla ripresa dell'operazione, schermate vuote, transazioni duplicate e perdita di dati inseriti nei moduli sono tutti difetti che solo un'interruzione può rivelare, ed è per questo che sopravvivono a un test funzionale che non prevede mai interruzioni.

Tipo di interruzioni nell'applicazione mobile

Le interruzioni rientrano in alcune categorie ben note, riassunte nell'illustrazione seguente.

Tutti conosciamo le interruzioni più comuni che si verificano di solito. Eccone alcune:

Batteria scarica
Batteria completamente carica
Telefonata in arrivo
SMS in arrivo
Notifica in arrivo da un'altra applicazione mobile
Collegato per la ricarica
Scollegato dalla ricarica
Dispositivo spento
Promemoria per l'aggiornamento delle applicazioni
allarme
Perdita della connessione di rete
Ripristino della connessione di rete

Questo elenco non è esaustivo, ma include gli scenari più comuni. Un modo pratico per organizzarlo è in base all'origine: eventi dipendenti dal dispositivo, come la batteria e la ricarica; eventi avviati dall'utente, come rispondere a una chiamata o passare da un'app all'altra; ed eventi esterni, come la perdita di segnale in ascensore o in galleria.

Risoluzione in caso di Interrupt

Il comportamento previsto in caso di tali interruzioni è uno dei seguenti quattro:

Esegui in background: L'interruzione prende il sopravvento mentre l'applicazione passa in secondo piano. Riprende il controllo al termine dell'interruzione. Ad esempio, una telefonata o una videochiamata FaceTime a cui si risponde mentre si sta leggendo un libro digitale su iBooks (o un'applicazione simile). Quando l'utente risponde al telefono, iBooks attende che la chiamata termini e poi riprende la lettura al termine.
Mostra avviso: L'avviso scompare e si continua a lavorare normalmente. Nell'intestazione compare il messaggio "SMS ricevuto". L'utente non se ne preoccupa e continua a utilizzare l'applicazione come di consueto. Anche altri avvisi di app per dispositivi mobili, come una nuova richiesta di amicizia su Facebook o un messaggio WhatsApp, rientrano in questa categoria. Tuttavia, se l'utente decide di leggere il messaggio, si verifica il comportamento descritto al punto 1. Se l'avviso viene ignorato, lo stato dell'applicazione rimane invariato.
Chiamare all'azione: Le sveglie devono essere disattivate o posticipate prima di poter continuare a lavorare. Lo stesso vale per i messaggi di aggiornamento delle app. È necessario annullare o accettare le modifiche prima di procedere. Un altro esempio è l'avviso di batteria scarica: è possibile scegliere di continuare normalmente o attivare la modalità di risparmio energetico, se il dispositivo lo consente.
Nessun impatto: Un esempio è quando una connessione di rete diventa disponibile e il tuo dispositivo si connette ad essa. Allo stesso modo, quando colleghi il dispositivo per la ricarica, non è necessario alcun avviso o invito all'azione. Probabilmente svolgerà la sua funzione mentre continui a utilizzare l'applicazione.

Pertanto, a seconda dell'interruzione che si sta testando, è necessario comprenderne il comportamento e verificare se la propria applicazione lo soddisfa. Inoltre, il comportamento descritto sopra potrebbe non essere lo stesso per tutte le applicazioni e i dispositivi. Assicuratevi di conoscere i dettagli specifici della vostra app mobile.

Test di interruzione Casi di test con risultati attesi

Una volta concordata la soluzione prevista, ogni interruzione diventa un normale caso di test con un trigger, un'azione e un risultato verificabile. La tabella seguente mostra come le quattro soluzioni sopra descritte si traducono in scenari concreti.

Interruzione	Scenario di prova	Risultato atteso
Telefonata in arrivo	Avvia una chiamata mentre un modulo è parzialmente compilato, rispondi e poi termina la chiamata.	L'applicazione passa in background e riprende sulla stessa schermata con i dati inseriti intatti.
SMS in arrivo o notifica push	Invia un messaggio mentre è in corso un video o un caricamento e ignora il banner	Il banner appare e scompare; lo stato dell'applicazione rimane invariato.
allarme	Lascia che un allarme programmato si attivi durante una sessione attiva e poi disattivalo	L'allarme richiede prima un invito all'azione, dopodiché l'applicazione riprende da dove si era interrotta.
Avviso di batteria scarica	Scaricare il dispositivo fino alla soglia di avviso durante una transazione	Viene visualizzato un avviso, la transazione non viene annullata e la modalità di risparmio energetico non rompe lo schermo
Perdita della connessione di rete	Disabilitare la connettività durante la richiesta, quindi ripristinarla.	Viene visualizzato un messaggio chiaro, non si verifica alcun arresto anomalo e la richiesta viene completata o fallisce in modo sicuro al ripristino.
Ricarica con o senza cavo	Collegare e scollegare il caricabatterie durante una sessione attiva	Nessun impatto: l'applicazione continua a funzionare senza modifiche visibili.
Promemoria per l'aggiornamento dell'applicazione	Visualizza una richiesta di aggiornamento mentre l'applicazione è in uso	L'utente può annullare o accettare, e la schermata sottostante rimane invariata indipendentemente dalla scelta.

Mantieni una riga per ogni interruzione per ogni schermata critica, anziché una riga per ogni interruzione per l'intera applicazione. La schermata di pagamento, la schermata di accesso e un modulo lungo presentano ciascuna un errore diverso, e un singolo caso generico nasconde questa differenza.

Ora che abbiamo capito cos'è l'Interrupt Testing e cosa convalidare quando lo si esegue, è tempo di parlare di come farlo.

Come eseguire il test di interruzione

Guarda questa affermazione: iBooks deve funzionare in background quando l'utente riceve una telefonata in arrivo.

Non lo considereresti un requisito funzionale dell'app iBooks? Io sì.

Quindi, il test degli interrupt è un sottoinsieme di Test di funzionalità per un'applicazione mobile. Per condurre i test di interruzione si utilizzano gli stessi framework e strumenti di test per applicazioni mobili. È compito dei tester ideare questi scenari. Una volta fatto ciò, si progettano i casi di test e li si esegue esattamente come qualsiasi altro test.

In pratica la sequenza è breve e ripetibile:

Elenca i percorsi utente critici: accesso, pagamento, caricamento, compilazione di moduli lunghi, riproduzione di contenuti multimediali.
Mappa ogni possibile interruzione dall'elenco sopra riportato su ciascun viaggio.
Concordate con il responsabile del prodotto la soluzione prevista per ogni abbinamento, poiché non esiste un valore predefinito universale.
Eseguire l'interruzione nel momento più rischioso, non in un momento di inattività, e poi riprendere.
Dopo la ripresa, verificare lo stato, i dati, la sessione e la memoria, non limitarsi a constatare che l'applicazione sia ancora aperta.

Per ulteriori informazioni sulla disciplina più ampia, consultare il Test mobili tutorial e i casi di esempio in Test delle app mobili.

Strumenti e tecniche per simulare le interruzioni

Gli scenari sopra descritti devono essere generati su richiesta, non si può attendere che siano pronti, e ogni piattaforma offre un modo per farlo.

Android Controlli estesi dell'emulatore: Il pannello laterale dell'emulatore simula una chiamata in arrivo, un SMS, il livello della batteria e lo stato di carica, nonché la potenza del segnale cellulare, in modo che la maggior parte delle interruzioni possa essere gestita senza bisogno di un secondo telefono.
Simulatore iOS e Xcode: La connettività e lo stato dell'hardware possono essere modificati sia dal simulatore che dalle impostazioni del dispositivo, mentre un dispositivo fisico associato copre gli scenari di chiamata che un simulatore non è in grado di riprodurre.
Un secondo dispositivo fisico: Effettuare una chiamata o inviare un messaggio al dispositivo in fase di test da un altro telefono rimane il metodo più fedele per riprodurre un'interruzione reale, soprattutto nei casi in cui la tempistica è fondamentale.
Impostazioni del dispositivo: Modalità aereo, interruttori Wi-Fi, Non disturbare, risparmio energetico e sveglie programmate gestiscono le interruzioni di connettività e di alimentazione su hardware reale.
Framework di automazione: Lo stesso stack di automazione utilizzato per il resto della suite di funzionalità può gestire l'applicazione prima e dopo l'interruzione, in modo che il controllo di ripresa venga eseguito in modo automatico anziché manualmente.
Cloud su dispositivi reali: Un cluster di dispositivi ospitato amplia la copertura tra produttori e versioni del sistema operativo, aspetto importante perché la gestione delle interruzioni è una delle aree in cui le personalizzazioni dei fornitori divergono maggiormente.

Qualunque sia il meccanismo, registra il momento esatto dell'interruzione nel caso di test. "Interruzione durante il caricamento" e "interruzione dopo il caricamento" sono test diversi con modalità di errore diverse.

Migliori pratiche per il test degli interrupt

Alcune abitudini distinguono una suite di gestione delle interruzioni efficace da un mero esercizio di mera formalità.

Interrompere nel momento peggiore: Target nell'istante in cui una transazione viene confermata o un file viene scritto, perché è lì che lo stato è più fragile.
Verifica il curriculum, non l'interruzione: Il difetto si manifesta quasi sempre dopo il ripristino del controllo, quindi le asserzioni vanno effettuate sulla schermata ripristinata.
Descrivere entrambe le direzioni di una modifica della rete: Perdere una connessione e ristabilirla sono due casi distinti, e il secondo viene saltato più spesso.
Variare la durata: Un avviso di due secondi e una chiamata di dieci minuti spingono l'applicazione attraverso diversi percorsi del ciclo di vita, incluso l'essere rimossa dalla memoria.
Diffusione su diverse versioni del sistema operativo e hardware di fascia bassa: La rimozione dello sfondo è molto più aggressiva sui dispositivi con risorse limitate, il che fa emergere i difetti che un telefono di punta tende a nascondere.
Automatizza le operazioni ripetitive: La connettività e le interruzioni della batteria vengono gestite automaticamente in modo impeccabile, liberando l'utente dall'intervento manuale per le chiamate e gli allarmi.
Monitorare l'utilizzo delle risorse e il loro stato: Un'interruzione che causa perdite di memoria o scarica la batteria al ripristino è un difetto anche quando lo schermo appare corretto, il che collega questo lavoro a test delle prestazioni delle app mobili.

Il test di interruzione non è uguale al test di ripristino?

No non lo è. Test di recupero convalida il ripristino da un guasto. Un'interruzione non è necessariamente un guasto, è una semplice disconnessionetraczione.

È come la differenza tra una virgola e un punto in italiano. La distinzione è puramente tecnica, ma il concetto è chiaro. Il Recovery Testing verifica se l'applicazione è in grado di riavviarsi dopo un errore; l'Interrupt Testing verifica se si verifica un errore quando qualcos'altro prende il sopravvento.

Ecco cosa bisogna sapere per iniziare con l'Interrupt Testing, una branca importante e intuitiva del test delle applicazioni mobili.

DOMANDE FREQUENTI

Gli scenari sono gli stessi, ma i risultati non lo sono. Le due piattaforme gestiscono le app in background e l'eliminazione della memoria in modo diverso, e Android Le interfacce utente dei fornitori aggiungono le proprie regole relative alla batteria, pertanto lo stesso test può avere esito positivo su una famiglia di dispositivi e fallire su un'altra.

I modelli di intelligenza artificiale leggono le user story e i report degli arresti anomali e propongono combinazioni di interruzioni che un tester potrebbe non aver elencato, ad esempio una chiamata che arriva esattamente durante l'aggiornamento del token. L'apprendimento automatico raggruppa anche i log degli arresti anomali in produzione per mostrare quali interruzioni causano effettivamente problemi agli utenti reali per prime.

Copilot genera script di base efficaci: mette l'app in background, attiva/disattiva la connettività, attende e infine ripristina lo schermo. La decisione su quando interrompere l'esecuzione e quale stato deve persistere spetta al tester, quindi è consigliabile considerare gli script generati come una bozza iniziale da rivedere.

Sì. I due nomi descrivono la stessa attività e vengono usati in modo intercambiabile tra team e strumenti. Scegli una grafia per il tuo piano di test e usala in modo coerente, perché la terminologia mista rende più difficile la ricerca delle suite e più facile la creazione di casi duplicati.

Utilizzateli entrambi. Gli emulatori sono ideali per una connettività rapida e ripetibile e per i casi di batteria in una pipeline. I dispositivi reali sono necessari per chiamate reali, gestori di batteria proprietari e gestione della memoria insufficiente, ovvero le condizioni che mettono in evidenza i difetti di ripristino più difficili da individuare.

Arresti anomali alla ripresa, schermate vuote o errate dopo il ritorno, perdita di dati inseriti nei moduli, pagamenti duplicati da una richiesta ripetuta, sessioni interrotte che richiedono un nuovo accesso, riproduzione multimediale bloccata e perdite di memoria o batteria che si manifestano solo dopo che l'applicazione viene ripetutamente eseguita in background.

Entrambe le cose. Le interruzioni di rete, batteria e cambio di app vengono gestite in modo affidabile tramite script e sono incluse nel test di regressione. Le chiamate in arrivo, le sveglie e le notifiche di alimentazione specifiche del fornitore sono solitamente più veloci da testare manualmente su un telefono reale, quindi la maggior parte dei team ne tiene un piccolo set a disposizione.

È opportuno iniziare non appena un percorso critico è completo in termini di funzionalità, piuttosto che durante la settimana di collaudo finale. La risoluzione dei difetti spesso richiede modifiche al ciclo di vita o alla gestione dello stato, e queste sono costose da implementare a posteriori una volta che la release candidate è stata bloccata.