8

Aufbau und Organisation einer Testsuite

Zum Schreiben von aussagekräftigen und zuverlässigen Tests gehört mehr als nur das Aufnehmen und Wiedergeben von Sequenzen. Sie können eine Testsuite zwar innerhalb kurzer Zeit mit diversen Sequenzen anfüllen, werden aber über kurz oder lang den Überblick verlieren, wenn Sie nicht darauf achten, den Tests eine verständliche Struktur zu geben.

Bevor Sie mit der Aufnahme von Sequenzen beginnen, die Sie anschließend mittels der nachfolgend beschriebenen Elemente zu Testfällen und Testsätzen zusammenstellen, ist es wichtig, dass

• Sie eine gute Vorstellung davon haben, was Sie eigentlich testen wollen.
• Sie die richtigen Dinge testen.
• Ihre Tests zuverlässig und wiederholbar sind.
• Die Tests einfach gewartet werden können.
• Die Ergebnisse Ihrer Tests aussagekräftig sind.

Zur Strukturierung der Tests stellt QF-Test diverse Elemente zur Verfügung. Dies sind zum einen die in Kapitel 5 besprochenen Komponenten und zum anderen die in diesem Kapitel vorgestellten Testsätze, Testfälle, Testschritte und Sequenzen sowie Events, Checks etc.

8.1

Struktur der Testsuite

QF-Test bietet Strukturelemente auf unterschiedlichen Ebenen.

Auf oberster Ebene gibt es die Testsuite, in der die Tests sowie Komponenten abgespeichert werden. Jede Testsuite wird in einer eigenen Datei abgespeichert. Zur erleichterten Handhabung einer größeren Anzahl von Testsuite Dateien können diese in Projekte zusammengefasst werden.

Die Testsuite hat eine feste Struktur, beginnend mit dem Testbereich, der beliebig viele Testfallsatz Knoten enthalten kann, in die wiederum beliebig viele Testfall Knoten oder auch weitere Testfallsätze eingefügt werden können.

Anschließend gibt es einen Bereich für Prozeduren. Als Strukturelement stehen hier Package Knoten zur Verfügung, die beliebig viele Prozedur oder weitere Package Knoten enthalten können.

Der folgende Bereich Extrasequenzen bietet die Möglichkeit, im Rahmen der Testentwicklung beliebige Knoten abzuspeichern und auszutesten.

Der letzte Knoten Fenster und Komponenten ist reserviert für die in den Tests benötigten Komponenten.

Testfälle selbst können wiederum mit Hilfe von Testschritt und Sequenz Knoten gegliedert werden.

Ein weiteres wichtiges Strukturelement sind Vorbereitung und Aufräumen Knoten. Diese dienen der Erstellung von Vor- und Nachbedingungen und können ihrerseits in Abhängigkeit Knoten zusammengefasst werden. Abhängigkeit Knoten bieten darüber hinaus auch Strukturen für die Behandlung von Fehlern und unvorhergesehenen Ereignissen.

Die eigentliche Testausführung geschieht über Events wie zum Beispiel Mausklicks, Checks, Abfragen, Knoten zur Ablaufsteuerung und solche, die Prozesse steuern sowie weitere, in Verschiedenes beschriebene Knoten.

Die Verknüpfung der Tests mit den Testdaten erfolgt über Datentreiber.

8.2

Testfallsatz und Testfall Knoten

2.0+8.2.1

Verwaltung von Tests mit Hilfe von Testfallsatz und Testfall Knoten

Mit den Knoten Testfallsatz und Testfall bietet QF-Test eine einfache, pragmatische Form der Testfallverwaltung direkt innerhalb von QF-Test. Sie sind die wichtigsten Bausteine zur Strukturierung einer Testsuite. Sie bieten die Möglichkeit mittels Abhängigkeit Knoten die Testfälle so zu erstellen, dass sie völlig unabhängig voneinander sind. Notwendige Aufräumarbeiten werden bei entsprechend aufgebauten Abhängigkeiten ebenso automatisch erledigt wie die Vorbereitungen für den aktuellen Test sowie die Fehlerbehandlung.

Auch hinsichtlich der Ergebnisdokumentation kommt den Testfall Knoten eine zentrale Rolle zu. In den Reports ist der Testfall das Strukturelement, auf dem die Fehlerstatistik und auch die Fehlerdokumentation basiert.

8.2.2

Konzepte

Ein Testfall Knoten entspricht konzeptuell einem einzelnen elementaren Testfall und ist damit das entscheidende Bindeglied zwischen Testplanung, Testdurchführung und Testauswertung. Mit Hilfe von Abhängigkeit Knoten können Testfälle so voneinander isoliert werden, dass sie in beliebiger Reihenfolge ausgeführt werden können und auf unvorhergesehenes Verhalten reagiert werden kann. Damit ist es möglich, Teile von funktionalen Tests als Build-Test auszuführen oder etwa einen erneuten Testlauf durchzuführen, bei dem nur die fehlgeschlagenen Testfälle wiederholt werden.

Testfallsätze sind im Prinzip einfach Sammlungen von zusammengehörigen Testfällen, die ähnliche Vor- und Nachbedingungen haben. Testfallsätze können auch verschachtelt werden. Die Struktur der Testfallsatz und Testfall Knoten ist damit ähnlich der Struktur der Prozeduren und Packages Knoten. Der Testsuite Knoten kann als spezielle Form eines Testfallsatzes angesehen werden.

Testsuite, Testfallsatz und Testfall Knoten können von jedem anderen Ort aus mit Hilfe eines Testaufruf Knotens aufgerufen werden. Auf diesem Weg können sehr einfach Tests erstellt und verwaltet werden, die nur eine Untermenge von bestehenden Tests ausführen. Mit Blick auf den Report sollten Testaufruf Knoten nicht innerhalb eines Testfall Knotens ausgeführt werden, weil damit Testfälle verschachtelt würden und vom Report nicht mehr richtig aufgelöst werden könnten. In diesem Fall wird eine Warnung ausgegeben.

8.2.3

Variablen und besondere Attribute

8.2.3.1

Defaultwert

Da Testfallsatz und Testfall Knoten durch Testaufruf Knoten aufgerufen werden können, verfügen sie analog zum Prozedur Knoten über einen Satz von Standardwerten für die Parameter. Diese werden auf dem Sekundärstapel gebunden und können über einen Testaufruf oder den Kommandozeilenparameter -variable <Name>=<Wert> überschrieben werden.

