Playground-Testautomatisierung

Wiedergabe von Automatisierungen als Test Manager-Automatisierungstyp neben von Studio erstellten Automatisierungen, ohne vorhandene Testsuiten in Studio neu zu schreiben.

Hinweis:

This capability is in controlled availability, delivered only to eligible tenants. It is available in Test Manager only when delivered through Test Cloud, and UiPath must enable it for your tenant before it works — contact your UiPath account team with your tenant details to request enablement.

Der Test Manager kann Testfälle ausführen, die von Playwright -Automatisierungen sowie von Studio erstellten (Robot)-Automatisierungen unterstützt werden. Teams, die bereits End-to-End-Tests in Playwright schreiben, können diese Tests in Test Manager zur Orchestrierung, Planung, Berichterstellung und Rückverfolgbarkeit integrieren, ohne sie in Studio neu zu schreiben.

So funktionieren Playwork-Automatisierungen durchgängig

Ein Playwright-Testprojekt befindet sich in einem eigenen Source Control-System außerhalb von UiPath. Von dort erreicht die Automatisierung den Test Manager über folgenden Ablauf:

1. Das Projekt wird mithilfe des tm pack -Befehls der UiPath-Befehlszeilenschnittstelle (CLI) in ein UiPath-Automatisierungspaket gepackt und dann im globalen mandantenweiten Paketfeed von Orchestrator oder in einem dedizierten Feed auf Ordnerebene veröffentlicht. Die Packschritte finden Sie unter Verpacken von Playwright-Projekten für den Test Manager.
2. Das veröffentlichte Paket wird im Test Manager auf die gleiche Weise wie eine in Studio veröffentlichte Automatisierung durch den Ablauf der Automatisierung ausgewählt.
3. Wenn das Paket mit einem Test Manager-Projektschlüssel erstellt wurde, werden übereinstimmende Testfälle automatisch erstellt und die Playwright-Automatisierung wird automatisch mit jedem Einzelnen verknüpft, sobald der Test Manager das Paket aufnimmt. Andernfalls wird der Testfall separat erstellt und die Automatisierung manuell verknüpft, wobei der gleiche Ablauf für Studio-Automatisierungen verwendet wird.
4. Von diesem Punkt an verhält sich der Testfall wie jeder andere automatisierte Testfall im Test Manager: Er kann in Testsätze gesetzt, bei Bedarf oder nach einem Zeitplan ausgelöst werden, und seine Ergebnisse, Artefakte und Links zur Rückverfolgbarkeit werden neben jedem anderen Testfall angezeigt .

Was der Test Manager aus Ihrem Playwright-Projekt erfasst

Test Manager-Feld	Kommt von Playwork
Name & Beschreibung	Nur Testtitel. Paketmetadaten enthalten kein Beschreibungsfeld, sodass die Beschreibung nicht ausgefüllt wird.
Beschriftungen	@tag /Anmerkungswerte (z. B. resilience, observability), als Beschriftungen zum Filtern und zum Testsatz-Scoping in den Testfall kopiert.
Projekt-/Spezifikationsdatei	Das Playwright-Projekt (aus playwright.config.ts) und die Spezifikationsdatei, zu der der Test gehört, erfasst als Metadaten. Pro Test wird ein Testfall erstellt – es gibt kein Fan-out pro Projekt.
Quelle (Registerkarte Automatisierung auswählen)	Ein Quellwert von Playwright oder UiPath, der in der Auswahl „Automatisierung auswählen“ angezeigt wird.

Hinweis:

Name & Die Beschreibung, Beschriftungen und die Projekt-/Spezifikationsdatei werden alle als automatisch generierte Systembeschriftungen für den Testfall implementiert. Nur Quelle ist ein separates Feld, das als eigene Spalte in der Automatisierungsauswahl ausgewählt wird, und nicht als Beschriftung.

Terminologie

• Automatisierung und Testfall bleiben getrennte Artefakttypen in Test Manager.
• Eine Automatisierung, ob Playwright oder Studio, wird einem Testfall zugewiesen.
• Ein Playwright-Test wird nie selbst als Testfall bezeichnet.

Ausführungs- und Berichtsparität

Einmal zugewiesen, wird ein von Playwright unterstützter Testfall genau wie ein von Studio erstellter ausgeführt, geplant und gemeldet: dieselben Trigger, dieselben Regeln für die Testsatzmitgliedschaft, dieselben Ergebnisse und Ansichten zur Rückverfolgbarkeit.

Bekannte Einschränkungen

Einschränkung	Was es bedeutet
Nur Chromium	Der Ausführungspod installiert nur Chromium. Ein Projekt, das für die Verwendung von Firefox oder Webkit konfiguriert ist, kann dennoch ausgewählt werden, aber die Ausführung wird nicht in diesem Browser ausgeführt.
Nur serverlose Ausführung	Playwork-Tests werden nur in der serverlosen UiPath-Infrastruktur mit einem dedizierten Pod pro Ausführung ausgeführt. Die Ausführung eines lokalen oder lokalen Roboters wird noch nicht unterstützt.
Nur Node.js (JavaScript/TypeScript).	Nur Node.js-basiert Playwork-Projekte werden unterstützt. Die Projekte playwright-python, playwright-java und playwright-dotnet werden nicht unterstützt.
Eigenständiges Projekt erforderlich	Jedes Projekt muss aus einem in sich geschlossenen Verzeichnis gepackt werden, wobei Abhängigkeiten am gepackten Stammverzeichnis auflösbar sind. Ein Mono-Repository-Unterordner funktioniert nur, wenn er eigenständig ist.
Keine Details auf Assertionsebene	Der Test Manager stellt die Assertionen von Playwork nicht einzeln bereit. Es basiert auf dem eigenen Pass-/Fehlschlagergebnis pro Versuch und den konfigurierten Anhängen von Playwight.
Kein Import von extern ausgeführten Ergebnissen	Ergebnisse einer Playwright Suite-Ausführung außerhalb des Test Managers, z. B. in der eigenen CI eines Kunden, können nicht importiert werden.
Einzelner Auftrag pro Ausführung	All test cases in one Playwright test set execution run within a single Orchestrator job — an oversized test set risks a job timeout.
Execution time limit	A Playwright test set execution has a 45-minute time limit, separate from the video-recording time limits that apply elsewhere in Test Manager.
Kein Multi-Pod-Sharding	Die gesamte Suite wird in einem Pod pro Ausführung ausgeführt. Die eigene Worker-Parallelität von Playwork gilt wie konfiguriert, aber verteiltes Shard über Pods hinweg ist noch nicht verfügbar.
Keine Berichterstellung pro Installation	Playwright-Installationen (test.extend()) werden normal ausgeführt, aber der Test Manager modelliert sie nicht mit Berichten auf Testfallebene oder pro Installation.
Keine Selbstreparatur	Agentische Selbstreparatur ist für Playwright-Automatisierungen noch nicht verfügbar.
Keine erzwungene Ausführungsreihenfolge	Testfallreihenfolge folgt playwright.config.ts. Das Aktivieren von „Enforce Execution Order“, „RPA Activity Coverage“ oder „Healing Agent“ in einem Playwright-Testsatz schlägt die Ausführung schnell fehl.
Paket- oder versionsübergreifendes Mischen ist verboten	Das Kombinieren von Testfällen aus zwei verschiedenen Playwright-Paketen oder aus demselben Paket in zwei verschiedenen Versionen in einem Testsatz ist blockiert.
Datengesteuerte Testsätze führen jede Variation aus	Jede Variante eines parametrisierten Playwright-Tests ist ein eigener Testfall. Beim Hinzufügen einer Variante zu einem Testsatz werden alle Variationen dieses Tests ausgeführt.
Keine UiPath-Videoaufzeichnung oder Live-Streaming	Das Aktivieren der Videoaufzeichnung für einen Playwright-Testsatz hat keine Auswirkungen und die Registerkarte Aufzeichnung und Livestream-Aktion zeigen keine Daten an. Die eigene Videoerfassung (use: { video } in playwright.config.ts) ist nicht betroffen – diese .webm -Dateien sind weiterhin als Artefakte angehängt.

Lizenzierung

Das Ausführen eines Playwright-Tests über den Test Manager verbraucht die gleiche Plattformkapazität wie jede andere serverlose Testausführung auf der zugrunde liegenden Roboter-Ausführungsebene – es gibt keine unterschiedliche Verbrauchsrate für Playwright und native UiPath-Testautomatisierungen. Weitere Informationen finden Sie unter Unified Pricing: Lizenzierung des Test Manager.

Zugehörig

• So funktioniert die Erfassung von Playwright-Artefakten
• Verpacken von Playwork-Projekten für den Test Manager
• Konfigurieren der Artefakterfassung für Playwright-Tests
• Auswählen von Automatisierungen