Automatisation des tests Playground

Lire les automatisations en tant que type d'automatisation Test Manager aux côtés des automatisations créées par Studio sans réécrire les suites de tests existantes dans Studio.

Remarque :

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.

Test Manager peut exécuter des cas de test s'appuyant sur des automatisations PlayWrite , en plus des automatisations créées par Studio. Les équipes qui écrivent déjà des tests de bout en bout dans Playground peuvent importer ces tests dans Test Manager à des fins d’orchestration, de planification, de génération de rapports et de traçabilité sans les réécrire dans Studio.

Fonctionnement des automatisations Playground

Un projet de test Playwork se trouve dans son propre système de contrôle de code source, en dehors d’UiPath. L’automatisation atteint ensuite Test Manager via le flux suivant:

1. Le projet est packagé dans un package d'automatisation UiPath à l'aide de la commande tm pack de l'interface de ligne de commande UiPath, puis publié dans le flux de package global pour le locataire d'Orchestrator ou dans un flux dédié au niveau du dossier. Pour les étapes de packaging, consultez Empaqueter les projets Playwight pour Test Manager.
2. Le package publié peut être sélectionné dans Test Manager de la même manière qu'une automatisation publiée dans Studio, via le flux d'automatisation Sélection .
3. Si le package a été créé avec une clé de projet Test Manager, les cas de test correspondants sont automatiquement créés et l’automatisation PlayWrite est automatiquement liée à chacun d’eux une fois que Test Manager a ingéré le package. Sinon, le cas de test est créé séparément et l'automatisation est liée manuellement, à l'aide du même flux utilisé pour les automatisations Studio.
4. À partir de ce moment, le cas de test se comporte comme n'importe quel autre cas de test automatisé dans Test Manager: il peut être placé dans des ensembles de tests, déclenché à la demande ou selon une planification, et ses résultats, artefacts et liens de traçabilité apparaissent aux côtés de tous les autres cas de test .

Ce que Test Manager capture de votre projet Playground

Champ Test Manager	Vient de Playground
Nom et horodatage; Description	Titre du test uniquement. Les métadonnées du package ne comportent aucun champ de description. La description n’est donc pas renseignée.
Libellés	@tag / valeurs d'annotation (par exemple, resilience, observability), copiées dans le cas de test sous forme de libellés à des fins de filtrage et de portée des ensembles de tests.
Fichier de projet/spécification	Le projet Playwork (depuis playwright.config.ts) et le fichier spécifique au test, capturés en tant que métadonnées. Un cas de test est créé par test, il n'y a pas de déploiement par projet.
Source (sélectionner l'onglet Automatisation)	Une valeur Source de PlayWrite ou UiPath, affichée dans le sélecteur Sélectionner l'automatisation.

Remarque :

Nom et horodatage; La description, les libellés et le fichier de projet/spécification sont tous mis en œuvre sous forme de libellés système générés automatiquement sur le cas de test. Seule la source est un champ distinct, affiché sous la forme d'une colonne dans le sélecteur Sélectionner l'automatisation plutôt que sous la forme d'un libellé.

Terminologie

• L'automatisation et le cas de test restent des types d'artefacts distincts dans Test Manager.
• Une automatisation, que ce soit Playground ou Studio, est affectée à un cas de test.
• Un test Playground n’est jamais lui-même appelé un cas de test.

Parité d'exécution et de rapports

Une fois attribué, un cas de test basé sur Playground est exécuté, planifié et signalé exactement comme un cas créé par Studio: mêmes déclencheurs, mêmes règles d’adhésion à l’ensemble de tests, mêmes résultats et vues de traçabilité.

Limites connues

Limitation	Ce que cela signifie
Chromium uniquement	Le pod d’exécution installe uniquement Chromium. Un projet configuré pour utiliser Firefox ou WebKit peut toujours être sélectionné, mais l'exécution ne s'exécute pas sur ce navigateur.
Exécution sans serveur uniquement	Les tests Playground s’exécutent uniquement sur l’infrastructure sans serveur UiPath, avec un pod dédié par exécution. L'exécution de robots sur site ou locaux n'est pas encore prise en charge.
Node.js uniquement	Uniquement basé sur Node.js Les projets Playground sont pris en charge. Les projets playwright-python, playwright-java et playwright-dotnet ne sont pas pris en charge.
Projet autonome requis	Chaque projet doit être compressé à partir d'un répertoire autonome, avec des dépendances résolvables à la racine compressée. Un sous-dossier à référentiel unique ne fonctionne que s'il est autonome.
Aucun détail au niveau des assertions	Test Manager n'expose pas les assertions de Playright individuellement. Il s'appuie sur le résultat de réussite/d'échec par tentative et de pièces jointes configurées.
Aucune importation des résultats d’exécutions externes	Les résultats d'une suite Playwight exécutée en dehors de Test Manager, par exemple dans le propre CI d'un client, ne peuvent pas être importés.
Tâche unique par exécution	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.
Pas de partage multi-pods	L'ensemble de la suite s'exécute dans un pod par exécution. Le parallélisme des travailleurs de Playert s’applique tel que configuré, mais le partitionnement distribué entre les pods n’est pas encore disponible.
Aucun rapport par correctif	Les installations Playwight (test.extend()) s'exécutent normalement, mais Test Manager ne les modélise pas avec des rapports au niveau des cas de test ou par correctif.
Aucune réparation automatique	L’autoréparation agentique n’est pas encore disponible pour les automatisations PlayWrite.
Aucun ordre d’exécution appliqué	L’ordre du cas de test suit playwright.config.ts. L’activation de l’ordre d’exécution, de la couverture de l’activité RPA ou de Healing Agent sur un ensemble de tests Playwork fait échoue l’exécution rapide.
Il est interdit de créer des packages ou de créer des versions différentes	Il est bloqué dans un même ensemble de tests. Il est bloqué dans un même ensemble de tests.
Les ensembles de tests centrés sur les données s’exécutent à chaque variation	Chaque variation d'un test Playwight paramétré est son propre cas de test. L'ajout d'une variation à un ensemble de tests exécute toutes les variations de ce test.
Aucun enregistrement vidéo ou flux en direct UiPath	L'activation de l'enregistrement vidéo sur un ensemble de tests Playground n'a aucun effet, et l'onglet Enregistrement et l'action de diffusion en direct n'affichent aucune donnée. La propre capture vidéo de PlayWrite (use: { video } dans playwright.config.ts) n’est pas affectée - ces .webm fichiers sont toujours joints en tant qu’artefacts.

Licences

L'exécution d'un test Playwight via Test Manager consomme la même capacité de la plateforme que toute autre exécution de test sans serveur, au niveau sous-jacent de l'exécution du robot - il n'y a pas de taux d'utilisation différent pour Playwwrite par rapport aux automatisations de test UiPath natives. Pour plus de détails, consultez Unified Pricing: attribution de licence Test Manager.

Associé

• Fonctionnement de la capture d’artefacts Playground
• Empaqueter des projets Playground pour Test Manager
• Configuration de la capture d’artefacts pour les tests Playground
• Sélectionner l'automatisation