8.2.3.2

Variablendefinitionen

Für einen Testfall kann man zudem Variablen definieren, die auf dem Primärstapel gebunden werden und nicht von außen mittels Testaufruf oder Kommandozeile überschrieben werden können. Primär- und Sekundärstapel sind in Abschnitt 6.2 näher beschrieben.

8.2.3.3

Charakteristische Variablen

In der Liste der Charakteristischen Variablen können die Namen der Variablen angegeben werden, deren Werte zum Beispiel bei datengetriebenem Testen für einen Durchlauf des jeweiligen Testfallsatz oder Testfall Knotens charakteristisch sind. Die Werte dieser Variablen werden in Protokoll und Report angezeigt und helfen somit bei der Analyse von Problemen.

8.2.3.4

Bedingung

Ein weiteres nützliches Attribut ist die Bedingung, vergleichbar mit der Bedingung eines If Knotens. Falls die Bedingung nicht leer ist, wird der Knoten nur ausgeführt, falls der Wert des Ausdrucks wahr ist. Andernfalls wird der Test übersprungen.

8.2.3.5

Fehlschlagen erwartet wenn...

Manchmal wird das Fehlschlagen eines Testfalls für eine bestimmte Zeitdauer erwartet, z. B. wenn dieser erstellt wird, bevor ein Feature oder Bug-Fix im SUT verfügbar ist. Das Attribut Fehlschlagen erwartet wenn... erlaubt es, solche Testfälle zu markieren, so dass diese getrennt gezählt werden und nicht in die prozentuale Fehlerstatistik eingehen.

8.3

Sequenz und Testschritt Knoten

Primäre Bausteine einer Testsuite sind die Sequenz und Testschritt Knoten, die ihre Unterknoten einen nach dem anderen ausführen. Sie dienen der Strukturierung der Unterknoten eines Testfall.

Der Unterschied zwischen Sequenz und Testschritt Knoten besteht darin, dass Testschritt Knoten im Report protokolliert werden, Sequenz Knoten hingegen nicht.

8.4

Vorbereitung und Aufräumen Knoten

Neben den eigentlichen Testschritten enthält jeder Testfall auch Vor- bzw. Nachbedingungen. Die Vorbedingungen werden in Vorbereitung Knoten implementiert, Nachbedingungen in Aufräumen Knoten. In einfachen Fällen werden diese als Unterknoten eines Testfall oder Testfallsatz Knotens eingefügt.

QF-Test bietet allerdings noch eine mächtigere Variante für das Behandeln von Vor- und Nachbedingungen nämlich Abhängigkeit Knoten. Diese ermöglichen nicht nur die Wiederverwendung, sondern bieten auch Möglichkeiten an, um auf unterschiedliche Verhalten während des Testlaufes zu reagieren.

Testfall Knoten mit durchdachten, passenden Vorbereitung und Aufräumen Knoten haben folgende wichtige Eigenschaften:

• Der Testfall kann unabhängig davon, ob vorhergehende Testfälle erfolgreich waren - oder eben nicht - ausgeführt werden.
• Testsuite bzw. der Testfallsatz können an beliebiger Position um weitere Testfall Knoten ergänzt werden, ohne andere Testfälle zu beeinflussen.
• Sie können einen Testfall erweitern oder ihn einfach ausprobieren, ohne vorhergehende Testfälle ausführen zu müssen, um das SUT in den passenden Zustand zu bringen.
• Sie können jede beliebige Teilmenge der Testfall Knoten ausführen, wenn Sie nicht den gesamten Testfallsatz benötigen.

Im einfachsten Fall wird der gleiche Ausgangszustand für alle Testfälle eines Testfallsatzes benötigt. Dies kann mittels der folgenden Struktur realisiert werden:

Hier wird zu Beginn jedes Testfalls die Vorbereitung und nach Ende des Testfalls das Aufräumen ausgeführt. Im Protokoll ist die Ausführungsreihenfolge genau zu erkennen:

Beim Testfallsatz Knoten werden Vorbereitung und Aufräumen Knoten vor und nach jedem im Testfallsatz enthalten Knoten (Testfall und Testfallsatz) ausgeführt. Bei einem Testfall Knoten werden hingegen Vorbereitung und Aufräumen nur einmal ganz zu Beginn und Ende ausgeführt.

Falls die Vorbereitung im obigen Beispiel den Start der Anwendung und die Aufräumen Knoten das Beenden dieser beinhaltet, würde vor jedem Testfall die Anwendung gestartet und danach wieder gestoppt. Diese Vorgehensweise ist wenig effizient. Daher bietet QF-Test eine umfassendere Struktur, den Abhängigkeit Knoten, zur Herstellung der Vorbedingungen und dem effizienten Umgang mit Aufräumarbeiten.

8.5

Prozeduren und Packages

In mancher Hinsicht ist das Schreiben von Tests dem Programmieren nicht unähnlich. Nachdem die ersten Schritte gemeistert sind, tendieren Tests ebenso wie Programmcode dazu, unkontrolliert auszuufern. Das funktioniert so lange ganz gut, bis irgendein grundlegender Baustein, auf den man sich verlassen hat, geändert werden muss. Ohne saubere Struktur brechen Programme ebenso wie Tests an diesem Punkt in sich zusammen, da der Aufwand für die Anpassung an die neue Situation höher ist als gleich von vorne anzufangen.

Ein Schlüsselpunkt, um dieses Problem zu verhindern, ist die Vermeidung von Redundanz. Wenn Sie sich zu sehr auf die Aufnahmefunktion allein verlassen, besteht die Gefahr, genau diese Redundanz zu erzeugen. Ein Beispiel: Sie nehmen verschiedene Sequenzen auf, die mit den Komponenten eines Dialogs interagieren. Um diese Sequenzen möglichst unabhängig voneinander zu halten, beginnen Sie jede Sequenz damit, dass Sie den Dialog öffnen. Analog beenden Sie die Sequenzen mit dem Schließen des Dialogs. Das ist eigentlich eine gute Idee, erzeugt aber Redundanz, da die Events zum Öffnen und Schließen des Dialogs in jeder einzelnen Sequenz vorkommen. Stellen Sie sich vor, was passiert, wenn sich das SUT auf eine Weise ändert, die dazu führt dass dieser Teil nicht mehr funktioniert, z.B. weil erst ein kleines Bestätigungsfenster geschlossen werden muss, bevor der Dialog geschlossen werden kann. Jetzt müssen Sie durch die gesamte Testsuite gehen, alle Stellen finden, an denen der Dialog geschlossen wird und jede einzelne Stelle an die neuen Gegebenheiten anpassen. Der blanke Horror...

