Adopter la solution Agilitest pour créer et maintenir un référentiel de tests automatisés est un processus en plusieurs étapes. Plusieurs de nos articles et pages de documentation technique traitent du processus de démarrage, ou de notre approche préférée pour la robustesse et la maintenabilité des tests.
Cet article aborde spécifiquement une étape obligatoire lorsque vous avez déjà choisi Agilitest et que vous souhaitez intégrer la solution dans votre environnement de production pour l'exécution des tests : quelle architecture utiliser pour l'exécution massive des tests, quels types de matériel et quelles technologies logicielles utiliser ?
Que faut-il faire pour exécuter un test produit avec Agilitest ?
Agilitest est un logiciel qui fonctionne sous le système d'exploitation Microsoft, dans sa version bureau, Windows 10, et dans sa version serveur, Windows Server 2016 et 2019.
Avant d'exécuter un test, il faut d'abord disposer d' un scénario de test au format ATS créé avec Agilitest. Ce scénario de test ATS peut être compilé et intégré dans une suite d'exécution TestNG grâce à Agilitest pour plus de facilité, même si cela est possible sans.
Deux possibilités principales existent pour exécuter un ou plusieurs tests :
- lancer une ligne de commande liée à une exécution TestNG
- utilisation par Jenkins d'un fichier de configuration Maven pom.xml généré dans Agilitest
L'environnement d'exécution d'un test consiste en une session utilisateur Windows ouverte dans laquelle le test est exécuté.
Lors de l'exécution du test, le logiciel à tester sera lancé et toutes les étapes fonctionnelles défileront à l'écran comme si un utilisateur virtuel effectuait les actions avec son clavier et sa souris.
Ensuite, les conditions préalables dépendent de l'adresse canal ou des canaux utilisés dans le scénario de test automatisé : bureau, web, webservice, iOS, Android.
Exécution des tests sur le bureau
La première étape d'un test de bureau consiste à lancer le logiciel à tester, le plus souvent sous la forme d'un fichier .exe à ouvrir. ATS et Agilitest peuvent s'en charger, mais il est également possible de se connecter à un processus en cours d'exécution lorsque cela est absolument nécessaire.
Une session graphique Windows est requise pour les tests sur le bureau.
Exécution de tests web
L'environnement d'exécution d'un test web est plus prévisible que celui d'un test de bureau puisque la première étape consiste toujours à lancer un navigateur pris en charge : Chrome, Firefox, Chromium-based Edge, Opera ou Internet Explorer.
Une session graphique Windows est requise pour les tests web.
Exécution de tests de webservices
L'utilisation d'un site webservice par le biais de requêtes HTTP est une opération de niveau inférieur à l'utilisation d'un logiciel avec une interface graphique.
Par conséquent, une session de console Windows peut être suffisante pour effectuer un test de webservices.
Bien qu'il ne soit pas indispensable de disposer d'un environnement de bureau graphique dans ce cas, cela est fortement recommandé afin de bénéficier de l'aspect multicanal d'Agilitest.
Exécution de tests mobiles Android et iOS
La première étape de la réalisation d'un test mobile consiste à lancer une application sur un mobile donné. Il est donc important d'être rigoureux dans la configuration de votre système, avec par exemple un plan d'adressage IP stable pour les mobiles ou les émulateurs.
Les mobiles physiques devront être reliés par un câble USB et connectés au même réseau que la machine qui effectue le test.
Les mobiles émulés dans le cloud Genymotion nécessitent simplement une connexion Internet fonctionnelle. Cette solution est très facile à utiliser, et permet d'exécuter les tests sur n'importe quelle machine Windows, virtualisée ou dans le cloud, sans jamais avoir besoin d'une ferme de mobiles physique.
Une session graphique Windows est toujours nécessaire, notamment pour pouvoir générer des rapports de test avec des captures d'écran, et rejouer des vidéos.
Que faut-il faire pour rejouer les tests de manière intensive ?
La session de l'utilisateur, composant principal de la chaîne d'exécution
Une condition préalable essentielle pour l'exécution d'un test Agilitest est la présence d'une session graphique Windows.
Il est formellement déconseillé d'exécuter deux tests en parallèle dans la même session utilisateur, d'une part pour éviter toute interférence entre les tests, d'autre part parce que cela ne constitue pas un modèle d'utilisation fonctionnel réaliste. Même un scénario fonctionnel riche censé reproduire les actions d'un utilisateur connu pour ses capacités multi-tâches sera écrit sous forme séquentielle et non en parallèle.
Il est possible d'empiler plusieurs sessions utilisateur sur le même ordinateur ou sur le même serveur Windows.
La session utilisateur permet l'isolation des tâches d'exécution des tests, mais aussi l'exécution de plusieurs tests en parallèle à raison d'un test par session.
Utilisation massive des sessions Windows
Sous Windows Server par exemple, l'utilisation massive de sessions Windows nécessite un OS activé avec sa propre licence, mais aussi des licences supplémentaires telles que des CALs utilisateurs, et si le protocole "Remote Desktop" est utilisé, des CALs RDS.
De nos jours, la méthode la plus courante pour utiliser de nombreuses sessions utilisateur consiste à utiliser un protocole de contrôle à distance tel que RDP ou Citrix.
La carte graphique virtuelle gérée par RDP est RDPUDD Chained DD
L'adaptateur graphique utilisé est alors virtuel, et géré par le système de contrôle à distance. Il n'y a pas de relation entre la carte graphique du serveur utilisé et le nombre de sessions simultanées au maximum.
Sécurité et connexion
Besoin d'une session ouverte...
Les règles de sécurité de Microsoft Windows ne permettent pas d'exécuter des applications sur une session qui n'est pas ouverte, que ce soit par le biais du planificateur de tâches ou d'un autre système d'exécution planifié ou déclenché à distance. La session Windows doit être ouverte pour que le test puisse être exécuté.
...mais session ouverte ne signifie pas sans authentification !
Ceci étant, il est possible d'exécuter des tests sur une session Windows ouverte, mais verrouillée par la demande d'authentification, le plus souvent par mot de passe.
Pour verrouiller une session locale, on peut cliquer sur le menu démarrer, puis sur l'utilisateur, puis sur Verrouiller.
Pour verrouiller une session distante, la même opération est possible (voir capture d'écran ci-dessous) mais il suffit de fermer la fenêtre de connexion. La preuve : que ce soit en verrouillant sciemment la session ou en se reconnectant via RDP après avoir fermé la connexion, l'authentification sera demandée.
Une fois que nous avons configuré une session pour qu'elle s'ouvre automatiquement ou par la connexion d'un utilisateur par un protocole tel que RDP, plusieurs possibilités sont disponibles :
- Une connexion automatique peut être configurée au démarrage du serveur, tout en conservant une bannière de verrouillage du mot de passe. Il est important de faire la différence entre "session ouverte" et "mot de passe requis". Par ailleurs, une session ouverte et visible sans mot de passe n'est pas un problème si aucun écran clavier-souris n'est connecté et que l'accès à la session par le protocole de bureau à distance (RDP, Citrix, ...) nécessite un mot de passe.
- il est possible d'effectuer une connexion à la demande en scriptant la demande de connexion via le protocole de bureau à distance. Vous pouvez ensuite configurer un script qui s'exécute au début de la session et qui interroge un service d'exécution à distance pour savoir s'il doit lancer un travail de test ou non.
De toute évidence, une authentification forte est nécessaire pour protéger l'accès aux sessions par tous les utilisateurs. Encore une fois, l'ouverture de session automatique ne signifie pas qu'un mot de passe ne sera pas nécessaire. Le revers de la médaille est vrai : ce n'est pas parce que votre session est fermée qu'elle est sécurisée, surtout si le protocole d'accès à distance est accessible sur une IP publique et que le mot de passe est faible !
La plateforme d'intégration continue : Jenkins
Nous avons couvert l'environnement pour exécuter un test Agilitest et les prérequis.
Mais s'il est possible d'exécuter un test de manière isolée sur la ligne de commande DOS ou PowerShell, ou même via le planificateur de tâches de Windows, ce n'est pas le but.
En fait, nous recommandons de programmer les exécutions de tests par le biais du système d'intégration continue Jenkins, qui est bien connu et largement utilisé dans le secteur. Agilitest supporte nativement Jenkins, soit en le déployant et en l'installant sur l'ordinateur du testeur, soit en se connectant à une instance existante en cours d'exécution.
Plus important encore, Agilitest est capable de communiquer avec Jenkins pour créer de nouveaux Jobs (ou éléments).
Si les besoins d'exécution des tests sont massifs, alors le serveur Jenkins n'exécutera aucun test et les déléguera aux serveurs d'exécution via la communication Jenkins maître-esclave par l'intermédiaire de l'agent Jenkins.
Pour ce faire, Jenkins permet l'utilisation de différents protocoles de communication tels que Java Web Start (JNLP) et SSH.
Conclusion
Comme vous pouvez le constater, la plupart des considérations de cet article sont générales, et non spécifiques à Agilitest. En effet, notre approche a toujours été de proposer des logiciels d'automatisation qui s'inscrivent dans un processus TestOps, lui-même composé de briques logicielles interopérables et les meilleures dans leur domaine. C'est ce que nous appelons une mise en œuvre " best of breed ".
La session Windows qui est le composant clé de l'architecture fournie par Microsoft pour paralléliser les tests dans une infrastructure dédiée.
Jenkins est le composant qui permet de planifier les exécutions tout en donnant accès aux rapports de campagne et en suivant le taux de réussite et d'échec pour un travail donné, même si ATS est compatible avec TestNg et peut être déployé sur tout système CI/CD.
Photo par Ant Rozetsky sur Unsplash
.png)
