Financé par l’UE et coordonné par Inria, le consortium Stamp vise à générer des tests automatiques pour DevOps. Cette automatisation permettrait de réduire le risque d’envoyer un bug en production. Démarré voici plus de deux ans, le projet a élaboré plusieurs outils innovants déjà disponibles en téléchargement, comme l’explique Caroline Landry, responsable technique.
Image par James Osborne de Pixabay
Google, Netflix et les autres géants du web livrent des centaines de milliers de mises à jour quotidiennes dans ce qui est devenu un torrent de production continue H24. Cette agilité leur confère un avantage concurrentiel en réduisant fortement les délais de mise sur marché. Secret de cette prouesse ? DevOps : une puissante méthode de développement logiciel qui vise à atteindre un haut niveau d’automatisation à toutes les étapes du développement et du déploiement. Néanmoins, le développement de tests automatiques pour toutes ces phases demeure manuel. Or, ces suites de tests devenant de plus en plus complexes, leur taille dépasse désormais souvent celle de l’application à tester. Si bien que les tests sont maintenant des logiciels à part entière, mais… non testés !
Créé dans cet objectif en décembre 2016, le consortium Stamp rassemble quatre partenaires académiques (Inria, KTH, SINTEF, TU Delft), cinq industriels (Activeeon, ATOS Spain, Engineering, TellU, XWiki), et OW2, une organisation pour le développement d’une base de logiciels d’infrastructure en open source.
Augmenter la couverture
“L’idée, ce n’est pas de générer de nouveaux tests à partir de rien, mais de se baser sur les tests déjà écrits par les développeurs, résume Caroline Landry, ingénieure de recherche dans l’équipe de génie logiciel DiverSE au centre Inria Rennes – Bretagne Atlantique. Après tout, ces développeurs sont les mieux placés pour savoir ce qu’il est important de tester. Mais leurs tests ne couvrent jamais vraiment 100% du code. D’où notre stratégie consistant à générer des variants, aussi appelés mutants. Notre projet distingue trois axes de recherche. D’abord l’amplification au niveau des tests unitaires. Ensuite au niveau de la configuration. Et pour finir, en production, après déploiement où nous générons de nouveaux tests basés sur des traces de l’exécution réelle, aussi appelées piles d’appels.”
Descartes
| Pour les tests unitaires, le consortium propose deux nouveaux outils, à commencer par Descartes. “Il permet d’évaluer la capacité de vos tests à détecter les bugs. Vous pouvez très bien avoir une suite de tests qui couvrent 100% de votre code, autrement dit qui exécutent toutes vos lignes de code. Pour autant, cela ne veut pas dire que les assertions, c’est-à-dire l’évaluation des résultats, sont correctes.” Pourquoi ? “Parce qu’en écrivant son test, un développeur a très bien pu oublier quelque-chose. Son test n’évalue donc pas forcément bien ce qu’il est censé tester.” | STAMP pour les développeurs à la commission européenne La technologie STAMP a été présentée au service IT de la commission européenne chargé du développement de tous les systèmes d’information de la commission. Cette présentation a été l’occasion pour les développeurs de la commission de voir l’intérêt des outils proposés par STAMP. Ils intègrent actuellement les outils du projet STAMP dans leur boite à outils pour le développement logiciel. |
Pour remédier à cela, les scientifiques utilisent ce que l’on appelle des tests par mutations. “Nous introduisons des anomalies, des bugs artificiels sous forme de petits changements de code. Ensuite, nous vérifions si, oui ou non, la suite de tests parvient à détecter ces changements. Nous faisons cela pour toutes les instructions du code source en exécutant à chaque fois la suite de tests. Nous obtenons ainsi un score de mutation. Il s’agit du ratio entre le nombre de mutants créés et ceux qui ont été effectivement détectés. Si certains bugs ajoutés passent inaperçus, alors il faut revoir les tests.” Pour effectuer cette analyse, les chercheurs utilisent PITest, un logiciel open source dédié au test par mutation dans les développements Java.
Analyse par mutations
Ceci dit, l’analyse par mutation est longue. Elle produit une énorme quantité de mutants. Mais surtout, elle se heurte à problème plus théorique : “certains mutants sont en fait… équivalents au code d’origine ! Ils se comportent de la même façon. Il n’y a pas moyen de les différencier. Du coup, nous nous sommes intéressés à l’extrême mutation, une approche introduite par le chercheur Rainer Niedermayr et des collègues en 2016. Au lieu de travailler sur l’instruction, on travaille au niveau de la méthode, dont on supprime toutes les instructions.” L’intérêt ? “Des temps de calcul beaucoup plus courts et un bien meilleur taux de détection. Nous avons pratiqué des analyses par mutation extrême sur des projets open source considérés comme bien testés et nous avons trouvé bon nombre de méthodes pseudo-testées.” Autrement dit : du code potentiellement à risque. Conçu spécifiquement pour détecter ces méthodes pseudo-testées, Descartes s’utilise comme un plugin de PITest.
DSpot
Après avoir détecté des tests défectueux, les chercheurs se sont dit qu’ils pourraient aussi générer automatiquement des corrections ou des propositions d’amélioration. “C’est tout l’objet de notre deuxième outil : DSpot. Il prend en entrée des cas de tests existants écrits par les développeurs, et génère en sortie des versions améliorées. Cette fois-ci, au lieu de faire muter le code de l’application, nous faisons muter les tests en changeant, par exemple, les paramètres dans les méthodes. Là-aussi, cette opération prend du temps. Donc, au lieu de faire cela sur tout le code, nous allons identifier les endroits faibles grâce à Descartes et ensuite utiliser DSpot sur ces endroits particuliers pour générer des variants de tests. Nous avons analysé plusieurs développements open source et nous sommes parvenus à générer un certain nombre de nouveaux tests.” Cette expérience a conduit les chercheurs à émettre des propositions de changements via GitHub, la plateforme de travail utilisée par énormément de développeurs. “À ce jour, sur 19 tests automatisés proposés, 13 ont été acceptés par les équipes de développement concernées.”
Camp
Descartes et DSpot résultent tous deux d’une collaboration entre Inria et KTH, en Suède. Le second axe de recherche, lui, implique Sintef, l’institut de recherche norvégien. “Nos collègues ont conçu un outil appelé Camp dont le rôle est d’amplifier les tests au niveau de la configuration. Il existe désormais tellement de versions d’un environnement qu’il devient difficile de tester exhaustivement le logiciel pour chacune d’entre elles. Camp va utiliser le fichier de configuration de Docker, le service de conteneurs logiciels. La configuration des machines virtuelles est décrite dans un fichier appelé Dockerfile. Celui-ci mentionne votre version Java, les bases de données et leur version, les navigateurs et leur version, la taille de la mémoire, etc. Docker produit toute la combinatoire de ces possibilités, sélectionne un sous-ensemble optimisé et génère tous les Dockerfiles correspondants. Camp reprend ensuite ces multiples fichiers afin d’exécuter les suites de tests pour toutes les configurations retenues. Membres du consortium, les entreprises Atos, Activeeon et TellU utilisent désormais Camp pour tester leurs logiciels. Quant à Engineering, elle l’a ajouté à son catalogue.”
Botsing
Le troisième axe de recherche s’intéresse au code une fois entré en production. “Quand un logiciel tombe en panne, il est toujours difficile de reconstituer le fil des événements qui a conduit à ce crash. L’enquête peut prendre beaucoup de temps. Nos collègues de l’Université de Delft (TUDelft) ont élaboré l’outil Botsing. Après chaque panne, Botsing récupère en entrée ce qu’on appelle une stack trace, c’est-à-dire une pile d’exécutions répertoriant toutes les fonctions appelées jusqu’au moment du crash. Ensuite, Botsing génère un test unitaire pour reproduire ce crash. Dans l’industrie, les développeurs s’y intéressent beaucoup car cela peut permettre d’identifier le morceau de code défectueux et de gagner énormément de temps.”
Tous ces outils open source sont d’ores et déjà disponibles en ligne de commande téléchargeables sur la plateforme GitHub. La plupart s’utilisent également comme plugin dans les environnements Maven, Eclipse, Gradle et Jenkins. “Les développeurs peuvent s’en servir pour vérifier l’efficacité de leurs propres tests. Descartes, par exemple, est déjà utilisé par des organisations extérieures au projet Stamp. Et nous encourageons les gens à s’en emparer, car nous avons besoin du feedback de l’industrie et de ses cas d’usage pour améliorer les outils.”
