Erste Schritte

Test Workflows

Test Workflows sind der zentrale Baustein für automatisiertes Testen in Autemos. Sie bieten eine visuelle, node-basierte Darstellung der Testlogik, die es Benutzern ermöglicht, automatisierte Tests effizient zu entwerfen, anzupassen und zu debuggen.

Ein typischer Workflow besteht aus aufeinanderfolgenden Schritten wie dem Öffnen einer Anwendung, der Interaktion mit UI-Elementen, der Validierung von Ergebnissen und der Datenverwaltung. Während die meisten Workflows linear sind, unterstützt Autemos auch bedingte Logik und Schleifen für fortgeschrittenere Testszenarien.

Die Test Workflows Übersicht listet alle vorhandenen Tests mit Listen-/Kachelansicht und Suchoptionen auf.

Was Sie mit Test Workflows tun können

Aufgezeichnete Tests verfeinern und benutzerdefinierte Logik hinzufügen
Validierungen und Assertions hinzufügen, um das Anwendungsverhalten zu überprüfen
Testdaten für dynamische, wiederverwendbare Szenarien integrieren
Ausführung Schritt für Schritt mit Breakpoints und Live-Ansicht debuggen
Testbereitschaft vor der automatisierten Headless-Ausführung sicherstellen

Die visuelle Canvas — jeder Schritt wird als Node dargestellt, der eine bestimmte Aktion ausführt.

Erstellen und Bearbeiten

Die Test Workflows Übersicht listet alle vorhandenen Tests auf. Die Schaltfläche + New Workflow öffnet eine leere Canvas. Die Schaltfläche Record Workflow navigiert zum Aufzeichnungsmodul, in dem Tests mit einem Klick-Recorder oder einem KI-Chatbot erstellt werden können. Workflows können zwischen Listen- und Kachelansicht umgeschaltet, gesucht, sortiert und ausgewählt werden.

Jeder Schritt im Workflow wird durch einen Node dargestellt, der eine bestimmte Aktion ausführt, wie z. B. das Klicken auf ein Element, die Texteingabe oder die Validierung einer Bedingung.

Erste Schritte

Kernkonzepte

Lineare Ausführung

Die meisten Workflows folgen einer von oben nach unten ausgeführten Abfolge von Schritten.

Bedingte Logik

Verwenden Sie If-Nodes, um die Ausführung basierend auf Laufzeitbedingungen zu verzweigen.

Schleifen

Iterieren Sie über Daten oder wiederholen Sie Aktionen mit Loop-Nodes für datengetriebenes Testen.

Drag & Drop Bearbeitung

Nodes können direkt auf der visuellen Canvas hinzugefügt, entfernt und umsortiert werden.

Beispiel: Bedingte Logik mit einem If-Node zur Verzweigung der Ausführung.

Nodes verstehen

Nodes sind die grundlegenden Einheiten eines Test Workflows. Jeder Node repräsentiert eine einzelne Aktion oder Operation:

Interaktion mit UI-Elementen (Click, Type)
Informationen erfassen (Extract Text, Screenshot)
Verhalten validieren (Assert, Soft Verify)
Daten verwalten (Test Data, Input-Variablen)
Ablauf steuern (If, Loop, Wait)

Nodes können je nach Typ mit Variablen und gespeicherten Daten interagieren. Eine detaillierte Dokumentation für jeden Node ist in den Node-Referenzabschnitten weiter unten verfügbar.

Node-Panel — verfügbare Node-Kategorien

Mit Testdaten und Variablen arbeiten

Test Workflows unterstützen eine flexible Datenverwaltung für dynamische und wiederverwendbare Tests. Daten können in Variablen gespeichert, während der Ausführung zwischengespeichert und in späteren Schritten wiederverwendet werden.

Werte in Workflow-Variablen speichern und schrittübergreifend wiederverwenden
Den Test Data Easy-Node verwenden, um tabellarische Datensätze inline zu binden
Auf Zeilendaten zugreifen über {{easyData.field}} oder {{easyDataRecords.0.field}}
Extern verwaltete Datensätze für die workflow-übergreifende Wiederverwendung verknüpfen

Test Data Easy — Datensatz direkt im Workflow binden.

Unterstützte Testtypen

Test Workflows unterstützen mehrere Testtypen innerhalb eines einzelnen Ablaufs — unabhängig oder kombiniert:

Web-Testing — browserbasierte UI-Automatisierung
Mobile Testing — iOS- und Android-App-Tests
API-Testing — direkte HTTP-Request-Validierung

Dies ermöglicht End-to-End-Szenarien wie: Mobile Aktion → API-Validierung → Web-Überprüfung.

Erste Schritte

Ihren ersten Test Workflow in 5 Minuten erstellen

Dieses Schnell-Tutorial führt Sie durch das Erstellen, Verfeinern und Debuggen eines einfachen Test Workflows in Autemos. Am Ende werden Sie einen funktionierenden, testbereiten Workflow haben.

Einen Test Workflow öffnen

Im Demo-Projekt finden Sie Beispieltests für Mobile, Web und einen kombinierten Ablauf. Nach der Auswahl eines Tests sehen Sie die Workflow-Canvas, auf der jeder Schritt als Node dargestellt ist. Aufgezeichnete Workflows umfassen typischerweise den App-Start, grundlegende Benutzerinteraktionen und Navigationsschritte.

Die Workflow-Struktur prüfen

Scannen Sie den Workflow von oben nach unten. Achten Sie auf eine klare Schrittabfolge (z. B. Login → Navigate → Aktion), fehlende Validierungen und fest codierte oder unklare Werte. In dieser Phase sind die meisten Workflows funktionsfähig, aber noch nicht robust oder wiederverwendbar.

Eine Validierung hinzufügen

Fügen Sie nach einer wichtigen Aktion einen Assert- oder Soft Verify-Node hinzu, um zu überprüfen, ob ein Bildschirm sichtbar ist, ein Wert korrekt ist oder ein Element vorhanden ist.

💡Verwenden Sie Soft Verify, wenn der Test auch bei einem fehlgeschlagenen Check fortgesetzt werden soll.

Testdaten einführen

Ersetzen Sie statische Werte durch dynamische Daten mithilfe des Test Data Easy-Nodes. Fügen Sie den Node direkt nach dem Startnode am Anfang des Workflows ein. Dadurch kann Ihr Workflow mit verschiedenen Datensätzen ausgeführt und szenarioübergreifend wiederverwendet werden.

Aufräumen und Strukturieren

Benennen Sie Nodes zur besseren Übersicht um (z. B. "Click Button" → "Click Login"), gruppieren Sie logische Schritte gedanklich (Login, Navigation, Aktion) und entfernen Sie unnötige Schritte. Ein übersichtlicher Workflow ist einfacher zu debuggen und zu pflegen.

Den Workflow debuggen

Wechseln Sie in den Debug-Modus. Setzen Sie einen Breakpoint bei einem kritischen Schritt, führen Sie den Workflow aus, arbeiten Sie Schritt für Schritt und beobachten Sie das Verhalten in der Live-Ansicht. Nutzen Sie das Execution Log, um Timing, Erfolg/Fehler und Fehler zu überprüfen. Beheben Sie Probleme sofort.

Testbereitschaft bestätigen

Ihr Workflow ist bereit, wenn: alle Schritte erfolgreich ausgeführt werden, Validierungen vorhanden sind, Testdaten korrekt konfiguriert sind und beim Debuggen keine blockierenden Fehler auftreten. Der Workflow kann nun zuverlässig in automatisierten Runs über den Scheduler ausgeführt werden.

Erste Schritte

Einen Workflow debuggen

Autemos bietet leistungsstarke Debugging-Funktionen, um sicherzustellen, dass Workflows wie erwartet funktionieren. Wechseln Sie direkt von der Workflow-Canvas zwischen Run- und Debug-Modus.

Zwischen Run- und Debug-Modus über die Canvas-Toolbar umschalten.

Debug-Modus

Beim Ausführen eines Workflows im Debug-Modus können Sie:

Breakpoints bei kritischen Schritten setzen
Schritte einzeln mit der Step-Schaltfläche ausführen
Die Ausführung jederzeit fortsetzen oder anhalten

Debug controls — Resume, Step, Stop, Paused

Debug-Steuerelemente — Resume, Step, Stop und Paused-Zustand.

Breakpoints setzen, um die Workflow-Ausführung bei einem bestimmten Schritt anzuhalten und zu untersuchen.

Execution Log

Das Execution Log liefert schrittweise Statusaktualisierungen, Ausführungszeiten und detaillierte Fehlerinformationen. Verwenden Sie es, um genau zu ermitteln, welcher Schritt fehlgeschlagen ist und warum.

Live-Ausführungsansicht

Live Device View — Echtzeit-Interaktion mit der Anwendung während der Ausführung beobachten.

Für UI-basierte Tests (Web oder Mobile) zeigt eine Live-Ansicht die Echtzeit-Interaktion mit der Anwendung, eine visuelle Bestätigung jedes Schritts und die Möglichkeit, die Ansicht in einem separaten Tab zu öffnen. Dies erleichtert die schnelle Identifizierung und Behebung von Problemen.

Erste Schritte

Error Handling & Soft Verify

Workflows unterstützen flexible Fehlerbehandlungsstrategien.

Standardverhalten

Standardmäßig stoppt ein Workflow die Ausführung, wenn ein Schritt fehlschlägt. Dies ist die sicherste Option und stellt sicher, dass Probleme sofort sichtbar werden.

Soft Verify

Bei Verwendung von Soft Verify werden Fehler protokolliert und die Ausführung fortgesetzt. Dies ist nützlich, wenn mehrere Validierungen ausgeführt werden sollen und Sie ein vollständiges Testergebnis anstelle eines vorzeitigen Abbruchs wünschen.

Ein fehlgeschlagener Schritt zeigt die Fehlerdetails inline an — XPath- oder Selector-Probleme werden direkt am Node angezeigt.

Wann welchen Ansatz verwenden

Standard (Bei Fehler stoppen)

Verwenden Sie dies, wenn ein Schrittfehler alle nachfolgenden Schritte sinnlos macht. Wenn z. B. der Login fehlschlägt, macht eine Fortsetzung keinen Sinn.

Soft Verify (Fortsetzen)

Verwenden Sie dies, wenn Sie alle Validierungsfehler in einem einzigen Run sammeln möchten, z. B. bei Formularfeldvalidierungen oder UI-Zustandsüberprüfungen.

Einen Workflow für die Ausführung vorbereiten

Bevor ein Workflow automatisch im Headless-Modus ausgeführt werden kann (z. B. in einem Scheduler), muss er testbereit sein. Ein Test gilt als bereit, wenn:

Alle Schritte erfolgreich ausgeführt werden
Datenabhängigkeiten aufgelöst sind
Keine blockierenden Fehler mehr vorhanden sind

Erste Schritte

Self-Healing

Autemos bietet Self-Healing-Funktionen für die Element-Identifikation. Wenn sich ein UI-Element zwischen Testläufen ändert — z. B. wenn eine CSS-Klasse, ID oder ein Attribut geändert wird — kann das System versuchen, sich automatisch zu erholen.

Self-Healing — automatische Wiederherstellung bei UI-Änderungen.

Geringere Instabilität

Tests funktionieren auch bei kleineren UI-Änderungen ohne manuellen Eingriff weiterhin.

Geringerer Wartungsaufwand

Self-Healing reduziert den Zeitaufwand für die Aktualisierung von Selectors nach Anwendungsupdates.

💡Self-Healing funktioniert am besten, wenn Elemente im Page Object Repository mit mehreren Selector-Strategien registriert sind. Je mehr Fallback-Strategien verfügbar sind, desto höher ist die Wiederherstellungsrate.

Open Browser

Browser

Der Open Browser-Node startet eine neue Browser-Instanz für die Ausführung webbasierter Testschritte. Er definiert den Ausführungskontext, einschließlich der Zielplattform und ob der Browser im Headless-Modus läuft.

Wann verwenden

Start eines Web-Test-Workflows
Definition der Ausführungsumgebung für browserbasiertes Testen
Ausführung von Tests auf einer bestimmten Plattform oder Konfiguration
Vorbereitung von Workflows für lokales Debugging oder automatisierte Ausführung

💡Dieser Node ist typischerweise der erste Schritt in jedem Web-Test-Workflow.

Open Browser Konfiguration — Plattform und Headless-Modus auswählen.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Headless	Führt den Browser ohne sichtbare Benutzeroberfläche aus	No	`true`
Platform	Definiert die Ziel-Ausführungsplattform	Yes	`Chrome`
Test Type	Definiert die Art der Testausführung	Yes	`Web`

Verhalten

Initialisiert eine neue Browser-Session
Wendet die ausgewählte Plattform und Konfiguration an
Startet den Browser im sichtbaren Modus (zum Debuggen) oder im Headless-Modus (für automatisierte Ausführung)
Bereitet die Umgebung für alle nachfolgenden Browser-Interaktionen vor

Ausgabe

Keine direkte Ausgabe. Der Node etabliert eine Browser-Session, die von allen nachfolgenden Schritten verwendet wird.

Input Variables

Output Variables

Fehlerbehandlung

Stoppt die Ausführung, wenn der Browser nicht gestartet werden kann
Stoppt die Ausführung, wenn die ausgewählte Plattform oder Konfiguration ungültig ist

Beispiel — Einen Chrome-Web-Test starten

Parameter	Wert
Headless	`false`
Platform	`Chrome`
Test Type	`Web`

Best Practices

Verwenden Sie den nicht-Headless-Modus während der Entwicklung und des Debuggings
Verwenden Sie den Headless-Modus für automatisierte und geplante Ausführungen
Stellen Sie sicher, dass die richtige Plattform für Ihr Testszenario ausgewählt ist
Behalten Sie diesen Node am Anfang Ihres Workflows
Vermeiden Sie das Mischen mehrerer Browser-Sessions innerhalb eines einzelnen Workflows, sofern nicht ausdrücklich erforderlich

Navigate

Browser

Der Navigate-Node öffnet eine bestimmte URL in der aktiven Browser-Session. Er wird typischerweise nach einem Open Browser-Node verwendet, um die Anwendung oder Seite zu laden, auf der der Test beginnen soll.

Wann verwenden

Öffnen der initialen Anwendungs-URL
Direkte Navigation zu einer bestimmten Seite oder einem Deep Link
Start eines Workflows aus einer umgebungsabhängigen Anwendungskonfiguration

💡Verwenden Sie das Feld Application, wenn die URL von der ausgewählten Umgebung abhängen soll (dev, staging, production).

Navigate Konfiguration — URL direkt eingeben oder eine Application für umgebungsabhängige Navigation auswählen.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Application	Projektanwendung zur Auflösung der Ziel-URL basierend auf der ausgewählten Umgebung	No	`Customer Portal`
URL	Direkte URL oder Pfad zur Navigation	Yes	`https://example.com/login`
Wait Until	Definiert, wann die Navigation als abgeschlossen gilt	No	`load`

* Die URL kann direkt angegeben oder über die ausgewählte Anwendungskonfiguration aufgelöst werden.

Wait Until Optionen

Option	Beschreibung
`load`	Fährt fort, nachdem das vollständige Seitenladereignis ausgelöst wurde
`domcontentloaded`	Fährt fort, wenn das initiale HTML geladen und geparst wurde
`networkidle`	Fährt fort, wenn die Netzwerkaktivität inaktiv geworden ist

Verhalten

Verwendet die aktive Browser-Session
Löst das Ziel aus der ausgewählten Application oder einer angegebenen URL auf
Navigiert den Browser zur Zielseite
Wartet, bis die konfigurierte Seitenladesbedingung erfüllt ist
Schlägt fehl, wenn die Navigation nicht abgeschlossen werden kann

Ausgabe

Keine Ausgabe.

Input Variables

Yes

Output Variables

Beispiel — Zu einer Login-Seite navigieren

Parameter	Wert
Application	`Customer Portal`
URL	`/login`
Wait Until	`load`

Best Practices

Platzieren Sie Navigate direkt nach Open Browser für Web-Workflows
Bevorzugen Sie Application-basierte Navigation für umgebungsabhängige Tests
Wählen Sie networkidle sorgfältig — Apps mit kontinuierlichen Hintergrundanfragen werden möglicherweise nie inaktiv
Fügen Sie nach der Navigation einen Assert- oder Soft Verify-Node hinzu, um zu bestätigen, dass die erwartete Seite angezeigt wird

Close Browser

Browser

Der Close Browser-Node beendet die aktive Browser-Session. Er wird typischerweise am Ende eines Test Workflows verwendet, um Ressourcen freizugeben und die Ausführung abzuschließen.

Wann verwenden

Beenden eines Web-Test-Workflows
Freigabe von Browser-Ressourcen nach der Ausführung
Sicherstellen eines sauberen Test-Lebenszyklus für wiederholte oder geplante Ausführungen

💡Dieser Node wird üblicherweise am Ende eines Workflows platziert.

Close Browser Konfiguration — Keep Alive optional für Debugging-Sessions aktivieren.

Configuration

Parameter	Description	Required	Example
Keep Alive	Hält die Browser-Session nach der Ausführung offen (nützlich für das Debugging)	No	`false`

Verhalten

Schließt die aktive Browser-Session und beendet alle Interaktionen
Gibt zugehörige Ressourcen frei
Wenn Keep Alive aktiviert ist: Die Browser-Session bleibt offen — nützlich für Debugging oder manuelle Inspektion

Ausgabe

Keine Ausgabe.

Input Variables

Output Variables

Beispiel — Browser am Ende des Workflows schließen

Parameter	Wert
Keep Alive	`false`

Verwenden Sie Keep Alive = true nur beim Debugging, um den Endzustand zu überprüfen.

Best Practices

Platzieren Sie diesen Node am Ende Ihres Workflows
Verwenden Sie Keep Alive = true nur beim Debugging
Schließen Sie Sessions bei automatisierten Runs immer, um Ressourcenlecks zu vermeiden

Type

UI Interaction

Der Type-Node gibt Text in ein bestimmtes Eingabefeld ein. Er wird verwendet, um Benutzereingaben in Formularen, Suchfeldern, Anmeldemasken oder beliebigen bearbeitbaren UI-Elementen zu simulieren.

Wann verwenden

Text in Eingabefelder eingeben
Formulare ausfüllen (z. B. Name, E-Mail, Passwort)
Dynamische Werte aus Testdaten bereitstellen
Realistisches Benutzer-Tippverhalten simulieren

💡Verwenden Sie stattdessen Select, wenn das Feld die Auswahl aus vordefinierten Optionen erfordert.

Type Konfiguration — Zielfeld und einzugebenden Wert angeben.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Field	Ziel-Eingabefeld	Yes	`LoginPage.passwordField`
Value	Einzugebender Text	Yes	`MySecret123`
Bindings	Erlaubt dynamische Werte aus Variablen oder Testdaten	No	`${password}`
Clear First	Löscht vorhandenen Inhalt vor der Eingabe	No	`true`

Verhalten

Wartet, bis das Ziel-Eingabefeld verfügbar und interaktionsfähig ist
Löscht optional vorhandenen Inhalt, wenn Clear First aktiviert ist
Gibt den angegebenen Wert ein und löst eingabebezogene Ereignisse aus
Schlägt fehl, wenn das Feld nicht gefunden oder nicht damit interagiert werden kann

Ausgabe

Keine Ausgabe.

Input Variables

Yes

Output Variables

Beispiel — Einen Verifizierungscode eingeben

Parameter	Wert
Field	`VerificationPage.codeField`
Value	`123456`
Clear First	`true`

Best Practices

Aktivieren Sie Clear First, wenn Felder bereits Werte enthalten könnten
Verwenden Sie Bindings für dynamische und wiederverwendbare Testeingaben
Vermeiden Sie das Hardcodieren von sensiblen Daten (z. B. Passwörtern)
Fügen Sie einen Assert- oder Soft Verify-Node hinzu, um zu validieren, dass der korrekte Wert angewendet wurde
Verwenden Sie stabile Eingabefelder aus dem Page Object Repository

Click

UI Interaction

Der Click-Node führt eine Klick- oder Tipp-Aktion auf einem bestimmten UI-Element aus. Er wird verwendet, um Schaltflächen auszulösen, zwischen Bildschirmen zu navigieren und Formulare abzusenden.

Wann verwenden

Schaltflächen oder Links auslösen
Zwischen Bildschirmen navigieren
Formulare absenden

Click Konfiguration — Zielelement aus dem Page Object Repository auswählen.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Field	Ziel-UI-Element	Yes	`LoginPage.loginButton`
Timeout	Maximale Wartezeit in Millisekunden	No	`5000`

Verhalten

Wartet, bis das Element sichtbar ist
Führt die Klick-Aktion aus
Schlägt fehl, wenn das Element nicht innerhalb des Timeouts gefunden wird

Ausgabe

Keine Ausgabe.

Input Variables

Output Variables

Beispiel — Die Login-Schaltfläche klicken

Parameter	Wert
Field	`LoginPage.loginButton`

Best Practices

Verwenden Sie Elemente aus dem Page Object Repository für Stabilität
Stellen Sie sicher, dass das Element vor der Interaktion sichtbar ist
Profitiert von Self-Healing, wenn sich die Element-Identifikation ändert

Double Click

UI Interaction

Der Double Click-Node führt eine Doppelklick-Aktion auf einem bestimmten UI-Element aus. Er wird für Interaktionen verwendet, die eine schnelle Zweifach-Klick-Eingabe erfordern, wie das Öffnen von Elementen, das Aktivieren von Bearbeitungsmodi oder das Auslösen erweiterter UI-Verhaltensweisen.

Wann verwenden

Ein einzelner Klick reicht nicht aus, um die gewünschte Aktion auszulösen
Interaktion mit Elementen, die Doppelklick erfordern (z. B. Listen, Tabellen, Datei-Explorer)
Aktivierung von Bearbeitungs- oder Detailansichten in Desktop-ähnlichen Webanwendungen

💡Wenn ein einzelner Klick funktioniert, bevorzugen Sie der Einfachheit halber den Click-Node.

Double Click Konfiguration — das Element auswählen, das eine Doppelklick-Interaktion erfordert.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Field	Ziel-UI-Element oder Selector	Yes	`UserList.firstRow`
Timeout	Maximale Wartezeit in Millisekunden	No	`5000`

Verhalten

Wartet, bis das Zielelement verfügbar und interaktionsfähig ist
Führt zwei schnelle aufeinanderfolgende Klick-Aktionen auf dem Element aus
Das Timing zwischen den Klicks wird automatisch gesteuert
Schlägt fehl, wenn das Element nicht innerhalb des definierten Timeouts gefunden wird

Ausgabe

Keine Ausgabe.

Fehlerbehandlung

Stoppt die Ausführung, wenn das Element nicht gefunden oder nicht damit interagiert werden kann
Kann mit Soft Verify kombiniert werden, um die Ausführung bei einem Fehler fortzusetzen
Profitiert von Self-Healing, wenn sich die Element-Identifikation ändert

Input Variables

Output Variables

Beispiel — Einen Datensatz per Doppelklick öffnen

Parameter	Wert
Field	`UserList.firstRow`
Timeout	`5000`

Diese Aktion öffnet die Detailansicht per Doppelklick.

Best Practices

Verwenden Sie Double Click nur, wenn er von der Anwendung ausdrücklich benötigt wird
Stellen Sie sicher, dass das Element sichtbar und nicht verdeckt ist, bevor es ausgeführt wird
Vermeiden Sie Double Click als Workaround für Timing-Probleme

Right Click

UI Interaction

Der Right Click-Node führt eine Rechtsklick-Aktion auf einem bestimmten UI-Element aus. Er wird typischerweise verwendet, um Kontextmenüs zu öffnen oder sekundäre Aktionen auszulösen, die über einen Standardklick nicht verfügbar sind.

Wann verwenden

Ein Kontextmenü öffnen
Auf sekundäre Aktionen eines Elements zugreifen
Mit Tabellenzeilen, Karten, Dateien oder Listenelementen interagieren
Desktop-ähnliches Verhalten in Webanwendungen testen

Right Click Konfiguration — das Element auswählen, auf das geklickt werden soll.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Field	Ziel-UI-Element oder Selector	Yes	`UserList.firstRow`
Timeout	Maximale Wartezeit in Millisekunden	No	`5000`

Verhalten

Wartet, bis das Zielelement verfügbar und interaktionsfähig ist
Führt eine Rechtsklick-Aktion auf dem Element aus
Öffnet typischerweise das Kontextmenü des Elements
Schlägt fehl, wenn das Element nicht gefunden oder nicht damit innerhalb des Timeouts interagiert werden kann

Ausgabe

Keine Ausgabe.

Fehlerbehandlung

Stoppt die Ausführung, wenn das Zielelement nicht gefunden oder nicht damit interagiert werden kann
Kann mit Soft Verify kombiniert werden, um die Ausführung bei einem Fehler fortzusetzen
Profitiert von Self-Healing, wenn sich die Element-Identifikation ändert

Input Variables

Output Variables

Beispiel — Das Kontextmenü für einen Benutzerdatensatz öffnen

Parameter	Wert
Field	`UserList.firstRow`
Timeout	`5000`

Nachdem das Kontextmenü geöffnet ist, fahren Sie im Workflow mit einem Click-Node fort, um die gewünschte Menüoption auszuwählen.

Best Practices

Folgen Sie mit einem Click-Node, um die gewünschte Menüoption auszuwählen
Fügen Sie einen Validierungsschritt hinzu, um zu bestätigen, dass das erwartete Kontextmenü erscheint
Verlassen Sie sich nicht auf browsernative Kontextmenüs — das Verhalten kann zwischen Browsern variieren

Hover

UI Interaction

Der Hover-Node bewegt den Cursor über ein bestimmtes UI-Element, ohne einen Klick auszuführen. Er wird verwendet, um hover-basierte Verhaltensweisen wie Tooltips, Dropdown-Menüs oder versteckte UI-Elemente auszulösen.

Wann verwenden

Ein Menü oder Element erscheint nur beim Hovern
Tooltips oder Overlays auslösen
Versteckte Schaltflächen oder Aktionen einblenden
UI-Verhalten testen, das von Mausbewegungen abhängt

💡Wenn dieselbe Aktion durch einen Klick ausgelöst werden kann, bevorzugen Sie Click für bessere Stabilität.

Hover Konfiguration — das Element auswählen, über das gehovt werden soll.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Field	Ziel-UI-Element oder Selector	Yes	`Navigation.menuItem`
Timeout	Maximale Wartezeit in Millisekunden	No	`5000`

Verhalten

Wartet, bis das Zielelement verfügbar und sichtbar ist
Bewegt den Cursor über das Element
Löst jegliches hover-basiertes UI-Verhalten aus (z. B. Dropdowns, Tooltips)
Führt keinen Klick oder weitere Interaktion aus
Schlägt fehl, wenn das Element nicht innerhalb des Timeouts gefunden wird

Ausgabe

Keine Ausgabe.

Fehlerbehandlung

Stoppt die Ausführung, wenn das Element nicht gefunden oder gehovt werden kann
Kann mit Soft Verify kombiniert werden, um die Ausführung bei einem Fehler fortzusetzen
Profitiert von Self-Healing, wenn sich die Element-Identifikation ändert

Input Variables

Output Variables

Beispiel — Ein Dropdown-Menü per Hover öffnen

Parameter	Wert
Field	`Navigation.productsMenu`
Timeout	`5000`

Folgen Sie diesem Schritt mit einem Click-Node, um eine Option aus dem Dropdown auszuwählen.

Best Practices

Kombinieren Sie mit einem Folgeschritt (z. B. Click oder Assert), um das Ergebnis zu validieren
Stellen Sie sicher, dass das Element vor dem Hovern sichtbar ist
Vermeiden Sie es, sich auf reine Hover-Interaktionen zu verlassen, wenn Alternativen vorhanden sind

Drag & Drop

UI Interaction

Der Drag & Drop-Node bewegt ein UI-Element von einem Ort zum anderen. Er wird verwendet, um Interaktionen wie das Verschieben von Elementen zwischen Listen, das Umsortieren von Elementen, das Hochladen per Drop-Zone oder die Arbeit mit visuellen Editoren zu testen.

Wann verwenden

Ein Element von einem Quellelement zu einem Zielbereich verschieben
Drag-and-Drop-Verhalten in Web- oder Mobile-Anwendungen testen
Elemente in einer Liste neu anordnen oder Objekte in Container ablegen

Drag & Drop Konfiguration — Quellelement und Ziel-Drop-Bereich definieren.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Source Field	Zu ziehendes UI-Element	Yes	`KanbanCard.todoItem`
Target Field	UI-Element oder Bereich, in den das Quellelement abgelegt werden soll	Yes	`KanbanColumn.inProgress`

Verhalten

Wartet, bis sowohl Quell- als auch Zielelemente verfügbar und interaktionsfähig sind
Zieht das Quellelement zum Zielort und lässt es los
Schlägt fehl, wenn eines der Elemente nicht innerhalb des Timeouts gefunden wird

Ausgabe

Keine Ausgabe.

Input Variables

Output Variables

Beispiel — Eine Aufgabenkarte von "To Do" nach "In Progress" verschieben

Parameter	Wert
Source Field	`TaskBoard.todoCard`
Target Field	`TaskBoard.inProgressColumn`

Best Practices

Verwenden Sie stabile Page Object Repository-Elemente für Quelle und Ziel
Fügen Sie nach der Aktion einen Assert- oder Soft Verify-Node hinzu, um zu bestätigen, dass das Element erfolgreich verschoben wurde
Vermeiden Sie genaue Pixel-Positionen, wenn element-basiertes Ziehen verfügbar ist
Bevorzugen Sie einfachere Interaktionen, wenn die Anwendung eine schaltflächenbasierte Alternative bietet

Press Key

UI Interaction

Der Press Key-Node sendet einen Tastendruck an ein ausgewähltes UI-Element. Er wird für tastaturgesteuerte Interaktionen wie das Absenden von Formularen, das Wechseln zwischen Feldern, das Schließen von Dialogen oder das Auslösen von Tastenkombinationen verwendet.

Wann verwenden

Formular mit Enter absenden
Mit Tab zum nächsten Feld wechseln
Dialog mit Escape schließen
Barrierefreiheit oder Tastaturnavigation testen

💡Wenn die Aktion zuverlässig mit einem Click-Node ausgeführt werden kann, bevorzugen Sie Click für bessere Lesbarkeit.

Press Key Konfiguration — Zielelement und zu sendende Taste auswählen.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Field	Ziel-UI-Element, das den Tastendruck erhalten soll	Yes	`LoginPage.passwordField`
Key	Zu sendende Taste	Yes	`Enter`

Verhalten

Wartet, bis das ausgewählte Feld oder Element verfügbar ist
Fokussiert das Zielelement wenn erforderlich
Sendet den konfigurierten Tastendruck
Löst das entsprechende Anwendungsverhalten aus
Schlägt fehl, wenn das Zielelement nicht gefunden oder der Tastendruck nicht ausgeführt werden kann

Ausgabe

Keine Ausgabe.

Fehlerbehandlung

Stoppt die Ausführung, wenn das Zielelement nicht gefunden oder nicht damit interagiert werden kann
Kann mit Soft Verify kombiniert werden, um die Ausführung bei einem Fehler fortzusetzen
Profitiert von Self-Healing, wenn sich die Element-Identifikation ändert

Input Variables

Output Variables

Beispiel — Ein Login-Formular mit Enter absenden

Parameter	Wert
Field	`LoginPage.passwordField`
Key	`Enter`

Der Tastendruck sendet das Formular ab und löst den nächsten Seitenladevorgang aus.

Best Practices

Wählen Sie das Element aus, das den Tastendruck erhalten soll
Verwenden Sie Tab und Escape sorgfältig — das Verhalten variiert je nach Fokuszustand
Fügen Sie nach dem Tastendruck einen Assert- oder Soft Verify-Node hinzu, um das erwartete Ergebnis zu validieren

Scroll

UI Interaction

Der Scroll-Node scrollt den Viewport entweder zu einem bestimmten UI-Element oder zu einer definierten Position anhand von Koordinaten. Er bringt Elemente in den sichtbaren Bereich oder steuert das Scroll-Verhalten explizit in komplexen Layouts.

Wann verwenden

Ein Element ist im aktuellen Viewport nicht sichtbar
Vorbereitung für Interaktionen wie Click oder Type
Scroll-Verhalten testen (z. B. Lazy Loading, lange Seiten)
Zu einer bestimmten Position innerhalb einer Seite oder eines Containers scrollen

💡Viele Interaktionen scrollen automatisch in den sichtbaren Bereich. Verwenden Sie diesen Node nur, wenn eine explizite Scroll-Steuerung erforderlich ist.

Scroll Konfiguration — zwischen element-basiertem und koordinaten-basiertem Scrollen wählen.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Field	Ziel-UI-Element (verwendet beim Scrollen zu einem Element)	No	`CheckoutPage.submitButton`
Scroll To	Definiert den Scroll-Modus (Element oder Position)	Yes	`element`
X	Horizontaler Scroll-Versatz in Pixeln (Positionsmodus)	No	`0`
Y	Vertikaler Scroll-Versatz in Pixeln (Positionsmodus)	No	`500`

* Field ist nur erforderlich, wenn Scroll To = element.

Scroll-Modi

Scroll To Element

Scrollt, bis das Zielelement im Viewport sichtbar ist.

Scroll To Position

Scrollt zu den angegebenen X/Y-Koordinaten ohne ein UI-Element zu benötigen.

Ausgabe

Keine Ausgabe.

Input Variables

Output Variables

Beispiel — Zu einem Element scrollen

Parameter	Wert
Field	`CheckoutPage.submitButton`
Scroll To	`element`

Beispiel — Zu einer Position scrollen

Parameter	Wert
Scroll To	`position`
X	`0`
Y	`800`

Best Practices

Bevorzugen Sie element-basiertes Scrollen für Stabilität
Vermeiden Sie fest codierte Koordinaten, wenn ein Page Object-Element verfügbar ist
Kombinieren Sie mit einer Folgeaktion (z. B. Click oder Assert)
Stellen Sie sicher, dass der richtige Scroll-Container in komplexen Layouts angesprochen wird

Select

UI Interaction

Der Select-Node wählt eine Option aus einem Dropdown-Feld aus. Er wird für Formulare, Filter, Konfigurationsfelder oder beliebige UI-Elemente verwendet, bei denen der Benutzer einen Wert aus einer Liste verfügbarer Optionen auswählen muss.

Wann verwenden

Einen Wert aus einem Dropdown auswählen
Formularfelder mit vordefinierten Optionen setzen
Filter oder Kategorien anwenden
Dynamische Werte über Bindings verwenden

💡Verwenden Sie Type nur, wenn das Feld Freitext erwartet. Verwenden Sie Select, wenn der Wert aus vordefinierten Optionen gewählt werden muss.

Select Konfiguration — Ziel-Dropdown, Wert und Auswahlstrategie wählen.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Field	Dropdown-Feld für die Interaktion	Yes	`PaymentPage.countryDropdown`
Value	Auszuwählender Optionswert	Yes	`Switzerland`
Bindings	Erlaubt die dynamische Bereitstellung des Werts	No	`country`
Select By	Definiert, wie die Option ausgewählt werden soll	Yes	`value`

Select By Optionen

Option	Beschreibung
`value`	Wählt die Option anhand ihres zugrunde liegenden Werts aus (z. B. `CH`)
`text`	Wählt die Option anhand ihres sichtbaren Labels aus (z. B. `Switzerland`)
`index`	Wählt die Option anhand ihrer Position in der Liste aus (z. B. `2`)

Verhalten

Wartet, bis das Dropdown-Feld verfügbar ist
Sucht die passende Option basierend auf der ausgewählten Strategie (Text, Wert oder Index)
Wählt die passende Option aus
Schlägt fehl, wenn das Feld oder die Option nicht gefunden werden können

Ausgabe

Keine Ausgabe.

Input Variables

Yes

Output Variables

Beispiel — Ein Land aus einem Zahlungsformular auswählen

Parameter	Wert
Field	`PaymentPage.countryDropdown`
Value	`Switzerland`
Select By	`text`

Best Practices

Bevorzugen Sie die Auswahl nach sichtbarem Text, wenn der Wert für Benutzer bedeutsam ist
Verwenden Sie Bindings, wenn Dropdown-Werte aus Testdaten kommen sollen
Vermeiden Sie index-basierte Auswahl, außer wenn die Reihenfolge der Optionen stabil ist
Fügen Sie nach der Auswahl einen Assert- oder Soft Verify-Node hinzu, um zu bestätigen, dass der Wert angewendet wurde

Screenshot

UI Interaction

Der Screenshot-Node erstellt ein Bild des aktuellen Anwendungszustands während der Testausführung. Er kann entweder den sichtbaren Viewport oder die gesamte Seite erfassen, je nach Konfiguration.

Wann verwenden

Testausführungsschritte dokumentieren
Beweise für Testergebnisse erfassen
Probleme während der Ausführung debuggen
Wichtige Checkpoints in einem Workflow aufzeichnen

💡Besonders nützlich nach wichtigen Schritten, z. B. nach dem Login, vor der Einreichung oder wenn eine Validierung fehlschlägt.

