Septembre 2026

Notes de version de septembre 2026 pour Test Manager dans Automation Cloud et Test Cloud.

4 septembre 2026

Automatisation des tests Playground

Test Manager peut désormais exécuter des cas de test s'appuyant sur des automatisations Playwwrite , ainsi que des automatisations créées par Studio, sans réécrire les suites Playwwrite existantes dans Studio. Cette fonctionnalité est en disponibilité contrôlée, fournie uniquement aux locataires éligibles et est disponible dans Test Manager uniquement lorsqu’elle est fournie via Test Cloud.

Packaging and linking

• Une nouvelle commande uip tm pack Interface de ligne de commande empaquète un projet Node.js Playwwrite dans un package d’automatisation UiPath, publiable dans Orchestrator comme n’importe quel autre package.
• Les cas de test Test Manager sont créés automatiquement et liés automatiquement directement à partir de vos test() blocs une fois que Test Manager a ingéré un package créé avec une clé de projet.
• Les automatisations Playwight peuvent être sélectionnées, mises à jour et dissociées via les flux d'automatisation Sélectionner l'automatisation et Dissocier l'automatisation - Les packages Playwight affichent une Source de Playwdroit aux côtés de UiPath Studio.
• Les nouveaux libellés du système PW_ gérés automatiquement permettent de rechercher et de filtrer sans affecter vos propres libellés.

Execution and reporting

• L'exécution d'un ensemble de tests peut être étendue à un ou plusieurs projets Playwight via la nouvelle liste déroulante Projets Playground lors de l’ajout d’un package à un ensemble de tests; chaque exécution bloque la sélection de son paquet, de sa version et de son projet sous forme d'instantané pour une réexécution fiable.
• Deux nouveaux onglets sur les journaux de cas de test Playwight: Tentatives pour le contexte d’erreur par tentative rendu en ligne, et Trace pour une visionneuse de traçage Playwwrite intégrée avec les journaux de la console, les appels réseau et les pièces jointes téléchargeables.
• Gestion des réessais: un test qui échoue puis réussit un réessai est enregistré comme Réussi, avec la ou les tentatives échouées toujours visibles dans l'onglet Tentatives et wasFlaky: true enregistré dans la pièce jointe des résultats par test.
• Aucun changement de licence: les exécutions Playwight consomment la même capacité de la plateforme que toute autre exécution de test sans serveur, en fonction du temps d’exécution.

Execution constraints

• Exécution avec Chromium uniquement et sans serveur uniquement; Projets Node.js Playground uniquement.
• Une tâche Orchestrator par exécution d'ensemble de tests, sans partition multi-pods.
• Aucun ordre d’exécution appliqué — l’ordre suit playwright.config.ts.
• Il est bloqué dans un même ensemble de tests. Il est bloqué dans un même ensemble de tests.
• L'ajout d'une variation de cas de test centrée sur les données à un ensemble de test exécute toutes ses variations générées.

Pour plus d’informations, consultez la section Automatisation de test Playwork.

3 septembre 2026

Données du Presse-papiers disponibles en tant qu'argument d'outil MCP sur les étapes de test

Les outils du protocole MCP de Test Manager pour l’ajout et la mise à jour des étapes de test (Ajouter des étapes de test en bloc, Mettre à jour en bloc les étapes de test) acceptent un argument de données du Presse-papiers facultatif, correspondant au champ déjà disponible dans l’interface utilisateur de Test Manager.

Cela vous permet de définir ou de mettre à jour les données du Presse-papiers d’une étape par programmation, par exemple lors de la génération de cas de test avec une entrée variable via Autopilot Chat ou Delegate, sans revenir à UI Automation. Les appelants existants qui omettent l'argument ne sont pas affectés.

Pour de plus amples informations, reportez-vous à la section Cas de test manuels de la documentation.

Nouvelles activités dans le connecteur Integration Service – Test Manager

Le package d'activités du connecteur UiPath Test Manager ajoute sept nouvelles activités:

