{"id":595,"date":"2019-09-20T17:36:12","date_gmt":"2019-09-20T15:36:12","guid":{"rendered":"https:\/\/project.inria.fr\/emergences\/?p=595"},"modified":"2021-03-03T17:38:13","modified_gmt":"2021-03-03T16:38:13","slug":"amplifier-les-tests-pour-devops","status":"publish","type":"post","link":"https:\/\/project.inria.fr\/emergences\/amplifier-les-tests-pour-devops\/","title":{"rendered":"Amplifier les tests pour DevOps"},"content":{"rendered":"

Financ\u00e9 par l’UE et coordonn\u00e9 par Inria, le consortium Stamp vise \u00e0 g\u00e9n\u00e9rer des tests automatiques pour DevOps. Cette automatisation permettrait de r\u00e9duire le risque d’envoyer un bug en production. D\u00e9marr\u00e9 voici plus de deux ans, le projet a \u00e9labor\u00e9 plusieurs outils innovants d\u00e9j\u00e0 disponibles en t\u00e9l\u00e9chargement, comme l’explique Caroline Landry, responsable technique.<\/strong><\/span><\/p>\n

\n

 <\/p>\n

\"\"<\/a>

Image par James Osborne de Pixabay<\/p><\/div>\n

 <\/p>\n

Google, Netflix et les autres g\u00e9ants du web livrent des centaines de milliers de mises \u00e0 jour quotidiennes dans ce qui est devenu un torrent de production continue H24. Cette agilit\u00e9 leur conf\u00e8re un avantage concurrentiel en r\u00e9duisant fortement les d\u00e9lais de mise sur march\u00e9. Secret de cette prouesse ? DevOps : une puissante m\u00e9thode de d\u00e9veloppement logiciel qui vise \u00e0 atteindre un haut niveau d’automatisation \u00e0 toutes les \u00e9tapes du d\u00e9veloppement et du d\u00e9ploiement. N\u00e9anmoins, le d\u00e9veloppement de tests automatiques pour toutes ces phases demeure manuel. Or, ces suites de tests devenant de plus en plus complexes, leur taille d\u00e9passe d\u00e9sormais souvent celle de l’application \u00e0 tester. Si bien que les tests sont maintenant des logiciels \u00e0 part enti\u00e8re, mais… non test\u00e9s !<\/p>\n

Cr\u00e9\u00e9 dans cet objectif en d\u00e9cembre 2016, le consortium Stamp rassemble quatre partenaires acad\u00e9miques (Inria, KTH, SINTEF, TU Delft), cinq industriels (Activeeon, ATOS Spain, Engineering, TellU, XWiki), et OW2, une organisation pour le d\u00e9veloppement d\u2019une base de logiciels d\u2019infrastructure en open source.<\/p>\n

Augmenter la couverture<\/span><\/p>\n

\u201cL’id\u00e9e, ce n’est pas de g\u00e9n\u00e9rer de nouveaux tests \u00e0 partir de rien, mais de se baser sur les tests d\u00e9j\u00e0 \u00e9crits par les d\u00e9veloppeurs, r\u00e9sume Caroline Landry<\/strong><\/a>, ing\u00e9nieure de recherche dans l’\u00e9quipe de g\u00e9nie logiciel DiverSE<\/strong><\/a> au centre Inria Rennes \u2013 Bretagne Atlantique. Apr\u00e8s tout, ces d\u00e9veloppeurs sont les mieux plac\u00e9s pour savoir ce qu’il est important de tester. Mais leurs tests ne couvrent jamais vraiment 100% du code. D’o\u00f9 notre strat\u00e9gie consistant \u00e0 g\u00e9n\u00e9rer des variants, aussi appel\u00e9s 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\u00e8s d\u00e9ploiement o\u00f9 nous g\u00e9n\u00e9rons de nouveaux tests bas\u00e9s sur des traces de l’ex\u00e9cution r\u00e9elle, aussi appel\u00e9es piles d’appels.\u201d<\/em><\/p>\n

 <\/p>\n

Descartes<\/span><\/p>\n\n\n\n
Pour les tests unitaires, le consortium propose deux nouveaux outils, \u00e0 commencer par Descartes. \u201cIl permet d’\u00e9valuer la capacit\u00e9 de vos tests \u00e0 d\u00e9tecter les bugs. Vous pouvez tr\u00e8s bien avoir une suite de tests qui couvrent 100% de votre code, autrement dit qui ex\u00e9cutent toutes vos lignes de code. Pour autant, cela ne veut pas dire que les assertions, c’est-\u00e0-dire l’\u00e9valuation des r\u00e9sultats, sont correctes.\u201d Pourquoi ? \u201cParce qu’en \u00e9crivant son test, un d\u00e9veloppeur a tr\u00e8s bien pu oublier quelque-chose. Son test n’\u00e9value donc pas forc\u00e9ment bien ce qu’il est cens\u00e9 tester.\u201d<\/em><\/span><\/td>\nSTAMP pour les d\u00e9veloppeurs \u00e0 la commission europ\u00e9enne<\/span>
\nLa technologie STAMP a \u00e9t\u00e9 pr\u00e9sent\u00e9e au service IT de la commission europ\u00e9enne charg\u00e9 du d\u00e9veloppement de tous les syst\u00e8mes d’information de la commission. Cette pr\u00e9sentation a \u00e9t\u00e9 l\u2019occasion pour les d\u00e9veloppeurs de la commission de voir l\u2019int\u00e9r\u00eat des outils propos\u00e9s par STAMP. Ils int\u00e8grent actuellement les outils du projet STAMP dans leur boite \u00e0 outils pour le d\u00e9veloppement logiciel.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Pour rem\u00e9dier \u00e0 cela, les scientifiques utilisent ce que l’on appelle des tests par mutations. \u201cNous introduisons des anomalies, des bugs artificiels sous forme de petits changements de code. Ensuite, nous v\u00e9rifions si, oui ou non, la suite de tests parvient \u00e0 d\u00e9tecter ces changements. Nous faisons cela pour toutes les instructions du code source en ex\u00e9cutant \u00e0 chaque fois la suite de tests. Nous obtenons ainsi un score de mutation. Il s’agit du ratio entre le nombre de mutants cr\u00e9\u00e9s et ceux qui ont \u00e9t\u00e9 effectivement d\u00e9tect\u00e9s. Si certains bugs ajout\u00e9s passent inaper\u00e7us, alors il faut revoir les tests.\u201d<\/em> Pour effectuer cette analyse, les chercheurs utilisent PITest, un logiciel open source d\u00e9di\u00e9 au test par mutation dans les d\u00e9veloppements Java.<\/p>\n

Analyse par mutations<\/span><\/p>\n

Ceci dit, l’analyse par mutation est longue. Elle produit une \u00e9norme quantit\u00e9 de mutants. Mais surtout, elle se heurte \u00e0 probl\u00e8me plus th\u00e9orique : \u201ccertains mutants sont en fait… \u00e9quivalents au code d’origine ! Ils se comportent de la m\u00eame fa\u00e7on. Il n’y a pas moyen de les diff\u00e9rencier. Du coup, nous nous sommes int\u00e9ress\u00e9s \u00e0 l’extr\u00eame mutation, une approche introduite par le chercheur Rainer Niedermayr et des coll\u00e8gues en 2016. Au lieu de travailler sur l’instruction, on travaille au niveau de la m\u00e9thode, dont on supprime toutes les instructions.\u201d L’int\u00e9r\u00eat ? \u201cDes temps de calcul beaucoup plus courts et un bien meilleur taux de d\u00e9tection. Nous avons pratiqu\u00e9 des analyses par mutation extr\u00eame sur des projets open source consid\u00e9r\u00e9s comme bien test\u00e9s et nous avons trouv\u00e9 bon nombre de m\u00e9thodes pseudo-test\u00e9es.\u201d<\/em> Autrement dit : du code potentiellement \u00e0 risque. Con\u00e7u sp\u00e9cifiquement pour d\u00e9tecter ces m\u00e9thodes pseudo-test\u00e9es, Descartes s’utilise comme un plugin de PITest.<\/p>\n

DSpot<\/span><\/p>\n

Apr\u00e8s avoir d\u00e9tect\u00e9 des tests d\u00e9fectueux, les chercheurs se sont dit qu’ils pourraient aussi g\u00e9n\u00e9rer automatiquement des corrections ou des propositions d’am\u00e9lioration. \u201cC’est tout l’objet de notre deuxi\u00e8me outil : DSpot. Il prend en entr\u00e9e des cas de tests existants \u00e9crits par les d\u00e9veloppeurs, et g\u00e9n\u00e8re en sortie des versions am\u00e9lior\u00e9es. Cette fois-ci, au lieu de faire muter le code de l’application, nous faisons muter les tests en changeant, par exemple, les param\u00e8tres dans les m\u00e9thodes. L\u00e0-aussi, cette op\u00e9ration prend du temps. Donc, au lieu de faire cela sur tout le code, nous allons identifier les endroits faibles gr\u00e2ce \u00e0 Descartes et ensuite utiliser DSpot sur ces endroits particuliers pour g\u00e9n\u00e9rer des variants de tests. Nous avons analys\u00e9 plusieurs d\u00e9veloppements open source et nous sommes parvenus \u00e0 g\u00e9n\u00e9rer un certain nombre de nouveaux tests.\u201d<\/em> Cette exp\u00e9rience a conduit les chercheurs \u00e0 \u00e9mettre des propositions de changements via GitHub, la plateforme de travail utilis\u00e9e par \u00e9norm\u00e9ment de d\u00e9veloppeurs. \u201c\u00c0 ce jour, sur 19 tests automatis\u00e9s propos\u00e9s, 13 ont \u00e9t\u00e9 accept\u00e9s par les \u00e9quipes de d\u00e9veloppement concern\u00e9es.\u201d<\/em><\/p>\n

Camp<\/span><\/p>\n

Descartes et DSpot r\u00e9sultent tous deux d’une collaboration entre Inria et KTH, en Su\u00e8de. Le second axe de recherche, lui, implique Sintef, l’institut de recherche norv\u00e9gien. \u201cNos coll\u00e8gues ont con\u00e7u un outil appel\u00e9 Camp dont le r\u00f4le est d’amplifier les tests au niveau de la configuration. Il existe d\u00e9sormais 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\u00e9crite dans un fichier appel\u00e9 Dockerfile. Celui-ci mentionne votre version Java, les bases de donn\u00e9es et leur version, les navigateurs et leur version, la taille de la m\u00e9moire, etc. Docker produit toute la combinatoire de ces possibilit\u00e9s, s\u00e9lectionne un sous-ensemble optimis\u00e9 et g\u00e9n\u00e8re tous les Dockerfiles correspondants. Camp reprend ensuite ces multiples fichiers afin d’ex\u00e9cuter les suites de tests pour toutes les configurations retenues. Membres du consortium, les entreprises Atos, Activeeon et TellU utilisent d\u00e9sormais Camp pour tester leurs logiciels. Quant \u00e0 Engineering, elle l’a ajout\u00e9 \u00e0 son catalogue.\u201d<\/em><\/p>\n

Botsing<\/span><\/p>\n

Le troisi\u00e8me axe de recherche s’int\u00e9resse au code une fois entr\u00e9 en production. \u201cQuand un logiciel tombe en panne, il est toujours difficile de reconstituer le fil des \u00e9v\u00e9nements qui a conduit \u00e0 ce crash. L’enqu\u00eate peut prendre beaucoup de temps. Nos coll\u00e8gues de l’Universit\u00e9 de Delft (TUDelft) ont \u00e9labor\u00e9 l’outil Botsing. Apr\u00e8s chaque panne, Botsing r\u00e9cup\u00e8re en entr\u00e9e ce qu’on appelle une stack trace, c’est-\u00e0-dire une pile d’ex\u00e9cutions r\u00e9pertoriant toutes les fonctions appel\u00e9es jusqu’au moment du crash. Ensuite, Botsing g\u00e9n\u00e8re un test unitaire pour reproduire ce crash. Dans l’industrie, les d\u00e9veloppeurs s’y int\u00e9ressent beaucoup car cela peut permettre d’identifier le morceau de code d\u00e9fectueux et de gagner \u00e9norm\u00e9ment de temps.\u201d<\/em><\/p>\n

Tous ces outils open source sont d’ores et d\u00e9j\u00e0 disponibles en ligne de commande t\u00e9l\u00e9chargeables sur la plateforme GitHub. La plupart s’utilisent \u00e9galement comme plugin dans les environnements Maven, Eclipse, Gradle et Jenkins. \u201cLes d\u00e9veloppeurs peuvent s’en servir pour v\u00e9rifier l’efficacit\u00e9 de leurs propres tests. Descartes, par exemple, est d\u00e9j\u00e0 utilis\u00e9 par des organisations ext\u00e9rieures au projet Stamp. Et nous encourageons les gens \u00e0 s’en emparer, car nous avons besoin du feedback de l’industrie et de ses cas d’usage pour am\u00e9liorer les outils.\u201d<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Financ\u00e9 par l’UE et coordonn\u00e9 par Inria, le consortium Stamp vise \u00e0 g\u00e9n\u00e9rer des tests automatiques pour DevOps. Cette automatisation permettrait de r\u00e9duire le risque d’envoyer un bug en production. D\u00e9marr\u00e9 voici plus de deux ans, le projet a \u00e9labor\u00e9 plusieurs outils innovants d\u00e9j\u00e0 disponibles en t\u00e9l\u00e9chargement, comme l’explique Caroline\u2026<\/p>\n

En savoir plus<\/span><\/i><\/a> <\/p>\n","protected":false},"author":1891,"featured_media":596,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7,1],"tags":[30],"class_list":["post-595","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-recherche","category-uncategorized","tag-30"],"_links":{"self":[{"href":"https:\/\/project.inria.fr\/emergences\/wp-json\/wp\/v2\/posts\/595","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/project.inria.fr\/emergences\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/project.inria.fr\/emergences\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/project.inria.fr\/emergences\/wp-json\/wp\/v2\/users\/1891"}],"replies":[{"embeddable":true,"href":"https:\/\/project.inria.fr\/emergences\/wp-json\/wp\/v2\/comments?post=595"}],"version-history":[{"count":2,"href":"https:\/\/project.inria.fr\/emergences\/wp-json\/wp\/v2\/posts\/595\/revisions"}],"predecessor-version":[{"id":598,"href":"https:\/\/project.inria.fr\/emergences\/wp-json\/wp\/v2\/posts\/595\/revisions\/598"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/project.inria.fr\/emergences\/wp-json\/wp\/v2\/media\/596"}],"wp:attachment":[{"href":"https:\/\/project.inria.fr\/emergences\/wp-json\/wp\/v2\/media?parent=595"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/project.inria.fr\/emergences\/wp-json\/wp\/v2\/categories?post=595"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/project.inria.fr\/emergences\/wp-json\/wp\/v2\/tags?post=595"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}