Screenshot Konfiguration — Screenshot benennen und optional die Ganzseitenerfassung aktivieren.

Verhalten

Erfasst den aktuellen Zustand der Anwendung zur Laufzeit
Wenn Full Page aktiviert ist: Scrollt und erfasst die gesamte Seite
Andernfalls: Erfasst nur den sichtbaren Viewport
Setzt die Ausführung unmittelbar nach der Aufnahme fort

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Name	Name der Screenshot-Datei	Yes	`login_success`
Bindings	Erlaubt dynamische Benennung über Variablen	No	`${testStep}_screenshot`
Full Page	Erfasst die gesamte Seite anstatt nur des sichtbaren Viewports	No	`true`

Verhalten

Erfasst den aktuellen Zustand der Anwendung zur Laufzeit
Speichert den Screenshot mit dem definierten Namen
Wenn Full Page aktiviert ist: Scrollt und erfasst die gesamte Seite
Andernfalls: Erfasst nur den sichtbaren Viewport
Setzt die Ausführung unmittelbar nach der Aufnahme fort

Ausgabe

Screenshot-Datei, gespeichert als Teil der Testausführungsergebnisse.

Fehlerbehandlung

Schlägt typischerweise nicht fehl, außer wenn die Screenshot-Aufnahme nicht möglich ist
Kann mit Soft Verify kombiniert werden, wenn in Validierungsabläufen verwendet
Hat keinen Einfluss auf den Anwendungszustand

Input Variables

Yes (für die Benennung)

Output Variables

Beispiel — Einen Screenshot nach dem Login aufnehmen

Parameter	Wert
Name	`after_login`
Full Page	`false`

Best Practices

Verwenden Sie aussagekräftige Namen zur einfachen Identifikation von Screenshots
Erfassen Sie Screenshots an kritischen Punkten (vor/nach wichtigen Aktionen)
Vermeiden Sie zu viele Screenshots, um die Ausführung schlank zu halten
Verwenden Sie Full Page nur wenn nötig — kann die Performance beeinträchtigen

Upload File

UI Interaction

Der Upload File-Node lädt eine Datei in eine Anwendung über ein Datei-Eingabeelement hoch. Er simuliert die Auswahl einer Datei zum Hochladen durch den Benutzer, ohne mit dem nativen Dateiauswahl-Dialog zu interagieren.

Wann verwenden

Dokumente, Bilder oder Anhänge hochladen
Datei-Upload-Funktionalität in Formularen testen
Dateien für Importprozesse bereitstellen
Szenarien automatisieren, die eine Dateiauswahl erfordern

💡Dieser Node funktioniert mit Datei-Eingabefeldern und interagiert nicht mit dem System-Dateiauswahl-Dialog.

Upload File Konfiguration — Datei-Eingabeelement und hochzuladenden Dateipfad angeben.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Field	Ziel-Datei-Eingabeelement	Yes	`UploadPage.fileInput`
File Path	Pfad zur hochzuladenden Datei	Yes	`/files/test-document.pdf`
Bindings	Erlaubt dynamische Dateipfade über Variablen	No	`${filePath}`

Verhalten

Wartet, bis das Datei-Eingabeelement verfügbar ist
Setzt den Dateipfad direkt auf dem Eingabeelement
Löst den Upload-Prozess aus, wie von der Anwendung definiert
Schlägt fehl, wenn das Element nicht gefunden oder der Dateipfad nicht zugänglich ist

Ausgabe

Keine Ausgabe.

Input Variables

Yes

Output Variables

Beispiel — Ein PDF-Dokument hochladen

Parameter	Wert
Field	`UploadPage.fileInput`
File Path	`/files/test-document.pdf`

Best Practices

Verwenden Sie Dateipfade, die in der Ausführungsumgebung zugänglich sind
Bevorzugen Sie relative oder umgebungsabhängige Pfade wenn möglich
Verwenden Sie Bindings, um die Dateiauswahl dynamisch zu gestalten
Stellen Sie sicher, dass das Datei-Eingabeelement im Page Object Repository korrekt definiert ist

Switch Session

Session Control

Der Switch Session-Node wechselt die Ausführung zu einer anderen aktiven Session innerhalb desselben Workflows. Er ermöglicht die Interaktion mit mehreren Sessions, wie z. B. verschiedenen Browser-Instanzen oder mobilen Geräten, innerhalb eines einzelnen Test Workflows.

Wann verwenden

Arbeit mit mehreren Browser-Sessions
Testen von Interaktionen zwischen verschiedenen Benutzern (z. B. Sender/Empfänger-Szenarien)
Wechsel zwischen Web- und Mobile-Sessions in einem kombinierten Workflow
Umgang mit Multi-Session- oder Multi-Geräte-Testszenarien

💡Wenn Ihr Workflow nur eine einzelne Session verwendet, ist dieser Node nicht erforderlich.

Switch Session Konfiguration — die Ziel-Session für den Ausführungskontext auswählen.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Target Session	Name oder Bezeichner der Session, zu der gewechselt werden soll	Yes	`Session_2`
Bindings	Erlaubt dynamische Session-Auswahl über Variablen	No	`${targetSession}`

Verhalten

Wechselt den Ausführungskontext zur angegebenen aktiven Session
Alle nachfolgenden Nodes werden innerhalb der ausgewählten Session ausgeführt
Erstellt oder schließt keine Sessions — wechselt nur zwischen bestehenden
Schlägt fehl, wenn die Ziel-Session nicht existiert oder nicht aktiv ist

Ausgabe

Keine Ausgabe.

Input Variables

Yes

Output Variables

Beispiel — Zu einer sekundären Browser-Session wechseln

Parameter	Wert
Target Session	`Session_2`

Best Practices

Verwenden Sie klare und konsistente Benennung für Sessions
Stellen Sie sicher, dass Sessions erstellt und aktiv sind, bevor Sie wechseln
Fügen Sie nach dem Wechsel Validierungsschritte hinzu, um den korrekten Kontext zu bestätigen
Verwenden Sie diesen Node hauptsächlich für Multi-Benutzer- oder Multi-Kontext-Szenarien

Switch Frame

Session Control

Der Switch Frame-Node ändert den Ausführungskontext zu einem bestimmten iframe oder zurück zum übergeordneten Frame. Er ist erforderlich, wenn mit Elementen interagiert wird, die in iframes eingebettet sind.

Wann verwenden

Interaktion mit Elementen innerhalb eines iframes
Zurückwechseln von einem iframe zur Hauptseite
Arbeit mit eingebetteten Inhalten wie Zahlungsdienstleistern, externen Widgets oder eingebetteten Anwendungen

💡Wenn Elemente nicht gefunden werden, aber sichtbar vorhanden sind, befinden sie sich häufig in einem iframe — dieser Node ist wahrscheinlich erforderlich.

Switch Frame Konfiguration — den iframe auswählen, in den gewechselt werden soll, oder zurück zum übergeordneten Frame wechseln.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Frame Selector	Selector oder Referenz auf den Ziel-iframe	Yes	`PaymentPage.paymentIframe`
Switch To	Definiert den Zielkontext (Frame oder übergeordneter Frame)	Yes	`frame`

* Frame Selector ist erforderlich, wenn Switch To = frame.

Switch To Optionen

Option	Beschreibung
`frame`	Wechselt den Ausführungskontext in den angegebenen iframe
`parent`	Wechselt den Ausführungskontext zurück zum übergeordneten (äußeren) Frame

Verhalten

Switch To Frame

Wartet, bis der iframe verfügbar ist, und wechselt den Ausführungskontext hinein. Alle nachfolgenden Aktionen werden innerhalb des iframes ausgeführt.

Switch To Parent

Wechselt den Ausführungskontext zurück zum übergeordneten (äußeren) Frame. Erforderlich, um weiterhin mit Elementen außerhalb des iframes zu interagieren.

Ausgabe

Keine Ausgabe.

Input Variables

Output Variables

Beispiel — In einen iframe wechseln

Parameter	Wert
Frame Selector	`PaymentPage.paymentIframe`
Switch To	`frame`

Beispiel — Zurück zum übergeordneten Frame wechseln

Parameter	Wert
Switch To	`parent`

Best Practices

Wechseln Sie nach Abschluss der iframe-Interaktionen immer zurück zum übergeordneten Frame
Verwenden Sie stabile iframe-Selectors aus dem Page Object Repository
Halten Sie iframe-Interaktionen im Workflow zusammengroupiert
Fügen Sie Validierungsschritte hinzu, um den korrekten Kontext zu bestätigen (z. B. Element-Vorhandensein)

Exit Frame

Session Control

Der Exit Frame-Node wechselt den Ausführungskontext vom aktuellen iframe zurück zu einem übergeordneten Dokument. Er wird verwendet, um einen iframe zu verlassen und weiterhin mit Elementen außerhalb davon zu interagieren.

Wann verwenden

Interaktionen innerhalb eines iframes wurden abgeschlossen
Sie müssen zur Hauptseite oder einem übergeordneten Frame zurückkehren
Elemente außerhalb des iframes sind nach dem Wechsel in einen Frame nicht zugänglich

💡Wenn Elemente plötzlich nach der Arbeit innerhalb eines iframes nicht gefunden werden können, müssen Sie wahrscheinlich den Frame verlassen.

Exit Frame Konfiguration — zum Top-Level-Dokument oder eine Ebene nach oben verlassen.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Exit To	Definiert den Zielkontext, zu dem zurückgewechselt werden soll	Yes	`top`

Exit To Optionen

Option	Beschreibung
`parent`	Wechselt eine Ebene nach oben vom aktuellen iframe
`top`	Wechselt zurück zum Hauptdokument (Root-Ebene)

Exit To Optionen

Top

Wechselt direkt zum Top-Level-Dokument unter Umgehung von verschachtelten iframes. Für die meisten Anwendungsfälle empfohlen.

Parent

Wechselt eine Ebene nach oben zum unmittelbaren übergeordneten Frame. Nützlich bei der Arbeit mit verschachtelten iframes.

Ausgabe

Keine Ausgabe.

Input Variables

Output Variables

Beispiel — Zum Hauptdokument verlassen

Parameter	Wert
Exit To	`top`

Best Practices

Verlassen Sie den Frame nach Abschluss der iframe-Interaktionen immer
Bevorzugen Sie top bei der Arbeit mit verschachtelten iframes, um Verwirrung zu vermeiden
Fügen Sie nach dem Verlassen eine Validierung hinzu, um den korrekten Kontext zu bestätigen
Vermeiden Sie unnötige Kontextwechsel

Mobile Press Key

Mobile

Der Mobile Press Key-Node simuliert das Drücken einer Hardware-Taste auf einem mobilen Gerät. Er wird verwendet, um systemseitige Aktionen wie das Zurücknavigieren, die Rückkehr zum Startbildschirm oder das Öffnen von Gerätemenüs auszulösen.

Wann verwenden

In der App mit der Gerät-Zurück-Taste zurücknavigieren
Zum Gerät-Startbildschirm zurückkehren
Systemmenüs oder geräteseitige Steuerungen öffnen
Mobilspezifisches Navigationsverhalten testen

💡Dieser Node interagiert mit dem Gerät, nicht nur mit der Anwendungs-UI.

Mobile Press Key Konfiguration — die zu simulierende Hardware-Taste auswählen (z. B. BACK, HOME).

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Key	Auf dem Gerät zu simulierende Hardware-Taste	Yes	`BACK`

Verfügbare Tasten

Option	Beschreibung
`BACK`	Navigiert einen Schritt in der App zurück
`HOME`	Kehrt zum Gerät-Startbildschirm zurück
`MENU`	Öffnet das Geräte- oder App-Menü (sofern unterstützt)
`APP_SWITCH`	Öffnet den App-Wechsler (Ansicht der zuletzt verwendeten Apps)
`ENTER`	Bestätigt Eingaben oder löst Standardaktionen aus
`DELETE`	Löscht Zeichen oder Inhalte
`VOLUME_UP`	Erhöht die Gerätelautstärke
`VOLUME_DOWN`	Verringert die Gerätelautstärke
`POWER`	Simuliert das Drücken der Ein-/Aus-Taste

Verhalten

Sendet den ausgewählten Hardware-Tastenbefehl an das mobile Gerät
Löst systemseitige Navigation oder Aktionen aus
Erfordert kein UI-Element
Das Verhalten kann je nach Gerät und Plattform (Android vs iOS) variieren

Ausgabe

Keine Ausgabe.

Input Variables

Output Variables

Beispiel — Zum vorherigen Bildschirm zurücknavigieren

Parameter	Wert
Key	`BACK`

Die BACK-Taste löst das native Navigationsverhalten des Geräts aus.

Best Practices

Verwenden Sie BACK für realistische Navigation anstelle von UI-Schaltflächen, wenn angemessen
Beachten Sie Unterschiede zwischen Android- und iOS-Verhalten
Vermeiden Sie HOME, es sei denn, es ist ausdrücklich erforderlich (verlässt den App-Kontext)
Kombinieren Sie mit Validierungsschritten, um das erwartete Navigationsergebnis zu bestätigen

Swipe

Mobile

Der Swipe-Node führt eine Wischgeste auf einem mobilen Gerät aus. Er wird verwendet, um Benutzerinteraktionen wie das Scrollen, das Navigieren zwischen Bildschirmen oder das Auslösen gestenbasierter Aktionen zu simulieren.

Wann verwenden

Durch Inhalte auf mobilen Bildschirmen scrollen
Zwischen Ansichten navigieren (z. B. Karussells, Tabs)
Gestenbasiertes UI-Verhalten auslösen
Mit Elementen interagieren, die Wischaktionen erfordern

Swipe Konfiguration — richtungsbasierter oder koordinatenbasierter Swipe-Modus wählen.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Direction	Vordefinierte Wischrichtung (up, down, left, right)	No	`up`
Start X	Start-X-Koordinate der Wischbewegung (Koordinatenmodus)	No	`100`
Start Y	Start-Y-Koordinate der Wischbewegung (Koordinatenmodus)	No	`600`
End X	End-X-Koordinate der Wischbewegung (Koordinatenmodus)	No	`100`
End Y	End-Y-Koordinate der Wischbewegung (Koordinatenmodus)	No	`100`
Duration	Dauer der Wischgeste in Millisekunden	No	`300`

Swipe-Modi

Richtungsbasiert

Verwendet vordefinierte Richtungen (up, down, left, right). Berechnet die Swipe-Koordinaten automatisch. Für die meisten Anwendungsfälle empfohlen.

Koordinatenbasiert

Verwendet explizite Start- und Endkoordinaten. Ermöglicht präzise Steuerung für benutzerdefinierte Layouts, komplexe Gesten oder fein abgestimmte Interaktionen.

Ausgabe

Keine Ausgabe.

Input Variables

Output Variables

Beispiel — Richtungsbasierter Swipe

Parameter	Wert
Direction	`up`
Duration	`300`

Beispiel — Koordinatenbasierter Swipe

Parameter	Wert
Start X	`100`
Start Y	`600`
End X	`100`
End Y	`100`
Duration	`300`

Best Practices

Bevorzugen Sie richtungsbasierte Swipes für Stabilität und Lesbarkeit
Verwenden Sie Koordinaten nur wenn nötig
Vermeiden Sie fest codierte Koordinaten über verschiedene Geräte hinweg — Bildschirmgrößen variieren
Halten Sie die Swipe-Dauer realistisch (zu schnell oder langsam kann das Verhalten beeinflussen)
Kombinieren Sie mit Assertions, um das erwartete Ergebnis zu überprüfen (z. B. Inhalt sichtbar)

Assert

Assertions

Der Assert-Node überprüft, ob ein UI-Element einer erwarteten Bedingung entspricht. Er wird verwendet, um das Anwendungsverhalten zu validieren und zu bestimmen, ob ein Test bestanden oder fehlgeschlagen ist.

Wann verwenden

Überprüfen, ob ein Element sichtbar ist
Prüfen, ob erwarteter Text oder Werte angezeigt werden
Bestätigen, dass ein Bildschirm, Dialog oder Ergebnis erscheint
Das Ergebnis einer vorherigen Aktion validieren

💡Assertions sind das, was ein automatisiertes Skript zu einem echten automatisierten Test macht.

Assert Konfiguration — Element, Bedingung und erwarteten Wert zur Überprüfung auswählen.

Konfiguration

Parameter	Beschreibung	Erforderlich	Beispiel
Field	Zu prüfendes Ziel-UI-Element	Yes	`LoginPage.errorMessage`
Condition	Bedingung, die geprüft werden soll	Yes	`visible`
Expected Value	Wert für den Vergleich (bedingungsabhängig)	No	`Invalid password`
Bindings	Erlaubt dynamische Erwartungswerte aus Variablen oder Testdaten	No	`${expectedMessage}`

* Expected Value ist nur für Bedingungen erforderlich, die gegen einen Wert vergleichen.

Verhalten

Wartet, bis das Zielelement oder die Bedingung ausgewertet werden kann
Prüft die ausgewählte Bedingung gegen das Element
Verwendet den erwarteten Wert, wenn die Bedingung einen Vergleich erfordert
Lässt den Workflow fehlschlagen, wenn die Assertion nicht erfüllt wird

Ausgabe

Keine Ausgabe. Der Node trägt zum Testergebnis bei, indem er die Validierung als bestanden oder fehlgeschlagen markiert.

Input Variables

Yes

Output Variables

Beispiel — Überprüfen, ob Erfolgsmeldung nach Formularabsenden sichtbar ist

Parameter	Wert
Field	`PaymentPage.successMessage`
Condition	`visible`
Expected Value	`(leer)`

Best Practices

Fügen Sie Assertions nach wichtigen Benutzeraktionen hinzu
Bevorzugen Sie aussagekräftige geschäftliche Validierungen gegenüber rein technischen Prüfungen
Verwenden Sie dynamische Erwartungswerte bei der Arbeit mit Testdaten
Halten Sie Assertions fokussiert: eine Validierung pro Assert-Node
Verwenden Sie Soft Verify, wenn Sie mehrere Validierungsfehler in einem Run sammeln möchten

Extract JSON Value

API Testing

Der Extract JSON Value Node extrahiert einen Wert aus der letzten API-Antwort mittels Response Path oder JSONPath. Der extrahierte Wert wird als Workflow-Variable gespeichert und kann in späteren Workflow-Schritten wiederverwendet werden.

Wann verwenden

Werte aus API-Responses extrahieren
IDs für spätere Requests speichern
Tokens oder Referenzen sichern
Verschachtelte JSON-Strukturen lesen

Extract JSON Value — Konfiguration von Store As und JSONPath für die Wert-Extraktion.

Configuration

Parameter	Description	Required	Example
Store As	Variablen-Name für den extrahierten Wert	Yes	`userId`
Response Path / JSONPath	Pfad zum gewünschten Wert in der Response	Yes	`$.data.id`

Verhalten

Liest die letzte API-Response
Führt den JSONPath aus
Extrahiert den Wert
Speichert den Wert als Variable

Ausgabe

Der extrahierte Wert wird über die durch Store As definierte Variable bereitgestellt. Beispiel: ${userId}

Input Variables

Yes

Output Variables

Yes

Fehlerbehandlung

Fehler bei ungültigem JSONPath
Fehler wenn kein Wert gefunden wird

Best Practices

Sinnvolle Variablennamen verwenden
Stabile JSONPaths bevorzugen

API Request

API Testing

Der API Request Node sendet HTTP-Requests direkt innerhalb eines Test Workflows. Damit lassen sich Backend-APIs aufrufen, Testdaten vorbereiten und UI- mit API-Tests kombinieren.

Wann verwenden

Backend APIs aufrufen
Testdaten vorbereiten
UI- und API-Tests kombinieren
Dynamische Daten laden

Unterstützte Methoden

GET
POST
PUT
DELETE
PATCH

API Request — Method und URL konfigurieren.

Configuration

Parameter	Description	Required	Example
Method	HTTP-Methode	Yes	`POST`
URL	Ziel-Endpoint	Yes	`https://api.example.com/users`
Auth Type	Authentifizierungs-Modus	No	`Bearer Token`
Headers	HTTP-Header	No	`Content-Type: application/json`
Body	Request-Body (JSON)	No	`{"name":"test"}`
Response Alias	Name unter dem die Response gespeichert wird	No	`createUserResponse`

Authentifizierung

Bearer Token

Token-basierte Authentifizierung.

Basic Auth

Benutzername / Passwort.

API Key

API-Key im Header oder Query.

OAuth2

OAuth2-Flow für sichere APIs.

Shared Config

Globale Auth-Konfiguration wiederverwenden.

Auth Type — Bearer Token, Basic Auth, API Key, OAuth2 oder Shared Config.

Headers & Body

Headers — HTTP-Header mit Key/Value-Paaren konfigurieren.

Body — Request-Body (z. B. JSON) für POST/PUT/PATCH-Requests.

Verhalten

Sendet den HTTP Request
Löst Workflow-Variablen auf
Speichert die Response

Ausgabe

Die Response wird unter dem konfigurierten Response Alias gespeichert und kann mit Extract JSON Value oder Verify Response weiterverarbeitet werden.

Response Alias — gespeicherte Response für die weitere Verarbeitung.

Input Variables

Yes

Output Variables

Yes

Fehlerbehandlung

Fehler bei ungültiger URL
Fehler bei ungültiger Authentifizierung
Fehler bei fehlgeschlagenem Request

Best Practices

Shared Config verwenden
Responses validieren
Keine Secrets hardcoden

Verify Response

API Testing

Der Verify Response Node validiert die Response des vorherigen API Requests. Drei Match-Modi stehen zur Verfügung: partial, exact oder jsonPath.

Wann verwenden

API Responses validieren
Statuswerte prüfen
JSON-Strukturen kontrollieren
Backend-Prozesse absichern

Verify Response — Konfiguration von Match Mode und Expected Body.

Configuration

Parameter	Description	Required	Example
Match Mode	Validierungsmodus (partial / exact / jsonPath)	Yes	`partial`
Expected Body	Erwarteter Wert oder erwartete Struktur	Yes	`{"status":"ok"}`

Match-Modi

partial

Prüft, ob die erwarteten Felder enthalten sind. Ideal für dynamische Responses.

exact

Strikte Übereinstimmung — die Response muss exakt dem Expected Body entsprechen.

jsonPath

Validierung über JSONPath-Ausdrücke. Ideal für grosse Responses.

Verhalten

Liest die letzte API-Response
Führt die Validierung aus
Stoppt den Workflow bei Fehlern

Ausgabe

Kein direkter Output. Der Node validiert die Response und stoppt den Workflow bei Fehlschlag.

Input Variables

Yes

Output Variables

Fehlerbehandlung

Fehler wenn keine Response existiert
Fehler wenn die Validierung fehlschlägt

Best Practices

partial für dynamische Responses verwenden
exact nur für stabile Responses verwenden
jsonPath für grosse Responses bevorzugen

If

Control Flow

Der If-Node führt bedingte Logik in einen Test Workflow ein. Er wertet eine Bedingung aus und leitet den Workflow in verschiedene Zweige, je nachdem, ob die Bedingung erfüllt ist oder nicht.

Wann verwenden

Schritte nur unter bestimmten Bedingungen ausführen
Optionale UI-Elemente behandeln (z. B. Popups, Dialoge)
Flexible und dynamische Workflows erstellen
Fallback- oder alternative Abläufe implementieren

💡Verwenden Sie If, um Ihre Tests widerstandsfähig zu machen, anstatt auf starre Schrittabfolgen zu setzen.

If Konfiguration — Bedingung, Operator und Vergleichswert für die Verzweigungslogik definieren.

Configuration

Parameter	Description	Required	Example
Condition	Definiert, was ausgewertet werden soll	Yes	`visible`
Operator	Definiert, wie die Bedingung ausgewertet wird	Yes	`equals`
Compare Value	Wert für den Vergleich (falls erforderlich)	No	`Success`
Bindings	Erlaubt dynamische Werte über Variablen	No	`${expectedValue}`

* Compare Value ist nur für Bedingungen erforderlich, die Werte vergleichen.

Verfügbare Bedingungen

Option	Description
`visible`	Element ist auf dem Bildschirm sichtbar
`hidden`	Element ist nicht sichtbar
`exists`	Element existiert im DOM/UI
`notExists`	Element existiert nicht
`textEquals`	Elementtext stimmt exakt überein
`textContains`	Elementtext enthält einen Wert
`valueEquals`	Elementwert stimmt mit erwarteter Eingabe überein

Verfügbare Operatoren

Option	Beschreibung
`equals`	Werte müssen exakt übereinstimmen
`notEquals`	Werte müssen unterschiedlich sein
`contains`	Wert muss die erwartete Eingabe enthalten
`greaterThan`	Numerischer Vergleich: größer als
`lessThan`	Numerischer Vergleich: kleiner als
`isEmpty`	Wert ist leer
`isNotEmpty`	Wert ist nicht leer

Verhalten

Wertet die definierte Bedingung zur Laufzeit aus
Vergleicht das Ergebnis mit dem ausgewählten Operator
Leitet die Ausführung in den True-Zweig (Bedingung erfüllt) oder False-Zweig (Bedingung nicht erfüllt)
Nur der ausgewählte Zweig wird ausgeführt

Ausgabe

Keine Ausgabe. Der Node steuert den Workflow-Ausführungsfluss, indem er in den True- oder False-Zweig weiterleitet.

Input Variables

Yes

Output Variables

Beispiel — Eine optionale Fehlermeldung behandeln

Nur fortfahren, wenn keine Fehlermeldung angezeigt wird:

Parameter	Value
Condition	`notExists`
Operator	`equals`

True-Zweig: Workflow fortsetzen | False-Zweig: Fehler behandeln (z. B. Screenshot aufnehmen, Test stoppen)

Best Practices

Verwenden Sie If für optionales oder dynamisches UI-Verhalten
Halten Sie Bedingungen einfach und lesbar
Vermeiden Sie tief verschachtelte If-Strukturen — sie sind schwer zu warten
Kombinieren Sie mit Assert oder Soft Verify für Validierungslogik
Verwenden Sie Variablen, um Bedingungen wiederverwendbar zu machen

Loop

Control Flow

Der Loop-Node iteriert über einen Datensatz und führt eine Gruppe von Nodes wiederholt aus. Er wird verwendet, um mehrere Datensätze zu verarbeiten und so datengetriebenes Testen innerhalb eines einzelnen Test Workflows zu ermöglichen.

Wann verwenden

Dieselben Schritte für mehrere Datensätze ausführen
Tests mit verschiedenen Eingabewerten ausführen
Über Datensätze iterieren (z. B. Benutzer, Bestellungen, Eingaben)
Skalierbare und wiederverwendbare Testszenarien aufbauen

💡Loop ist unverzichtbar für datengetriebenes Testen.

Loop Konfiguration — Datenquelle, Save As-Variable und maximale Iterationen definieren.

Configuration

Parameter	Description	Required	Example
Data Source	Zu iterierende Datensammlung	Yes	`${users}`
Save As	Variablenname für das aktuelle Element in jeder Iteration	Yes	`item`
Max Iterations	Maximale Anzahl von Schleifendurchläufen	No	`100`
Bindings	Erlaubt dynamische Datenquellen und Variablennamen	No	`${dataSet}`

Behavior

Liest die bereitgestellte Datenquelle
Iteriert über jedes Element in der Sammlung
Speichert das aktuelle Element in der in Save As definierten Variable
Führt alle Nodes innerhalb der Schleife für jedes Element aus
Stoppt, wenn alle Elemente verarbeitet sind oder das Limit der Max Iterations erreicht ist

Ausgabe

Keine direkte Ausgabe. Die Save As-Variable ist innerhalb der Schleife für jede Iteration verfügbar.

Input Variables

Yes

Output Variables

Beispiel — Mehrere Benutzer verarbeiten

Parameter	Value
Data Source	`${users}`
Save As	`user`
Max Iterations	`50`

Innerhalb der Schleife: Type ${user.name} → Type ${user.email} → Click Submit

Best Practices

Aussagekräftige Variablennamen verwenden (z. B. user, order, item)
Iterationen bei großen Datensätzen begrenzen
Mit Assertions kombinieren, um jede Iteration zu validieren
Schleifenlogik einfach und lesbar halten
Tief verschachtelte Schleifen vermeiden — sie sind schwer zu warten und zu debuggen

Wait

Control Flow

Der Wait Node pausiert die Ausführung für eine definierte Zeitspanne. Er wird verwendet, um eine feste Verzögerung zwischen Schritten in einem Test Workflow einzufügen.

Wann verwenden

Warten auf den Abschluss von Animationen oder Übergängen
Umgang mit bekannten, festen Verzögerungen in der Anwendung
Stabilisierung von Interaktionen in Randfällen, wenn keine bessere Bedingung verfügbar ist

💡Wait sollte sparsam eingesetzt werden. Bevorzugen Sie bedingungsbasiertes Warten (z. B. Assert), wann immer möglich.

Wait-Konfiguration — geben Sie die Pausendauer in Millisekunden an.

Configuration

Parameter	Description	Required	Example
Duration	Wartezeit	Yes	`1000`
Unit	Zeiteinheit für die Dauer (ms oder s)	Yes	`ms`

Verhalten

Pausiert die Ausführung für die angegebene Dauer
Prüft während der Wartezeit keine Bedingung
Setzt die Ausführung nach Ablauf der Zeit fort
Interagiert nicht mit dem Anwendungszustand

Ausgabe

Keine Ausgabe.

Input Variables

Output Variables

Häufige Fehler: Wait statt echter Validierung zu verwenden, große Verzögerungen einzubauen, um instabile Tests zu "reparieren", oder mehrere Wait-Nodes zu verketten, führt zu langsamer und unzuverlässiger Ausführung. Statt Wait 5000ms bevorzugen Sie Assert element is visible.

Beispiel — 1 Sekunde warten

Parameter	Value
Duration	`1000`
Unit	`ms`

💡Statt zu warten bevorzugen Sie Assert element is visible oder eine If-Bedingung — das macht Tests schneller und zuverlässiger.

Best Practices

Wait nur verwenden, wenn keine bedingungsbasierte Alternative verfügbar ist
Wartezeiten so kurz wie möglich halten
Assert (z. B. visible) oder If-Bedingungen gegenüber Wait bevorzugen
Wait für Animationen verwenden, nicht für Ladelogik

Time Gap

Control Flow

Der Time Gap Node teilt einen Test Workflow in asynchrone Teile auf und setzt die Ausführung zu einem späteren Zeitpunkt fort.

Im Gegensatz zum normalen Wait Node bleibt die Workflow-Ausführung beim Time Gap Node nicht aktiv. Stattdessen wird der aktuelle Workflow-Teil abgeschlossen, persistiert und der nächste Teil separat eingeplant. Dadurch werden langlaufende und asynchrone Automatisierungsszenarien ermöglicht.

💡Time Gap ist essenziell für Enterprise-Workflows, welche verzögerte Fortsetzungen, asynchrone Prozesse oder geplante Folgevalidierungen benötigen.

Wann verwenden

Verwende den Time Gap Node wenn:

mehrere Minuten, Stunden oder Tage gewartet werden müssen
asynchrone Backend-Prozesse verarbeitet werden
auf externe Systeme gewartet werden muss
mehrteilige Workflows erstellt werden
verzögerte Business-Events validiert werden
zukünftige Workflow-Fortsetzungen geplant werden
Retry- oder Follow-up-Workflows benötigt werden

Typische Beispiele: Sendungsverfolgung nach Versand · Warten auf Zahlungsbestätigung · Verzögerte E-Mail-Verifizierung · Overnight-Processing · Langlaufende Business-Workflows.

💡Time Gap erstellt eine echte asynchrone Workflow-Grenze.

Time Gap Konfiguration — Wait Mode (Relative / Absolute), Dauer und Continue on Failure.

Configuration

Parameter	Description	Required	Example
Wait Mode	Definiert ob Relative oder Absolute verwendet wird	Yes	`Relative`
Wait For	Dauer bis der nächste Workflow-Teil startet	Nur Relative	`1`
Unit	Zeiteinheit für die relative Verzögerung	Nur Relative	`Minutes`
Anchor Type	Definiert den Scheduling-Modus	Nur Absolute	`Specific date & time`
Date & Time (UTC)	Exakter UTC-Zeitpunkt für die Fortsetzung	Nur Absolute	`2026-03-01 12:00`
Continue on Failure	Plant den nächsten Teil auch bei Fehlern ein	No	`Enabled`

Verhalten

Relative Mode

Der Relative Mode plant den nächsten Workflow-Teil nach einer definierten Dauer (z. B. nach 1 Minute, 2 Stunden oder 1 Tag).

Der aktuelle Workflow-Teil wird abgeschlossen
Der Workflow-Status wird persistiert
Der nächste Teil wird nach der konfigurierten Dauer eingeplant
Die Ausführung wird automatisch fortgesetzt

Absolute Mode

Der Absolute Mode plant die Fortsetzung zu einem fixen UTC-Datum und Zeitpunkt.

Der aktuelle Workflow-Teil wird abgeschlossen
Der Workflow-Status wird persistiert
Der nächste Workflow-Teil wird an einen festen Zeitpunkt gebunden
Die Ausführung wird automatisch zum definierten Zeitpunkt fortgesetzt

Time Gap teilt den Workflow automatisch in mehrere Ausführungsteile.

Workflow-Aufteilung

Der Time Gap Node teilt Workflows automatisch in mehrere Ausführungsteile auf. Jeder Workflow-Teil wird unabhängig ausgeführt.

Beispiel-Ablauf

Part 1 → Bestellung erstellen
Time Gap → 1 Stunde warten
Part 2 → Sendungsverfolgung prüfen

Persistenter Runtime-Status

Da die Ausführung zwischen den Workflow-Teilen unterbrochen wird, persistiert die Plattform automatisch alle relevanten Workflow-Daten:

Workflow-Variablen
Extrahierte Werte
Environment-Konfigurationen
Runtime-Kontext
Generierte IDs, Bestellnummern, API-Responses
Session-Metadaten

Dadurch können spätere Workflow-Teile mit demselben Ausführungskontext weiterarbeiten.

💡Korrekte State-Persistierung ist essenziell für asynchrone Automatisierung.

Ausgabe

Kein direkter Output. Der Node plant die asynchrone Fortsetzung des Workflows.

Input Variables

Yes

Output Variables

Arbeiten mit Variablen

Variablen, welche vor dem Time Gap Node erstellt wurden, bleiben auch in späteren Workflow-Teilen verfügbar.

Time Gap — persistierte Variablen werden zwischen Workflow-Teilen mitgenommen.

Beispiel

Parameter	Value
Save Variable	`${orderNumber}`

Part 1: Bestellung erstellen → ${orderNumber} speichern
Part 2: ${orderNumber} wiederverwenden → Sendung verfolgen

Fehlerbehandlung

Der aktuelle Workflow-Teil wird vor dem Scheduling abgeschlossen
Ungültige Scheduling-Konfigurationen können die Ausführung stoppen
Absolute Scheduling benötigt gültige UTC-Zeitstempel
Continue on Failure erlaubt die Fortsetzung trotz vorheriger Fehler
Fehler bei der Workflow-Persistierung können die Fortsetzung verhindern

Beispiel — Relative Mode (1 Minute warten)

Parameter	Value
Wait Mode	`Relative`
Wait For	`1`
Unit	`Minutes`

Verhalten: Part 1 wird abgeschlossen, der Workflow pausiert asynchron, Part 2 startet nach 1 Minute.

Beispiel — Absolute Mode (fester Zeitpunkt)

Parameter	Value
Wait Mode	`Absolute`
Anchor Type	`Specific date & time`
Date & Time (UTC)	`2026-03-01 12:00`

Verhalten: Der Workflow wird exakt zum definierten UTC-Zeitpunkt fortgesetzt.

Best Practices

Wichtige Runtime-Daten vor dem Time Gap persistieren
Aussagekräftige Variablennamen verwenden
Relative Mode für flexible Verzögerungen nutzen
Absolute Mode für geplante Business-Events verwenden
Asynchrone Workflows modular und lesbar halten
Continue on Failure bewusst einsetzen
Verzögerte Workflows nach Wiederaufnahme validieren

Acquire Test Data

Test Data

Der Acquire Test Data Node ruft Testdaten aus einer konfigurierten Testdatenquelle ab und sperrt sie. Er ruft strukturierte Daten (z. B. Benutzer, Kunden, Bestellungen) ab und stellt sie zur Verwendung in einem Test Workflow bereit.

Wann verwenden

Abruf von Testdaten aus einer zentralen Datenquelle
Durchführung datengesteuerter Tests mit verwalteten Datensätzen
Sicherstellung eindeutiger oder reservierter Daten für jede Testausführung
Vermeidung von Konflikten zwischen parallelen Test-Läufen

💡Dieser Node ist unerlässlich für zuverlässige und skalierbare Testautomatisierung.

Configuration

Parameter	Description	Required	Example
Source Type	Art der Datenquelle	Yes	`rest-api`
Data Type	Art des abzurufenden Datensatzes	Yes	`CUSTOMER`
Quantity	Anzahl der abzurufenden Datensätze	Yes	`1`
Scope	Legt fest, wie lange die Daten reserviert sind	Yes	`RUN`
TTL Override	Benutzerdefinierte Gültigkeitsdauer für die Datensperrung	No	`PT30M`
Store As	Variablenname für die abgerufenen Daten	Yes	`acquiredToken`
Bypass Cache	Erzwingt den erneuten Abruf frischer Daten unter Umgehung des Caches	No	`false`

