7.4 State-based Test Design

Nils Foken

Steuerungsfehler

• fehlende / falsche Transition

• fehlendes / falsches Ereignis

• fehlende / falsche Aktion

• zusätzlicher / falscher oder fehlender Zustand

• Schleichpfad

• Falltür

Steuerungsfehler durch Vererbungen

• fehlende / falsche Methode der Unterklasse

• Überlagern von Sichtbarkeiten von Variablen

• falsche Umleitung einer Transition

• fehlerhafte Schleifenbedingungen

Entwickeln eines Testmodels

• das gewünschte Programmverhalten wird repräsentiert

• Korrektheit

• Vollständigkeit

Anforderungen:

Struktur1. ein Startzustand mit zugehöriger α-Transition

2. mindestens ein Endzustand (keine wegführenden Transitionen)

3. keine äquivalenten Zustände

4. alle Zustände erreichbar / Endzustand von jedem anderen Zustand aus erreichbar

5. jedes definierte Ereignis ist in mindestens einer Transition vorhanden

6. alle Zustände haben hin- und wegführende Transitionen (Ausnahme: Start-, Endzustand)

7. nur ein Ereignis wird pro Zustand gleichzeitig akzeptiert

8. alle Transitionen führen zu definierten Zuständen

9. alle Exceptions werden behandelt

Zustandsnamen1. Zustandsnamen sollten die Aufgabe des Zustands

beschreiben

2. Zustände die als Platzhalter dienen möglichst entfernen

3. Namen wie „Warten auf X“ nicht verwenden

4. Mealy und Moore Zustände nicht in einem Model gemeinsam verwenden

5. für Mealy Zustände passive Namen verwenden

6. für Moore Zustände aktive Namen verwenden

7. keine irrelevanten Informationen im Namen (z.B. Variablenintervalle)

8. keine Namen die auf mit dem Zustand verbundene Aktionen verweisen

9. keine Namen die Nutzerinteraktionen beschreiben

Bedingte Transitionen

1. für jeden erreichbaren Wert einer Bedingung müssen Transitionen vorliegen

2. jeder erreichbare Wert schließt alle anderen aus

3. eine Bedingung mit mehr als 2 Variablen sollte mit einer Wahrheitstabelle überprüfte werden

Vererbungen

1. eine Unterklasse darf keine in der Oberklasse definierten Zustände entfernen

2. keine Bedingungen der Oberklasse dürfen abgeschwächt oder umgangen werden

3. alle von der Oberklasse geerbten Aktionen müssen auch in der Unterklasse ausführbar sein

Fehlerbehandlung

1. alle möglichen Fehler müssen behandelt werden

2. bei einem unbekannten Fehler dürfen keine unerwarteten Nebeneffekte auftreten

3. jeder Zustand muß nach einer vorgegebenen Zeit beendet sein

4. nach jedem Fehler muß das System an einer definierten Stelle weiter laufen

Die N+ Teststrategie1. integriert Elemente aus verschiedenen Teststrategien

2. nutzt das flattened state model

3. alle impliziten Transitionen werden auf Schleichpfade überprüft

4. es müssen dazu Methoden vorhanden sein, die den resultierenden Zustand einer Transition liefern

ein N+ Test deckt alle Steuerungsfehler, Schleichpfade, fehlerhaften Unter-/ Oberklassen Interaktionen und viele undefinierte Zustände auf

Fehlerhafte α und ω-Transitionen werden erkannt

Falltüren können sich andeuten

Vorgehensweise:1. ein FREE Model der zu testenden Implementierung erstellen

- mit den Checklisten prüfen

- das Zustandsdiagramm erweitern

- die Response Matrix dazu erstellen

2. den round-trip path Testfall durchlaufen

3. den Schleichpfad Testfall durchlaufen

Jedes andere Model ist auch möglich, solange es die selben Informationen wie ein FREE Model zur Verfügung stellt.

