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

2
Erstellen einer eigenen Testsuite [45-60 Min]
2.1
Einführung

Dieses Kapitel wird Sie durch die Schritte führen, die notwendig sind, um Ihre erste eigene Testsuite zu erstellen. Die zu testende Applikation wird das "FileChooserDemo" sein, welches Teil des Java Software Development Kit's ist. Zur Sicherheit haben wir es jedoch (inklusive Source-Code) auch in der vorliegenden Distribution von QF-Test im Verzeichnis qftest-4.1.6/doc/tutorial/FileChooserDemo mitgeliefert.

Das "FileChooserDemo" ist eine sehr schöne Demonstration dafür, wie die Klasse "FileChooser" in Swing angepasst werden kann, um einen spezifischen Dialog zum "Öffnen", "Schließen", "Sichern" etc. für die eigene Applikation zu erzeugen. Wir werden es im Folgenden als SUT benutzen, um dafür eine eigene Testsuite für QF-Test zu erstellen.

Dieser Teil des Tutorials erläutert folgende Schritte: Starten des SUT in QF-Test. Aufnehmen und Organisieren eines einfachen Tests. Erstellen eines Tests, welcher eine kausale Abhängigkeit von Funktionen (Geschäftslogik) in der Applikation überprüft.

2.2
Starten der Anwendung

Öffnen Sie bitte eine neue, leere Testsuite mittels »Datei«-»Neue Testsuite...«. Bitte beachten Sie, dass die "alte" Testsuite in einer getrennten Registerkarte geöffnet bleibt.

Stellen Sie bitte sicher, dass die Detailansicht aktiv ist (»Ansicht«-»Details anzeigen«). In der linken Ebene des zweigeteilten Bildschirms sehen Sie den Baum, welcher die Testsuite repräsentiert. Für den dort gerade ausgewählten Knoten werden auf der rechten Seite die Attribute im Detail angezeigt.

Zu Beginn jedes Tests muss die zu testende Applikation gestartet werden. Im vorliegenden Fall soll dies das "FileChooserDemo" aus dem Java Software Development Kit sein. bereits aus dem vorigen Kapitel kennen. Wir werden den Schnellstart-Assistenten benutzen, um eine entsprechende Startsequenz zu erzeugen.

Öffnen Sie bitte den Schnellstart-Assistenten über das »Extras« Menü oder alternativ über den Aufnahmeknopf, wenn dieser noch das Fragezeichen zeigt. Der Assistent sollte Sie entsprechend dem folgendem erklärenden Text begrüßen. Nach einem kurzen Hallo drücken Sie bitte den "Weiter" Knopf.

Abbildung 2.1:  Der Schnellstart-Assistent.

Hier kann der Typ der zu testenden Applikation ausgewählt werden. Selektieren Sie bitte "Ein Java Archiv (java -jar <archive>)" und gehen Sie weiter.

Abbildung 2.2:  Auswählen des SUT Typs.

Nun werden Sie nach dem Java Programm gefragt. Sie können einfach den vorgeschlagenen Wert ${qftest:java} belassen, welcher bedeutet, dass das Java benutzt wird, mit dem QF-Test selbst läuft. Sie können also einfach weiter gehen zum nächsten Schritt im Assistenten.

Abbildung 2.3:  Angabe des Java Programms.

Der nächste Schritt ermöglicht die Angabe eines Arbeitsverzeichnisses für die Anwendung. Da unser Demo kein solches benötigt, können Sie einfach weitergehen.

Abbildung 2.4:  Arbeitsverzeichnis.

Nun ist es Zeit das Java Archiv anzugeben. Für unser Beispiel wird es das FileChooserDemo.jar im Verzeichnis doc/tutorial/FileChooserDemo Ihrer QF-Test Installation sein. Sie können die Datei über den "Verzeichnis auswählen" Knopf Verzeichnis         auswählen oberhalb des Feldes komfortabel auswählen oder direkt als Text im Feld eingeben. Eine weitere Möglichkeit (die unter Windows und Unix funtioniert) ist ${qftest:dir.version}/doc/tutorial/FileChooserDemo/FileChooserDemo.jar zu verwenden, wobei der erste Teil eine Variable ist, die zum versionsspezifischen Installationsverzeichnis von QF-Test expandiert.

Abbildung 2.5:  Auswahl der Jar Datei.

