- Premiers pas avec Test Suite
- Vue d'ensemble (Overview)
- Automatisation de test
- Studio
- Vue d'ensemble (Overview)
- Activités et API de test
- Orchestrator
- Testing Robots
- Test Manager
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.
- 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é.
- 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é.
Dans la rubrique suivante, vous pouvez apprendre à effectuer des tests RPA de vos automatisations Attended en fonction de scénarios de test spécifiques.
|
Qui effectue les tests |
Procédure de test |
Capture des résultats de test |
Exigences de licence |
|---|---|---|---|
|
• Testeurs manuels • UAT ou PME commerciales |
|
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 : 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. |
|
Qui effectue les tests |
Procédure de test |
Capture des résultats de test |
Exigences de licence |
|---|---|---|---|
| Les robots de test Unattended fournissent des détails et des événements d'exécution. | Runtimes Testing |
