Couverture de code

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher
image illustrant l’informatique
Cet article est une ébauche concernant l’informatique.

Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.

Ce modèle est-il pertinent ? Cliquez pour en voir d'autres.
Cet article ne cite pas suffisamment ses sources (juillet 2010).

Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références » (modifier l'article, comment ajouter mes sources ?).

En génie logiciel, la couverture de code est une mesure utilisée pour décrire le taux de code source exécuté d'un programme quand une suite de test est lancée. Un programme avec une haute couverture de code, mesurée en pourcentage, a davantage de code exécuté durant les tests ce qui laisse à penser qu'il a moins de chance de contenir de bugs logiciels non détectés, comparativement à un programme avec une faible couverture de code.[1],[2] Différentes métriques peuvent être utilisées pour calculer la couverture de code; les plus basiques sont le pour le pourcentage de sous routine et le pourcentage d'instructions appelées durant l'exécution de la suite de test.

La mesure de ce taux implique souvent l'utilisation de tests unitaires.

Méthodes de couverture de code[3][modifier | modifier le code]

Il y a de nombreuses méthodes pour mesurer la couverture de code[4]. Les principales sont :

  • Couverture des fonctions (Function Coverage) - Chaque fonction dans le programme a-t-elle été appelée ?
  • Couverture des instructions (Statement Coverage) - Chaque ligne du code a-t-elle été exécutée et vérifiée ?
  • Couverture des points de tests (Condition Coverage) - Chaque point d'évaluation (tel que le test d'une variable) a-t-il été exécuté et vérifié ? (Le point de test teste-t-il ce qu'il faut ?)
  • Couverture des chemins d'exécution (Path Coverage) - Chaque parcours possible (par exemple les 2 cas vrai et faux d'un test) a-t-il été exécuté et vérifié ?

Certaines méthodes sont liées, par exemple :

  • La couverture des chemins implique à la fois la couverture des instructions et la couverture des points de tests ;
  • La couverture des instructions n'implique pas la couverture des points de tests, comme le montre le code ci-dessous (écrit en langage C) :
 void foo(int bar)
 {
    printf("this is ");
    if (bar < 1)
    {
       printf("not ");
    }
    printf("a positive integer");
 }

Si la fonction foo est appelée avec l'argument bar = -1, alors on assure la couverture des instructions (elles sont toutes exécutées) ; par contre, la couverture des points de tests n'est pas assurée.

Une couverture complète des chemins est généralement très difficile à accomplir, voire impossible :

  • Tout code contenant une succession de n points de tests contient potentiellement 2n chemins différents ; les boucles peuvent aboutir à un nombre infini de chemins possibles ;
  • Certains chemins sont parfois infranchissables, dans le sens où il n'existe pas de paramètre d'entrée du programme permettant de suivre ce chemin en particulier (les tests empêchant ce chemin sont souvent placés « par sécurité » au niveau d'une fonction) ;
  • Il n'existe pas d'algorithme général déterminant les chemins infranchissables (sinon un tel algorithme permettrait de résoudre le problème de l'arrêt).

La couverture de chemins consiste plus à regrouper les chemins par ressemblance (par exemple, ne différant que par le nombre de parcours de boucles) et à tester ces chemins « de base ».

Pour faciliter les tests, on instrumente le code source de façon à tracer l'exécution au cours des tests. La « trace » résultante est ensuite analysée pour identifier les chemins et les zones de code qui n'ont pas été vérifiés, puis les tests sont mis à jour (si nécessaire) pour améliorer la couverture. Combinée à d'autres méthodes, il est possible d'aboutir à un ensemble abordable (réaliste) de tests de non-régression.

La couverture de code accomplie est exprimée sous forme de pourcentage du code total. La signification de ce pourcentage dépend des types de couvertures effectuées : tester « 67 % des chemins possibles » est plus utile que « 67 % des instructions ».

Modified Condition/Decision Coverage (MC/DC)[modifier | modifier le code]

Également appelé « decision coverage », cette méthode est utilisée par la norme DO-178B[5] pour les logiciels soumis avec de très hauts critères de sécurité[6].

Pour valider le MC/DC, pendant le test, tous les points ci-dessous doivent être vrais au moins une fois[7] :

  • Chaque décision essaie toutes les issues possibles ;
  • Chaque condition, dans une décision, prend toutes les issues possibles ;
  • Chaque point d'entrée et de sortie est passé ;
  • Chaque condition dans une décision affecte indépendamment l'issue de la décision.

exemple :

 if ((a || b) && c)

les critères de décision/condition sont validés, si :

  • a=true, b=true, c=true
  • a=false, b=false, c=false

Cependant dans ce cas, b dans le premier test et c dans le second n'influence pas le résultat, il faudrait donc tester, pour satisfaire la méthode MC/DC, avec :

  • a=false, b=false, c=true
  • a=true, b=false c=true
  • a=false, b=true, c=true
  • a=false, b=true, c=false


Voir aussi[modifier | modifier le code]

Outils de couverture de code[modifier | modifier le code]

Notes[modifier | modifier le code]

  1. (en) Larry Brader, Howie Hilliker et Alan Wills, Testing for Continuous Delivery with Visual Studio 2012, Microsoft, (ISBN 1621140180, lire en ligne), « Chapter 2 Unit Testing: Testing the Inside », p. 30
  2. (en) Laurie Williams, Ben Smith et Sarah Heckman, « Test Coverage with EclEmma », sur Open Seminar Software Engineering, North Carolina State University (consulté le 16 juin 2016)
  3. (en) « Types of Model Coverage », MathWorks.
  4. Benoit Gantaume, « Définition de la couverture de code illustrée avec JUnit », JUnit.fr, 3 avril 2012.
  5. RTCA/DO-178B « Software Considerations in Airborne Systems and Equipment Certification ».
  6. DO-178B sur Wikipédia.
  7. (en) Kelly Hayhurst, Dan Veerhusen, John Chilenski et Leanna Rierson, « A Practical Tutorial on Modified Condition/ Decision Coverage », NASA,‎ (lire en ligne).