Behavior

Fordert Daten von der konfigurierten Testdatenquelle an
Sperrt die abgerufenen Datensätze, um eine Wiederverwendung in parallelen Ausführungen zu verhindern
Speichert das Ergebnis in der definierten Variable
Stellt die Daten für nachfolgende Schritte über Platzhalter wie ${"{"}acquiredToken.record.username{"}"} bereit

Output

Die abgerufenen Daten werden in der durch Store As definierten Variable gespeichert. Beispiel: ${acquiredToken.record.username} oder ${acquiredToken.records[0].email}

Input Variables

Yes

Output Variables

Yes

Beispiel — Kundendatensatz für einen Test-Lauf abrufen

Parameter	Value
Source Type	`rest-api`
Data Type	`CUSTOMER`
Quantity	`1`
Scope	`RUN`
Store As	`acquiredToken`

Verwendung in einem späteren Schritt: Type ${acquiredToken.record.email}

Best Practices

Aussagekräftige Namen für gespeicherte Variablen verwenden (z. B. customerData, testUser)
Menge so gering wie nötig halten, um Ressourcen zu schonen
Scope = RUN für isolierte Testausführungen verwenden
Mit Assertions kombinieren, um die Datennutzung zu validieren

Extract Text

Test Data

Der Extract Text Node liest Text- oder Attributwerte aus einem UI-Element und speichert das Ergebnis in einer Variable. Wird verwendet, um dynamische Anwendungsdaten während der Testausführung für spätere Validierung, Vergleich oder Wiederverwendung zu erfassen.

Wann verwenden

Werte aus der Benutzeroberfläche auslesen
Dynamische Inhalte wie IDs, Meldungen oder Summen erfassen
Angezeigte Werte später im Workflow vergleichen
Anwendungsdaten für Assertions oder API-Aufrufe speichern
Dynamische und datengesteuerte Testszenarien aufbauen

💡Wird häufig zusammen mit Assert, If und Type Nodes verwendet.

Extract Text-Konfiguration — Element, auszulesendes Attribut und Variablenname zum Speichern des Ergebnisses auswählen.

Configuration

Parameter	Description	Required	Example
Page	Page Object mit dem Zielelement	Yes	`CheckoutPage`
Element	UI-Element, aus dem Daten extrahiert werden	Yes	`orderNumberLabel`
Variable Name	Name der Variable zum Speichern des extrahierten Werts	Yes	`orderNumber`
Attribute	Eigenschaft oder Attribut des Elements, das ausgelesen wird	Yes	`textContent`

Unterstützte Attribute

Option	Description
`textContent`	Sichtbarer Textinhalt des Elements
`value`	Aktueller Wert eines Eingabefelds
`innerText`	Dem Benutzer angezeigter gerenderter Text
`placeholder`	Platzhaltertext eines Eingabefelds
`href`	Ziel-URL eines Links
`src`	Quell-URL eines Bild- oder Medienelements

Behavior

Wartet, bis das Zielelement verfügbar ist
Liest das ausgewählte Attribut oder den Textwert aus dem Element
Speichert den extrahierten Wert in der angegebenen Variable
Stellt den Wert für alle nachfolgenden Workflow-Schritte bereit

Ausgabe

Der extrahierte Wert wird in der angegebenen Variable gespeichert und ist für alle nachfolgenden Workflow-Schritte verfügbar.

Input Variables

Output Variables

Yes

Beispiel — Bestellnummer von der Checkout-Seite extrahieren

Parameter	Value
Page	`CheckoutPage`
Element	`orderNumberLabel`
Variable Name	`orderNumber`
Attribute	`textContent`

Spätere Verwendung: Assert ${orderNumber} is not empty

Best Practices

Aussagekräftige Variablennamen verwenden
textContent für sichtbaren UI-Text bevorzugen
Extrahierte Werte mit Assert oder If Nodes validieren
Unbeabsichtigtes Überschreiben von Variablen vermeiden
Extraktionslogik nah an der Verwendungsstelle des Werts platzieren

Persist Test Data

Test Data

Der Persist Test Data Node speichert zuvor abgerufene Testdaten zur späteren Wiederverwendung in Workflow-Ausführungen oder asynchronen Verarbeitungsschritten. Wird verwendet, um gesperrte Datensätze über den aktuellen Ausführungskontext hinaus zu erhalten.

Wann verwenden

Ein Workflow wird pausiert und später fortgesetzt
Die Testausführung erstreckt sich über mehrere asynchrone Prozesse
Abgerufene Datensätze bei Workflow-Neustarts erhalten
Daten zwischen mehreren Ausführungsversuchen koordinieren

💡Besonders nützlich in CI/CD- und asynchronen Ausführungsszenarien.

Persist Test Data-Konfiguration — Token-Variable, Run ID und Attempt ID angeben.

Configuration

Parameter	Description	Required	Example
Token Variable	Variable mit dem abgerufenen Datensatz-Token	Yes	`acquiredToken`
Run ID	Eindeutiger Bezeichner für die Workflow-Ausführung	Yes	`ci-build-42`
Attempt ID	Bezeichner für den Ausführungsversuch	Yes	`1`

Verhalten

Liest das Datensatz-Token aus der angegebenen Variable
Speichert den Datensatzverweis für den späteren Abruf
Verknüpft die persistierten Daten mit einer bestimmten Run ID und Attempt ID
Ermöglicht zukünftigen Workflow-Ausführungen, denselben Datensatz fortzusetzen

Ausgabe

Keine direkte Ausgabe. Der Datensatzverweis wird extern für zukünftige Workflow-Versuche gespeichert.

Input Variables

Yes

Output Variables

Beispiel — Kundendatensatz für einen CI-Pipeline-Lauf persistieren

Parameter	Value
Token Variable	`acquiredToken`
Run ID	`ci-build-42`
Attempt ID	`1`

Verwenden Sie Resume Test Data mit derselben Run ID und Attempt ID, um den Datensatz später wiederherzustellen.

Best Practices

Stabile und eindeutige Run IDs verwenden
Nur Datensätze persistieren, die Workflow-Neustarts überstehen müssen
Namenskonventionen über Workflows hinweg konsistent halten
Mit Resume Test Data für Fortsetzungsszenarien kombinieren

Release Test Data

Test Data

Der Release Test Data Node gibt einen zuvor abgerufenen oder wiederhergestellten Datensatz zurück an den Testdaten-Pool. Wird verwendet, um gesperrte Testdaten nach Abschluss eines Workflows oder wenn die Daten nicht mehr benötigt werden, wieder verfügbar zu machen.

Wann verwenden

Ein Workflow hat die Verwendung der abgerufenen Testdaten abgeschlossen
Ein zuvor gesperrter Datensatz soll an den Pool zurückgegeben werden
Vermeidung unnötiger Datensperren nach der Ausführung
Bereinigung der Testdatennutzung nach erfolgreichen oder fehlgeschlagenen Läufen

💡Dieser Node ist der Bereinigungsschritt für Testdaten, die zuvor im Workflow abgerufen wurden.

Release Test Data-Konfiguration — Token-Variable und Scope angeben.

Configuration

Parameter	Description	Required	Example
Token Variable	Variable mit dem abgerufenen oder wiederhergestellten Datensatz-Token	Yes	`acquiredToken`
Scope	Scope, in dem der Datensatz freigegeben werden soll	Yes	`RUN`

Scope-Optionen

Option	Description
`RUN`	Gibt den Datensatz für den aktuellen Workflow-Lauf frei
`PROJECT`	Gibt den Datensatz im Rahmen des aktuellen Projekts frei
`TENANT`	Gibt den Datensatz im gesamten Tenant-Scope frei

Output

Keine Ausgabe. Die Datensatzsperre wird gemäß dem ausgewählten Scope aufgehoben oder freigegeben.

Input Variables

Yes

Output Variables

Beispiel — Kundendatensatz nach Abschluss des Workflows freigeben

Parameter	Value
Token Variable	`acquiredToken`
Scope	`RUN`

Best Practices

Abgerufene Testdaten freigeben, sobald sie nicht mehr benötigt werden
Dieselbe Token-Variable verwenden, die von Acquire Test Data oder Resume Test Data erstellt wurde
RUN-Scope für die meisten Workflow-Ausführungen bevorzugen
Diesen Node nahe am Ende des Workflows oder in einem Bereinigungszweig platzieren

Resume Test Data

Test Data

Der Resume Test Data Node stellt zuvor persistierte Testdaten wieder her und macht sie innerhalb der aktuellen Workflow-Ausführung wieder verfügbar. Das Gegenstück zum Persist Test Data Node.

Wann verwenden

Fortsetzen eines pausierten oder neu gestarteten Workflows
Zuvor persistierte Datensätze wiederherstellen
Asynchrone oder verteilte Testausführung fortsetzen
Konsistente Testdaten über Wiederholungen oder CI/CD-Phasen hinweg beibehalten

Resume Test Data-Konfiguration — Run ID, Attempt ID und Store As-Variable angeben.

Configuration

Parameter	Description	Required	Example
Run ID	Bezeichner der Workflow-Ausführung, aus der die Daten wiederhergestellt werden	Yes	`ci-build-42`
Attempt ID	Bezeichner des persistierten Ausführungsversuchs	Yes	`1`
Store As	Variablenname, unter dem der wiederhergestellte Datensatz bereitgestellt wird	Yes	`acquiredToken`

Verhalten

Ruft den persistierten Datensatz anhand von Run ID und Attempt ID ab
Stellt den Datensatzverweis im Workflow-Kontext wieder her
Stellt die wiederhergestellten Daten über die in Store As definierte Variable bereit
Die wiederhergestellte Variable verhält sich genau wie Daten aus Acquire Test Data

Ausgabe

Der wiederhergestellte Datensatz wird über die durch Store As definierte Variable bereitgestellt. Beispiel: ${acquiredToken.record.username}

Input Variables

Yes

Output Variables

Yes

Beispiel — Persistierten Kundendatensatz wiederherstellen

Parameter	Value
Run ID	`ci-build-42`
Attempt ID	`1`
Store As	`acquiredToken`

Spätere Verwendung: Type ${acquiredToken.record.email}

Best Practices

Stabile Run IDs über zusammenhängende Workflow-Ausführungen hinweg verwenden
Attempt IDs für denselben asynchronen Ausführungsfluss konsistent halten
Dieselbe Store As-Variablennamenskonvention im gesamten Workflow verwenden
Mit Release Test Data kombinieren, um Datensatzsperren ordnungsgemäß zu bereinigen

HTTP Request

API & Scripting

Der HTTP Request Node sendet eine HTTP-Anfrage an einen externen Dienst oder API-Endpunkt. Wird verwendet, um Daten direkt über APIs im Rahmen eines Test Workflows abzurufen, zu erstellen, zu aktualisieren oder zu validieren.

Wann verwenden

REST-APIs während eines Workflows aufrufen
Testdaten vorbereiten oder bereinigen
Backend-Antworten validieren
UI- und API-Tests in einem einzigen Ablauf kombinieren
Externe Systeme in automatisierte Tests integrieren

💡Häufig verwendet für Testdaten-Setup und Backend-Validierung.

HTTP Request-Konfiguration — Methode, URL, Header und Request-Body festlegen.

Configuration

Parameter	Description	Required	Example
Url	Ziel-API-Endpunkt	Yes	`https://api.example.com/users`
Method	HTTP-Methode der Anfrage	Yes	`GET`
Headers	Mit der Anfrage gesendete HTTP-Header	No	`[{"Authorization":"Bearer token"}]`
Body	An die API gesendeter Request-Payload	No	`{"name":"John"}`
Body Type	Format des Request-Body	No	`json`

* Body ist in der Regel für POST-, PUT- oder PATCH-Anfragen erforderlich.

Unterstützte HTTP-Methoden

Option	Description
`GET`	Daten abrufen
`POST`	Neue Daten erstellen
`PUT`	Vorhandene Daten ersetzen
`PATCH`	Vorhandene Daten teilweise aktualisieren
`DELETE`	Daten entfernen

Unterstützte Body-Typen

Option	Description
`json`	JSON-Payload
`form-data`	Mehrteilige Formularübermittlung
`x-www-form-urlencoded`	URL-kodierte Formulardaten
`text`	Nur-Text-Payload

Behavior

Sendet die konfigurierte HTTP-Anfrage an den Ziel-Endpunkt
Wendet Header- und Payload-Konfiguration an
Wartet auf die API-Antwort
Stellt die Antwort (Statuscode, Header, Body) für spätere Workflow-Schritte bereit

Unterstützte Methoden

GET, POST, PUT, PATCH, DELETE — sowie andere Standard-HTTP-Methoden, die von der aufgerufenen API unterstützt werden.

Ausgabe

Der Node stellt Zugriff auf die API-Antwort bereit, einschließlich Statuscode, Header und Response-Body. Antwortwerte können extrahiert und in nachfolgenden Workflow-Schritten wiederverwendet werden.

Input Variables

Yes

Output Variables

Yes

Beispiel — Kundendaten abrufen

Parameter	Value
Url	`https://api.example.com/customers/42`
Method	`GET`
Headers	`[{"Authorization":"Bearer token"}]`

Beispiel — Testdaten über API erstellen

Parameter	Value
Url	`https://api.example.com/customers`
Method	`POST`
Body	`{"name":"John Doe"}`
Body Type	`json`

Best Practices

Variablen und Bindings anstelle hartcodierter Werte verwenden
Authentifizierungstoken sicher aufbewahren
Wichtige Antworten mit Assert oder Extract Text validieren
APIs für effizientes Testdaten-Setup statt nur UI-Vorbereitung verwenden
Request-Payloads lesbar und wartbar halten

Execute JavaScript

API & Scripting

Der Execute JavaScript Node führt benutzerdefinierten JavaScript-Code direkt in der aktiven Browser-Sitzung aus. Wird für erweiterte Browser-Interaktionen, das Abrufen dynamischer Informationen, die Manipulation des Seitenverhaltens oder die Ausführung von Logik verwendet, die von Standard-Workflow-Nodes nicht abgedeckt wird.

Wann verwenden

Direkte Zugriff auf Browser- oder DOM-Informationen
Dynamische Anwendungsdaten abrufen
Erweiterte UI-Interaktionen durchführen
Benutzerdefinierte Logik im Browser-Kontext ausführen
Randfälle behandeln, die von integrierten Nodes nicht unterstützt werden

💡Dieser Node ist für fortgeschrittene und technische Anwendungsfälle gedacht.

Execute JavaScript-Konfiguration — Skript schreiben und optional eine Store Result As-Variable definieren.

Configuration

Parameter	Description	Required	Example
Script	Im Browser-Kontext ausgeführter JavaScript-Code	Yes	`return document.title;`
Store Result As	Variablenname zum Speichern des zurückgegebenen Ergebnisses	No	`pageTitle`

Behavior

Führt das bereitgestellte JavaScript in der aktiven Browser-Sitzung aus
Läuft im Kontext der aktuell geladenen Seite
Kann auf das DOM zugreifen, Browser-Informationen lesen und den Seitenzustand manipulieren
Gibt das Ergebnis des Skripts zurück (falls zutreffend) und speichert es in der konfigurierten Variable

Ausgabe

Optionale Ausgabe. Wenn das Skript einen Wert zurückgibt und Store Result As konfiguriert ist, wird das Ergebnis in der angegebenen Variable gespeichert. Beispiel: ${pageTitle} → Customer Portal

Input Variables

Yes

Output Variables

Yes

Beispiel — Aktuellen Seitentitel abrufen

Parameter	Value
Script	`return document.title;`
Store Result As	`pageTitle`

Spätere Verwendung: Assert ${pageTitle} equals Dashboard

Beispiel — Elementtext auslesen

Parameter	Value
Script	`return document.querySelector('#total').textContent;`
Store Result As	`totalAmount`

Best Practices

Skripte kurz und fokussiert halten
Integrierte Nodes wann immer möglich bevorzugen
Werte explizit mit return zurückgeben
Aussagekräftige Variablennamen für gespeicherte Ergebnisse verwenden
Den Anwendungszustand nur wenn erforderlich verändern
Ergebnisse mit Assert oder If Nodes validieren

Table Handling

Die Table Handling Nodes bieten einen vollständigen Satz geschäftsorientierter Operationen für die Interaktion mit Unternehmenstabellen in Ihren Test Workflows. Anstatt auf Zeilenpositionen oder technische Selektoren zu vertrauen, arbeiten sie mit Geschäftsspalten, Bedingungen und konfigurierten Tabellendefinitionen.

Cell Value

Table Handling

Der Cell Value Node liest, validiert oder speichert den Wert einer bestimmten Spalte aus einer Tabellenzeile. Wird verwendet, um während der Workflow-Ausführung dynamisch auf Geschäftsdaten aus Tabellen zuzugreifen.

Wann verwenden

Werte aus einer Tabellenzeile auslesen
Tabelleninhalt überprüfen
Geschäftsdaten für spätere Workflow-Schritte extrahieren
Mit durch Find Row identifizierten Zeilen arbeiten
Status, Beträge, IDs oder andere tabellenbasierte Informationen validieren

💡Dieser Node ermöglicht Workflows die Interaktion mit Tabellendaten basierend auf geschäftlicher Bedeutung statt fester Zeilenpositionen.

Cell Value-Konfiguration — Tabelle, Spalte, Aktion und Zeilenbedingungen definieren.

Configuration

Parameter	Description	Required	Example
Table	Zentral verwaltete Tabellendefinition	Yes	`OrdersTable`
Action	Legt fest, was mit dem Zellwert geschehen soll	Yes	`Read value`
Match	Legt fest, wie mehrere Bedingungen ausgewertet werden	No	`All conditions`
Where	Bedingungen zur Identifikation der Zielzeile	No	`Order Number equals ${orderNumber}`
Column	Name der Geschäftsspalte, auf die zugegriffen wird	Yes	`Status`
Save As	Variablenname zum Speichern des Zellwerts	No	`orderStatus`

* Where ist optional, wenn der aktuelle Zeilenkontext bereits vorhanden ist (z. B. nach Find Row). Save As ist erforderlich, wenn Werte gelesen und gespeichert werden.

Verfügbare Aktionen

Option	Description
`Read value`	Liest den Zellwert und speichert ihn als Variable
`Verify value`	Validiert den Zellwert gegen eine erwartete Bedingung
`Read and verify`	Liest und validiert den Wert in einem einzigen Schritt

Zusätzliche Optionen

Option	Description
`Search Scope`	Legt fest, wo die Tabellensuche beginnen soll (z. B. Start from first page)
`Max Pages`	Maximale Anzahl der zu durchsuchenden Seiten (Standard: 10)
`Timeout (ms)`	Maximale Wartezeit für den Abschluss der Tabellensuche (Standard: 15000)

Behavior

Lokalisiert die Zielzeile über den aktuellen Tabellenzeilenkontext oder konfigurierte Bedingungen
Wertet Bedingungen gegen die Tabellenzeilen aus
Navigiert bei Bedarf über Tabellenseiten
Greift auf die angegebene Geschäftsspalte zu und führt die konfigurierte Aktion aus (lesen, prüfen oder beides)

Ausgabe

Der Zellwert wird in der durch Save As definierten Variable gespeichert.

Input Variables

Yes

Output Variables

Yes

Beispiel — Status einer bestimmten Bestellung auslesen

Parameter	Value
Table	`OrdersTable`
Action	`Read value`
Where	`Order Number equals ORD-100245`
Column	`Status`
Save As	`orderStatus`

Best Practices

Find Row vor Cell Value verwenden, wenn mit dynamischen Tabellen gearbeitet wird
Nach stabilen Geschäftswerten suchen, nicht nach Zeilenposition
Aussagekräftige Variablennamen wie orderStatus oder customerName verwenden
Max Pages begrenzen, um langwierige Suchen zu vermeiden
Wichtige Werte mit Assert oder If Nodes validieren

Check Table State

Table Handling

Der Check Table State Node überprüft den aktuellen Zustand einer Tabelle. Wird verwendet, um zu validieren, ob eine Tabelle sichtbar, ausgeblendet, leer, befüllt oder bereit für seitenabhängige Workflows ist.

Wann verwenden

Überprüfen, ob eine Tabelle sichtbar ist, bevor mit ihr interagiert wird
Prüfen, ob eine Tabelle Zeilen enthält
Leere-Zustand-Szenarien kontrolliert behandeln
Paginierungsverhalten validieren (hat nächste Seite, keine nächste Seite)
Sicherstellen, dass tabellenabhängige Workflows sicher fortgesetzt werden können

💡Diesen Node vor Find Row, Cell Value, Paginierungsschritten, Zeilenauswahl oder dynamischen Tabelleninteraktionen verwenden.

Check Table State-Konfiguration — Tabelle und zu prüfenden Erwartungszustand auswählen.

Configuration

Parameter	Description	Required	Example
Table	Zentral verwaltete Tabellendefinition	Yes	`OrdersTable`
State	Zu prüfender erwarteter Tabellenzustand	Yes	`notEmpty`

Verfügbare Zustände

Option	Description
`visible`	Tabelle ist auf dem Bildschirm sichtbar
`hidden`	Tabelle ist nicht sichtbar
`empty`	Tabelle enthält keine Zeilen
`notEmpty`	Tabelle enthält mindestens eine Zeile
`hasNextPage`	Tabelle hat eine nächste Seite
`noNextPage`	Tabelle hat keine nächste Seite

Behavior

Wartet auf den konfigurierten Tabellenzustand
Wertet die ausgewählte Prüfung gegen die Tabelle aus
Stoppt die Ausführung, wenn der erwartete Zustand innerhalb des Timeouts nicht erreicht wird
Ändert weder den Tabelleninhalt noch die Zeilenauswahl

Ausgabe

Keine Ausgabe.

Input Variables

Yes

Output Variables

Beispiel — Vor der Suche prüfen, ob die Tabelle Daten enthält

Parameter	Value
Table	`OrdersTable`
State	`notEmpty`

Diesen Node vor Find Row oder Click Row platzieren, um Fehler bei leeren Tabellen zu vermeiden.

Best Practices

Diesen Node vor Paginierungs- oder Zeileninteraktionsschritten verwenden
Tabellensichtbarkeit vor Find Row oder Cell Value validieren
Leere-Zustand-Szenarien explizit behandeln
Has next page vor Paginierungsschleifen und No next page zur Erkennung des Endes verwenden

Click Row

Table Handling

Der Click Row Node lokalisiert und klickt eine passende Geschäftszeile innerhalb einer konfigurierten Tabelle. Wird verwendet, um zeilenbasierte Aktionen auszulösen, wie das Öffnen von Detailansichten, das Auswählen von Datensätzen oder das Ausführen von Standard-Tabelleninteraktionen.

Wann verwenden

Details für einen bestimmten Geschäftsdatensatz öffnen
Eine Zeile in einer Tabelle auswählen
Aktionen auf Zeilenebene auslösen
Von einer Tabelle zu einer Detailseite navigieren
Mit dynamischen Geschäftstabellen interagieren, ohne auf Zeilenindizes zu vertrauen

💡Dieser Node klickt auf die Geschäftszeile selbst — nicht auf ein bestimmtes Zellenelement.

Click Row-Konfiguration — Bedingungen zur Identifikation der Ziel-Geschäftszeile definieren.

Configuration

Parameter	Description	Required	Example
Table	Zentral verwaltete Tabellendefinition	Yes	`OrdersTable`
Match	Legt fest, wie mehrere Bedingungen ausgewertet werden	No	`All conditions`
Where	Bedingungen zur Identifikation der Zielzeile	Yes	`Order Number equals ${orderNumber}`
Search Scope	Legt fest, wo die Tabellensuche beginnen soll	No	`Start from first page`
Max Pages	Maximale Anzahl der zu durchsuchenden Seiten	No	`10`

Verhalten

Durchsucht die konfigurierte Tabelle nach einer passenden Geschäftszeile
Wendet die konfigurierten Bedingungen an
Navigiert bei Bedarf durch die Paginierung
Bestimmt das technische Klickziel automatisch aus der Tabellendefinition
Führt eine Klickaktion auf der passenden Zeile aus

Ausgabe

Keine Ausgabe.

Input Variables

Yes

Output Variables

Beispiel — Details einer bestimmten Bestellung öffnen

Parameter	Value
Table	`OrdersTable`
Where	`Order Number equals ORD-100245`
Search Scope	`Start from first page`

Best Practices

Nach stabilen Geschäftsbezeichnern statt nach Zeilenposition suchen
All conditions bei der Identifikation eindeutiger Datensätze verwenden
Start from first page für deterministisches Verhalten bevorzugen
Mit Check Table State vor komplexen Tabelleninteraktionen kombinieren

Filter Table

Table Handling

Der Filter Table Node wendet Filter in einer konfigurierten Tabelle an, durchsucht sie oder löscht Filter. Wird verwendet, um sichtbare Geschäftsdatensätze während der Workflow-Ausführung dynamisch einzugrenzen.

Wann verwenden

Eine Tabelle nach Geschäftswerten filtern
Tabelleninhalte durchsuchen
Sichtbare Zeilen vor der Interaktion reduzieren
Aktive Tabellenfilter löschen
Tabellen für Find Row- oder Click Row-Operationen vorbereiten

💡Dieser Node ermöglicht Workflows das effiziente Arbeiten mit großen und dynamischen Geschäftstabellen.

Filter Table-Konfiguration — Filtermodus, Geschäftsspalte und Filterwert auswählen.

Configuration

Parameter	Description	Required	Example
Table	Zentral verwaltete Tabellendefinition	Yes	`OrdersTable`
Filter Mode	Legt die Art der Filteroperation fest	Yes	`Column Filter`
Column	Zu filternde Geschäftsspalte (Column Filter-Modus)	No	`Status`
Operator	Filtervergleichsoperator	No	`contains`
Value	Anzuwendender Filterwert	No	`Active`

* Column, Operator und Value sind für den Column Filter-Modus erforderlich.

Filter-Modi

Column Filter

Wendet einen Filter auf eine bestimmte Geschäftsspalte mit einem Wert und Operator (equals, contains usw.) an.

Global Search

Führt eine globale Tabellensuche über alle Spalten hinweg aus.

Clear Filters

Entfernt alle aktiven Tabellenfilter und stellt den vollständigen Datensatz wieder her.

Ausgabe

Keine Ausgabe.

Input Variables

Yes

Output Variables

Beispiel — Bestellungstabelle nach Status filtern

Parameter	Value
Table	`OrdersTable`
Filter Mode	`Column Filter`
Column	`Status`
Operator	`equals`
Value	`Active`

Best Practices

Tabellen vor dem Suchen oder Klicken von Zeilen filtern
contains für flexible Suchen bevorzugen
equals für deterministische Validierungen verwenden
Filter vor dem Start nicht zusammenhängender Tabellenoperationen löschen

Find Row

Table Handling

Der Find Row Node durchsucht eine konfigurierte Tabelle und speichert eine passende Zeile als Variable. Wird verwendet, um eine bestimmte Tabellenzeile anhand einer oder mehrerer Geschäftsbedingungen zu finden.

Wann verwenden

Eine bestimmte Zeile in einer Tabelle muss gefunden werden
Ein späterer Schritt soll mit Zellen in dieser Zeile interagieren
Tabelleninhalt anhand von Geschäftsdaten validieren
Die Zeilenposition kann sich zwischen Ausführungen ändern
Feste Zeilenindizes sollen vermieden werden

💡Find Row verwenden, wenn der Test Daten nach Bedeutung und nicht nach Position identifizieren soll.

Find Row-Konfiguration — Bedingungen zur Zeilenfindung und den Save Row As-Variablennamen definieren.

Configuration

Parameter	Description	Required	Example
Table	Zentral verwaltete Tabellendefinition	Yes	`OrdersTable`
Match	Legt fest, wie mehrere Bedingungen ausgewertet werden	No	`All conditions`
Where	Bedingungen zur Identifikation der Zielzeile	Yes	`Order Number equals ${orderNumber}`
Save Row As	Variablenname zum Speichern der gefundenen Zeile	Yes	`foundRow`
Search Scope	Legt fest, wo die Tabellensuche beginnen soll	No	`Start from first page`
Max Pages	Maximale Anzahl der zu durchsuchenden Seiten	No	`10`

Verhalten

Verwendet die ausgewählte Tabellendefinition
Wertet die konfigurierten Bedingungen gegen Tabellenzeilen aus
Wählt die passende Zeile basierend auf der Find-Option aus (erste, letzte, erste sichtbare)
Speichert den Zeilenverweis in der durch Save Row As definierten Variable
Macht die Zeile für spätere tabellenbezogene Nodes verfügbar

Ausgabe

Die passende Zeile wird in der durch Save Row As definierten Variable gespeichert und kann in nachfolgenden Cell Value-, Click Row- oder Run Cell Action-Nodes verwendet werden.

Input Variables

Yes

Output Variables

Yes

Beispiel — Bestellzeile anhand der Bestellnummer finden

Parameter	Value
Table	`OrdersTable`
Where	`Order Number equals ORD-100245`
Save Row As	`targetOrder`

Best Practices

Nach stabilen Geschäftswerten suchen, nicht nach Zeilenposition
Klare Variablennamen wie orderRow, customerRow oder invoiceRow verwenden
All conditions bei der Identifikation einer eindeutigen Zeile bevorzugen
Mehrere Bedingungen verwenden, wenn ein einzelner Wert möglicherweise nicht eindeutig ist
Nach dem Finden der Zeile einen Assert oder Soft Verify hinzufügen, um die erwarteten Daten zu bestätigen

Table Inspect

Table Handling

Der Table Inspect Node liest strukturelle und Laufzeitinformationen aus einer konfigurierten Tabelle. Wird verwendet, um Header, Spalten, Sortierung, Paginierung, Auswahlzustand und verfügbare Zeilenaktionen während der Workflow-Ausführung zu inspizieren.

Wann verwenden

Tabellenstruktur dynamisch validieren
Tabellenmetadaten lesen (aktuelle Seite, Gesamtseiten, Anzahl ausgewählter Elemente)
Sortierungs- oder Paginierungszustand überprüfen
Ausgewählte Zeilen inspizieren
Fortgeschrittene oder adaptive Tabellen-Workflows erstellen

💡Dieser Node stellt Laufzeit-Tabellenintelligenz bereit, die in späteren Workflow-Schritten wiederverwendet werden kann.

Table Inspect-Konfiguration — Inspektionsmodus und Variable zum Speichern des Ergebnisses auswählen.

Configuration

Parameter	Description	Required	Example
Table	Zentral verwaltete Tabellendefinition	Yes	`OrdersTable`
Mode	Legt fest, welche Tabelleninformationen inspiziert werden	Yes	`Pagination`
Store As	Variablenname zum Speichern des Inspektionsergebnisses	Yes	`tableInfo`

Verfügbare Modi

Option	Description
`Pagination`	Liest den Paginierungszustand: aktuelle Seite, Gesamtseiten, hat nächste Seite
`Headers`	Liest Spaltenheader-Informationen
`Columns`	Liest konfigurierte Geschäftsspaltendefinitionen
`SelectedRows`	Liest aktuell ausgewählte Zeilen
`RowActions`	Liest verfügbare Zeilenaktionen aus der Tabellendefinition

Behavior

Liest Tabellenstrukturinformationen basierend auf dem ausgewählten Inspektionsmodus
Ruft Laufzeit-Metadaten ab, wie aktuelle Seite, Gesamtseiten, ausgewählte Zeilen
Speichert strukturierte Inspektionsergebnisse für die spätere Verwendung im Workflow
Ändert keine Tabellendaten, wendet keine Filter an, klickt keine Zeilen an und ändert keine Paginierung

Ausgabe

Inspektionsergebnisse werden in der durch Store As definierten Variable gespeichert. Beispiel: ${tableInfo.currentPage}, ${tableInfo.totalPages}

Input Variables

Yes

Output Variables

Yes

Beispiel — Paginierungszustand vor einer Schleife inspizieren

Parameter	Value
Table	`OrdersTable`
Mode	`Pagination`
Store As	`tableInfo`

Verwendung: If ${tableInfo.hasNextPage} equals true → navigate to next page

Best Practices

Table Inspect vor fortgeschrittenen Tabelleninteraktionen verwenden
Inspektionsergebnisse mit aussagekräftigen Variablennamen speichern
Paginierungsinspektion vor Paginierungsschleifen verwenden
Mit If Nodes für adaptive Workflows kombinieren
Spaltenvalidierung verwenden, um Tabellenkonfigurationsänderungen früh zu erkennen

Load / Scroll Table

Table Handling

Der Load / Scroll Table Node lädt zusätzliche Zeilen oder steuert die Scroll-Position einer konfigurierten Tabelle. Wird für verzögert geladene, virtuelle, unendlich scrollende oder lange Tabellen verwendet, bei denen nicht alle Zeilen sofort verfügbar sind.

Wann verwenden

Mit verzögert geladenen oder virtuellen Tabellen arbeiten
Zusätzliche Zeilen laden, bevor Daten gesucht oder validiert werden
An den Anfang oder das Ende einer Tabelle scrollen
Eine passende Geschäftszeile in den sichtbaren Bereich bringen
Tabellen ohne klassische Paginierung behandeln

Load / Scroll Table-Konfiguration — Tabelle und die auszuführende Lade- oder Scroll-Aktion auswählen.

Configuration

Parameter	Description	Required	Example
Table	Zentral verwaltete Tabellendefinition	Yes	`OrdersTable`
Action	Legt die auszuführende Lade- oder Scroll-Operation fest	Yes	`Load More Once`
Where	Bedingungen zur Identifikation der Zeile, zu der gescrollt werden soll (nur Scroll to Matching Row)	No	`Order Number equals ${orderNumber}`

Ladeoptionen

Load More Once

Lädt den nächsten Satz von Zeilen. Bietet präzise Kontrolle über jeden Ladeschritt.

Load All Rows

Lädt wiederholt Zeilen, bis die Tabelle keine weiteren Daten meldet.

Scroll to Top/Bottom

Scrollt den Tabellenanzeigebereich nach oben oder unten.

Scroll to Matching Row

Scrollt, bis eine passende Geschäftszeile sichtbar wird.

Ausgabe

Keine Ausgabe.

Input Variables

Yes

Output Variables

Beispiel — Alle Zeilen in einer virtuellen Tabelle laden

Parameter	Value
Table	`OrdersTable`
Action	`Load All Rows`

Diesen Node vor Find Row oder Rows verwenden, um sicherzustellen, dass alle Daten verfügbar sind.

Best Practices

Load more once für präzise Kontrolle über jeden Ladeschritt verwenden
Load all rows nur bei überschaubarer Tabellengröße verwenden
Scroll to matching row bevorzugen, wenn nach einem bekannten Geschäftsdatensatz gesucht wird
Das Laden aller Zeilen bei sehr großen Datensätzen vermeiden, sofern nicht notwendig
Mit Check Table State oder Find Row für zuverlässige Validierung kombinieren

Change Table Page

Table Handling

Der Change Table Page Node navigiert zwischen Seiten in einer paginierten Tabelle. Wird verwendet, um direkt durch die Tabellenpaginierung zu navigieren, anstatt auf automatische Tabellensuche zu vertrauen.

Wann verwenden

Manuelles Navigieren durch paginierte Tabellen
Zur nächsten oder vorherigen Tabellenseite wechseln
Direkt zu einer bestimmten Seite springen
Kontrollierte Paginierungs-Workflows erstellen
In Schleifen durch Seiten iterieren

💡Dieser Node gibt Workflows explizite Kontrolle über das Tabellenblätterungsverhalten.

Change Table Page-Konfiguration — Tabelle und Seitennavigationsaktion auswählen.

Configuration

Parameter	Description	Required	Example
Table	Zentral verwaltete Tabellendefinition	Yes	`OrdersTable`
Action	Auszuführende Seitennavigationsaktion	Yes	`Next Page`
Page Number	Zielseitennummer (nur für Go To Page-Aktion)	No	`3`

Verfügbare Seitenaktionen

Navigiert zur nächsten Seite der Tabelle.

Navigiert zur vorherigen Seite der Tabelle.

First Page

Springt zur ersten Seite der Tabelle.

Go To Page

Springt direkt zu einer angegebenen Seitennummer.

Ausgabe

Keine Ausgabe.

Input Variables

Yes

Output Variables

Beispiel — Zur nächsten Seite navigieren

Parameter	Value
Table	`OrdersTable`
Action	`Next Page`

Verwenden Sie Check Table State (hasNextPage) vor diesem Node, um Fehler auf der letzten Seite zu vermeiden.

Best Practices

Check Table State vor dem Navigieren zur nächsten Seite verwenden
Mit Loop Nodes für die Verarbeitung mehrerer Seiten kombinieren
Go to page nur verwenden, wenn Seitennummern stabil und vorhersehbar sind
Timeouts realistisch für die Tabellenladeperformance halten

Rows

Table Handling

