Ausführungspläne (Execution Plans)

Ein Ausführungsplan (Execution Plan) organisiert Testfälle in einem ausführbaren Bündel. Sie verwenden ihn, um mehrere Tests gemeinsam auszuführen – zum Beispiel einen vollständigen End-to-End-Ablauf, der sich über mehrere Testfälle erstreckt. Zudem können Sie den Plan zeitlich planen oder ihn über Ihre CI/CD-Pipeline auslösen.

Ein Plan beantwortet drei Fragen:

1. Welche Tests sind Teil davon?
2. In welcher Reihenfolge werden sie ausgeführt (rein parallel, rein sequenziell oder eine Mischung daraus)?
3. Wie fließen Parameterwerte von früheren Tests in spätere Tests ein?

Sie erstellen einen Plan, indem Sie Tests auf dem Tab „Test-Cases“ in Gruppen organisieren. Jede Gruppe kann entweder manuell ausgewählte Tests enthalten oder durch ein Tag gesteuert werden (wird automatisch mit jedem Test befüllt, der aktuell dieses Tag trägt) – siehe Gruppen. Die Gruppenstruktur des Plans steuert die Ausführungsreihenfolge und wie Parameterwerte zwischen den Tests weitergegeben werden.

Sie verwalten Pläne unter Execution Plans in der linken Navigation. Durch Drücken von Ctrl+m auf der Listenseite wird ein neuer Plan erstellt. Die Planliste selbst ist in Ordnern organisiert – diese stehen in keinem Zusammenhang mit den unten beschriebenen Gruppen innerhalb eines einzelnen Plans.

Tabs

Ein Ausführungsplan hat vier Tabs:

Tab	Beschreibung
General	Titel, Beschreibung, Zeitplan und Setup/Teardown.
Test-Cases	Die Gruppen-/Teststruktur und Parameterbindungen.
Executions	Paginierter Verlauf jeder Ausführung dieses Plans mit Status, Dauer und Auslöserquelle. Klicken Sie auf eine Zeile, um die Ausführungsdetails zu öffnen.
Change History	Audit-Protokoll der Änderungen an der Plandefinition, mit dem gleichen Verhalten und den gleichen Einschränkungen wie bei der Change History von Tests.

Header-Aktionen

Oben rechts auf der Seite mit den Plandetails finden Sie:

• Start — führt den Plan sofort mit seiner aktuellen Konfiguration aus. Wenn der Plan mehrere Gruppen enthält, öffnet die Schaltfläche ein kleines Menü, sodass Sie auch ab einer bestimmten Gruppe starten können (nützlich, um einen fehlgeschlagenen Lauf fortzusetzen, ohne die früheren Gruppen erneut auszuführen).
• Pipeline — öffnet die CI/CD-Konfiguration zum Auslösen dieses Plans von außerhalb von msg.ZenTestAI. Siehe Pipeline-Integration weiter unten.
• Save / Delete — untere Aktionsleiste. Löschen ist dauerhaft.

Tab „General“

• Title — erforderlich.
• Description — optional.
• Setup — wird vor der ersten Gruppe ausgeführt. Kann entweder ein gespeicherter Testfall oder ein Skript sein (wählen Sie eines von beiden, nicht beides). Optional.
• Teardown — wird nach der letzten Gruppe ausgeführt, mit der gleichen Skript-oder-Test-Auswahl. Optional.
• Schedule — siehe Scheduling weiter unten.

Scheduling

Drei Modi:

• Manual — der Plan läuft nur, wenn jemand auf Start klickt oder ihn über die Pipeline auslöst.
• Time Based — By Duration — wählen Sie eine Wiederholung (alle N Minuten, Stunden, Tage, Wochen oder Monate).
• Cron — geben Sie einen Cron-Ausdruck ein. Der Editor validiert den Ausdruck während der Eingabe (mit einer kurzen Verzögerung) und zeigt eine Vorschau der nächsten geplanten Ausführungen in menschenlesbarer Form an. Cron-Ausdrücke werden in der lokalen Serverzeit interpretiert; der Editor zeigt den Offset an, damit Sie sehen, was dies für Ihre lokale Zeitzone bedeutet.

warnung

Häufige Zeitpläne können teuer werden – jeder Lauf verbraucht KI-Token und Runner-Kapazität. Wählen Sie den niedrigstmöglichen Takt, der Ihren Anforderungen entspricht, insbesondere bei Cron-Plänen.

Benachrichtigungen, Wiederholungen bei Fehlern und „Fail-Fast“ sind derzeit nicht auf Planebene konfiguriert.

Tab „Test-Cases“

Auf dem Tab „Test-Cases“ geben Sie dem Plan seine Struktur. Das Layout ist zweispaltig:

• Links — die Gruppen, die den Plan bilden.
• Rechts — eine durchsuchbare, in Ordnern organisierte Liste aller Tests im Tenant. Sie ziehen Tests von rechts nach links.

Die Ausführungssemantik ist einfach:

Tests innerhalb einer Gruppe werden parallel ausgeführt. Gruppen werden sequenziell ausgeführt, eine nach der anderen.

Gruppen

Jede Gruppe verfügt über:

• Einen Anfasser zum Verschieben/Sortieren der Gruppen.
• Ein Name-Feld (optional).
• Einen optionalen Tag-Chip. Das Entfernen des Chips macht die Gruppe statisch; das Auswählen eines Tags macht die Gruppe tag-gesteuert.
• Eine Anzeige der Ausführungsvariante (vor allem bei tag-gesteuerten Gruppen sichtbar; bei statischen Gruppen werden Varianten pro Test gewählt – siehe unten).
• Einen Löschen-Button.

