Strukturierung¶

In diesem Kapitel sind Testschrittvorlagen zusammengefasst, mit deren Hilfe sich Testfälle strukturieren lassen, z.B. durch Gruppierung von Testschritten oder Kommentierung.

Block¶

Diese Testschrittvorlage dient der Gruppierung zusammenhängender Testschritte. Lange Sequenzen lassen sich damit deutlich übersichtlicher gestalten. Im Testfalleditor können die im Block enthaltenen Schritte über das „+“-Zeichen neben dem Block eingeblendet oder mittels „-“ ausgeblendet werden. Im Testreport werden alle Testschritte innerhalb des Blocks eingerückt dargestellt. Die Bewertung ergibt sich durch Akkumulation der Einzelbewertungen der enthaltenen Testschritte.

Der Block-Testschritt bietet die Möglichkeit, den Testfall zu beenden oder abzubrechen, wenn die Ausführung eines Testschritts innerhalb des Blocks fehlschlägt. Um das Verhalten eines Blocks zu definieren, muss der Abschnitt Bedingter Testabbruch im Dialog aufgeklappt werden. Als Bedingung wird die Menge von Bewertungen angegeben, die als Fehlschlagen zu interpretieren sind und zum Beenden oder Abbruch des Testfalls führen sollen. Die im Block enthaltenen Testschritte werden so lange ausgeführt, bis die Bewertung eines Testschritts die Bedingung erfüllt. Tritt dies ein, wird die Ausführung des Testfalls (Haupt-Package) noch im Block beendet bzw. abgebrochen. Das Verhalten entspricht dabei dem des Exit-Testschritts. Bei Abbruch wird der Block selbst und infolgedessen auch der Testfall mit ERROR bewertet. Beim Beenden wird die Bewertung des Blocks und des Testfalls hingegen nicht verändert.

Die Ursache bzw. eine Qualifizierung des Abbruchs (z.B. in Form einer vom Testmanagement auszuwertenden Bewertung) können als Abbruch-Code hinterlegt werden. Der Abbruch-Code wird in die Spalte „Wert“ im Testreport übernommen. Vordefinierte Abbruch-Codes lassen sich in der Datei verdictmappings.xml im Workspace hinterlegen und sind dann in der Drop-Down-Liste verfügbar. Falls ein Testmanagement-System eingerichtet ist, kann die Liste der Abbruch-Codes auch in den Testmanagement-Einstellungen konfiguriert werden. Außerdem ist es möglich, eine Abbruch-Bemerkung festzulegen, welche weitere Informationen über den Abbruch geben kann. Diese Information ist schließlich in der Kommentar-Spalte des Testreports sichtbar.

Abbruch-Code und Abbruch-Bemerkung werden (sofern vorhanden) in der Package-Zusammenfassung des Testberichts aufgelistet. Es kann für jedes Package jeweils nur einen Abbruch-Code und eine Abbruch-Bemerkung existieren. Werden im Testfall mehrere verschachtelte Blöcke verwendet, so kann über die Option „Abbruchinformationen der Kinder überschreiben“ gesteuert werden, welche Abbruch-Informationen schließlich im Report erscheinen. Angenommen ein Block-Testschritt liegt innerhalb eines weiteren und legt den Abbruch-Code „No Run Precondition“ und die Abbruch-Bemerkung „Hier ist ein Fehler unterlaufen“ fest. Ob diese Informationen im Testbericht erscheinen, hängt davon ab, ob im darüberliegenden Block ein Häkchen bei „Abbruchinformationen der Kinder überschreiben“ gesetzt wurde. Dieses Verhalten wird dabei nicht davon beeinträchtigt, ob ein Häkchen in „Testabbruch bei“ gesetzt wurde. Abbruchinformationen werden also auch dann überschrieben, wenn für den oberen Block kein expliziter Testabbruch konfiguriert wurde.

Der Haken Nutzeranweisung markiert den Block zum Vorlesen bei der interaktiven Ausführung. In der Tesfallübersicht wird der Block mit einem Lautsprecher gekennzeichnet. Nähere Informationen finden Sie im Kapitel zum interaktiven Testen.

Der Block-Testschritt bietet die Möglichkeit, die Spalteninhalte in verschiedenen Sprachen zu hinterlegen (siehe auch Packageübersetzung prüfen). Die aktuell verwendete Sprache kann unabhängig von der Programmsprache gewählt werden (siehe Testeditor) und wird durch das Flaggensymbol angezeigt.

Desweiteren können die aktuellen Werte von Variablen in die Einträge in Aktion / Name, Parameter und Erwartung / Wert übernommen werden. Dafür werden die Variablen in geschweiften Klammern geschrieben wie zum Beispiel {variablenName}. Diese Platzhalter werden dann zum Ausführungszeitpunkt mit den Werten der Variablen zu diesem Zeitpunkt ersetzt und im Ausführungsdialog sowie im Report entsprechend angezeigt. In der Detailanzeige des Blocks im Report stehen dann zusätzlich noch die ursprünglichen, nicht ersetzten, Ausdrücke. Bei der interaktiven Ausführung werden die ersetzten Ausdrücke vorgelesen und ermöglichen damit parametrierbare, vom bisherigen Verlauf des Testfalls abhängige, Anweisungen.

Sind beim Einfügen eines Blocks mehrere aufeinanderfolgende Testschritte markiert, so werden diese automatisch in den neu eingefügten Block verschoben.

Pre- und Postcondition¶

Manchmal ist es notwendig, verschiedene Arbeitsschritte vor bzw. nach dem eigentlichen Testfall auszuführen. Greift ein Test bspw. auf Größen eines Modells zu, muss dieses erst in einen bestimmten Zustand überführt werden. Nach dem Test sollte das Modell hingegen wieder in den Ausgangszustand gebracht werden, um Seiteneffekte auf andere Tests zu vermeiden.

