Automatisation de test

Pour tirer le meilleur parti de vos efforts de test, tenez compte des bonnes pratiques d'automatisation des tests suivantes, basées sur les tests d'application ou RPA.

Test d'application

• Utilisez le modèle Test Automation Framework pour implémenter des projets d’automatisation stables et évolutifs.
• Les cas de test doivent être indépendants les uns des autres. Un cas de test ne doit pas dépendre de l'exécution d'un autre cas de test.
• Un cas de test ne doit avoir qu'un seul objectif spécifique. Chaque workflow de test ne doit contenir qu'une seule vérification.
• Chaque fonctionnalité doit avoir un test unitaire. Si des exceptions sont autorisées, créez un test distinct pour chaque cas de test, ainsi qu’une exception.
• Dans une structure de cas de test Given-When-Then, si la partie Given devient trop étendue et ingérable, essayez de redéfinir le cas de test. Cela pourrait nécessiter plus de granularité ou de reformulation.
• Gérez les cas de test et mettez-les à jour après toute demande de changement.
• Envisagez d'établir une logique de gestion des tests pour disposer d'une manière unique de définir les cas de test.
• Pour augmenter la réutilisabilité entre les projets de test individuels, ainsi qu'entre les projets de test et RPA, essayez d'utiliser les bibliothèques et le référentiel d'objets, dans la mesure du possible.
• Incluez les tests dans le pipeline CI/CD.
• Les tests fonctionnels dans le cadre de votre pipeline CI doivent être exécutés aussi rapidement que possible afin de ne pas retarder votre build. Par conséquent, essayez d'exécuter ces tests en parallèle sur autant de Robots que possible.
• Les noms d'activité doivent refléter l'action entreprise. Pour les comportements non évidents, pensez à utiliser des annotations sur vos activités.
• Envisagez d'utiliser une journalisation détaillée et la gestion des exceptions pour déboguer le processus et éviter les faux résultats négatifs.
• Planifiez la récupération ou les nouvelles tentatives en cas d'erreur à différentes étapes pour éviter les échecs.
• Envisagez d'avoir une structure de dossiers dédiée aux tests et d'utiliser la même convention d'affectation de noms aux cas de test dans tous vos projets.
• Utilisez des ressources pour les variables susceptibles de changer et utilisées plusieurs fois.
• Dans les scénarios où l’état d’une application doit être validé avant de passer à certaines étapes d’un processus, envisagez d’appliquer des mesures de validation. Ces mesures peuvent inclure l’utilisation d’activités supplémentaires qui attendent que l’application passe à l’état souhaité avant d’effectuer d’autres interactions (les délais codés en dur ne sont pas considérés comme une bonne pratique).
• Envisagez d'utiliser un simulateur de clic/saisie de texte ou d'envoyer des messages Windows, dans la mesure du possible.
• Ne supprimez pas, ne déplacez pas et ne renommez pas les cas de test en dehors de Studio. Effectuez ces actions dans Studio uniquement. Utilisez Importer des cas de test (Import Test Cases) au cas où un cas de test d'un autre projet devrait être référencé.

Test RPA