Um noch einmal auf die Analogie zurückzukommen: Die entsprechende Art der Programmierung wird Spaghetti Programmierung genannt und führt zu der gleichen Art von Wartungsproblemen. Diese können vermieden werden, wenn identische Teile an einer Stelle zusammengefasst werden, wo sie bei Bedarf aufgerufen werden. Eine Anpassung an neue Gegebenheiten erfordert dann nur noch Modifikationen an dieser einen Stelle.

QF-Test verfügt über einen Satz von Knotentypen, der diese Art der Modularisierung ermöglicht. Dabei handelt es sich um die Knoten Prozedur, Prozeduraufruf und Package. Eine Prozedur ist einer Sequenz sehr ähnlich, abgesehen davon, dass der Name der Prozedur zur Referenzierung durch einen Prozeduraufruf Knoten dient. Ein Prozeduraufruf wird ausgeführt, indem die Kontrolle an die entsprechende Prozedur übergeben wird. Mit dem letzten Kindknoten der Prozedur ist dann auch der Prozeduraufruf beendet.

Packages sind dazu da, Prozeduren noch mehr Struktur zu geben, indem zusammengehörende Prozeduren in einem Package zusammengefasst werden können. Eine Hierarchie von Packages und Prozeduren ist unter dem Knoten Prozeduren angesiedelt.

Eine Prozedur, die immer exakt die selben Schritte ausführt, egal wie und woher sie aufgerufen wird, ist nur von sehr begrenztem Nutzen. Um obiges Beispiel fortzuführen, könnte eine Prozedur beispielsweise den Dialog öffnen und seine Felder mit einigen Werten vorbelegen. Diese Werte sollten dann natürlich nicht hart in der Prozedur verdrahtet sein, sondern wir wollen sie beim Prozeduraufruf individuell festlegen. Zu diesem Zweck können Parameter für eine Prozedur definiert werden. Im Prozeduraufruf werden dann Werte für diese Parameter festgelegt. Diese sind nur für genau diese Ausführung der Prozedur gültig. Eine ausführliche Beschreibung zur Definition von Parametern und allgemein Variablen in QF-Test, finden Sie in Kapitel 6. Zum besseren Verständnis ihres Zusammenspiels sollten Sie auch einen Blick auf die detaillierte Dokumentation der Prozedur und Prozeduraufruf Knoten werfen.

Eine Testsuite-Bibliothek mit allgemein nützlichen Prozeduren wird von QF-Test unter dem Namen qfs.qft zur Verfügung gestellt. Dieser Bibliothek ist ein ganzes Kapitel des Tutorials gewidmet. Abschnitt 26.1 erklärt, wie Sie die Bibliothek direkt in Ihre Testsuiten einbinden.

3.1+8.5.1

Lokale Prozeduren und Packages

Wenn Sie in mehreren Testsuiten arbeiten, dann könnten Sie in die Situation kommen, dass Sie manche wiederverwendbaren Sequenzen bzw. Testschritte nur von einer bestimmten Testsuite aus ansprechen möchten. Wenn Sie solche lokale Prozeduren erstellen wollen, dann müssen Sie als erstes Zeichen des Prozedurnamens ein '_' definieren. Das '_' markiert die Prozedur als lokal in der jeweiligen Testsuite.

Aufrufe von lokalen Prozeduren können nur innerhalb der Testsuite eingefügt werden, in der diese Prozedur definiert ist. Sie können dasselbe Konzept auch für lokale Packages nutzen.

3.1+8.5.2

Relative Prozeduren

Wenn Sie Prozeduren in anderen Prozeduren aufrufen, könnte es manchmal von Vorteil sein, nicht den vollen Namen der Prozedur definieren zu müssen.

So genannte 'relative' Prozeduraufrufe können nur in Packages eingefügt werden, welche das Attribut Grenze für relative Aufrufe (siehe auch Grenze für relative Aufrufe) gesetzt haben. Der Aufbau von relativen Aufrufen sieht wie folgt aus:

Wie Sie sehen können, wird für jede Ebene einfach ein Punkt hinzugefügt. Eine Prozedur zwei Ebenen höher, wird also mittels drei Punkten referenziert (Die aktuelle Ebene zählt auch mit).

8.5.3

Einfügen von Prozeduraufruf Knoten

Sie sollten Tests in einzelnen Testschritten organisieren, wobei idealerweise jeder Testschritt einem QF-Test Prozedur Knoten entspricht. QF-Test bietet unterschiedliche Methoden um Prozeduraufruf Knoten anzulegen:

1. Mittels Auswahl im Menü »Einfügen«-»Prozeduren«-»Prozeduraufruf«
2. Mittels Rechtsklick und Auswahl von »Knoten einfügen«-»Prozeduren«-»Prozeduraufruf«
3. Wenn Sie einen Prozedur Knoten an eine Stelle, wo ein Prozeduraufruf eingefügt werden soll, kopieren, wird dieser eingefügt.
4. Mittels Drag&Drop Operation, d.h. Ziehen eines Prozedur Knotens an die gewünschte Stelle.
5. Mittels Tastaturkürzel Strg⁠+⁠A
6. Mittels der Umwandlung einer Sequenz oder eines Testschritt in eine Prozedur, wie in Abschnitt 8.5.5 beschrieben. Tastaturkürzel Strg⁠+⁠Shift⁠+⁠P

Diese Methoden funktionieren auch für Bezug auf Abhängigkeit Knoten bis auf die letzten beiden.

3.1+8.5.4

Parametrisieren von Knoten

Sie können Parameter von Prozeduren, Abhängigkeiten oder Testfälle automatisch mittels des Menüs »Operationen«-»Knoten parametrisieren« erstellen.

Der Parametrisierungsdialog ermöglicht es Ihnen noch weitere Details über das Erstellen der Parameter zu definieren, z.B. ob nur Parameter für Texteingaben oder Checkknoten zu erstellen sind.

3.0+8.5.5

Konvertieren von Sequenzen und Testschritte in Prozeduren

