Handbuch

Nach einem automatischen Testlauf ist das Protokoll bzw. der erstellte Report dieser Ausführung ein guter Einstiegspunkt um sich ein Bild von den Testergebnissen zu machen. Sind Fehler aufgetreten, stellt sich für Sie als Anwender oft die Herausforderung die fehlgeschlagenen Testfälle nochmals auszuführen, um das Fehlverhalten zu analysieren oder nach einer erfolgten Fehlerbehebung diesen Testfall nochmals offiziell nachzutesten. Eventuelle Nachtestergebnisse könnten bei Bedarf auch im Report angezeigt werden und zwar wahlweise zusätzlich oder an Stelle des fehlerhaften Ergebnisses des vorherigen Laufs. In manchen Fällen kann es auch einfach vom Interesse sein, einige Testfälle nochmals gezielt mit dem Variablenstand vom vorigen Lauf anzustoßen und die vorherigen Protokolle unangetastet zu lassen.

Genau hierfür bietet QF-Test nun die Möglichkeit, direkt aus dem Protokoll heraus Testfälle nochmals auszuführen. Dies erreichen Sie, indem Sie den Protokoll-Knoten oder die gewünschten Testfallsatz Knoten selektieren und die Menüaktion »Testfälle nochmal ausführen« im Menü »Bearbeiten« oder über das Kontextmenü auswählen. Alternativ können sie die Testfälle aus der Fehlerliste über den Kontextmenüeintrag »Testfälle der selektierten Knoten nochmal ausführen« auswählen. Im daraufhin erscheinenden Dialog können Sie die nochmal auszuführenden Testfälle auswählen sowie in der Auswahlbox Protokollmodus bestimmen, ob die Ergebnisse dieser Wiederholung in das originale Protokoll des Laufes eingepflegt werden sollen oder nicht. Es werden folgende Auswahlmöglichkeiten geboten:

		Abbildung 20.1:  Dialog zur Wiederausführung von Testfällen

Diese wiederholte Ausführung verwendet für jeden Testfall dessen Variablenstände aus dem vorherigen Protokoll. Die Variable ${qftest:isInRerunFromLog} erhält für eine solche Wiederholung den Wert true, womit im Test zwischen normalem Lauf und Wiederholung unterschieden werden kann.

HinweisDie Zusammenführung der Protokolle basiert zur Zeit auf den Namen der Testfälle und Testfallsätze. Daher müssen deren Namen eindeutig sein. Im Falle von datengetriebenen Testen sollten Sie darauf achten, dass Sie diese Eindeutigkeit der Namen über die Attribute 'Name für separates Protokoll' bzw. 'Charakteristische Variablen' herstellen.

Während der Testautomatisierung kann es vorkommen, dass Testschritte sich volatil verhalten und manchmal das richtige Ergebnis liefern aber in anderen Fällen scheitern. Meist sind solche Fälle abhängig vom Timing und können in QF-Test mit 'Warten auf Komponente' Knoten oder Checks auf Zustände, mit Skripten, Verzögerungen oder Kontrollstrukturen stabilisiert werden. Alternativ oder zusätzlich ermöglicht QF-Test es Ihnen, solche Knoten im Fehlerfall automatisch nochmals auszuführen.

Für die Art der automatischen Ausführung im Fehlerfall können Sie bei jedem ausführbaren Knoten in der Testsuite einen Doctag im Attribut 'Bemerkung' verwenden. Dieser Doctag kann im Wesentlichen wie folgt aussehen:

@rerun attempts=3;errorlevel>=ERROR;newerrorlevel=WARNING;
          handler=handlers.errorhandler
        

Das obige Beispiel bedeutet, dass ein Knoten im Falle eines Fehlers oder einer Exception maximal dreimal wiederholt wird bis kein Fehler und keine Exception mehr auftreten. Die Versuche, die mit Fehler oder Exception endeten, werden im Protokoll als Warnung markiert und nicht mehr als Fehler. Nach jedem Versuch, der mit Fehler oder Exception endet, wird die Prozedur handlers.errorhandler aufgerufen. Besteht nach dem dritten Versuch immer noch ein Fehler oder eine Exception, so wird dieser letzte Zustand protokolliert.

Falls Sie den aktuellen Versuch des Reruns herausfinden möchten, können Sie die Variable reruncounter aus der qftest Variablengruppe verwenden, siehe Abschnitt 7.5.