Den nächsten Schritt der optionalen SWT Intrumentierung können Sie einfach mit "Weiter" überspringen, da unser FileChooserDemo Beispiel nicht auf SWT sondern auf Swing basiert.

Abbildung 2.6:  SWT Instrumentierung.

Fast haben wir es geschafft. Bleibt noch die Vergabe eines Namens als Referenz für unseren Client. Wir wollen ihn, nicht ganz unerwartet, "FileChooserDemo" nennen.

Abbildung 2.7:  Name des Clients.

Zu guter Letzt gibt es einige Informationen, was wir zu erwarten haben, wenn der Assistent nun seine Aufgabe, eine Startsequenz zu erzeugen, abschließt und wo es Hilfe gibt im Fall von Problemen. Deaktivieren Sie bitte noch die "Automatisch starten" Option, da wir zuerst einen Blick auf die erzeugte Startsequenz werfen wollen. Nun drücken Sie bitte den "Fertig" Knopf.

Abbildung 2.8:  Abschließende Informationen.

Die generierte Startsequenz erscheint in den "Extrasequenzen" und enthält drei Schritte:

  • Globale Client Variable setzen
  • Java SUT starten
  • Warten auf die Verbindung des Clients
Abbildung 2.9:  Generierte Startsequenz

Sie können einen Blick auf die Details der Knoten werfen und werden im wesentlichen die Werte, die Sie während der einzelnen Schritte im Assistenten eingegeben haben, den entsprechenden Knotenattributen zugewiesen finden.

Nun wollen wir die Sache in Aktion sehen. Stellen Sie bitte sicher, dass der Knoten "Vorbereitung" ausgewählt ist und drücken Sie den Wiedergabe Knopf oder betätigen einfach die Zeilenvorschub-Taste [Return]. Im folgenden Bild ist das Fenster des SUT Client dargestellt, das nun erscheinen sollte.

Abbildung 2.10:  Das Fenster des "FileChooserDemo".

Sollte bei Ihnen das Fenster nach einigen Sekunden nicht erscheinen, lohnt ein Blick auf das Terminal, welches u.a. Ausgaben über Fehlermeldungen beim Programmstart enthält.

2.3
Hinzufügen einer Mausklick Sequenz

Wir werden nun einen recht einfachen Test in Form einer Mausklick Sequenz hinzufügen. Drücken Sie dazu den "Aufnahme" Aufnahme Knopf und wechseln Sie zum Fenster der "FileChooserDemo" Applikation. Von jetzt ab wird jede Maus- oder Tastaturaktion aufgenommen. Drücken Sie bitte auf einige Buttons und wechseln Sie anschließend zurück zum QF-Test Fenster. Drücken Sie dort den Stop Knopf. Sie finden die aufgenommene Sequenz unter dem "Extrasequenzen" Knoten, wie im folgenden Bild dargestellt.

Abbildung 2.11:  Der Baum nach Aufnahme der Mausklick Sequenz.

Als Namen wird standardmäßig Datum und Zeit der Erstellung verwendet. Dieser kann anschließend beliebig verändert werden. Um nun die von Ihnen erzeugte Sequenz abzuspielen, markieren Sie diese und drücken auf Play. Der Ablauf der Mausklick Sequenz im SUT sollte sich nun wiederholen. Diese Form des Tests ermöglicht z.B. auch die automatische Demonstration einer Applikation.

In der Testanwendung wird in den meisten Fällen jedoch lediglich die zugrundeliegende Swing Implementierung der Fenster-Komponenten getestet und weniger die Geschäftslogik Ihres Programms. Im letzten Abschnitt dieses Kapitels werden wir Tests entwickeln, die den Inhalt eines Textfeldes prüfen und eine kausale Verbindung (Geschäftslogik) im "FileChooserDemo" behandeln.

Davor wollen wir jedoch aus dem Inhalt unserer Spielwiese "Extrasequenzen" eine richtige Testsuite strukturieren.

2.4
Strukturieren einer Testsuite

Die Basisstruktur unterhalb des Wurzelknotens einer Testsuite ist durch folgende Knoten festgelegt:

  • Eine beliebige Anzahl von "Testfallsatz" und "Testfall" Knoten, um funktionale Tests zu spezifizieren und zu strukturieren.
  • "Prozeduren" - hier können wiederverwertbare Sequenzen in Prozeduren organisiert werden
  • "Extrasequenzen" - unsere Spielwiese für Aufnahmen etc.
  • "Fenster und Komponenten" - das eigentliche Herz der Testsuite. Hier sind alle aufgenommenen Fenster und Komponenten des SUT mit ihren Eigenschaften enthalten