Diese Konvertierung kann sehr hilfreich sein um sofort während der Entwicklung Prozeduren zu erstellen. Unter Extrasequenzen können Sie Sequenzen in Prozeduren konvertieren und in den Prozeduren Bereich verschieben.

3.1+ Wenn Sie eine Sequenz oder Testschritt unter einem Testfall konvertieren, dann erstellt QF-Test automatisch eine Prozedur und fügt an Stelle der Sequenz oder des Testschritt den entsprechenden Prozeduraufruf ein.

Die Konvertierung kann mittels dem Menü »Operationen«-»Knoten konvertieren in«-»Prozedur« oder über das Tastaturkürzel Shift⁠+⁠Strg⁠+⁠P angestoßen werden.

8.6

Abhängigkeit Knoten

Video: Abhängigkeiten

8.6.1

Funktionsweise

Abhängigkeiten stellen eine mächtige und optimierte Variante für die Herstellung von Vor- und Nachbedingungen dar. Sie sind unverzichtbar zur Ausführung von Tests im QF-Test Daemon-Modus. Ihre prinzipielle Funktionsweise ist wie folgt:

1. Erstellung einer Liste der für den Testfall benötigen Abhängigkeiten.
2. Vergleich der aktuellen Abhängigkeitenliste mit der des vorangehenden Testfalls.
3. Ausführung der Aufräumen Knoten derjenigen Abhängigkeiten, die in der Abhängigkeitenliste des aktuellen Testfalls nicht mehr vorkommen oder deren Charakteristische Variablen sich verändert haben sowie derjenigen Abhängigkeiten, die auf diesen basieren.
4. Ausführung aller Vorbereitung Knoten der aktuellen Abhängigkeitenliste.

Testfälle als auch andere Abhängigkeiten können sich mittels Bezug auf Abhängigkeit Knoten auf Abhängigkeit Knoten, die im Prozeduren Bereich abgelegt wurden, beziehen. Somit können Vorbereitung und Aufräumen Knoten, die sich in einem Abhängigkeiten Knoten befinden von mehreren Testfällen genutzt werden - im Gegensatz zu denjenigen, die direkt in einem Testfall oder Testfallsatz Knoten liegen.

Für das Verständnis der Arbeitsweise von Abhängigkeiten ist es hilfreich, sich das Vorgehen eines Testers bei manuellen Tests anzusehen: Zunächst führt er alle notwendigen Vorbereitungen und dann den ersten Testfall aus. Wenn bei der Ausführung des Testfalls Fehler auftreten, wird er gegebenenfalls Fehlerbehandlungsroutinen ausführen. Als nächstes prüft er, welche Vorbedingungen für den nächsten Test gelten und wird erst dann eventuelle Aufräumarbeiten durchführen. Dabei wird er nur das aufräumen, was für nächsten Testfall nicht mehr benötigt wird. Als nächstes geht er alle Vorbedingungen durch und prüft, ob die notwendigen Voraussetzungen noch bestehen oder ob zum Beispiel auf Grund von Fehlern im vorhergehenden Testfall wiederhergestellt werden müssen. Falls das SUT in einen stark fehlerhaften Zustand versetzt wurde, führt er weitere Aufräumarbeiten aus bevor er die Vorbedingungen für den nächsten Testfall herstellen kann.

Genau diese Vorgehensweise können Sie über QF-Test Abhängigkeiten abbilden.

Mit den Abhängigkeiten werden die Nachteile der klassischen Vorbereitung und Aufräumen Knoten, dass zum einen die Vorbereitung Knoten nur über die Verschachtelungen von Testfallsätzen geschachtelt werden können und zum anderen in jedem Fall der Aufräumen Knoten ausgeführt wird, behoben. Beides ist nicht sonderlich effizient. Abhängigkeit Knoten geben nicht nur eine Antwort auf diese beiden Punkte sondern bieten zudem Strukturelemente für die Behandlung von Fehlern und unvorhergesehenen Ereignissen.

Abhängigkeiten werden in vielen mitgelieferten Beispieltestsuiten verwendet, zum Beispiel:

• In doc/tutorial die Testsuite namens dependencies.qft. Die Abhängigkeiten in dieser Testsuite werden ausführlich im Tutorial in Kapitel 16 erläutert.
• Im Verzeichnis demo/carconfigSwing die Testsuite carconfigSwing_de.qft, die ein realistisches Beispiel enthält.
• Die SWT Demo Suite namens swt_addressbook.qft, die für SWT-Anwender ein Beispiel bietet.
• In demo/eclipse die Testsuite namens eclipse.qft, in der Sie eine verschachtelte Abhängigkeit finden.
• In doc/tutorial verwendet das Datentreiber-Demo datadriver.qft Abhängigkeiten.

Wenn Sie im Debugger in Einzelschritten durch diese Testsuiten gehen und sich die zugehörigen Variablenbindungen und Protokolle ansehen, sollten Sie ein gutes Gefühl für diese Technik bekommen. Bitte beachten Sie, dass Sie veränderte Testsuiten am besten in einem projektspezifischen Ordner speichern.

8.6.2

Verwendung von Abhängigkeiten

Abhängigkeiten können an zwei Stellen definiert werden:

• Allgemeine Abhängigkeiten, die oft wiederverwendet werden und als Grundlage für weitere Abhängigkeiten dienen, können genau wie ein Prozedur Knoten implementiert und unterhalb des Prozeduren Knotens platziert werden, zum Beispiel in einem Package Knoten namens "Abhängigkeiten". Der qualifizierte Name wird genau wie der einer Prozedur gebildet. Abhängigkeiten können analog zu einem Prozeduraufruf durch einen Bezug auf Abhängigkeit Knoten referenziert werden.
• Alternativ können Abhängigkeiten Knoten am Beginn eines Testsuite, Testfallsatz oder Testfall Knotens implementiert werden.

Zusätzlich zu ihrer eigenen Abhängigkeit können Testfälle und Testfallsätze die Abhängigkeit von ihrem Parentknoten erben.

Eine Abhängigkeit sollte sich jeweils nur um eine Vorbedingung kümmern. Hat diese ihrerseits Vorbedingungen, sollten diese zu Grunde liegenden Schritte von anderen Abhängigkeiten übernommen werden. Dies kann implizit durch Erben der Abhängigkeit von einem Parentknoten oder explizit durch einen Bezug auf Abhängigkeit Knoten geschehen.

