Image principale: Execution massive des tests

Déploiement d’Agilitest sur un environnement de production, pour des exécutions massives de tests

par Paul Chevalier | 25 novembre 2020

L’adoption de la solution Agilitest pour créer et maintenir un référentiel de tests automatisés est un processus en plusieurs étapes. Nombreux sont nos articles et nos pages de documentation technique qui abordent la prise en main, ou encore l’approche que nous affectionnons en ce qui concerne la robustesse et la maintenabilité des tests.

Le présent article traite spécifiquement d’une étape qui est obligatoire lorsqu’on a déjà choisi Agilitest et qu’on souhaite intégrer la solution dans son environnement de production pour l’exécution des tests : quelle architecture employer pour de l’exécution massive de tests, quels types de matériels, et quelles technologies logicielles utiliser ?

Que faut-il pour exécuter un test ?

Agilitest est un logiciel qui tourne sous le système d’exploitation de Microsoft, dans sa déclinaison bureau, Windows 10, et sa déclinaison serveurs Windows Server 2016 et 2019.

Avant d’exécuter un test, il faut tout d’abord un scénario de test au format ATS créé dans Agilitest. Ce scénario de test ATS pourra ê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 principales possibilités existent pour exécuter un ou plusieurs tests :

  • lancer une ligne de commande relative à une exécution TestNG,
  • exploiter par Jenkins un fichier de configuration Maven pom.xml généré dans Agilitest.

L’environnement d’exécution d’un test se compose d’une session utilisateur Windows ouverte dans laquelle le test est exécuté.

Lorsque le tests s’exécutera, le logiciel à tester s’ouvrira 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 pré-requis dépendent du canal ou des canaux utilisés dans le scénario de test automatisé : desktop, web, webservice, iOS, Android.

Exécution de tests desktop

La première étape d’un test desktop consiste à lancer un logiciel à tester, le plus souvent sous la forme d’un fichier.exe à ouvrir. Il est aussi possible de se raccorder à un processus en cours d’exécution lorsque cela est absolument indispensable.

Une session Windows graphique est donc requise pour les tests desktop.

Exécution de tests web

L’environnement d’exécution d’un test web est plus prévisible qu’un test desktop puisque la première étape consiste toujours à lancer un navigateur supporté : Chrome, Firefox, Edge basé sur Chromium, Opera ou Internet Explorer.

Une session Windows graphique est donc requise pour les tests web.

Exécution de tests de webservices

L’utilisation d’un webservices au travers de requêtes HTTP est une opération de plus bas niveau que l’utilisation d’un logiciel doté d’une interface graphique.

Par conséquent, une session Windows de console peut suffire pour jouer un test de webservices. S’il n’est pas indispensable de disposer d’un environnement graphique de bureau dans ce cas, cela reste vivement conseillé afin de bénéficier de l’aspect multi-canal d’Agilitest.

Exécution de tests mobiles Android et iOS

La première étape de l’exécution d’un test mobile consiste à lancer une application sur un mobile donné. Il est donc important d’être rigoureux dans la configuration de l’ensemble, avec par exemple un plan d’adressage IP stable pour les mobiles.

Les mobiles physiques devront être connectés par câble USB et connectés au même réseau que la machine qui exécute le test.

Les mobiles émulés dans le cloud Genymotion nécessitent simplement une connexion Internet fonctionnelle. Cette solution apporte une grande facilité d’utilisation, et permet notamment d’exécuter les tests sur n’importe quelle machine Windows, éventuellement virtualisée ou dans le cloud, sans jamais nécessiter de fermes de mobiles physiques.

Une session Windows graphique reste indispensable, en particulier pour être en mesure de générer les rapports de tests illustrés de screenshots, et les vidéos de replay.

Que faut-il pour rejouer des tests de manière intensive ?

La session utilisateur, composant principal de la chaîne d’exécution

A ce stade, nous pouvons dire qu’un pré-requis indispensable à l’exécution d’un test Agilitest, c’est la présence d’une session Windows graphique.

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 schéma réaliste d’utilisation fonctionnelle. Même un scénario fonctionnel riche supposé reproduire les actions d’un utilisateur reconnu pour ses capacités multi-tâches sera écrit sous forme séquentielle et non en parallèle. En effet, personne ne dispose de deux curseurs de souris sur un même écran car aucun OS ne le permet.

En revanche, il est tout à fait possible d’empiler de nombreuses sessions utilisateur sur un même poste ou sur un même serveur Windows.

La session utilisateur permet donc l’isolation des tâches d’exécution de tests, mais aussi l’exécution de plusieurs tests en parallèle à raison d’un test par session.

Utilisation massive de sessions Windows