Für diese Zwecke stehen die beiden Testschritte Precondition und Postcondition zur Verfügung. Diese sind besondere Block-Testschritte, deren Eigenschaften im Folgenden beschrieben werden.

Precondition¶

In der Precondition werden sämtliche Schritte durchgeführt, die zur Vorbereitung des Tests notwendig sind. Aus Sicht der Testfall-Spezifikation ist die Precondition daher kein Bestandteil des Testfalls, sondern stellt die Vorbedingung dar, unter welcher der Test ausgeführt werden darf. Nur wenn die Precondition erfolgreich abgearbeitet wurde, darf der Test ausgeführt werden. Je nachdem wie die Option Testabbruch bei gesetzt ist, wird der Testfall daher sofort abgebrochen, sobald ein Testschritt in der Precondition zu INCONCLUSIVE (optional), FAILED oder ERROR ausgewertet wurde.

Je nachdem wie die Option Bewertung überschreiben gesetzt ist, wird die Precondition mit ERROR bewertet, sobald die Bewertung der enthaltenen Testschritte INCONCLUSIVE (optional), FAILED oder ERROR ist. Ist die Bewertung aller enthaltenen Testschritte NONE oder SUCCESS, wird die Precondition mit NONE bewertet.

Alternativ kann die Einstellung Bewertung überschreiben auf Bewertung nicht überschreiben gesetzt werden. Dann erbt die Precondition (wie ein normaler Block-Testschritt) das Ergebnis ihrer Kinder (kann also bspw. auch SUCCESS werden).

Im Gegensatz zum normalen Block-Testschritt überschreibt die Precondition im Falle eine Abbruchs standardmäßig Abbruch-Code und -Bemerkung. Dieses Verhalten kann über die Option Abbruchinformationen der enthaltenen Testschritte überschreiben beeinflusst werden. Als Abbruch-Code kann ein beliebiger Python-Ausdruck verwendet werden. Außerdem kann eine Liste von vordefinierten Abbruch-Codes zur Verfügung stehen, wenn eine Verbindung zum Testmanagement-Service eingerichtet wurde. Weitere Informationen hierzu können dem Kapitel Konfiguration entnommen werden.

Postcondition¶

Die Postcondition stellt eine Liste von Arbeitsschritten dar, die nach der Testausführung abgearbeitet werden muss. Wenn das Häkchen Postcondition auch bei Abbruch ausführen gesetzt ist, wird diese Liste selbst dann abgearbeitet, wenn der Testfall explizit abgebrochen wurde. Dabei spielt es keine Rolle, ob der Abbruch durch eine manuellen Eingabe des Nutzers oder durch einen Testschritt ausgelöst wurde.

Die Bewertung der Postcondition verhält sich analog zu der der Precondition. Abhängig von der Option Bewertung der enthaltenen Testschritte überschreiben (NONE/ERROR) erfolgt die Bewertung anhand der enthaltenen Testschritte. Ist die Option gesetzt (Standardwert), wird die Postcondition bei einer Gesamtbewertung ihrer Kinder von NONE oder SUCCESS als NONE bewertet, bei etwas anderem wird die Bewertung zu ERROR. Soll die Bewertung der enthaltenen Testschritte nicht überschrieben werden, wird diese für die Postcondition übernommen. Ob sich dieses Ergebnis auch auf das globale Testergebnis auswirkt, hängt von der Option Wirkt sich auf Gesamtbewertung aus ab. Standardmäßig ist diese Option deaktiviert.

Einschränkungen¶

Die Precondition muss, sofern vorhanden, immer an erster Stelle des Packages stehen. Ist dies nicht der Fall, wird die Precondition im Testfall-Editor als fehlerhaft markiert und bei der Ausführung erscheint eine entsprechende Fehlermeldung im Testreport. Analog dazu darf die Postcondition immer nur an letzter Stelle des Packages stehen. Des Weiteren ist es nicht gestattet, Packages zu referenzieren, die über eine Pre- und/oder eine Postcondition verfügen.

Kommentar¶

Wählt man den Testschritt Kommentar aus, öffnet sich das Dialogfenster Kommentar.

Mit dieser Funktion kann der Testfall kommentiert und unterteilt werden. Die Kommentare werden im Testreport dokumentiert.

Die Eingabe kann als String, über Variablen oder durch eine Verknüpfung von beiden stattfinden. Wenn z. B. die Variable „TextVar“ den Wert "Hallo" enthält, ergibt der Ausdruck TextVar + " Welt" im Testreport: "Hallo Welt".

Über die Auswahl hinter Bewertung kann angegeben werden, ob der eigentlich bewertungslose Testschritt Kommentar, doch eine (statische) Bewertung enthalten soll. Dies kann hilfreich sein, um dem Nutzer die Angaben im Testreport hervorzuheben und ihm gleich zu zeigen, dass dieser Kommentar auf ein Soll-/Fehlverhalten hindeutet.

Nach der Bestätigung mit OK, wird der Testschritt in den Testfall eingefügt.

Todo¶

Dieser Testschritt stellt keinen Testschritt im eigentlichen Sinne dar. Vielmehr soll es daran erinnern, dass hier noch etwas erledigt werden muss. Es gleicht somit einem Kommentar, nur dass es bei der Ausführung immer mit FAILED bewertet wird, da an dieser Stelle noch Testschritte fehlen. Eine Zusammenfassung aller Todo-Schritte eines Packages erhält man im Tab Eigenschaften eines geöffneten Packages.