1. Situation initiale
Dans le cadre d'un projet mené par une grande banque cantonale suisse visant à automatiser les tests du système bancaire Avaloq à l'aide de Tricentis Tosca, la production de rapports est un enjeu crucial. Actuellement, quatre mises à jour sont déployées chaque année. Compte tenu de la diminution des efforts requis pour l'exécution manuelle des tests de régression, un cycle de mise à jour mensuel est envisagé. Malgré des efforts considérables, Tosca Analytics n'a pas encore été implémenté avec succès pour la génération de rapports de test. Cette situation a conduit à l'idée de mettre en place un rapport de test basique, généré automatiquement au sein de Tosca, à l'aide de moyens techniques simples.
2. Objectifs
Dans le cadre du projet actuel, les informations pertinentes telles que le nom du cas de test, le(s) numéro(s) de commande, les résultats de vérification, etc., sont enregistrées dans un fichier texte lors de l'exécution de chaque cas de test (d'après une idée de mon collègue Michael Weiglein). Ce fichier est mis à la disposition du responsable du département afin de faciliter le suivi de l'exécution des tests. Cependant, ce fichier n'indique pas si un cas de test s'est exécuté avec succès ni si, par exemple, la vérification d'une condition a échoué. Étant donné que ce fichier texte est créé avant la fin de l'exécution du test, son résultat n'est pas encore disponible à ce moment-là.
Par conséquent, les responsables de département doivent disposer d'un moyen simple de vérifier, à tout moment et dans un emplacement facilement accessible, si un cas de test s'est exécuté avec succès pour la dernière fois et, le cas échéant, à quelle date. De plus, le temps nécessaire à la génération d'un rapport de test simple doit être considérablement réduit.
3. Exigences techniques
Une condition préalable essentielle à la mise en œuvre est l'exécution de tests avec Jenkins, car le système dépend des fichiers XML générés. Par défaut, Jenkins enregistre ces fichiers dans un répertoire du serveur correspondant à la tâche de test, par exemple : C:\jenkins\workspace\Financing. Un agent Tosca pour l'exécution distribuée, exécuté sur une autre machine, peut rencontrer des difficultés d'accès à ce répertoire en raison d'autorisations insuffisantes. Il est donc nécessaire de configurer Jenkins afin que les fichiers de résultats soient enregistrés sur un lecteur réseau accessible (voir figure 1). Les répertoires de stockage de ces fichiers doivent être créés avant l'exécution des tests ; par exemple, « Créer une demande de prêt ».
Fig. 1 : Exemple de fichier de configuration Jenkins pour la réalisation de tests dans un département spécifique.
4. Processus général
Entre autres, des expressions régulières sont utilisées pour filtrer les données pertinentes suivantes à partir d'un fichier de résultats Jenkins (voir Fig. 2) :
- Nom du cas de test
- Horodatage
- Résultat (Réussi, Échec)
Figure 2 : Extrait d'un exemple de fichier de résultats Jenkins
Ces informations sont compilées dans une chaîne de caractères au format CSV, puis enregistrées dans un fichier du même format dans le répertoire cible. L'algorithme suivant est utilisé de manière plus générale (voir Fig. 3) :
Figure 3 : Algorithme d'extraction des données pertinentes du fichier de résultats Jenkins
Il arrive qu'un cas de test ne soit pas exécuté, mais qu'il soit inclus dans le fichier de résultats Jenkins. Le système vérifie alors si la recherche initiale de la chaîne de caractères correspondante donne des résultats. Si la recherche est infructueuse, une chaîne de caractères par défaut contenant l'horodatage et le résultat du test est écrite dans le fichier cible. Cela permet d'identifier immédiatement que ce cas de test n'a pas été exécuté lors de la dernière exécution.
5. Mise en œuvre concrète avec Tosca
Pour la mise en œuvre variable, Tosca utilise une feuille de test avec la structure suivante (voir Fig. 4) :
Fig. 4 : Feuille de test Tosca
Dans le cadre du projet actuel, une feuille de test distincte est utilisée pour chaque département, comme les finances ou les transactions de paiement, afin de garantir que la liste des cas de test ne soit pas trop exhaustive et que le résultat soit adapté au public cible.
Certaines des étapes pertinentes du modèle de test sont discutées plus en détail ci-dessous (voir Fig. 5).
Fig. 5 : Modèle de test Tosca
Le contenu du fichier de résultat XML généré par Jenkins peut être chargé à partir du répertoire respectif basé sur la feuille de test Tosca via un chemin comme suit : \\Tosca\Resultat\Jenkins\{XL[Nom de l'étape]}\{XL[Nom du parallèle]}_Resultat.xml.
La recherche de la chaîne d'environnement est implémentée de manière à rechercher directement le nom approprié pour l'environnement de test (par exemple, INT pour un environnement de test d'intégration).
L'expression régulière suivante est utilisée pour rechercher la chaîne source, à partir de laquelle les données souhaitées sont ensuite extraites : `({XL[Instance.Name]}).* log="[-+] (Échec|Réussite)"` (où la référence XL correspond au nom spécifique d'un cas de test). Ce nom de cas de test correspond exactement au nom de l'instance correspondante dans la feuille de test ; il ne peut donc pas être extrait de la chaîne source.
Le texte situé entre le nom du cas de test et l'horodatage est trouvé à l'aide de l'expression régulière suivante, puis supprimé : .*".*horodatage=".
L'horodatage UTC se présente sous la forme suivante : 2020-01-31T12:49:54.1985841+01:00. Il est converti au format AAAA-MM-JJ HH:MM. La transformation de l'horodatage au format cible s'effectue en plusieurs étapes :
- Extraction de données
- Temps d'extraction
- Assemblez les horodatages au format souhaité
Le résultat du test lui-même est extrait sous forme de texte via une recherche directe : (Échec|Réussite).
Si l'ensemble de ce processus n'était pas implémenté avec Tosca, mais plutôt, par exemple, à l'aide d'un script, la recherche de toutes les chaînes de résultats pourrait être effectuée en une seule étape à l'aide de listes de cas de test spécifiques par département, au lieu d'utiliser des cas de test Tosca concrets.
La chaîne de résultats actuelle est ensuite écrite à la fin d'un fichier CSV. Ce fichier est enregistré sous un nom suivant la structure {Environnement de test_Département_Date}.csv dans un répertoire approprié, par exemple INT_Financing_2020-01-31.csv (ou sous forme variable : {B[AVQ_Environnement de test]}_{XL[Département]}_{DATE[][][yyyy-MM-dd]}.csv). Si ce fichier texte n'existe pas encore, l'en-tête contenant la chaîne « Cas de test ; Horodatage ; Résultat » est d'abord écrit dans un fichier vide. À chaque exécution du processus, le système vérifie si le fichier CSV existe déjà. Si c'est le cas, son contenu est copié, la nouvelle chaîne de caractères est ajoutée à la fin, et le nouveau contenu est réécrit dans le même fichier. Le texte suivant est utilisé comme chaîne de remplacement : {XL[Instance.Name]};Non exécuté;–.
Le processus produit ainsi, par exemple, un fichier CSV avec le contenu suivant :
Cas de test ; Horodatage ; Résultat :
Tests de base financiers – enregistrement de prêt ; 31/01/2020 16:38:35 ; Réussi :
Création d’une demande de prêt immobilier ; Non exécuté ;
Création d’une demande de prêt professionnel ; 31/01/2020 16:52:10 ; Échec
6. Exécution
Le rapport de test peut être généré manuellement à l'aide d'une liste d'exécution dans Tosca. Pour une exécution automatisée immédiatement après un test, une étape configurée dans Jenkins, contenant les éléments nécessaires à l'exécution distribuée des tests dans Tosca.
7. Avantages
Ce rapport de test simple, généré automatiquement, peut apporter des avantages aux fonctions individuelles, tels que :
- Le responsable des tests consacre moins de temps à la création manuelle des rapports de test. Les cas de test ayant échoué peuvent être annotés d'un commentaire dans une colonne supplémentaire d'un fichier Excel avant d'être transmis au chef de service.
- L' ingénieur de test assure le suivi des instances de test en mettant à jour et en configurant en continu les feuilles de test avec les nouveaux cas de test implémentés. Les instances de test sont créées rapidement avec Tosca.
- L' expert du domaine a un accès permanent aux résultats des tests sans avoir à les diffuser explicitement. Cela permet une meilleure visibilité des résultats.
L'avantage réel dépend bien sûr de l'environnement spécifique et du type de rapport de test requis.
8. Poursuite de l'expansion
8.1 Amélioration de la lisibilité avec un fichier Excel ou PDF
Si Microsoft Excel est installé sur l'ordinateur exécutant l'agent Tosca pour les tests avec Jenkins, le fichier CSV peut être rendu plus lisible. Pour cela, un modèle Excel avec mise en forme conditionnelle est créé afin de faciliter l'identification des résultats de test grâce à la coloration en vert ou en rouge. Le contenu du fichier CSV est ensuite importé dans les cellules A4 à C54, et ainsi de suite. Ce fichier Excel peut également être enregistré au format PDF.
Figure 6 : Modèle Excel avec mise en forme conditionnelle des résultats de test
8.2 Distribution par courriel
Les rapports de test générés peuvent être envoyés aux destinataires souhaités à l'aide d'un script PowerShell du type suivant :
Envoyer-MailMessage -à @(“test@example.com”) -depuis “Tests de régression”<no-reply@example.com> " -SmtpServer "servername.example.com" -Subject "Résultat du test" -Body "Le résultat du test se trouve en pièce jointe." -Attachments "Test result.csv" -Encoding ([System.Text.Encoding]::UTF8)')
Cette tâche sera exécutée à l'heure souhaitée via le Planificateur de tâches Windows (ou une tâche cron dans les environnements Unix).
9. Conclusion
Cette description explique comment automatiser la génération de rapports au sein de Tricentis Tosca, grâce à des moyens techniques simples, lors de tests effectués avec Jenkins. La conception et la diffusion des rapports de test peuvent être rapidement adaptées aux besoins spécifiques de chaque contexte. Bien entendu, ces rapports de base ne remplacent pas un reporting complet destiné à la direction. L'objectif est de fournir un résultat d'exécution de test généré automatiquement et accessible aux utilisateurs métiers selon leurs besoins.
3 février 2020, Bernhard Fuchs
Mise à jour du 2 mars 2020 :
Dans la version originale, le format de date, par exemple 2020-01-31T12:49:54.1985841+01:00, n'était pas interprété correctement. Comme il n'y a pas de décalage horaire avec l'heure d'Europe centrale, la section relative à la conversion de l'heure a été supprimée.
Je décris une méthode bien plus élégante pour générer un rapport de test à partir des fichiers de résultats Jenkins dans l'article de blog intitulé « Des méthodes plus élégantes pour générer un rapport simple sur l'exécution des tests Jenkins ».
