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. Stellen Sie sicher, dass:

• Sie eine gute Vorstellung davon haben, was Sie eigentlich testen wollen.
• Sie die richtigen Dinge testen.
• Ihre Tests zuverlässig und wiederholbar sind sowie im Fall von Änderungen am SUT, die QF-Test nicht kompensieren kann, einfach gewartet werden können.
• Die Ergebnisse Ihrer Tests aussagekräftig sind.

Eine der wesentlichen Voraussetzungen hierfür, nämlich eine saubere Struktur der 'Komponenten', wurde bereits in Kapitel 6 besprochen. In diesem Kapitel werden wir uns auf die Strukturierung der eigentlichen Sequenzen, Events, Checks, etc. konzentrieren.

Ein primärer Baustein einer Testsuite ist der 'Sequenz' Knoten, der seine Kindknoten einen nach dem anderen ausführt. Der 'Test' Knoten ist diesem ähnlich, bietet aber zusätzlich Möglichkeiten für vorbereitende und aufräumende Maßnahmen. Vor QF-Test Version 2 war der 'Test' Knoten der primäre Repräsentant für einen konzeptuellen Testfall. In dieser Rolle wurde er von den neuen 'Testfall' und 'Testfallsatz' Knoten abgelöst, welche im folgenden Abschnitt 10.2 näher beschrieben werden. Dennoch sind 'Sequenz' und 'Test' Knoten immer noch wichtige Bausteine auf den unteren Ebenen. Der Unterschied zwischen diesen beiden Knoten liegt in ihrer Semantik.

		Abbildung 10.1:  'Sequenzen' und 'Tests'

Das Konzept eines 'Sequenz' Knotens ist, dass seine Kindknoten genau in der angegebenen Reihenfolge abgearbeitet werden müssen, da jeder Knoten vom Ergebnis seines Vorgängers abhängig ist. Eine aufgenommene Sequenz von Events ist hierfür ein gutes Beispiel. Stellen Sie sich vor, was passiert, wenn die Events in zufälliger Reihenfolge abgespielt würden.

Im Gegensatz hierzu steht die Semantik eines 'Test' Knotens. Seine Kindknoten sind voneinander unabhängig und sollten in beliebiger Reihenfolge ausgeführt werden können. Um diese Unabhängigkeit zu erreichen, muss gewährleistet sein, dass jeder Kindknoten vor seiner Ausführung die gleichen Ausgangsbedingungen vorfindet. Diese Ausgangsbedingungen herzustellen ist Aufgabe des 'Test' Knotens, der zu diesem Zweck über zwei zusätzliche Kindknoten verfügen kann: 'Vorbereitung' und 'Aufräumen'.

Wie bei der 'Sequenz' werden auch die normalen Kindknoten eines 'Tests' einer nach dem anderen in der gegebenen Reihenfolge abgearbeitet. Zusätzlich wird vor jedem Kindknoten einmal der 'Vorbereitung' Knoten ausgeführt, der für die Herstellung des konsistenten Ausgangszustandes verantwortlich ist. Nach jedem Kindknoten kommt der 'Aufräumen' Knoten zum Zug, der für die Beseitigung der Folgen des Kindknotens im SUT zuständig ist.

Das mag alles unnötig kompliziert klingen, aber die Vorbedingungen für einen Test und die Abgrenzung von Tests so dass sie völlig unabhängig voneinander werden, sind so wichtige Themen, dass in QF-Test Version 2 'Vorbereitung' und 'Aufräumen' Knoten durch einen noch mächtigeren Mechanismus abgelöst wurden. Dieser basiert auf 'Abhängigkeit' Knoten, welche in Kapitel 12 genauer beschrieben werden. Doch ebenso wie 'Test' Knoten erfüllen auch 'Vorbereitung' und 'Aufräumen' noch ihren Zweck auf den unteren Ebenen. Ein 'Test' Knoten mit durchdachten, passenden 'Vorbereitung' und 'Aufräumen' Knoten hat folgende wichtige Eigenschaften:

• Sie können zu einem 'Test' jederzeit weitere Kindknoten an beliebiger Position hinzufügen, ohne die anderen Knoten zu beeinflussen.
• Wenn Sie einen Test erweitern, oder einfach eine Sequenz ausprobieren wollen, müssen Sie nicht alle vorhergehenden Schritte ausführen, um das SUT in den passenden Zustand zu bringen.
• Sie können jede beliebige Teilmenge der Knoten eines 'Tests' ausführen, wenn Sie nicht den gesamten Test benötigen.
• Wenn ein Kindknoten eines 'Tests' aus irgendeinem Grund fehlschlägt, können die restlichen Kindknoten trotzdem ausgeführt werden, sofern die 'Vorbereitung' und 'Aufräumen' Knoten in der Lage sind unter diesen Umständen den Ausgangszustand wiederherzustellen. In einer 'Sequenz', in der jeder Knoten direkt von seinem Vorgänger abhängt, bedeutet der Fehlschlag eines einzelnen Knotens automatisch das Scheitern der gesamten Sequenz.

Das Attribut 'Implizit Exceptions fangen' eines 'Tests' ist für die oben beschriebene Fehlerbehandlung zuständig.

Mit den Knoten 'Testfallsatz' und 'Testfall' bietet QF-Test eine einfache, pragmatische Form der Testfallverwaltung direkt innerhalb von QF-Test. Ihre wichtigste Eigenschaft ist die intelligente Verwaltung von Abhängigkeiten, die im folgenden Kapitel 12 beschrieben wird. Damit können 'Testfälle' so erstellt werden, dass sie völlig unabhängig voneinander sind. Mit den richtigen 'Abhängigkeit' Knoten werden Aufräumarbeiten im SUT von vorhergehenden Tests ebenso automatisch erledigt wie die Vorbereitungen für den aktuellen Test sowie die gesamte Fehlerbehandlung.

Ein 'Testfall' Knoten entspricht konzeptuell einem einzelnen elementaren Testfall und ist damit das entscheidende Bindeglied zwischen Testplanung, -durchführung und -auswertung. Mit Hilfe von 'Abhängigkeiten' können 'Testfälle' so voneinander isoliert werden, dass sie in beliebiger Reihenfolge ausgeführt werden können. QF-Test sorgt dabei für die automatische Auflösung aller Abhängigkeiten der Tests. Aufräumarbeiten werden ebenfalls automatisch durchgeführt und zwar so, dass beim Übergang von einem Test zum nächsten nur die minimal notwendigen Aktionen ausgeführt werden. 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älle' die ähnliche Anforderungen für Vorbereitung und Aufräumen haben. 'Testfallsätze' können verschachtelt werden. Die Struktur der 'Testfallsatz' und 'Testfall' Knoten ist damit ähnlich zu der Struktur der 'Package' und 'Prozedur' 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. Wichtig hierbei ist, dass ein 'Testaufruf' auch bei der Ausführung als elementar zu sehen ist. Daher 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.

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 im 'Testaufruf' Knoten überschrieben werden. Ein 'Testfall' kann zudem wie ein 'Test' Knoten Variablen definieren, die auf dem Primärstapel gebunden werden und nicht von außen überschrieben werden können.

Die Liste der 'Charakteristischen Variablen' gibt die Namen der Variablen an, deren Werte bei datengetriebenem Testen für einen Durchlauf des jeweiligen Knotens charakteristisch sind. Jede Ausführung eines 'Testfall' Knotens mit einem eigenen Satz von charakteristischen Variablen ist als eigenständiger Testfall anzusehen. Die Expandierten Werte dieser Variablen werden in Protokoll und Report angezeigt und helfen somit bei der Analyse von Problemen.

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. Ist der Wert falsch, wird der Test als übersprungen gewertet.

Manchmal wird das Fehlschlagen eines 'Testfalls' für eine bestimmte Zeitdauer erwartet, z. B. wenn dieser bereits 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.

Aus Gründen der Rückwärtskompatibilität und um den Übergang von den alten 'Test' zu den modernen 'Testfallsatz' und 'Testfall' Knoten zu erleichtern, behandelt QF-Test 'Test' Knoten im Report analog zu 'Testfallsatz' oder 'Testfall' Knoten, sofern deren Position in der Hierarchie dies zulässt.

Alte Testsuiten, deren Struktur noch auf 'Test' Knoten basiert, können migriert werden, um die neuen Features von 'Testfallsätze' und 'Testfälle' zu nutzen. Klicken Sie hierzu mit der rechten Maustaste auf einen Knoten, um dessen Kontextmenü anzuzeigen. Wenn eine Transformation erlaubt ist, wird QF-Test anbieten, den 'Test' Knoten in einen 'Testfallsatz' oder 'Testfall' Knoten umzuwandeln. Um eine ganze Hierarchie von 'Test' Knoten zu transformieren müssen Sie von oben nach unten arbeiten.

Hinweis Sowohl 'Testfallsatz' als auch 'Testfall' Knoten können aus Gründen der Rückwärtskompatibilität 'Vorbereitung' und 'Aufräumen' Knoten enthalten. Bei einem 'Testfallsatz' verhalten sich diese genau wie bei einem 'Test', d.h. 'Vorbereitung' und 'Aufräumen' Knoten werden vor und nach jedem im 'Testfallsatz' enthalten Test ausgeführt. Bei einem 'Testfall' werden hingegen 'Vorbereitung' und 'Aufräumen' nur einmal ganz zu Beginn und Ende ausgeführt. Enthält ein 'Testfallsatz' oder 'Testfall' Knoten sowohl 'Abhängigkeit' als auch 'Vorbereitung'/'Aufräumen' Knoten wir die 'Abhängigkeit' zuerst aufgelöst. 'Vorbereitung' und 'Aufräumen' haben keinen Einfluss auf den in Abschnitt 12.2 beschriebenen Stapel von Abhängigkeiten.

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.

		Abbildung 10.2:  'Packages' und 'Prozeduren'

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 8. 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 17.1 erklärt, wie Sie die Bibliothek direkt in Ihre Testsuiten einbinden.

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 ersten Buchstaben 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.

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

Sie sollten Tests in einzelnen Testschritten organisieren, wobei idealerweise jeder Testschritt einem QF-Test 'Prozedur' Knoten entspricht. QF-Test bietet daher 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]

Diese Methoden funktionieren auch für 'Bezug auf Abhängigkeit' Knoten bis auf das Tastaturkürzel.

Sie können Parameter von 'Prozeduren', 'Abhängigkeiten' oder 'Testfälle' automatisch mittels Kontextmenü und Auswahl von »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.

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' unter einem 'Testfall' konvertieren, dann erstellt QF-Test automatisch eine 'Prozedur' und fügt an Stelle der 'Sequenz' den entsprechenden 'Prozeduraufruf' ein.

Wie jede programmierähnlichen 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.

Basierend auf den 'Bemerkung' Attributen von 'Testfallsatz', 'Testfall', 'Package' und 'Prozedur' Knoten kann QF-Test 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 15 beschrieben.

Letzte Änderung: 23.04.2012 Copyright © 1999-2012 Quality First Software GmbH