Die eigentliche Implementierung der Vor- und Nachbedingungen geschieht in Vorbereitung und Aufräumen Knoten innerhalb der Abhängigkeit.

Enthält ein Testfallsatz oder Testfall Knoten sowohl Abhängigkeit Knoten als auch Vorbereitung und Aufräumen Knoten, wird die Abhängigkeit zuerst aufgelöst. Vorbereitung und Aufräumen Knoten haben keinen Einfluss auf den Stapel von Abhängigkeiten.

8.6.3

Abhängigkeiten - Ausführung und Stapel von Abhängigkeiten

Die Ausführung einer Abhängigkeit gliedert sich in drei Phasen:

1. Erstellung einer Liste benötigter Abhängigkeiten und Abgleich mit der Liste früher ausgeführter Abhängigkeit Knoten
2. Ausführung von Aufräumen Knoten, falls notwendig
3. Ausführung der Vorbereitung Knoten aller benötigen Abhängigkeiten

Die im vorliegenden Kapitel verwendeten Beispiele beziehen sich alle auf Testfälle, die eine Kombination der folgenden Vorbedingungen und Nachbereitungen erfordern:

Beispiel

Abhängigkeit A: Anwendung gestartet

Vorbereitung: Anwendung bei Bedarf starten
Aufräumen: Anwendung stoppen

Abhängigkeit B: Anwender angemeldet

Vorbereitung: Anwender bei Bedarf anmelden
Aufräumen: Anwender abmelden

Abhängigkeit C: Anwendungsmodul 1 geladen

Vorbereitung: Anwendungsmodul 1 bei Bedarf laden
Aufräumen: Anwendungsmodul beenden

Abhängigkeit D: Anwendungsmodul 2 geladen

Vorbereitung: Anwendungsmodul 2 bei Bedarf laden
Aufräumen: Anwendungsmodul 2 beenden

Abhängigkeit E: Dialog in Modul 2 geöffnet

Vorbereitung: Dialog in Modul 2 bei Bedarf öffnen
Aufräumen: Dialog schließen

Abhängigkeit C hängt von B ab, B wiederum von A.
Abhängigkeit E hängt von D ab, D von B und damit auch von A.

Vor der Ausführung eines Testfall Knotens prüft QF-Test, ob dieser einen Abhängigkeit Knoten besitzt oder erbt. In diesem Fall prüft QF-Test, ob der Abhängigkeit Knoten seinerseits weitere Abhängigkeiten einbezieht. Auf Basis dieser Analyse erstellt QF-Test zunächst eine Liste der auszuführenden Abhängigkeiten. Dies entspricht Schritt 1 des nachfolgenden Beispiels.

Als nächstes prüft QF-Test, ob bereits für vorhergehende Testfälle Abhängigkeiten ausgeführt wurden. Falls ja, vergleicht QF-Test die Liste der ausgeführten Abhängigkeiten mit den aktuell benötigten. Für nicht mehr benötigte Abhängigkeiten werden nun die Aufräumen Knoten ausgeführt. Danach durchläuft QF-Test alle Vorbereitung Knoten, wobei mit den grundlegenden Abhängigkeiten begonnen wird. Der Name des ausgeführten Abhängigkeiten Knotens wird jeweils vermerkt. Diese Liste wird Abhängigkeitenstapel genannt.

Beispiel: Testfall 1

Test von Anwendungsmodul 1.
Es handelt sich um den ersten ausgeführten Testfall Knoten.

1. Schritt:
   Die Analyse der Abhängigkeiten ergibt eine Liste mit den Abhängigkeiten A-B-C (Anwendung gestartet, Anwender angemeldet, Modul 1 geladen).
2. Schritt
   Abgleich der Abhängigkeitenliste mit dem Abhängigkeitenstapel: In diesem Beispiel ist der Abhängigkeitenstapel leer, da noch kein Testfall ausgeführt wurde.
3. Schritt
   Ausführung der Vorbereitung Knoten, beginnend mit A (Anwendung starten), dann B (Anwender anmelden, Anwendername: Standard), und C (Modul 1 laden).
   Auf dem Abhängigkeitenstapel wird die Ausführung der Abhängigkeiten A-B-C vermerkt.
4. Schritt
   Ausführung des Testfall Knotens.

Diese Schritte lassen sich im Protokoll genau nachverfolgen:

Nach Ausführung des Testfall Knotens verbleibt die Anwendung zunächst in dem Zustand, in den der Testfall sie versetzt hat. Erst nach der Analyse der Abhängigkeiten des nächsten Testfall Knotens werden bei Bedarf Abhängigkeiten abgebaut - in umgekehrter Ausführungsreihenfolge der Vorbereitung Knoten. Anschließend werden die Vorbereitung Knoten aller benötigen Abhängigkeiten durchlaufen. Dieser Punkt ist sehr wichtig. Es werden also nicht einfach die restlichen Vorbereitung Knoten ausgeführt, sondern die aller einbezogenen Abhängigkeit Knoten. Der Grund hierfür ist, dass es, wie bereits erwähnt, in der Natur des Testens liegt, dass es zu Fehlerzuständen kommen kann. Daher wird vor Ausführung eines Vorbereitung Knotens geprüft, ob auch die jeweils zugrunde liegenden Voraussetzungen erfüllt sind. Die Vorbereitung Knoten sollten daher so aufgebaut sein, dass zunächst geprüft wird, ob die Voraussetzung bereits gegeben ist und nur bei Bedarf der gesamte Vorbereitung Knoten durchlaufen wird.

Außerdem sollten Vorbereitung Knoten und Aufräumen Knoten immer in der Lage sein, Programmzustände, die auf Grund von Fehlern nicht dem Sollzustand entsprechen, zu bereinigen, so dass der nachfolgende Testfall nicht von vorangehenden Fehlern beeinträchtigt wird. Auch sollte ein Aufräumen Knoten nicht zu einem Fehler führen, wenn der angestrebte Zustand bereits besteht. Wenn das SUT zum Beispiel beendet werden soll, darf es zu keinem Fehler kommen, wenn es, aus welchem Grund auch immer, schon vor Ausführung des Aufräumen Knotens nicht mehr läuft.

Beispiel: Testfall 2

Test eines Dialogs in Anwendungsmodul 2

1. Schritt:
   Die Analyse der einbezogenen Abhängigkeiten ergibt die Abhängigkeitenliste A-B-D-E (Anwendung gestartet, Anwender angemeldet, Modul 2 geladen, Dialog geöffnet).
