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 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
modifierIl y a de nombreuses méthodes pour mesurer la couverture de code[3]. Les principales sont[4] :
- 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) - Toutes les conditions (tel que le test d'une variable) sont-elles exécutées et vérifiées ? (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 ».
É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é.
Pour valider le MC/DC, pendant le test, tous les points ci-dessous doivent être vrais au moins une fois[6] :
- 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
Articles connexes
modifier- Test de régression
- Non-régression
- Boîte blanche : à l'inverse de la boîte noire, on s'intéresse au fonctionnement interne d'un système (entrées et sorties) et on ne lui fait pas confiance.
- Méthode MC/DC
- Test de mutation
- Métrique (logiciel)
Outils de couverture de code
modifier- Testwell CTC++ pour C, C++, Java et C#
- LDRA pour C, C++, Java et Ada
- Xdebug pour PHP
- Compuware Xpediter Code Coverage pour Cobol/Assembleur/PLI sur mainframe z/OS
Notes et références
modifier- ↑ (en) Larry Brader, Howie Hilliker et Alan Wills, Testing for Continuous Delivery with Visual Studio 2012, Microsoft, 2 mars 2013, 248 p. (ISBN 978-1-62114-018-4 et 1-62114-018-0, lire en ligne), « Chapter 2 Unit Testing: Testing the Inside », p. 30
- ↑ (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)
- ↑ Benoit Gantaume, « Définition de la couverture de code illustrée avec JUnit », JUnit.fr, 3 avril 2012.
- ↑ (en) « Types of Model Coverage », MathWorks.
- ↑ RTCA/DO-178B « Software Considerations in Airborne Systems and Equipment Certification ».
- ↑ (en) Kelly Hayhurst, Dan Veerhusen, John Chilenski et Leanna Rierson, « A Practical Tutorial on Modified Condition/ Decision Coverage », NASA, mai 2001 (lire en ligne).
