Interrupt-Tests in mobilen Anwendungen

Was ist Interrupttest?

Interrupt-Tests Der Test von mobilen Anwendungen ist ein Teilgebiet, das sich damit befasst, wie eine Anwendung auf eine Unterbrechung reagiert und ihren vorherigen Zustand wiederherstellt. Die Unterbrechung kommt von außerhalb der Anwendung – vom Betriebssystem, der Hardware oder einer anderen App – und der Test überprüft, ob beim Wiedereintritt der Kontrolle keine Daten, Bildschirmzustände oder laufende Transaktionen verloren gehen.

Interrupt-Testing ist für alle Anwendungstypen anwendbar – Web-, Mobil-, Standalone-Anwendungen usw. Die Vielfalt an Geräten, Netzwerken und Konfigurationen macht es umso wichtiger für … Mobile mehr als für die anderen.

Warum brauchen Sie Interrupt-Tests?

Was passiert fast immer in Meetings? Man wird unterbrochen, richtig? Manche reagieren darauf völlig unbeeindruckt, andere brauchen einen Moment, um sich zu fangen, und wieder andere verlieren komplett den Faden. Kurz gesagt: Interrupt-Testing versucht herauszufinden, welches Verhalten Ihre Anwendung in solchen Situationen zeigt.

Vergessen wir für einen Moment die Formulierung und betrachten wir eine andere Situation aus dem Alltag. Angenommen, Sie besitzen eine Taschenlampe und schalten sie ein. Die Batterie ist leer, was den aktuellen Betriebszustand unterbricht. Tauschen Sie die Batterien aus und schalten Sie die Taschenlampe wieder ein. Sie sollte nun wieder normal funktionieren. Dies ist der Anwendungsfall. Eine Testmethode, die sich darauf konzentriert, ob dies tatsächlich der Fall ist oder nicht, nennt sich Interrupt-Test.

Der geschäftliche Nutzen ist eindeutig. Eine Unterbrechung tritt im ungünstigsten Moment auf – mitten in einer Zahlung, einem Upload oder einem Formular – und ein Nutzer, der seine Arbeit verliert, versucht es selten erneut. Abstürze beim Fortsetzen, leere Bildschirme, doppelte Transaktionen und verlorene Formulareingaben sind allesamt Fehler, die nur durch eine Unterbrechung aufgedeckt werden. Deshalb bleiben sie auch bei einem reibungslosen Ablauf ohne Unterbrechungen bestehen.

Art der Unterbrechungen in der mobilen Anwendung

Unterbrechungen lassen sich in eine Handvoll bekannter Gruppen einteilen, die in der folgenden Abbildung zusammengefasst sind.

Wir alle kennen die üblichen Unterbrechungen, die normalerweise auftreten. Hier sind einige davon:

• Batterie schwach
• Akku voll – während des Ladevorgangs
• Eingehender Anruf
• Eingehende SMS
• Eingehende Benachrichtigung von einer anderen mobilen Anwendung
• Zum Aufladen eingesteckt
• Vom Laden getrennt
• Gerät ausgeschaltet
• Erinnerungen an Anwendungsaktualisierungen
• Alarme
• Verlust der Netzwerkverbindung
• Wiederherstellung der Netzwerkverbindung

Diese Liste ist nicht vollständig, umfasst aber die häufigsten Szenarien. Eine praktische Möglichkeit zur Organisation bietet die Kategorisierung nach Ursprung: geräteabhängige Ereignisse wie Akku und Ladevorgang, benutzerinitiierte Ereignisse wie das Annehmen eines Anrufs oder das Wechseln von Apps und externe Ereignisse wie Signalverlust in einem Aufzug oder Tunnel.

Lösung im Falle einer Unterbrechung

Das zu erwartende Verhalten im Falle dieser Unterbrechungen ist eines der folgenden vier:

