Unser Markenzeichen ist die automatisierte, modell-gestützte Realisierung von Testsuiten unter Verwendung von grafischen Benutzungsmodellen für Hard- und Software-Systeme.



Agile Travel - Web App aus Practical Web Test Automation



Mit der Webanwendung Agile Travel , dem Standardbeispiel aus Zhimin Zhans Buch Practical Web Test Automation, wollen wir zeigen, wie moderne Testmethoden in Kombination mit dem TestPlayer© Framework vorteilhaft erweitert werden können.

Die App Agile Travel simuliert ein Flugbuchungssystem und wird direkt über diesen URL gestartet. Danach zeigt die GUI folgende Ansicht:

Nach Drücken des Sign In -Button können Flüge gebucht werden:

.

Anschließend werden nach Drücken des Continue -Button die Daten des Fluggastes eingegeben:

.

Das korrespondierende Benutzungsmodell, das als Basis für die automatische Generierung von Testfällen dient, zeigt die vielfältigen Interaktionsmöglichkeiten mit der Webapplikation:



Aus dem initialen Startzustand [, der bei Start des Testfalls ausgeführt wird, ist nur der Benutzungszustand Agile Travel direkt erreichbar, danach können je nach Nutzerintention andere Zustände wie Remember me, Heading New Stuff, User Name, Password oder Sign in gewählt werden. Jeder Testfall endet mit dem Erreichen des finalen Stopzustands ].

Die Zustandsübergänge zwischen den 29 Benutzungszuständen (inklusive Start- und Stopzustand) werden durch die generischen Ereignisse e1 bis e99 getriggert, die gemeinsam mit den zugeordneten Übergangswahrscheinlichkeiten p1 bis p99 automatisch während der Generierung der Testsuite vom TestPlayer© erzeugt wurden.

Mit dem TestPlayer© ist es jetzt möglich aus dem obigen Benutzungsmodell automatisch Testfälle für den modell-basierten Test der Webapplikation Agile Travel zu generieren. Die nachfolgende Testsuite enthält 19 Testfälle zur vollständigen Abdeckung aller Benutzungszustände, die nach dem Sortierkriterium sort_l erzeugt sind, d.h. die Testfälle sind aus 500 statistisch zufällig generierten Testfällen nach der Länge der Testfälle sortiert worden. Jeder neue Testfall deckt dabei mindestens einen neuen Benutzungszustand im Vergleich zu seinem Vorgänger ab:


  • Testsuite Zustandsabdeckung enthält 19 Testfälle (von insgesamt 500 automatisch generierten)
Die Testfälle sind animiert (hervorgehoben durch fett-orangene Einfärbung) dargestellt und zeigen die Abdeckung der Benutzungszustände sowie die Übergänge zwischen den Zuständen. Die Zahl hinter dem Doppelpunkt des jeweiligen Klickereignisses verdeutlicht, wie oft der jeweilige Zustandsübergang während des Testfalls durchlaufen wurde.

Beim Generieren der Testsuite erzeugt der TestPlayer© verschiedene Diagramme, die es ermöglichen die charakteristischen Eigenschaften der Testsuite besser zu verstehen. Dazu gehört z.B.

  • die Abweichung der statistischen Häufigkeiten der Benutzungszustände der kompletten Testsuite ( in diesem Fall mit 500 Testfällen) von der theoretischen Verteilung der MCUM (Markov Chain Usage Model) bei Gleichverteilung aller Zustandsübergänge, wenn keine Wahrscheinlichkeitswerte vorgegeben werden. Dabei sind nur wenige Unterschiede festzustellen, d.h. die Testsuite mit 500 Testfällen bildet das vorgegebene Modell sehr gut ab:



  • die Häufigkeiten der Benutzungszustände in der reduzierten Testsuite, die alle Zustände abdeckt:



  • die Häufigkeiten der Transitionsereignisse in der reduzierten Testsuite, die alle Zustände abdeckt:


Neben den grafischen Darstellungen erzeugt der TestPlayer© außerdem Textdateien, die die Testfälle der Testsuite in kompakter JSON-Formatierung für die Testausführung bereitstellen. Die Datei test_cases_for_state_coverage.json enthält die 19 Testfälle der Testsuite Zustandsabdeckung für den Test der Webapplikation Agile Travel :

Während der Testausführung sind zusätzliche Treiber erforderlich, um den Zugriff auf die Webapplikation Agile Travel zu automatisieren. Wir verwenden dafür das weit verbreitete Automatisierungsframework SeleniumHQ, das sich bequem in eine, auf Eclipse basierende Testumgebung einbinden lässt:

Das Python-Script AgileTravel.py enthält für jeden Benutzungszustand eine Beschreibung welche Aktionen, d.h. Konkretisierungen der abstrakten Testschritte e1 bis e99 auszuführen sind. Der Testschritt

definiert zum Beispiel, was bei Erreichen des Benutzungszustands First name zur Eingabe eines Passagiervornahmens für die Flugbuchung während der Testausführung zu tun ist:

  1. Überprüfung der Pre-Condition <Passenger Details> stellt sicher, dass die Aktionen des Testschritts im Benutzungszustand Passenger Details ausgeführt werden. Im Fehlerfall wird der else-Zweig durchlaufen und über die assert-Anweisung eine entsprechende Fehlermeldung ausgegeben.
  2. Suche nach einem Eingabefeld mit dem Namen passengerFirstName.
  3. Löschen möglicher Texte, bedingt durch vorherige Eingaben.
  4. Eingabe eines zufälligen Vornamens (in diesem Fall Jeff) im Eingabefeld passengerFirstName:



  5. Überprüfung der Post-Condition <Passenger Details> stellt sicher, dass der korrekte Zustandsübergang in den Benutzungszustand Passenger Details erfolgt. Außerdem überwacht die assert-Anweisung die Ausführung des Testschrittes und vergibt je nach Testergebnis das Testverdikt pass, fail bzw. error.

Mit Run Configurations können in Eclipse die Aufrufparameter für die Testausführung übergeben werden:



Die Dateioption -f test_cases/AgileTravel.TestPlayer/500_sort_l/test_cases_for_state_coverage.json.txt liest die automatisch generierte Testsuite zur Abdeckung aller Benutzungszustände während der Testausführung ein.

Beim Drücken auf den Run Button startet der Webbrowser im Automatik-Modus (erkennbar durch das Roboter-Icon vor der Adressleiste) und führt selbstständig alle Aktionen der eingelesenen Testsuite aus:

Während der Testausführung werden in der Konsole die einzelnen Testfälle protokolliert und ihre Ausführungsdauern am Ende ausgegeben:

Am Ende der Testausführung wird das Ergebnis in einem ausführlichen Testreport festgehalten. Für jeden Testfall der Testsuite werden die folgenden Daten ausgegeben:

  • Start Time : Ausführungszeitpunkt des Testfalls
  • Duration : Ausführungsdauer des Testfalls
  • Result : Ergebnis der Testausführung ( Pass , Fail , Error ) und Anzahl der Testschritte
  • Test case # : Nummer des Testfalls in der Testsuite (1, ...)
  • Dateiname der Testsuite
Im Show -Bereich sind für jeden Testfall weitere Details einstellbar:
  • Summary : kurze Zusammenfassung aller Testschritte
  • Failed : detailierte Darstellung aller Testschritte mit dem Testverdict Fail
  • All : detailierte Darstellung aller Testschritte



Aus dem Testreport ist zu erkennen, dass alle 19 Testfälle der Testsuite den Test mit Pass bestanden haben.

Sehr oft sind Tester daran interessiert nur einen Teil der Anwendung gezielt zu testen oder zu Beginn eines Testzyklus nur den sogenannten Happy Path zu überprüfen.

