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



Pet Clinic - Modell-basiertes Testen von Spring Applikationen



Das nachfolgende Beispiel zeigt, wie Spring Applikationen mit Hilfe des TestPlayer© Frameworks getestet werden können. Nach der Installation über Github wird die Spring Applikation Pet Clinic über den lokalen URL http://localhost:9966/petclinic/ gestartet und zeigt folgende Ansicht:

Eine genauere Beschreibung der Spring Applikation Pet Clinic kann hier gefunden werden.

Ein korrespondierendes Benutzungsmodell, das als Basis für die automatische Generierung von Testfällen dient, sieht wie folgt aus:



Aus dem initialen Startzustand [, der bei Start des Testfalls ausgeführt wird, ist nur der Benutzungszustand Home direkt erreichbar, danach können auch die anderen Hauptzustände Find owners, Veterinarians und Error aus der Auswahlleiste gewählt werden. Über die Benutzungszustände Find owners und Veterinarians gelangt man, abhängig vom ausgewählten Usecase, in die weiteren Unterzustände und beendet den Testfall mit Erreichen des finalen Stopzustands ].

Die Zustandsübergänge zwischen den 34 Benutzungszuständen werden durch die generischen Ereignisse e1 bis e124 getriggert, die gemeinsam mit den zugeordneten Übergangswahrscheinlichkeiten p1 bis p124 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 Spring Applikation Pet Clinic zu generieren. Die nachfolgende Testsuite enthält 27 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:


  • Testsuite Zustandsabdeckung enthält 27 (von 500) Testfälle
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 von der theoretischen Verteilung (wenn keine Wahrscheinlichkeitswerte vorgegeben werden handelt es sich dabei um eine Gleichverteilung aller Zustandübergänge



  • die Häufigkeiten der Benutzungszustände



  • die Häufigkeiten der Transitionsereignisse


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 27 Testfälle der Testsuite Zustandsabdeckung für den Test der Spring Applikation Pet Clinic :

Während der Testausführung sind zusätzliche Treiber erforderlich, um den Zugriff auf die Spring Applikation Pet Clinic 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 TestPetClinic.py enthält für jeden Benutzungszustand eine Beschreibung welche Aktionen, d.h. Konkretisierungen der abstrakten Testschritte e1 bis e124 auszuführen sind. Der Testschritt

definiert zum Beispiel, was bei Erreichen des Benutzungszustands New Visit zur Erzeugung eines neuen Besuchtermins während der Testausführung zu tun ist:

  1. Überprüfung der Pre-Condition <New Visit> stellt sicher, dass die Aktionen des Testschritts im Benutzungszustand New Visit ausgeführt werden. Im Fehlerfall wird der else-Zweig durchlaufen und über die assert-Anweisung eine entsprechende Fehlermeldung ausgegeben.
  2. Eintrag einer Beschreibung im Eingabefeld description und Klicken auf den Submit-Button Add Visit:



  3. Überprüfung der Post-Condition <Owner Information> stellt sicher, dass der korrekte Zustandsübergang in den Benutzungszustand Owner Information 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/PetClinic/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 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 außer Testfall #20 alle anderen Testfälle der Testsuite den Test mit Pass bestanden haben. Im Show -Bereich von Testfall #20 kann die Situation genauer analysiert werden:
  • Testschritt AddNewVisit besitzt das Testverdict Fail
  • Testschritte AddOwner und NewVisit sind die unmittelbaren Vorgänger. Damit klar, warum Testschritt AddNewVisit nicht erfolgreich war: ein neuer Owner besitzt noch kein Pet, damit kann auch kein Visit angelegt werden!

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






Die einzelnen Abschnitte im Video sind zeitlich wie folgt gegliedert:
  • 0:0-1:07: Benutzung der Spring Applikation Pet Clinic
  • 1:08-2:48: Benutzung des TestPlayer© Dashboards zum automatischen Erzeugen von Testsuiten
  • 2:49-2:55: Benutzungsmodell der Spring Applikation Pet Clinic
  • 2:58-3:44: Eclipse/Python Testumgebung
  • 3:48-4:20: Start der automatisierten Ausführung der Testsuite zur Abdeckung aller Benutzungszustände
  • 4:21-4:49: verkürzter Ablauf der Testausführung und Ausgabe der Testschritte in der Eclipse-Konsole
  • 4:50-5:23: Anzeige der fehlerfreien Testschritte #1 bis #19 des Testreports
  • 5:24-5:36: Analyse des fehlerhaften Testschrittes AddNewVisit
  • 5:37-6:11: Anzeige der fehlerfreien Testschritte #21 bis #27 des Testreports
  • 6:13-6:20: Veränderungen durch die automatisierte Testausführung der Spring Applikation Pet Clinic
  • 6:23-6:33: neu generierter Benutzers Peter Black der den fehlerhaften Testschritt #20 AddNewVisit auslöst