Funktionale Testfälle werden durch "Testfall" Knoten repräsentiert und mittels "Testfallsatz" Knoten gruppiert und strukturiert. "Vorbereitung" und "Aufräumen" Knoten können Aktionen enthalten, um einen wohldefinierten Zustand vor und nach einem Testfall sicher zu stellen.

Ein mögliches "Vorbereitung/Aufräumen" Paar ist das Starten und Beenden des SUT selbst, was einen definierten Status sicherstellt. Dieser Mechanismus kann auf jeder Ebene verwendet werden, z.B das Öffnen und Schließen eines Dialogs.

Wir beginnen mit dem Umbenennen des "Testfallsatz" Knotens von "unbenannt" in "FileChooser Tests". Den erscheinenden Dialog bzgl. dem Aktualisieren von Verweisen können wir einfach mit 'Ja' beantworten.

Der zweite Schritt ist, den vom Schnellstart Assitenten erzeugte Knoten "Vorbereitung" in den "Testfallsatz" zu verschieben, und zwar vor den enthaltenen Testfall. Das Verschieben kann mit Hilfe der Maus (Drag&Drop), des Kontextmenüs (rechte Maustaste Ausschneiden/Einfügen) oder der Tastenkombination [Strg-X] und [Strg-V] durchgeführt werden.

Hinweis Bei Drag&Drop kann der Zielknoten aufgeklappt werden, indem man den Mauszeiger über dem "+" links vom Zielknoten verweilen lässt.

Der Vobereitungssequenz kann man noch eine spezifischere Beschreibung geben, a la "FileChooserDemo starten".

Abbildung 2.12:  Beginn der Strukturierung.

Ein Punkt fehlt noch zur Komplettierung des "Vorbereitung" Knotens: Nachdem sich das SUT bei QF-Test angemeldet hat, kann es noch eine Weile dauern, bis das erste Fenster auf dem Bildschirm erscheint. Es muss sichergestellt sein, dass der eigentliche Test nicht vorher beginnt, daher muss an dieser Stelle auf das Erscheinen des Fensters gewartet werden.

Fügen Sie zu diesem Zweck einen "Warten auf Komponente" Knoten ein. Sie finden diesen unter »Einfügen«-»Diverse Knoten«-»Warten auf Komponente«. Wenn das SUT noch läuft, sollte das "Client" Attribut bereits vorbelegt sein, in unserem Fall mit dem Wert "$(client)". Um die 'QF-Test component ID' festzulegen, klicken Sie auf den Komponente         auswählen Button oberhalb des Textfeldes. Wählen Sie in dem daraufhin erscheinenden Dialog mit den aufgezeichneten Fenstern und Komponenten den Knoten "JFrame frameFileChooserDemo".

Abbildung 2.13:  Dialog zur Auswahl einer Komponente

Das Ergebnis sollte nun dem folgenden Bild entsprechen. Sie können jetzt das SUT beenden und durch Ausführen des kompletten "Vorbereitung" Knotens neu starten.

Abbildung 2.14:  Vorbereitungssequenz für das FileChooserDemo.

Als Nächstes gilt es, einen Testfall aus der vorher aufgezeichneten Clickstream Sequenz zu machen. Dazu müssen wir letztere aus den "Extrasequenzen" in den unbenannten Testfall verschieben. Den "Testfall" müssen Sie öffnen, bevor der "Sequenz" Knoten hineingeschoben werden kann. Den Testfall wollen wir zu 'Clickstream' umbenennen, die Sequenz zu 'Einige Clicks'.

Zum Schluss erzeugen wir eine "Aufräumen" Sequenz, um die Applikation zu beenden. Sie besteht aus zwei Schritten: Einer, den Client zu beenden und ein zweiter, um sicher zu stellen, dass er auch wirklich terminiert wurde. Führen Sie bitte selbstständig diese kleine Aufgabe durch. Wenn Sie fertig sind, werfen Sie zum Vergleich bitte einen Blick auf die nachfolgende Grafik.

Abbildung 2.15:  Der Baum nach der Neustrukturierung.

