Le taux de couverture des tests de références est calculé de la manière suivante :
· On ajoute un appel à une méthode de comptage pour chaque ligne de code. Chaque appel
prend en paramètre un compteur qui devient son identifiant. Dans le même temps, on insère
dans une table de base de données une ligne correspondant à la ligne de code traitée, avec
bien sûr le même identifiant.
· Ensuite, lors de l’exécution de l’application instrumentée, après chaque ligne de code, il y
aura l’appel à la fonction de comptage. Cette dernière peut selon un paramétrage, soit
produire une trace XML donnant la liste des lignes appelées, soit mettre à jour directement
la ligne correspondant à son identifiant en base.
· Au final, on se retrouve avec une table contenant l’ensemble des lignes de l’application, et
pour chacune d’elle, un indicateur spécifiant si elle a été utilisée lors de l’exécution ou non.
De simples requêtes suffisent ensuite pour connaître le taux de couverture(24).
J’ai aussi développé un outil produisant un site web statique permettant de mieux visualiser le taux
de couverture (cf. Figure 31). La première version de l’outil de couverture était d’une certaine
manière plus « intelligente » car elle n’ajoutait pas d’appels à chaque ligne de code, mais
uniquement au début des méthodes et dans chaque branche (conditions, boucles), en indiquant le
nombre de lignes de code de chaque bloc. La Figure 32 démontre la nécessité d’instrumenter toutes
les lignes de l’application.
En effet, ici si l’instruction « CommonDialog.ShowPrinter » provoque une erreur, le reste des
lignes jusqu’au traitement d’erreur ne sera pas exécuté. Or, avec la logique précédente, dès l’entrée
dans la méthode, l’ensemble des lignes se trouvant hors d’une condition ou d’une boucle, aurait été
considérées comme passées, ce qui est faux, puisque la gestion d’erreur force le débranchement
jusqu’à la balise « ErrHandler: », donc les lignes 1013 à 1018 n’ont pas été exécutées.
de la classe « SdfMigration ».
24 Taux de couverture : (100 * nombre de lignes utilisées/nombre de lignes total)
Page suivante : 4.2.2 Cartographie dynamique, état des composants graphiques
Retour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance