Logo QF-Test

Tutorial zur praktischen Einführung
in QF-Test

 

Gratis Testen  Download  Kaufen

Yann Spöri, QF-Test Entwicklung & Support

Die Beispiele, Demos und praktischen Übungen zu QF-Test verhelfen zu einem schnellen Start.

Yann Spöri,
Software Engineer, QFS

Uwe Klüh, Senior Sales Manager, QFS

Durchsuchen Sie die gesamte Dokumentation (Handbuch, Tutorial, Mailingliste, Standardbibliothek), indem Sie die Suchfunktion der Homepage nutzen.

Uwe Klüh, Sr. Sales Manager, QFS

Tutorial

1
Bearbeiten einer Beispiel Testsuite [30-45 Min]
1.1
Bevor wir anfangen

Beim ersten Start von QF-Test und/oder der zu testenden Anwendung über QF-Test kann eine Sicherheitswarnung der Windows-Firewall auftreten mit der Frage, ob Java geblockt werden soll oder nicht. Da QF-Test Netzwerkprotolle für die Kommunikation mit dem SUT (System under Test) nutzt, darf dies nicht geblockt werden, um das automatisierte Testen zu ermöglichen.

1.2
Starten von QF-Test und Laden einer Testsuite

Nach dem Starten von QF-Test laden Sie bitte unser erstes Beispiel. Dazu öffnen Sie den Dateiauswahl-Dialog über das Menü »Datei«-»Öffnen...« und wechseln nach qftest-4.1.6/doc/tutorial, welches sich unterhalb Ihrer QF-Test Installation befindet. Dort wählen Sie bitte die Datei Options.qft aus und öffnen diese. QF-Test präsentiert Ihnen die Testsuite wie im folgenden Bild dargestellt:

Abbildung 1.1:  Das Fenster der Testsuite Options.qft.

Der linke Bereich des Hauptfensters enthält eine Baumstruktur, welche die Testsuite repräsentiert. Rechts befindet sich die Detailansicht des Knotens, der im Baum gerade markiert ist. (Falls die Detailansicht bei Ihnen nicht zu sehen sein sollte, aktivieren Sie diese bitte über das Menü »Ansicht«-»Details anzeigen«.) Im unteren Fensterbereich befindet sich das Terminal, welches die Standardausgaben des zu testenden Clients protokolliert. Die Anzeige des Terminals kann mittels »Ansicht«-»Terminal«-»Anzeigen« kontrolliert werden. Mit Hilfe des Baumes können Sie durch die Testsuite navigieren und einzelne Knoten auswählen, für die dann jeweils die Details im rechten Fensterbereich eingeblendet werden.

Klicken Sie bitte doppelt auf den Knoten "Testfallsatz: Options", um ihn zu expandieren. Unser Testfallsatz enthält primär drei Testfälle: "Clickstream", "Text check" und "Selected test". Umgeben werden die Testfälle von einem "Vorbereitung"/"Aufräumen" Paar, welches ein sauberes System als Ausgangsbasis für die Testfälle garantiert.

Abbildung 1.2:  Der Inhalt des Knotens "Testfallsatz: Options".

In den folgenden Abschnitten werden wir Funktion und Zweck der einzelnen Knoten erklären.

1.3
Starten der Anwendung

Zuerst wollen wir den Vorbereitungsknoten genauer unter die Lupe nehmen. Expandieren Sie ihn dazu bitte, wie im folgenden Bild gezeigt.

Abbildung 1.3:  Der Knoten "Vorbereitung".

Es werden drei Kindknoten sichtbar:

  • "Java SUT Client starten" startet das zu testende Programm, das System Under Test. Wir kürzen es gerne mit SUT ab.
  • "Warten auf Client" wartet, bis die neue Java Virtual Machine, in welcher das SUT läuft, sich mit QF-Test verbindet.
  • "Warten auf Komponente" wartet auf das Erscheinen einer bestimmten Komponente des SUT, hier dem Hauptfenster des "Options" Dialogs. Damit kann davon ausgegangen werden, dass das SUT erfolgreich hochgelaufen und bereit für Tests ist. Der Umgang mit Komponenten und ihre Bedeutung werden später noch genauer erläutert.

Markieren Sie nun bitte den "Java SUT Client starten" Knoten, der zum Starten des SUT verwendet wird.

Abbildung 1.4:  Der Knoten "Start SUT client".

Wir wollen uns die Knotenattribute im rechten Fensterbereich genauer ansehen:

  • Im obersten Feld "Client" wird ein eindeutiger Bezeichner für unsere Testapplikation definiert. Er lässt sich frei wählen und wird im Weiteren immer wieder als Referenz gebraucht.
  • Das Feld "Ausführbares Programm" wird im vorliegenden Beispiel durch die Variable "${qftest:java}" repräsentiert. Dies entspricht dem Java Programm, das Sie während der Installation von QF-Test angegeben haben. Hier könnte aber auch eine volle Pfadangabe zu einer Java Virtual Machine stehen. Mittels des "Programm auswählen" Programm auswählen Knopfes lässt sich das Java Executable auch mit Hilfe eines Dateiauswahldialogs auswählen.
  • Das Feld "Verzeichnis" bezeichnet das Arbeitsverzeichnis des SUT. Hier wird Ihr Heimatverzeichnis verwendet.
  • Die "Klasse" enthält die Java Klasse unseres SUT, deren main() Funktion zum Starten aufgerufen wird.
  • Unter "Parameter" sehen Sie ein Kommandozeilenargument für das SUT, in dem die Sprache auf Englisch gesetzt wird. Zusätzlich wird der Classpath an das SUT durchgereicht. Das ist erforderlich, da eine eigene Klasse von QF-Test als SUT verwendet wird und somit ein entsprechender Classpath benötigt wird.
  • Die restlichen Felder werden für das folgende Beispiel nicht benötigt und sind deshalb leer. Ganz unten befindet sich noch ein Feld "Bemerkung", das Kommentare aufnehmen kann.

Wir wollen nun die Anwendung wirklich starten. Markieren Sie dazu bitte den Knoten "Vorbereitung", doch belassen Sie ihn aufgeklappt. Dann klicken Sie den Knopf "Wiedergabe" Play. Anschließend lässt sich der Ablauf in der Baumansicht verfolgen. Der gerade aktive Knoten wird während der Wiedergabe durch "->" markiert. Auch sehen Sie die Ausgaben des SUT Clients im Terminal.

Nach Abschluss der Startsequenz erscheint unsere Demoapplikation "Options Demo" am Bildschirm. Sie ist vollständig unter Kontrolle und den wachsamen Augen von QF-Test.

Hinweis Wenn das Options Demo auf Ihrem Bildschirm nicht zu sehen ist, oder nur kurzzeitig erscheint, dann befindet es sich vermutlich hinter dem Hauptfenster von QF-Test. Am besten positionieren Sie beide Fenster nebeneinander, so dass Sie beide zur gleichen Zeit sehen können. Sollten Sie einen Fehlerdialog erhalten, der darauf hinweist, dass sich QF-Test nicht mit dem SUT verbinden konnte, werfen Sie bitte einen Blick in das Handbuch Kapitel 3.1.3.

Abbildung 1.5:  Das "Options Demo".
1.4
Ein erster Testfall - Mausklick Sequenz

Als Nächstes wollen wir einen Blick auf einen ersten Testfall werfen. Der Testfallknoten "Clickstream" beinhaltet eine Sequenz von Mausklicks und das Ausfüllen von Textfeldern. Dadurch werden zwei einfache, aber grundlegende Möglichkeiten von QF-Test gezeigt.

Wenn Sie den Testfallknoten "Clickstream" öffnen, sehen Sie darin enthalten zwei Sequenzen:

Abbildung 1.6:  Der Testfallknoten "Clickstream" besteht aus zwei Sequenzen.

Um diese auszuführen, markieren Sie den "Clickstream" Testfallknoten und drücken den "Wiedergabe" Knopf Play. Die Testsequenzen werden nun automatisch im SUT abgespielt und sollten ohne Probleme durchlaufen.

Das Testergebnis wird während und nach dem Testlauf in der Statuszeile am unteren Rand des QF-Test Hauptfensters angezeigt und lautet "Keine Fehler". Daneben gibt es auch noch Zähler für Anzahl und Ergebnis der wiedergegebenen Testfälle. In unserem Fall war das nur einer, der fehlerfrei lief, was einer Erfolgsquote von 100% entspricht.

Hinweis Wenn Sie den Mauszeiger auf dem Symbol eines Testfallzählers ruhen lassen, wird Ihnen eine entsprechende Beschreibung angezeigt. Eine Auflistung aller Testfallzähler finden Sie im Kapitel Aufnahme und Wiedergabe des Handbuchs.

Um anschließend nachzuvollziehen, was wir während der Wiedergabe gesehen haben, werfen wir einen Blick in die Sequenz "Table" innerhalb des "Clickstream" Testfalls:

Abbildung 1.7:  Die Sequenz "Table" enthält Mausklicks und Texteingaben.

Dort sehen wir, dass die Sequenz von zwei Mausklicks eingeleitet wird. Sie sehen auch die Koordinaten der Klicks relativ zum Nullpunkt der dahinter angegebenen Komponente. Beim ersten Klick ist das z.B. der Baumknoten mit der Bezeichnung "Table" im JTree "OptionGroup-tree-Tree". Auf die Bedeutung der Syntax im Detail wird später eingegangen.

Nach den Mausklicks bewirkt der "Warten auf Komponente" Knoten, dass auf das Erscheinen eines Eingabedialogs gewartet wird, bevor im anschließenden Knoten "Texteingabe" der Text "String" in das Textfeld geschrieben wird. Den Rest der Sequenz sollten Sie nun alleine verstehen können. Werfen Sie ruhig auch einen Blick in die andere Testsequenz "Tab". Hier tauchen noch "Tastaturevent" Knoten als Neuigkeit auf.

1.5
Einige Tipps zwischendurch

Hier zwischendurch ein kleiner Tipp, wenn Sie z.B. bei einem Knotentyp nicht genau wissen, wofür er eingesetzt wird, oder auch die Bedeutung eines seiner Attribute nicht zuordnen können. QF-Test ist mit einer kontextsensitiven Hilfe ausgestattet. Bewegen Sie den Mauszeiger zu dem Element, für das Sie Hilfe wünschen und drücken Sie die rechte Maustaste. Es erscheint das Kontextmenü, bei dem es ganz unten den Eintrag »Was ist das?« gibt. Wenn Sie diesen auswählen, wird das entsprechende Kapitel im Referenzteil des Handbuches in Ihren Standardbrowser geladen. (Unix-Anwender können den Browser unter »Bearbeiten«-»Optionen...« im Bereich "Allgemein" einstellen.) So finden Sie schnell die benötigte Information. Probieren Sie es doch bitte gleich mal aus.

Wenn Sie nach einem Thema oder Stichwort suchen wollen, so empfehlen wir Ihnen dies in der PDF Version des Handbuchs zu tun. Die HTML Version ist dafür nicht so gut geeignet, da sie zur besseren Navigation in einzelne Seiten aufgeteilt ist. Auf jeder HTML Seite befindet sich auch eine Verknüpfung auf die PDF Version des Handbuchs, so dass der Übergang jederzeit leicht möglich ist.

1.6
Ein erster Check - Prüfen eines Textfeldes

Eines der wichtigsten Konzepte in QF-Test ist das der Checks, d.h. eine Überprüfung bestimmter Elemente im SUT. Ein "Text Check" prüft das Vorhandensein eines Textes in einer Textfeld-Komponente des SUT.

Als Beispiel für eine Überprüfung - einen Check - soll durch die nachfolgend beschriebene Sequenz die Beschriftung eines Textfeldes verifiziert werden.

Abbildung 1.8:  Der zu prüfende Labeltext "May be negative".

Wenn Sie in unserer Testapplikation "Option Demo" im Baum auf der linken Seite den "Miscellaneous" Knoten öffnen und darin den "Numbers" Knoten auswählen, sehen Sie auf der rechten Seite das zweite Textfeld mit dem Label "May be negative". Dieser Text soll geprüft werden.

Im folgenden Bild sehen Sie den zugehörigen Testfallknoten "Text check", im expandierten Zustand:

Abbildung 1.9:  Der Testfall "Text check".

Der Testfall besteht aus zwei Mausklicks zum Öffnen des "Miscellaneous" Knotens und Selektieren des Eintrags "Numbers". Anschließend wird ein "Check Text" Knoten benutzt, um den Labeltext zu überprüfen.

Wir haben den Label "May be negative" für das Textfeld aufgezeichnet, jedoch absichtlich den erwarteten Wert abgeändert. Sie können dies nachprüfen, indem Sie den Knoten "Check Text" in der Testsuite markieren. Die Detailansicht des Knotens zeigt, dass der erwartete Text "May be positive" anstatt "May be negative" lautet. Das wird beim Ablauf des Tests zu einem Fehler führen, was aber so gewollt ist, um Ihnen zu zeigen wie man damit umgeht.

Markieren Sie nun bitte den Testfall-Knoten "Check text" und führen Sie ihn aus. Ein Dialog erscheint nach dem Ablauf mit der Meldung "Es sind 0 Exceptions, 1 Fehler und 0 Warnungen aufgetreten".

Abbildung 1.10:  QF-Test meldet einen Fehler im Knoten "Check Text".

Zur weiteren Diagnose wollen wir uns das Protokoll ansehen. Wir können dazu direkt den Button "Protokoll anzeigen" drücken. Alternativ kann man das Protokoll in der Testsuite mittels »Wiedergabe«-»1. ...« oder der Tastenkombination [Strg-L] öffnen. Es wird in einem neuen Fenster angezeigt:

Abbildung 1.11:  Das Protokoll für die Wiedergabe des "Check Text" Knotens.

Das Protokollfenster ähnelt im Aufbau dem einer Testsuite. Der Baum auf der linken Seite repräsentiert nun aber die zeitliche Darstellung des Testlaufs. Die Zeitachse verläuft von oben nach unten. Analog zur Testsuite befindet sich auf der rechten Seite eine Detailansicht des jeweils ausgewählten Protokollknotens im Baum.

Was sofort auffällt, ist der rote Rahmen um den Wurzelknoten des Protokollbaumes. Er verrät uns, dass sich ein Fehler in einem der Kindknoten verbirgt. Die schnellste Methode, um den Fehler zu finden, bietet »Bearbeiten«-»Nächsten Fehler finden« bzw. [Strg-N]. Dies führt zu folgendem Bild:

Abbildung 1.12:  Diagnose des fehlgeschlagenen Checks "Check Text".

Die Detailansicht auf der rechten Seite zeigt die Abweichung zwischen erwartetem und gefundenem Text. Ein typischer Arbeitsschritt ist nun, ausgehend von dem Protokollknoten, in dem der Fehler aufgetreten ist, zurück in die Testsuite zu springen, um dort z.B. eine Anpassung im korrespondierenden Checkknoten vorzunehmen. Unter der Voraussetzung, dass der Fehler-Protokollknoten markiert ist, leistet hierbei »Bearbeiten«-»Knoten in Testsuite finden« bzw. [Strg-T] hervorragende Dienste. Eine Stufe weiter geht die Funktionalität des Protokollknotens mit dem Titel "Fehlgeschlagen: Check Text" in Abbildung 1.12, auswählbar über das Kontextmenü, das man über die rechte Maustaste öffnen kann: »Checkknoten mit erhaltenen Daten aktualisieren« bzw. [Strg-U].

Eine weitere Möglichkeit zur Fehlerdiagnose tritt in Erscheinung, wenn Sie den folgenden Knoten "Bildschirmabbild" auswählen. Dessen Detailansicht enthält ein vollständiges Abbild des Bildschirms zum Zeitpunkt, an dem der Fehler festgestellt wurde. Es kann eine große Hilfe sein, den Zustand des SUT in diesem Moment zu sehen, um die Ursache des Fehlers zu finden. Die folgende Grafik zeigt den Knoten:

Abbildung 1.13:  Bildschirmabbild zum Zeitpunkt des Fehlers.

Neben dem Abbild des gesamten Bildschirms speichert QF-Test auch Bilder der einzelnen Fenster des SUT. Für unser Beispiel ist dies der Knoten "Bildschirmabbild von Fenster: Option Demo". Diese sind dann hilfreich, falls das SUT durch eine andere Anwendung zum Fehlerzeitpunkt verdeckt ist.

HinweisDie in einem längeren Testlauf im Protokoll gesammelten Informationen können große Mengen an Arbeitsspeicher verbrauchen. Deshalb ist QF-Test so voreingestellt, dass es eine spezielle Form von kompakten Protokollen erstellt. Dabei werden nur die ca. letzten 100 Protokollknoten aufgehoben und der Rest verworfen. Informationen für Fehlerdiagnose und Reportgenerierung bleiben durchgängig erhalten. Diese Funktion ist mit der Option "Kompakte Protokolle erstellen" über »Bearbeiten«-»Optionen...«-»Protokoll«-»Inhalt« konfigurierbar. Der Typ eines Protokolls wird auch in seinem Wurzelknoten angezeigt. Auch die Anzahl der Bildschirmabbilder, die im Protokoll gespeichert werden, ist konfigurierbar.

Wenn Sie möchten, können Sie nun als kleine Übung den erwarteten Text im Knoten "Check Text" der Testsuite wie oben beschrieben korrigieren. Wenn Sie den Checkknoten in der Testsuite anschließend nocheinmal ausführen, sollte kein Fehler mehr gemeldet werden. Machen Sie bitte zum Schluss diese Änderung mittels »Bearbeiten«-»Rückgängig machen« bzw. [Strg-Z] wieder rückgängig, um für die weitere Testdurchführung eine einheitliche Ausgangsbasis zu gewährleisten.

1.7
Ein zweiter Check - Zustand eines Optionsfeldes prüfen

In der dritten Sequenz "Selected Test" werden wir überprüfen, ob sich ein Optionsfeld (Radio Button) im Zustand "ausgewählt" befindet. In der "Options Demo" Applikation kann man interaktiv eine Anzahl von Buttons auswählen. Wir werden dieses verwenden, um sowohl einen erfolgreichen Check zu kreieren, als auch einen Check, der zu einem Fehler führt.

Abbildung 1.14:  Der "Selected test" Knoten.

Der Knoten "Selected test" zeigt drei Mausklick Events und zwei Checks. Die ersten zwei Klicks bewirken ein Ausklappen des "Miscellaneous" Knotens im "Option Demo" Baum und das Auswählen des Eintrags "Choices". Danach überprüft der "Check boolean: selected" Knoten, dass sich der vierte Radio Button nicht im Zustand "ausgewählt" befindet. Der dritte Klick bewirkt ein Auswählen des vierten Radio Buttons und der zweite "Check boolean: selected" Knoten überprüft erneut, dass sich dieser Button nicht im Zustand "ausgewählt" befindet. Das ist natürlich ein Widerspruch, so dass der letzte Check offensichtlich zu einem Fehler führen wird.

Abbildung 1.15:  Check von Auswahlfeldern im "Options Demo".

Sie können nun die Check Knoten im Detail ansehen und die Sequenz auch starten. Achten Sie gegebenenfalls darauf, den "Miscellaneous" Knoten wieder zu schließen, wenn Sie die Sequenz als Ganzes laufen lassen möchten.

1.8
Beenden der Applikation

Die Aufräumsequenz wird (wie auch die Vorbereitungssequenz) nach jedem Testfall innerhalb des umschließenden Testfallsatzes ausgeführt. Sie dient dazu, die Applikation nach dem Ausführen eines Tests in einen spezifischen Zustand zu versetzen, welcher die Basis für den darauf folgenden Test bildet. Die Aufräumsequenz ist vergleichbar mit "tear-down" Methoden in Unittests.

Die Aufräumsequenz "Stop the application" versucht die Applikation auf saubere Art und Weise zu stoppen. Dazu wird der "Cancel" Button des "Options Demo" gedrückt. Wenn dies nicht nicht den gewünschten Erfolg bringt, wird das Beenden auf die "harte Tour" vollzogen.

Abbildung 1.16:  Die Aufräumsequenz "Stop the application".

  • Den Rahmen bildet ein Konstrukt aus einem "Try" und einem "Catch" Knoten.
  • Der "Warten auf Programmende" Knoten prüft ob das "Options Demo" wirklich terminiert, falls nicht, wird eine "ClientNotTerminatedException" ausgelöst.
  • Diese wird vom "Catch" Knoten gefangen.
  • Dann beendet ein Knoten "Programm beenden" den Client auf harte Weise.

Wir haben in diesem Test einen eher "defensiven" Aufräumknoten implementiert. Darin versuchen wir zuerst die Applikation konventionell zu beenden und nur wenn dies fehlschlägt, wird der Prozess beendet.

1.9
Alles in einem Rutsch

In den vergangenen Abschnitten haben wir uns Schritt für Schritt durch die einzelnen Bereiche unserer Beispieltestsuite gearbeitet. Nun ist es an der Zeit die gesamte Suite in einem Rutsch als Ganzes ausführen zu lassen. Das könnte in der Praxis einem Regressionstest entsprechen, dem wir unser SUT unterziehen wollen.

Schließen Sie bitte das "Options Demo", falls es aktuell läuft. Nun können Sie den Testfallsatz "Options" markieren und ihn ausführen. Der Testlauf dauert eine knappe Minute. Dies liegt unter anderem an einer Verzögerung, die wir zur besseren Nachvollziehbarkeit eingebaut haben. Sie sehen in den Details des Testfallsatzknotens unter Standardwerte eine Variable "delay", die auf 500 ms definiert ist. Wenn Sie diesen Wert reduzieren, können Sie den Testlauf beschleunigen. Der Test endet mit den bekannten zwei Fehlern.

Wenn Sie sich nun bitte das Protokoll ansehen, sehen Sie wie QF-Test den Test abarbeitet.

Abbildung 1.17:  Das Protokoll des gesamten Testfallsatzes "Options".

Hier sieht man auch noch einmal die bereits erwähnte Eigenschaft des Testfallsatzknotens, dass vor jedem darin enthaltenen Test jeweils die Vorbereitungssequenz und danach jeweils die Aufräumsequenz abgearbeitet wird. Dadurch wird immer ein sauberer Ausgangszustand sichergestellt.

1.10
Reportgenerierung

Im Qualitätssicherungsprozess ist es wichtig, Testergebnisse zu dokumentieren und auch zu archivieren. QF-Test bietet die Möglichkeit, aus Protokollen Testreports zu generieren. Wir wollen dies für das gerade aufgezeichnete Protokoll beispielhaft durchführen.

Die Reportgenerierung kann im Protokollfenster über »Datei«-»XML/HTML Report erstellen...« angestoßen werden. Es erscheint ein Dialog zur weiteren Auswahl möglicher Parameter:

Abbildung 1.18:  Auswahldialog für die Reportgenerierung.

Im ersten Feld können Sie den Dateinamen des Reports festlegen. QF-Test bietet zwei Arten von Reports - einen einfachen HTML Report und einen XML Report. Die XML Form kann der Anwender als Grundlage verwenden und sie mit Hilfe selbst geschriebener XSLT Stylesheets in einen beliebigen eigenen Report transformieren.

Es gibt weitere Optionen um die Behandlung von HTML und Doctags in Kommentarfeldern und das Anzeigen des Reports nach der Generierung in einem Browser zu steuern. Sie können die Felder einfach unverändert belassen. Weitere Details finden Sie bei Bedarf im Kapitel Reports und Testdokumentation des Anwenderhandbuchs.

Wir wollen uns nun einen einfachen HTML Report zu unserem letzten Testlauf erzeugen lassen. Bestätigen Sie bitte den Dialog zur Reportgenerierung (nach einem eventuellen Anpassen der Optionen) mit "OK". Anschließend sollte sich automatisch Ihr Browser mit einem Ergebnis äquivalent zum folgenden Bild öffnen:

Abbildung 1.19:  Ein HTML Report.

Der Testbericht beginnt mit einer Zusammenfassung, mit allgemeinen Systeminformationen im linken Bereich, einer Legende mit der Bedeutung der verwendeten Symbole rechts und dem Gesamtergebnis darunter. In unserem Fall sind es die bekannten zwei Fehler.

Auf die Zusammenfassung folgt eine Fehlerübersicht, welche alle Fehler auflistet, inklusive Ort des Auftretens (den Testfall) und beschreibender Fehlermeldung. Teil drei bildet eine Übersicht der Testfallsätze, die hier nur den "Options" Testfallsatz enthält, da unsere Testsuite nur diesen enthält. Zum Schluss werden alle Testfälle des "Options" Testfallsatzes mit den zugehörigen Details, wie Beschreibung, Ergebnis und Laufzeit, aufgelistet.

Die Reporterstellung in QF-Test ist ein praktisches Hilfsmittel, um einen Überblick über einen Testlauf zu gewinnen und ein Dokument zu Präsentations- und Archivierungszwecken zu erstellen.

Videos Downloads Dokumentation Kaufen Gratis Testen