TestPlayer 2.0 – Benutzerhandbuch

Kurzfassung

TestPlayer 2.0 ist eine fortschrittliche, webbasierte Plattform für das Model-Based Testing (MBT) [1], die Erstellung von Testsuiten aus Zustandsübergangsmodellen automatisiert. Benutzer können eine integrierte Entwicklungsumgebung nutzen, um DOT-Graphen [2] zu bearbeiten und stochastische Benutzerprofile über Markov Chain Usage Models (MCUM) zu definieren. Das System verfügt über einen MBT-Wizard zur Konfiguration von Testalgorithmen, wie beispielsweise der Knoten- und Kantenabdeckung (Node und Edge Coverage), sowie einen SUT-Adapter-Manager, um abstrakte Modelle mit realen Browser-Interaktionen zu verknüpfen [4]. Ein hierarchischer Projekt-Arbeitsbereich organisiert die generierten Artefakte, während interaktive Dashboards analytische Metriken wie Steady-State-Wahrscheinlichkeiten bereitstellen. Umfangreiche Visualisierungstools [3] ermöglichen die schrittweise Inspektion von Testfällen und die vergleichende Performance-Analyse von Testläufen. Letztendlich optimiert die Plattform den gesamten Testlebenszyklus – von der automatisierten Modellgenerierung durch UI-Crawling bis hin zum detaillierten Reporting der Ausführungsergebnisse.

1. Login und Authentifizierung

Der Zugang zum TestPlayer 2.0 ist durch ein sicheres Authentifizierungssystem geschützt.

Figure 1 Die zentrale Login-Maske des TestPlayer Portals.

Nach erfolgreicher Eingabe von E-Mail-Adresse und Passwort wird der Anwender in seinen persönlichen Arbeitsbereich weitergeleitet.

2. Dashboard und Modellverwaltung

Das Dashboard ist der zentrale Einstiegspunkt und die persönliche Schaltzentrale nach dem Login. Hier werden alle verfügbaren Testmodelle (Projekte) des angemeldeten Benutzers aufgelistet.

Figure 2 Die personalisierte Dashboard-Übersicht der eigenen Testmodelle.

• Projektauswahl: Ein Klick auf “Öffnen” bei einem Projekt führt direkt in die Projektdateien, in der alle bisher generierten Artefakte verwaltet werden.

• Neues Projekt: Über den Button “+ Neues Projekt” können frische DOT-Modelle in das System importiert und für die Testgenerierung vorbereitet werden.

3. Blog / News & Updates

Um über neue Funktionen, Releases und Ankündigungen rund um das Model-Based Testing informiert zu bleiben, verfügt der TestPlayer 2.0 über einen integrierten Blog-Bereich.

Figure 3 Der News-Bereich für aktuelle Release-Notes und Ankündigungen.

4. DOT Editor & MCUM IDE

Die integrierte Entwicklungsumgebung (IDE) des TestPlayer 2.0 erlaubt die direkte Bearbeitung der Graphen und Wahrscheinlichkeiten direkt im Browser, unterteilt in die Bearbeitung des Basismodells und die Profil-Verwaltung.

4.1 Basismodell bearbeiten

Im oberen Bereich der IDE kann der DOT-Code des Basismodells bearbeitet werden [2].

Figure 4 Code-Editor für das zugrundeliegende DOT-Modell.

Jede Änderung am Code kann sofort visuell überprüft werden. Die Live-Vorschau rendert das Basismodell und zeigt die topologische Struktur (“Ground Truth”) an.

Figure 5 Gerenderte Live-Vorschau des Basismodells.

4.2 Profilverwaltung & Live-Injection

Im unteren Bereich der IDE können benutzerspezifische Profile (z. B. HappyPath) angelegt und im JSON-Format verwaltet werden. Diese Profile überschreiben abstrakte Variablen im DOT-Code mit konkreten Übergangswahrscheinlichkeiten.

Figure 6 Verwaltung und Bearbeitung stochastischer Benutzerprofile.

Sobald ein Profil ausgewählt ist, projiziert die Live-Vorschau die stochastischen Gewichte direkt auf den Graphen. Die Kanten werden entsprechend der injizierten Wahrscheinlichkeiten eingefärbt und hervorgehoben.

Note

Zuweisungen von p=0 in einem Profil werden vom Algorithmus strikt respektiert, sodass diese Kanten bei der Generierung ignoriert werden. Unzugängliche Graphen-Teile werden von der stochastischen Analyse automatisch isoliert.

5. Der MBT Wizard (Parameterkonfiguration)

Der MBT Wizard steuert die Smart Testing Engine. Im ersten Schritt wird das gewünschte Modell aus der eigenen Bibliothek ausgewählt.

Figure 7 Startbildschirm des MBT Wizards zur Auswahl des Testmodells.

Im Anschluss werden die Parameter für die Generierung der Testsuite festgelegt. Die Benutzeroberfläche merkt sich automatisch die zuletzt verwendeten Einstellungen pro Projekt.

5.1 Test-Algorithmen

• Random Walk: Generiert zufällige Pfade durch das Modell bis zum Zielzustand oder bis zum Erreichen der maximalen Schrittzahl.

• Node Coverage: Garantiert, dass jeder erreichbare Knoten mindestens einmal durchlaufen wird. Redundante Pfade werden durch einen Greedy-Algorithmus eliminiert.

• Edge Coverage: Garantiert, dass jede erreichbare Kante abgedeckt wird.

• Markov Chain Varianten: Kombiniert die obigen Algorithmen mit den statistischen Wahrscheinlichkeiten aus den Profilen der MCUM IDE.

Figure 8 Algorithmen für die Testfallgenerierung.

6. SUT-Adapter Manager (Web-UI)

Ein System Under Test (SUT) Adapter bildet das Bindeglied zwischen den abstrakten Zuständen und Kanten des Testmodells (z. B. e1, s2) und den konkreten Interaktionen der Testausführung (Playwright Automation Engine [4]). Über die Menüschaltfläche 🔌 SUT-Adapter Manager steht eine voll integrierte Web-Oberfläche zur Verfügung, mit der SUT-Adapter angelegt, konfiguriert und gepflegt werden können.

6.1 Adapter-Übersicht & Verwaltung

Die Hauptansicht des Managers bietet eine tabellarische Auflistung aller im System existierenden Adapter:

• Such- und Filterfunktion: Ermöglicht das schnelle Auffinden von Adaptern nach Name oder Ziel-URL.

Figure 9 Übersicht und Schnellzugriff auf alle konfigurierten SUT-Adapter.

• Erstellung neuer Adapter: Über die Schaltfläche “+ Neuer Adapter” lässt sich direkt in der Benutzeroberfläche ein neuer Adapter-Container anlegen.

• Aktionen: Für jeden Adapter stehen Buttons zum direkten Öffnen der Detail-Konfiguration sowie zum sicheren Löschen veralteter Instanzen bereit.

Figure 10 Erstellung neuer SUT-Adapter und weitere Aktionen.

6.2 Stammdaten & Authentifizierung

Die Detailansicht eines SUT-Adapters gliedert sich in eine zweigeteilte Arbeitsumgebung: Auf der linken Seite befindet sich das Formular zur Pflege der grundlegenden Verbindungsparameter.

Figure 11 Stammdaten-Panel zur Pflege von URLs, Logindaten und JSON-Testdaten.

1. Adapter Name & Beschreibung: Eindeutige Bezeichnung und Freitextbeschreibung für das Testteam.

2. Default URL (SUT-Ziel): Die Basis-URL des zu testenden Web-Systems (z. B. https://localhost:8000).

3. Authentifizierung (LOGIN_MACRO): Zugangsdaten (Username und Password), die automatisch injiziert werden, wenn ein Testschritt die Aktion Login Macro Flow ausführt.

4. Test Data Pools (JSON): Schlüssel-Wert-Speicher im JSON-Format zur Bereitstellung dynamischer Eingabedaten. Variablen in Form von {{variable}} innerhalb von Event-Mappings lösen Werte aus diesem Pool automatisch zur Laufzeit auf.

6.3 Event Mappings Editor (Locators & Actions)

Im rechten Bereich befindet sich das interaktive Tab Event Mappings. Hier wird definiert, welche UI-Aktion beim Auslösen eines abstrakten Modellevents (z. B. player_4) auf der Webseite ausgeführt werden soll.

Jedes Event Mapping umfasst folgende Parameter:

• Abstract Event: Name der Kante im DOT-Modell (z. B. player_4).

• Action (Choice): Vordefinierte Auswahlliste der Interaktionsart:

• Click: Mausklick auf ein Element.

• Text Input: Eingabe von Text in ein Eingabefeld.

• Submit Form: Absenden eines Formulars.

• Assert Element Visible: Überprüfung der Sichtbarkeit.

• Sleep / Wait: Definiertes Warten auf UI-Reaktionen.

• Select Dropdown: Auswahl einer Option aus einer HTML-Select-Box.

• Login Macro Flow: Ausführen des automatisierten Login-Ablaufs.

• Locator Type (Choice): Art des Element-Finders:

• CSS Selector, ID, XPath, Name, Class Name, Link Text, Tag Name, None / Macro.

• Locator Value: Der konkrete Suchausdruck im DOM (z. B. #btn-submit oder //button[@id='login']).

• Action Value: Optionale Zusatzdaten für die Aktion (z. B. der einzugebende Text oder die Variable {{username}}).

Note

In-Place Editing, Löschen & Hinzufügen: Änderungen in der Tabelle können direkt vorgenommen werden. Über das Mülleimer-Symbol am Zeilenende wird eine Zuordnung gelöscht. Über die hervorgehobene grüne Zeile am Tabellenende (➕ Neues Event) lässt sich sofort ein weiteres Event-Mapping zur Tabelle hinzufügen. Ein Klick auf “Event Mappings Speichern” sichert alle Anpassungen gesammelt ab.

6.4 State Mappings Editor (Assertions & Indikatoren)

Das zweite Tab State Mappings regelt das Test-Orakel: Es definiert, wie der TestPlayer verifiziert, ob das SUT nach Ausführung eines Events einen bestimmten Modellzustand (z. B. s5) erfolgreich erreicht hat.

• Abstract State: Name des Zustands im DOT-Modell (z. B. s5).

• Indicator Type (Choice): Prüfmethode für den Zustand:

• CSS Selector (Sichtbar): Prüft, ob ein bestimmtes UI-Element im DOM sichtbar ist.

• URL (Regex / Enthält): Prüft, ob die aktuelle Browser-URL ein Muster enthält (z. B. /dashboard).

• Sichtbarer Text im DOM: Verifiziert das Vorhandensein eines bestimmten Textabschnitts auf der Seite.

• Indicator Value: Der konkrete Wert oder Suchausdruck für den Indikator (z. B. .logged-in-banner).

7. Projekt-Dateien (Workspace)

Die Dateiansicht ist streng hierarchisch aufgebaut (Profil \(\rightarrow\) Suite \(\rightarrow\) Artefakte), um auch bei hunderten generierten Dateien die Übersicht zu bewahren.

Figure 12 Übersicht der Projektdateien mit Profil-Ordnern.

Note

Dynamische Sichtbarkeit von Profilen: Die Ansicht der Projekt-Dateien ist ein dynamischer Datei-Browser. Die grünen Profil-Ordner werden ausschließlich aus den Dateinamen der tatsächlich vorhandenen Testsuiten generiert. Ein in der MCUM IDE neu angelegtes Profil (z. B. HappyPath) erscheint hier erst, nachdem über den MBT Wizard mindestens eine Testsuite für dieses Profil generiert wurde.

7.1 Ordnerhierarchie

1. Profil-Ebene: Grüne Ordner (z. B. Profil: Basismodell), die alle zugehörigen Testsuiten kapseln.

2. Suite-Ebene: Der spezifische Lauf. Über den Button “🗑️ Suite löschen” kann hier die komplette Testsuite samt aller generierten Diagramme restlos aus der Datenbank entfernt werden.

Figure 13 Profil/Testsuite-Ebene: Kapselung aller zugehörigen Testsuiten.

3. Artefakt-Ebene: Unterteilt in aufklappbare Workflow-Phasen 1. Testsuite & Ausführung, 2. Diagramme & Artefakte, 3. Testläufe (Reports & DuckDB Live-Traces) und 4. Visualisierung der Testläufe.

Figure 14 Artefakt-Ebene: Unterteilt in aufklappbare Workflow-Phasen.

7.2 MCUM Analyse Dashboard (Steady-State & Visits)

Sobald ein Profil-Ordner aufgeklappt wird, berechnet die Smart Testing Engine über Matrix-Operationen (Fundamentalmatrix \(N\)) on-the-fly die analytischen Metriken des zugrundeliegenden Markov-Modells [1]. Die Ergebnisse werden dargestellt als:

• Steady State Probability: Zeigt die relative, langfristige Aufenthaltswahrscheinlichkeit (\(\pi\)) für jeden Zustand.

Figure 15 Steady State Probability: Relative Aufenthaltswahrscheinlichkeit (\(\pi\)) für jeden Zustand.

• Expected Visits per Test Case: Zeigt die Anzahl der durchschnittlichen Besuche (\(V\)) eines Knotens pro Testlauf.

Figure 16 Expected Visits per Test Case: Anzahl der durchschnittlichen Besuche (\(V\)) eines Knotens pro Testlauf.

Note

Warum sehen beide Diagramme identisch aus? Dass die Balken exakt dieselbe relative Höhe aufweisen, ist ein mathematisches Gesetz absorbierender Markow-Ketten [1]. Die stationäre Wahrscheinlichkeit eines Knotens (\(\pi_i\)) ist strikt proportional zu seinen erwarteten Besuchen (\(V_i\)) geteilt durch die durchschnittliche Gesamtlänge eines Testfalls. Die X-Achse zeigt die Zustände alphanumerisch sortiert.

7.3 Projektdokumentation & Timeline

Am Ende der Projektdateien eines Projekts befindet sich die chronologische Projektdokumentation. Diese vertikale Timeline dient als Audit-Log und kombiniert automatische System-Events nahtlos mit manuellen Anmerkungen der Anwender. Um auch bei langen Projekthistorien die Navigation zu erleichtern, ist die Timeline standardmäßig zugeklappt und lässt sich über ein dediziertes Sortier-Icon am oberen Rand jederzeit umkehren (chronologisch / umgekehrt chronologisch).

Figure 17 Die Projektdokumentation aggregiert Testläufe und einklappbare manuelle Notizen in einer sortierbaren Timeline.

Automatische System-Events: Sobald ein asynchroner Testlauf gestartet, erfolgreich beendet oder mit einem Fehler abgebrochen wird, generiert das System automatisch einen Eintrag in der Timeline. So lässt sich die Historie der Testausführungen visuell und lückenlos nachvollziehen.

Manuelle Notizen & Markdown-Editor: Über die Schaltfläche “Neue Notiz hinzufügen” können Fachtester eigene Beobachtungen, Fehleranalysen oder Zwischenstände dokumentieren. Manuelle Notizen werden sehr übersichtlich als aufklappbare Tabs (Akkordeons) dargestellt, die im Normalzustand geschlossen sind und lediglich ihre fortlaufende Nummer sowie den vergebenen Titel zeigen.

• Titel & Nummerierung: Jede Notiz erhält systemseitig automatisch eine fortlaufende Identifikationsnummer (z. B. “Notiz #4”) und kann mit einem optionalen, individuellen Titel für die bessere Auffindbarkeit versehen werden.

• Markdown & Mermaid: Der integrierte Editor unterstützt vollständiges Markdown sowie Mermaid.js für die schnelle Skizzierung von Diagrammen.

• Live-Vorschau: Während der Eingabe zeigt eine Live-Vorschau sofort das finale, gerenderte Ergebnis an.

• Metadaten-Injektion: Neue Notizen werden automatisch mit einem dynamischen Template befüllt, das Datum, Uhrzeit und den aktuellen Standort (z. B. Waldaschaff) des Testers erfasst.

• Mehrfacher Dateiupload: Über das Upload-Feld können in einem Durchgang beliebig viele Screenshots und Abbildungen (Mehrfachauswahl) angehängt werden. Diese lassen sich über Platzhalter flexibel im Text anordnen und werden dynamisch in das finale Markdown-Rendering eingebettet.

Figure 18 Der Editor bietet Live-Rendering für Markdown, anpassbare Titel und mehrfache Bild-Uploads inkl. Metadaten-Template.

Einträge bearbeiten und löschen: Manuelle Notizen können jederzeit nachträglich angepasst werden. Ein Klick auf das Bleistift-Symbol (direkt im Tab-Header) öffnet die bestehende Notiz erneut im Editor, um Texte oder den Titel zu verfeinern und zusätzliche Bilder hochzuladen. Über das Mülleimer-Symbol lassen sich veraltete Einträge unwiderruflich aus der Historie entfernen.

8. Visualisierung und Diagram Viewer

Der TestPlayer 2.0 enthält eine hochperformante Rendering-Engine (D3.js / Graphviz / Chart.js), die JSON- und DOT-Daten direkt im Browser interaktiv darstellt [2][3].

8.1 Visualisierung der Testfälle (Frames)

Jeder generierte Testfall einer Suite kann im Diagram Viewer Schritt für Schritt analysiert werden.

• Navigation: Es kann nahtlos zwischen Testfällen (z. B. TC #1 bis TC #10) gesprungen werden.

• Darstellung: Wahlweise als Accumulated Representation (Historie inkl. verblasster vorheriger Pfade zur Visualisierung der bisher erreichten Testabdeckung) oder Single-Mode (isolierter Pfad).

Figure 19 Single-Mode Representation eines einzelnen Testfalls.

Figure 20 Akkumulierte Representation einer Folge von Testfällen.

8.2 Übersicht der Testsuite (Testfokus)

Der Testfokus aggregiert alle Durchläufe einer kompletten Suite auf einem einzigen Graphen. Kantenstärken (Penwidth 1 bis 4) und Farben (Matplotlib “Blues”-Palette) visualisieren die Besuchshäufigkeit, die zusätzlich in den Kantenlabels angezeigt wird. Nicht besuchte Knoten und Kanten werden ausgegraut und besitzen keine Besuchshäufigkeit.

Figure 21 Testfokus und Visualisierung der Besuchshäufigkeit.

8.3 Vergleichende Analyse (Overlays)

Um die Güte einer generierten Testsuite analytisch zu bewerten, bietet der Viewer für die Diagramme der Zustands- und Ereignishäufigkeiten eine interaktive Vergleichsfunktion (Overlay). Über das Dropdown-Menü “⚖️ Vergleichen mit:” kann ein zweiter Datensatz (blau) über den aktuellen Datensatz (grün) gelegt werden. Das Anklicken der blauen bzw. grünen Legende entfernt den blauen bzw. grünen Datensatz aus dem Diagramm. Erneutes Anklicken zeigt ihn wieder.

• Empirie vs. Theorie: Hierbei wird die empirisch gemessene Häufigkeit der Testsuite mit der theoretischen Steady-State-Wahrscheinlichkeit des MCUM-Basismodells verglichen, um Abweichungen des Random Walks zu identifizieren.

• Empirie vs. Empirie: Ermöglicht den direkten Abgleich zweier generierter Testsuiten untereinander.

Figure 22 Vergleich einer generierten Testsuite mit der theoretischen MCUM-Wahrscheinlichkeit.

Note

Effizienzsteigerung durch stochastische Konvergenz: Die Overlay-Analyse liefert den empirischen Beweis für das “Gesetz der großen Zahlen” im Model-Based Testing. Wie in Abbildung Stochastische Konvergenz: 1000 vs. 250 Testfälle im direkten Vergleich. zu sehen ist, unterscheidet sich die Verteilung einer gigantischen Testsuite (z. B. 1000 Testfälle) nur asymptotisch von einer deutlich kleineren Suite (z. B. 250 Testfälle). Der Aufwand für die spätere Testausführung kann somit in der Praxis drastisch (z. B. auf ein Viertel) reduziert werden, ohne gravierende Genauigkeitsverluste in der Profilabdeckung zu erleiden.

Figure 23 Stochastische Konvergenz: 1000 vs. 250 Testfälle im direkten Vergleich.

9. Ausführung und Performance-Visualisierung der Testläufe

Sobald eine Testsuite gegen ein System Under Test (SUT) ausgeführt wurde, stehen im Workspace zwei weitere Phasen (Phase 3 & Phase 4) zur detaillierten Performance-Auswertung bereit. Diese Ansichten setzen die Metriken aus Smart Testing 2.0 visuell um [1].

Figure 24 Start eines Testlaufs.

Figure 25 Erfolgreicher Verlauf deines Testlaufs.

9.1 Testläufe (Reports & DuckDB Live-Traces)

Dieser Abschnitt liefert die Rohdaten und eine aggregierte Zusammenfassung des ausgewählten Testlaufs:

• Übersichtskarten: Zeigen das Ausführungs-Zeitfenster, die Gesamtdauer in ms, die reale Testausführungszeit (inklusive Betriebssystem-Overhead für den Start/Stop des asynchronen Playwright-Agenten und das Abspeichern der Trace-Daten in der Datenbank), die Anzahl der evaluierten Testfälle und Testschritte, sowie eine Status-Matrix (PASS / FAIL / ERR).

• Übersichtsdiagramme: Zwei Diagramme geben Aufschluss über die absolute Häufigkeit und die Ausführungszeiten einzelner Testschritte des Testlaufs.

• Aufschlüsselung der Testfälle: Ein aufklappbares Akkordeon, mit dem jeder Testfall und die Ergebnisse seiner einzelnen Testschritte chronologisch inspiziert werden können.

Figure 26 Ausführungs-Zeitfenster, die Gesamtdauer, die Anzahl der evaluierten Testfälle und Schritte.

Figure 27 Absolute Häufigkeiten einzelner Testschritte.

Figure 28 Bearbeitungszeiten der einzelnen Testschritte.

9.2 Visualisierung der Testläufe (Performance-Metriken)

Die vierte Phase bietet tiefgehende Diagramme zur Identifikation von Flaschenhälsen (Bottlenecks) im SUT. Ein Klick auf ein Diagramm öffnet dieses in einer hochaufgelösten Lightbox-Ansicht (Zoom), wobei die Proportionen und Schriftgrößen dynamisch erhalten bleiben [3]. Alle Achsen unterstützen Natural Sorting, wodurch Labels wie e2 mathematisch korrekt vor e11 einsortiert werden [3].

• Execution Times of the Complete Test Suite: Eine Zeitachse, die die Laufzeit jedes einzelnen ausgeführten Schritts der gesamten Suite visualisiert.

Figure 29 Darstellung der Ausführungszeiten einer kompletten Testsuite.

• Execution Times for Test Case: Eine isolierte Zeitachse für einen bestimmten Testfall, die aus einem Dropdown-Menü gewählt werden kann.

Figure 30 Darstellung der Ausführungszeiten eines einzelnen Testfalls.

Detaillierte Metriken zur Ausführung einzelner Testschritte: Um Ausreißer in der Applikationsperformance aufzudecken, werden die Ausführungszeiten aller identischen Testschritte aggregiert und evaluiert:

Figure 31 Detaillierte Metriken zur Ausführung einzelner Testschritte.

• Minimum Execution Times: Zeigt die schnellste Ausführungszeit eines Testschritts über den gesamten Testlauf (Best-Case-Szenario).

• Mean Execution Times: Berechnet die durchschnittliche Laufzeit und dient als robuster Indikator für die reguläre System-Performance.

• Maximum Execution Times: Hebt Ausreißer hervor, bei denen ein einzelner Schritt untypisch lange benötigte (Worst-Case-Szenario).

• Sum of Execution Times: Die kumulierte Gesamtausführungszeit macht sichtbar, welche Schritte aggregiert die meiste Rechenzeit des Testlaufs beanspruchten.

Figure 32 Kumulierte Gesamtausführungszeit einzelner Testschritte.

9.3 Vergleichende Performance-Analyse (Overlays)

Analog zum Strukturvergleich von Testsuiten lassen sich auch die empirischen Metriken von zwei unabhängigen Testläufen direkt übereinanderlegen. Über das Dropdown-Menü “⚖️ Vergleichen mit:” kann ein zweiter Testlauf (graue Balken) über den Basis-Lauf (türkise Balken) gelegt werden.

• Dynamische Union-Menge: Bricht ein Lauf frühzeitig ab (z. B. durch einen Fehler), interpoliert das System die X-Achse automatisch über die Maximallänge beider Läufe. Fehlende Events werden auf der Achse belassen und mit Nullwerten aufgefüllt, sodass die chronologische Darstellung und der Abgleich absolut synchron bleiben.

• Identifikation von Regressionen: Die überlagerten Balkendiagramme machen Performance-Einbrüche zwischen zwei Test-Iterationen, Code-Refactorings oder verschiedenen SUT-Releases auf einen Blick sichtbar.

Wie zu sehen ist, weist der zweite Testlauf deutlich höhere Werte bei den Ausführungszeiten auf. Dies kann auftreten, wenn ein höheres Volumen an Hintergrundverkehr vorliegt oder wenn viele parallele Aufgaben die Ausführungszeit des Testlaufs beeinflussen.

Figure 33 Vergleichende Performance-Analyse: Vergleich der Ausführungszeiten zweier Testläufe.

Figure 34 Vergleich der Ausführungszeiten zweier Testfälle.

Figure 35 Sortierter Vergleich der Summe der Ausführungszeiten zweier Testläufe.

9.4 Playwright-Replay (Video-Aufzeichnung)

Um bei fehlerhaften Testläufen nicht nur den statischen DOM-Zustand (Trace) analysieren zu können, bietet der TestPlayer 2.0 eine vollständige Video-Aufzeichnung der Browsersitzung. Wird eine Testsuite vor der Ausführung über die Checkbox mit dem Debug-Modus gestartet, zeichnet die Playwright Automation Engine die gesamte Interaktion als komprimiertes .webm-Video auf.

Dieses Replay ermöglicht es dem Tester, die exakte User Journey, Layout-Verschiebungen und Animationen dynamisch zu betrachten, wie der Agent sie zur Laufzeit erlebt hat. Das Video wird automatisch mit dem entsprechenden Testlauf-Datensatz (TestRun) verknüpft und kann zur Fehleranalyse herangezogen werden.

Figure 36 Playwright-Replay: Vollständige Video-Aufzeichnung (.webm) eines asynchronen Testlaufs im Debug-Modus.

10. Exportfunktionen

Alle Diagramme und Grafiken können für externe Dokumentationen und Berichte exportiert werden:

• Statistiken & Metriken: Direkter Einzel-Download als .png oder .png. Die Diagramme enthalten ein dediziertes Buch-Layout (Calibri, fetter zweizeiliger Untertitel und blauer Hintergrund) und erhalten automatisch eindeutige Dateinamen [3].

• Testfall-Frames: Batch-Export. Der Diagram Viewer rendert alle Frames asynchron im Hintergrund und bündelt sie als benanntes .zip-Archiv.

11. Auto-Discovery von MCUMs (Automatisierte Modellgenerierung)

Die manuelle Erstellung von Zustandsübergangsmodellen für komplexe Webanwendungen ist zeitaufwendig und fehleranfällig gegenüber UI-Änderungen. Um diesen Engpass aufzulösen, verfügt der TestPlayer 2.0 über eine integrierte Auto-Discovery Engine. Diese Funktionalität ermöglicht es, das System Under Test (SUT) automatisiert zu explorieren (Crawling) und daraus on-the-fly ein valides Markov Chain Usage Model (MCUM) im DOT-Format sowie einen initialen SUT-Adapter zu generieren.

Figure 37 Auto-Discovery von MCUMs.

11.1 Konfiguration und Stopwort-Filterung

Bevor die Exploration beginnt, konfiguriert der Anwender das Ziel-SUT sowie die Dauer des Explorations-Profils (z. B. 5 bis 60 Minuten) über die Model Discovery Benutzeroberfläche. Um eine Zustandsexplosion (State-Space Explosion) zu verhindern und das generierte Modell exakt auf die relevante Geschäftslogik zu fokussieren, verfügt das System über ein dynamisches Discovery Stopwords Tag-System.

Anwender können hier gezielt Schlagwörter (z. B. “login”, “passwort”, “register”) hinzufügen, aktivieren oder deaktivieren. Während des Crawling-Prozesses wird das Vision-LLM strikt angewiesen, sämtliche UI-Elemente und Aktionen zu ignorieren, die mit diesen aktiven Stopwörtern übereinstimmen. Dies verhindert zuverlässig, dass sich der autonome Agent in Authentifizierungs-Schleifen verfängt oder irrelevante Teilbereiche der Applikation exploriert.

11.2 Funktionsweise der Exploration (UI-Crawling)

Die Auto-Discovery Engine nutzt einen headless Playwright-Agenten, der selbstständig mit der Zielapplikation interagiert. Der Prozess durchläuft iterativ folgende Phasen:

1. Initialisierung: Der Agent navigiert zur Start-URL und analysiert das Document Object Model (DOM) der aktuellen Ansicht.

2. Action Extraction: Ein heuristischer Parser identifiziert alle interagierbaren Elemente (Buttons, Links, Input-Felder, Dropdowns) auf der aktuellen Seite.

3. Execution & Tracing: Der Agent wählt eine Aktion aus (z. B. einen Klick), führt diese aus und wartet auf das Rendern der Folgeseite, um sicherzustellen, dass die Ansicht vollständig geladen ist.

4. Graph Building: Der Ursprungszustand, die ausgeführte Aktion (Kante) und der neu erreichte Zustand werden in einer dynamischen Graphenstruktur protokolliert.

Figure 38 Phasen der Auto-Discovery: Vom initialen Seitenaufruf bis zum dynamischen Graph Building.

11.3 Zustandsabstraktion (State Abstraction)

Die größte Herausforderung bei der automatischen Modellgenerierung ist die Erkennung, ob sich die Applikation nach einer Aktion in einem neuen oder einem bereits bekannten Zustand befindet. Hierfür nutzt der TestPlayer 2.0 eine intelligente Zustandsabstraktion:

• DOM-Hashing: Anstatt die gesamte HTML-Struktur zu vergleichen, extrahiert die Engine strukturgebende Merkmale (z. B. die Anzahl und Art der Container, aktive Navigationselemente, Formularfelder) und generiert daraus einen eindeutigen Hash-Wert.

• Dynamische Daten-Ignoranz: Fluktuierende Inhalte wie Uhrzeiten, zufällige IDs oder temporäre Werbebanner werden durch das Filter-Regelwerk aus dem Hash ausgeschlossen, um eine Zustandsexplosion (State Explosion) zu verhindern.

Figure 39 Zustandsabstraktion: Filterung dynamischer UI-Elemente zur Generierung robuster State-Hashes.

11.4 Von der Exploration zum Markov-Modell (MCUM)

Nachdem die Exploration (z. B. über ein definiertes Zeitlimit oder eine festgelegte Knotendeckung) abgeschlossen ist, liegt der Graph als topologische Ground Truth vor. Im letzten Schritt wird dieser Graph in ein stochastisches Modell (MCUM) überführt.

Die empirischen Wahrscheinlichkeiten der Kanten (Übergänge) werden basierend auf den beobachteten Frequenzen während des Crawlings berechnet. Die Wahrscheinlichkeit \(p\) für den Übergang von Zustand \(s_i\) zu Zustand \(s_j\) bei Ausführung der Aktion \(a\) wird ermittelt durch:

\[p(s_i \xrightarrow{a} s_j) = \frac{n(s_i, a, s_j)}{\sum_{k} n(s_i, a_k, s_k)}\]

Wobei \(n\) die absolute Anzahl der beobachteten Traversierungen darstellt. Kanten, die zu Fehlern (z. B. 404 Pages oder Endlosschleifen) führen, können automatisch mit Pönale-Wahrscheinlichkeiten bestraft oder isolierten Fehlerknoten markiert werden. Das finale Modell wird im DOT-Format exportiert und steht im Dashboard sofort für die Testfallgenerierung bereit.

11.5 Synergie mit dem SUT-Adapter Lifecycle

Das durch die Auto-Discovery generierte DOT-Modell besitzt naturgemäß maschinengenerierte (strukturelle) Locators, wie z. B. lange und unleserliche CSS-Pfade (div > span:nth-child(3) > button).

Genau hier greift der Transformations-Workflow (siehe Administrationshandbuch, Kapitel 3.2): Das Skript transform_adapter nutzt Heuristic Matching, um die frisch entdeckte, akkurate Topologie der Auto-Discovery mit den menschenlesbaren, semantischen Namen (z. B. btn_login) eines manuell gepflegten Referenz-Adapters zu fusionieren. So entsteht vollautomatisiert ein Testmodell, das sowohl strukturell zu 100 % der aktuellen Applikation entspricht, als auch lesbare, wartbare UI-Locators für die Smart Testing Engine bietet.

12. Case Study: Automatische Discovery und Generierung für das Projekt “Playwright”

Diese übergeordnete End-to-End Fallstudie demonstriert den vollständigen Workflow des TestPlayer 2.0 in der Praxis. Als Testobjekt dient hierbei die offizielle Dokumentationsseite der Playwright Automation Engine.

12.1 Initialisierung und Auto-Discovery

Der Prozess beginnt ohne ein existierendes DOT-Modell. Stattdessen wird die Auto-Discovery Engine (siehe Kapitel 11) mit der Ziel-URL der Playwright-Webseite gestartet. Der Agent durchläuft die Seite autonom, identifiziert interagierbare Elemente im DOM und baut iterativ einen Graphen auf.

Figure 40 Schritt 1: Konfiguration und Start des Auto-Discovery-Laufs auf dem Zielsystem.

Nach Abschluss der Explorationsphase wandelt das System die gesammelten Metadaten in ein valides Markov Chain Usage Model (MCUM) um. Das Ergebnis ist eine topologische “Ground Truth” der Playwright-Dokumentation, bei der Navigationspfade, Zustände und Kanten (Events) automatisch abgeleitet wurden.

Figure 41 Schritt 2: Das aus der Exploration automatisch generierte Zustandsübergangsmodell.

12.2 Projekt-Workspace und Dateiverwaltung

Sobald das Modell gespeichert ist, legt der TestPlayer 2.0 automatisch einen neuen Projekt-Workspace an. Hier wird das neu entdeckte Basismodell samt Profil-Struktur hinterlegt.

12.3 Testsuite-Generierung über den MBT Wizard

Mit dem Modell als Grundlage wird nun der MBT Wizard gestartet, um eine ausführbare Testsuite zu berechnen. In diesem Szenario wird der Algorithmus für die Node Coverage (Zustandsabdeckung) gewählt, um sicherzustellen, dass jeder durch die Discovery gefundene Benutzungszustand mindestens einmal im Testlauf durchlaufen wird.

Figure 42 Schritt 3: Generierung einer Testsuite zur Zustandsabdeckung des SUT.

Figure 43 Schritt 4: Der hierarchische Arbeitsbereich der neuen Testsuite.

12.4 Visuelle Inspektion (Diagram Viewer)

Bevor der asynchrone Testlauf gegen das reale SUT gestartet wird, lässt sich die berechnete Suite im Diagram Viewer überprüfen. Hier kann visuell validiert werden, welche Pfade der Algorithmus durch das Auto-Discovery-Modell gewählt hat.

Figure 44 Schritt 5a: Inspektion eines einzelnen, generierten Testfalls (Single-Mode).

Figure 45 Schritt 5b: Überprüfung der wachsenden Zustandsabdeckung (Accumulated Representation).

Der aggregierte Testfokus bestätigt, dass das Ziel der Node Coverage erreicht wurde: Alle Zustände wurden abgedeckt, und die farbliche Heatmap (Blues-Palette) verdeutlicht die Gewichtung der Traversierungen.

Figure 46 Schritt 5c: Der Testfokus der Suite zeigt eine 100%ige Zustandsabdeckung.

12.5 Analytische Auswertung der Häufigkeiten

Neben dem Graphen liefert das System Balkendiagramme, um die Verteilung der Besuche analytisch zu bewerten. Hier lässt sich ablesen, ob die automatische Testgenerierung bestimmte Zustände oder Events unverhältnismäßig stark frequentiert.

Figure 47 Schritt 6a: Analytische Auswertung der erreichten Zustandshäufigkeiten.

Figure 48 Schritt 6b: Verteilung der ausgeführten Events (UI-Interaktionen).

12.6 Die Ausführung und der erste “FAIL”

Die Validierung ist abgeschlossen, und die Suite wird über den Hintergrund-Worker (Q-Cluster) zur Ausführung gegen die Live-Webseite gesendet.

Da das zugrundeliegende Modell vollständig durch eine KI / Heuristik generiert wurde, sind die maschinell erzeugten CSS-Locators im zugehörigen SUT-Adapter teilweise anfällig gegenüber minimalen Layoutverschiebungen der Webseite. Genau dieses Szenario tritt beim Testlauf ein: Ein Element wird nicht rechtzeitig gefunden, und der Playwright-Agent wirft einen Timeout. Das System fängt dies ab und markiert den Testlauf sowie das spezifische Event mit einem FAIL.

Figure 49 Schritt 7: Der reale Testlauf bricht ab, da ein Auto-Discovery Locator auf der Live-Seite fehlschlägt.

12.7 SUT-Adapter Debugging und Fehlerbehebung

Ursache für solche Abbrüche sind in der Praxis häufig veraltete oder fehlerhaft generierte Locators (z. B. durch dynamische UI-Änderungen oder ungenaue Auto-Discovery-Pfade), die dazu führen, dass der Playwright-Agent nicht mit dem System Under Test interagieren kann.

Schritt 1: Identifikation des Fehlers im Dashboard Während der Ausführung einer generierten Testsuite bricht der Testlauf unerwartet ab. Das Dashboard zeigt im Akkordeon “Testfall Breakdown” sofort an, an welcher Stelle der Fehler aufgetreten ist. Im vorliegenden Fall schlug Testfall #3 beim Event star repo fehl. Um die Fehlerursache ohne manuelles Nachstellen sofort identifizieren zu können, erzeugt und sichert der TestPlayer automatisch den zugehörigen Playwright-Trace in einem .zip-Archiv ab. Über den Button “Trace” wird die Aufzeichnung des fehlgeschlagenen Laufs direkt aus der Datenbank geladen und im Playwright Trace Viewer geöffnet. Dieser stellt den exakten DOM-Zustand, die Netzwerkanfragen, den Action-Verlauf und alle Konsolenausgaben genau zum Zeitpunkt des Abbruchs visuell bereit.

Figure 50 Schritt 1: Identifikation des Abbruchs (FAIL) im Event “star repo” und Start der Trace-Analyse.

Schritt 2: Analyse des Timeouts im Trace Viewer Der Playwright Trace Viewer springt automatisch an das Ende der Aufzeichnung. Im Tab “Errors” sowie im Quellcode-Panel unten ist der Grund für den Absturz ersichtlich: Ein Timeout 3000ms exceeded. Die Engine hat die konfigurierten 3 Sekunden lang vergeblich versucht, das Element für das Event star repo im DOM zu finden und anzuklicken.

Figure 51 Schritt 2: Der Trace Viewer offenbart den exakten Zeitpunkt und die Ursache des Timeouts.

Schritt 3: Lokalisierung des korrekten Elements Um den Fehler zu beheben, muss herausgefunden werden, wie das Ziel-Element (star repo Button/Link) stattdessen adressiert werden kann. Mit Hilfe der DOM-Inspektion im Trace Viewer (oder über die Entwicklertools des eigenen Browsers auf der SUT-Seite) wird nach einem robusten und eindeutigen Selektor gesucht. Anstatt eines unzuverlässigen, generierten ID-Pfades (#_docusaurus_skip...) erweist sich hier ein direkter CSS-Selektor auf das href-Attribut als stabilere Lösung.

Figure 52 Schritt 3: Inspektion des gerenderten DOMs zur Ermittlung eines robusten Ersatz-Locators.

Schritt 4: Navigation zum SUT-Adapter Mit dem Wissen um den fehlerhaften Selektor navigiert der Anwender über das Portal-Menü in den SUT-Adapter Manager und öffnet den betroffenen Adapter (hier: “Auto-Discovery (Projekt 15)”). In den “Event Mappings” wird das Abstract Event star repo lokalisiert. Es ist gut zu erkennen, dass der aktuelle Locator Type (CSS Selector) und der Value fehlerhaft bzw. veraltet sind.

Figure 53 Schritt 4: Aufsuchen des fehlerhaften Event-Mappings im SUT-Adapter Manager.

Schritt 5: Anpassung und Speicherung des Mappings Der alte Locator Value wird durch den neu ermittelten, robusten Selektor (in diesem Fall a[href="https://g..."]) ersetzt. Durch einen Klick auf “Event Mappings Speichern” wird die Änderung live in die PostgreSQL-Datenbank geschrieben. Das grüne Banner bestätigt die erfolgreiche Aktualisierung. Der SUT-Adapter ist nun wieder synchron mit der Realität der Applikation.

Figure 54 Schritt 5: In-Place Aktualisierung des Locators und Speicherung in der Datenbank.

Schritt 6: Erfolgreicher Retest Die fehlerhafte Testsuite kann nun ohne Neugenerierung einfach erneut ausgeführt werden. Da der TestPlayer bei jedem Start dynamisch auf die aktuellen Mappings des SUT-Adapters zugreift, greift die Korrektur sofort. Der Dashboard-Banner signalisiert nun einen “Erfolgreichen Verlauf des Testlaufs”. Der Flaschenhals wurde eliminiert und die Testabdeckung ist wieder gewährleistet.

Figure 55 Schritt 6: Der erneute Testlauf schließt dank des korrigierten SUT-Adapters erfolgreich ab.

12.9 Performance-Analyse mit Playwright

Der TestPlayer 2.0 bietet nicht nur detaillierte Metriken zur Testabdeckung, sondern auch tiefe Einblicke in die tatsächliche Ausführungs-Performance des System Under Test (SUT). Das integrierte Debugging-Ökosystem nutzt die volle Leistungsfähigkeit der Playwright Automation Engine [4], um Engpässe und Fehlerursachen granular aufzuschlüsseln.

12.9.1 Erweiterte Zeitmetriken: Zeitfenster, Reale Task-Dauer und Trace-Dauer

Das “Zeitfenster” ist für die historische Einordnung und das Korrelieren von Lastspitzen (z. B. nächtliche Cronjobs vs. Server-Deployments) extrem wichtig. Um die Performance und den Systemdurchsatz ganzheitlich bewerten zu können, wertet das Testlauf-Dashboard auf den oberen Übersichtskarten nun drei entscheidende Zeitmetriken aus:

• Zeitfenster: Der absolute kalendarische Zeitraum (z. B. 01.08.2026 23:33:47 bis 01.08.2026 23:33:51), in dem der Testlauf auf dem System stattfand. Diese chronologische Einordnung ist essenziell, um Testergebnisse und Latenzen mit anderen Systemereignissen (wie Server-Deployments, Lastspitzen oder nächtlichen Cronjobs) abzugleichen.

• Trace-Dauer (ms): Die reine Interaktionszeit der Playwright Automation Engine auf dem DOM (z. B. 670.25 ms) für das finale Rendern und Klicken innerhalb der virtuellen Browser-Instanz).

• Reale Dauer (Task) (s): Die “Wall-Clock”-Gesamtzeit (Real Execution Time), die der asynchrone Django-Q Hintergrund-Worker für die vollständige Verarbeitung des Testlauf-Tasks benötigt (z. B. 2.93 s). Dies schließt den Start der Test-Matrix, die asynchrone DuckDB-Datenaufbereitung und die abschließende Speicherung im relationalen PostgreSQL-Modell ein.

Figure 56 Unterscheidung zwischen der chronologischen Einordnung, der asynchronen Task-Gesamtlaufzeit und der reinen Playwright Trace-Interaktion.

12.9.2 Analyse von Latenz-Ausreißern

Das Zusammenspiel aus Performance-Metriken und Playwright-Traces ermöglicht hochpräzise Analysen der SUT-Antwortzeiten.

Das Szenario: Bei der Analyse der Execution Times des erfolgreichen Testlaufs fiel im Dashboard ein scheinbarer Flaschenhals auf: Ein spezifischer Navigationsschritt (select navigation tab in der Docusaurus-Header-Leiste) generiert “Ausreißer” von durchschnittlich ~60 bis 85 ms, während einfache DOM-Klicks in 1 bis 40 ms abgearbeitet wurden.

Die Untersuchung: In der chronologischen Aktionsliste (Actions-Tab) konnte der spezifische Klick-Schritt anhand seines Locator-Pfades und der Ausführungszeit von exakt 84 ms isoliert werden. Der interne Call-Log von Playwright offenbarte dabei die genaue Aufschlüsselung, wofür diese Millisekunden investiert wurden:

• ~26 ms - Locator-Auflösung: Das Durchsuchen des aktuellen, gerenderten DOM-Baums durch die Chromium-Engine, um das Element anhand des komplexen CSS-Selektors (#__docusaurus > nav > div > div > a:nth-of-type(5)) zu identifizieren.

• ~18 ms - Actionability Checks: Das zwingende Warten der Engine auf den Zustand “visible, enabled and stable”. Playwright stellt hierbei durch kontinuierliche Checks sicher, dass das Element (etwa durch CSS-Animationen im Header oder Layout-Shifts beim Laden) nicht mehr unter dem virtuellen Cursor verrutscht.

• ~7 ms - Viewport-Kalkulation: Die Positionsberechnung, um zu validieren, ob ein Scrollen (scrolling into view if needed) innerhalb des 1920x1080 Viewports notwendig ist.

• ~18 ms - Physische Klick-Simulation: Anstatt eines sofortigen JavaScript-.click() simuliert Playwright einen echten Menschen auf Protokollebene. Dies erfordert das synchrone Abfeuern von mousedown-, mouseup- und click-Events, was physikalische Zeit kostet.

• ~15 ms - Navigationstrigger: Die Registrierung durch den Browser, dass über den <a href="...">-Link ein Seitenwechsel initiiert wurde.

Figure 57 Isolierung des Klick-Events und Aufschlüsselung der Latenz im Call-Log des Trace Viewers.

Das Ergebnis: Was im Performance-Graphen zunächst als “Ausreißer” erschien, erwies sich bei genauerer Betrachtung als Nachweis für die extreme Präzision und Stabilität des Systems. Die gemessenen Zeiten stellen keinen Flaschenhals in der asynchronen Verarbeitung des TestPlayer 2.0 dar, sondern reflektieren die harten, physikalischen Grenzen der Rendering-Engine bei der Durchführung realistischer, validierter Nutzerinteraktionen. Die beobachtete End-to-End-Automation operiert exakt in diesem Zeitfenster.

13. Best Practices im Model-Based Testing (MBT)

Der automatisierte Einsatz von Model-Based Testing und Auto-Discovery generiert in kurzer Zeit eine immense Menge an Systeminteraktionen. Um Datenkorruption zu vermeiden und aussagekräftige Testergebnisse zu garantieren, ist ein systematisches Vorgehen beim Testen von Web-Applikationen zwingend erforderlich.

13.1 SUT-Isolierung (Die Staging-Regel)

Lassen Sie automatisierte Test-Agenten oder die Auto-Discovery Engine niemals auf eine produktive Live-Umgebung los. Der Agent klickt auf sämtliche erreichbaren Links, füllt Formulare aus und könnte reale Business-Prozesse (z.B. Bestellungen, E-Mail-Versand) auslösen. Richten Sie für das Zielsystem immer eine dedizierte Staging-, QA- oder Sandbox-Umgebung ein und hinterlegen Sie diese sichere Adresse explizit als default_url im SUT-Adapter.

13.2 Der dedizierte Bot-Account

Erstellen Sie in der Datenbank des externen Zielsystems (SUT) einen speziellen Bot-User (z.B. discovery_bot@example.com).

• Sichere Berechtigungen: Vergeben Sie ausschließlich die Rechte eines regulären Nutzers. Dies bildet die echte Customer Journey realitätsnah ab und verhindert, dass der Agent in administrative Bereiche vordringt.

• Konfiguration im TestPlayer: Tragen Sie die Zugangsdaten dieses Bot-Users in die Felder login_username und login_password des jeweiligen SUT-Adapters ein. Der TestPlayer injiziert diese Daten bei Ausführung der Aktion LOGIN_MACRO dynamisch in die Automation Engine.

13.3 Testdaten-Hygiene und Teardown-Strategien

Nach intensiven Testläufen oder einer ausgiebigen Auto-Discovery-Phase muss der entstandene Datenmüll systematisch bereinigt werden. Hierbei ist strikt zwischen lokalen und remote erzeugten Daten zu unterscheiden:

• Lokaler Cleanup (Im TestPlayer): Ungewollte Dummy-Graphen, generierte Testsuiten und aufgezeichnete Trace-Dateien werden direkt über die Benutzeroberfläche des TestPlayers gelöscht. Ein Klick auf “Suite löschen” triggert die Route delete_diagram_folder, welche sowohl die Datenbankeinträge entfernt als auch verwaiste physische Artefakte auf dem Server bereinigt. Alternativ stehen dedizierte Backend-Skripte für Massenlöschungen zur Verfügung.

• Remote Cleanup (Im Zielsystem): Der TestPlayer kann externe Zielsysteme nicht automatisch bereinigen. Das SUT muss von sich aus zurückgesetzt werden. Die effizienteste Methode ist hierbei der Cascade-Delete: Loggen Sie sich in das Backend des Zielsystems ein und löschen Sie den dedizierten Bot-User. Sofern das Zielsystem über saubere relationale Datenbankstrukturen verfügt, werden alle von diesem Nutzer generierten Testdaten automatisch und restlos kaskadierend gelöscht.

Figure 58 Systematischer MBT-Workflow: Strikte Trennung von lokalen Testartefakten und remote SUT-Zuständen.

Glossar

Model-Based Testing (MBT)

Ein Softwaretest-Verfahren, bei dem Testfälle systematisch aus einem abstrakten Verhaltensmodell der zu testenden Software abgeleitet werden.

Markov Chain Usage Model (MCUM)

Ein stochastisches Modell, das Benutzerverhalten durch Zustände und übergangsbezogene Wahrscheinlichkeiten repräsentiert.

Fundamentalmatrix (N)

Eine Matrix in der Theorie der absorbierenden Markow-Ketten, berechnet durch \(N = (I - Q)^{-1}\), die angibt, wie oft ein transienter Zustand im Durchschnitt besucht wird, bevor der Endzustand erreicht wird.

Ground Truth

Das originale visuelle und topologische Layout des DOT-Modells, welches auch bei der dynamischen Farb- und Kantenanpassung durch die Engine exakt erhalten bleibt.

Set Cover Problem

Ein mathematisches Optimierungsproblem. Im TestPlayer verwendet, um redundante Testfälle aus einer generierten Suite zu filtern (Greedy-Algorithmus mit Post-Pruning).

Literaturverzeichnis

[1] Dulz, W. (2026). Smart Testing 2.0: AI-driven practice and Markov Chain models. Independent Publishing.

[2] Graphviz Documentation. (2024). DOT Language and Layout Engines. Graphviz.org.

[3] D3.js & Chart.js. (2024). Interactive Data Visualization for the Web.

[4] Playwright Automation Engine. (2026). Playwright - Web automation for testing, scripting, and AI agents. Microsoft.

---

TestPlayer 2.0 – Administrationshandbuch

Das Administrations-Backend des TestPlayer 2.0 basiert auf der Django-Administrationsoberfläche. Es bietet dem Plattform-Administrator eine Schnittstelle für die Tiefenkonfiguration der Systemumgebung, die Benutzerverwaltung und die Überwachung der asynchronen Ausführungsprozesse.

Figure 59 Administrations-Backend des TestPlayer 2.0.

1. Authentication and Authorization

In diesem Bereich wird die Zugriffskontrolle der Plattform gesteuert.

• Groups: Erstellung und Verwaltung von Rechtegruppen. Hier können logische Berechtigungsbündel geschnürt werden, um verschiedenen Nutzerklassen (z. B. Standard-Testern vs. Administratoren) spezifische Systemrechte gebündelt zuzuweisen.

• Users: Verwaltung aller registrierten Systembenutzer. Erlaubt das Zurücksetzen von Passwörtern, die Definition des Aktivitätsstatus sowie die Zuteilung der Benutzer zu den vorher definierten Gruppen.

2. Blog

Das Portal für die direkte Kommunikation mit den Endanwendern.

• Blog-Artikel: Das Content-Management-Modul zur Erstellung, Bearbeitung und Veröffentlichung von News-Beiträgen und Release-Notes. Die hier eingepflegten Einträge erscheinen direkt im News- & Updates-Bereich des TestPlayer Dashboards.

3. MBT_Core (Teststeuerung)

Die Kommandozentrale für die Anbindung externer Zielsysteme und das Metadaten-Management der Ausführungen.

3.1 SUT-Adapter Verwaltung (Web-UI vs. Django-Admin)

SUT-Adapter steuern die Übersetzung zwischen Modell und Ausführung. Die primäre Anlaufstelle für Fachtester und Testautomatisierer ist die SUT-Adapter Manager Web-UI (siehe Benutzerhandbuch, Kapitel 6).

Im Django-Admin-Backend (MBT_Core -> SUT Adapter) können Administratoren zusätzlich systemweite Batch-Operationen durchführen oder die Rohdaten von Adaptern inspezieren.

Figure 60 Django-Admin Sicht auf die SUT-Adapter Stamm- und Inline-Daten.

3.2 SUT-Adapter Lebenszyklus (Export / Transform / Import)

Für eine nahtlose Integration von automatisch erkannten UI-Modellen (Auto-Discovery) und manuell angereicherten Referenz-Modellen existiert ein dedizierter Workflow über die Kommandozeile (CLI). Die Datenverwaltung erfolgt dabei über JSON-Dateien im Verzeichnis mbt_core/management/data/sut_adapter/.

• Export (export_adapter): Exportiert einen bestehenden SUT-Adapter aus der Datenbank in eine JSON-Datei, um ihn als Basis oder Backup zu sichern.

• Befehl: python manage.py export_adapter "<Adapter Name>"

• Transformation (transform_adapter): Das Kernstück des Auto-Discovery Workflows. Dieses Skript nutzt Heuristic Matching (Fuzzy Matching), um strukturelle Locators (z. B. verschachtelte CSS-Pfade) aus einem Auto-Discovery-Adapter mit semantischen Locators (z. B. sauberen XPATHs) aus einem Referenz-Adapter zu verheiraten.

• Befehl: python manage.py transform_adapter "<Auto-Discovery Adapter>" "<Referenz Adapter>"

• Import (import_adapter): Lädt den erfolgreich transformierten SUT-Adapter aus der JSON-Datei zurück in die Datenbank, damit er für die Testausführung zur Verfügung steht.

• Befehl: python manage.py import_adapter "<Transformierter Adapter Name>"

Figure 61 Der Workflow: Vom Auto-Discovery Modell über Heuristic Matching bis zum produktiven Adapter.

3.3 Test Data Pools & Variablen-Mapping

Damit generierte Testfälle mit dynamischen Testdaten versorgt werden können (ohne die Testlogik fest zu codieren), unterstützt der TestPlayer 2.0 Test Data Pools.

• Variablen-Syntax: In den Event-Mappings eines SUT-Adapters können Platzhalter in Form von {{variable}} im Feld action_value definiert werden (z. B. {{travelDay}} oder {{toPort}}). Die JSON-Testdatenpools lösen diese Variablen zur Laufzeit auf.

• Heuristische Übernahme: Beim Transformieren (via transform_adapter) erkennt die Heuristik Domänen-Synonyme (z. B. destination = toPort) und übernimmt nicht nur die bevorzugten Locators, sondern auch die Variablen-Syntax ({{variable}}) automatisch in den neuen SUT-Adapter.

3.4 Test Runs

Übersicht aller asynchron gestarteten Testläufe. Erlaubt dem Administrator die direkte Einsicht in die Metadaten eines Laufs und das manuelle Löschen fehlerhafter oder verwaister Einträge, um die Datenbank sauber zu halten.

Figure 62 Übersicht aller asynchron gestarteten Testläufe.

4. Task Queue (Q2)

Dieser Sektor bietet die vollständige Kontrolle und Einsicht in den Django-Q Cluster, der für die asynchrone Playwright-Abarbeitung (MBTExecutor) im Hintergrund verantwortlich ist.

• Failed tasks: Eine essenzielle Ansicht für das Debugging. Hier landen Tasks (wie Testläufe), die aufgrund von Fehlern (z. B. Playwright-Timeouts, Netzwerkprobleme) abgebrochen wurden, inklusive der vollständigen Stacktraces.

• Queued tasks: Testläufe, die aktuell auf einen freien Hintergrund-Worker warten und noch nicht in der Ausführung sind.

• Scheduled tasks: Verwaltung von zeitgesteuerten, wiederkehrenden Aufgaben (Cronjobs).

• Successful tasks: Das historische Protokoll aller erfolgreich abgeschlossenen Hintergrund-Operationen.

Figure 63 Protokoll aller erfolgreich abgeschlossenen Hintergrund-Q2-Operationen.