- Démarrage
- À propos de Test Manager
- Actions d'Autopilot
- À propos du chat Autopilot (agent)
- À propos du masquage des informations personnelles
- Démarrage
- Disponibilité de la fonctionnalité Test Manager
- Tarification unifiée : Test Manager de licence
- Flex : Test Manager de licence
- Guide de démarrage rapide
- Types de test dans Test Manager
- Gestion de projet
- Documents
- Travailler avec l’analyse de l’impact des modifications
- Créer des scénarios de test
- Affectation de cas de test aux exigences.
- Clonage des cas de test
- Exporter des cas de test
- Lier des cas de test à Test Manager dans Studio
- Delete test cases
- Cas de test manuels
- Documenter les cas de test avec Task Capture
- Paramètres
- Playwright test case fields
- Activation de la gouvernance au niveau du projet
- Désactivation de la gouvernance au niveau du projet
- Activation de la gouvernance au niveau des cas de test
- Désactivation de la gouvernance au niveau du cas de test
- Gérer les approbateurs pour les cas de test régis
- Gérer les cas de test régis à l’état En cours
- Gérer les cas de test régis à l’état En révision
- Gérer les objets régis à l'état Signé
- Gérer les commentaires pour les cas de test régis
- Appliquer des filtres et des vues
- Importer des ensembles de test Orchestrator
- Creating test sets
- Ajouter des cas de test à un ensemble de test
- Attribuer des utilisateurs par défaut dans l'exécution de l'ensemble de tests
- Activation de la couverture des activités
- Activer Healing Agent
- Configuration d'ensembles de test pour des dossiers et des robots d'exécution spécifiques
- Remplacer les paramètres
- Cloner des ensembles de tests
- Exporter des ensembles de tests
- Appliquer des filtres et des vues
- FAQ - Parité des fonctionnalités - Test Manager vs Orchestrator
- Exécution de tests manuels
- Exécuter des tests automatisés
- Exécuter des cas de test sans ensemble de tests
- Exécuter des tests mixtes
- Créer des exécutions en attente
- Appliquer un ordre d’exécution
- Réexécution des exécutions de test
- Planification des exécutions
- Résoudre les problèmes des exécutions automatisées
- Tests d'accessibilité pour Test Cloud
- Opérations et utilitaires de projet
- Paramètres de Test Manager
- Intégration de l'outil de gestion du cycle de vie des applications (ALM)
- Intégration de l'outil de gestion du cycle de vie des applications (ALM)
- Connecté à Test Manager
- Test Manager - Connecteur Integration Service
- Intégration de l'API
- Agents de codage pour les tests
- Résolution des problèmes
Options de paramètres pour les cas de test dans Test Manager, y compris une limite de 250 paramètres, des règles d'unicité de nomination et des contraintes de type String.
Création de paramètres
Vous pouvez créer des paramètres pour chaque cas de test d'un ensemble de test. Vous pouvez ajouter un nombre maximum de 250 paramètres, chacun devant avoir un nom unique dans le contexte d'un cas de test.
Les paramètres ne peuvent être que de type String.
- Ouvrez le cas de test auquel vous souhaitez ajouter des paramètres.
- Accédez à l'onglet PARAMÈTRES (PARAMETERS).
- Sélectionnez Créer un paramètre et remplissez les champs ci-dessous :
- Nom : donnez au paramètre un nom unique.
Lorsque vous nommez le paramètre, vous pouvez utiliser des lettres, des chiffres, des espaces et les caractères suivants : -, _, ,, et ..
Par exemple, nommez le paramètre adminName. 2. Valeur par défaut - Saisissez la valeur par défaut du paramètre.
N'oubliez pas que les paramètres ne peuvent être que de type String.
Ce champ Valeur par défaut n'est pas obligatoire. Par conséquent, si vous le laissez vide, le paramètre sera une chaîne vide.
Par exemple, définissez la valeur par défaut sur JohnDoe. 3. Suggestion : offre des informations supplémentaires sur les informations contenues dans le paramètre.
Pour cet exemple, ajoutez la suggestion suivante : The supervisor of the organization.
- Sélectionnez Créer pour créer le paramètre.
Les paramètres que vous créez dans l'onglet Paramètres d'un cas de test ne peuvent actuellement être utilisés que pour les exécutions de test manuelles.
Modification des paramètres
Après avoir créé des paramètres, vous pouvez les modifier en fonction de votre cas d'utilisation.
- Ouvrez le cas de test pour lequel vous souhaitez modifier un paramètre.
- Accédez à l'onglet PARAMÈTRES (PARAMETERS).
- Sélectionnez Modifier à côté du paramètre que vous souhaitez modifier.
- Dans la fenêtre Modifier le paramètre , mettez à jour les champs que vous souhaitez modifier.
- Sélectionnez Enregistrer (Save) pour enregistrer les modifications.
Utilisation de paramètres dans les tests manuels
Vous pouvez utiliser des paramètres dans les tests manuels ou automatisés avec les valeurs par défaut que vous avez définies pour chaque cas de test. Ou vous pouvez remplacer les valeurs de paramètres par défaut des cas de test au sein d'un ensemble de tests. Pour de plus amples informations sur le remplacement des valeurs de paramètres, consultez la section Remplacer les paramètres.
Manual test cases support only a single default value per parameter. There is no built-in way to define multiple value sets (an iteration or parameter table) for one manual test case. To run a manual test case against different parameter values, create separate test sets, each overriding the parameter to a different value for that test case.
- Créez un cas de test.
- En fonction du type d’exécution que vous souhaitez utiliser, procédez comme suit :
- Exécution manuelle:
- Accédez à l'onglet Étapes manuelles et ajoutez des étapes manuelles.
- Pour référencer les paramètres dans les étapes manuelles, saisissez leur nom entre doubles crochets.
- Exécution manuelle:
Par exemple, pour ajouter le paramètre username dans une étape manuelle, référencez-le en tant que {{username}}.
- Exécution automatisée: lors de l'exécution automatisée d'un ensemble de test, les arguments Studio de l'automatisation (correspondant à chaque cas de test) sont automatiquement appliqués (en tant que paramètres) dans Test Manager, au niveau de l'ensemble de test pour chaque cas de test ajouté dans l'ensemble de test .
Pour les exécutions automatisées, les arguments Studio sont réaffichés dans la vue Remplacer les paramètres au niveau de l'ensemble de tests. Ils n'apparaissent pas dans l'onglet Paramètres d'un cas de test individuel, qui est réservé aux paramètres que vous créez manuellement dans Test Manager.
Les paramètres de Test Manager sont toujours de type String. Pour cette raison, les données sont transmises de Test Manager à un argument Studio uniquement lorsque cet argument est également de type Chaîne. Si l'argument de Studio utilise un type de données différent, la valeur n'est pas transmise, même si les noms correspondent.
Test Manager parameters do not automatically map to Studio arguments, even when the names match, and there is no global variable shared across test cases in a test set. Arguments, defined in Studio and overridable at the test-case or test-set level, are the supported mechanism for passing values between test cases. Test Manager does not aggregate test-case data at the test-set level natively; for test-set-level reporting, use an external reporting tool.
Best practices for test case arguments and data
Managing larger or variable datasets
If input values are extensive or need to vary across test runs, use data-driven testing instead of manually maintained parameters. Test Manager supports data-driven testing using Excel files. UiPath Data Service or Test Data Queues (managed through Orchestrator) can also be used for structured data and dependencies.
Data Fabric/Data Service linked test data
When a Data Fabric/Data Service entity is linked as test data, each row becomes its own test variation. Test Manager does not support grouping multiple rows into a single logical variation. If one variation needs several related records (for example, a transaction with multiple line items), use a parent record as the variation driver, then use activities in the workflow to query the related child records from Data Fabric at runtime (for example, by a shared ID).
Interdependent test cases
For test cases where one test case's output feeds another's input, use an external data store rather than relying on in-memory dependencies between test cases, for example:
- Orchestrator Assets
- Data Service
- Files d'attente de données de test
- An external database or file
If reuse in memory is critical, combine the relevant logic into a single workflow or test case instead.
Résultat
Le paramètre est créé et disponible dans l'onglet Paramètres du cas de test. Pour les exécutions manuelles, vous pouvez référencer le paramètre dans les étapes manuelles à l'aide de doubles accolades et la valeur est appliquée lors du runtime.