Sous Windows Server 2012R2 par exemple, l’utilisation massive de sessions Windows nécessite un OS activé avec sa licence propre, mais aussi des licences additionnelles de type CAL Utilisateur, et si le protocole « Bureau à Distance » est utilisé, des CAL RDS.

De nos jours, la méthode la plus courante pour utiliser de nombreuses sessions utilisateur est de recourir à un protocole de prise de contrôle à distance tel que RDP ou Citrix.

Affichage virtuel : RDPUDD Chained DD
Carte graphique virtuelle gérée par RDP : RDPUDD Chained DD

On peut constater que l’adaptateur graphique utilisé est alors virtuel, et géré par le système de prise de contrôle à distance. Il n’y a aucune relation entre la carte graphique du serveur utilisé et du nombre de sessions concurrentes au maximum.

Sécurité et ouverture de session

Nécessité 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 via la planificateur de tâches ou un autre système d’exécution planifiée ou déclenchée à distance. La session Windows doit être ouverte pour que le test puisse être exécuté.

…mais session ouverte ne veut pas dire sans authentification !

Cela étant, il est possible d’exécuter des tests sur une session Windows ouverte, mais verrouillée avec 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 (cf. copie d’écran ci-dessous) mais fermer la fenêtre de connexion suffit. La preuve : que ce soit en verrouillant la session sciemment ou en se reconnectant via RDP après fermeture de la connexion, l’authentification sera demandée.

Session Windows Server verrouillée à distance. Nota : il suffisait de fermer la fenêtre RDP pour le même résultat.

Une fois que l’on a configuré une session pour s’ouvrir automatiquement ou moyennant la connexion d’un utilisateur par un protocole tel que RDP, plusieurs possibilités s’offrent à nous :

  • une ouverture de session automatique peut être configurée au démarrage du serveur, tout en conservant un bandeau de verrouillage par mot de passe. Il faut bien différentier « session ouverte » et « mot de passe requis ». En outre, une session ouverte et visible sans mot de passe n’est pas problématique 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.
  • une ouverture de session à la demande peut être réalisée en scriptant la demande de connexion via protocole de bureau à distance. On peut alors configurer un script qui s’exécute au démarrage de la session et qui interroge un service d’exécution distante pour savoir s’il doit lancer un job de test ou pas.

Bien évidemment, une authentification forte devra être mise en place pour protéger l’accès aux sessions par tous les utilisateurs. Encore une fois, l’ouverture automatique d’une session ne signifie pas que le mot de passe ne sera pas requis. La contrepartie est vraie : ce n’est pas parce que votre session est fermée qu’elle est sécurisée, notamment si le protocole d’accès distant 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 permettant d’exécuter un test Agilitest ainsi que les pré-requis.

Mais bien qu’il soit possible d’exécuter un test de manière isolée en ligne de commande DOS ou PowerShell, ou même via le planificateur de tâches Windows, là n’est pas l’intérêt.

En effet nous recommandons de programmer les exécutions de tests grâce au système d’intégration continue Jenkins qui est bien connu et largement utilisé dans le secteur.

Plus encore, Agilitest est capable de communiquer avec Jenkins pour créer de nouveaux Jobs (ou items). La présentation détaillée de l’intégration avec Jenkins est présentée dans notre Webinar « Lancer des campagnes et produire des rapports de tests automatisés sous Jenkins ».

Pour intégrer Agilitest avec Jenkins, la mise en place minimale consiste à faire exécuter les tests par la machine qui exécute Jenkins. Si les besoins d’exécution de tests sont massifs, alors le serveur Jenkins n’exécutera aucun test et les déléguera aux serveurs d’exécution via une communication Jenkins Master-Slave via l’agent Jenkins. Pour cela, Jenkins permet l’utilisation de différent protocoles de communication comme Java Web Start (JNLP) et SSH.

Pour en savoir plus sur l’intérêt de la synergie de Jenkins avec Agilitest, consultez notre article qui explique comment l’interface Jenkins d’Agilitest va vous simplifier la vie.

Conclusion

Vous l’aurez compris, la plupart des considérations de cet article sont générales, et non spécifiques à Agilitest. A vrai dire, notre démarche a toujours été de proposer un logiciel d’automatisation qui s’inscrive dans un processus TestOps, lui-même composé de briques logicielles interopérables et les meilleures dans leur domaine. C’est ce qu’on appelle une implémentation « best of breed ».

C’est donc bien la session Windows qui est le composant d’architecture clé fourni par Microsoft pour paralléliser les tests au sein d’une infrastructure dédiée.

Quant à lui, Jenkins est le composant qui permet de planifier des exécutions tout en donnant accès aux rapports de campagnes et en suivant le taux de succès et le taux d’échec pour un job donné.


Crédit photo: Brett Sayles de Pexels