2. Schritt:
   Abgleich der Abhängigkeitenliste mit dem Abhängigkeitenstapel: Abhängigkeit C ist keine Voraussetzung für Testfall 2. Daher wird der Aufräumen Knoten der Abhängigkeit C ausgeführt (Beenden von Modul 1).
3. Schritt:
   Ausführung der Vorbereitung Knoten, beginnend mit A (Es wird erkannt, dass die Anwendung bereits läuft und der Rest des Vorbereitung Knotens übersprungen.), dann B (Es wird erkannt, dass der Anwender bereits angemeldet ist und der Rest des Vorbereitung Knotens übersprungen.), dann D (Es wird erkannt, dass Modul 2 noch nicht geladen ist - der Vorbereitung Knoten wird komplett ausgeführt.), dann E (analog zu D).
4. Schritt:
   Ausführung des Testfall Knotens 2.

Auch der Aufräumen-Schritt erscheint im Protokoll:

8.6.4

Charakteristische Variablen

Eine Abhängigkeit kann ihrerseits von den Werten gewisser Variablen abhängen. Diese Variablen werden als Charakteristische Variablen einer Abhängigkeit bezeichnet. Beim Abgleich der benötigten Abhängigkeit Knoten mit den bereits ausgeführten auf dem Abhängigkeitenstapel werden die Charakteristischen Variablen mit herangezogen. Zwei Abhängigkeit Knoten gelten nur dann als gleich, wenn auch die Werte aller Charakteristischen Variablen zwischen der vorherigen und der aktuellen Ausführung übereinstimmen. Somit ist es auch möglich, dass eine Abhängigkeit sich, direkt oder indirekt, mehrfach auf die selbe Abhängigkeit bezieht, aber mit unterschiedlichen Werten für die Charakteristischen Variablen. In diesem Fall taucht die bezogene Abhängigkeit mehrfach in der Liste der benötigten Abhängigkeiten und nach deren Ausführung auf dem Abhängigkeitenstapel auf, jeweils mit dem entsprechenden Wert der Charakteristischen Variablen.

Wird die Abhängigkeit abgebaut und ihr Aufräumen Knoten ausgeführt, erhalten die Charakteristischen Variablen innerhalb des Aufräumen Knotens die gespeicherten Werte, also die, die sie zum Zeitpunkt der Ausführung des Vorbereitung Knotens hatten. Dadurch wird sicher gestellt, dass die Ausführung eines Testfall Knotens mit anderen Variablenwerten die Aufräumen Knoten beim Abbau des Abhängigkeitenstapels nicht aus der Bahn werfen kann. Denken Sie zum Beispiel an die häufig für den Namen des SUT Clients verwendete Variable "client". Wird zunächst ein Satz von Tests für ein SUT ausgeführt und benötigt der nächste Testfall ein ganz anderes SUT, wird eventuell die Variable "client" umdefiniert. Der Aufräumen Knoten zum Beenden des alten SUT muss aber den alten Wert für "client" erhalten, sonst könnte er den alten SUT Client gar nicht beenden. Darum kümmert sich QF-Test automatisch, sofern sich "client" unter den Charakteristischen Variablen der Abhängigkeit befindet.

Beispiel: Testfall 3:

Der gleiche Dialog soll für den Administrator getestet werden.

1. Schritt:
   Die Analyse der einbezogenen Abhängigkeiten ergibt die gleiche Abhängigkeitenliste A-B-D-E (Anwendung gestartet, Anwender angemeldet, Modul 2 geladen, Dialog geöffnet) wie für Testfall 2, wobei die Charakteristische Variablen in Abhängigkeit B den Wert 'Administrator' hat.
2. Schritt:
   Abgleich der Abhängigkeitenliste mit dem Abhängigkeitenstapel: Die benötigte Abhängigkeit B unterscheidet sich auf Grund der Charakteristischen Variablen 'anwendername' mit dem Wert 'Administrator' von der auf dem Abhängigkeitenstapel gespeicherten mit dem Wert 'Standard'. Dies bedeutet, dass der Abhängigkeitenstapel bis einschließlich Abhängigkeit B (Anwender abmelden) abgebaut wird, beginnend mit Aufräumen für Abhängigkeit E (Dialog schließen), dann Aufräumen für Abhängigkeit D (Modul 2 beenden), dann Aufräumen für Abhängigkeit B (Anwender abmelden). Die Variable 'anwendername' erhält hierbei den über die Charakteristische Variablen gespeicherten Wert 'Standard'.)
3. Schritt:
   Ausführung der Vorbereitung Knoten, beginnend mit A (Es wird erkannt, dass die Anwendung bereits läuft und der Rest der Vorbereitung übersprungen.), dann B (Administrator anmelden), dann D (Modul 2 laden), dann E (Dialog öffnen)
4. Schritt:
   Ausführung des Testfall Knotens 3

Im Protokoll sieht man die den Wert der Charakteristischen Variablen hinter der jeweiligen Abhängigkeit:

Weitere typische Beispiele für Charakteristischen Variablen sind die JDK-Version, wenn das SUT mit verschiedenen JDK-Versionen getestet werden soll, oder der Browsername im Falle einer Web-Anwendung. Diese würden in unserem Beispiel als Charakteristische Variablen für Abhängigkeit A (Anwendung gestartet) definiert.

8.6.5

Aufräumen erzwingen

In manchen Anwendungsfällen kann es nötig sein, dass der Aufräumen Knoten einer Abhängigkeit nach jedem Testfall ausgeführt wird. In diesem Fall kann das Attribut Aufräumen erzwingen gesetzt werden.

Falls bei einem der Abhängigkeit Knoten auf dem Stapel das Attribut Aufräumen erzwingen gesetzt ist, werden von diesem und eventuell nachgeordneten Abhängigkeit Knoten die Aufräumen Knoten ausgeführt.

Beispiel:

In diesem Beispiel verlangt die Testlogik, dass das Anwendungsmodul 2 nach Testausführung immer beendet werden muss. Somit wird im Abhängigkeit Knoten D das Attribut Aufräumen erzwingen gesetzt.

Nun würden in Schritt 2 unserer Beispiele immer die Aufräumen Knoten der Abhängigkeit E (Dialog schließen) und der Abhängigkeit D (Modul 2 beenden) ausgeführt.

