Zustandsübergangstest: Lebenszyklen systematisch testen

Was ist der Zustandsübergangstest?

Der Zustandsübergangstest ist ein verhaltensbasiertes Black-Box-Testverfahren, das Testfälle aus einem Zustandsmodell ableitet: aus der endlichen Menge der möglichen Zustände eines Systems, den Ereignissen, die Zustandswechsel auslösen, und den erlaubten Übergängen dazwischen.

Dahinter steht eine einfache Beobachtung: Viele Systeme haben ein Gedächtnis. Dieselbe Aktion führt je nach Vorgeschichte zu unterschiedlichen Ergebnissen. Ein “Update starten” bedeutet etwas anderes, wenn das Gerät gerade im Normalbetrieb läuft, als wenn bereits eine Installation im Gang ist. Wer nur Eingaben testet und die Vorgeschichte ignoriert, testet an solchen Systemen vorbei.

Gearbeitet wird mit dem Zustandsübergangsdiagramm oder der Zustandsübergangstabelle. Beide transportieren denselben Inhalt; die Tabelle führt pro Zeile einen erlaubten Übergang auf, mit aktuellem Zustand, auslösendem Ereignis, Folgezustand und optionaler Aktion. Daraus entstehen Testpfade, die einzelne Übergänge, Übergangsfolgen oder komplette Wege durch das System prüfen. Der Zustandsübergangstest gehört zum Standardrepertoire der Testentwurfsverfahren.

Wann ist das Verfahren geeignet?

Überall dort, wo Objekte oder Prozesse einen klaren Lebenszyklus durchlaufen: Bestell- und Reklamationsprozesse, Authentifizierungsabläufe (angemeldet, gesperrt, freigeschaltet), Firmware- und Gerätelebenszyklen, Genehmigungs-Workflows, Vertragsphasen.

Ein praktischer Nebeneffekt: Enthalten die Anforderungen bereits ein Zustandsmodell, dient es direkt als Testbasis. Fehlt es, entsteht es während der Testanalyse, und dabei kommen regelmäßig Lücken in den Anforderungen ans Licht, lange bevor der erste Test läuft. Die Tabellenform erzwingt nämlich Vollständigkeit: Für jeden Zustand muss beantwortet werden, welche Ereignisse vorkommen können und was bei nicht spezifizierten Ereignissen passieren soll. Im Diagramm übersieht man einen fehlenden Pfeil leicht, in der Tabelle fällt die leere Zelle auf.

Weniger geeignet ist das Verfahren für sehr große oder hochgradig parallele Zustandsräume. Laufen mehrere unabhängige Zustände gleichzeitig, etwa der Gerätezustand und der Zustand der Cloud-Verbindung, wächst der kombinierte Raum als Produkt der Einzelzustände. Dann hilft Hierarchisierung oder die Trennung in mehrere kleinere Maschinen. Kontinuierliche Größen wie Sensorwerte müssen vorab in Klassen abstrahiert werden.

Vorgehen in fünf Schritten

1. Zustände identifizieren. Welche unterscheidbaren Zustände kann das Objekt einnehmen?
2. Ereignisse und Übergänge identifizieren. Welche Ereignisse lösen Zustandswechsel aus, welche Übergänge sind erlaubt? Ergebnis ist die Zustandsübergangstabelle.
3. Überdeckungsmaß wählen. Üblich sind Zustandsüberdeckung (jeder Zustand einmal besucht) und die N-Switch-Maße: 0-Switch testet jeden Übergang einmal, 1-Switch jede Abfolge von zwei Übergängen.
4. Testpfade ableiten. Pfade durch das Modell bilden, die die gewählten Überdeckungselemente abdecken.
5. Testfälle ausformulieren. Pro Pfad ein Testfall mit Anfangszustand, Ereignissequenz und erwarteten Zwischen- und Endzuständen.

Ein kompaktes Beispiel

Das Firmware-Update eines Routers durchläuft fünf Zustände: Betrieb, Download, Installation, Neustart, Rollback. Sieben Übergänge sind spezifiziert:

