Automatisation de l’exécution des tests Webservices et batch par des fonctionnels
Par Adrien Franco et Marc Hage Chahine
Bien que la pyramide des tests automatisés (rappel ci-dessous) soit connue, l’automatisation des tests reste très liée dans l’imaginaire collectif – et particulièrement pour les ingénieurs logiciels de haut niveau – aux tests d’interfaces graphique (IHM).
Pour rappel, si les tests IHM sont tout en haut de la pyramide, c’est-à-dire les moins nombreux à automatiser, c’est parce que ces tests sont les plus complexes (ils dépendent de nombreux paramètres) à automatiser et à maintenir (avec une forte sensibilité à de nombreux changements). De même, l’IHM nécessite souvent un produit avancé dans son développement et cela peut aller à l’encontre, dans certains contextes, du « shift left ». Il est donc généralement plus intéressant d’automatiser les couches les plus basses de l’application, notamment grâce à des tests de Webservices ou des tests batch, comme cela a été fait dans le retour d’expérience présenté dans cet article.
Contexte
Nous sommes ici sur un produit existant qui continue d’évoluer. Ce produit est sans IHM mais complexe. Cette complexité entraîne la nécessité d’exécuter un grand nombre de tests de différents types (Webservices, batch, base de données…), afin d’atteindre une couverture fonctionnelle suffisante. De même, ce logiciel doit régulièrement être testé. Car des modifications du logiciel ou de partenaires sont fréquentes. Cette tâche est assignée à 2 testeurs fonctionnels qui n’avaient pas le temps de préparer les données (1/2 journée pour créer 200 jeux de données nécessaires aux tests) et d’exécuter suffisamment de tests pour valider un niveau de qualité suffisant. Ce manque de temps forçait les testeurs à faire des choix forts et à renoncer à certains tests importants, ce qui engendrait l’apparition d’anomalies évitables en production.
Conscients de cette problématique et de l’apport théorique de l’automatisation, nous avons pris la décision de créer un automate de test avec les fonctions suivantes :
- La génération des fichiers de jeux de données utilisés par les Webservices
- Le lancement automatisé d’offres de service (OS) : les Webservices
- Le lancement automatisé de batch
- Le lancement automatisé d’offres de services et de batch, ordonnancés au sein d’une même exécution
- Le contrôle automatisé des résultats obtenus
- La mise à disposition d’un bilan des résultats obtenus.
La prise en compte du profil non technique des testeurs amenés à travailler sur la solution a également entraîné d’autres besoins comme :
- La réalisation d’un guide utilisateur de l’automate permettant son utilisation par des agents ne disposant d’aucune compétence technique spécifique
- La maintenabilité par tout analyste disposant d’un minimum de connaissances en développement logiciel, grâce à une syntaxe de code source explicite et commentée.
Démarche adoptée
Afin de répondre au mieux à ce besoin, nous avons mis en place une démarche en plusieurs étapes :
Un audit
L’audit s’est fait au travers d’entretiens et d’ateliers. Le but de ce dernier était de bien identifier le contexte et les besoins.
Le retour des ateliers a permis de dégager les points suivants :
Une définition de la stratégie d’automatisation
Le recueil des différents besoins effectué avec l’audit a également permis la co-construction d’une stratégie de test.
Nous avons choisi de faire intervenir un consultant expérimenté en automatisation des tests, afin de mettre au point un POC (Proof Of Concept).
Les résultats du POC servant alors de base, pour la suite de l’automatisation des tests, avec une sélection et une priorisation des tests à automatiser. Le POC a également permis de prévoir les retours sur investissements de l’automatisation.
La mise en place d’un POC (Proof Of Concept)
Le POC a mis en lumière que l’automatisation était techniquement faisable mais que, pour cela, il fallait résoudre certains challenges comme :
- Une utilisation exclusive de LibreOffice
Excel n’étant pas un outil utilisé dans cette entreprise
- Enregistrement de jeux de données multiples au format XML
Il fallait traiter des nœuds multiples mais aussi réussir à bien identifier les points à modifier ou traiter.
- L’envoi et la réception de requêtes SOAP avec des pièces jointes
La documentation à ce sujet est faible car SOAP est de moins en moins utilisé, contrairement à REST.
- L’utilisation d’OpenVPN pour accès à la base de données et aux fichiers
Contrainte liée à l’environnement du logiciel et à la politique de l’entreprise
- Rendre générique l’envoi de requêtes SQL.
La création de l’automate et l’industrialisation des tests
Suite au POC, la décision a été prise d’automatiser. Le choix de l’outil s’est porté sur la création d’une feuille de calcul servant d’interface aux testeurs. Cette feuille de calcul contrôle RobotFramework qui, en plus de contribuer à la résolution de nombreux challenges, a l’avantage d’être très flexible et de s’adapter à différents types de tests. C’est également un outil Open Source (ce qui était une contrainte forte de l’entreprise).
Les différents challenges ont été relevés de la manière suivante :
La restitution
Au final, l’automate proposé répond entièrement aux besoins fonctionnels en étant capable d’exécuter :
- Des tests de Webservices SOAP qui exécutent et récupèrent des requêtes, avec ou sans pièces jointes, en contrôlant les valeurs de ces requêtes. Des tests batch qui font des contrôles de fichiers
- De la validation de base de données à travers des requêtes SQL, qui valident l’impact des requêtes SOAP.
La solution proposée sous la forme de 2 formats de feuilles de calcul (1 pour les tests, 1 pour la génération de données), très simples à utiliser et à maintenir, permet de répondre aux besoins opérationnels, en gérant simplement les jeux de données, en permettant de piloter aisément et en étant très simple d’utilisation pour des fonctionnels qui n’ont donc pas besoin d’avoir de connaissances techniques particulières, comme cela peut parfois être le cas avec de l’automatisation de tests. Cette solution fonctionne grâce à une architecture simple et compréhensible de l’outil de gestion de l’automate. On peut, par exemple, penser à des choix ergonomiques comme :
- Chaque onglet a un but et un nom définissant clairement son rôle. On a, par exemple, un onglet listant les tests, un autre listant les OS testés ou encore un onglet « légende » permettant d’expliquer le sens de noms utilisés.
- Chaque ligne à un rôle spécifique et clair. Pour les onglets sur les tests, cela correspond à un test ou un pas de test, dans le cas d’un test utilisant plusieurs OS. Dans l’onglet ci-dessous (anonymisé), chaque ligne correspond à un Webservice :
- Chaque test est paramétrable. Les paramètres sont gérés avec les colonnes de leur ligne dédiée.
La gestion des données se fait également avec un autre fichier, sous forme d’une feuille de calcul avec un onglet par OS et listant des cas ou pas de test (1 test par ligne) pour chacun de ces OS.
Enfin, les bilans sont détaillés et générés automatiquement grâce à RobotFramework, ce qui permet d’analyser simplement et rapidement les causes d’échec.
Description de l’automate
L’automate a deux fonctionnalités principales qui sont la création de jeux de données et l’exécution des tests.
Pour générer les données, nous avons mappé les différents fichiers xml attendus en sortie avec un onglet par Webservice. Nous avons mis chaque élément du fichier xml en colonne avec son xpath, pour pouvoir écrire correctement les bonnes valeurs au bon endroit.
Pour la partie exécution, chaque ligne va correspondre à un cas de test avec son propre identifiant et générer un fichier différent.
Pour exécuter les tests, l’automate a besoin d’être lancé à l’aide d’une ligne de commande. Etant donné que le profil des utilisateurs n’est pas très technique, nous avons encapsulé cette ligne de commande dans un fichier « .bat » qui enclenche l’exécution de l’automate (RobotFramework). Robotframework va alors chercher les informations dans les feuilles de calcul, afin de générer et d’exécuter les tests. Du point de vue de l’utilisateur, il suffit simplement de cliquer sur le fichier « .bat » pour générer les données de tests et exécuter la campagne.
Pour résumer, la solution développée peut se schématiser comme ceci :
La vie de l’automate
Les projets de développement ne sont pas un long fleuve tranquille. Il en est de même avec l‘automatisation implémentée avec notre outil, où certains imprévus ont fait irruption.
Un des plus notables est probablement celui où le script Python, permettant de lancer la connexion au VPN, n’obtenait pas de valeur de retour. Cela rendait impossible la suite de l’exécution normale de l’automate, étant donné que la tâche précédente ne se terminait jamais.
Pour contourner ce point, nous avons utilisé la technique du multithread, en mettant donc dans un thread dédié la connexion au VPN et, dans une autre, la partie purement fonctionnelle de l’exécution de l’automate avec ses fonctionnalités dédiées.
De plus, l’automate interagit avec la feuille de calcul LibreOffice, grâce à une librairie spécifique codée en Python qui permet de lire dans n’importe quelle cellule de n’importe quel onglet et va permettre de traiter les valeurs propres à chaque cas de test (jeu de données à générer ou cas de test à exécuter).
Les éventuels messages d’erreur que peut rencontrer l’automate sont remontés dans les logs de Robot Framework grâce à l’implémentation de ces différents contrôles, à travers les mots-clés définis par l’utilisateur.
Les résultats de l’automatisation
L’automatisation proposée est un franc succès. Elle est actuellement utilisée et les testeurs fonctionnels continuent de développer la couverture de test et de faire évoluer simplement les tests grâce à cet outil.
Cette automatisation est un succès car elle a engendré :
- Une amélioration de la qualité grâce à une meilleure couverture des tests à chaque campagne.
L’automatisation des tests a permis de multiplier les tests et les données. Là où la création de 600 fichiers pour les données nécessitait un peu plus d’une journée, maintenant seules 2 minutes suffisent.
De même, ces jeux de données générés sont beaucoup plus fiables car les erreurs humaines (courantes sur les tâches longues et répétitives) sont maintenant évitées.
De plus, l’outil, du fait de sa capacité à faire évoluer les tests et à générer facilement des données, permet d’adapter les tests aux différentes campagnes et de limiter l’impact du paradoxe des pesticides.
Le problème initial de ne plus pouvoir faires les tests pour assurer un niveau de qualité suffisant, dans le temps imparti, est maintenant oublié et il y a moins d’anomalies en production.
Initialement, les 2 testeurs disposaient de 3 jours pour exécuter le plus de cas de tests possible à chaque release ; au vu du temps que prenait la création des jeux de données, l’exécution et les contrôles, ils ne pouvaient, au mieux, effectuer qu’entre 150 et 200 cas de tests.
Maintenant, ces 200 cas de tests sont exécutés en moins de 3O minutes par l’automate.
Il leur est maintenant possible d’exécuter une campagne de régression « complète », c’est-à-dire plusieurs milliers de tests, de manière automatique, en l’espace de quelques heures seulement.
- Un gain de temps
Les campagnes de tests sont maintenant beaucoup plus courtes, alors que la couverture des tests est beaucoup plus grande et les tests beaucoup plus nombreux.
De même, les jeux de données générés sont beaucoup plus rapides : 2 minutes pour générer 600 fichiers xml de jeux de données contre plusieurs heures en manuel.
De plus, il était auparavant nécessaire pour les tests de Webservices d’ajouter manuellement les pièces jointes dans chaque requête via SOAP UI. C’est maintenant l’automate qui s’en charge, ce qui permet de faire plus de tests avec pièces jointes, sans devoir attendre une intervention humaine.
Là où auparavant les 2 testeurs pouvaient mettre plus de 15 minutes à dérouler un cas de test (qui consiste à créer son fichier de jeu de données, l’insérer dans la requête Soap, exécuter la requête, analyser le résultat, faire des contrôles en base de données…), l’automate effectue toutes ces actions en seulement 4 ou 5 secondes, selon le temps que met le Webservice pour répondre.
L’automate est donc très véloce et permet, en plus du temps gagné, de s’assurer de la qualité, car il peut répéter à l’infini les mêmes actions, qui peuvent se révéler fastidieuses lorsque la fatigue du testeur se fait sentir. L’automate permet, en effet, de faire plus en quelques heures (des milliers de tests) que ce qui était fait en 3 jours (200 tests). En plus d’améliorer la vision sur la qualité, cela réduit drastiquement le temps d’exécution des campagnes de régression.
Maintenant, il suffit juste de passer du temps sur la conception des cas de tests dans le fichier ods et une fois la tâche effectuée, plus besoin d’y toucher. Cette action permet également de continuer à construire le référentiel de tests.
- Le gain de temps permet de dépenser son temps sur des tâches à plus forte valeur ajoutée.
Le temps est gagné sur l’exécution et l’analyse de résultats, car l’automate fait lui-même les vérifications en base de données et sur serveur pour les fichiers issus des batch.
Conclusion
L’automatisation de l’exécution des tests, ce n’est pas que l’automatisation des tests IHM. Automatiser des tests de Webservices offre généralement un retour sur investissement très rapide et visible, car ils sont nombreux, assez similaires entre eux et évoluent moins que les interfaces graphiques, ce qui implique beaucoup moins de maintenance et réduit donc le coût et augmente la rentabilité de l’automate.
Ce n’est pas pour rien que la pyramide des tests automatisés se représente souvent avec les tests d’intégration / Webservices / API comme étant les tests à automatiser, juste après les tests unitaires.
De même, comme nous l’avons vu dans ce retour d’expérience, la technicité de ces tests peut être cachée avec une interface simple et accessible à des profils non techniques, mais qui répond à l’ensemble des besoins.
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