Damit haben wir die wichtigsten Schritte zur Strukturierung unserer Testsuite abgeschlossen. Im folgenden Abschnitt werden wir einen "Check" aufnehmen, um den Inhalt eines Textfeldes zu überprüfen.

2.5
Überprüfen eines Textfeldes

Um das Verhalten des Clients zu überprüfen, verwenden wir "Check" Knoten. Wir werden zuerst einen Check aufnehmen und verifizieren, dass ein Textfeld den erwarteten String beinhaltet. Der Check soll auf den Text eines Buttons im FileChooser Fenster angewendet werden.

Wenn der SUT Client noch nicht läuft, so starten Sie ihn bitte und beginnen Sie mit der Aufnahme. Im FileChooserDemo drücken Sie den "Show FileChooser" Button.

Um den Check aufzunehmen benützen Sie den "Check aufnehmen" Check aufnehmen Knopf in QF-Test und wechseln wieder zum SUT. Wenn Sie sich jetzt dort mit dem Mauszeiger über Komponenten bewegen, werden diese blau umrahmt, was die aktuelle Auswahl signalisiert.

Bewegen Sie bitte die Maus zum "Öffnen" Knopf und betätigen Sie die rechte Maustaste, um einen Check aufzunehmen. Das Menü beinhaltet eine Auswahl möglicher Standard-Checks für den Button. Die folgende Abbildung zeigt die Situation:

Abbildung 2.16:  Aufnahme eines Checks im FileChooser Fenster.

Wählen Sie bitte den "Text" Check aus und beenden Sie danach die Aufnahme mit Stop.

Danach nehmen Sie eine beliebige neue Mausklick Sequenz auf und schließen dann das FileChooser Fenster.

Hinweis Anstatt für die Aktivierung des Checkmodus zurück in die Testsuite zu springen, um den Check aufnehmen Knopf zu drücken, können Sie auch einfach im SUT bleiben und die Taste [F12] verwenden. Sie aktiviert/deaktiviert den Modus zum Aufnehmen von Checks.

Sie sollten nun die Kenntnisse besitzen, um die aufgenommenen Sequenzen in einem "Testfall" organisieren zu können. Ihr Ergebnis können Sie mit unserer folgenden Lösung vergleichen. Hierbei haben wir zusätzlich Sequenzen in "Testschritt" Knoten konvertiert, womit sie genauer spezifiziert sind und auch im Report sichtbar werden.

Abbildung 2.17:  Der Baum nach Aufnahme und Organisieren des "Text check" Testfalls.

Hinweis Knoten konvertieren kann man sehr einfach über den Menüpunkt »Operationen«»Knoten konvertieren in« oder über das Kontextmenü des Knotens.

Wir wollen nun einen ersten richtigen Testlauf mit unserer neuen Suite durchführen. Beenden Sie dazu nun bitte den SUT Client und markieren den 'FileChooser Tests' Testfallsatz. Führen Sie diesen durch Drücken von "Wiedergabe" Play oder der [Return] Taste aus.

Das Ergebnis des Testlaufs wird im "Protokoll" festgehalten. Um dieses anzuschauen, können wir direkt den Button "Protokoll anzeigen" nutzen.

HinweisAus einer Testsuite heraus kann das letzte Protokoll über den Letztes Protokoll öffnen Button in der Werkzeugleite geöffnet werden oder auch über das Menü »Wiedergabe«-»1. ...« mit der alternativen Tastenkombination [Strg-L].

Abbildung 2.18:  Der Protokollbaum zum eigenen Testfallsatz.

Im Protokoll wird nochmal deutlich, dass die Knoten "Vorbereitung" und "Aufräumen" vor bzw. nach jedem Testfall ausgeführt werden, um für definierte Zustände zu sorgen.

Hinweis Das Starten und Beenden der zu testenden Anwendung vor und nach jedem Testfall ist zwar ein sicherer Weg zum Herstellen sauberer Ausgangsbedingungen, jedoch auch ein zeitaufwendiger. In der Regel wird man versuchen das SUT nur einmal zu starten und durch andere Methoden einen definierten Ausgangszustand sicherzustellen.

In diesem Testlauf traten keine Fehler oder Exceptions auf. Aber Sie sehen gelbe Rahmen um einige Knoten im Protokollbaum, welche auf Warnungen hinweisen. Im Fall des FileChooser's werden sie durch Komponenten hervorgerufen, denen keine Namen zugewiesen sind. Wir möchten an dieser Stelle nicht weiter auf diese Warnungen eingehen, aber Sie finden ausführliche Informationen zur Wichtigkeit von Komponentennamen im Handbuch.

