Infrastructure d'automatisation des test

Vue d'ensemble (Overview)

L'infrastructure d'automatisation des test est un modèle qui fournit une base pour les projets de test en intégrant les meilleures pratiques essentielles. L'infrastructure comprend des fonctionnalités de gestion des ressources, des constantes, de la journalisation et de la gestion des exceptions.

Mode de fonctionnement

Le modèle suit trois phases consécutives :

1. SetUp (SetUp.xaml) — Cette phase lit le fichier Assets.json et initialise les applications utilisées dans le processus. Si l'initialisation est réussie, l'exécution passe à la phase Exécuter le test. En cas d'échec, l'exécution se termine et un cas de test échoue, générant une capture d'écran disponible dans Orchestrator.
   
   

   

   
   
   1. InitAllAssets.xaml— Cette phase initialise, remplit et génère un dictionnaire de configuration, Ressources (Assets), qui est utilisé tout au long du projet. Les ressources sont récupérées à partir d'Orchestrator.
2. Exécuter le test (espace réservé pour le cas de test) : c'est au cours de cette phase que le scénario de test est exécuté. L'activité Placeholder (Espace réservé) se transforme au moment du runtime en activité Appeler le fichier de flux de travail (Invoke Workflow File. Cette activité appelle ensuite le cas de test avec le modèle d'exécution qui lui est attaché. Cela crée un fichier de workflow temporaire appelé Generated – testCaseName. Le cas de test est encapsulé dans une étendue avec délai d'expiration (Timeout Scope) dont la valeur d'entrée Générer une exception après (Throw Exception After) est définie sur la constante TestTimeOut. Si l'exécution du cas de test dépasse TestTimeOut, l'exécution s'arrête. Ceci est utile dans le cas où un processus se retrouve dans une boucle infinie, car il arrête l'exécution afin que le robot puisse être libéré.
   
   

   

   
   
3. Nettoyage (TearDown.xaml) : cette phase finalise l'exécution du cas de test et effectue les actions nécessaires pour nettoyer l'environnement en vue des exécutions futures.
   
   

   

   
   
   1. KillAllProcesses.xaml : force l'arrêt d'un processus Windows qui représente une application utilisée dans le processus métier. Cependant, l'arrêt des processus peut entraîner des résultats indésirables, tels que la perte des modifications non enregistrées des fichiers. Malgré le nom de ce workflow, il n'est pas obligatoire de toujours forcer l'arrêt de tous les processus utilisés. D'autres étapes peuvent être plus appropriées pour rétablir l'état du système, en fonction des exigences du processus métier.
4. TakeScreenshots.xaml : prend une capture d'écran de tout l'écran et l'enregistre au format .PNG dans un dossier spécifié par l'argument in_Folder. Vous pouvez invoquer cette phase partout où vous en avez besoin dans le workflow.

Personnalisation du modèle

Pour configurer le modèle en fonction de votre cas d'utilisation spécifique, procédez comme suit :

1. Dans le dossier Données (Data), ouvrez le fichier Assets.json et ajoutez les ressources Orchestrator auxquelles vous devez accéder.
   
   

   

   
   
   Remarque : Utilisez le fichier Assets.json pour tout type de ressources, à l'exception des informations d'identification. Pour utiliser les ressources d'identification définies dans Orchestrator, ajoutez-les plutôt en tant que constante.
2. Dans le gestionnaire de données, sous Constantes (Constants), ajoutez les ressources d'identification que vous souhaitez utiliser. Pour y accéder, ajoutez une activité Obtenir les informations d'identification (Get Credential).
   Astuce : Si la ressource d'informations d'identification est stockée dans un dossier Orchestrator différent de celui dans lequel le processus est en cours d'exécution, créez une autre constante pour stocker le nom du dossier.
3. Modifiez la constante TestTimeOut pour modifier le temps d'exécution autorisé d'un cas de test.

Les dépendances par défaut de ce modèle de projet sont UiPath.System.Activities, UiPath.UIAutomation.Activities et UiPath.Testing.Activities.