Interrupt-Tests in mobilen Anwendungen

⚡ Intelligente Zusammenfassung

Interrupt-Tests prüfen, wie sich eine mobile Anwendung verhält, wenn ein Anruf, ein Alarm, eine Benachrichtigung oder ein Netzwerkabbruch die Verbindung unterbricht, und ob die Anwendung nach Beendigung der Unterbrechung wieder in ihren vorherigen Zustand zurückkehrt.

  • 🔘 Umfang: Die Technik gehört zum Bereich Mobile Application Testing, ist aber auch auf Web- und Standalone-Software anwendbar.
  • ☑️ Unterbrechungsquellen: Eingehende Anrufe, SMS, Alarme, niedriger Akkustand, Ladevorgänge, App-Updates und Netzwerkänderungen decken die meisten realen Szenarien ab.
  • ✅ Vier erwartete Ergebnisse: Im Hintergrund ausführen, eine Warnung anzeigen, eine Handlungsaufforderung auslösen oder keine Auswirkungen haben – jede Anwendung definiert, welche Option gilt.
  • 🧪 Versuchsaufbau: Interrupt-Testing ist eine Teilmenge des Funktionstests, daher gelten die gleichen Frameworks, Testfälle und Ausführungsprozesse.
  • ️ Simulation: Der Emulator bietet erweiterte Steuerelemente, Geräteeinstellungen und Realgeräte-Clouds, die Anrufe, Warnmeldungen und Verbindungsabbrüche auf Abruf nachbilden.
  • 📊 Kein Wiederherstellungstest: Wiederherstellungstests validieren die Wiederherstellung nach einem Ausfall, während eine Unterbrechung nur ein vorübergehender Fehler ist.traction, kein Fehler.

Interrupt-Test in einer mobilen Anwendung, bei dem ein eingehender Anruf den aktiven App-Bildschirm übernimmt

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.

Arten von Unterbrechungen in einer mobilen Anwendung, einschließlich Anrufen, SMS, Alarmen, Akku- und Netzwerkereignissen

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.

Unterbrechung Testszenario Erwartetes Ergebnis
Eingehender Anruf Einen Anruf auslösen, während ein Formular halb ausgefüllt ist, diesen annehmen und anschließend beenden. Die Anwendung wechselt in den Hintergrund und wird anschließend auf demselben Bildschirm mit den eingegebenen Daten fortgesetzt.
Eingehende SMS oder Push-Benachrichtigung Senden Sie eine Nachricht, während ein Video aufgenommen oder hochgeladen wird, und ignorieren Sie das Banner. Das Banner erscheint und verschwindet; der Anwendungsstatus bleibt unverändert.
Alarme Lassen Sie einen geplanten Alarm während einer aktiven Sitzung auslösen und ignorieren Sie ihn. Der Alarm erfordert zunächst eine Handlungsaufforderung, anschließend wird die Anwendung an der Stelle fortgesetzt, an der sie unterbrochen wurde.
Batteriewechselanzeige Entleere das Gerät während einer Transaktion bis zum Warnschwellenwert. Es wird eine Warnung angezeigt, die Transaktion wird nicht abgebrochen, und der Energiesparmodus führt nicht zu einem Bildschirmabsturz.
Verlust der Netzwerkverbindung Die Verbindung während der Anfrage unterbrechen und anschließend wiederherstellen. Es wird eine eindeutige Meldung angezeigt, es tritt kein Absturz auf, und die Anfrage wird bei der Wiederherstellung entweder erfolgreich abgeschlossen oder schlägt sicher fehl.
Laden im angeschlossenen oder nicht angeschlossenen Zustand Schließen Sie das Ladegerät während einer aktiven Sitzung an und trennen Sie es. Keine Auswirkungen – die Anwendung läuft ohne sichtbare Veränderung weiter.
Erinnerung an Anwendungsaktualisierung Zeigen Sie eine Aktualisierungsaufforderung an, während die Anwendung verwendet wird. Der Nutzer kann abbrechen oder akzeptieren, und der zugrundeliegende Bildschirm bleibt in beiden Fällen erhalten.

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

Die Szenarien sind dieselben, die Ergebnisse jedoch nicht. Die beiden Plattformen handhaben Hintergrund-Apps und Speicherbereinigung unterschiedlich, und Android Hersteller-Skins fügen ihre eigenen Batterieregeln hinzu, sodass derselbe Test bei einer Gerätefamilie erfolgreich sein und bei einer anderen fehlschlagen kann.

KI-Modelle analysieren Nutzerberichte und Absturzprotokolle und schlagen Unterbrechungskombinationen vor, die ein Tester möglicherweise nicht berücksichtigt hat – beispielsweise einen Anruf, der genau zum Zeitpunkt der Token-Aktualisierung eingeht. Maschinelles Lernen gruppiert zudem Absturzprotokolle aus der Produktion, um zu zeigen, welche Unterbrechungen tatsächlich zuerst zu Problemen bei echten Nutzern führen.

Copilot erstellt die Standardversionen gut – die App wird in den Hintergrund verschoben, die Verbindung umgeschaltet, gewartet und anschließend der wiederhergestellte Bildschirm angezeigt. Die Entscheidung, wann der Vorgang unterbrochen werden soll und welcher Zustand erhalten bleiben muss, obliegt dem Tester. Daher sollten die generierten Skripte als Ausgangspunkt für die Überprüfung dienen.

Ja. Beide Bezeichnungen beschreiben dieselbe Aktivität und werden team- und toolübergreifend synonym verwendet. Wählen Sie für Ihren Testplan eine Schreibweise und verwenden Sie diese konsequent, da uneinheitliche Terminologie die Suche nach Testsuiten erschwert und die Erstellung doppelter Fälle erleichtert.

Nutzen Sie beides. Emulatoren eignen sich ideal für schnelle, wiederholbare Verbindungen und den Akkuverbrauch in einer Pipeline. Echte Geräte werden für authentische Anrufe, herstellerspezifische Akkuverwaltung und das Entfernen von Verbindungen bei geringem Speicher benötigt – genau die Bedingungen, unter denen die schwerwiegendsten Wiederaufnahmefehler aufgedeckt werden.

Abstürze beim Fortsetzen, leere oder falsche Bildschirme nach der Rückkehr, verlorene Formulareingaben, doppelte Zahlungen bei wiederholten Anfragen, unterbrochene Sitzungen, die eine erneute Anmeldung erfordern, blockierte Medienwiedergabe und Speicher- oder Batterielecks, die erst auftreten, nachdem die Anwendung wiederholt in den Hintergrund verschoben wurde.

Beides trifft zu. Netzwerk-, Akku- und App-Wechselunterbrechungen lassen sich zuverlässig skripten und gehören in den Regressionstest. Eingehende Anrufe, Alarme und herstellerspezifische Energiesparhinweise lassen sich in der Regel schneller manuell auf einem echten Endgerät testen, daher halten die meisten Teams ein kleines manuelles Testset bereit.

Beginnen Sie mit der Fehlerbehebung, sobald eine kritische Funktion vollständig implementiert ist, und nicht erst in der letzten Härtungsphase. Wiederaufnahmefehler erfordern oft Änderungen am Lebenszyklus oder Zustandsmanagement, deren nachträgliche Anpassung nach dem Einfrieren des Release Candidates kostspielig ist.

Fassen Sie diesen Beitrag mit folgenden Worten zusammen: