TestPlayer 2.0 – Benutzerhandbuch

Kurzfassung

Der TestPlayer 2.0 ist eine fortschrittliche, webbasierte Plattform für das Model-Based Testing (MBT) [1]. Das System ermöglicht die automatisierte Generierung von Testsuiten aus abstrakten Zustandsübergangsmodellen (z. B. im DOT-Format) [2]. Durch die Integration von Markov Chain Usage Models (MCUM) und heuristischen Algorithmen (Random Walk, Node Coverage, Edge Coverage) können zielgerichtete Testfälle berechnet werden [1]. Das integrierte Dashboard bietet eine hierarchische Dateiverwaltung sowie interaktive Visualisierungen der generierten Testfälle, Heatmaps und Zustandswahrscheinlichkeiten, um die Testabdeckung und das Systemverhalten visuell zu analysieren [3].

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 topologi-sche 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. ReturnMaster oder SignIn) 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.

Figure 7 Gerenderte Live-Vorschau stochastischer Benutzerprofile.

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 8 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 [1].

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

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

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

Figure 9 Algorithmen für die Testfallgenerierung.

6. 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 10 Übersicht der Projektdateien mit Profil-Ordnern.

6.1 Ordnerhierarchie

1. Profil-Ebene: Blaue 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.

3. Artefakt-Ebene: Unterteilt in aufklappbare Workflow-Phasen (Rohdaten, Diagramme, Reports und Visualisierung der Testläufe).

Note

Dynamische Sichtbarkeit von Profilen: Die Ansicht der Projekt-Dateien ist ein dynamischer Datei-Browser. Die blauen 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.

6.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 [1].

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

Figure 11 MCUM Analyse-Dashboard für das Basismodell.

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 [1]. Die X-Achse zeigt die Zustände alphanumerisch sortiert.

7. 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].

7.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 12 Single-Mode Representation eines einzelnen Testfalls.

Figure 13 Akkumulierte Representation einer Folge von Testfällen.

7.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 14 Testfokus und Visualisierung der Besuchshäufigkeit.

7.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 [1].

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

Figure 15 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 [1]. 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) [1]. 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 [1].

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

8. 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].

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

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

• Summary Cards: Zeigen das Ausführungs-Zeitfenster, die Gesamtdauer in ms, die Anzahl der evaluierten Testfälle und Schritte sowie eine Status-Matrix (PASS / FAIL / ERR) an.

• Testfall Breakdown: Ein aufklappbares Akkordeon, mit dem jeder Testfall und die Ergebnisse seiner einzelnen Testschritte chronologisch inspiziert werden können.

8.2 Visualisierung der Testläufe (Performance-Metriken)

Die vierte Phase bietet tiefgehende Diagramme zur Identifikation von Flaschenhälsen (Bottlenecks) im SUT [1]. 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 [1].

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

Figure 17 Chronologische Darstellung der Ausführungszeiten der kompletten Testsuite.

Detailed Test Step Execution Metrics: Um Ausreißer in der Applikationsperformance aufzudecken, werden die Ausführungszeiten aller identischen Testschritte aggregiert und evaluiert [1]:

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

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

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

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

Figure 18 Mean Execution Times: Detaillierte Ansicht der durchschnittlichen Laufzeiten pro Testschritt inklusive Buch-konformem Subtitle.

8.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.

Figure 19 Execution Times of the Complete Test Suite: Chronologischer Vergleich der Ausführungszeiten zweier interpolierter Testläufe.

Figure 20 Detailed Test Step Execution Metrics: Direkter Abgleich von Minimum, Mean, Maximum und Sum Execution Times zwischen zwei Testläufen.

9. Exportfunktionen

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

• Statistiken & Metriken: Direkter Einzel-Download als .png oder .jpg. 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.

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.

---

TestPlayer 2.0 – Administrationshandbuch

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

Figure 21 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.

• SUT Adapter: Hier werden die System-Under-Test (SUT) Profile definiert (z. B. AgileTravel WebApp Chrome Headless oder HelloTestPlayer WebApp). Ein SUT Adapter bündelt die Standard-URL, spezifische Login-Credentials für Makros und die exakten Mappings, die abstrakte Graphen-Events (z. B. e1) in konkrete UI-Lokatoren (XPath, CSS) übersetzen.

Figure 22 SUT Adapter der Webapp HelloTestPlayer.

• 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 23 Ü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 24 Protokoll aller erfolgreich abgeschlossenen Hintergrund-Q2-Operationen.