Der Rows Node zählt, liest oder validiert Zeilen innerhalb einer konfigurierten Tabelle. Wird verwendet, um während der Workflow-Ausführung dynamisch mit sichtbaren, passenden, ausgewählten oder gesamten Zeilensätzen zu arbeiten.

Wann verwenden

Zeilen in einer Tabelle zählen
Passende Zeilen in ein Array einlesen
Existenz von Zeilen validieren
Zeilenanzahlen überprüfen
Validierungen über mehrere Zeilen hinweg anwenden

💡Entwickelt für skalierbare Geschäftstabellen-Validierung und Massenverarbeitung von Zeilen.

Rows-Konfiguration — Aktion (count, read, verify), zu zählendes Objekt und Bedingungen auswählen.

Configuration

Parameter	Description	Required	Example
Table	Zentral verwaltete Tabellendefinition	Yes	`OrdersTable`
Action	Legt fest, was mit den Zeilen geschehen soll	Yes	`Count`
What to Count	Legt fest, welche Zeilen gezählt werden	No	`Visible rows`
Match	Legt fest, wie mehrere Bedingungen ausgewertet werden	No	`All conditions`
Where	Bedingungen zur Identifikation passender Zeilen	No	`Status equals Active`
Save As	Variablenname zum Speichern des Ergebnisses	No	`rowCount`

* Save As ist für die Aktionen Count und Read Matching Rows erforderlich.

Verfügbare Aktionen

Count

Zählt sichtbare, passende, ausgewählte oder gesamte Zeilen und speichert das Ergebnis.

Read Matching Rows

Liest alle passenden Zeilen in ein Array für die weitere Verarbeitung.

Verify Presence

Überprüft, ob mindestens eine passende Zeile existiert.

Verify All Rows

Überprüft, ob alle passenden Zeilen die konfigurierten Bedingungen erfüllen.

Ausgabe

Für Count- und Read Matching Rows-Aktionen wird das Ergebnis in der durch Save As definierten Variable gespeichert.

Input Variables

Yes

Output Variables

Yes

Beispiel — Aktive Bestellungen in der Tabelle zählen

Parameter	Value
Table	`OrdersTable`
Action	`Count`
Where	`Status equals Active`
Save As	`activeCount`

Best Practices

Aussagekräftige Save As-Variablennamen verwenden
Geschäftsbedingungen gegenüber Zeilenpositionen bevorzugen
Read matching rows für die erweiterte Zeilenverarbeitung verwenden
Verify presence vor der Zeileninteraktion verwenden
Mit Filter Table für große Datensätze kombinieren

Run Cell Action

Table Handling

Der Run Cell Action Node führt eine konfigurierte Aktion aus einer bestimmten Geschäftsspalte innerhalb einer passenden Tabellenzeile aus. Wird verwendet, um zeilenspezifische Aktionen auszulösen, wie das Öffnen von Details, Bearbeiten von Datensätzen, Herunterladen von Dateien oder Ausführen von Kontextmenüaktionen direkt aus einer Tabellenzelle.

Wann verwenden

Aktionen aus Aktionsspalten auslösen
Zeilenspezifische Schaltflächen oder Menüs anklicken
Detail- oder Bearbeitungsdialoge öffnen
Geschäftsaktionen innerhalb von Tabellen ausführen
Mit dynamischen Zeilenaktionen interagieren, ohne auf technische Selektoren zu vertrauen

💡Dieser Node interagiert mit konfigurierten Geschäftsaktionen statt mit rohen UI-Elementen.

Run Cell Action-Konfiguration — Tabelle, Geschäftsspalte, Action Key und Zeilenbedingungen angeben.

Configuration

Parameter	Description	Required	Example
Table	Zentral verwaltete Tabellendefinition	Yes	`OrdersTable`
Column	Geschäftsspalte, die die Aktion enthält	Yes	`Actions`
Action Key	Schlüssel zur Identifikation der spezifischen auszuführenden Aktion	Yes	`edit`
Match	Legt fest, wie mehrere Bedingungen ausgewertet werden	No	`All conditions`
Where	Bedingungen zur Identifikation der Zielzeile	Yes	`Order Number equals ${orderNumber}`
Search Scope	Legt fest, wo die Tabellensuche beginnen soll	No	`Start from first page`
Max Pages	Maximale Anzahl der zu durchsuchenden Seiten	No	`10`

Ausgabe

Keine Ausgabe.

Input Variables

Yes

Output Variables

Beispiel — Edit-Aktion einer bestimmten Bestellzeile anklicken

Parameter	Value
Table	`OrdersTable`
Column	`Actions`
Action Key	`edit`
Where	`Order Number equals ORD-100245`

Best Practices

Stabile Geschäftsbedingungen zur Zeilenidentifikation verwenden
All conditions für die eindeutige Zeilenidentifikation bevorzugen
Aussagekräftige Action Keys in Tabellendefinitionen verwenden
Start from first page für deterministische Workflows bevorzugen
Mit Check Table State vor komplexen Tabellenaktionen kombinieren

Run Row Action

Table Handling

Der Run Row Action Node führt eine konfigurierte Aktion direkt auf einer passenden Tabellenzeile aus. Wird verwendet, um geschäftsspezifische Zeilenaktionen auszulösen, wie das Öffnen von Detailansichten, Bearbeiten von Datensätzen, Löschen von Einträgen oder Ausführen von workflowspezifischen Zeilenoperationen.

Wann verwenden

Auf einer Tabellenzeile konfigurierte Aktionen ausführen
Detailansichten oder Bearbeitungsdialoge öffnen
Datensätze löschen
Zeilenspezifische Workflows auslösen
Mit dynamischen Geschäftstabellen arbeiten, ohne auf technische Selektoren zu vertrauen

💡Dieser Node führt Aktionen aus, die auf Zeilenebene definiert sind, statt innerhalb einer bestimmten Zelle.

Run Row Action-Konfiguration — Tabelle, Action Key und Zeilenbedingungen angeben.

Configuration

Parameter	Description	Required	Example
Table	Zentral verwaltete Tabellendefinition	Yes	`OrdersTable`
Action Key	Schlüssel zur Identifikation der auszuführenden Zeilenaktion	Yes	`delete`
Match	Legt fest, wie mehrere Bedingungen ausgewertet werden	No	`All conditions`
Where	Bedingungen zur Identifikation der Zielzeile	Yes	`Order Number equals ${orderNumber}`
Search Scope	Legt fest, wo die Tabellensuche beginnen soll	No	`Start from first page`
Max Pages	Maximale Anzahl der zu durchsuchenden Seiten	No	`10`

Ausgabe

Keine Ausgabe.

Input Variables

Yes

Output Variables

Beispiel — Stornierte Bestellzeile löschen

Parameter	Value
Table	`OrdersTable`
Action Key	`delete`
Where	`Status equals Cancelled`

Best Practices

Stabile Geschäftsbedingungen zur Zeilenidentifikation verwenden
All conditions für die eindeutige Zeilenidentifikation bevorzugen
Aussagekräftige Row Action Keys verwenden
Start from first page für deterministische Workflows bevorzugen
Max Pages realistisch halten, um langsame Ausführung zu vermeiden

Set Row Selection

Table Handling

Der Set Row Selection Node wählt Zeilen in einer konfigurierten Tabelle aus oder hebt die Auswahl auf. Wird verwendet, um den Zeilenauswahlzustand zu steuern, ohne technische Auswahldetails wie Checkboxen oder interne UI-Implementierungen offenzulegen.

Wann verwenden

Geschäftsdatensätze in einer Tabelle auswählen
Zeilen abwählen
Massenauswahlen verwalten
Zeilen für Batch-Operationen vorbereiten
Mit Mehrfach- oder Einfachauswahl-Tabellen arbeiten

💡Dieser Node abstrahiert das Tabellenauswahlverhalten in geschäftsspezifische Workflow-Aktionen.

Set Row Selection-Konfiguration — Auswahlakton und Zeilenbedingungen definieren.

Configuration

Parameter	Description	Required	Example
Table	Zentral verwaltete Tabellendefinition	Yes	`OrdersTable`
Action	Auszuführende Auswahloperaton	Yes	`Select Matching`
Match	Legt fest, wie mehrere Bedingungen ausgewertet werden	No	`All conditions`
Where	Bedingungen zur Identifikation der auszuwählenden Zeilen	No	`Status equals Active`
Max Pages	Maximale Anzahl der zu durchsuchenden Seiten	No	`10`

Auswahlaktionen

Select Matching

Wählt Zeilen aus, die den konfigurierten Geschäftsbedingungen entsprechen.

Deselect Matching

Hebt die Auswahl von Zeilen auf, die den konfigurierten Geschäftsbedingungen entsprechen.

Select All Visible

Wählt alle aktuell sichtbaren Zeilen in der Tabelle aus.

Clear Selection

Hebt die Auswahl aller ausgewählten Zeilen in der Tabelle auf.

Ausgabe

Keine Ausgabe.

Input Variables

Yes

Output Variables

Beispiel — Alle aktiven Bestellzeilen auswählen

Parameter	Value
Table	`OrdersTable`
Action	`Select Matching`
Where	`Status equals Active`

Best Practices

Stabile Geschäftsbedingungen zur Zeilenidentifikation verwenden
Alte Auswahlen vor neuen Massenoperationen ggf. löschen
Mit Rows oder Table Inspect zur Validierung des Auswahlzustands kombinieren
Max Pages realistisch halten, um langwierige Suchen zu vermeiden

Sort Table

Table Handling

Der Sort Table Node wendet Sortierung für eine Geschäftsspalte in einer konfigurierten Tabelle an oder hebt sie auf. Wird verwendet, um die Tabellensortierung dynamisch zu steuern, ohne auf technische Header-Selektoren oder manuelle UI-Klicks zu vertrauen.

Wann verwenden

Tabellendaten nach einer Geschäftsspalte sortieren
Tabellensortierung vor der Validierung ändern
Deterministische Tabellenzustände vorbereiten
Sortierte Datensätze überprüfen
Aktive Sortierung einer Spalte entfernen

💡Bietet Sortierungssteuerung auf Geschäftsebene für dynamische Unternehmenstabellen.

Sort Table-Konfiguration — Geschäftsspalte und Sortierungsrichtung auswählen.

Configuration

Parameter	Description	Required	Example
Table	Zentral verwaltete Tabellendefinition	Yes	`OrdersTable`
Column	Geschäftsspalte, nach der sortiert wird	Yes	`Order Date`
Direction	Anzuwendende Sortierungsrichtung	Yes	`Descending`

Sortierungsrichtungen

Ascending

Sortiert die Spalte von niedrigsten zu höchsten Werten (A–Z, 0–9).

Descending

Sortiert die Spalte von höchsten zu niedrigsten Werten (Z–A, 9–0).

Clear Sorting

Entfernt die Sortierung der ausgewählten Geschäftsspalte.

Ausgabe

Keine Ausgabe.

Input Variables

Yes

Output Variables

Beispiel — Bestellungen nach Datum absteigend sortieren

Parameter	Value
Table	`OrdersTable`
Column	`Order Date`
Direction	`Descending`

Best Practices

Sortierung vor zeilenbasierter Validierung anwenden
Stabile Geschäftsspalten für deterministische Workflows verwenden
Sortierung löschen, wenn Workflows zu einem neutralen Tabellenzustand zurückkehren sollen
Mit Rows oder Find Row für vorhersehbare Tabelleninteraktion kombinieren

Table Verify

Table Handling

Der Table Verify Node ist der zentrale Verifikationsnode für tabellenbasierte Workflows. Wird verwendet, um Tabellenzustand, Header, Spalten, Zeilen, Anzahlen, Sortierung, Auswahl, Zellwerte und konfigurierte Zeilenaktionen in einem einzigen einheitlichen Verifikationsnode zu validieren.

Wann verwenden

Tabellensichtbarkeit oder leere Zustände überprüfen
Tabellenstruktur validieren (Header, Spalten)
Zeilenanzahlen oder Zeilenexistenz überprüfen
Zellwerte validieren
Sortierungsverhalten prüfen
Ausgewählte Zeilen und konfigurierte Zeilenaktionen validieren

💡Dieser Node zentralisiert die meisten tabellenbezogenen Validierungsszenarien in einer wiederverwendbaren Verifikationskomponente.

Table Verify-Konfiguration — Verifikationstyp, Tabelle und erwartete Werte auswählen.

Configuration

Parameter	Description	Required	Example
Table	Zentral verwaltete Tabellendefinition	Yes	`OrdersTable`
Verification Type	Legt fest, welcher Aspekt der Tabelle verifiziert wird	Yes	`Row Count`
Match	Legt fest, wie mehrere Bedingungen ausgewertet werden	No	`All conditions`
Where	Bedingungen zur Identifikation von Zeilen (wo anwendbar)	No	`Status equals Active`
Expected Value	Erwarteter Wert für den Vergleich (wo anwendbar)	No	`5`

* Expected Value is required for value comparison verifications.

Verification Types

Table State

Verify visibility, emptiness, or pagination state (has/no next page).

Column / Header

Verify that a specific business column or header exists in the table.

Row Count / Presence

Verify the number of rows or that a matching row exists.

Cell Value

Verify the value of a specific cell in a matching row.

Sorting

Verify that the table is sorted by a specific column and direction.

Row Action

Verify that a configured action exists on a matching row.

Behavior

Automatically uses table definitions, business columns, configured row actions, and pagination handling
Verification failures stop the workflow unless Soft Verify is enabled

Output

No output. Verification failures stop the workflow unless Soft Verify is enabled.

Input Variables

Yes

Output Variables

Example — Verify the status of a specific order row

Parameter	Value
Table	`OrdersTable`
Verification Type	`Cell Value`
Column	`Status`
Where	`Order Number equals ORD-100245`
Expected Value	`Delivered`

Best Practices

Use business conditions instead of row indexes
Prefer centralized table verification over custom assertions
Verify table state before row interaction
Use explicit sorting verification in deterministic workflows
Validate pagination behavior in large datasets
Keep verification focused and readable

Test Runs

Das Test Runs-Modul bietet zentralisierte Transparenz über automatisierte Testausführungen, Ausführungshistorie, Workflow-Stabilität und Debugging-Informationen. Es gibt Teams alles, was sie benötigen, um ihre automatisierten Test-Workflows zu überwachen, zu untersuchen und zu verbessern.

Was das Modul bietet

Ausführungsgesundheit über alle Workflows hinweg überwachen
Workflow-Stabilität und Pass-Rate-Trends analysieren
Einzelne Fehler mit schrittweisen Traces untersuchen
Flaky Automation erkennen, bevor sie Probleme verursacht
Detaillierte Ausführungs-Traces mit Screenshots prüfen
Automatische Self-Healing-Aktivität und Ergebnisse überprüfen

Modulsektionen

Test Run Overview

Zentraler Einstiegspunkt für alle ausgeführten Workflows und historischen Ausführungen, geordnet nach Workflow und einzelnem Lauf.

Test Details Page

Analyse der Ausführungen auf Workflow-Ebene, einschliesslich Pass Rates, Dauer-Trends, Flaky-Werten und vollständiger Ausführungshistorie.

Run Details Page

Vollständige schrittweise Ausführungsübersicht für einen einzelnen Lauf — einschliesslich Screenshots, Fehlern und Healing-Details.

Test Run Overview

Test Runs

Die Test Run Overview ist der zentrale Einstiegspunkt für alle ausgeführten Workflows und historischen Ausführungen. Sie gibt Teams einen Überblick über den Ausführungszustand und ermöglicht eine schnelle Navigation zu einzelnen Läufen oder Workflow-Details.

Wann verwenden

Überwachung der allgemeinen Gesundheit Ihrer Automations-Suite
Identifizierung welche Workflows fehlschlagen oder instabil werden
Navigation zu einer bestimmten Ausführung zur Untersuchung
Filtern von Läufen nach Status, Environment oder Zeitraum

Die Übersicht ist in zwei Tabs unterteilt: Tests (aggregierte Analyse auf Workflow-Ebene) und Runs (Übersicht einzelner Ausführungen).

Tests-Tab

Der Tests-Tab konzentriert sich auf Workflow-Stabilität und historische Ausführungsqualität. Er hilft Benutzern dabei zu identifizieren:

Instabile Workflows und Flaky Automation
Ausführungstrends über die Zeit
Langfristige Qualitätsindikatoren

Tests-Tab — Analyse auf Workflow-Ebene mit Pass Rates, Dauer und Stabilitätsindikatoren.

Verfügbare Spalten

Column	Description
Test	Name des Workflows
Pass Rate	Prozentsatz erfolgreicher Ausführungen
Duration	Durchschnittliche Ausführungsdauer
Runs	Gesamtanzahl der Ausführungen
Status	Aktueller Workflow-Zustand
Last Runs	Visualisierung des jüngsten Ausführungstrends

Flaky Label

Als instabil erkannte Tests werden automatisch mit einem Flaky-Label markiert. Der Flaky-Wert wird auf Basis von Pass/Fail-Wechseln, inkonsistentem Ausführungsverhalten und instabiler Ausführungshistorie berechnet — sodass Teams schnell Automation identifizieren können, die Stabilisierung erfordert.

Workflow-Status

Status	Description
Passed	Letzte Ausführungen erfolgreich abgeschlossen
Failed	Letzte Ausführung fehlgeschlagen
Running	Workflow wird gerade ausgeführt
Aborted	Workflow-Ausführung manuell oder extern gestoppt
Broken	Workflow schlug über mehrere Ausführungen hinweg kontinuierlich fehl

Runs-Tab

Der Runs-Tab zeigt alle einzelnen Workflow-Ausführungen an. Diese Ansicht konzentriert sich auf:

Ergebnisse und Status einzelner Ausführungen
Verwendete Environments und Browser oder Geräte
Laufzeitanalyse und Dauer
Healing-Sichtbarkeit pro Ausführung

Runs-Tab — Liste einzelner Ausführungen mit Environment, Browser, Dauer und Healing-Indikatoren.

Verfügbare Spalten

Column	Description
Run	Name des ausgeführten Workflows
Executed At	Ausführungszeitstempel
Status	Ausführungsergebnis
Tests	Anzahl der ausgeführten Tests
Duration	Gesamtlaufzeit
Environment	Ausführungs-Environment
Browser	Verwendeter Browser oder Gerät
Actions	Ausführungsdetails öffnen

Healing-Indikator

Ein violettes Herzsymbol neben einem Lauf zeigt an, dass Self-Healing während der Ausführung angewendet wurde. Die Zahl gibt an, wie viele Healing-Operationen stattgefunden haben.

Beispiele

Indikator	Bedeutung
💜 1	Ein Selector oder Workflow-Schritt wurde automatisch geheilt
💜 3	Drei Healing-Operationen erfolgten während dieser Ausführung

Dies bietet sofortige Transparenz über Workflow-Resilienz und automatisches Wiederherstellungsverhalten, ohne den vollständigen Ausführungsbericht öffnen zu müssen.

Suche und Filterung

Die Test Run Overview unterstützt mehrere Filter- und Suchfunktionen, um bestimmte Läufe oder Workflows schnell zu finden.

Suche

Benutzer können nach Workflow-Name, Laufname oder Lauf-ID suchen.

Status-Filter

Filter	Beschreibung
All Status	Alle Ausführungen anzeigen
Passed	Nur erfolgreiche Ausführungen anzeigen
Failed	Nur fehlgeschlagene Ausführungen anzeigen
Running	Aktuell aktive Ausführungen anzeigen
Aborted	Abgebrochene Ausführungen anzeigen

Environment-Filter

Ausführungen nach Environment filtern, um umgebungsspezifische Probleme zu isolieren. Beispiele: staging, production, mobile-device-farm.

Zeitraum-Filter

Zeitraum	Beschreibung
Last 7 days	Jüngste Ausführungsaktivität
Last 30 days	Mittelfristige Analyse
Last 90 days	Langfristige Stabilitätsprüfung
All time	Vollständige Ausführungshistorie

Test Details Page

Test Runs

Die Test Details Page bietet Analysen der Ausführungen auf Workflow-Ebene und historische Trends für einen bestimmten Workflow. Sie gibt Teams die nötigen Einblicke, um langfristige Automationsstabilität zu verstehen und wiederkehrende Probleme zu untersuchen.

Wann verwenden

Analyse der Stabilität eines bestimmten Workflows über die Zeit
Überprüfung der vollständigen Ausführungshistorie eines Workflows
Untersuchung wiederkehrender oder sporadischer Fehler
Überwachung von Flaky-Verhalten und Nachverfolgung von Verbesserungen

Test Details Page — Analyse auf Workflow-Ebene mit Metriken, Pass Rate und Ausführungs-Timeline.

Verfügbare Metriken

Der obere Bereich der Test Details Page zeigt wichtige Leistungskennzahlen für den ausgewählten Workflow an.

Metrik	Beschreibung
Total Runs	Gesamtanzahl der Workflow-Ausführungen
Pass Rate	Prozentsatz erfolgreicher Ausführungen
Avg Duration	Durchschnittliche Laufzeit über alle Ausführungen
Last Green	Zeitstempel der letzten erfolgreichen Ausführung
Flaky Score	Workflow-Stabilitätsindikator basierend auf Pass/Fail-Wechseln

Ausführungshistorie

Die Ausführungs-Timeline visualisiert das historische Workflow-Verhalten mithilfe farbiger Statusindikatoren, sodass Muster und Instabilitätsphasen auf einen Blick erkennbar sind.

Ausführungshistorie — farbige Timeline mit bestandenen, fehlgeschlagenen und übersprungenen Ausführungen im Zeitverlauf.

Farbe	Bedeutung
Grün	Bestanden
Rot	Fehlgeschlagen
Grau	Übersprungen

Diese Visualisierung hilft Benutzern, instabile Ausführungsphasen, wiederkehrende Fehler, Stabilitätsverbesserungen und Ausführungstrends schnell zu erkennen.

Historische Laufliste

Unterhalb der Timeline werden alle historischen Ausführungen des ausgewählten Workflows aufgelistet. Jeder Eintrag enthält:

Ausführungsdatum und -uhrzeit
Status-Ergebnis
Retry-Informationen
Laufzeitdauer
Environment und Browser
Eindeutige Lauf-ID

Ein Klick auf das Augensymbol in einer Ausführungszeile öffnet den Test Execution Details-Dialog — eine kompakte Zusammenfassung mit schnellem Zugriff auf wichtige Ausführungsinformationen, bevor der vollständige Bericht geöffnet wird.

Feld	Beschreibung
Status	Ausführungsergebnis
Duration	Laufzeitdauer
Browser	Ausführungs-Browser
Environment	Gewähltes Ausführungs-Environment
Run ID	Eindeutiger Ausführungsbezeichner

Test Execution Details Pop-Up — kompakte Zusammenfassung vor der Navigation zum vollständigen Laufbericht.

💡 Benutzer können direkt aus dem Pop-Up zum vollständigen Ausführungsbericht navigieren, indem sie die Schaltfläche View Full Run Details verwenden — ohne zur Übersicht zurückzukehren.

Run Details Page

Test Runs

Die Run Details Page bietet eine vollständige schrittweise Ausführungsübersicht für eine einzelne Workflow-Ausführung. Sie ist das primäre Werkzeug für Debugging, Ursachenanalyse und Healing-Untersuchung.

Wann verwenden

Debugging einer fehlgeschlagenen Ausführung zur Ursachenfindung
Prüfung jedes Workflow-Schritts und seines Ergebnisses
Validierung von Screenshots zur Beurteilung des UI-Zustands während der Ausführung
Überprüfung von Self-Healing-Verhalten und reparierten Selektoren

Run Details Page — vollständiger schrittweiser Ausführungsbericht für einen einzelnen Workflow-Lauf.

Ausführungszusammenfassung

Der obere Bereich der Run Details Page zeigt eine übergeordnete Zusammenfassung der Ausführung an.

Workflow-Name und Ausführungszeitstempel
Gesamtdauer und übergeordneter Ausführungsstatus
Verwendeter Browser oder Gerät
Ausführungs-Environment
Gesamt-Pass-Rate für diesen Lauf

Test Case Ausführungsfluss

Alle Workflow-Schritte werden chronologisch angezeigt und bieten vollständige Transparenz über das Ausführungsverhalten.

Jeder Schritt enthält:

Node-Typ und Aktionsbeschreibung
Ausführungsdauer pro Schritt
Ausführungsergebnis (bestanden / fehlgeschlagen)
Schritt-Screenshots
Technische Details zum Debugging

Screenshots

Ausführungs-Screenshots werden während der Workflow-Ausführung automatisch erfasst. Sie helfen Benutzern, den Workflow-Fortschritt zu visualisieren, Fehler zu untersuchen, UI-Verhalten zu validieren und den Ausführungskontext zu analysieren. Sichtbarkeit und Skalierung der Screenshots können direkt im Bericht angepasst werden.

Desktop-Schritt-Screenshot

Mobile-Schritt-Screenshot

Fehlerdetails

Fehlgeschlagene Workflow-Schritte zeigen detaillierte technische Fehlerinformationen an, um Debugging und Ursachenanalyse zu vereinfachen.

Fehlertyp	Beschreibung
Missing element	Das Zielelement wurde im DOM nicht gefunden
Selector failure	Der konfigurierte Selector hat kein Element gefunden
Timeout exception	Der Schritt hat das konfigurierte Timeout überschritten
Execution stack trace	Vollständiger technischer Trace für erweitertes Debugging

Fehlerdetails — technische Fehlerinformationen für fehlgeschlagene Workflow-Schritte.

Healing-Details

Wenn Self-Healing während der Ausführung angewendet wurde, zeigt der Bericht detaillierte Healing-Informationen für jeden reparierten Schritt an.

Healing-Details — ursprünglicher Selector, reparierter Selector und Konfidenzwert für jeden geheilten Schritt.

Feld	Beschreibung
Healed Step	Der Workflow-Schritt, der automatische Reparatur erforderte
Old	Ursprünglich fehlschlagender Selector
New	Automatisch reparierter Selector
Confidence	Zuverlässigkeitswert des Healing-Ergebnisses

Healing-Konfidenz

Der Konfidenzwert gibt an, wie zuverlässig die automatische Reparatur ist. Höhere Konfidenzwerte repräsentieren stärkere Selector-Ähnlichkeit, zuverlässigere Healing-Kandidaten und grössere Ausführungsstabilität in Zukunft.

⚠️ Überprüfen Sie Healing-Ergebnisse immer, bevor Sie Workflows in die Produktion übernehmen. Ein niedriger Konfidenzwert kann darauf hinweisen, dass der reparierte Selector manuelle Validierung erfordert.

Häufige Anwendungsfälle

Die häufigsten Szenarien für die Nutzung des Test Runs-Moduls — und welche Ansicht jeweils verwendet wird.

Workflow-Stabilitätsanalyse

Verwenden Sie die Tests-Ansicht, um die allgemeine Automationsqualität zu überwachen.

Als Flaky markierte Workflows identifizieren
Pass Rates über die gesamte Automations-Suite überwachen
Langfristige Automationsqualitätstrends analysieren
Stabilisierungsarbeit nach Flaky-Werten priorisieren

Ausführungsuntersuchung

Verwenden Sie die Runs-Ansicht, um einzelne Ausführungen zu prüfen.

Ergebnisse eines bestimmten Laufs prüfen
Laufzeitverhalten und Dauer analysieren
Umgebungsspezifische Probleme untersuchen
Ergebnisse über verschiedene Browser oder Environments vergleichen

Fehler-Debugging

Verwenden Sie die Run Details Page für eine tiefgehende Untersuchung fehlgeschlagener Ausführungen.

Screenshots prüfen, um den UI-Zustand beim Fehler zu verstehen
Fehlgeschlagene Schritte und deren technische Fehlerausgabe prüfen
Stack Traces für Ursachenanalyse analysieren
Prüfen, ob Self-Healing das Problem gelöst oder verdeckt hat

Healing-Validierung

Verwenden Sie Healing-Indikatoren und Healing-Details, um die automatische Wiederherstellung zu überwachen und zu validieren.

Automatisches Wiederherstellungsverhalten über Läufe hinweg überwachen
Reparierte Selektoren validieren, bevor Workflows übernommen werden
Workflow-Resilienz über die Zeit analysieren
Workflows identifizieren, die zu häufig auf Healing angewiesen sind

Best Practices

Empfehlungen, um das Beste aus dem Test Runs-Modul herauszuholen.

Flaky Workflows regelmässig überwachen — Instabilität erkennen, bevor sie die Produktion erreicht
Broken-Workflows sofort untersuchen — kontinuierliches Fehlschlagen signalisiert ein grundlegendes Problem
Healing-Ergebnisse vor der Workflow-Übernahme prüfen — niedrige Konfidenzwerte erfordern manuelle Validierung
Ausführungshistorie statt isolierter Fehler verwenden — ein einzelner Fehler kann Rauschen sein; ein Muster ist ein Signal
Screenshots beim Debugging analysieren — visueller Kontext ist schneller als das Lesen von Logs
Ausführungen beim Troubleshooting nach Environment filtern — umgebungsspezifische Probleme isolieren
Die Lauf-ID verwenden, um mit Teammitgliedern über bestimmte Ausführungen zu kommunizieren
Statusbasierte Filterung einrichten, um tägliche Reviews auf Failed- und Broken-Workflows zu fokussieren

💡 Das Test Runs-Modul bietet vollständige Transparenz über Workflow-Ausführungsqualität, Laufzeitverhalten und Automationsstabilität — von übergeordneten Analysen bis hin zu detailliertem Ausführungs-Debugging.

Pages

Pages, Fields & Table Definitions

Das Pages-Modul bietet zentralisiertes Management für wiederverwendbare technische UI-Elemente, die in automatisierten Workflows verwendet werden. Es fungiert als technische Grundschicht für Workflows, indem es wiederverwendbare PageObjects, Feld-Selektoren und geschäftsfreundliche Table Definitions organisiert.

Was das Modul bietet

Wiederverwendbare PageObjects für Anwendungsseiten verwalten
Zentralisiertes Selector- und Feld-Management
Wiederverwendbare Geschäftstabellen-Abstraktionen
Selector-Validierung und automatische Wartung
Selector- und Caching-Konfiguration auf Projektebene

Modulstruktur

Abschnitt	Zweck
Pages	Wiederverwendbare PageObjects verwalten
Fields	Zentralisiertes Selector- und Feld-Management
Table Definitions	Wiederverwendbare Geschäftstabellen-Abstraktionen
Settings	Selector- und Caching-Konfiguration auf Projektebene

Page-Generierung

Pages können entweder automatisch vom AI Recorder während Aufzeichnungssitzungen generiert oder manuell erstellt und gepflegt werden. Ziel ist es, das technische Selector-Management von der Workflow-Logik zu trennen und dabei Wiederverwendbarkeit, Wartbarkeit und skalierbare Automation zu ermöglichen.

Pages Management

Pages

Der Pages-Bereich ermöglicht Benutzern das Management wiederverwendbarer PageObjects, die Anwendungsseiten, Bildschirme oder Ansichten repräsentieren. Jedes PageObject kann URLs, wiederverwendbare Felder, verknüpfte Table Definitions, Workflow-Referenzen und Nutzungsmetriken enthalten.

Pages Management — Übersicht aller konfigurierten PageObjects mit Metriken und Verwaltungsaktionen.

Dashboard-Metriken

Metrik	Beschreibung
Total Pages	Gesamtanzahl konfigurierter Pages
Active	Anzahl aktiver PageObjects
Total URLs	Anzahl verknüpfter URLs
Total Usage	Gesamtnutzungszählung für Felder und Workflows

Page-Tabelleninformationen

Spalte	Beschreibung
Name	Eindeutiger PageObject-Name
Description	Optionale Page-Beschreibung
URLs	Verknüpfte URLs
Elements	Anzahl verknüpfter Felder
Workflows	Anzahl verknüpfter Workflows
Usage	Nutzungsstatistiken
Status	Aktiver oder inaktiver Status
Updated	Datum der letzten Änderung

Verfügbare Aktionen

Pages nach Name oder URL suchen
Neue Pages manuell erstellen
Bestehende Page-Konfigurationen bearbeiten
Nicht mehr verwendete Pages löschen
Verknüpfte Workflows prüfen
Technische Code-Ansicht öffnen

Create New Page

Pages

Benutzer können wiederverwendbare PageObjects manuell erstellen. Eine Page repräsentiert eine wiederverwendbare technische Abstraktion eines Anwendungsbildschirms oder -bereichs.

Create New Page — Konfigurationsdialog zum Definieren eines neuen wiederverwendbaren PageObjects.

Konfigurationsoptionen

Feld	Beschreibung
Name	Eindeutiger Page-Bezeichner in PascalCase (z. B. LoginPage, DashboardPage)
Description	Optionale Erläuterung zum Zweck der Page
URLs	Eine oder mehrere der Page zugeordnete URLs
Status	PageObject aktivieren oder deaktivieren
Locator Strategy	Locator-basierte Selektoren kompatibel mit XPath und CSS

💡 Nach der Erstellung können Felder in der Page Details-Ansicht hinzugefügt und verwaltet werden.

Page Details

Pages

Der Page Details-Dialog bietet eine vollständige Übersicht des ausgewählten PageObjects, einschliesslich verknüpfter URLs, verknüpfter Table Definitions, wiederverwendbarer Felder und Workflow-Integrationsaktionen.

Verfügbare Abschnitte

Abschnitt	Beschreibung
URL Section	Alle dem PageObject zugeordneten URLs
Definition Tables	Verknüpfte wiederverwendbare Table Definitions
Fields Section	Alle wiederverwendbaren Selektoren und Felder

Feldeigenschaften

Eigenschaft	Beschreibung
Field Name	Wiederverwendbarer Feld-Bezeichner
Locator	Technischer Selector
Context	Feld-Metadaten

Verfügbare Aktionen

Felder zur Page hinzufügen
Code aus der Page-Struktur generieren
Table Definitions hinzufügen
Page-Konfiguration bearbeiten

Fields Management

Fields

Der Fields-Bereich fungiert als zentralisiertes Selector-Repository für alle wiederverwendbaren technischen Elemente. Fields sind wiederverwendbare Selektoren, die über Workflows, Pages und Validierungen hinweg geteilt werden können.

Fields Management — zentralisiertes Repository aller wiederverwendbaren Selektoren mit Validierungsstatus und Nutzungsmetriken.

Dashboard-Metriken

Metrik	Beschreibung
Total Fields	Gesamtanzahl der Felder
Valid	Erfolgreich validierte Felder
Failed	Fehlerhafte oder ungültige Felder
Pending	Validierung ausstehend
Avg Success Rate	Durchschnittliche Selector-Erfolgsrate

Feldinformationen

Spalte	Beschreibung
Page	Zugeordnete Page
Field Name	Selector-Name
Locator	Technischer Selector
Status	Validierungsstatus
Source	Manuell oder KI-generiert
Properties	Feld-Fähigkeiten
Success Rate	Laufzeit-Erfolgsrate
Usage	Nutzungsstatistiken
Updated	Datum der letzten Änderung

Filterung & Suche

Benutzer können Felder nach Status, Quelle, Page und Suchbegriff filtern, um bestimmte Selektoren im Projekt schnell zu finden.

Edit Field Entry

Fields

Der Edit Entry-Dialog ermöglicht Benutzern die Pflege wiederverwendbarer Selektoren, die Aktualisierung ihrer Locator-Strategie sowie die Konfiguration von Feldtypen und unterstützten Interaktionen.

Edit Field — Selector- und Typ-Konfiguration

Edit Field — Kontext- und Methoden-Details

Bearbeitbare Eigenschaften

Eigenschaft	Beschreibung	Beispiele
Locator	Technischer Selector zur Element-Identifikation	XPath, CSS Selector, Appium locator
Field Type	Definiert die Feld-Fähigkeit	Button, Input, Checkbox, Dropdown, Label
Methods	Unterstützte Interaktionen und Validierungen	click, getText, isEnabled

Kontextinformationen

Der Dialog zeigt auch kontextuelle Metadaten an, einschliesslich Sichtbarkeit, Klickbarkeit, Eingabe-Fähigkeit und der zugeordneten URL.

Table Definitions

Table Definitions bieten wiederverwendbare Geschäftsabstraktionen für dynamische Datentabellen. Anstatt technische Selektoren direkt an Workflow-Benutzer weiterzugeben, stellt das System geschäftsfreundliche Tabellenoperationen bereit.

Table Definitions — Liste aller konfigurierten wiederverwendbaren Tabellenabstraktionen.

Was Table Definitions ermöglichen

Mit Zeilen, Spalten, Filtern, Sortierung und Paginierung arbeiten
Zeilenaktionen ohne technische Komplexität konfigurieren
Tabellenlogik über mehrere Workflows hinweg wiederverwenden
Technische Selektoren von Geschäftsbenutzern abstrahieren

Smart Table Definition Wizard

Table Definitions

Der Wizard vereinfacht die Erstellung wiederverwendbarer Table Definitions. Er unterstützt Geschäftsabstraktion, technische Selector-Generierung und wiederverwendbare Workflow-Integration. Der Simple Mode konzentriert sich auf die geschäftsseitige Konfiguration und verbirgt technische Implementierungsdetails.

Wizard-Schritte

