# Couverture de code

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$^,$. 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

Il y a de nombreuses méthodes pour mesurer la couverture de code. 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) - 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) :
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 2$^n$ 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)

Également appelé « decision coverage », cette méthode est utilisée par la norme DO-178B 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 :
* 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 :
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