• Créer une étape de test – Crée une étape de test pour un cas de test.
• Get Requirements (Obtenir les exigences) : obtient toutes les exigences d'un projet.
• Obtenir les cas de test – Obtient tous les cas de test d'un projet.
• Obtenir les exécutions de test : permet d'obtenir toutes les exécutions de test pour un projet.
• Get Test Sets (Obtenir des ensembles de tests): obtient tous les ensembles de tests d'un projet.
• Obtenir l'étape de test – Obtient une étape de test par ID.
• Mettre à jour l'étape de test – Met à jour les détails d'une étape de test, tels que la description et le résultat attendu.

Pour de plus amples informations, reportez-vous à la page des activités UiPath Test Manager dans la documentation.

Refonte de la page des exigences

La page des détails de l’exigence a été repensée avec les modifications suivantes:

• La barre d'outils expose Évaluer l'exigence et Attribuer un cas de test (regroupant Créer un nouveau cas de test, Attribuer un cas de test existant, Générer des cas de test et Trouver des tests obsolètes) en tant qu'actions directes, avec Optimiser la couverture, qui est conservé comme point d'entrée en double sans date de retrait actuellement défini.
• Le champ de description utilise un éditeur de texte enrichi au lieu de la syntaxe Markdown et affiche Aucune description ajoutée lorsqu’il est vide.
• Les libellés, les champs personnalisés, les pièces jointes et les métadonnées d'audit (Créé par / Mis à jour par) sont réorganisés dans la vue d'ensemble des exigences.

La vue d'ensemble utilise une mise en page réactive qui empile le contenu secondaire sous la zone principale à des largeurs plus réduites.

Les cas de test attribués bénéficient des options Vue de la grille et Vue de la liste . La vue Liste utilise un défilement virtuel, charge les cas de test par lots de 500 et affiche des indicateurs compacts de dernier résultat (Réussi, Échec, Aucun résultat). Vous pouvez filtrer les cas de test attribués, y compris par dernier résultat, et sélectionner un ou plusieurs fichiers pour les désaffecter ou les supprimer en bloc. Les cas de test ne peuvent toujours pas être exécutés directement à partir d’une exigence.

Pour de plus amples informations, reportez-vous à la section Exigences de la documentation.

Lecture et copie plus faciles des messages du journal complet dans les exécutions de test

Les messages de journal du robot longs ou tronqués dans l'onglet Journaux d'une exécution de test étaient difficiles à lire entièrement et ne pouvaient pas être copiés.

L'onglet Journaux comporte une colonne Info : sélectionnez l'icône d'information sur n'importe quelle ligne du journal pour ouvrir son message complet dans une fenêtre contextuelle, avec un bouton Copier le message .

L'onglet Journaux bénéficie également de la recherche et du tri des messages dans la colonne Niveau , ainsi que d'un filtre Niveau qui affiche uniquement les niveaux de journalisation qui vous intéressent:

• Trace (All)
• Info + Warn + Error + Fatal
• Warn + Error + Fatal
• Error + Fatal
• Critique

Pour de plus amples informations, reportez-vous à la section Analyse des résultats de test de la documentation.

Résolution de bogues

• Correction de ObjectLabels demandes d'ajout/de suppression en bloc avec une valeur objectType non valide ou non prise en charge (associee à une liste vide ou supérieure à la limite d'ID d'objet) renvoyant une erreur 500 au lieu de 400 Bad Request avec un message de validation. (TMMH-32720)
• Correction de ObjectFilters requêtes de création/d'affectation avec une erreur filterExpression incorrecte (type JSON incorrect ou nul) renvoyant une erreur 500 au lieu de 400 Bad Request avec un message de validation. (TMMH-32720)
• Correction des corps de demande malformés avec des champs saisis de manière incorrecte (par exemple, une valeur search envoyée sous forme de tableau au lieu d'une chaîne) renvoyant une erreur 500 au lieu de 400 Bad Request, dans les points de terminaison de l'API Test Manager. (TMMH-32720)