Behavior-Driven Testing (BDT) mit technischer Beschreibung

Version 5.3.2

27.4.1

Eine technische Beschreibung eines Testfalles mit Behavior-Driven Testing (BDT) orientiert sich an den grundlegenden Aktionen, die ausgeführt werden müssen. Das dazugehörige Beispiel finden Sie unter qftest-5.3.2/demo/keywords/behaviordriven/ BehaviorDrivenTesting.qft. Der dazugehörige Testplan liegt unter qftest-5.3.2/demo/keywords/behaviordriven/createvehicle.xlsx. Bitte achten Sie darauf, dass Sie den Ordner in ein projektspezifisches Verzeichnis kopieren und diese dort modifizieren.

Nach BDT mit technischer Sicht wird unser "Fahrzeug anlegen" Testfall nun wie folgt beschrieben:

Gegeben Anwendung läuft
Gegeben Dialog Fahrzeuge ist geöffnet
Wenn Textfeld Name auf Wert <name> gesetzt
Und Textfeld Preis mit Wert <preis> gefüllt
Und Button Neu geklickt wurde
Und Button OK geklickt wurde
Dann ist Tabelle Fahrzeuge eine neue Zeile mit den Werte <name> und <formatierter-preis> erschienen
Und Spalte Modell enthält den Wert <name>
Und Spalte Preis enthält den Wert <formatierter-preis>

Der BDT Ansatz beschreibt Vorbedingungen und Aktionen mit Hilfe der Schlüsselwörter Gegeben, Wenn, Und und Dann, die am Satzanfang stehen müssen. Eine nähere Erläuterung dieses Konzeptes finden Sie in entsprechender Testliteratur.

Für QF-Test bedeutet dies, dass wir wieder Prozeduren bauen müssen, die dieser Beschreibung entsprechen. Hier hat sich bewährt, dass die BDT-Keywords als separate Packages erstellt werden. In der mitgelieferten Testsuite finden Sie hierfür auch die Packages Given, When_And und Then.

Abbildung 27.6: Testsuite Behavior-Driven Testing technisch

In unserer Beispiel-Testsuite liegen nun die entsprechenden Prozeduren unter den jeweiligen Packages, also z.B. eine Prozedur vehicles dialog opened unter dem Package Given. Um Flüchtigkeitsfehler bei der Beschreibung zu vermeiden wird vor dem Prozeduraufruf $(teststep) ein Server-Skript read test-steps and fix typos eingeführt, dass die gsamte Beschreibung in Kleinbuchstaben formatiert und mehrfache Leerzeichen durch eines ersetzt.

Damit der selbe Testfall mit unterschiedlichen Testdaten abgespielt werden kann, wurde dieses Beispiel erweitert.

Natürlich könnte man hier auch versuchen, den generischen Erkennungsansatz, wie im vorigen Abschnitt beschrieben (Abschnitt 27.3), anzuwenden. Hierfür muss entweder die Beschreibung sehr genau sein oder das vorgelagerte Skript muss die Komponenten und deren Namen gut herausfinden können.

Handbuch