Schritt	Zweck
1 — Basics	Allgemeine Tabellenkonfiguration
2 — Columns	Zuordnung von Geschäftsspalten
3 — Actions	Zeilenaktionen und Fähigkeiten
4 — Review	Generierte Vorschau

Schritt 1 — Basics

Tabellenname, Beschreibung, unterstützte Plattformen, zugeordnete Page und automatisch generierten Status konfigurieren. Unterstützte Plattformen umfassen Web / Playwright und Mobile / Appium.

Schritt 1 — Basics: allgemeine Tabellenkonfiguration und Plattformauswahl.

Schritt 2 — Columns

Wiederverwendbare Geschäftsspalten definieren (z. B. Order Number, Status, Customer, Total, Date). Das System schlägt einen stabilen Row Key vor, der intern für Zeilenreferenzen, wiederverwendbare Kriterien und Workflow-Aktionen verwendet wird.

Schritt 2 — Columns: Zuordnung von Geschäftsspalten und Row-Key-Konfiguration.

Schritt 3 — Actions

Unterstützte Tabellenfähigkeiten und optionale wiederverwendbare Zeilenaktionen konfigurieren. Der Wizard zeigt eine Workflow-Vorschau an, die zeigt, wie die Tabelle in Workflow-Nodes erscheinen wird.

Fähigkeit	Beschreibung
Pagination	Mehrseitige Unterstützung
Sorting	Spaltensortierung
Filtering	Filter-Unterstützung
Actions	Zeilenaktionen
Lazy Load	Unterstützung für endloses Scrollen

Schritt 3 — Actions: Zeilenaktionen, Fähigkeiten und Workflow-Vorschau.

Schritt 4 — Review

Der Review-Schritt zeigt die generierte technische Vorschau, die wiederverwendbare Geschäftszuordnung, die Plattform-Kompatibilität und die generierten Selektoren an.

Schritt 4 — Review: generierte Tabellendefinitions-Vorschau und Plattform-Kompatibilitätszusammenfassung.

Expert Mode

Table Definitions

Der Expert Mode legt die vollständige technische JSON-Konfiguration offen, die intern von der Automations-Engine verwendet wird. Dieser Modus richtet sich an erfahrene Benutzer und Entwickler, die direkte Kontrolle über Selektoren und Fähigkeiten benötigen.

Expert Mode — vollständige JSON-Konfiguration für Web-Definition, Mobile-Definition und Capabilities.

Technische Konfiguration

Konfiguration	Enthält
Web Definition JSON	Tabellen-Selektoren, Zeilen-Selektoren, Zellen-Selektoren
Mobile Definition JSON	Appium- und mobile-spezifische Selektoren
Capabilities JSON	Pagination, Filtering, Sorting, Zeilenaktionen, Lazy Loading

Project Settings

Settings

Der Settings-Bereich steuert das projektweite Selector- und Caching-Verhalten.

Project Settings — Field-Cache-Konfiguration und Selector-Strategie-Einstellungen.

Field-Cache-Einstellungen

Einstellung	Zweck
Enable field caching	Wiederverwendbare Selektoren für schnellere Ausführung cachen
Max Cache Size	Maximale Anzahl gecachter Einträge
Cache Expiration	Zeitpunkt der automatischen Bereinigung
Max Retry Attempts	Retry-Anzahl für fehlgeschlagene Selektoren
Validation Timeout	Timeout für die Selector-Validierung

Automatische Wartung

Automatische Bereinigung veralteter gecachter Selektoren
Automatischer Retry fehlgeschlagener Selektoren
Locator-basierte Selektoren (XPath/CSS kompatibel) als empfohlene Standardstrategie

Page Settings

Settings

Page Settings — seitenspezifische Konfiguration für Screenshots, Validierung und Versionierung.

Page-Konfiguration

Einstellung	Beschreibung
Auto-generate selectors	Selektoren für Page-Elemente automatisch erstellen
Enable screenshots	Screenshots für PageObjects speichern
Screenshot on failure	Screenshots aufnehmen, wenn Selektoren fehlschlagen
Validate selectors	Selektoren bei der Erstellung validieren
Page object versioning	Eine Historie der Selector-Änderungen pflegen

Benachrichtigungseinstellungen

Optionale Benachrichtigungen können für PageObject-Änderungen, Feld-Alerts, Selector-Fehler und tägliche Aktivitätszusammenfassungen konfiguriert werden.

KI & Recorder-Integration

Der Recorder und die KI-Komponenten sind tief in das Pages-Modul integriert, um den manuellen Wartungsaufwand zu minimieren und die Workflow-Erstellung zu beschleunigen.

Automatische Generierung

Pages automatisch aus Aufzeichnungssitzungen erstellen
Selektoren generieren und Felder ohne manuelle Eingabe validieren
Wiederverwendbare Page-Strukturen aus beobachteten UI-Interaktionen aufbauen
Table Definitions basierend auf erkannten Datentabellen vorschlagen

Wichtige Vorteile

Vorteil	Beschreibung
Wartbarkeit	Selektoren und Pages werden zentral gepflegt
Wiederverwendbarkeit	Felder und Tabellen über Workflows und Projekte hinweg wiederverwendet
Geschäftsabstraktion	Workflow-Benutzer interagieren mit Geschäftskonzepten, nicht mit rohen Selektoren
KI-unterstützt	Recorder und KI generieren technische Assets automatisch
Skalierbarkeit	Tausende von Selektoren konsistent über grosse Projekte hinweg verwalten

Self-Healing

Self-Healing & LLM

Das Self-Healing & LLM-Modul bietet zentralisiertes Management, Monitoring und Konfiguration der KI-gestützten Selector-Healing-Fähigkeiten der Plattform. Es ermöglicht automatische Selector-Wiederherstellung, intelligente Locator-Fallback-Strategien und KI-unterstützte Healing-Vorschläge.

Was das Modul bietet

Automatische Selector-Wiederherstellung bei UI-Änderungen
Intelligente Locator-Fallback-Strategien
KI-unterstützte Healing-Vorschläge mit Konfidenzwerten
Monitoring und Analyse der Selector-Zuverlässigkeit
Globale und projektspezifische Healing-Konfiguration
Verfolgung von Healing-Kosten und Transparenz der KI-Token-Nutzung

Modulstruktur

Abschnitt	Zweck
LLM Dashboard	Analyse und KI-Healing-Metriken
Self-Healing Monitor	Laufzeit-Healing-Gesundheit und Zuverlässigkeit
Healing Config	Globale und projektspezifische Konfiguration

Tiefe Integration

Self-Healing ist tief in Test Workflows, Test Runs, Laufzeitausführung und Reporting integriert. In früheren Modulen ist Healing während der Workflow-Ausführung und in Berichten sichtbar — dieses Modul konzentriert sich auf das operative Management und die Konfiguration des Healing-Systems selbst.

LLM Dashboard

Self-Healing

Das LLM Dashboard bietet Transparenz über KI-gestützte Healing-Aktivitäten, Vorschlagsgenerierung, Laufzeitkosten und Akzeptanzmetriken. Es ermöglicht Teams zu verstehen, wie oft Healing stattfindet, wie erfolgreich es ist und welche operativen KI-Kosten entstehen.

LLM Dashboard — KI-Healing-Analyse, Vorschlags-Tracking, Token-Nutzung und Kostenübersicht.

Dashboard-Metriken

Metrik	Beschreibung
Success Rate	Gesamte Healing-Erfolgsrate über alle Ausführungen
Proposals	Gesamtanzahl der KI-generierten Healing-Vorschläge
Accepted	Akzeptierte und erfolgreich angewendete Vorschläge
LLM Costs	Geschätzte KI-Betriebskosten einschliesslich Verarbeitung von Eingabe- und Ausgabe-Tokens

Token-Nutzung

Metrik	Beschreibung
Input Tokens	An das LLM gesendete Tokens
Output Tokens	Vom LLM zurückgegebene Tokens
Total Tokens	Kombinierte Token-Nutzung

Kostenübersicht

Typ	Beschreibung
Input Cost	Kosten der Prompt-Verarbeitung
Output Cost	Kosten der generierten Antworten
Total Cost	Kombinierte LLM-Betriebskosten

Das Cost-Trend-Diagramm zeigt die historische Entwicklung der KI-Kosten über die Zeit an und hilft Organisationen, Skalierungseffekte, ungewöhnliche Nutzungsspitzen und das KI-Betriebsbudget zu überwachen. Die Feedback-Distribution-Visualisierung zeigt die Gesamtverhältnisse von akzeptierten und abgelehnten Vorschlägen zur Bewertung der KI-Vorschlagsqualität.

Recent Proposals

LLM Dashboard

Die Recent Proposals-Tabelle zeigt kürzlich generierte Healing-Vorschläge mit ihrem aktuellen Status, Konfidenzwerten und verfügbaren Aktionen an.

Vorschlagsinformationen

Spalte	Beschreibung
Date	Zeitstempel der Vorschlags-Erstellung
Page	Zugeordnetes PageObject
Element	Betroffener Selector
Confidence	KI-Konfidenzwert für den Vorschlag
Status	Aktueller Vorschlags-Status
Actions	Vorschlagsdetails anzeigen

Vorschlags-Status

Status	Beschreibung
Pending	Wartet auf Überprüfung oder automatische Annahme
Accepted	Erfolgreich angewendet — Selector ist jetzt geheilt
Rejected	Vom Benutzer oder System abgelehnt

Self-Healing Monitor

Monitoring

Der Self-Healing-Bereich konzentriert sich auf die Laufzeit-Healing-Gesundheit und Selector-Zuverlässigkeit. Er bietet operative Transparenz über Healing-Versuche, Wiederherstellungserfolg, Selector-Stabilität und Laufzeitzuverlässigkeit.

Self-Healing Monitor — Laufzeit-Healing-Gesundheit, Strategie-Rotationen und Selector-Zuverlässigkeitsmetriken.

Laufzeit-Metriken

Metrik	Beschreibung
Healing Events	Gesamtanzahl aufgezeichneter Healing-Events über alle Ausführungen
Success Rate	Prozentsatz erfolgreicher Healing-Operationen
Failed Heals	Fehlgeschlagene Healing-Versuche — kann auf instabile Anwendungen oder grössere UI-Änderungen hinweisen
Strategy Rotations	Wie oft Fallback-Strategien während Healing-Versuchen rotiert wurden
Heals per Minute	Häufigkeit der Healing-Aktivität während der Laufzeitausführung
Avg Heal Time	Durchschnittliche Dauer für Healing-Versuche
LLM Calls	Anzahl der KI-Anfragen während Healing-Operationen

Circuit Breaker

Monitoring

Die Healing-Engine umfasst einen Schutzmechanismus namens Circuit Breaker. Er verhindert übermässige wiederholte Healing-Versuche während instabiler Ausführungen und schützt so die Systemstabilität und Ausführungsqualität.

Circuit Breaker-Zustände

Zustand	Beschreibung
Closed (OK)	Healing-System arbeitet normal
Open	Healing nach wiederholten Fehlern vorübergehend deaktiviert

Proaktive Gesundheitsprüfung

Die Plattform kann die Selector-Zuverlässigkeit proaktiv analysieren, bevor die Testausführung beginnt, sodass Teams instabile Selektoren frühzeitig erkennen können.

Gesundheitszustand	Beschreibung
Healthy	Stabile Selektoren ohne Healing-Historie
Degraded	Potenziell instabile Selektoren mit gelegentlichem Healing
Critical	Hochriskante Selektoren mit häufiger Healing-Abhängigkeit

Field Reliability

Monitoring

Die Field Reliability-Tabelle bietet Gesundheitsanalysen pro Selector und ermöglicht Teams, instabile oder häufig geheilte Selektoren zu identifizieren und Wartungsarbeiten zu priorisieren.

Zuverlässigkeitsmetriken

Spalte	Beschreibung
Field	Selector-Name
Page Object	Zugeordnete Page
Reliability	Stabilitätsprozentsatz über jüngste Ausführungen
Usage	Gesamtausführungsanzahl
Heals	Anzahl ausgelöster Healing-Events
Heal Ratio	Healing-Häufigkeit als Prozentsatz der Nutzung

Zuverlässigkeits-Interpretation

Zuverlässigkeit	Bedeutung
100%	Vollständig stabiler Selector — kein Healing erforderlich
90–99%	Sehr stabil — seltene Healing-Events
70–89%	Mittelmässige Instabilität — Überprüfung empfohlen
Unter 70%	Hohe Healing-Abhängigkeit — manuelle Wartung erforderlich

Healing Configuration

Configuration

Der Healing Config-Bereich steuert das globale und projektspezifische Healing-Verhalten. Die Konfiguration kann zentral verwaltet oder projektweise überschrieben werden.

Healing-Konfiguration — globale Standardeinstellungen und projektspezifische Überschreibungseinstellungen.

Konfigurationsbereiche

Bereich	Beschreibung
Global	Standardeinstellungen, die plattformweit angewendet werden — alle Projekte erben diese, sofern sie nicht überschrieben werden
Project	Projektspezifische Überschreibungen — geerbte Werte werden in der Benutzeroberfläche visuell angezeigt

Self-Healing-Aktivierung

Der Hauptschalter steuert, ob Healing aktiv ist. Wenn deaktiviert, schlagen Selektoren sofort fehl und es werden keine Fallback-Strategien versucht.

Self-Healing Enabled — Hauptschalter für die Healing-Engine.

Healing Modes

Configuration

Healing Modes dropdown

Mode	Description
Automatic	System wendet erfolgreiche Healing-Ergebnisse automatisch zur Laufzeit an — minimiert Ausführungsunterbrechungen
Propose Only	System generiert Vorschläge, erfordert jedoch manuelle Überprüfung vor der Anwendung — empfohlen für regulierte oder produktionskritische Environments
Disabled	Healing-Funktionalität vollständig deaktiviert

💡 Verwenden Sie den Propose Only-Modus für kritische Produktions-Workflows, bei denen automatische Selector-Änderungen eine Governance-Prüfung erfordern, bevor sie angewendet werden.

Schwellenwerte & Limits

Configuration

Schwellenwerte definieren die Mindestkonfidenzwerte und Ausführungslimits, die steuern, wie aggressiv die Healing-Engine vorgeht.

Auto-Heal Threshold

Definiert den minimalen Konfidenzwert, der für automatisches Healing erforderlich ist. Bereich: 0.0–1.0. Höhere Werte sind sicherer und konservativer; niedrigere Werte ermöglichen aggressiveres automatisches Healing.

Auto-Heal Threshold — minimaler Konfidenzwert für automatische Selector-Reparatur.

Proposal Threshold

Definiert den minimalen Konfidenzwert für die Generierung von Healing-Vorschlägen. Dieser Schwellenwert ist typischerweise niedriger als der Auto-Heal-Threshold, damit auch Vorschläge mit niedrigerer Konfidenz für die manuelle Überprüfung angezeigt werden.

Proposal Threshold — minimale Konfidenz für die Generierung eines Healing-Vorschlags.

Max Auto-Heals Per Run

Begrenzt die maximale Anzahl von Healing-Operationen, die während einer einzelnen Ausführung erlaubt sind. Verhindert instabile endlose Healing-Schleifen und schützt die Gesamtausführungsqualität.

Max Auto-Heals Per Run — Obergrenze für Healing-Operationen pro Workflow-Ausführung.

Max Healing Attempts

Definiert, wie viele Retry-Versuche pro Selector erlaubt sind, bevor die Healing-Engine aufgibt.

Max Healing Attempts — Retry-Limit pro Selector bevor aufgegeben wird.

Heal Count for Blacklist

Definiert, wie viele wiederholte Fehler erlaubt sind, bevor eine Locator-Strategie vorübergehend auf die Blacklist gesetzt wird.

Heal Count for Blacklist — Fehlerschwelle, bevor eine Strategie vorübergehend ausgeschlossen wird.

Blacklist Window

Definiert das gleitende Zeitfenster für Blacklist-Berechnungen. Beispiel: 7 Tage — nur Fehler innerhalb der letzten 7 Tage zählen zum Blacklist-Schwellenwert.

Blacklist Window — gleitendes Zeitfenster für die Blacklist-Fehlerzählung.

Critical Fields

Critical Fields sind Selektoren, die niemals automatisch geheilt werden sollen. Diese Felder erfordern immer eine manuelle Überprüfung, bevor Änderungen angewendet werden. Typische Beispiele sind Login-Schaltflächen, Zahlungsaktionen, destruktive Operationen und produktionskritische Workflows.

Critical Fields — Selektoren vom automatischen Healing ausgeschlossen, immer manuelle Überprüfung erforderlich.

Locator Priority

Configuration

Die Healing-Engine kann Locator-Strategien bei Wiederherstellungsversuchen priorisieren. Locators mit höherer Priorität werden zuerst versucht, sodass Teams eine Präferenz für stabile semantische Selektoren gegenüber fragilen technischen Selektoren durchsetzen können.

Locator Priority — Drag-and-Drop-Reihenfolge der Fallback-Locator-Strategien.

Standard-Prioritätsreihenfolge

Priorität	Strategie	Begründung
#1	`data-testid`	Am stabilsten — speziell für Tests entwickelt
#2	`aria`	Semantisch und barrierefreiheitsbasiert
#3	`css`	Flexibel und weitverbreitet unterstützt
#4	`name`	Stabiler Bezeichner für Formularfelder
#5	`id`	Eindeutig, kann aber dynamisch sein
#6	`xpath`	Letzter Ausweg — anfällig für DOM-Änderungen

💡 Priorisieren Sie immer data-testid- und aria-Attribute. Dies sind stabile semantische Bezeichner, die UI-Refactoring überstehen, im Gegensatz zu XPath, das bei strukturellen DOM-Änderungen bricht.

Scheduler

Test Scheduler

Das Test Scheduler-Modul ermöglicht Teams die Automatisierung und Orchestrierung von Testausführungen über Projekte, Workflows und Environments hinweg. Es bietet zentralisierte Planungsfähigkeiten für wiederkehrende Regressions-Suiten, Smoke Tests, Monitoring-Prüfungen und verkettete Ausführungsflüsse.

Was das Modul bietet

Zeitbasierte Ausführung mit Cron-Intervallen
Ereignisbasierte Ausführung auf Basis von Abhängigkeiten zwischen Schedules
Bevorstehende Ausführungen überwachen und historische Läufe prüfen
Ausführungseinstellungen und Environments konfigurieren
Schedules bei Bedarf manuell auslösen
Externe CI/CD-Integration via API

Modulsektionen

Abschnitt	Zweck
Schedules	Alle geplanten Ausführungen verwalten und konfigurieren
Upcoming Runs	Zukünftige geplante Ausführungen vorschauen
History	Zentralisierte Ausführungshistorie über alle Schedules

Schedules

Scheduler

Der Schedules-Tab bietet eine zentralisierte Übersicht aller konfigurierten Schedules im Projekt. Jede Schedule-Karte zeigt Name, Beschreibung, Ausführungsfrequenz, Zeitzone, verknüpfte Workflows, aktuellen Status und schnelle Aktionssteuerungen an.

Schedules — zentralisierte Übersicht aller konfigurierten Schedules mit Status und schnellen Aktionen.

Verfügbare Aktionen

Aktion	Beschreibung
Run Now	Führt den Schedule sofort aus
Enable / Disable	Aktiviert oder pausiert den Schedule
Edit	Ändert die Schedule-Konfiguration
Delete	Entfernt den Schedule dauerhaft
Open Details	Öffnet das detaillierte Schedule-Management

Schedule-Status

Status	Beschreibung
Active	Schedule wird automatisch gemäss seinem Intervall ausgeführt
Inactive	Schedule ist pausiert — keine Ausführungen werden ausgelöst
Scheduled	Ausführung ist für zukünftige Ausführung in der Warteschlange
Running	Schedule wird gerade ausgeführt
Failed	Letzte Ausführung fehlgeschlagen
Passed	Letzte Ausführung erfolgreich abgeschlossen

Create Schedule

Schedules

Benutzer können neue Schedules über die Schaltfläche New Schedule erstellen. Der Erstellungsdialog unterstützt mehrere Konfigurationsbereiche einschliesslich Name, Trigger-Typ, Frequenz, Zeitzone, Runner und verknüpfte Tests.

Grundkonfiguration

Feld	Beschreibung
Schedule Name	Sichtbarer Name des Schedules (z. B. Nightly Regression Suite)
Description	Optionale Metadaten zur Beschreibung des Zwecks
Timezone	Ausführungs-Zeitzone (z. B. Europe/Zurich)

Ausführungseinstellungen

Einstellung	Beschreibung
Runner Type	Selenium Grid, Cloud Runner, Local Agent
Parallelism	Anzahl gleichzeitiger Testausführungen
Max Retries	Retry-Anzahl für fehlgeschlagene Ausführungen
Retry Delay	Verzögerung zwischen Retry-Versuchen

Create Schedule-Dialog

Trigger Types

Schedules

Der Scheduler unterstützt mehrere Trigger-Strategien, um verschiedenen operativen Anforderungen gerecht zu werden.

Zeitbasiert (Cron)

Schedules werden auf Basis wiederkehrender Zeitintervalle ausgeführt.

Frequenz	Beschreibung
Every 5 min	Kontinuierliches Monitoring
Every 15 min	Hochfrequente Ausführung
Every 30 min	Standard-Monitoring
Hourly	Periodische Ausführung
Daily	Tägliche Regressions-Läufe
Weekly	Wöchentliche Validierungszyklen
Custom	Benutzerdefinierte Cron-Ausdrücke für präzise Planung

Ereignisbasiert

Schedules können ausgelöst werden, nachdem ein anderer Schedule erfolgreich abgeschlossen wurde. Dies ermöglicht verkettete Ausführungsflüsse, Abhängigkeits-Orchestrierung und mehrstufige Validierungs-Pipelines.

Headless-Ausführung

Modus	Beschreibung
Headed	Browser-UI während der Ausführung sichtbar
Headless	Browser läuft unsichtbar — schnellere Ausführung, geringerer Infrastrukturaufwand

Upcoming Runs

Monitoring

Der Upcoming Runs-Tab bietet Transparenz über zukünftige geplante Ausführungen über alle konfigurierten Schedules hinweg. Benutzer können Läufe für die nächsten 24 Stunden, 48 Stunden oder 7 Tage vorschauen.

Upcoming Runs — Vorschau aller zukünftigen geplanten Ausführungen mit Zeit- und Workflow-Details.

Angezeigte Informationen

Spalte	Beschreibung
Scheduled Time	Genauer zukünftiger Ausführungszeitstempel
Schedule	Zugeordneter Schedule-Name
Test / Workflow	Auszuführende Workflow- oder Testnamen
Status	Status der in der Warteschlange befindlichen Ausführung

Execution History

Monitoring

Der History-Tab bietet eine zentralisierte Übersicht aller historischen Schedule-Ausführungen über das gesamte Projekt. Im Gegensatz zur schedule-spezifischen Laufhistorie aggregiert diese Ansicht Ausführungen aller konfigurierten Schedules in einem einzigen operativen Dashboard.

Ausführungshistorie — zentralisierte Ansicht aller geplanten Laufergebnisse im Projekt.

Historie-Tabelle

Spalte	Beschreibung
Timestamp	Datum und Uhrzeit der Ausführung
Schedule	Name des ursprünglichen Schedules
Test Name	Ausgeführter Workflow oder Test
Status	Endgültiges Ausführungsergebnis
Duration	Gesamtausführungszeit
Actions	Detaillierte Ausführungsinformationen aufrufen

Filterung & Suche

Der History-Tab enthält Status-Filter (All, Passed, Failed) und Zeitraum-Filter (Last 24h, Last 7d, Last 30d) für schnellere Untersuchung und Analyse. Die Tabelle unterstützt Paginierung für grosse Ausführungsvolumen.

Anwendungsfälle

Fehleruntersuchung — wiederkehrende Fehler über Schedules und Workflows hinweg identifizieren
Leistungsmonitoring — Trends der Ausführungsdauer über die Zeit verfolgen
Regressionsstabilität — langfristige Automationszuverlässigkeit analysieren
Operative Auditierung — vollständigen Audit-Trail der automatisierten Ausführungen pflegen

Schedule Details

Schedule Management

Das Öffnen eines Schedules bietet detaillierte Verwaltungsfunktionen. Die Detailansicht ist in drei Tabs unterteilt: Tests, Upcoming Runs und Run History.

Tests

Der Tests-Tab zeigt alle dem Schedule zugewiesenen Workflows an und ermöglicht vollständiges Test-Management innerhalb des Schedules.

Tests-Tab — alle dem Schedule zugewiesenen Workflows mit Abhängigkeiten und Ausführungseinstellungen verwalten.

Test zu Schedule hinzufügen

Tests können dynamisch zu bestehenden Schedules mit vollständigen Konfigurationsoptionen hinzugefügt werden.

Option	Beschreibung
Workflow	Den auszuführenden Workflow auswählen
Dependency	Definieren, welcher Test vor diesem abgeschlossen sein muss
Retry Behavior	Retry-Anzahl und Verzögerung für diesen spezifischen Test überschreiben
Headless Mode	Browser ohne sichtbare UI ausführen
Variables	Workflow-Eingabe-/Ausgabe-Variablen zur Parametrisierung synchronisieren

Add Test to Schedule-Dialog

💡 Verwenden Sie Test Dependencies, um Ausführungsflüsse zu verketten — beispielsweise: Checkout Flow hängt von Login Flow ab. Dies stellt sicher, dass Authentifizierung und Environment-Vorbereitung vor geschäftskritischen Tests erfolgen.

Upcoming Runs

Der Upcoming Runs-Bereich auf Schedule-Ebene zeigt zukünftige Ausführungen nur für den ausgewählten Schedule an und hilft Teams, das Planungsverhalten vor der Ausführung zu validieren.

Upcoming Runs (Schedule-Detail) — nächste geplante Ausführungen mit genauen Zeitstempeln und Laufreihenfolge.

Angezeigte Informationen

Genauer Ausführungszeitstempel
Relative Ausführungszeit (z. B. "in 2 Stunden")
Laufreihenfolge im Schedule
Nächster Ausführungsindikator

Run History

Der Run History-Bereich bietet historische Transparenz über alle Ausführungen des ausgewählten Schedules.

Run History — Ausführungs-Timeline für den ausgewählten Schedule mit Status, Dauer und Trigger-Details.

Historie-Informationen

Feld	Beschreibung
Date	Ausführungszeitstempel
Trigger	Ausführungsquelle (geplant, manuell, ereignisbasiert)
Status	Endgültiger Ausführungszustand
Tests	Anzahl ausgeführter Tests
Duration	Gesamtausführungsdauer

Historie-Filter

Ausführungshistorie nach Status und Zeitraum (Last 24h, Last 7d, Last 30d) filtern, um Vorfälle schnell zu isolieren oder langfristige Trends zu analysieren.

External Integration

Integration

Zusätzlich zur integrierten Planung unterstützt Autemos die Integration mit externen Orchestrierungs- und CI/CD-Plattformen. Dies ermöglicht Organisationen, automatisierte Tests direkt aus bestehenden Delivery-Pipelines auszulösen.

Unterstützte Plattformen

GitLab CI/CD
Jenkins
Azure DevOps
GitHub Actions
Benutzerdefinierte Pipeline-Systeme via API

API-basierte Ausführung

Autemos stellt APIs bereit, die es externen Systemen ermöglichen, einzelne Tests, vollständige Workflows, Regressions-Suiten und geplante Ausführungsketten auszulösen. Externe Systeme verwalten die Orchestrierung, während Autemos Testausführung, Browser-Automation, Reporting, Self-Healing und Analyse übernimmt.

Häufige Integrationsszenarien

Szenario	Ablauf
CI/CD-Validierung	GitLab Pipeline → Deployment → Autemos Tests auslösen → Validieren
Enterprise-Planung	Enterprise Scheduler → Autemos API → Automatisierte Ausführung
Release Gate	Build → Deployment auf Staging → Workflow auslösen → Auswerten → Fortfahren oder Stoppen

Interne vs. externe Planung

Typ	Beschreibung
Intern	Direkt im Test Scheduler-Modul verwaltet
Extern	Via API aus CI/CD- oder Enterprise-Systemen ausgelöst

💡 Viele Organisationen verwenden einen hybriden Ansatz — interne Schedules für wiederkehrendes Monitoring und Regressionstests, externe Trigger für CI/CD und Deployment-Validierung. Beides kann kombiniert werden, während die zentralisierte Berichterstattung in Autemos erhalten bleibt.

Erste Schritte

Code Generation

Der Code Generation Hub ermöglicht Teams die automatische Generierung wiederverwendbaren Automation-Codes aus Autemos-Workflows und PageObjects. Er überbrückt die Lücke zwischen visuellem Low-Code-Testdesign und entwicklerbasiertem Quellcode-Management — und erzeugt produktionsreife Automation-Frameworks, die auf Ihren bestehenden Technologie-Stack abgestimmt sind.

Code Generation Hub — Dashboard mit Übersicht über Framework, Project Structure und Sync Profiles auf einen Blick.

Kernfähigkeiten

Automatische Code-Generierung

Wiederverwendbaren Automation-Code direkt aus Test-Workflows, PageObjects, Field Definitions und Actions generieren.

Framework-konformer Output

Generierter Code folgt Framework-Konventionen, Projektstrukturregeln, Benennungsstandards und Template-Definitionen.

Git Synchronization

Generierten Code direkt in GitHub-, GitLab- oder Bitbucket-Repositories pushen — mit Branch-Management und History-Tracking.

Sync Profiles

Wiederverwendbare Synchronisierungs-Konfigurationen für automatisierte, ereignisbasierte oder geplante Code-Auslieferung erstellen.

Unterstützte Frameworks & Sprachen

Sprachen	Frameworks	Test Runners	Git Providers
Java, TypeScript, Python, C#	Selenium, Playwright, Appium	TestNG, JUnit, Vitest, Jest	GitHub, GitLab, Bitbucket

Code-Generierungs-Workflow

Framework & Projekt konfigurieren

Setup-Wizard ausführen, um Sprache, Framework, Package-Namespace und Git-Verbindung auszuwählen.

Projektstruktur definieren

Output-Pfade für Test-Dateien, PageObjects und Konfiguration mithilfe dynamischer Platzhalter festlegen.

Templates konfigurieren

Klassenstrukturen, Methoden-Implementierungen und Framework-Syntax über den Template Manager definieren.

Workflows & PageObjects auswählen

Auswählen, welche Test-Workflows und PageObjects einbezogen werden sollen. Referenzierte PageObjects werden automatisch erkannt.

Generieren & Ausliefern

Als ZIP-Paket herunterladen oder direkt in das Git-Repository pushen. Mit Sync Profiles automatisieren.

Erste Schritte

Dashboard

Das Dashboard bietet eine zentralisierte Übersicht der aktuellen Code-Generierungs-Konfiguration. Es zeigt den Status aller drei Kern-Konfigurationsbereiche auf einen Blick und ermöglicht direkten Zugriff zum Bearbeiten jedes Bereichs.

Framework-Übersicht

Zeigt die gewählte Sprache, Framework-Konfiguration und den Package-Namespace an. Zeigt Konfiguriert, wenn das Setup abgeschlossen ist.

Projektstruktur-Übersicht

Zeigt die konfigurierten Output-Pfade für Tests, PageObjects und Konfigurationsdateien mit einer Live-Anzahl der zugeordneten Dateien an.

Sync Profiles-Übersicht

Zeigt bestehende Synchronisierungs-Profile, deren Status und eine Verknüpfung zum Erstellen neuer Profile an.

Konfiguration

Setup

Der Setup-Bereich konfiguriert die technische Grundlage des generierten Automation-Projekts. Er enthält Framework-Einstellungen und die Git-Verbindung nebeneinander, sowie eine Danger Zone zum Zurücksetzen der Konfiguration.

Setup-Tab — Framework-Einstellungen (links) und Git-Verbindung (rechts) nebeneinander konfiguriert.

Framework-Einstellungen