Für 0-Switch-Überdeckung reichen drei Pfade:

Angenommen, TF 3 fällt durch: Das Rollback stellt die alte Version korrekt wieder her, aber die Störungsmeldung an das Monitoring bleibt aus. Der Zustandswechsel stimmt, die Aktion auf dem Übergang nicht. Ohne die explizite Aktionsspalte in der Tabelle wäre dieser halbe Fehler leicht als “funktioniert doch” durchgerutscht.

Die Überdeckungsrechnung zu diesem Modell (5 Zustände, 7 Übergänge, 9 gültige Übergangspaare):

Die drei fehlenden Übergangspaare betreffen alle denselben Fall: den erneuten Update-Start, nachdem das Gerät nach Abbruch, Rollback oder erfolgreichem Update in den Betrieb zurückgekehrt ist. Ein einziger langer Pfad, der mehrere Update-Versuche hintereinander fährt, schließt die Lücke. Genau solche Wiederholungen sind im Feld Alltag und im Testlabor chronisch untergetestet; die Rechnung macht das sichtbar, das Bauchgefühl nicht.

Überdeckung und Erfolgskriterien

Vier Maße tragen die Praxis. Die Zustandsüberdeckung verlangt nur, dass jeder Zustand einmal aktiv war; sie ist das schwächste Kriterium. Die 0-Switch-Überdeckung verlangt jeden Übergang mindestens einmal, die 1-Switch-Überdeckung jedes Paar aufeinanderfolgender Übergänge. Für Modelle mit Schleifen kommt die Rundreiseüberdeckung dazu: Jede minimale Sequenz, die in einem Zustand beginnt und in demselben endet, wird einmal durchlaufen. Schleifen sind in Lebenszyklen typische Fehlerquellen, deshalb zahlt sich dieses Kriterium überproportional aus.

Die Wahl folgt der Risikolage. Für risikoarme Abläufe reicht 0-Switch. Wo Folgefehler wehtun, etwa bei allem, was Geld bewegt oder Geräte im Feld betrifft, lohnt 1-Switch, weil sich viele Fehler erst in der Kombination zweier Übergänge zeigen. Stufen oberhalb von 2-Switch bleiben sicherheitskritischen Systemen vorbehalten; ihr Aufwand wächst exponentiell.

Stärken und Grenzen

Die Stärke des Verfahrens: Es macht Reihenfolge- und Statusabhängigkeiten systematisch sichtbar, deckt Übergangsfehler und nicht spezifizierte Ereignisse auf und liefert messbare Überdeckungskriterien, mit denen sich der Testumfang begründen lässt. Das Modell taugt nebenbei als Kommunikationsgrundlage mit Stakeholdern.

Die Grenzen: Das System muss tatsächlich endlich viele, klar unterscheidbare Zustände haben. Sehr große und parallele Zustandsräume sprengen das Modell; kontinuierliche Werte brauchen Vorarbeit. Und wie jedes modellbasierte Verfahren prüft der Zustandsübergangstest nur, was im Modell steht. Ein unvollständiges Modell erzeugt vollständig wirkende Tests, das ist seine tückischste Schwäche.

Ein Praxisrat noch: mit der Tabelle anfangen, nicht mit dem Diagramm. Die Tabelle ist textlich, versionierbar, leicht zu reviewen und werkzeuggestützt weiterverarbeitbar. Das hübsche Diagramm entsteht daraus als Visualisierung, nicht umgekehrt.

Verwandte Verfahren

Der CRUD-Test prüft Berechtigungen auf Datenoperationen, aber ohne Reihenfolgebezug; er ergänzt den Zustandsübergangstest bei datengetriebenen Systemen. Der szenariobasierte Test verfolgt Anwendungspfade ohne formales Zustandsmodell und passt, wenn die Anwendersicht wichtiger ist als die formale Überdeckung. Geht es um Regeln statt um Abläufe, ist der Entscheidungstabellentest das passende Werkzeug. Einen Überblick über alle elf Verfahren und ihre Auswahl gibt die Seite Testentwurfsverfahren.