- Notes de publication
- Démarrage
- Paramétrage et configuration
- Projets d'automatisation
- Dépendances
- Types de workflows
- Comparaison de fichiers
- Meilleures pratiques d'automatisation
- Intégration du contrôle de code source
- Débogage
- L'outil de diagnostic (Diagnostic Tool)
- Analyseur de workflow
- À propos de l'analyseur de workflow
- ST-NMG-001 - Convention d'affectation de noms des variables
- ST-NMG-002 - Convention d'affectation de noms des arguments
- ST-NMG-004 - Duplication du nom complet
- ST-NMG-005 - La variable remplace une autre
- ST-NMG-006 - La variable remplace l'argument
- ST-NMG-008 - Longueur de variable dépassée
- ST-NMG-009 - Ajouter un préfixe aux variables DataTable
- ST-NMG-011 - Ajouter un préfixe aux arguments Datatable
- ST-NMG-012 - Valeurs par défaut de l'argument
- ST-NMG-016 : longueur d'argument dépassée
- ST-DBP-002 - Nombre élevé d'arguments
- ST-DBP-003 - Bloc d'interception vide
- ST-DBP-007 - Plusieurs couches de l'organigramme
- ST-DBP-020 - Propriétés de sortie non définies
- ST-DBP-023 : Workflow vide
- ST-DBP-024 - Vérification de l’activité de persistance
- ST-DBP-025 - Condition préalable à la sérialisation des variables
- ST-DBP-026 - Utilisation de l’activité Délai
- ST-DBP-027 - Pratiques exemplaires de persistance
- ST-DBP-028 - Condition préalable à la sérialisation des arguments
- ST-MRD-002 - Valeurs par défaut des noms d'activités
- ST-MRD-004 - Activités inaccessibles
- ST-MRD-005 - Séquences redondantes
- ST-MRD-007 - Clauses If imbriquées
- ST-MRD-008 - Séquence vide
- ST-MRD-009 - Activités profondément imbriquées
- ST-MRD-011 - Utilisation de la ligne d'écriture
- ST-MRD-017 - Incomplet si (Incomplete If)
- ST-USG-005 - Arguments d'activité codée en dur
- ST-USG-009 - Variables inutilisées
- ST-USG-010 - Dépendances inutilisées
- ST-USG-014 - Restrictions sur les paquets (Package Restriction)
- ST-USG-020 - Nombre minimum de messages consignés
- ST-USG-024 - Non utilisé, sauvegardé pour plus tard (Unused Saved for Later)
- ST-USG-025 - Utilisation abusive de la valeur enregistrée (Saved Value Misuse)
- ST-USG-026 - Restrictions d'activité (Activity Restrictions)
- ST-USG-027 - Packages requis
- Variables
- Arguments
- Noms d'espace importés
- Flux de contrôle
- Réf. d’objets
- Journalisation
- L'outil de migration MiseAlEchelleCoordonnees (ScaleCoordinates)
- Outil ScreenScrapeJavaSupport
- StudioPro
- Extensions
- Résolution des problèmes
- Internet Explorer x64
- Problèmes d'interopérabilité avec Microsoft Office
- Identification des éléments d'IU dans PDF avec options d'accessibilité
- Identification des éléments d'IU après les mises à jour de Windows
- Applications JxBrowser
- Surveillance des événements utilisateur
- Java dans App-V
- Prise en charge et limitations de Microsoft App-V
- Résolution des problèmes Citrix
Le test RPA est conçu pour tester directement les workflows et afficher la couverture de l’activité pendant l’exécution. Ces processus de test garantissent que l’exécution est effectuée et que tous les cas importants sont couverts, quelles que soient les décisions prises lors de l’exécution.
Créer un cas de test
An RPA Testing file can be created by invoking a workflow from the project. Right-click a workflow in the Project panel and select Create Test Case or Data Driven Test Case:
You can select Mock workflow under test when you create your test case if you want to make a copy of your workflow where you can mock specific activities. For more information, see Mock Testing.
Un cas de test .xaml est créé, invoque le workflow et a trois conteneurs supplémentaires : Given, When, et Then. Le fichier est invoqué à l’intérieur de l’activité Invoquer un fichier de workflow, qui fait partie du conteneur When.
Les arguments du workflow sont automatiquement importés. Pour afficher ou ajouter d’autres arguments, cliquez sur le bouton Importer des arguments faisant partie de l’activité Invoquer un fichier de workflow.
Couverture de l'activité
Pour vérifier la couverture d’activité du flux de travail, déboguez le cas de test nouvellement créé et affichez les cas de test couverts et non couverts dans le panneau Couverture de l'activité (Activity Coverage).
Lors de l’exécution de cette action dans notre exemple, nous avons reçu la couverture suivante :
Selon le message, ce cas de test ne couvrait que 53 % des activités du workflow. Selon vos besoins d’automatisation, vous pouvez créer des cas de test distincts pour couvrir chaque scénario pendant l’exécution. Par exemple, le flowchart ci-dessus utilise une activité Flow Switch. Nous pouvons alors créer un autre cas de test pour suivre l’exécution d’un autre scénario, comme dans le cas des prêts à faible volume.
Une autre façon serait de créer un cas de test pour couvrir toutes les sections du workflow. Pour notre workflow, nous avons décidé d’utiliser un ensemble distinct de données pour tester toutes les activités. Par conséquent, nous avons importé des données d'un fichier .csv et nous avons utilisé une activité Pour chaque pour les transmettre à travers chaque activité dans le workflow :
Lors du débogage, un taux de couverture d’activité de 100 % a été atteint, ce qui signifie que l’ensemble de données utilisé dans le cas de test, ainsi que les activités ajoutées, couvraient tous les scénarios possibles du projet.
Publier les cas de test
Test cases are packaged only if they are Set as Publishable. In the Project panel, right-click a test case and select Set as Publishable. Read more about setting test cases as publishable here.
La publication est effectuée en cliquant sur les options de ruban Publier ou Publier les cas de test :
-
Publier - publie l’ensemble du projet avec des cas de test;
-
Publish Test Cases - publishes the project as a test case to be managed from Orchestrator's Test Cases page.