Für diesen Zweck kann das Test-Profil im TestPlayer© Dashboard gezielt angepasst werden, d.h. die Übergangswahrscheinlichkeiten werden so gesetzt, dass nur Teile des Benutzungsmodell durchlaufen werden. Das nachfolgende Profil fokussiert die Testsuite nur auf Testfälle mit One-Way-Flügen ( p27=0 ) und Visa-Buchung ( p74=0 ) ohne die Zustände Remember me und Heading New Stuff aufzusuchen ( p9=1 ). Die restlichen Anpassungen der Wahrscheinlichkeitswerte im Profil sorgen dafür, dass keine Rückwärtsschleifen aktiviert sind und das Benutzungsmodelle linear vom Startzustand [ zum Endzustand ] durchlaufen wird:

Im TestPlayer© Dashboard kann nun wie folgt eine reduzierte Testsuite generiert werden. Zuerst werden im Bereich Model settings das Modell AgileTravel und das Profil AgileTravel ausgewählt. Außerdem muss Profile Usage auf yes gesetzt werden:



Im Bereich Generation settings wird die Anzahl der zu generierenden Testfälle im Tab Testcase Definitions auf den Wert 10 eingestellt. Dieser kleine Wert ist für die fokussierte Testsuite ausreichend. Zusätzlich wird als Generation strategy die Strategie fast overview eingestellt, bei der neben der Generierung einer Testsuite weitere nützliche Diagramme erzeugt werden:


Mit dem Filemanager kann noch einmal das Profil überprüft werden, bevor die automatische Generierung der Testsuite angestoßen wird:

Nach der automatischen Generierung kann mit dem Filemanager auf die Testfälle im Verzeichnis testcases/AgileTravel/ zugegriffen werden. Wählt man z.B. das Unterverzeichnis 10_sort_l_p aus werden die Testsuiten angezeigt, die nach der Länge der Testfälle sortiert sind und über ein Profil generiert wurden. In der Statistikdatei statistics.txt ist u.a. zu erkennen, dass 5 Testfälle ausreichen, um alle Benutzungszustände und Zustandsübergänge der fokussierten Testsuite abzudecken:


Die Datei test_cases_for_state_coverage.json.txt enthält die 5 Testfälle, die anschließend für die Testausführung benötigt werden:

Im Verzeichnis diagrams/AgileTravel/10/... wurden über die Generierungstrategie fast overview zusätzliche Diagramme generiert. Das nachfolgende Diagramm zeigt z.B. eine Variante der TestPlayer© Visualisierung. Dabei ist zu erkennen, dass nur ein Teil der Benutzungszustände während des Test überprüft werden, während die blau eingefärbten Zustände beim Test wie gewünscht nicht berücksichtigt werden:

Im folgenden ist noch einmal die fokussierte Testsuite mit 5 Testfällen visualisiert. Jeder neue Testfall deckt dabei mindestens einen neuen Benutzungszustand im Vergleich zu seinem Vorgänger ab:

Mit diesen 5 Testfällen kann anschließend ein fokussierter Test der Webanwendung Agile Travel durchgeführt werden:

Mit Run Configurations wird in Eclipse über die Dateioption -f test_cases/AgileTravel.TestPlayer/10_sort_l_p/test_cases_for_state_coverage.json.txt die fokussierte Testsuite zur Testausführung eingelesen. Während der Testausführung werden in der Konsole die einzelnen Testfälle protokolliert und ihre Ausführungsdauern am Ende ausgegeben:



Am Ende der Testausführung wird das Ergebnis in einem ausführlichen Testreport festgehalten:



Aus dem Testreport ist zu erkennen, dass die 5 Testfälle der Testsuite den Test mit Pass bestanden haben.

Das folgende Video zeigt die beschriebene Vorgehensweise und alle wesentlichen Schritte noch einmal in kompakter Darstellung: