Des logs aux tests de régression assisté par l’IA – Démarche et retour d’expérience avec Gravity

L’automatisation des tests en 2022 reste un point de peine très important des équipes de développement logiciel.

Cela apparaît fortement dans l’enquête CFTL 2021-2022, avec des niveaux d’automatisation qui stagnent, des efforts d’automatisation estimés trop importants et une maintenance très difficile.  Dans les réponses à la question sur les principaux axes d’amélioration des tests pour l’avenir, de nombreux répondants citent les apports de l’IA pour faciliter l’automatisation des tests.

Dans cet article, nous présentons une approche et un processus outillé utilisant les logs en production pour mesurer et compléter la couverture de l’usage par les tests automatisés de régression avec des techniques de Machine Learning et de Model-Based Testing. Il s’agit de répondre à deux des problèmes majeurs de l’automatisation :

• Garantir la pertinence des tests automatisés de régression vis-à-vis de la couverture de l’usage du logiciel ;
• Réduire l’effort de création et de maintenance de ces tests.

La pertinence des tests vis-à-vis des risques en production est une valeur clé des activités QA. C’est encore plus vrai pour les tests automatisés de régression dont la création et la maintenance requièrent des efforts et investissements significatifs sur la durée. Trois étapes (cf. Figure 1) organisent ce processus outillé : (1) Analyse et visualisation des traces d’usage en production et des traces de test ; (2) Comparaison de ces traces et identification des tests nécessaires pour compléter la couverture, et (3) Génération des scripts de test automatisés.

Ce processus peut s’appliquer à l’automatisation des tests via IHM ou sur API. Pour être concret dans cette présentation, nous utilisons un exemple de tests API sur une application eCommerce appelée Spree.

Etape 1 – Extraction des traces à partir des logs

Il s’agit dans cette première étape de reconstituer des traces d’usage à partir des événements enregistrés dans des logs lors de l’usage du logiciel.

Un peu de vocabulaire est utile pour clarifier le sujet :

• Un fichier ou une base de logs est un ensemble d’événements d’exécution, généralement enregistré dans une base de données (telle que ElasticSearch) ou géré avec un outil de monitoring (tel que Splunk, Dynatrace, Datadog ou App Insight par exemples).
• Un événement de log est l’item de base d’un fichier de logs. Il s’agit d’un événement enregistré, avec un timestamp, et un ensemble de caractéristiques. Pour notre exemple fil-rouge avec l’API Spree, la Figure 2a montre un extrait de ces événements de log correspondant aux appels d’API au format REST.
• Une trace est une séquence d’événements de log correspondant à une session d’usage. Sur notre exemple, il s’agit d’une séquence d’appels de l’API Spree, issue d’une exécution enregistrée. C’est par exemple un parcours client sur une boutique en ligne gérée avec Spree.

Dans cette première étape, trois traitements sont réalisés, après configuration de l’accès à l’outil de monitoring :

1. Acquisition des événements de logs sur une plage de temps définie et éventuellement avec un filtrage sur des types d’événement de logs,
2. Interprétation des événements de log en traces (illustré par la Figure 2.b). Dans cette figure 2b, chaque item d’une couleur différente désigne une ligne du fichier de log. Les logs sont ainsi triés pour constituer les traces (c’est-à-dire la suite des événements pour une session utilisateur).
3. Clustering hiérarchique des traces pour les regrouper par proximité métier et leur visualisation sous la forme de workflows (illustré par la Figure 3).  Le clustering est une catégorie d’algorithmes de Machine Learning (une branche de l’IA) qui permet de regrouper des données par proximité.

Le calcul des traces à partir des événements de log s’appuie sur une reconnaissance du chaînage entre événements. Dans les cas les plus fréquents, cela est réalisé de façon automatique grâce à un identifiant de session. Pour les cas plus complexes, la configuration du chaînage des événements de log est réalisée de façon manuelle.

Après calcul des traces, le clustering hiérarchique permet de les organiser en fonction de leur degré de proximité : deux traces correspondant à des séquences d’événements proches seront positionnées proches par l’algorithme de clustering hiérarchique.

Enfin, la visualisation sous forme de workflow est construite automatiquement à partir d’un algorithme d’abstraction issu du Model-Based Testing.

Etape 2 – Analyse et visualisation de la couverture de l’usage par les tests

Le calcul des traces vu précédemment à partir des logs en production peut aussi être réalisé à partir des logs d’exécution des tests. Cela permet ainsi d’obtenir des traces d’exécution de tests qui vont être comparées aux traces d’usage obtenues lors de la phase précédente pour établir la couverture de l’usage par les tests. La Figure 4 montre la visualisation comparée de traces d’usage, obtenue en production, et de traces de tests obtenues lors d’exécution de tests. Les parcours en couleur rose désignent des traces d’usage couvertes par au moins une trace de test. En couleur violette apparaissent les traces d’usage qui ne sont couvertes par aucune trace de test.

Les traces de tests peuvent être issues d’une exécution de tests automatisés (typiquement des tests de régression), mais aussi d’une exécution manuelle (par exemple de sessions de tests exploratoires). Comme le montre la figure 4, la couverture est visualisée sur le workflow et sa mesure en pourcentage est calculée pour les groupes de traces (au différent niveau du clustering hiérarchique).

Etape 3 – Génération des scripts de tests automatisés

Dans notre exemple fil-rouge, du test sur l’API Spree, les tests sont automatisés avec l’outil Postman. La Figure 5 illustre le schéma de principe de la génération des tests à partir de l’analyse de la couverture de l’usage par les tests :

1. Les traces d’usage sont obtenues sur l’environnement de production et les traces de test sur l’environnement de test ;
2. Ces traces sont comparées pour établir les traces non-couvertes par les tests ;
3. Les traces non-couvertes, en fonction du niveau de couverture souhaité, sont sélectionnées par l’utilisateur pour compléter la couverture
4. La génération automatique des scripts de test dans l’environnement d’automatisation cible est réalisée, ici en Postman, en associant, avec le support de l’outil, les étapes de la trace et les actions de test correspondantes.

Sur notre exemple, comme les événements de log sont des appels d’API REST, et que les tests automatisés correspondent à des séquences d’appels d’API au même format, le passage des événements loggés aux scripts de tests est réalisé en forgeant les requêtes REST pour publication en Postman. Pour faciliter cette construction des requêtes d’appel d’API pour les tests, les spécifications en Swagger sont utilisées lorsque disponibles, ce qui est le cas pour notre exemple fil-rouge de l’API Spree. A la fin de l’étape 3, les scripts de tests permettant de compléter la couverture ont été générés automatiquement. Sur notre exemple Spree, c’est plus de 80% des artefacts d’automatisation qui sont produits automatiquement. Seules certaines données de test doivent être reprises.

Retour d’expérience

Le processus outillé décrit précédemment est implémenté dans un outil appelé Gravity, développé par Smartesting. Gravity est expérimenté dans des contextes réels de tests basés sur les API et au niveau de l’IHM, dans des contextes de digital factory, de plateforme eCommerce et de R&D d’éditeurs SaaS. Voici plusieurs constats qui peuvent être dressés à ce stade :

• Sur les différents contextes d’expérimentation, les logs étaient disponibles et dans un format qui a permis de les utiliser directement, sans retouche. Dans la totalité des cas, ces logs sont gérés dans un outil adapté. Ceux que nous avons rencontrés sont : Dynatrace, Datadog, Splunk, Application Insight et Elasticsearch.
• Le calcul des traces d’usage, leur clustering et visualisation sous la forme de workflows, facilitent au sein de l’équipe Produit une meilleure connaissance des usages réels par les utilisateurs/clients. Dans certains cas, on a constaté que des usages étaient découverts dont l’équipe Produit n’avait pas connaissance.
• La mesure de couverture et la visualisation de cette couverture sur le workflow des traces apparaît comme très utile aux équipes pour compléter cette couverture en se focalisant sur les parcours utilisateurs clés.

Les tests de régression fonctionnels sur API sont un bon cas d’usage du processus avec Gravity, pour obtenir une bonne couverture de l’usage et une diminution de l’effort d’automatisation des tests.

L’expérimentation de la démarche d’ensemble « des logs aux tests » nous a permis d’identifier plusieurs aspects méthodologiques concrets de mise en œuvre. Nous en citons deux :

• Le processus facilite la collaboration entre les ingénieurs Opérations (qui gèrent les logs) et les testeurs (qui créent les tests). Cela s’inscrit dans l’évolution des pratiques de développement logiciel vers le DevOps.
• L’acquisition des logs, au départ de notre processus, est réalisée en ciblant des extraits représentatifs de l’usage (par exemple une partie de la journée de travail ou un certain type d’utilisateur), en fonction des objectifs de couverture de l’usage par les tests.

En conclusion

Le processus outillé allant des logs aux tests que nous avons présenté dans cet article permet de répondre aux besoins des équipes logicielles d’optimiser leurs tests de régression automatisés sur les parcours utilisateurs clés.

L’analyse de la couverture de test sur les traces d’usage est mise en évidence graphiquement et est actualisée au fur et à mesure de l’évolution du Produit, qui induit des changements dans l’usage par les utilisateurs.

L’apport de l’IA est réalisé lors de l’étape de clustering des traces, pour faciliter l’analyse des patterns d’usage en production. Nous expérimentons certaines directions complémentaires qui viendront graduellement renforcer les fonctionnalités de l’outil, par exemple pour le calcul des données de test par apprentissage automatique des classes d’équivalence des données, et sur l’extraction des parcours représentatifs à tester sur un cluster d’usage donné.

Si le sujet de l’automatisation des tests de régression à partir des logs vous intéresse, l’outil Gravity est proposé sous la forme d’une application Web disponible ici.

Il vous est aussi possible de visionner le Webinar sur Gravity du 27 janvier dernier, intitulé « Générez vos tests API Postman en 5mn grâce à vos logs ! ».