• Les cas de test doivent être indépendants les uns des autres. Un cas de test ne doit pas dépendre de l'exécution d'un autre cas de test.
• Envisagez de créer de petits workflows qui gèrent le plus petit nombre d'actions possible. Cela facilitera la compréhension et permettra d'effectuer des tests unitaires.
• Un cas de test ne doit avoir qu'un seul objectif spécifique. Chaque workflow de test ne doit contenir qu'une seule vérification.
• Chaque fonctionnalité doit avoir un test unitaire. Si des exceptions sont autorisées, créez un test distinct pour chaque cas de test.
• Pour augmenter la réutilisabilité entre les projets de test individuels, ainsi qu'entre les projets de test et RPA, essayez d'utiliser les bibliothèques et le référentiel d'objets, dans la mesure du possible.
• Dans une structure de cas de test Given-When-Then, si la partie Given devient trop étendue et ingérable, essayez de redéfinir le cas de test. Cela pourrait nécessiter plus de granularité ou de reformulation. La modularité est la clé d’un bon test unitaire. Les tests d’écriture peuvent permettre d’obtenir des commentaires/d’examiner le code par rapport au développement.
• Utilisez la simulation chaque fois que des étapes complexes sans rapport avec l'objectif du cas de test peuvent être remplacées.
• Envisagez d'établir une logique de gestion des tests pour disposer d'une manière unique de définir les cas de test.
• Gérez les cas de test et mettez-les à jour après toute demande de changement.
• Incluez les tests dans le pipeline CI/CD.
• Exécutez vos cas de test chaque fois que vous validez une modification de votre RPA pour vous assurer que vous n'avez pas introduit de bogue.
• Préparez un ensemble de test RPA pouvant être exécuté par le service informatique dans un environnement de pré-production chaque fois qu'il prévoit de déployer un changement d'environnement (comme une mise à jour Windows) afin que vous puissiez détecter les problèmes potentiels avant qu'ils n'affectent la production.
• Les noms d'activité doivent refléter l'action entreprise. Pour les comportements non évidents, pensez à utiliser des annotations sur vos activités.
• Planifiez la récupération ou les nouvelles tentatives en cas d'erreur à différentes étapes pour éviter les échecs.
• Envisagez d'avoir une structure de dossiers dédiée aux tests et d'utiliser la même convention d'affectation de noms aux cas de test dans tous vos projets.
• Utilisez des ressources pour les variables susceptibles de changer et utilisées plusieurs fois.
• Dans les scénarios où l’état d’une application doit être validé avant de passer à certaines étapes d’un processus, envisagez d’appliquer des mesures de validation. Ces mesures peuvent inclure l’utilisation d’activités supplémentaires qui attendent que l’application passe à l’état souhaité avant d’effectuer d’autres interactions (les délais codés en dur ne sont pas considérés comme une bonne pratique).
• Envisagez d'utiliser un simulateur de clic/saisie de texte ou d'envoyer des messages Windows, dans la mesure du possible.
• Ne supprimez pas, ne déplacez pas et ne renommez pas les cas de test en dehors de Studio. Effectuez ces actions dans Studio uniquement. Utilisez Importer des cas de test (Import Test Cases) au cas où un cas de test d'un autre projet devrait être référencé.

Test RPA des automatisations Attended

Dans la rubrique suivante, vous pouvez apprendre à effectuer des tests RPA de vos automatisations Attended en fonction de scénarios de test spécifiques.

Remarque : assurez-vous que vous disposez d’une licence fonctionnelle pour Orchestrator et Test Manager.

Tests d'acceptation Attended User

Qui effectue les tests	Procédure de test	Capture des résultats de test	Exigences de licence
• Testeurs manuels • UAT ou PME commerciales	L’équipe AQ définit les cas de tests manuels dans Test Manager comme suit : a. Étapes prérequises b. Exécution de l'automatisation c. Assertions Les testeurs UAT exécutent un cas de test manuel dans Test Manager. Les testeurs UAT préparent l'environnement pour l'automatisation Attended en fonction du scénario spécifique qui doit être testé, comme défini dans l'étape prérequise 1a. Les testeurs UAT exécutent l’automatisation Attended via l’Assistant UiPath®. Les testeurs UAT vérifient les assertions après l'exécution de l'automatisation.	Les résultats, y compris les captures d’écran et les documents, sont disponibles pour le testeur UAT dans Test Manager.	Le testeur UAT nécessite une licence d'automatisation Attended. Vous pouvez gérer vos licences en fonction de votre type de déploiement : • Installation locale Vous pouvez résoudre ce problème selon deux scénarios : • Publiez les packages d'automatisation dans votre environnement de production Orchestrator qui dispose d'une licence d'automatisation Attended allouée pour le testeur UAT. • Attribuez un sous-ensemble de licences d'utilisateurs Attended à votre environnement de non-production Orchestrator.

Tests de régression Unattended

Qui effectue les tests	Procédure de test	Capture des résultats de test	Exigences de licence
Robot de test Unattended.	L’équipe AQ définit les cas de test dans Test Manager comme suit : a. Étapes prérequises b. Exécution de l'automatisation c. Assertions Les développeurs d'automatisation créent des cas de test sur des automatisations existantes. Les actions assistées des utilisateurs sont simulées via . Les développeurs d’automatisation lient les cas de test de Studio à Test Manager. Les développeurs d'automatisation publient des cas de test sur Orchestrator, puis les regroupent dans des ensembles de test (en fonction des besoins métier). Les tests Unattended peuvent être exécutés manuellement via Orchestrator et Test Manager, ou en les planifiant dans Orchestrator. (Facultatif) Si des outils CI/CD sont disponibles, ils peuvent être exploités pour des tests et un déploiement entièrement automatisés. UiPath fournit l'intégration CI/CD via les éléments suivants : • Extension Azure DevOps • Plug-in Jenkins	Les robots de test Unattended fournissent des détails et des événements d'exécution.	Runtimes Testing