Beim Schließen des Protokolls wird gefragt, ob Sie speichern möchten, da es nur solange verfügbar ist, bis QF-Test beendet wird.

Wir werden nun einen Fehler im Knoten "Check Text" provozieren. Sehen Sie sich dazu bitte den folgenden Ausschnitt der Detailansicht des Knotens an.

Abbildung 2.19:  Ausschnitt der Detailansicht des Knotens "Check Text".

Im "Text" Feld lässt sich ablesen, welchen Wert QF-Test in diesem Check erwartet. Um einen Fehler zu verursachen, ändern Sie diesen Text in beliebiger Weise ab. Bestätigen Sie anschließend Ihre Eingabe mit OK und führen den Test erneut aus.

Ein Dialog mit dem erwarteten Resultat "0 Exceptions, 1 Fehler, 0 Warnungen" erscheint.

Wenn Sie nun das neue Protokoll öffnen, sehen Sie ein rotes Quadrat um den Knoten "Check Text", welches anzeigt, dass unterhalb dieses Knotens ein Fehler aufgetreten ist. Benützen Sie im Menü »Bearbeiten«-»Nächsten Fehler finden« oder die Tastenkombination [Strg-N], dann sehen Sie den von QF-Test erwarteten Text und was im Testlauf gefunden wurde.

Wir werden nun einen Testfall entwerfen, der beispielhaft die Geschäftslogik in der Applikation testet.

2.6
Testen von Geschäftslogik

Der überwiegende Teil unserer bisherigen Beispiele hat nicht die Logik der Applikation, sondern lediglich die zugrundeliegende Swing Implementierung des Fenster und Komponenten getestet.

Um Geschäftslogik zu testen, brauchen wir einen kausalen Zusammenhang zwischen einer Aktion des Benutzers und der Reaktion der Applikation. Es gibt eine schöne, passende Konstellation im FileChooserDemo, wo ein Textfeld seinen Enabled Status beim Betätigen des "Custom" Optionsfeldes (im linken Teil der Fensters) ändert.

Für unseren Test haben wir beschlossen, eine Mausklick Sequenz zum Aktivieren des Textfeldes aufzunehmen, dann zu prüfen, dass das Textfeld wirklich aktiv ist und zum Abschluss die Applikation mit einem Druck auf den "Öffnen" Knopf zurückzusetzen. Diese Sequenz ist ein wirklicher Aktion-Reaktion Test der Applikation, da diese zwei Komponenten innerhalb Swing keine Verbindung besitzen. Nur den Inhalt eines Textfeldes zu prüfen, ist nicht ein Test der Logik, sondern des initialen Zustandes der ganzen Applikation.

Wir machen genauso weiter wie beim "Check Text" und nehmen die Mausklick Sequenz und den Check getrennt auf. Der resultierende Baum, nach dem Neuanordnen in eine saubere Sequenz, ist im folgenden Bild gezeigt:

Abbildung 2.20:  Der Baum nach Einfügen des "Check Enabled Status" Testfalls.

  • Die erste Sequenz drückt den "Custom" Button und aktiviert damit das Textfeld.
  • Die zweite Sequenz überprüft, dass das Feld wirklich aktiv ist. Das ist ein wirklicher Test von Geschäftslogik in der Applikation, da die Verbindung zwischen dem Button und dem Textfeld außerhalb von Swing liegt.
  • Zum Schluss setzt die dritte Sequenz die Applikation mittels Drücken des "Öffnen" Knopfes zurück.

Sie können diesen Check auf die gleiche Weise manipulieren wie für den "Check Text", indem Sie in die Detailansicht gehen und das Kontrollkästchen "Enabled Status" für den Status ausschalten. Nun wird QF-Test erwarten, dass sich das Textfeld im deaktivierten Zustand befindet, was dann während des nächsten Testlaufs zu einem Fehler führt.

Wir möchten damit dieses Kapitel beenden und einen Schritt weiter in Richtung Fehlerdiagnose gehen. Hierbei stellt der Debugger ein wichtiges Werkzeug innerhalb QF-Test dar. Seine Handhabung und Möglichkeiten sollen im nächsten Abschnitt beschrieben werden.

Videos Downloads Dokumentation Kaufen Gratis Testen