Einstellung	Beschreibung
Language	Programmiersprache (Java, TypeScript, Python, C#)
Framework	Automation-Framework (Selenium, Playwright, Appium)
Package Name	Root-Package-Namespace (z. B. `ch.eribank.test`)
Base URL	Standard-Anwendungs-URL für das generierte Projekt
Test Runner	Test-Ausführungs-Engine (TestNG, JUnit, Vitest, Jest)

Git-Verbindung

Feld	Beschreibung
Provider	Git-Provider — GitHub, GitLab oder Bitbucket
Repository URL	Ziel-Repository für die Code-Synchronisierung
Access Token	Persönlicher Zugriffstoken zur Authentifizierung
Default Branch	Branch für die Synchronisierung (z. B. `main`)

Verwenden Sie Test Connection, um Repository-Zugriff, Authentifizierung, Branch-Verfügbarkeit und Schreibberechtigungen vor der Aktivierung der Synchronisierung zu validieren.

💡Die Danger Zone am Ende des Setups ermöglicht das Zurücksetzen der Projektkonfiguration. Dabei werden Framework-Einstellungen entfernt und der Wizard neu gestartet — Templates und Projektstruktur bleiben jedoch erhalten.

Setup Wizard

Neue Projekte verwenden einen geführten 4-Schritte-Wizard zur Konfiguration der Code-Generierungs-Grundlage.

Schritt 1 — Plattform wählen: Web, Mobile oder Web + Mobile.

Schritt 2 — Automation-Framework-Kombination auswählen.

Schritt 3 — Package-Name und Base URL für das Projekt eingeben.

Schritt 4 — Vollständige Konfiguration vor Abschluss des Setups überprüfen.

Konfiguration

Project Structure

Der Bereich Project Structure definiert, wie generierte Dateien im Ziel-Repository organisiert werden. Output-Pfade verwenden dynamische Platzhalter, die zur Generierungszeit aufgelöst werden.

Project Structure — Output-Pfade konfigurieren und den generierten Ordnerbaum vor der Generierung vorab ansehen.

Konfigurierbare Output-Pfade

Pfad	Beispiel	Zweck
Test Output Path	`src/test/java/{packagePath}/`	Wo Test-Klassendateien generiert werden
PageObject Output Path	`src/main/java/{packagePath}/pages/`	Wo PageObject-Klassendateien generiert werden
Config Output Path	optional	Wo unterstützende Konfigurationsdateien abgelegt werden

Dynamische Platzhalter

Platzhalter	Aufgelöster Wert
`{packagePath}`	Package-Name als Verzeichnispfad (z. B. `ch/eribank/test`)
`{TestName}`	Name der generierten Test-Klasse
`{PageName}`	Name der generierten PageObject-Klasse

Eine Live-Ordnerbaum-Vorschau visualisiert die vollständige generierte Projektstruktur basierend auf der aktuellen Pfad-Konfiguration — noch bevor Code generiert wird.

Konfiguration

Templates

Templates definieren die genaue Code-Struktur, die Autemos für jedes Framework und jeden Feldtyp generiert. Sie steuern Klassenstrukturen, Methoden-Implementierungen, Imports, Framework-Syntax und Feld-Interaktionsmethoden.

Templates — Method Templates geordnet nach Field Type (LINK, TEXT, BUTTON, etc.) mit den verfügbaren Methoden.

Haupt-Templates

Haupt-Templates definieren die übergeordnete Klassenstruktur für jeden generierten Dateityp:

Test-Klassenstruktur
PageObject-Klassen
Konfigurationsdateien
Utility-Klassen

Method Templates nach Field Type

Jeder von PageObjects bereitgestellte Feldtyp besitzt eigene Interaktionsmethoden. Diese werden basierend auf dem Feldtyp und dem gewählten Framework generiert:

Methode	Zweck	Beispiel-Feldtypen
`click()`	Klick-Interaktion auslösen	Link, Button
`getText()`	Textinhalt lesen	Link, Text
`getHref()`	Hyperlink-URL lesen	Link
`type()`	Text in ein Feld eingeben	Input
`select()`	Dropdown-Wert auswählen	Dropdown

Code Template Management

Der Code Template Manager ist eine separate globale Funktion, die als zentrale Engine hinter der Code-Generierung fungiert. Er ermöglicht Teams:

Templates für beliebige Sprach- und Framework-Kombinationen anpassen
Organisatorische Coding-Standards definieren
Wiederverwendbare Generierungs-Logik erstellen
Feldspezifische Interaktionsmethoden verwalten

Zugriff über die Schaltfläche Edit in Template Manager im Templates-Tab oder über die globale Sidebar-Navigation.

Code Template Management — template editor

Code Template Management — Templates, Node-Templates, Methoden & Feldtypen bearbeiten.

Automation

Sync Profiles

Sync Profiles ermöglichen Teams die Automatisierung wiederkehrender Synchronisierungs-Workflows. Ein Profil definiert, welche Workflows und PageObjects synchronisiert werden, den Ziel-Git-Branch, Trigger-Bedingungen und das Planungsverhalten — alles als wiederverwendbare Konfiguration gespeichert.

Auswählen, welche Workflows und PageObjects synchronisiert werden
Einen dedizierten Git-Ziel-Branch pro Profil definieren
Geplante oder ereignisbasierte Sync-Trigger konfigurieren
Optional einen Pull Request nach jedem Sync automatisch erstellen
Profile unabhängig voneinander aktivieren oder deaktivieren

Neues Sync Profile — Workflows und PageObjects zur Einbeziehung auswählen.

Profil-Konfiguration

Einstellung	Beschreibung
Tests (Workflows)	Auswählen, welche Workflows einbezogen werden. Referenzierte PageObjects werden automatisch erkannt.
Page Objects	Automatisch anhand von Workflow-Referenzen ausgewählt oder manuell hinzugefügt.
Git Target Branch	Dedizierter Branch für dieses Profil (z. B. `codegen/profile-name-sync`)
Schedule	Periodische Synchronisierung aktivieren (nächtlich, täglich, etc.)
Event Triggers	Automatisch synchronisieren, wenn bestimmte Ereignisse eintreten
Auto-create PR	Nach jedem Sync automatisch einen Pull Request zur Überprüfung öffnen
Active	Profil unabhängig aktivieren oder deaktivieren

Ereignisbasierte Trigger

Trigger	Beschreibung
Run on Workflow Save	Automatisch synchronisieren, wenn ein Workflow geändert und gespeichert wird
Run on Successful Test Run	Nach einer erfolgreichen Ausführung synchronisieren — hält das Repository stets aktuell

💡Aktivieren Sie Auto-create PR zusammen mit Event-Triggern, um für jede automatisch generierte Änderung eine Code-Review zu erzwingen — ideal für CI/CD-Pipelines, die kontrollierte Merges erfordern.

Automation

Generate

Der Generate-Tab ermöglicht manuelle, bedarfsgesteuerte Code-Generierung. Workflows und PageObjects zur Einbeziehung auswählen, das Output-Format wählen und sofort generieren.

Generate-Tab — Tests und PageObjects auswählen, dann Vorschau anzeigen, als ZIP herunterladen oder zu Git pushen.

Auswahl

Einzelne Workflows im Tests-Panel auswählen — oder Select All verwenden
Referenzierte PageObjects werden automatisch erkannt, wenn ein Workflow ausgewählt wird
Zusätzliche PageObjects können manuell aus dem Page Objects-Panel hinzugefügt werden

Generierungsoptionen

Option	Beschreibung
Include Test Files	Ausführbare Test-Klassendateien für die gewählten Workflows generieren
Include Config Files	Framework-Konfiguration und unterstützende Assets generieren

Output-Optionen

Vorschau

Den generierten Code vor dem Herunterladen oder Pushen prüfen — Dateinamen, Struktur und Inhalt überprüfen.

Generate & Download ZIP

Das vollständige generierte Projekt als ZIP-Archiv für lokale Nutzung oder manuelle Integration herunterladen.

Push to Git

Den generierten Code direkt in das konfigurierte Git-Repository und den Branch pushen.

Automation

Git Sync

Der Git Sync-Tab bietet direktes Repository-Management — Git-Verbindung konfigurieren, Code manuell pushen und die vollständige Synchronisierungshistorie einsehen.

Git Sync — Provider, Repository-URL, Zugriffstoken und Branch konfigurieren. Sync History verfolgt alle früheren Pushes.

Git-Verbindung

Unterstützte Provider: GitHub, GitLab, Bitbucket. Repository-URL, persönlichen Zugriffstoken und Standard-Branch konfigurieren. Test Connection verwenden, um vor dem Speichern zu validieren.

Sync History

Die Sync History bietet vollständige Transparenz über jeden vorherigen Synchronisierungs-Lauf:

Zeitstempel jeder Synchronisierung
Push-Ergebnis (Erfolg oder Fehler)
Verwendeter Branch
Fehlerdetails für Debugging

Externe Integration & CI/CD

Code-Generierung und Synchronisierung können auch extern via API ausgelöst werden. Dies unterstützt die Integration mit:

GitLab CI Pipelines
Jenkins Jobs
GitHub Actions Workflows
Benutzerdefinierten Deployment-Pipelines

💡Kombinieren Sie externe API-Trigger mit Sync Profiles für eine vollautomatische Code-Generierungs-Pipeline — generieren, pushen und einen PR automatisch als Teil jedes Deployment-Zyklus öffnen.

Erste Schritte

Recorder

Der Recorder ist der schnellste Weg, automatisierte Tests in Autemos zu erstellen. Statt Workflows manuell Schritt für Schritt aufzubauen, können Benutzer einfach mit der Anwendung interagieren, während Autemos sämtliche Aktionen automatisch aufzeichnet und in wiederverwendbare Test Workflows umwandelt.

Der Recorder unterstützt zwei Recording-Modi:

Manual Recording — klassischer Click-Recorder
AI Recording — KI-gestützte Testerstellung über natürliche Sprache

Während der Aufnahme erstellt Autemos automatisch Pages und Fields, Workflow Nodes, Assertions, Reusable Selectors, Page Objects sowie Tabellen- und UI-Strukturen. Der erzeugte Workflow kann anschliessend gespeichert und im Test Workflow Editor weiterbearbeitet werden.

Hauptfunktionen

Dual Recording Modes

Wählen zwischen klassischer Interaktionsaufzeichnung (Manual) und KI-gesteuerter Testerstellung über natürliche Sprache (AI).

Web & Mobile Support

Unterstützung für Browser-basierte Anwendungen sowie Mobile Automation auf Android, iOS, physischen Geräten und Device Farms.

Automatische Page Object Erkennung

Pages, Fields und Selectors werden während der Aufzeichnung automatisch erkannt und als wiederverwendbare Komponenten erstellt.

Workflow Ready

Der generierte Workflow steht sofort im Test Workflow Editor zur Weiterbearbeitung und Ausführung bereit.

Erste Schritte

Recorder Workspace

Der Recorder bietet eine zentrale Oberfläche zum Aufzeichnen, Analysieren und Speichern von Testabläufen. Der Workspace ist in klar getrennte Bereiche unterteilt, die während einer Session zusammenarbeiten.

Hauptbereiche

Session Area — Anzeige der aktiven Browser- oder Mobile-Session
AI Chat Panel — Interaktion mit der KI über natürliche Sprache (AI-Modus)
Events Panel — zeigt alle aufgezeichneten technischen Events in Echtzeit
Workflow View — Visualisierung des generierten Test Workflows
Pages View — Anzeige der automatisch erkannten Pages und Fields

Recorder dashboard — Manual mode with no active session

Recorder Workspace — Manual- und AI-Modus, Events / Workflow / Pages Tabs.

Session Management

Session starten

Benutzer können direkt aus dem Recorder neue Sessions starten. Unterstützte Session-Typen: Web Browser und Mobile Device.

Web Browser Session

Konfigurieren Sie die Browser-Session über eine vordefinierte Anwendung und Umgebung oder geben Sie eine URL direkt ein.

Feld	Beschreibung
Application	Auswahl einer definierten Anwendung
Environment	Auswahl der Zielumgebung (DEV, QA, UAT, PROD)
Browser	Auswahl des Zielbrowsers
Certificate	Einbindung von persönlichen oder projektweiten Zertifikaten
Resolved URL	Anzeige der final geöffneten URL

Web Browser Session — Application, Environment, Browser und Certificate auswählen.

Direkte URL-Aufzeichnung

Alternativ kann direkt eine URL eingegeben werden, ohne Application oder Environment auszuwählen. Ideal für Ad-hoc-Tests, externe Webseiten, temporäre Umgebungen und Schnelltests.

💡Verwenden Sie Enter URL manually, wenn das Ziel nicht als Autemos-Anwendung registriert ist — die Session wird nicht an eine Projektumgebung gebunden.

Direkte URL-Eingabe — ohne Application oder Environment starten.

Mobile Device Session

Feld	Beschreibung
Platform	Auswahl: Android oder iOS
Device	Auswahl eines verbundenen Geräts oder manuelle UDID-Eingabe
Application	Auswahl der installierten Mobile App

Mobile Device Session — Platform, Device und Application auswählen.

Session Management

Manual Recording

Der Manual Recorder eignet sich für Benutzer, die direkt mit der Anwendung arbeiten möchten, während Autemos sämtliche Aktionen automatisch aufzeichnet.

Funktionsweise

Starten Sie eine Session, interagieren Sie mit der Anwendung und beenden Sie den Ablauf. Autemos zeichnet automatisch auf:

Clicks und Inputs
Navigation und Page Transitions
Assertions und Element-Interaktionen

Automatisch erzeugte Artefakte

Workflow Nodes

Jede aufgezeichnete Aktion wird zu einem Node im visuellen Workflow.

Page Objects

Pages und Fields werden automatisch erkannt und als wiederverwendbare Komponenten erstellt.

Assertions

Validierungsschritte werden automatisch zusammen mit den Interaktions-Events erfasst.

Reusable Selectors

Pro Element werden mehrere Selektorstrategien generiert für langfristige Stabilität.

Session Management

AI Recording

Mit dem AI Recorder können Benutzer Tests vollständig über natürliche Sprache erstellen. Wechseln Sie in den AI-Modus und beschreiben Sie das gewünschte Szenario im AI Chat Panel.

💡Beispiel: „Öffne eBanking, navigiere zu Budget, öffne Hilfe und Kontakt und prüfe die Telefonnummer."

Die KI interpretiert die Eingabe, führt die Aktionen aus, navigiert durch die Anwendung und erstellt automatisch den vollständigen Workflow.

AI-Modus — AI Chat Panel und Modell-Selektor (z. B. GPT-4o).

Transparente KI-Ausführung

Während der AI-Ausführung zeigt Autemos live an:

Ausgeführte Commands und Browser-Aktionen
Generierte Workflow Nodes und Page Objects
Durchgeführte Assertions
Zusammenfassung der Ausführung

KI-Ausführungsübersicht — Schritte und Ergebnisse werden im Chat angezeigt.

Unterstützte AI Models

Der Recorder unterstützt konfigurierbare AI Models (z. B. GPT-4o), die je nach Projektanforderung ausgewählt werden können.

Aufgezeichnete Daten

Events Recording

Der Events-Tab zeigt sämtliche aufgezeichneten technischen Aktionen mit vollständigen Details.

Typische Events

open_browser()
click_element()
assert_element()
close_session()

Event-Details

Jedes Event enthält: Event Type, Selector, Page Object Referenzen, Parameter, Assertion Values sowie Browser- oder Device-Kontext. Events können nach Web, Mobile und Event Type gefiltert werden.

Events-Tab — alle aufgezeichneten Aktionen mit Typ, Selector und Page Object Referenzen.

Aufgezeichnete Daten

Workflow-Generierung

Autemos wandelt die aufgezeichneten Events automatisch in einen visuellen Workflow um. Der Workflow-Tab zeigt den generierten Graphen in Echtzeit.

Inhalt des Workflows

Navigation Nodes (Open Browser, Close)
Action Nodes (Click, Type, Swipe)
Assertions und Session Handling
Ablaufreihenfolge und bedingte Logik

Wiederverwendbarkeit

Die erzeugten Workflows können bearbeitet, kombiniert, geplant, ausgeführt und für Code Generation verwendet werden.

Workflow-Tab — der generierte Workflow-Graph aktualisiert sich in Echtzeit.

Aufgezeichnete Daten

Automatische Page Object Erkennung

Eine der wichtigsten Funktionen des Recorders ist die automatische Erstellung von Page Objects. Autemos erkennt während der Aufnahme kontinuierlich UI-Strukturen und erstellt daraus wiederverwendbare Komponenten.

Automatisch erkannte Elemente

Pages, Fields, Buttons, Inputs, Links
Tabellen und UI-Strukturen
Assertions und Selectors

Reuse Detection

Autemos erkennt automatisch bereits existierende Elemente und markiert sie als Reused oder New — Duplikate werden vermieden, die Wartbarkeit verbessert.

Pages-Tab — erkannte Page Objects und Fields, markiert als Reused oder New.

Ausgabe & Integration

Recorder Output

Nach dem Speichern erstellt der Recorder automatisch einen vollständigen Satz wiederverwendbarer Assets:

Test Workflow

Wiederverwendbarer Workflow zur Ausführung und Bearbeitung im Test Workflow Editor.

Page Objects

Strukturierte Seitenmodelle mit Fields und Selectors.

Assertions

Automatisch erfasste Validierungslogik, direkt im Workflow eingebettet.

Event Metadata

Technische Informationen zur Ausführung für Debugging und Audit.

Integration mit dem Test Workflow Editor

Nach dem Speichern kann der erzeugte Workflow im Test Workflow Editor erweitert werden: Bedingungen, Schleifen, Variablen, Retry-Logik, Integrationen und erweiterte Assertions. Der Recorder dient als Grundlage für komplexe Enterprise-Testautomatisierung.

Integration mit Code Generation

Die erzeugten Workflows können direkt im Code Generation Hub verwendet werden, um automatisierten Testcode für Selenium, Playwright oder Appium zu generieren.

Typische Use Cases

Schnelle Test-Erstellung

Automatisierte Tests innerhalb weniger Minuten erstellen.

Citizen Automation

Auch Fachanwender ohne Programmierkenntnisse können Tests erstellen.

Page Object Discovery

Wiederverwendbare Seitenstrukturen automatisch generieren.

Regression Testing

Benutzerabläufe schnell in Regressionstests umwandeln.

Erste Schritte

Test Data Management

Das Test Data Management Modul ermöglicht die zentrale Verwaltung, Bereitstellung und Wiederverwendung von Testdaten innerhalb der Plattform. Es stellt sicher, dass Test Workflows jederzeit auf konsistente, dynamische und reproduzierbare Testdaten zugreifen können — unabhängig davon, ob die Daten aus APIs, Datenbanken, Dateien oder internen Datensätzen stammen.

Test Data Management — zentrale Verwaltung aller Testdaten-Quellen, Bindings und Datensätze.

Das Modul unterstützt

Zentrale Datenquellen
Wiederverwendbare Datensätze
Runtime-Bindings
Asynchrone Datenpersistierung
Scope-basierte Datenhaltung
Dynamische Testdatenbereitstellung

💡Testdaten sind ein zentraler Bestandteil stabiler und skalierbarer Testautomatisierung.

Ziele des Moduls

Testdaten zentral verwalten
Redundante Datendefinitionen vermeiden
Daten zwischen Workflows wiederverwenden
Dynamische Datenquellen anbinden
Asynchrone Testausführungen unterstützen
Reproduzierbare Tests sicherstellen
Komplexe Enterprise-Testdatenflüsse abbilden

Hauptbereiche

Bereich	Beschreibung
Overview	Status und Runtime-Übersicht
Data Sources	Verwaltung externer Datenquellen
Variables	Testdaten-Bindings und Variablen
Settings	Adapter- und Datenbank-Konfiguration

Status

Overview Dashboard

Das Overview Dashboard zeigt den aktuellen Zustand der Testdaten-Infrastruktur — Adapter-Status, aktive Datenquellen, Cache und Runtime-Zustände auf einen Blick.

Overview Dashboard — Live-Status aller Testdaten-Komponenten und Verbindungen.

Enthaltene Informationen

Adapter-Status

Verfügbarkeit aller Datenadapter.

Aktive Datenquellen

Welche Quellen aktuell verbunden sind.

Cache-Informationen

Nutzung und Auslastung des Caches.

Scope-Verwendung

Aktive Scopes pro Run / Project / Tenant.

Auto-Refresh Status

Konfiguration automatischer Aktualisierungen.

Runtime-Zustände

Aktive Bindings und Runtime-Variablen.

Hilft dabei

Verbindungsprobleme schnell zu erkennen
Aktive Datenbindungen zu überwachen
Cache-Nutzung zu analysieren
Runtime-Datenzustände zu prüfen

Datenquellen

Data Sources

Im Bereich Data Sources werden externe und interne Datenquellen verwaltet. Jede Datenquelle kann mehrfach innerhalb verschiedener Test Workflows verwendet werden.

Data Sources — Verwaltung aller konfigurierten Datenquellen und Adapter.

Unterstützte Source Types

REST API

HTTP-basierte Datenabfragen.

JSON File

Strukturierte JSON-Datenquellen.

Excel

XLSX-basierte Datensätze.

Database

JDBC / PostgREST Anbindungen.

iSynth

iSynth-Datenquellen für synthetische Testdaten.

Named Data Sources

Named Data Sources definieren wiederverwendbare Datenquellen-Konfigurationen — z. B. testdata_users, api_orders, customer_data, product_catalog.

Named Data Sources — wiederverwendbare Datenquellen.

Eine Datenquelle enthält:

Source Type
Verbindungsinformationen
Authentifizierung
Retry-Konfiguration
Timeout-Konfiguration
Path Templates

💡Named Data Sources ermöglichen zentrale Wiederverwendung und vereinfachte Wartung.

REST API Datenquellen

REST APIs können direkt als Testdatenquelle verwendet werden — z. B. für Kundendaten, Produktdaten oder Session-Tokens.

REST API Datenquellen — direkter Zugriff auf APIs für dynamische Testdaten.

Parameter	Beschreibung
Base URL	API-Endpoint
Authentication	Token, Basic Auth, OAuth
Timeout	Maximale Wartezeit
Retry Handling	Wiederholungslogik bei Fehlern
Health Path	Health-Check Endpoint
Path Templates	Dynamische URL-Pfade

iSynth Integration

Das Modul unterstützt iSynth-basierte Testdatenquellen für synthetische Testdaten-Generierung.

iSynth Integration — synthetische Testdaten und dynamische Datenbereitstellung.

Unterstützte Funktionen

Synthetische Testdaten-Generierung
Dynamische Runtime-Datenbereitstellung
Temporäre Datensatz-Erstellung
Tenant-bewusste Datenisolierung

Konfigurierbare Parameter

Base URL
Authentication
API Keys
Timeout
Retry-Konfiguration
Path Templates
TTL (Time-to-Live)

Damit lassen sich direkt in die Plattform integrieren:

Synthetische Kundengenerierung
Skalierbare Enterprise-Testdaten
Privacy-sichere Testautomatisierung
Dynamische CI/CD-Testdatenbereitstellung
Parallele Ausführung mit isolierten Datensätzen

Datenbank-Anbindungen

Das Modul unterstützt Datenbank-basierte Testdatenquellen über JDBC oder PostgREST. Damit können bestehende Testdatenbanken, Data Pools und zentrale Testdaten-Repositories direkt verwendet werden.

Datenbank-Anbindungen — JDBC / PostgREST Konfiguration.

Datenbank-Details — Tabellen-Mapping und Datenabruf.

Konfigurierbare Parameter

Tabellenname
Schema
Data Type Column
API Keys
Maximale Datensätze

Bindings

Test Data Bindings

Bindings verbinden Workflows mit Datenquellen. Ein Binding definiert, welche Daten geladen werden, aus welcher Quelle, unter welchem Namen und für welche Umgebung.

Test Data Bindings — Verknüpfung von Workflows mit Datenquellen.

Beispiel-Binding

Parameter	Wert
Binding Name	`premiumCustomer`
Source	`customer_api`
Data Type	`CUSTOMER`

Verwendung im Workflow

${premiumCustomer.email}
${premiumCustomer.id}

Environment-spezifische Bindings

Bindings können pro Environment definiert werden — dadurch können dieselben Workflows unterschiedliche Datenquellen je Umgebung verwenden.

DEV

Entwicklungs-Daten.

TEST

Test-Daten.

STAGING

Staging-Daten.

PROD

Produktions-Daten.

Environment-spezifische Bindings — pro DEV / TEST / STAGING / PROD.

Datensätze

Test Data Easy

Test Data Easy ermöglicht die einfache Verwaltung statischer oder halb-dynamischer Datensätze direkt innerhalb der Plattform. Datensätze können erstellt, bearbeitet, importiert und wiederverwendet werden.

Test Data Easy — direkte Verwaltung von Datensätzen innerhalb der Plattform.

Datensätze hinzufügen und bearbeiten

Test Data Easy Datensätze können entweder direkt in einem Test Workflow oder zentral im Test Data Modul verwaltet werden. Dadurch können Teams schnell wiederverwendbare Datensätze für Workflows, Bindings, Loops und Data-driven Testing-Szenarien erstellen.

New Test Data Easy Dataset — Dialog zum Erstellen und Bearbeiten von Datensätzen mit allen Optionen (Linked Workflow, One-Time Use, Add Column/Row, Import).

Funktionen

Unterstützte Möglichkeiten:

Wiederverwendbare Datensätze erstellen
Bestehende Datensätze bearbeiten
Zeilen hinzufügen und entfernen
Spalten hinzufügen und entfernen
CSV / XLSX / JSON Dateien importieren
Tabellendaten direkt einfügen
Datensätze mit Workflows verknüpfen
One-Time-Use Datensätze konfigurieren

Unterstützte Importformate

CSV

Komma-getrennte Werte.

XLSX

Excel-Tabellen.

JSON

Strukturierte JSON-Daten.

Manuelle Eingabe

Tabellendaten direkt im Grid einfügen.

Damit lassen sich bestehende Testdaten-Repositories schnell in die Plattform integrieren.

Datensatz-Struktur

Ein Datensatz besteht aus Spalten, Zeilen und optionalen Workflow-Verknüpfungen. Typische Beispiele:

Login-User
Produktlisten
Testbestellungen
Referenzdaten

Verknüpfte Workflows

Datensätze können optional mit einem bestimmten Test Workflow verknüpft werden. Das verbessert:

Nachverfolgbarkeit
Wartbarkeit
Workflow-spezifisches Testdaten-Management

💡Wenn kein Workflow verknüpft ist, kann der Datensatz projektweit wiederverwendet werden.

Typischer Ablauf

In den meisten Fällen:

Test Data Easy Datensätze werden direkt während der Workflow-Erstellung angelegt
Der Datensatz wird automatisch mit dem Workflow verknüpft
Variablen können sofort in Workflow-Nodes verwendet werden

Alternativ können Datensätze auch zentral im Test Data Modul erstellt und gepflegt werden. Das ist nützlich für:

Gemeinsam genutzte Datensätze
Wiederverwendbare Regression-Daten
Zentral verwaltete Test-Pools
Teamweite, wiederverwendbare Testassets

One-Time Use — Markierung bereits konsumierter Datensätze.

One-Time Use

Der One-Time Use Modus verhindert die Wiederverwendung bereits konsumierter Datensätze.

Verhalten

Verwendete Zeilen werden markiert
Bereits verwendete Daten werden nicht erneut geliefert
Ideal für eindeutige Testdaten

Beispiele: Gutscheincodes · Einmal-User · eindeutige Registrierungen

💡Verhindert Datenkonflikte in parallelen Tests.

Tools

Playground & Acquire

Der Playground dient zum manuellen Testen und Validieren von Datenquellen.

Playground — Datenquellen manuell abfragen und validieren.

Funktionen

Testdaten abrufen
Filter testen
TTL prüfen
Cache-Verhalten validieren
Async Store prüfen

Acquire Test Data

Mit Acquire Test Data können Daten manuell geladen werden.

Parameter	Beschreibung
Source Type	Quelle der Daten
Data Type	z. B. CUSTOMER, ORDERS, USERS
Quantity	Anzahl der abzurufenden Datensätze
Scope	RUN / PROJECT / TENANT
TTL Override	Eigene Cache-Lebenszeit
JSON Filter	Filter-Logik
Cache Bypass	Cache umgehen

Async Store

Der Async Store ermöglicht persistente Datenhaltung über asynchrone Workflow-Ausführungen hinweg.

Besonders wichtig für

Time Gap Nodes
Mehrteilige Workflows
Langlaufende Prozesse

Persistierte Daten überleben

JVM Restarts
Workflow-Unterbrechungen
Asynchrone Fortsetzungen

Architektur

Scope-Konzept & Cache-System

Scope-Konzept

Das Modul unterstützt unterschiedliche Daten-Lebenszyklen, um Daten gezielt zu isolieren oder zu teilen.

Scope	Beschreibung
RUN	Nur für eine Testausführung
PROJECT	Für ein Projekt verfügbar
TENANT	Global tenantweit verfügbar

Cache-System

Das integrierte Cache-System reduziert unnötige Datenabrufe.

Funktionen

Token-Caching
API-Response-Caching
Scope-basierte Cache-Verwaltung
TTL-Steuerung

Vorteile

Schnellere Ausführung
Geringere API-Last
Stabilere Testläufe

Runtime

Runtime-Verhalten & Fehlerbehandlung

Das Test Data Management läuft tief integriert in die Workflow-Ausführung und stellt sicher, dass Daten zur richtigen Zeit verfügbar sind.

Runtime-Verhalten

Vor Start eines Workflows

Bindings werden aufgelöst
Datenquellen werden abgefragt
Daten werden validiert
Runtime-Variablen erzeugt

Während der Ausführung

Daten bleiben verfügbar
Runtime-State kann persistiert werden
Async Workflows können Daten wieder aufnehmen

Fehlerbehandlung

Das Modul unterstützt robuste Fehlerbehandlung:

Retry-Mechanismen

Automatische Wiederholungen bei Fehlern.

Timeout-Konfiguration

Maximale Wartezeit pro Quelle.

Adapter-Health-Checks

Verfügbarkeitsprüfung der Adapter.

Cache-Fallbacks

Fallback auf gecachte Daten.

Persistente Wiederaufnahme

Async-Workflows können fortgesetzt werden.

Typische Fehler

Nicht erreichbare APIs
Ungültige Datenstrukturen
Leere Datensätze
Abgelaufene Tokens

Konfiguration

Einstellungen

Der Bereich Einstellungen definiert das Standardverhalten für Laufzeit, Caching, Persistenz und Infrastruktur innerhalb des Test Data Managements. Hier können Administratoren und Test Architekten zentral steuern, wie Testdaten geladen, zwischengespeichert, gespeichert und geschützt werden.

Projekt-Standardeinstellungen

Die Projekt-Standardeinstellungen definieren das Laufzeitverhalten für alle Testdatenoperationen innerhalb eines Projekts.

Projekt-Standardeinstellungen — Standardquelle, TTL, Persistenzbereich und Retry-Verhalten.

Konfigurierbare Parameter

Standardquelle
Standard-TTL
Standard-Persistenzbereich
Retry-Verhalten
Maximale Anzahl an Retries

Unterstützte Scopes

RUN

Nur für eine Testausführung.

PROJECT

Für ein Projekt verfügbar.

TENANT

Global tenantweit verfügbar.

Vorteile

Zentrale Laufzeitkonfiguration
Konsistentes Testdatenhandling
Projektspezifische Overrides
Stabiles Retry- und Recovery-Verhalten

Projekt Cache Policy

Die Cache Policy steuert, wie lange geladene oder generierte Datensätze innerhalb der Plattform verfügbar bleiben.

Projekt Cache Policy — TTL, Persistenz-Scope und Per-Type Overrides.

Konfigurierbare Parameter

Standard-TTL
Persistenz-Scope
TTL-Overrides pro Datentyp

Vorteile

Temporäre Runtime-Datensätze
Wiederverwendbare Projekt-Caches
Optimierte Performance
Reduzierte externe API-Aufrufe
Konfigurierbare Datenlebenszeiten

Globale Infrastruktur & Sensitive Felder

Das Modul unterstützt zentrale Infrastruktur-Einstellungen für asynchrone Persistenz und den sicheren Umgang mit sensitiven Daten.

Global Infrastructure and Sensitive Fields

Globale Infrastruktur & Sensitive Felder — Async Store Backend und Maskierung.

Infrastrukturkonfiguration

Async Store Backend
Effective Source
Effective Scope
Retry-Konfiguration

Maskierung sensitiver Felder

Passwörter

Vollständige Maskierung in Logs.

Tokens

API- und Session-Tokens.

IBANs

Bankverbindungen.

Kreditkartennummern

Zahlungsdaten.

Vorteile

Sicheres Runtime-Logging
Schutz sensitiver Informationen
Zentrale Infrastrukturverwaltung
Compliance-konforme Testausführung

Globale Cache Infrastruktur

Die Plattform beinhaltet eine zentrale Cache-Infrastruktur für Runtime-Datensätze und temporäre Persistenz.

Globale Cache Infrastruktur — Maximale Cache-Grösse, Eviction und Persistenz-Scope.

Konfigurierbare Parameter

Maximale Cache-Grösse
Eager Eviction
Eviction-Intervall
Effektiver Persistenz-Scope

Vorteile

Skalierbares Runtime-Caching
Automatische Bereinigung
Optimierte Speichernutzung
Stabile Ausführung langlaufender Workflows

💡Projekteinstellungen können Werte aus der globalen Konfiguration übernehmen oder individuell überschreiben.

Anwendung

Best Practices, Häufige Fehler & Vorteile

Best Practices

Datenquellen zentral verwalten
Bindings konsistent benennen
Environment-spezifische Bindings verwenden
One-Time Use für eindeutige Daten aktivieren
Datenquellen im Playground testen
Runtime-Daten sauber persistieren
TTLs bewusst konfigurieren

⚠️Häufige Fehler — Hardcoded Testdaten verwenden · Testdaten zwischen parallelen Runs teilen · keine Scope-Trennung verwenden · One-Time Use vergessen · zu grosse Datensätze laden · Environment-Mapping ignorieren.

Vorteile

Vorteil	Beschreibung
Zentrale Testdatenverwaltung	Alle Datenquellen an einem Ort.
Skalierbare Datenbereitstellung	Geeignet für Enterprise-Mengen.
Dynamische Datenquellen	APIs, DBs, Files, Synthetic.
Asynchrone Datenpersistierung	Über Time Gap Nodes hinweg.
Wiederverwendbare Datensätze	Einmal definieren, mehrfach nutzen.
Bessere Wartbarkeit	Zentrale Änderungen.
Stabilere Automatisierung	Cache + Retry + Health-Checks.
Höhere Wiederverwendbarkeit	Bindings über Workflows hinweg.

Das Test Data Management bildet die Grundlage für professionelle Enterprise-Testautomatisierung mit konsistenten und reproduzierbaren Testdaten.

Erste Schritte

Grid Dashboard

Das Grid Dashboard bietet eine zentrale Echtzeit-Übersicht über alle konfigurierten Browser- und Mobile-Ausführungsumgebungen innerhalb von Autemos. Es unterstützt Teams dabei, ihre Automatisierungsinfrastruktur effizient zu überwachen und zu verwalten.

Grid Dashboard — zentrale Übersicht aller verbundenen Browser, Mobile Devices, Cloud Provider und aktiven Sessions.

Was das Dashboard visualisiert

Verfügbare Browser
Verbundene Mobile Devices
Cloud Provider
Aktive Sessions
Kapazitätsauslastung
Geräte-Status

Zweck

Das Grid Dashboard wurde entwickelt, um:

Die Gesundheit der Ausführungsinfrastruktur zu überwachen
Verfügbare Ausführungskapazitäten sichtbar zu machen
Verbundene Browser und Devices darzustellen
Aktive und verfügbare Sessions anzuzeigen
Transparenz über die Test-Infrastruktur bereitzustellen

Erste Schritte

Unterstützte Ausführungsumgebungen

Das Grid Dashboard unterstützt verschiedene Browser- und Mobile-Umgebungen sowie Cloud-Provider-Integrationen.

Desktop Browser

Chrome, Edge, Firefox, Safari und Remote Selenium Nodes.

Mobile Devices

Android, iOS, Smartphones, Tablets, lokale Geräte und Cloud Devices.

Cloud Provider

Experitest, BrowserStack, Sauce Labs, LambdaTest sowie individuelle Provider.

Desktop Browser

Browser	Beschreibung
Chrome	Standard-Browser für die meisten Web-Automatisierungen
Edge	Microsoft Edge auf Chromium-Basis
Firefox	Mozilla Firefox
Safari	Apple Safari (macOS / iOS)
Remote Selenium Nodes	Selbst gehostete Selenium-Grid-Nodes

Mobile Devices

Android & iOS
Smartphones und Tablets
Lokale Geräte
Cloud Devices

Dashboard

Dashboard Bereiche

Das Dashboard ist in mehrere logische Bereiche unterteilt, um schnellen Zugriff auf die wichtigsten Infrastruktur-Informationen zu ermöglichen.

Provider Übersicht

Der obere Bereich zeigt alle konfigurierten Provider sowie deren Verfügbarkeit. Beispiele:

Local
Experitest
Cloud Provider

Type Filter

Benutzer können Ausführungsumgebungen filtern nach:

Filter	Beschreibung
Desktop	Nur Desktop-Browser anzeigen
Mobile	Nur Mobile-Umgebungen anzeigen
Real Devices	Nur physische Geräte anzeigen
All	Alle Ausführungsumgebungen anzeigen

Dies vereinfacht die Navigation in grösseren Infrastrukturen.

Dashboard

Infrastruktur-Metriken

Vier zentrale Metriken liefern auf einen Blick einen Überblick über die Kapazität und Auslastung der gesamten Infrastruktur.

Total Devices

Gesamtanzahl konfigurierter Devices und Anzahl verfügbarer Devices. Beispiel: 12 Total Devices, 2 available.

Active Sessions

Aktuell laufende Sessions und maximale Session-Kapazität. Beispiel: 1 of 6 max.

Available Slots

Verbleibende Ausführungskapazität und freie Slots über alle Provider hinweg.

Cloud Providers

Anzahl konfigurierter Cloud Provider und aktive Provider-Verbindungen.

Dashboard

Browser Grid Monitoring

Im Bereich Local Grid Browsers visualisiert das Dashboard alle verbundenen Browser mit Detail-Informationen zu Version, Auslastung und freien Slots.

Visualisierte Informationen

Information	Beschreibung
Browser-Typ	Chrome, Edge, Firefox, Safari
Browser-Version	Installierte Version
Verfügbare Slots	Anzahl freier paralleler Slots
Genutzte Kapazität	Aktuell belegte Slots
Session-Auslastung	Auslastung in Prozent

💡Beispiel: Chrome v131.0 · 1 / 6 slots · 17 % Auslastung.

Dashboard

Device Visualization

Jedes verbundene Mobile Device wird als eigene Card dargestellt — mit allen relevanten Informationen auf einen Blick.

Device Cards

Feld	Beschreibung
Device Name	Eindeutiger Geräte-Name
OS-Version	Betriebssystem-Version (Android / iOS)
Plattform	Android oder iOS
Provider	Lokal, BrowserStack, Sauce Labs etc.
Verfügbarkeitsstatus	Aktueller Status (Online / Busy / Offline)
Device-Modell	Spezifisches Modell (z. B. iPhone 15 Pro)

Device Status

Online

Gerät ist verbunden und verfügbar.

Offline

Gerät ist aktuell nicht erreichbar.

Busy

Gerät ist mit einer Session beschäftigt.

In Use

Gerät wird gerade aktiv verwendet.

Available

Gerät ist frei und bereit für eine neue Session.

Echtzeit-Monitoring

Das Dashboard aktualisiert sich dynamisch und zeigt Session-Auslastung, Device-Konnektivität, Infrastruktur-Verfügbarkeit und Provider-Status in Echtzeit.

Integration

Provider Integration

Das Grid Dashboard unterstützt sowohl lokale Infrastrukturen als auch externe Cloud-Provider — alles in einer einheitlichen Ansicht.

Lokale Infrastruktur

Unterstützt intern gehostete:

Selenium Grid
Appium Grid
Browser Nodes
Lokale Mobile Devices

Cloud Device Farms

Unterstützt externe Cloud Provider für:

Mobile Testing
Cross-Browser Testing
Parallel Execution

Integration

Kapazitätsmanagement

Mit den Kapazitäts-Informationen können Teams ihre Ausführungsstrategie optimieren und Engpässe frühzeitig erkennen.

Session Availability

Teams können schnell erkennen:

Verfügbare Ausführungskapazität
Grid-Engpässe
Überlastete Nodes
Freie Execution Slots

Parallel Execution Visibility

Das Dashboard unterstützt bei der Optimierung von:

Paralleler Testausführung
Ressourcen-Allokation
Infrastruktur-Skalierung

Integration

Health Monitoring

Das Dashboard zeigt den allgemeinen Gesundheitsstatus der gesamten Infrastruktur.

Infrastruktur-Gesundheit

Healthy

Alle Provider und Devices funktionieren einwandfrei.

Warning

Einzelne Komponenten zeigen Probleme an.

Offline

Provider oder Devices sind nicht erreichbar.

Partial Availability

Nur ein Teil der Infrastruktur ist verfügbar.

Real Device Management

Das Grid Dashboard bietet Sichtbarkeit über verbundene Smartphones, Tablets, OS-Versionen, Provider-Zuordnung und die Verfügbarkeit von Real Devices.

Skalierbarkeit

Enterprise-Infrastrukturen
Hybrid-Umgebungen
Multi-Provider-Setups
Verteilte Execution Nodes

Anwendung

Use Cases & Vorteile

Typische Anwendungsfälle

Infrastruktur-Monitoring

Zentrale Überwachung aller Ausführungsumgebungen.

Planung von Testausführungen

Verfügbare Devices und Browser-Slots vor grossen Regression Runs identifizieren.

Kapazitätsoptimierung

Auslastung überwachen und Infrastruktur effizient skalieren.

Real Device Operations

Verwaltung und Überwachung von Mobile Device Farms.

Vorteile

Vorteil	Beschreibung
Zentrale Übersicht	Ein zentrales Dashboard für die gesamte Ausführungsinfrastruktur.
Echtzeit-Überwachung	Live-Sichtbarkeit über Sessions und Device-Auslastung.
Bessere Ressourcennutzung	Freie Kapazitäten und Engpässe schnell identifizieren.
Verbesserte Stabilität	Früherkennung von Offline-Devices oder Provider-Problemen.
Enterprise-Skalierung	Unterstützt grosse verteilte Automatisierungsinfrastrukturen.

Erste Schritte

Project Settings

Das Modul Project Settings zentralisiert die administrative Konfiguration eines Projekts. Es ermöglicht Projekt-Ownern und Administratoren die Verwaltung von Projekt-Metadaten, Umgebungen, Mitgliedern, API Keys sowie Authentifizierungs-Konfigurationen und Secrets.

Project Settings — zentrale Verwaltung aller projektbezogenen Konfigurationen.

Verwaltete Bereiche

Projekt-Metadaten

Name, Beschreibung und Grundkonfiguration des Projekts.

Projekt-Umgebungen

Applikationen und Environments (TEST / QA / PROD).

Mitglieder & Berechtigungen

Zugriffe und Rollen pro Projekt.

API Keys

Programmatischer Zugriff für externe Integrationen.

Auth & Secrets

Wiederverwendbare Auth-Konfigurationen und verschlüsselte Secrets.

Das Modul bildet die Grundlage für sichere Zusammenarbeit, Umgebungsmanagement und API-Integrationen innerhalb der Plattform.

Konfiguration

General Settings

Die Sektion General enthält die zentrale Projektkonfiguration inklusive Projektname, Beschreibung, Umgebungsverwaltung und Applikations-Katalog.

General Settings — Projektname, Beschreibung und Applikations-/Environment-Katalog.

Jedes Projekt definiert

Mehrere Anwendungen und Umgebungen, die verwendet werden für:

Test Workflows
Recorder Sessions
Test Data Bindings
API-Ausführungen

Wann verwenden

Beim Anlegen einer neuen Projektstruktur
Konfiguration von Testumgebungen
Verwaltung mehrerer Applikations-URLs
Trennung von TEST / QA / PROD Umgebungen
Aktualisierung der Projekt-Metadaten

Project Details

Parameter	Beschreibung
Project Name	Name des Projekts
Description	Optionale Projektbeschreibung

Project Environments

Jede Applikation kann mehrere Umgebungen enthalten. Beispiel:

Application	Environment	URL
Migros	TEST	`https://www.migros.ch/de`

Unterstützte Aktionen

Applikation hinzufügen
Applikation entfernen
Environments hinzufügen
Environment-URLs definieren
Default-Environments konfigurieren

Verhalten

Environment-Konfigurationen werden zentral verwaltet
Workflows können dynamisch auf Environments referenzieren
Recorder- und API-Nodes verwenden die konfigurierten Environment-URLs
Änderungen wirken projektweit

Best Practices

Klare Naming-Konventionen für Environments verwenden
TEST, QA und PROD strikt trennen
Keine Produktions-Credentials in Test-Environments nutzen
Environment-URLs zentral pflegen

Konfiguration

Members

Die Sektion Members verwaltet den Projektzugriff und die Benutzerrechte.

Members — Übersicht aller Projektmitglieder mit ihren Rollen.

Benutzer können

Projekten zugewiesen werden
Aus Projekten entfernt werden
Bestimmte Rollen erhalten

Unterstützte Rollen

Rollenzuweisung — OWNER, ADMIN oder MEMBER pro Benutzer.

Rolle	Berechtigungen
OWNER	Vollständige Projektadministration
ADMIN	Workflows, Settings und Benutzer verwalten
MEMBER	Erlaubte Ressourcen ausführen und bearbeiten

Wann verwenden

Projektzugriff gewähren
Team-Berechtigungen verwalten
Tester oder Entwickler onboarden
Administrative Zugriffe beschränken

Verhalten

Nur zugewiesene Benutzer können auf das Projekt zugreifen
Rollen bestimmen die verfügbaren Berechtigungen
Owners haben volle administrative Kontrolle
Members erhalten begrenzten operativen Zugriff

Best Practices

OWNER-Berechtigungen auf wenige Benutzer beschränken
MEMBER für Standard-Tester verwenden
Projektzugriffe regelmässig prüfen
Inaktive Benutzer entfernen

Integration & Security

API Keys

Die Sektion API Keys ermöglicht den sicheren programmatischen Zugriff auf die Plattform. API Keys können für externe Integrationen, CI/CD-Pipelines, Service Accounts und automatisierte Ausführungen verwendet werden.

API Keys — sicherer programmatischer Zugriff für externe Integrationen.

Wann verwenden

Integration externer Systeme
Automatisierte Ausführungen
Anbindung an CI/CD-Pipelines
Machine-to-Machine-Kommunikation

Configuration

API Key Konfiguration — Name, Beschreibung und Ablaufdatum.

Parameter	Beschreibung
Key Name	Name des API Keys
Description	Optionale Beschreibung zur Verwendung
Expires In	Ablaufdauer in Tagen

Verhalten

API Keys werden sicher generiert
Der vollständige Key wird nur einmalig nach der Erstellung angezeigt
Abgelaufene Keys werden automatisch ungültig
Keys können jederzeit widerrufen werden

⚠️Sicherheitshinweis — Der vollständige API Key wird nur einmalig nach der Erstellung angezeigt. Speichere API Keys immer sicher ab.

Best Practices

Wo möglich Ablaufdaten verwenden
Keys regelmässig rotieren
Separate Keys pro Integration
API Keys niemals öffentlich exponieren

Integration & Security

Auth & Secrets

Die Sektion Auth & Secrets verwaltet wiederverwendbare Authentifizierungs-Konfigurationen und verschlüsselte Secrets.

Auth & Secrets — wiederverwendbare Auth-Konfigurationen und verschlüsselte Secrets.

Unterstützte Komponenten

Environment Secrets

Verschlüsselte sensitive Werte pro Umgebung.

Shared Auth Configurations

Wiederverwendbare Authentifizierungs-Setups.

OAuth2 Credentials

OAuth2-Client-Konfigurationen.

Bearer Tokens

Token-basierte Authentifizierung.

API Keys

API-Key-Authentifizierung.

Basic Authentication

Benutzername / Passwort.

Environment Secrets

Environment Secrets — verschlüsselte sensitive Daten zentral verwaltet.

Environment Secrets speichern verschlüsselte sensitive Werte wie Tokens, Passwörter, Client Secrets und API Credentials. Secrets sind at rest verschlüsselt und werden nach der Erstellung nie wieder vollständig angezeigt.

Configuration

Parameter	Beschreibung
Key	Secret-Identifier
Value	Verschlüsselter Secret-Wert
Description	Optionale Beschreibung

Verhalten

Secrets sind sicher verschlüsselt
Werte bleiben nach Erstellung verborgen
Secrets können über mehrere Auth-Konfigurationen wiederverwendet werden
Werden von API Request Nodes und Integrationen verwendet

Auth Configurations

Auth Configurations — wiederverwendbare Auth-Setups für API Request Nodes.

Auth Configurations bieten wiederverwendbare Authentifizierungs-Setups für API Request Nodes. Unterstützte Authentifizierungs-Typen:

Bearer Token
Basic Auth
API Key
OAuth2 Client Credentials

Configuration

Parameter	Beschreibung
Name	Name der Auth-Konfiguration
Description	Optionale Beschreibung
Auth Type	Authentifizierungs-Methode
Secret Reference	Verknüpftes verschlüsseltes Secret

Verhalten

Auth-Konfigurationen verwenden zentralisierte Secrets
Mehrere Workflows können dieselbe Auth-Config teilen
Änderungen wirken automatisch auf alle abhängigen Requests
Credentials werden niemals in Workflows offengelegt

Anwendung

Best Practices

Wichtigste Empfehlungen für die Verwendung des Project Settings Moduls:

Sensitive Daten immer als Secrets speichern
Shared Auth Configurations wiederverwenden
Keine Zugangsdaten direkt im Workflow speichern
Credentials pro Umgebung trennen
Secrets regelmässig rotieren
Klare Naming-Konventionen für Environments verwenden
OWNER-Berechtigungen auf wenige Benutzer beschränken
Projektzugriffe regelmässig prüfen und bereinigen
API Keys mit Ablaufdaten versehen
Separate API Keys pro Integration verwenden

Erste Schritte

Persönliche Einstellungen

Das Modul Persönliche Einstellungen ermöglicht Benutzern die Verwaltung ihrer eigenen Kontoinformationen und persönlichen Zertifikatskonfigurationen. Es ist über den Benutzer-Avatar oben rechts in der Plattform erreichbar.

Persönliche Einstellungen — erreichbar über den Benutzer-Avatar oben rechts.

Funktionen

Persönliche Profilinformationen

Übersicht der eigenen Kontodetails.

Persönliche Runtime-Zertifikate

Verwaltung individueller mTLS-Zertifikate.

Persönliche Zertifikatsquellen

Eigene File-System- oder Vault-Quellen.

mTLS-Client-Zertifikate

Sichere Client-Authentifizierung gegenüber geschützten Anwendungen.

Verfügbare Aktionen

Persönliche Einstellungen öffnen
Profilinformationen anzeigen
Persönliche Zertifikate verwalten
Persönliche Runtime-Quellen verwalten
Von der Plattform abmelden

Erste Schritte

Profil

Die Sektion Profil zeigt die Informationen des aktuell angemeldeten Benutzers an. Diese Informationen sind schreibgeschützt und repräsentieren das aktive Benutzerkonto innerhalb der Plattform.

Profil — schreibgeschützte Übersicht des aktiven Benutzerkontos.

Das Profil enthält

Feld	Beschreibung
Benutzername	Eindeutiger Login-Name
E-Mail-Adresse	Kontakt-E-Mail des Benutzers
Vorname	Vorname des Benutzers
Nachname	Nachname des Benutzers
Zugewiesene Rollen	Systemweite und projektbezogene Rollen
Interne Benutzer-ID	Eindeutige Plattform-ID

Wann verwenden

Überprüfung des aktiven Benutzerkontos
Kontrolle von Rollen und Berechtigungen
Einsicht in Kontoinformationen
Analyse von Berechtigungsproblemen

Zertifikate & Quellen

Zertifikate

Die Sektion Zertifikate verwaltet persönliche Runtime-Zertifikatskonfigurationen. Zertifikate werden getrennt von gemeinsam genutzten Projektkonfigurationen gespeichert.

Sie ermöglicht

Speicherung persönlicher mTLS-Zertifikate
Konfiguration persönlicher Runtime-Dateiquellen oder Vault-Quellen
Nutzung individueller Zertifikate für sichere API-Kommunikation
Tests von mTLS-geschützten Anwendungen mit persönlicher Identität

Add Certificate Source — Runtime-Quelle für persönliche Zertifikate hinzufügen.

Zertifikate & Quellen

Persönliche Quellen

Persönliche Quellen definieren benutzerspezifische Runtime-Speicherorte für Zertifikate und sichere Dateien.

Hilfreich wenn

Benutzer keine globalen/shared Zertifikatsquellen verwenden sollen
Persönliche Vault-Zugangsdaten benötigt werden
Teamunabhängige Zertifikatsverwaltung erforderlich ist

Add Personal Certificate — persönliches Zertifikat hinzufügen mit Source-Auswahl.

Unterstützte Quellentypen

File System Source

Lokales Verzeichnis als Quelle.

Gemeinsame Dateifreigaben

Network-Share oder gemounteter Pfad.

Vault-basierte Quellen

Sichere Vault-Anbindung für Credentials.

Konfigurationsparameter

Parameter	Beschreibung
Name	Name der Runtime-Quelle
Beschreibung	Optionale Beschreibung
Source Type	Typ der Runtime-Quelle
Share Root Path	Basisverzeichnis oder Runtime-Pfad

Beispiel — File-Share-Konfiguration

Parameter	Value
Source Type	`File System Source`
Share Root Path	`/certs`

Dadurch können Zertifikatsprofile relative Dateipfade innerhalb des definierten Root-Verzeichnisses verwenden.

Zertifikate & Quellen

Persönliche Zertifikate

Persönliche Zertifikate werden für die sichere Client-Authentifizierung gegenüber mTLS-geschützten Anwendungen verwendet. Zertifikate referenzieren eine Runtime-Quelle und können optional mit einem Passwort geschützt werden.

Unterstützte Zertifikatformate

PKCS#12 (.p12 / .pfx)

Zertifikatskonfiguration

Parameter	Beschreibung
Name	Name des Zertifikatsprofils
Beschreibung	Optionale Beschreibung
Certificate Source	Referenz auf die Runtime-Quelle
Certificate Type	Zertifikatsformat
Certificate File	Hochgeladene Zertifikatsdatei
Password	Optionales Zertifikatspasswort
Allowed Origins	Erlaubte Ziel-Domains

Allowed Origins

Allowed Origins beschränken die Verwendung eines Zertifikats auf definierte Zielsysteme. Beispiel: https://example.com. Dies erhöht die Sicherheit, indem Zertifikate nur für freigegebene Domains verwendet werden dürfen.

⚠️Sicherheitshinweis — Zertifikate und Secrets werden sicher zur Laufzeit verarbeitet.

Best Practices

Separate Zertifikate pro Umgebung verwenden
Allowed Origins möglichst einschränken
Persönliche Zertifikate nicht teilen
Zertifikate mit Passwort schützen
Zertifikate regelmässig rotieren

Account

Logout

Benutzer können sich direkt über das Avatar-Menü oben rechts von der Plattform abmelden.

Beim Logout

Wird die aktuelle Sitzung beendet
Wird der aktive Benutzerkontext gelöscht
Erfolgt die Rückkehr zum Login-Screen

Erste Schritte

Global Settings

⚠️Nur für Administratoren — Der Bereich Global Settings ist ausschliesslich für Systemadministratoren zugänglich. Änderungen wirken sich auf alle Projekte, Benutzer und das globale Systemverhalten aus. Falsche Konfigurationen können Stabilität, Sicherheit, Ausführungsumgebungen oder verbundene Dienste beeinträchtigen.

Das Modul Global Settings bietet eine zentrale Verwaltung aller systemweiten Konfigurationen innerhalb der gesamten Autemos-Plattform. Alle Einstellungen gelten global für sämtliche Projekte und Umgebungen.

Global Settings — zentrale Verwaltung aller plattformweiten Konfigurationen.

Konfigurierbare Bereiche

LLM Integration

Konfiguration von Large Language Models für AI-Funktionalitäten.

Security

Authentifizierung, Passwort-Richtlinien und Zugriffskontrolle.

Notifications

Email- und Slack-basierte Benachrichtigungen.

Storage

Datenrichtlinien, Aufbewahrung und Backups.

Selenium Grid

Verteilte Browser-Ausführungs-Infrastruktur.

Cloud Providers

Externe Testplattform-Integrationen.

Certificates

Sichere Runtime-Zertifikate für geschützte Anwendungen.

Zweck

Infrastruktur zentral verwalten
Enterprise-Administration vereinfachen
Plattformweite Integrationen steuern
Test-Infrastruktur konfigurieren
Sicherheits- und Compliance-Richtlinien umsetzen
Benachrichtigungen und Speicherstrategien verwalten
Skalierbare Testumgebungen bereitstellen

AI & Security

LLM Integration

Die LLM Integration Settings ermöglichen die Konfiguration von Large Language Models innerhalb der gesamten Plattform. Diese Einstellungen werden verwendet für KI-gestützte Feldgenerierung, AI-basierte Automatisierung, intelligente Workflow-Erstellung, automatische Testgenerierung und Auto-Healing.

LLM Integration — Konfiguration des LLM-Providers, API-Key, Modell-Auswahl und Rate Limits.

Konfigurationsmöglichkeiten

Einstellung	Beschreibung
Enable LLM	Aktiviert oder deaktiviert AI-Funktionalitäten global für die gesamte Plattform.
LLM Server URL	Endpoint des LLM-Providers (z. B. `https://api.openai.com/v1`).
API Key	Sichere API-Authentifizierung — verschlüsselt im Backend gespeichert, versteckte UI-Anzeige.
Model Selection	Auswahl des AI-Modells (GPT-4, GPT-4o, Claude, eigene Modelle).
Temperature	Steuert Kreativität und Determinismus — niedrige Werte = stabilere Ergebnisse, hohe Werte = kreativere Antworten.
Max Tokens	Maximale Anzahl an Tokens pro Anfrage.
Timeout	Maximale Ausführungszeit für AI-Anfragen.
Rate Limits	Maximale Requests pro Minute, API-Schutz und Kostenkontrolle.
Monthly Cost Threshold	Monatliches Kostenlimit für AI-Nutzung — Budgetkontrolle und Enterprise Governance.

Logging Optionen

Detailliertes AI-Logging
Fallback-Caching
Debugging und Monitoring

AI & Security

Security Settings

Der Bereich Security Settings verwaltet globale Authentifizierungs- und Sicherheitsrichtlinien der Plattform.

Security Settings — Session Management, Passwort-Richtlinien, Two-Factor Authentication und CORS-Konfiguration.

Session Management

Einstellung	Beschreibung
Session Timeout	Meldet Benutzer nach einer definierten Inaktivitätsdauer automatisch ab.
Max Login Attempts	Maximale Anzahl fehlgeschlagener Login-Versuche vor einer Kontosperrung.

Passwort-Richtlinien

Mindestpasswortlänge
Enterprise Passwort-Standards
Erweiterte Sicherheitsrichtlinien

Two-Factor Authentication

Verpflichtende 2FA
Globale MFA-Richtlinien
Erweiterte Kontosicherheit

Guest Access & CORS

Einstellung	Beschreibung
Guest Access	Steuert, ob Gastbenutzer auf öffentliche Projekte zugreifen dürfen.
CORS Configuration	Definiert erlaubte Origins für Frontend-/Backend-Kommunikation (z. B. `http://localhost:3000`). Unterstützt Enterprise Deployments, eigene Domains und Multi-Environment Setups.

Kommunikation

Notification Settings

Der Bereich Notifications verwaltet systemweite Kommunikationskanäle für Benachrichtigungen und Alerts.

Notifications — SMTP-Konfiguration und Slack-Integration für Email- und Webhook-basierte Benachrichtigungen.

Email Notifications — SMTP Configuration

Feld	Beschreibung
SMTP Server	Hostname des SMTP-Servers
SMTP Port	Port des SMTP-Servers (z. B. 587)
Authentication	Authentifizierungsdaten (verschlüsselt gespeichert)
Sender Address	Absenderadresse für ausgehende Emails
Admin Recipients	Admin-Benachrichtigungsadressen

Email Features

Systembenachrichtigungen
Execution Alerts
Fehlerberichte
Administrative Nachrichten

Slack Integration

Autemos unterstützt die Integration von Slack über Webhooks. Webhook-URLs werden verschlüsselt gespeichert.

Echtzeit-Benachrichtigungen
Execution Alerts
Fehlerberichte
Team-Kommunikation

🔒Sensible Daten wie Passwörter und Webhook-URLs werden grundsätzlich verschlüsselt im Backend gespeichert.

Infrastruktur

Storage Management

Der Bereich Storage Settings verwaltet systemweite Speicher- und Datenrichtlinien.

Storage Management — Upload-Limits, Data Retention, automatische Bereinigung und Backups.

File Upload Limits

Maximale Upload-Grösse
Speicherlimits
Ressourcenschutz

Data Retention

Steuert die Aufbewahrungsdauer von Systemdaten:

Screenshots
Logs
Execution-Artefakte
Reports

Automatic Cleanup & Compression

Funktion	Vorteil
Automatic Cleanup	Automatische Löschung veralteter Daten — reduzierter Speicherverbrauch und Compliance-Unterstützung
Data Compression	Speicheroptimierung durch Datenkomprimierung

Automatic Backups

Unterstützt geplante automatische Backups in folgenden Intervallen:

Täglich
Wöchentlich
Monatlich

Infrastruktur

Selenium Grid Configuration

Die Selenium Grid Settings verwalten die Infrastruktur für verteilte Browser-Ausführung — parallele Tests, Browser Nodes, Docker-basiertes Grid und skalierbare Execution-Infrastruktur.

Selenium Grid — Node-Konfiguration für Chrome, Firefox und Edge mit Session Limits und Recording-Optionen.

Grid Configuration

Einstellung	Beschreibung
Chrome Nodes	Anzahl der Chrome-Nodes im Grid
Firefox Nodes	Anzahl der Firefox-Nodes im Grid
Edge Nodes	Anzahl der Edge-Nodes im Grid
Session Limits	Maximale parallele Sessions
Connection Timeouts	Verbindungs-Timeouts für Grid-Nodes

Automatic Grid Management

Auto-start Grid
Auto-stop Grid
Dynamisches Node-Scaling

Recording Options

Videoaufzeichnung
Automatische Screenshots
Fehlerdiagnose

💡Das lokale Selenium Grid verbindet sich automatisch über das Docker-Netzwerk — keine manuelle URL-Konfiguration erforderlich.

Mobile Emulator Configuration

Mobile Emulator — Konfiguration von Android-Emulatoren (Samsung, Pixel, virtuelle Geräte-Skalierung).

Unterstützt die Konfiguration von Android-Emulatoren wie Samsung- und Pixel-Geräte sowie virtuelle Geräte-Skalierung.

Emulator Settings

Einstellung	Beschreibung
Number of Emulators	Anzahl der parallel laufenden Emulatoren
Memory Allocation	Speicherzuweisung pro Emulator
Screen Resolution	Bildschirmauflösung des virtuellen Geräts
Screen Dimensions	Bildschirm-Dimensionen
Session Timeouts	Timeouts für Emulator-Sessions

⚠️Plattformanforderungen: Android-Emulatoren benötigen Linux, KVM-Unterstützung und Hardware-Virtualisierung.

Infrastruktur

Cloud Providers

Der Bereich Cloud Providers verwaltet Integrationen externer Testplattformen wie Experitest, BrowserStack, Sauce Labs und LambdaTest.

Cloud Providers — Verwaltung externer Testplattform-Integrationen mit Routing und Status-Monitoring.

Unterstützte Provider

Experitest
BrowserStack
Sauce Labs
LambdaTest
Eigene Provider

Provider Routing

Autemos unterstützt Routing für Desktop Browser, virtuelle Mobile Devices und reale Geräte.

Connection Management

Funktion	Beschreibung
API Credentials	Sichere Provider-Authentifizierung
Connection Test	Verbindungsprüfung vor dem Speichern
Device Availability	Anzeige verfügbarer Geräte
Execution Routing	Steuerung der Test-Ausführung pro Provider

Provider Status Monitoring

Online-/Offline-Status
Verfügbare Geräte
Slot-Kapazitäten
Browser-Verfügbarkeit

Infrastruktur

Certificates Management

Der Bereich Certificates verwaltet sichere Runtime-Zertifikate für geschützte Anwendungen.

Certificates — zentrale Verwaltung gemeinsamer Zertifikate mit Vault- und File-System-Integration.

Shared Certificate Sources

Administratoren können konfigurieren:

Gemeinsame Zertifikatsspeicherorte
Vault-Integrationen
Gemeinsame File-System-Quellen

Diese Zertifikate können projektübergreifend genutzt werden.

Shared Certificates

Gemeinsame Zertifikate werden zentral verwaltet und sind global verfügbar. Typische Anwendungsfälle:

Enterprise-Authentifizierung
Gemeinsame mTLS-Zugriffe
Organisationsweite Zertifikate

💡Persönliche Zertifikate werden im persönlichen Settings-Menü hinzugefügt und verwaltet — nicht in den Global Settings.

Sicherheit & Verschlüsselung

Sensible Konfigurationswerte werden plattformweit geschützt durch:

Backend-Verschlüsselung
Sichere Credential-Speicherung
Versteckte UI-Werte
Sichere API-Kommunikation

Plattform

System Status & Skalierbarkeit

Die Plattform bietet eine Live-Übersicht über den Zustand sämtlicher Infrastruktur-Komponenten — Administratoren können den Systemzustand jederzeit schnell überprüfen.

System Status Overview — Live-Status aller Plattform-Komponenten auf einen Blick.

Live-Status-Übersicht

LLM-Status
Sicherheitsniveau
Benachrichtigungsstatus
Storage Cleanup Verhalten

Enterprise Skalierbarkeit

Die Architektur der Global Settings unterstützt:

Enterprise Deployments

Grosse, verteilte Installationen mit zentraler Konfiguration.

Multi-Projekt Umgebungen

Konfiguration über viele parallele Projekte hinweg.

Verteilte Execution

Verteilte Execution-Infrastrukturen.

Cloud-native Setups

Cloud-native Testumgebungen.

Hybrid Testing

Hybride Testing-Setups (lokal + Cloud).

Anwendung

Use Cases & Vorteile

Typische Anwendungsfälle

Enterprise Plattform-Administration

Zentrale Verwaltung aller Infrastruktur- und Integrationskomponenten.

AI Infrastruktur-Konfiguration

Globale Verwaltung von AI-Providern und AI-Nutzung.

Security Governance

Organisationsweite Sicherheits- und Compliance-Richtlinien.

Distributed Test Infrastructure

Verwaltung von Selenium Grid und Cloud-Testplattformen.

Certificate & Authentication

Sichere Verwaltung von Runtime-Zertifikaten und Authentifizierung.

Vorteile

Vorteil	Beschreibung
Zentrale Administration	Ein zentraler Ort für sämtliche systemweiten Einstellungen.
Enterprise Security	Starke Verschlüsselung und moderne Zugriffskontrolle.
Skalierbare Infrastruktur	Unterstützt verteilte Ausführung und Cloud-Integrationen.
Operative Transparenz	Bietet Übersicht über Infrastrukturstatus und Konfiguration.
Flexible Integrationen	Unterstützt unterschiedliche Provider, Umgebungen und Enterprise-Architekturen.

Erste Schritte

Executive Dashboard

⚠️Administrator-Zugriff erforderlich — Die Konfiguration und Anpassung des Executive Dashboard ist ausschliesslich Benutzern mit Administrator-Rechten vorbehalten. Standardbenutzer können Dashboard-Informationen basierend auf ihren Berechtigungen ansehen, jedoch keine Konfigurationsänderungen durchführen.

Das Executive Dashboard bietet eine zentrale High-Level-Übersicht über das gesamte Testautomatisierungs-Portfolio innerhalb von Autemos. Es kombiniert Informationen aus Projekten, Testausführungen, Schedules, Infrastruktur sowie AI-/LLM-basierten Funktionen in einer einzigen Management-Ansicht.

Executive Dashboard — zentrale High-Level-Übersicht über das gesamte Testautomatisierungs-Portfolio.

Zielgruppe

Executives

Strategische Übersicht über Qualität und Automatisierung.

QA Manager

Portfolio-weite Qualitätssteuerung.

Test Leads

Teamübergreifende Test-Aktivität.

Engineering Manager

Release- und Stabilitäts-Entscheidungen.

Plattform-Administratoren

Globale Infrastruktur-Übersicht.

DevOps Teams

Pipeline- und Grid-Monitoring.

Zweck

Allgemeine Testqualität überwachen
Automatisierungs-KPIs analysieren
Flaky bzw. instabile Tests identifizieren
Testinfrastruktur überwachen
Portfolio-weite Trends analysieren
Fehler frühzeitig erkennen
AI-/LLM-Kosten überwachen
Gesundheitsstatus von Projekten bewerten
Release-Entscheidungen verbessern

Nur Administratoren können:

Dashboard Widgets konfigurieren
Portfolio-Metriken anpassen
Globale Dashboard-Einstellungen ändern
KPI-Schwellwerte definieren
Executive Reporting Views konfigurieren
Globale Analytics-Sichtbarkeit verwalten
Monitoring- und Governance-Einstellungen definieren

Erste Schritte

Dashboard Bereiche

Das Executive Dashboard besteht aus mehreren Analyse- und Monitoring-Bereichen, die zusammen ein vollständiges Bild der Plattform liefern.

Bereich	Zweck
Executive Overview	Zentrale KPIs zur Bewertung der Plattform
Portfolio Metrics	Portfolio-weite Qualitätsmetriken
Schedule Status	Aktive Schedules und automatisierte Ausführungen
Pass Rate Trends	Historische Pass Rate Entwicklung
Recent Failures	Aktuelle fehlgeschlagene Ausführungen
Flaky Tests	Instabile Tests mit Severity-Klassifizierung
Project Status	Qualität und Gesundheit einzelner Projekte
Grid Status	Operativer Zustand der Testinfrastruktur
Duration Trends	Trends der Testausführungsdauer
Project Health	Zusammenfassende Gesundheits-Scores
Activity Feed	Plattformaktivitäten in Echtzeit
LLM Cost Analytics	AI- und LLM-bezogene Betriebskosten
Quick Actions	Schneller Zugriff auf Verwaltungsaktionen

Executive KPIs

Executive Overview

Die Executive Overview zeigt zentrale KPIs zur Bewertung des allgemeinen Zustands der Testautomatisierungsplattform.

Executive Overview — zentrale KPIs (Pass Rate, Tests Executed, Coverage, Flaky Rate) auf einen Blick.

Wichtige Kennzahlen

Pass Rate

Allgemeine Erfolgsquote aller Testausführungen (z. B. 95,2 %). Bewertet Teststabilität, Release Readiness und Zuverlässigkeit.

Tests Executed

Gesamtanzahl ausgeführter Tests im gewählten Zeitraum — Portfolio-Aktivität und Automatisierungs-Tracking.

Test Coverage

Automatisierungsabdeckung kritischer Geschäftsprozesse und Flows — für Risikoanalyse und Identifikation von Lücken.

Flaky Rate

Anteil instabiler oder inkonsistenter Tests. Hohe Werte deuten auf instabile Umgebungen, Synchronisationsprobleme, schwache Selektoren oder Infrastrukturprobleme hin.

Zeitfilter

Das Executive Dashboard unterstützt konfigurierbare Zeiträume:

Zeitfilter-Buttons (7 / 14 / 30 Days + Custom).

Filter	Beschreibung
7 Days	Kurzfristige Trends
14 Days	Mittelfristige Entwicklung
30 Days	Monatliche Übersicht
Custom Range	Eigener Zeitraum für detaillierte Analysen

Executive KPIs

Portfolio Pass Rate Trend

Visualisiert die Entwicklung der Pass Rate über die Zeit hinweg für das gesamte Portfolio.

Portfolio Pass Rate Trend — historische Visualisierung der Erfolgsquote über das gesamte Portfolio.

Unterstützt

Qualitätsüberwachung
Erkennung von Regressionen
Stabilitätsanalysen
Bewertung der Release-Qualität

Features

Historische Visualisierung
Trendanalyse
Zeitbereichsfilter
Vergleichende Qualitätsanalysen

Monitoring

Schedule Status

Zeigt den aktuellen Zustand aller aktiven Schedules und automatisierten Ausführungen.

Schedule Status — Übersicht aktiver Schedules, 24h Pass Rate und geplante Ausführungen.

Angezeigte Informationen

Kennzahl	Beschreibung
Active Schedules	Anzahl aktiver Schedules, Gesamtanzahl konfigurierter Schedules, Ausführungsbereitschaft
Pass Rate (24h)	Erfolgsquote geplanter Ausführungen in den letzten 24 Stunden
Upcoming Runs	Geplante Ausführungen, nächste Startzeiten, Queue-Übersicht

Vorteile

Execution Pipelines überwachen
Bottlenecks frühzeitig erkennen
Kontinuierliche Testaktivität sicherstellen

Monitoring

Recent Failures

Bietet eine schnelle Übersicht über die neuesten fehlgeschlagenen Testausführungen — für schnelle Reaktion auf Incidents.

Recent Failures — aktuelle fehlgeschlagene Tests mit Failure-Indikatoren und Status.

Features

Aktuelle fehlgeschlagene Tests
Failure-Indikatoren
Ausführungsstatus

✅Wenn keine Fehler vorhanden sind, wird ein sauberer Systemstatus angezeigt.

Vorteile

Schnelle Fehlererkennung
Incident-Reaktion
Regressionserkennung

Monitoring

Flaky Tests

Das Flaky Tests Widget identifiziert instabile Tests mit inkonsistentem Verhalten und priorisiert sie nach Severity.

Flaky Tests — Liste instabiler Tests mit Severity-Klassifizierung und Stabilitäts-Score.

Angezeigte Informationen

Feld	Beschreibung
Testname	Eindeutiger Test-Identifier
Fehlerrate	Anteil fehlgeschlagener Läufe
Severity Level	Kritikalität (Critical / Warning / Low)
Letzte Ausführung	Zeitpunkt des letzten Laufs
Stabilitäts-Score	Zusammenfassende Stabilitätsmetrik

Severity-Klassifizierung

Critical

Hohe Failure-Rate, dringender Handlungsbedarf.

Warning

Auffällige Instabilität, sollte überprüft werden.

Low

Gelegentliche Inkonsistenzen, niedrige Priorität.

Vorteile

Stabilisierung priorisieren
Zuverlässigkeit der Tests erhöhen
False Positives reduzieren
CI/CD-Stabilität verbessern

Projects & Infrastructure

Project Status

Zeigt den Qualitäts- und Gesundheitsstatus einzelner Projekte — inklusive GO / NO-GO Entscheidungsunterstützung für Release-Freigaben.

Project Status — Pro-Projekt-Übersicht mit Pass Rate, Coverage und GO/NO-GO Status.

Kennzahlen pro Projekt

Kennzahl	Beschreibung
Pass Rate	Erfolgsquote des Projekts
Coverage	Test-Abdeckung
Total Tests	Gesamtanzahl der Tests
Failed Tests	Anzahl fehlgeschlagener Tests
GO / NO-GO Status	Klare Release-Empfehlung

GO / NO-GO Entscheidungsunterstützung

Das Dashboard unterstützt Release-Entscheidungen durch klare Qualitätsindikatoren:

GO

Projekt erfüllt alle Qualitätsschwellen — Release empfohlen.

NO-GO

Projekt unter Qualitätsschwelle — Release blockiert.

Verwendet für: Release Management · Deployment-Freigaben · Executive Reporting

Projects & Infrastructure

Grid Status

Zeigt den operativen Zustand der Testinfrastruktur — Grid Nodes, Sessions und Parallelisierungskapazität.

Grid Status — Übersicht der Selenium Grid Nodes, Sessions und Auslastung.

Kennzahlen

Kennzahl	Anzeige
Nodes	Gesamtanzahl Grid Nodes, verfügbare Nodes, Offline Nodes
Sessions	Aktive Sessions, Session-Auslastung, Parallelisierungs-Kapazität

Vorteile

Identifikation von Infrastruktur-Bottlenecks
Erkennung von Ressourcenengpässen
Aufdeckung von Grid-Instabilitäten

Projects & Infrastructure

Duration Trends

Analysiert Trends der Testausführungsdauer über die Zeit hinweg — für Performance-Monitoring und Infrastruktur-Planung.

Duration Trends — Trendanalyse der Ausführungszeiten zur Performance-Optimierung.

Kennzahlen

Durchschnittliche Laufzeit
Langsamste Ausführungen
Zeitliche Veränderungen

Vorteile

Performance-Monitoring
Optimierung der Ausführungszeiten
Infrastrukturplanung

Projects & Infrastructure

Project Health

Das Project Health Widget bewertet die Gesamtqualität eines Projekts anhand mehrerer KPIs und liefert einen zusammenfassenden Health Score.

Project Health — Health Score auf Basis von Pass Rate, Flakiness, Coverage und Cost Trends.

Health Metrics

Pass Rate
Flakiness
Coverage
Cost Trends

Health Score

Projekte erhalten einen zusammenfassenden Gesundheits-Score (z. B. 4 / 5 Excellent).

Vorteile

Executive Visibility
Vereinfachte Qualitätsbewertung
Portfolio-Priorisierung

AI & Activity

Activity Feed

Der Activity Feed zeigt aktuelle Plattformaktivitäten in Echtzeit — für operative Transparenz und Team Awareness.

Activity Feed — Echtzeit-Stream aller Plattformaktivitäten.

Ereignisse

Schedule-Ausführungen
Erfolgreiche Tests
Fehlgeschlagene Tests
Systemaktionen
AI-Aktivitäten

Vorteile

Operative Transparenz
Echtzeit-Monitoring
Team Awareness

AI & Activity

LLM Cost Analytics

Überwacht AI- und LLM-bezogene Betriebskosten — für Budgetkontrolle und Optimierung der AI-Effizienz.

LLM Cost Analytics — Tracking täglicher und monatlicher AI-Kosten sowie Nutzungstrends.

Kennzahlen

Kennzahl	Beschreibung
Heutige AI-Kosten	Tageskosten der AI-Nutzung
Monatliche AI-Kosten	Kumulierte Kosten des aktuellen Monats
AI-Nutzungstrends	Entwicklung der Nutzung über die Zeit

Vorteile

AI-Kosten kontrollieren
API-Nutzung überwachen
AI-Effizienz optimieren
Budgetplanung unterstützen

AI & Activity

Quick Actions

Bietet schnellen Zugriff auf häufig verwendete Verwaltungsaktionen — für effiziente Navigation und administrative Workflows.

Quick Actions — Direktzugriff auf Projects, Analytics und administrative Aktionen.

Beispielaktionen

Browse Projects
Open Analytics Dashboard
Manage Projects

Vorteile

Verbesserte Navigationsgeschwindigkeit
Operative Effizienz
Optimierte administrative Workflows

Plattform & Anwendung

Plattform-Features

Das Executive Dashboard kombiniert drei strategische Plattform-Fähigkeiten: Echtzeit-Monitoring, projektübergreifende Sichtbarkeit und integrierte AI-Analytik.

Echtzeit-Monitoring

Das Executive Dashboard wurde für nahezu Echtzeit-Monitoring entwickelt — mit Live-Updates, dynamischen Kennzahlen und kontinuierlichem Infrastruktur-Monitoring.

Projektübergreifende Sichtbarkeit

Im Gegensatz zu projektbezogenen Dashboards aggregiert das Executive Dashboard globale Daten über:

Alle Projekte
Alle Schedules
Alle Ausführungen
Alle Umgebungen
Alle Infrastruktur-Nodes

AI & Automation Insights

Das Dashboard integriert AI-bezogene Metriken wie:

LLM-Kosten
AI-generierte Tests
AI-gestützte Ausführungen
AI-basierte Qualitätsanalysen

Dadurch entsteht Transparenz über Automatisierungsqualität und AI-Betriebskosten.

Plattform & Anwendung

Enterprise Vorteile & Use Cases

Enterprise Vorteile

Vorteil	Beschreibung
Executive Visibility	Management-taugliches Reporting und Qualitätsmonitoring.
Schnellere Entscheidungen	Schnelle Identifikation von Risiken, Fehlern, instabilen Projekten und Infrastrukturproblemen.
Höhere Release-Sicherheit	Release-Governance durch Health Metrics, Pass Rates und GO / NO-GO Indikatoren.
Infrastruktur-Transparenz	Einblicke in Grid-Auslastung, Parallelisierungskapazität und Geräteverfügbarkeit.
AI Governance	Überwachung und Kontrolle von AI-Nutzung und AI-Kosten.

Typische Use Cases

Release Readiness Monitoring

Bewertung, ob Projekte bereit für ein Deployment sind.

Portfolio Quality Tracking

Überwachung von Qualitätsentwicklungen über alle Automatisierungsinitiativen hinweg.

Infrastruktur-Monitoring

Überwachung des Selenium Grid und der gesamten Testinfrastruktur.

Flaky Test Reduktion

Identifikation instabiler Tests zur Verbesserung der CI/CD-Zuverlässigkeit.

Executive Reporting

Bereitstellung managementfreundlicher Qualitäts- und Automatisierungsmetriken.

Erste Schritte

Projects

⚠️Nur für Administratoren — Projekte können ausschliesslich von Administratoren erstellt, bearbeitet und gelöscht werden.

Das Projects Menü ist der zentrale Verwaltungsbereich für alle Projekte innerhalb von Autemos. Es ermöglicht Benutzern, verschiedene Automatisierungsprojekte zu erstellen, zu organisieren, zu durchsuchen und zwischen ihnen zu navigieren.

Projects Overview — zentraler Verwaltungsbereich aller Projekte mit Suche, Filter und Project Cards.

Projekte als oberster Container

Projekte dienen als oberster Container für:

Test Workflows

Alle Workflows eines Projekts.

Test Runs

Projekt-bezogene Ausführungen.

Pages

Wiederverwendbare PageObjects.

Auto-Heal Konfigurationen

Healing-Regeln pro Projekt.

Test Data

Testdaten und Datensätze.

Schedules

Geplante Ausführungen.

Code Generation

Generierter Automatisierungscode.

Recorder Sessions

Aufgezeichnete Sessions.

Was ein Projekt repräsentieren kann

Jedes Projekt ist logisch getrennt und kann folgendes repräsentieren:

Eine Anwendung
Ein Produkt
Einen Kunden
Eine Business-Domain
Eine Testinitiative

Zweck

Das Projects Menü unterstützt Teams dabei:

Automatisierungs-Assets zu organisieren
Testdomänen voneinander zu trennen
Projektspezifische Workflows zu verwalten
Schnell auf Projektfunktionen zuzugreifen
Skalierbare Automatisierungsstrukturen aufzubauen

Übersichtsseite

Project Cards

Jedes Projekt wird als Project Card mit wichtigen Informationen dargestellt — für schnelle Übersicht und Navigation.

Project Card — kompakte Übersicht mit Status, Test-Anzahl, Failed Tests, Pages und Fields.

Angezeigte Informationen

Information	Beschreibung
Project Name	Eindeutiger Name des Projekts
Project Status	Aktivitätsindikator (active / inactive)
Anzahl der Tests	Gesamtanzahl der Tests im Projekt
Failed Tests (7d)	Fehlgeschlagene Tests der letzten 7 Tage
Anzahl der Pages	Anzahl konfigurierter PageObjects
Anzahl der Fields	Anzahl wiederverwendbarer Felder
Last Updated Timestamp	Zeitpunkt der letzten Änderung

Project Status

Projekte können verschiedene Statusindikatoren anzeigen:

active

Projekt ist aktiv und in Verwendung.

inactive

Projekt ist deaktiviert oder ungenutzt.

Dadurch erhalten Benutzer schnelle Transparenz über die Projektaktivität.

Übersichtsseite

Suche, Sortierung & Ansichten

Die Projects Übersichtsseite bietet umfangreiche Funktionen, um auch in grossen Portfolios schnell das richtige Projekt zu finden.

Project Search

Die Suchleiste ermöglicht es Benutzern, Projekte schnell zu finden. Unterstützt die Suche nach:

Projektname
Projektbezogenen Inhalten

Sorting Options

Projekte können nach verschiedenen Kriterien sortiert werden:

Sortierung	Beschreibung
Recently Updated	Zuletzt geänderte Projekte zuerst
Name	Alphabetisch nach Projektname
Tests	Nach Anzahl der Tests
Failed (7d)	Nach fehlgeschlagenen Tests der letzten 7 Tage
Pages	Nach Anzahl der PageObjects
Fields	Nach Anzahl der Fields

Vorteile der Sortierung

Aktive Projekte priorisieren
Instabile Projekte identifizieren
Grosse Projekte schnell finden
Wachstum der Automatisierung überwachen

View Modes

Die Projects Seite unterstützt mehrere Darstellungsmodi:

Grid View

Kompakte Card-Ansicht mit allen Projekten im Überblick.

List View

Tabellarische Listenansicht mit Detail-Informationen.

Verwaltung

Create New Project

Administratoren können neue Projekte direkt über das Projects Menü erstellen.

Create New Project Dialog — Projektname und optionale Beschreibung definieren.

Create Project Dialog

Feld	Beschreibung
Project Name	Definiert den eindeutigen Namen des Projekts.
Description	Optionale Projektbeschreibung für organisatorische Zwecke.

Create Project Action

Der Create Project Button erstellt den neuen Projektcontainer und initialisiert die Projektstruktur (Workflows, Pages, Schedules, etc.).

Verwaltung

Edit & Delete Project

Bestehende Projekte können von Administratoren bearbeitet oder entfernt werden.

Edit Project

Edit Project — Projektname kann jederzeit umbenannt werden.

Bestehende Projekte können nach der Erstellung bearbeitet werden.

Bearbeitbare Felder

Feld	Beschreibung
Project Name	Der Projektname kann jederzeit umbenannt werden.

Delete Project

Administratoren können Projekte entfernen, die nicht mehr benötigt werden.

⚠️Wichtige Hinweise — Das Löschen eines Projekts kann folgende Inhalte entfernen: Workflows, Runs, Pages, Test Data, Schedules sowie generierte Assets. Die genauen Auswirkungen sind abhängig von der Systemkonfiguration und den Retention Policies.

Funktionen

Navigation Shortcuts & Isolation

Jede Project Card bietet direkte Navigations-Shortcuts zu wichtigen Projektbereichen, und jedes Projekt ist vollständig isoliert.

Test Workflow Navigation

Benutzer können direkt das Test Workflow Menü öffnen. Dies ermöglicht schnellen Zugriff auf:

Workflow-Bearbeitung
Workflow-Ausführung
Wartung der Automatisierung

Code Generation Navigation

Benutzer können direkt das Code Generation Menü öffnen. Dies ermöglicht schnellen Zugriff auf:

Generierten Automatisierungscode
Framework-Exporte
AI-generierte Automatisierungs-Assets

Project Isolation

Jedes Projekt verwaltet isolierte:

Workflows
Page Objects
Fields
Schedules
Automatisierungs-Assets

Vorteile der Isolation

Saubere Organisation
Skalierbarkeit
Unterstützung mehrerer Teams
Klare Verantwortlichkeitstrennung

Funktionen

Access Management

Projektzugriffsrechte werden nicht innerhalb des Projects Menüs verwaltet — die gesamte Projekt-Zugriffskontrolle erfolgt zentral über das Users Menü.

💡Im Users Menü werden alle Zugriffsrechte projektübergreifend gepflegt — das hält das Projects Menü übersichtlich und fokussiert auf Projektorganisation.

Was im Users Menü konfiguriert wird

Projektsichtbarkeit

Welche Benutzer welche Projekte sehen können.

Benutzerzuweisungen

Zuweisung von Usern zu Projekten.

Rollenverwaltung

Definition und Vergabe von Projektrollen.

Berechtigungskonfiguration

Granulare Permission-Einstellungen.

Anwendung

Use Cases & Enterprise Vorteile

Typische Use Cases

Customer Separation

Separate Projekte für unterschiedliche Kunden oder Tenants.

Application Separation

Organisation der Automatisierung nach Anwendungen oder Plattformen.

Team Organization

Trennung von Projekten nach Abteilungen oder QA-Teams.

Environment Isolation

Unabhängige Automatisierungsstrukturen für Staging, Produktion und Testumgebungen.

Skalierbarkeit

Das Projects Menü wurde entwickelt zur Unterstützung von:

Kleinen Teams
Enterprise-Organisationen
Multi-Projekt-Umgebungen
Grossen Automatisierungs-Portfolios

Enterprise Vorteile

Vorteil	Beschreibung
Better Organization	Strukturierte Trennung von Automatisierungs-Assets.
Faster Navigation	Schneller Zugriff auf Workflows und Code Generation.
Simplified Management	Zentrale Projektverwaltung und Übersicht.
Scalability	Unterstützt grosse Enterprise-Automatisierungsportfolios.

Erste Schritte

Test Search

Das Test Search Menü bietet eine zentrale Such- und Discovery-Oberfläche für alle Tests innerhalb von Autemos. Die Funktion wurde entwickelt, um schnelle Transparenz über grosse Automatisierungsportfolios hinweg zu ermöglichen.

Test Search Overview — zentrale Tabellenansicht aller Tests mit Suche, Filtern und Pass-Rate-Visualisierung.

Was die Funktion ermöglicht

Tests schnell finden
Teststatus analysieren
Ausführungsqualität überwachen
Fehlgeschlagene oder flaky Tests filtern
Testdetails einsehen
Direkt zu zugehörigen Test Runs navigieren

Zweck

Die Test Search Funktion unterstützt Teams dabei:

Tests projektübergreifend zu finden
Testqualität zu überwachen
Fehlgeschlagene oder instabile Tests zu identifizieren
Ausführungsstatistiken zu analysieren
Schnell zu Ausführungen zu navigieren
Debugging-Workflows zu verbessern
Portfolio-weite Transparenz zu schaffen

Hauptfunktionen

Globale Testsuche

Suche über alle Projekte hinweg.

Filterfunktionen

All / Passed / Failed / Flaky.

Testübersichtstabelle

Zentrale Tabelle mit allen Metriken.

Pass Rate Visualisierung

Visuelle Fortschrittsindikatoren.

Ausführungsstatistiken

Total Runs, Average Duration, Last Run.

Detaillierte Testansicht

Performance Trends und Tags.

Direkte Test Runs Navigation

Schnellzugriff auf Ausführungshistorie.

Suche & Filter

Die Test Search Seite kombiniert eine leistungsstarke globale Suche mit schnellen Filtermöglichkeiten — für effiziente Test Discovery.

Global Test Search

Die Suchleiste ermöglicht die globale Suche über alle Projekte hinweg. Unterstützt die Suche nach:

Suchkriterium	Beispiele
Test Name	`custom-workflow`
Suite	`Banking`
Component	`chromium`
Tags	`Mobile`

Filter Optionen

Die Test Search Seite bietet schnelle Filtermöglichkeiten:

All

Alle Tests anzeigen.

Passed

Nur erfolgreich ausgeführte Tests.

Failed

Nur fehlgeschlagene Tests.

Flaky

Nur instabile Tests mit inkonsistentem Verhalten.

Zweck der Filter

Instabile Tests isolieren
Fehler schneller erkennen
Flaky Verhalten analysieren
Sich auf stabile Ausführungen konzentrieren

Tabelle

Test Overview Table

Die zentrale Tabelle zeigt alle passenden Tests inklusive wichtiger Ausführungsmetriken.

Angezeigte Informationen

Spalte	Beschreibung
Test Name	Eindeutiger Test-Identifier
Tags	Kategorisierungs-Metadaten
Project	Zugehöriges Projekt
Average Duration	Durchschnittliche Laufzeit
Status	PASSED / FAILED / FLAKY
Pass Rate	Prozentwert + visueller Indikator
Total Runs	Gesamtanzahl der Ausführungen
Last Run Timestamp	Zeitpunkt der letzten Ausführung
Action Buttons	Direktzugriff auf Details und Test Runs

Test Status

PASSED

Test wurde erfolgreich ausgeführt.

FAILED

Test ist fehlgeschlagen.

FLAKY

Test zeigt inkonsistentes Verhalten.

Die Statusindikatoren ermöglichen schnelle Transparenz über die Stabilität der Tests.

Pass Rate Visualisierung

Die Pass Rate Spalte enthält Prozentwerte und visuelle Fortschrittsindikatoren — dadurch kann schnell die Testzuverlässigkeit, Konsistenz der Ausführungen und Qualität der Automatisierung bewertet werden.

Weitere Metriken

Metrik	Verwendung
Average Duration	Performance-Monitoring, Identifikation langsamer Tests, Optimierungsanalysen
Total Runs	Nutzungsanalyse, Ausführungs-Tracking, Stabilitätsbewertung
Last Run Information	Veraltete Tests identifizieren, aktuelle Aktivitäten überwachen, Aktualität prüfen

Test Details

Test Details View

Benutzer können eine detaillierte Testansicht für jeden Test öffnen — mit erweiterten Informationen zu Ausführung und Performance.

Test Details View — erweiterte Informationen mit Performance Trend, Tags und direkter Navigation zu Test Runs.

Angezeigte Informationen

Information	Beschreibung
Test Name	Eindeutiger Test-Identifier
Current Status	Aktueller Status (PASSED / FAILED / FLAKY)
Suite	Zugehörige Test Suite
Component	Komponenten-Zuordnung
Duration	Laufzeit des Tests
Pass Rate (30d)	Erfolgsquote der letzten 30 Tage
Total Runs	Gesamtanzahl der Ausführungen
Last Run	Zeitpunkt der letzten Ausführung
Performance Trend	Visualisierter Trend über die Zeit
Tags	Zugewiesene Metadaten

Recent Performance

Der Recent Performance Graph visualisiert das aktuelle Ausführungsverhalten über die Zeit. Unterstützt:

Stabilitätsanalysen
Trendüberwachung
Qualitätsmonitoring

Tags Bereich

Der Tags Bereich zeigt zugewiesene Metadaten zur besseren Kategorisierung und Suchbarkeit.

View Runs Navigation

Der View Runs Button ermöglicht die direkte Navigation zu den zugehörigen Test Runs. Dadurch erhalten Benutzer schnellen Zugriff auf:

Ausführungshistorie
Logs
Screenshots
Debugging-Informationen
Fehleranalysen

Sichtbarkeit

Projektübergreifende Sichtbarkeit

Die Test Search Funktion arbeitet über alle zugänglichen Projekte hinweg — eine echte portfolio-weite Discovery-Oberfläche.

💡Dadurch können Benutzer projektübergreifend nach Tests suchen, ohne vorher das richtige Projekt auswählen zu müssen — ideal für QA-Teams, die mehrere Projekte parallel betreuen.

Möglichkeiten

Global suchen
Tests vergleichen
Doppelte Tests identifizieren
Portfolio-weite Qualität überwachen

Anwendung

Use Cases & Enterprise Vorteile

Typische Use Cases

Failure Investigation

Fehlgeschlagene Tests finden und Ausführungsdetails analysieren.

Flaky Test Analyse

Flaky Tests filtern und Stabilisierung priorisieren.

Automation Health Monitoring

Pass Rates und Ausführungsmetriken überwachen.

Cross-Project Search

Tests unabhängig vom Projektstandort finden.

Execution Analysis

Historische Ausführungsmetriken und Trends analysieren.

Enterprise Vorteile

Vorteil	Beschreibung
Zentrale Transparenz	Eine zentrale Suchoberfläche für alle Tests innerhalb der Organisation.
Höhere operative Effizienz	Reduziert den Zeitaufwand beim Finden von Tests und Ausführungen.
Verbesserte Qualitätsüberwachung	Ermöglicht portfolio-weite Stabilitätsanalysen.
Schnellere Incident Response	Unterstützt schnellere Analyse von Fehlern und Regressionen.

Erste Schritte

User Management

⚠️Nur für Administratoren — Der Bereich User Management ist ausschliesslich für Administratoren zugänglich. Nur Benutzer mit administrativen Berechtigungen können Benutzer einladen, bearbeiten, deaktivieren, löschen, Projekte zuweisen und Rollen verwalten. Dies gewährleistet eine sichere und zentralisierte Zugriffskontrolle innerhalb der gesamten Autemos Plattform.

Das User Management Menü ist der zentrale Administrationsbereich zur Verwaltung aller Benutzer innerhalb von Autemos.

Was Administratoren können

Benutzer erstellen und einladen
Benutzerkonten verwalten
Projektzugriffe zuweisen
Projektrollen konfigurieren
Benutzeraktivitäten überwachen
Plattformberechtigungen steuern

Entwickelt für

Enterprise Access Management

Zentrale Kontrolle für grosse Organisationen.

Multi-Team-Umgebungen

Saubere Trennung mehrerer Teams.

Sichere Projektisolation

Granulare Zugriffskontrolle pro Projekt.

Skalierbare Berechtigungen

Auch bei sehr grossen Benutzerzahlen.

Zweck

Der Bereich User Management unterstützt Organisationen dabei:

Plattformzugriffe zu kontrollieren
Verantwortlichkeiten zu trennen
Projektberechtigungen zu verwalten
Neue Benutzer einzubinden
Inaktive Konten zu deaktivieren
Sichere Enterprise-Governance sicherzustellen

Hauptfunktionen

Benutzerübersicht
Benutzersuche
Benutzereinladung
Benutzerbearbeitung
Projektzuweisung
Rollenverwaltung
Aktivierung und Deaktivierung von Konten
Benutzerlöschung

Übersicht

User Management Übersicht

Die Hauptübersicht zeigt alle registrierten Benutzer an — mit Dashboard-Statistiken, Suchfunktion und vollständiger Benutzertabelle.

User Management Übersicht — Dashboard mit Statistiken, Benutzersuche und vollständiger Benutzertabelle.

Dashboard Statistiken

Die oberen Dashboard-Karten bieten eine schnelle Übersicht über die Plattformnutzung:

Total Users

Gesamtanzahl aller registrierten Benutzer.

Active Users

Anzahl aktiver Konten.

Administrators

Anzahl der Admin-Benutzer.

Disabled Users

Anzahl deaktivierter Konten.

Benutzertabelle

Die Benutzertabelle zeigt alle Benutzer und deren Kontoinformationen:

Spalte	Beschreibung
User Name	Vollständiger Name des Benutzers
Username	Eindeutiger Benutzername (Login)
Email	E-Mail-Adresse
Role	Systemweite Rolle (Administrator / User)
Status	Kontostatus (Active / Disabled)
Created Date	Datum der Kontoerstellung
Last Login	Zeitpunkt des letzten Logins
Actions Menu	Direktzugriff auf Benutzeraktionen

Benutzerrollen

Benutzer können unterschiedliche systemweite Rollen besitzen:

Administrator

Vollständige Plattform-Verwaltungsrechte.

User

Standard-Benutzerkonto mit projektbezogenen Rechten.

Die Rollen definieren Plattformberechtigungen, Verwaltungsfunktionen und Zugriffseinschränkungen.

Benutzerstatus

Active

Benutzer kann sich anmelden und arbeiten.

Disabled

Benutzer ist gesperrt — kein Login möglich.

Suchfunktion

Die Suchleiste ermöglicht Administratoren das schnelle Auffinden von Benutzern. Unterstützte Suchkriterien:

Name
Username
E-Mail-Adresse

Verwaltung

Invite New User

Administratoren können neue Benutzer direkt über das User Management Menü einladen.

Invite User Dialog — Email, Username, Vor- und Nachname für die Einladung neuer Benutzer.

Invite User Dialog

Feld	Beschreibung
Email	E-Mail-Adresse für die Einladung
Username	Eindeutiger Login-Name
First Name	Vorname des Benutzers
Last Name	Nachname des Benutzers

⚠️SMTP Hinweis — Falls SMTP nicht konfiguriert ist, zeigt das System eine Warnmeldung an. In diesem Fall können Einladungs-Emails nicht automatisch versendet werden, und Passwort-Reset-Links müssen manuell geteilt werden. Dadurch werden Administratoren auf unvollständige Benachrichtigungskonfigurationen hingewiesen.

Benutzererstellung

Nach der Einladung:

Wird das Benutzerkonto erstellt
Können Login-Daten initialisiert werden
Kann der Benutzer Onboarding-Informationen erhalten

Verwaltung

Benutzer bearbeiten & Status

Bestehende Benutzer können nachträglich bearbeitet werden, und Administratoren können Konten jederzeit aktivieren oder deaktivieren.

Edit User — bearbeitbare Felder für E-Mail, Vor-/Nachname und User Enabled Status.

Bearbeitbare Felder

Feld	Beschreibung
Email	E-Mail-Adresse aktualisieren
First Name	Vornamen ändern
Last Name	Nachnamen ändern
User Enabled Status	Konto aktivieren oder deaktivieren

💡Username Einschränkung — Der Username kann nach der Erstellung nicht mehr geändert werden. Dies gewährleistet konsistente Identitäten, stabile Audit-Daten und sichere Berechtigungsstrukturen.

Benutzer aktivieren / deaktivieren

Administratoren können Benutzer aktivieren oder deaktivieren. Deaktivierte Benutzer:

Können sich nicht mehr anmelden
Verlieren den Plattformzugriff
Behalten historische Referenzen innerhalb des Systems

Verwendung

Temporäre Sperrungen

Kurzfristiger Zugriffsentzug.

Mitarbeiter-Offboarding

Geordneter Austritt mit Datenerhalt.

Sicherheitsmassnahmen

Sofortige Sperrung bei Compliance-Themen.

Verwaltung

User Actions & Löschen

Jede Benutzerzeile besitzt ein Actions Dropdown Menu mit allen wichtigen Benutzeraktionen.

Verfügbare Aktionen

Aktion	Beschreibung
Edit	Benutzerdaten bearbeiten
View Projects	Projektzuweisungen verwalten
Disable	Konto deaktivieren
Delete	Benutzer dauerhaft löschen

Benutzer löschen

Administratoren können Benutzer dauerhaft aus dem System entfernen.

⚠️Wichtige Hinweise — Beim Löschen eines Benutzers werden Berechtigungen sofort entfernt. Historische Test-Zuweisungen können erhalten bleiben, und Audit-Logs können weiterhin Referenzen speichern.

Projektzuweisung

Projektzuweisung & Rollen

Benutzer können einem oder mehreren Projekten zugewiesen werden — mit individuellen Projektrollen pro Zuweisung.

Manage User Projects — zentrale Verwaltung aller Projektzuweisungen pro Benutzer.

Manage User Projects

Der Projektdialog ermöglicht Administratoren:

Projekte zuzuweisen
Projekte zu entfernen
Projektrollen zu verwalten
Aktuelle Zuweisungen einzusehen

Assigned Projects Ansicht

Assigned Projects — bereits zugewiesene Projekte mit aktuellen Rollen und Zuweisungsdaten.

Der Tab Assigned Projects zeigt:

Zugewiesene Projekte
Aktuelle Projektrollen
Zuweisungsdaten
Projekt-Owner Informationen

Available Projects Ansicht

Der Tab Available Projects zeigt Projekte, die dem Benutzer noch nicht zugewiesen wurden. Administratoren können verfügbare Projekte durchsuchen und neue Projektzugriffe vergeben.

Assign Project Dialog

Assign Project Dialog — Projekt zuweisen und gleichzeitig die Benutzerrolle definieren.

Administratoren können ein Projekt zuweisen und gleichzeitig die Benutzerrolle definieren.

Projektrollen

Projektbezogene Rollen können sein:

Owner

Vollständige Projektverantwortung und administrative Kontrolle.

Admin

Kann Projektressourcen und Konfigurationen verwalten.

Member

Standardzugriff zur Zusammenarbeit innerhalb des Projekts.

Viewer

Nur lesender Zugriff auf Projektinformationen.

Projektberechtigungen

Projektrollen definieren den Zugriff auf:

Workflows
Test Runs
Pages
Schedules
Test Data
Automation Assets

Dies gewährleistet Projektisolation, kontrollierte Zusammenarbeit und sicheren Multi-Team-Betrieb.

Anwendung

Use Cases & Enterprise Vorteile

Typische Anwendungsfälle

Team-Onboarding

Neue QA Engineers oder Automation Developers einladen.

Kundentrennung

Benutzer ausschliesslich kundenbezogenen Projekten zuweisen.

Rollenbasierte Zugriffskontrolle

Administrative Funktionen gezielt auf bestimmte Benutzer beschränken.

Temporärer Zugriff

Kurzfristigen Projektzugriff für externe Mitarbeiter oder Partner vergeben.

Offboarding

Benutzer deaktivieren oder entfernen, wenn sie das Unternehmen verlassen.

Enterprise Vorteile

Vorteil	Beschreibung
Zentralisierte Zugriffskontrolle	Die gesamte Benutzer- und Berechtigungsverwaltung erfolgt zentral in einer Administrationsoberfläche.
Sichere Multi-Team-Zusammenarbeit	Projekte und Berechtigungen können sauber zwischen Teams und Abteilungen getrennt werden.
Skalierbare Benutzerverwaltung	Unterstützt Enterprise-Umgebungen mit grossen Benutzerzahlen.
Vereinfachtes Onboarding	Neue Benutzer können schnell den benötigten Projekten zugewiesen werden.
Verbesserte Sicherheit	Administratoren behalten die vollständige Kontrolle über Berechtigungen, Projektzugriffe, Benutzeraktivitäten und den gesamten Benutzer-Lifecycle.

Erste Schritte

Code Template Management

⚠️Eingeschränkter Zugriff — Nur für Testarchitekten / Administratoren — Das Modul ist für fortgeschrittene Benutzer (Testarchitekten, Framework Engineers, Administratoren) vorgesehen. Fehlerhafte Änderungen an Templates können direkten Einfluss auf den generierten Automation Code in allen Projekten haben.

Das Modul Code Template Management ermöglicht es Testarchitekten und Administratoren, die Templates zu definieren und zu verwalten, welche von Autemos für die automatische Codegenerierung verwendet werden.

Code Template Management — zentrale Verwaltung aller Codegenerierungs-Templates pro Sprache und Framework.

Grundlage für

Code Generation Engine

Dynamische Generierung von Automation Code.

KI-gestützte Generierung

Basis für AI-erzeugten Automation Code.

Framework-Exportsystem

Framework-spezifischer Code-Export.

Anstatt statischen, vordefinierten Code zu generieren, erstellt Autemos den Automatisierungscode dynamisch auf Basis konfigurierbarer Templates. Dadurch kann der generierte Code vollständig an interne Coding Standards, Framework-Strukturen, Architekturvorgaben, Naming Conventions und Enterprise Best Practices angepasst werden.

Zweck

Generierten Automation Code standardisieren
Mehrere Programmiersprachen unterstützen
Verschiedene Automatisierungsframeworks unterstützen
Generierte Teststrukturen anpassen
Unternehmensweite Coding Standards einhalten
Templates an interne Frameworks anpassen

Unterstützte Programmiersprachen & Frameworks

Sprachen	Frameworks
Java · TypeScript · Python · C#	Selenium · Playwright · Appium

Architekturübersicht

Das Code Template Management System ist in vier Hauptbereiche unterteilt:

Template Editor

Klassenstrukturen, Imports, Konstruktoren.

Node Templates

Workflow-Aktionen zu Code-Übersetzungen.

Methods & Field Types

Feldannotationen und Interaktionsmethoden.

Configuration Import/Export

Migration und Versionierung.

Konfiguration

Sprache & Framework Auswahl

Bevor Templates bearbeitet werden können, müssen Benutzer eine Programmiersprache und ein Automatisierungsframework auswählen. Dadurch entstehen framework-spezifische Template-Konfigurationen.

Haupttemplate-Typen

Das System unterstützt verschiedene Template-Kategorien:

pageobject

Templates für wiederverwendbare PageObject-Klassen.

test

Templates für ausführbare Testklassen.

Diese Templates definieren die grundlegende Struktur des generierten Automation Codes.

💡Jede Kombination aus Sprache + Framework hat ihre eigene Template-Konfiguration — z. B. unterscheidet sich ein Java/Selenium-PageObject grundlegend von einem TypeScript/Playwright-PageObject.

Template Editor

Der Template Editor definiert die allgemeine Codestruktur, die während der Codegenerierung verwendet wird — Imports, Klassenstrukturen, Konstruktoren, Methoden, Feldinjektionen und Variablen-Placeholder.

Template Editor — Klassenstruktur, Konstruktoren und Variablen-Placeholder für die Codegenerierung.

Main Template

Das Main Template steuert die generierte Klassenstruktur:

PageObject Templates

Struktur wiederverwendbarer PageObjects.

Testklassen-Templates

Struktur ausführbarer Testklassen.

Template-Variablen

Templates unterstützen dynamische Platzhaltervariablen — diese werden während der Codegenerierung automatisch ersetzt:

Variable	Verwendung
`${className}`	Name der generierten Klasse
`${fields}`	Felder-Block (Field Annotations)
`${methods}`	Methoden-Block (Interaction Methods)
`${packageName}`	Package- bzw. Namespace-Name

Constructor Template

Definiert, wie Konstruktoren generiert werden. Beispielhafte Anwendungsfälle:

WebDriver Injection
Dependency Injection
Framework-Initialisierung
PageFactory-Initialisierung

Beschreibungsfeld & Speichern

Das Description-Feld dokumentiert den Zweck des Templates zur besseren Wartbarkeit. Die Aktion Save Template speichert die aktualisierte Template-Konfiguration — Änderungen wirken sich unmittelbar auf zukünftigen generierten Code aus.

Node Templates

Node Templates definieren, wie Workflow-Nodes in Automation Code übersetzt werden. Jede Workflow-Aktion kann abhängig von Sprache, Framework und Architektur unterschiedlichen Code generieren.

Node Templates — Definition der Code-Generierung pro Workflow-Aktion (Click, Assertion, Navigation, …).

Unterstützte Node-Typen

Assertion

Verifikationen und Validierungen.

Click

Klick-Interaktionen.

Navigation

URL-Navigation und Routing.

Validation

Datenvalidierungen.

API Calls

HTTP-Aufrufe.

Wait Conditions

Synchronisation und Waits.

Template-Variablen

Node Templates unterstützen dynamische Platzhalter, die automatisch aus den Workflow-Daten befüllt werden:

Variable	Beschreibung
`${varName}`	Variablen-Name
`${methodCall}`	Methodenaufruf
`${value}`	Eingabewert
`${url}`	Ziel-URL
`${duration}`	Wartezeit / Timeout
`${expected}`	Erwarteter Wert
`${actual}`	Tatsächlicher Wert

Beispiel

Ein Assertion-Node kann beispielsweise als Template definiert sein:

assertEquals(${expected}, ${actual});

Während der Generierung wird daraus konkreter Code:

assertEquals("Success", resultText);

Methods & Fields

Methods & Field Types

Der Bereich Methods & Field Types definiert Feldannotationen, generierte Feldstrukturen und wiederverwendbare Interaktionsmethoden. Dadurch können generierte PageObjects framework-spezifischen Konventionen folgen.

Methods & Field Types — Templates für Feldannotationen und wiederverwendbare Methoden.

Field Type Selection

Benutzer können Templates für die folgenden Feldtypen definieren:

INPUT

Eingabefelder.

BUTTON

Schaltflächen.

CHECKBOX

Checkboxen.

DROPDOWN

Auswahllisten.

TABLE

Tabellen-Strukturen.

LINK

Hyperlinks.

Field Annotation Templates

Dieser Bereich definiert, wie UI-Elemente im generierten Code dargestellt werden:

Selenium-Annotationen
Playwright-Locators
Appium-Mobile-Selektoren

Wiederverwendbare Methoden

Das System unterstützt wiederverwendbare Interaktionsmethoden:

Methode	Verwendung
`click`	Klick auf ein Element
`type`	Texteingabe
`clear`	Feld leeren
`getValue`	Wert auslesen

Jede Methode kann benutzerdefinierte Implementierungslogik, framework-spezifisches Verhalten und Enterprise Utilities enthalten.

Hinweise auf fehlende Templates

Das System markiert unvollständige Template-Definitionen mit dem Hinweis „Missing Template". Dadurch können Architekten unvollständige Framework-Konfigurationen schnell identifizieren.

Edit- & Delete-Aktionen

Jedes Methodentemplate unterstützt Edit und Delete — dadurch ist eine vollständige Verwaltung wiederverwendbarer Automation-Methoden möglich.

Configuration

Configuration Import / Export

Der Configuration-Bereich ermöglicht Unternehmen, Template-Konfigurationen zu exportieren, zu importieren und zwischen Umgebungen zu migrieren.

Configuration Import / Export — Template-Konfigurationen für Backup, Migration und Team-Synchronisation.

Export Configuration

Exportiert die aktuelle Template-Konfiguration für:

Backups
Migrationen
Versionierung
Austausch zwischen Teams

Import Configuration

Importiert zuvor exportierte Template-Konfigurationen — nützlich für:

Onboarding
Framework-Rollouts
Synchronisation mehrerer Umgebungen

Anwendung

Use Cases & Best Practices

Typische Anwendungsfälle

Selenium Enterprise Frameworks

Generierung unternehmensweiter Selenium PageObjects und Teststrukturen.

Playwright-Standardisierung

Sicherstellung konsistenter Playwright-Architekturen über Teams hinweg.

Appium Mobile Automation

Generierung wiederverwendbarer Mobile-Automation-Strukturen.

KI-gestützte Codegenerierung

Bereitstellung sauberer Templates für KI-generierten Automation Code.

Best Practices

Empfehlung	Beschreibung
Versionierte Templates verwenden	Templates sollten versioniert und historisiert werden.
Zugriff beschränken	Nur erfahrene Framework-Architekten sollten Templates bearbeiten dürfen.
Templates sorgfältig testen	Fehlerhafte Templates können sämtliche generierten Automation-Artefakte beeinflussen.
Einheitliche Standards einhalten	Konsistente Naming- und Strukturkonventionen verwenden.

Test Workflows

Was Sie mit Test Workflows tun können

Erstellen und Bearbeiten

Kernkonzepte

Lineare Ausführung

Bedingte Logik

Schleifen

Drag & Drop Bearbeitung

Nodes verstehen

Mit Testdaten und Variablen arbeiten

Unterstützte Testtypen

Ihren ersten Test Workflow in 5 Minuten erstellen

Einen Test Workflow öffnen

Die Workflow-Struktur prüfen

Eine Validierung hinzufügen

Testdaten einführen

Aufräumen und Strukturieren

Den Workflow debuggen

Testbereitschaft bestätigen

Einen Workflow debuggen

Debug-Modus

Execution Log

Live-Ausführungsansicht

Error Handling & Soft Verify

Standardverhalten

Soft Verify

Wann welchen Ansatz verwenden

Standard (Bei Fehler stoppen)

Soft Verify (Fortsetzen)

Einen Workflow für die Ausführung vorbereiten

Self-Healing

Geringere Instabilität

Geringerer Wartungsaufwand

Verwandte Module

Open Browser

Wann verwenden

Konfiguration

Verhalten

Ausgabe

Fehlerbehandlung

Beispiel — Einen Chrome-Web-Test starten

Best Practices

Navigate

Wann verwenden

Konfiguration

Verhalten

Ausgabe

Beispiel — Zu einer Login-Seite navigieren

Best Practices

Close Browser

Wann verwenden

Configuration

Verhalten

Ausgabe

Beispiel — Browser am Ende des Workflows schließen

Best Practices

Type

Wann verwenden

Konfiguration

Verhalten

Ausgabe

Beispiel — Einen Verifizierungscode eingeben

Best Practices

Click

Wann verwenden

Konfiguration

Verhalten

Ausgabe

Beispiel — Die Login-Schaltfläche klicken

Best Practices

Double Click

Wann verwenden

Konfiguration

Verhalten

Ausgabe

Fehlerbehandlung

Beispiel — Einen Datensatz per Doppelklick öffnen

Best Practices

Right Click

Wann verwenden