Gruppen gibt es in zwei Ausführungen:

• Statische Gruppen — die Inhalte werden manuell ausgewählt. Ziehen Sie Tests aus dem rechten Bereich in die Gruppe. Sie können die Reihenfolge der Tests innerhalb der Gruppe ändern, aber die Reihenfolge hat keinen Einfluss auf die Ausführung (alles in der Gruppe läuft parallel).
• Tag-gesteuerte Gruppen — die Inhalte stammen von allen Tests, die das ausgewählte Tag tragen. Die Gruppe ist schreibgeschützt: Sie können keine Tests hinein- oder herausziehen, und der Titel ist gesperrt. Das Entfernen des Tags wandelt die Gruppe wieder in eine statische um und löscht ihre Tests.

Statisch und tag-gesteuert schließen sich gegenseitig aus – eine Gruppe ist entweder das eine oder das andere.

Um eine neue Gruppe hinzuzufügen, ziehen Sie einen Test in den gestrichelten Bereich "drop here to create a group" zwischen bestehende Gruppen oder klicken Sie auf Add new group am unteren Rand.

Auswahl der Ausführungsvariante

Wenn ein Test Varianten besitzt, können Sie auswählen, welche Variante innerhalb des Plans ausgeführt werden soll. Für statische Gruppen wird dies pro Test in der Gruppe festgelegt; tag-gesteuerte Gruppen führen jeden Test immer mit seiner Standardvariante aus.

Parameterbindungen

Jeder Test innerhalb einer statischen Gruppe hat einen kleinen Parameter-Chip, der den Dialog Parameter Bindings öffnet. Der Dialog listet jeden Parameter dieses Tests auf, mit einem von vier Bindungsmodi pro Parameter:

Modus	Funktionsweise
Map by name	Sucht nach einem Parameter mit dem gleichen Namen in den Tests einer früheren Gruppe und verwendet den dort erfassten Wert. Wenn kein früherer Test diesen liefert, schlägt der Lauf fehl.
From execution variant	Verwendet den Wert, den der Parameter in der ausgewählten Variante des Tests hat (d. h. die eigene Definition des Tests).
Hardcoded	Ein fester Wert, der direkt im Bindungsdialog eingegeben wird. Nützlich für plan-eigene Konstanten, ohne die zugrunde liegenden Testvarianten zu ändern.
From a specific source test	Wählen Sie einen bestimmten früheren Test im Plan und einen spezifischen Parameternamen für diesen Test. Verwenden Sie dies, wenn zwei frühere Tests denselben Parameternamen verwenden und Sie eine eindeutige Zuordnung benötigen.

Einige wichtige Regeln:

• Bindungen können nur rückwärts lesen. Ein Test in Gruppe 3 kann sich an Parameter binden, die in Gruppe 1 oder 2 erfasst wurden – niemals an einen späteren oder an einen parallelen Geschwister-Test.
• Parallele Tests in derselben Gruppe teilen sich keine Parameterwerte; jeder parallele Test hat seinen eigenen Geltungsbereich.
• Neue Tests, die einer Gruppe hinzugefügt werden, verwenden standardmäßig Map by name für jeden Parameter. Überprüfen Sie die Bindungen vor dem Speichern – implizite Namenszuordnungen können leicht fehlerhaft sein, wenn zwei unabhängige Tests zufällig denselben Parameternamen haben.

Es gibt keinen Bereich für plan-weite Konstanten. Verwenden Sie Hardcoded-Bindungen bei einzelnen Tests, um feste Werte einzufügen, oder setzen Sie den Wert in der Variante des Tests.

Pipeline-Integration

Die Schaltfläche Pipeline führt Sie zur Produktverwaltungsseite, auf der die Pipeline-Konfiguration für diesen Plan geöffnet ist. Von dort können Sie die Webhook-URL und den Authentifizierungs-Token kopieren, die Sie benötigen, um den Plan aus Ihrem CI/CD-System (GitHub Actions, GitLab CI, Jenkins, Azure DevOps, …) aufzurufen.

Ein über die Pipeline ausgelöster Lauf erscheint wie ein manueller Lauf auf dem Tab Executions, jedoch mit entsprechend markierter Auslöserquelle.

Tab „Executions“

Der Tab „Executions“ ist eine chronologische Tabelle aller Ausführungen dieses Plans, mit:

• Startzeit,
• Dauer,
• Endstatus,
• Auslöserquelle (manuell / geplant / Pipeline).

Klicken Sie auf eine Zeile, um die Ausführungsdetails zu öffnen, wo Sie jeden im Plan ausgeführten Test prüfen, Screenshots und Protokolle ansehen und einzelne Tests erneut ausführen können.

Einschränkungen

Dinge, die der Plan heute nicht bietet:

• Keine Parameterkonstanten auf Planebene – verwenden Sie Hardcoded-Bindungen oder setzen Sie den Wert in einer Testvariante.
• Keine Überschreibung der Ausführungsvariante pro Gruppe bei statischen Gruppen – die Variante wird pro Test gewählt.
• Keine E-Mail-Benachrichtigungen, automatische Wiederholungen oder Fail-Fast zwischen Gruppen, die auf Planebene konfiguriert werden können.
• Kein Rollback über den Tab „Change History“ – siehe Change History.