8.6.6

Abhängigkeiten abbauen

QF-Test räumt Abhängigkeiten je nach Bedarf der Testfälle auf.

Sie können den Stapel der Abhängigkeiten auf zwei Arten explizit leeren:

• Über den Menüeintrag »Wiedergabe«-»Abhängigkeiten auflösen« wird der Stapel "sauber" abgebaut indem alle Aufräumen Knoten in umgekehrter Reihenfolge der Abhängigkeitsvorbereitungen ausgeführt werden.
• Mittels »Wiedergabe«-»Abhängigkeiten zurücksetzen« wird der Stapel dagegen einfach gelöscht, ohne dass irgendein Knoten ausgeführt wird.

Bei einem Testfall, der selbst keine Abhängigkeiten nutzt, bleibt der Stapel der Abhängigkeiten unberührt, d.h. es werden keine Aufräumen Knoten ausgeführt. Erst beim nächsten Testfall mit Abhängigkeiten wird der Abhängigkeitenstapel wieder berücksichtigt.

8.6.7

Eskalation von Fehlern

Eine weitere hervorragende Eigenschaft von Abhängigkeiten ist die Möglichkeit, Fehler ohne weiteren Aufwand zu eskalieren. Betrachten wir wieder das Beispiel aus dem vorhergehenden Abschnitt nachdem der erste Abhängigkeitenstapel A-B-C (Anwendung gestartet, Anwender angemeldet, Modul 1 geladen) aufgebaut und alle zugehörigen Vorbereitung Knoten ausgeführt wurden. Was passiert, wenn bei der Ausführung des eigentlichen Testfall Knotens das SUT auf einen wirklich schweren Fehler stößt wie z.B. ein Deadlock und nicht mehr auf Benutzereingaben reagiert?

Schlägt beim Abbau des Stapels von Abhängigkeiten die Ausführung eines Aufräumen Knotens fehl, baut QF-Test die nächstzugrunde liegende Abhängigkeit ab, bei erneuten Problemen eine weitere und so fort. Analog dazu führt beim Aufbau des Stapels ein Fehler in einem Vorbereitung Knoten dazu, dass zunächst eine weitere Abhängigkeit abgebaut wird und dann noch einmal die Vorbereitung Knoten ausgeführt werden.

Beispiel:

Im obigen Beispiel Testfall 1 geht das SUT zum Beispiel in ein Deadlock und reagiert nicht mehr auf Eingaben. Zunächst wird eine Exception geworfen, die Ausführung von Testfall 1 abgebrochen und mit Testfall 2 fortgefahren.

1. Schritt:
   Analyse der benötigten Abhängigkeiten und Erstellen der
   Abhängigkeitenliste A-B-D-E (Anwendung gestartet, Anwender angemeldet, Modul 2 geladen, Dialog geöffnet)
2. Schritt:
   Der Abgleich der benötigten Abhängigkeiten mit dem von Testfall 1 aufgebauten Abhängigkeitenstapel A-B-C (Anwendung gestartet, Anwender angemeldet, Modul 1 geladen) bewirkt, dass der Aufräumen Knoten der Abhängigkeit C (Modul 1 beenden) ausgeführt wird.
   Dabei kommt es erneut zur Exception. Nun führt QF-Test den Aufräumen Knoten der zu Grunde liegenden Abhängigkeit B (Anwender abmelden) aus. Dies scheitert erneut, so dass wiederum die zu Grunde liegende Abhängigkeit A aufgeräumt wird. Diese schließt erfolgreich die Anwendung.
3. Schritt:
   Ausführung der Vorbereitung Knoten, beginnend mit A (Anwendung starten), dann B (Anwender anmelden), dann D (Modul 1 laden) und schließlich E (Dialog öffnen).
4. Schritt:
   Testfall 2 kann trotz des Deadlocks in Testfall 1 ausgeführt werden.

Dies lässt sich wieder genau im Protokoll nachverfolgen:

Damit die Fehlereskalation zuverlässig funktioniert, ist es sehr wichtig, Aufräumen Knoten so zu implementieren, dass entweder der gewünschte Zustand erreicht oder eine Exception geworfen wird. Letzteres führt nur zum Erfolg, wenn in einer der grundlegenderen Abhängigkeiten ein umfassender Aufräumen Knoten vorhanden ist, der das SUT in einen definierten Zustand bringen oder beenden kann. Dabei ist es wichtig, dass zum Beispiel der Aufräumen Knoten, der das SUT beenden soll, nicht nur versucht, das SUT etwa über das Datei->Beenden Menü sauber herunterzufahren, sondern auch abprüft, ob die Aktion erfolgt reich war und gegebenenfalls drastischere Maßnahmen durchführt wie zum Beispiel den Prozess des SUT "abzuschießen". Ein solcher Aufräumen Knoten sollte also einen Try/Catch Block verwenden und zusätzlich in einem Finally Knoten sicherstellen, dass das SUT auf jeden Fall beendet ist.

Bei sauber implementierter Fehlerbehandlung werden sich Testfälle selbst bei schweren Fehlern kaum gegenseitig beeinflussen. Dies schützt vor dem Verlust aller Testergebnisse eines lang dauernden nächtlichen Testlaufs nur aufgrund eines einzelnen Fehlers zu einem frühen Zeitpunkt.

8.6.8

Fehlerbehandlung und Reaktion auf unerwartetes Verhalten

Neben der automatischen Eskalation von Fehlern unterstützt ein Abhängigkeit Knoten auch die explizite Behandlung von Fehlern oder Exceptions, die bei der Ausführung eines Testfall Knotens auftreten. Hierzu können Catch Knoten am Ende des Abhängigkeit Knotens eingefügt werden. Diese fangen im Testfall auftretende Exceptions und können gezielt darauf reagieren. So könnte zum Beispiel eine DeadlockTimeoutException mit umgehender Terminierung des SUT Prozesses quittiert werden. Eine derart gefangene Exception wird in Protokoll und Report weiterhin als Exception aufgeführt.