1. Im Hintergrund laufen: Die Unterbrechung tritt in den Hintergrund, während die Anwendung vorübergehend pausiert. Nach Beendigung der Unterbrechung übernimmt sie wieder die Kontrolle. Ein Beispiel hierfür ist ein Telefon- oder FaceTime-Anruf, den Sie annehmen, während Sie ein E-Book in iBooks (oder einer ähnlichen Anwendung) lesen. Sobald Sie den Anruf annehmen, wartet iBooks, bis das Gespräch beendet ist, und setzt die Nutzung anschließend fort.
2. Benachrichtigung anzeigen: Die Benachrichtigung verschwindet und Sie arbeiten wie gewohnt weiter. Im Header erscheint die Meldung „SMS empfangen“. Der Nutzer ignoriert dies und arbeitet normal mit der Anwendung. Auch andere Benachrichtigungen von mobilen Apps, wie beispielsweise eine neue Freundschaftsanfrage auf Facebook oder eine WhatsApp-Nachricht, fallen in diese Kategorie. Liest der Nutzer die Nachricht, verhält sich die Anwendung wie unter Punkt 1 beschrieben. Ignoriert er die Benachrichtigung, bleibt der Zustand der Anwendung unverändert.
3. Aufruf zum Handeln: Alarme müssen deaktiviert oder auf Schlummern gestellt werden, bevor Sie weiterarbeiten können. Dasselbe gilt für App-Update-Benachrichtigungen. Sie müssen die Änderungen entweder ablehnen oder akzeptieren, bevor Sie fortfahren können. Ein weiteres Beispiel ist die Warnung bei niedrigem Akkustand: Sie können wie gewohnt fortfahren oder, falls vom Gerät unterstützt, in den Energiesparmodus wechseln.
4. Keine Auswirkung: Ein Beispiel hierfür ist, wenn eine Netzwerkverbindung hergestellt wird und sich Ihr Gerät damit verbindet. Auch beim Anschließen Ihres Geräts zum Laden ist keine Benachrichtigung oder Handlungsaufforderung erforderlich. Es lädt wahrscheinlich automatisch, während Sie Ihre Anwendung weiter nutzen.

Je nachdem, welche Unterbrechung Sie testen, sollten Sie das Verhalten verstehen und prüfen, ob Ihre Anwendung die Anforderungen erfüllt. Beachten Sie außerdem, dass das oben beschriebene Verhalten nicht für alle Anwendungen und Geräte gleich sein muss. Informieren Sie sich daher unbedingt über die spezifischen Details Ihrer mobilen App.

Interrupt-Testing-Testfälle mit erwarteten Ergebnissen

Sobald die erwartete Lösung vereinbart ist, wird jede Unterbrechung zu einem gewöhnlichen Testfall mit einem Auslöser, einer Aktion und einem überprüfbaren Ergebnis. Die folgende Tabelle zeigt, wie die vier oben genannten Lösungen in konkrete Szenarien umgesetzt werden.

Verwenden Sie für jeden kritischen Bildschirm und jede Unterbrechung eine eigene Zeile, anstatt für jede Unterbrechung in der gesamten Anwendung eine eigene Zeile zu verwenden. Der Zahlungsbildschirm, der Anmeldebildschirm und ein ausführliches Formular weisen jeweils unterschiedliche Fehler auf, und ein einzelner generischer Fall verschleiert diese Unterschiede.

Nachdem wir nun verstanden haben, was Interrupt-Tests sind und was bei der Durchführung validiert werden muss, ist es an der Zeit, darüber zu sprechen, wie man es durchführt.

So führen Sie Interrupt-Tests durch

Schauen Sie sich diese Aussage an: iBooks muss im Hintergrund laufen, wenn der Benutzer einen eingehenden Anruf erhält.

Würden Sie das nicht als funktionale Anforderung der iBooks-App bezeichnen? Ich schon.

Interrupt-Tests sind also eine Teilmenge von Funktionsprüfung Für eine mobile Anwendung. Um Unterbrechungstests durchzuführen, verwenden Sie dieselben Testframeworks und -tools wie für mobile Anwendungen. Es ist Aufgabe der Tester, diese Szenarien zu konzipieren. Anschließend entwerfen Sie die Testfälle und führen sie genauso aus wie jeden anderen Test.

In der Praxis ist die Sequenz kurz und wiederholbar:

1. Listen Sie die wichtigsten Benutzerabläufe auf – Anmeldung, Zahlung, Upload, Langformulare, Medienwiedergabe.
2. Ordnen Sie jede mögliche Unterbrechung aus der obigen Liste jeder einzelnen Reise zu.
3. Die erwartete Lösung für jedes Paar sollte mit dem Produktinhaber vereinbart werden, da es keinen universellen Standardwert gibt.
4. Die Unterbrechung sollte im risikoreichsten Moment erfolgen, nicht in einem ruhigen Augenblick, und anschließend sollte die Ausführung fortgesetzt werden.
5. Überprüfen Sie nach der Wiederaufnahme den Zustand, die Daten, die Sitzung und den Speicher, nicht nur, ob die Anwendung noch geöffnet ist.

Weitere Informationen zum übergeordneten Fachgebiet finden Sie unter Mobiles Testen Tutorial und die Beispielfälle in Testen mobiler Apps.

Werkzeuge und Techniken zur Simulation von Unterbrechungen

Die oben genannten Szenarien müssen bedarfsorientiert erstellt werden, anstatt darauf zu warten, und jede Plattform bietet eine Möglichkeit dazu.

