7.4 State-based Test Design Nils Foken. Steuerungsfehler fehlende / falsche Transition fehlendes / falsches Ereignis fehlende / falsche Aktion zusätzlicher.

Präsentation zum Thema: "7.4 State-based Test Design Nils Foken. Steuerungsfehler fehlende / falsche Transition fehlendes / falsches Ereignis fehlende / falsche Aktion zusätzlicher."—  Präsentation transkript:

1 7.4 State-based Test Design Nils Foken

2 Steuerungsfehler fehlende / falsche Transition fehlendes / falsches Ereignis fehlende / falsche Aktion zusätzlicher / falscher oder fehlender Zustand Schleichpfad Falltür

3 Steuerungsfehler durch Vererbungen fehlende / falsche Methode der Unterklasse Überlagern von Sichtbarkeiten von Variablen falsche Umleitung einer Transition fehlerhafte Schleifenbedingungen

4 Entwickeln eines Testmodels das gewünschte Programmverhalten wird repräsentiert Korrektheit Vollständigkeit Anforderungen:

5 Struktur 1.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)

6 7.nur ein Ereignis wird pro Zustand gleichzeitig akzeptiert 8.alle Transitionen führen zu definierten Zuständen 9.alle Exceptions werden behandelt

7 Zustandsnamen 1.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 8.keine Namen die auf mit dem Zustand verbundene Aktionen verweisen 9.keine Namen die Nutzerinteraktionen beschreiben

9 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

10 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

11 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

12 Die N+ Teststrategie 1.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

13 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.

14 round-trip path 1.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

15 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

16 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:

17 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

18 Testen von Zustandsübergängen Methoden die den aktuellen Zustand zurückliefern Wiederholung von Testdurchläufen state revealing signatures

19 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*/...

20 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

21 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)

22 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)

23 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.

24 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

25 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

26 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)

27 Testen mit Signaturen der Länge M 1.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