Des Weiteren kann ein Fehlerbehandlung Knoten in der Abhängigkeit zwischen dem Aufräumen Knoten und dem ersten Catch Knoten eingefügt werden. Dieser wird ausgeführt, wenn der Testfall mit dem Ergebnis "Fehler" beendet wird. Im Fall einer Exception wird der Fehlerbehandlung Knoten nicht ausgeführt, da das in der Regel eher noch mehr Probleme verursachen würde und sogar mit der Behandlung von Exceptions kollidieren könnte. Um im Fall von Fehlern und Exceptions die selben Konsequenzen zu ziehen, können Sie dafür eine Prozedur implementieren und diese aus Fehlerbehandlung und Catch Knoten heraus aufrufen. Fehlerbehandlung Knoten sind nützlich, um Informationen zu ermitteln und zu speichern, die QF-Test nicht bereits automatisch zur Verfügung stellt.

So könnten Sie beispielsweise eine Kopie von temporären Dateien oder Protokollen erstellen, die von Ihrem SUT angelegt werden und eventuell Aufschlüsse über die Fehlerursache liefern könnten. Es wird jeweils nur der oberste Fehlerbehandlung Knoten auf dem Stapel von Abhängigkeiten ausgeführt. Wenn also bei einem Stapel der Form A,B,C,D] sowohl A als auch C einen Fehlerbehandlung Knoten enthalten, wird nur der Knoten von C ausgeführt. Andernfalls wäre es schwierig, in der spezialisierten Abhängigkeit C die Fehlerbehandlung der allgemeineren Abhängigkeit A zu modifizieren. Um die Fehlerbehandlung von A in C wiederzuverwenden, implementieren Sie diese in einer Prozedur.

8.6.9

Namensräume für Abhängigkeiten

Hinweis Dieser Absatz ist für Sie nur interessant, wenn Sie mehrere Applikationen haben, die Sie gleichzeitig testen wollen und wenn der Abhängigkeit Knoten eines Testfalls keine Auswirkung auf den bestehenden Abhängigkeitenstapel haben soll.

Ein typischer Anwendungsfall ist der Test ganzer Prozessketten, die mehrere Applikationen umfassen.

Als Beispiel soll hier folgende Situation dienen: Der Außendienst erfasst die Angebotsdaten über eine Web-Applikation und schickt diese an ein Datenbanksystem in der Zentrale, wo die Angebote vervollständigt, gedruckt und versandt werden. Eine Kopie der versandten Aufträge wird in einem separaten Dokumentenmanagementsystem (DMS) abgespeichert.

In obigem Beispiel erfassen zwei unterschiedliche Mitarbeiter (AnwenderA und AnwenderB) die Daten für das Angebot, zwei weitere (AnwenderC und AnwenderD) erstellen die Angebote und die Archivierung wird im Dokumentenmanagementsystem geprüft. Damit sich die Anhängigkeiten nicht gegenseitig beeinflussen, wird im Bezug auf Abhängigkeit Knoten jeweils ein passender Name im Feld Namensraum für Abhängigkeiten eingetragen.

Wenn man den Testfallsatz ausführt, sieht man im Protokoll, dass für den ersten Testfall ein Abhängigkeitenstapel im Namensraum "Datenerfassung" angelegt wird:

Für den zweiten Testfall wird ein Abhängigkeitenstapel im Namensraum "Datenbanksystem" angelegt. Der Abhängigkeitenstapel im Namensraum "Datenerfassung" wird nicht betrachtet. Es wird also das Datenbanksystem gestartet. Die Anwendung zur Datenerfassung bleibt unverändert.

Für den dritten Testfall wird ein Abhängigkeitenstapel im Namensraum "Dokumentenverwaltung" angelegt. Die Abhängigkeitenstapel in den Namensräumen "Datenerfassung" und "Datenbanksystem" werden nicht betrachtet. Es wird also das Dokumentenmanagementsystem gestartet. Die beiden anderen Anwendungen bleiben unverändert.

Im vierten Testfall werden die benötigten Abhängigkeiten mit dem vorhandenen Stapel im Namensraum "Datenerfassung" aus dem ersten Testfall abgeglichen. Die Abhängigkeitenstapel in den beiden anderen Namensräumen werden nicht betrachtet. Es wird also Anwender A abgemeldet und Anwender B an der Datenerfassung neu angemeldet. Die beiden anderen Anwendungen bleiben unverändert.

Im fünften Testfall werden die benötigten Abhängigkeiten mit dem vorhandenen Stapel im Namensraum "Datenbanksystem" aus dem zweiten Testfall abgeglichen. Die Abhängigkeitenstapel in den beiden anderen Namensräumen werden nicht betrachtet. Es wird also Anwender C abgemeldet und Anwender D im Datenbanksystem neu angemeldet. Die beiden anderen Anwendungen bleiben wiederum unverändert.

Im letzten Testfall wird die benötigte Abhängigkeit mit dem vorhandenen Stapel im Namensraum "Dokumentenverwaltung" aus dem dritten Testfall abgeglichen. Die Abhängigkeitenstapel in den beiden anderen Namensräumen werden nicht betrachtet. Es ergibt sich kein Handlungsbedarf bezüglich Aufräumarbeiten. Die beiden anderen Anwendungen bleiben wiederum unverändert.

8.7

Dokumentieren von Testsuiten

Wie jede programmierähnliche Tätigkeit benötigt Testautomatisierung eine gute Dokumentation um langfristig erfolgreich sein zu können. Andernfalls besteht die Gefahr, den Überblick zu verlieren und Dinge unnötigerweise mehrfach zu implementieren oder Tests zu übersehen, die automatisiert werden sollten. Eine gute Dokumentation ist von unschätzbarem Wert, wenn Sie sich auf der Suche nach der Ursache für einen fehlgeschlagenen Test durch ein Protokoll arbeiten. Außerdem trägt sie wesentlich zur Lesbarkeit von Reports bei.

Eine gute Möglichkeit, die Tests lesbar zu gestalten und gleichzeitig zu dokumentieren sind die Sequenz und Testschritt Knoten, mit deren Hilfe Sie die aufgenommenen Knoten zusammenfassen und beschriften können.

Es steht auch ein Kommentar Knoten zur Verfügung um Erläuterungen einzufügen.

Wenn Sie eine Dokumentation erstellen wollen, die auch außerhalb von QF-Test verfügbar sein soll, so können Sie basierend auf den Bemerkung Attributen von Testfallsatz, Testfall, Package und Prozedur Knoten einen Satz von umfassenden HTML Dokumenten erstellen, welche die benötigten Informationen schnell auffindbar machen. Die verschiedenen Arten von Dokumenten und die Mittel zu ihrer Erstellung werden ausführlich in Kapitel 24 beschrieben.