Für das @rerun Doctag können verschiedene Parameter wie attempts oder errorlevel mit folgender Bedeutung verwendet werden:

attempts

Die maximale Anzahl der Wiederholungen.

errorlevel (optional)

Gibt an, auf welche Arten von Fehlverhalten reagiert werden soll. Hier können Sie entweder die Fehlerstufen EXCEPTION, ERROR oder WARNING angeben, entweder exakt (mit =) oder mit > oder >=. Mit errorlevel=ERROR wird der Knoten nur bei Fehlern neu ausgeführt wird, bei errorlevel>=ERROR bei Fehlern und Exceptions. Falls Sie nichts angeben wird der Wert errorlevel>=ERROR als Standard herangezogen.

newerrorlevel (optional)

Legt die Fehlerstufe für die Protokollierung des initialen Laufs und eventueller weiterer fehlgeschlagener Versuche fest. Zulässige Werte sind wiederum EXCEPTION, ERROR oder WARNING sowie zusätzlich NOLOG und KEEP. Die Stufe NOLOG bedeutet, dass die fehlerhaften Versuche aus dem Protokoll gelöscht werden, so dass nur der letzte Versuch im Protokoll auftaucht. Der Wert NOLOG sollte mit großer Vorsicht eingesetzt werden. Der Wert KEEP gibt an, dass die originalen Fehlerstufen im Protokoll behalten werden. Falls Sie nichts angeben wird der Wert WARNING als Standard herangezogen.

handler (optional)

Definiert den Namen einer Prozedur, welche aufgerufen werden soll, falls das Fehlverhalten auftritt. Diese Prozedur wird nach jedem fehlgeschlagenen Durchlauf ausgeführt.

reusevariables (optional, default=true)

Hier geben Sie an, ob der Variablenstand vom Beginn des ersten Durchlaufs wiederverwendet werden soll. Steht der Parameter auf false wird der aktuelle Variablenstand genutzt.

logmessages (optional, default=true)

Ist dieser Parameter auf true gesetzt, wird am Anfang eines jeden Versuchs sowie nach erfolgreicher bzw. fehlerhafter Ausführung eine Nachricht in das Protokoll geschrieben. Zusätzlich wird bei jedem Versuch eine Anmerkung im Protokoll für diesen Knoten gesetzt.

logmessagesintoreport (optional, default=true)

Ist dieser Parameter und der Parameter logmessages auf true gesetzt, werden die Meldungen auch in den Report geschrieben.

keepfirst (optional, default=false)

Falls dieser Wert auf true gesetzt wird, wird das erste gefangene Fehlerverhalten mit dem Originalzustand protokolliert. Im Falle von weiteren Fehlern wird der Parameter newerrorlevel herangezogen.

exceptiontype (optional)

Falls Sie einen speziellen Exceptiontype fangen wollen, können Sie diesen Typ hiermit angeben, z.B. CheckFailedException oder nur ClientNotConnected für eine ClientNotConnectedException. Dieser Parameter sollte nur verwendet werden, wenn Sie Exception als Wert für errorlevel gesetzt haben. Details zu Exceptions finden Sie beim 'Catch' Knoten.

exceptionmessage (optional)

Falls Sie eine bestimmte Exception mit bestimmter Nachricht abfangen wollen, können Sie diese Nachricht hier angeben. Dieser Parameter sollte nur verwendet werden, wenn Sie Exception als Wert für errorlevel gesetzt haben. Details zu Exceptions finden Sie beim 'Catch' Knoten.

exceptionregex (optional)

Wenn dieser Wert true ist, dann stellt der Parameter exceptionmessage einen regulären Ausdruck dar. Dieser Parameter sollte nur verwendet werden, wenn Sie Exception als Wert für errorlevel gesetzt haben und einen Wert für exceptionmessage angegeben haben. Details zu Exceptions finden Sie beim 'Catch' Knoten.

exceptionlocalized (optional)

Wenn dieser Wert true ist, dann steht der Parameter exceptionmessage für die lokalisierte Fehlermeldung der Exception. Dieser Parameter sollte nur verwendet werden, wenn Sie Exception als Wert für errorlevel gesetzt haben und einen Wert für exceptionmessage angegeben haben. Details zu Exceptions finden Sie beim 'Catch' Knoten.

Letzte Änderung: 19.03.2019 Copyright © 1999-2019 Quality First Software GmbH