round-trip path1. Startzustand wird die Wurzel des Baums (bei mehreren

Konstruktoern der α Zustand

2. jede wegführende Transition erzeugt mindestens eine neue Kante (Ereignis) mit einem neuen Knoten (resultierender Zustand

- unbedingte Transitionen erzeugen einen neuen Zweig

- einfache Boolsche Ausdrücke oder Ausdrücke die nur logische UND enthalten, erzeugen einen neuen Zweig

- Ausdrücke mit mindestens einem logischem ODER erzeugen für jede Variablenkombination, die den Ausdruck auf WAHR abbildet, einen neuen Zweig

3. für jede Kante und jeden Knoten die aus 2. resultieren:

- die Kante wird mit der zugehörigen Transition, Bedingung und Aktion markiert

- ist der neue Knoten (=Zustand) schon im Graphen vorhanden oder ein Endzustand, wird er mit *

markiert

4. Wiederholen von 2. und 3. bis alle Blattknoten als Endzustand markiert sind

mit diesem Baum kann man danach alle Testfälle durchlaufen

Schleichpfad: Illegale Transitionen und Umgehen von Bedingungen

• Testen von eigentlich nicht vorgesehenen Transitionen

• Testen auf korrekte Meldungen

• Auffinden von fehlerhaften Zustandsübergängen

das Testen auf Schleichpfade kann ausgelassen werden, wenn ein kompletter Automat vorliegt, i.e. wenn alle Ereignis-Zustandspaare vorhanden sind.

Ein Schleichpfad ist überall dort möglich, wo Transitionen nicht explizit angegeben wurden oder Bedingungen als FALSCH ausgewertet wurden. Daher:

Vorgehensweise:• der Test wird aus der Response Matrix herausgearbeitet

• für jede nichtmarkierte Transition in jedem Zustand wird ein Testfall generiert:

1. das zu testende Programm wird in den erforderlichen Zustand versetzt

2. das illegale Ereignis wird erzeugt (meist von Hand)

3. überprüfen, ob die erzeugte Antwort der spezifizierten entspricht

4. überprüfen daß der aktuelle Zustand sich NICHT geändert hat

Testen von Zustandsübergängen

• Methoden die den aktuellen Zustand zurückliefern

• Wiederholung von Testdurchläufen

• state revealing signatures

Methoden die den aktuellen Zustand zurückliefern

bool isGameStarted() {...}

bool isPlayer1Served() {...}

bool isPlayer2Served() {...}

bool isPlayer3Served() {...}

bool isPlayer1Won() {...}

bool isPlayer2Won() {...}

bool isPlayer3Won() {...}

int winner() {/*liefert die Spielernummer die gewinnt*/}

/*Test Setup*/

assert(isGameStarted());

out.p1_start(); /*sendet das Ereignis*/

/*simulieren eines Spielzuges*/

assert(winner() == 1);

/*prüft die Aktion*/

assert(out.isPlayer1Served());

/*prüft den nächsten Zustand*/

...

Wiederholung von Testdurchläufen

• Zustandsübergänge können bei einzelnen Testdurchgängen zufällig korrekt ablaufen

Vergleich der Ergebnisse aus verschiedenen Testdurchgängen kann Fehler aufzeigen

state revealing signatures

• ist eine exakte Methode festzustellen, in welchem Zustand man sich befindet

• eine Sequenz von Ausgaben der vorhergehenden Zustände, die eindeutig einen Zustand identifizieren (Problem: mehrere Startzustände ergeben unterschiedliche Signaturen für ein und denselben Zustand)

Möglichkeiten und Einschränkungen beim Testen

• Stückweises Testen

• Testen aller Transitionen

• Testen aller Transitionssequenzen

• Testen aller round-trip paths

• Testen mit Signaturen der Größe M

• „komplettes Testen“ (aufgrund der Menge der Varianten meist unmöglich)

Stückweises Testen

Testen der verschiedenen Gruppen voneinander getrennt

1. Testen aller Zustände

2. Testen aller Ereignisse

3. Testen aller Aktionen

Da man hier nur die Konsistenz der einzelnen Teile prüft, findet man nur zufällig Fehler die aus der Interaktion von Zuständne, Ereignissen und Aktionen herrühren.

Testen aller Transitionen

• jede Transition und somit die mit ihr verbundenen Zustände, Ereignisse und Aktionen wird mindestens einmal getestet

• keine bestimmte Reihenfolge ist vorgeschrieben

es können keine zusätzlichen Transitionen (Schleichpfade) gefunden werden

Testen aller Transitionssequenzen

• alle Sequenzen von Transitionen der Länge n werden getestet

es können Fehler gefunden werden, aber da ein feste Sequenzlänge n vorgegeben ist, nicht alle

Testen aller round-trip paths

• alle Sequenzen von Transitionen die bei einem Zustand beginnen und aufhören werden getestet (bis zu einer Länge n)

alle fehlenden oder falschen Ereignis- Aktionspaare werden gefunden

nicht alle Fehlerhaften Zustände werden aufgedeckt (z.B. wenn man bis zur Länge n=10 testet, und erst die 11. Transition fehlerhaft ist)

Testen mit Signaturen der Länge M1. man erwartet, daß sich das System nach n Transitionen in

einem bestimmten Zustand befindet

2. aus diesen Transitionen generiert man die Signatur des Zustands

3. nach dem Testlauf vergleicht man die erwartete Signatur mit der durch den Testlauf erzeugten

Man erwartet im System M fehlerhafte Zustände man muß mindestens Signaturen der Länge M verwenden um alle erwarteten Fehler zu finden.

hat man mehr als M Fehler im System findet man diese nicht