• Android Erweiterte Emulatorsteuerung: Das Emulator-Seitenpanel simuliert einen eingehenden Anruf, eine SMS, den Akkustand und den Ladezustand sowie die Mobilfunksignalstärke, sodass die meisten Unterbrechungslisten ohne ein zweites Mobiltelefon abgearbeitet werden können.
• iOS-Simulator und Xcode: Konnektivitäts- und Hardwarezustände können sowohl vom Simulator als auch von den Geräteeinstellungen aus variiert werden, während ein gekoppeltes physisches Gerät die Anrufszenarien abdeckt, die ein Simulator nicht erzeugen kann.
• Ein zweites physisches Gerät: Das Anrufen oder Senden einer Nachricht an das zu testende Gerät von einem anderen Mobiltelefon aus ist nach wie vor die zuverlässigste Methode, um eine reale Unterbrechung zu simulieren, insbesondere in zeitkritischen Fällen.
• Geräteeinstellungen: Flugmodus, WLAN-Umschaltung, Nicht stören, Energiesparmodus und geplante Alarme decken Verbindungs- und Stromausfälle auf realer Hardware ab.
• Automatisierungs-Frameworks: Derselbe Automatisierungs-Stack, der für den Rest Ihrer Funktionssuite verwendet wird, kann die Anwendung vor und nach der Unterbrechung steuern, sodass die Wiederaufnahmeprüfung durchgeführt und nicht nur visuell überprüft wird.
• Echtzeit-Geräte-Clouds: Eine gehostete Gerätefarm erweitert die Abdeckung über verschiedene Hersteller und Betriebssystemversionen hinweg, was wichtig ist, da die Unterbrechungsbehandlung einer der Bereiche ist, in denen die Anpassungen der Hersteller am stärksten voneinander abweichen.

Unabhängig vom Mechanismus sollte der genaue Zeitpunkt der Unterbrechung im Testfall protokolliert werden. „Unterbrechung während des Uploads“ und „Unterbrechung nach dem Upload“ sind unterschiedliche Tests mit unterschiedlichen Fehlermodi.

Best Practices für Interrupt-Tests

Ein paar Gewohnheiten unterscheiden eine sinnvolle Interrupt-Suite von einer bloßen Pflichtübung.

• Unterbrechen im ungünstigsten Moment: Target in dem Moment, in dem eine Transaktion abgeschlossen oder eine Datei geschrieben wird, denn dann ist der Zustand am fragilsten.
• Testen Sie den Lebenslauf, nicht die Unterbrechung: Der Fehler tritt fast immer nach der Rückkehr der Steuerung auf, daher gehören die Assertions auf den wiederhergestellten Bildschirm.
• Beide Richtungen einer Netzwerkänderung abdecken: Der Verlust und die Wiederherstellung einer Verbindung sind zwei verschiedene Dinge, wobei der zweite Fall häufiger übersprungen wird.
• Die Dauer variieren: Ein zweisekündiger Alarm und ein zehnminütiger Anruf versetzen die Anwendung in verschiedene Lebenszyklusphasen, einschließlich der Entfernung aus dem Speicher.
• Verteilt auf verschiedene Betriebssystemversionen und leistungsschwache Hardware: Die Hintergrundlöschung ist bei leistungsschwachen Geräten weitaus aggressiver, wodurch Mängel sichtbar werden, die ein Flaggschiff-Handy verbirgt.
• Automatisieren Sie die wiederholbaren Aufgaben: Verbindungs- und Batterieunterbrechungen werden sauber automatisiert, wodurch der manuelle Aufwand bei Anruf- und Alarmszenarien reduziert wird.
• Beachten Sie sowohl die Ressourcennutzung als auch den Status: Eine Unterbrechung, die zu Speicherlecks oder einer schnellen Entladung des Akkus beim Fortsetzen führt, ist ein Fehler, selbst wenn der Bildschirm korrekt aussieht, was diese Arbeit mit … in Verbindung bringt. Leistungstests für mobile Apps.

Ist Interrupt-Testen nicht dasselbe wie Wiederherstellungstests?

Nein ist es nicht. Wiederherstellungstests Die Wiederherstellung nach einem Ausfall wird bestätigt. Eine Unterbrechung ist nicht zwangsläufig ein Ausfall – sie ist lediglich eine Störung.traction.

Es ist wie der Unterschied zwischen Komma und Punkt im Englischen. Die Unterscheidung ist rein technischer Natur, aber das Prinzip ist klar. Wiederherstellungstests prüfen, ob die Anwendung nach einem Fehler wieder funktioniert; Unterbrechungstests prüfen, ob überhaupt Fehler auftreten, wenn ein anderer Prozess in den Vordergrund tritt.

Das ist alles, was man wissen muss, um mit Interrupt-Testing zu beginnen – einem wichtigen und intuitiven Zweig des Mobile Application Testing.

Häufig gestellte Fragen