UNIVERSITE DE YAOUNDE 1

INF 352
SOFTWARE TESTING
Rapport

Groupe 3 - Path Coverage

Élèves :
- NDONGWOU FLORINDA
22T2835
- TAMOKOUE SIMO 22Y1048
Enseignant :
- VOUKENG ZANGUE 22T2946
DR KIMBI
- TAGNY TAGNY IDRISS 21T2342
- NGONGANG NANA 21T2318
- POINTEU JUNIOR 22T2938
- TIOMELA ZANGUE 21U2144
 22 avril 2025

INF 352 Rapport - Groupe 3 - Path Coverage 2

 Table des matières
Table des matières
1 Introduction 2

2 Fondements du Path Coverage 2

2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Comparaison avec d’autres techniques de couverture . . . . . . . . . . . . . 2
2.3 Cas d’utilisation appropriés . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Méthodologie du Path Coverage 3

3.1 Étapes de mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Exemple illustratif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

4 Avantages et limites 4
4.1 Avantages du Path Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2 Limites et défis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3 Comparaison coût-efficacité . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5 Applications pratiques et outils 6

5.1 Domaines d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2 Outils de support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3 Bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

6 Conclusion 7

INF 352 Rapport - Groupe 3 - Path Coverage 1

 2 Fondements du Path Coverage
1 Introduction
Le test logiciel est un pilier essentiel pour garantir la qualité et la fiabilité des applica-
tions, particulièrement dans des domaines critiques comme l’aéronautique ou le médical.
Parmi les approches de test, le White Box Testing, qui repose sur l’analyse du code source,
se distingue par sa capacité à explorer la structure interne des programmes. Dans ce
cadre, la technique de Path Coverage joue un rôle clé en visant à tester tous les chemins
d’exécution possibles d’un programme, assurant ainsi une couverture exhaustive des flux
logiques. Ce rapport vise à définir le Path Coverage, expliquer son fonctionnement, analyser
ses avantages et limites, et illustrer son application à travers un exemple concret. Structuré
en sections claires, il offre une vision complète de cette technique essentielle pour les projets
nécessitant une fiabilité élevée.

2 Fondements du Path Coverage

2.1 Définition
Le Path Coverage est une technique de test en boîte blanche qui consiste à s’assurer
que tous les chemins d’exécution possibles dans le code d’un programme sont testés. Un
chemin représente une séquence unique d’instructions ou de décisions traversée lors de
l’exécution, déterminée par les structures de contrôle comme les conditions (if, else) ou
les boucles. Cette approche vise à garantir une couverture exhaustive des flux logiques,
permettant de détecter des erreurs potentielles dans des parties du code rarement exécutées.
Tester chaque chemin est crucial pour valider le comportement du logiciel dans toutes les
situations possibles, en particulier lorsque la fiabilité est primordiale.

2.2 Comparaison avec d’autres techniques de couverture

Le Path Coverage se distingue d’autres techniques de couverture utilisées dans le White
Box Testing par son niveau d’exhaustivité :
— Statement Coverage : Cette technique s’assure que chaque ligne de code exé-
cutable est parcourue au moins une fois. Elle est simple mais ne garantit pas que
toutes les décisions ou combinaisons logiques sont testées.
— Branch Coverage : Elle exige que chaque branche d’une structure de contrôle
(par exemple, les blocs if et else) soit exécutée au moins une fois. Bien que plus
rigoureuse que la Statement Coverage, elle ne couvre pas toutes les combinaisons
de décisions possibles.
— Path Coverage : Plus complète, cette technique teste chaque combinaison unique
de flux d’exécution, en tenant compte de toutes les séquences possibles de décisions.
Cela en fait une méthode plus approfondie mais aussi plus complexe à mettre en
œuvre.

INF 352 Rapport - Groupe 3 - Path Coverage 2

 3 Méthodologie du Path Coverage
2.3 Cas d’utilisation appropriés
Le Path Coverage est particulièrement adapté à des contextes où la fiabilité et la
robustesse du logiciel sont critiques. Il est souvent utilisé dans :
— Applications critiques : Les systèmes embarqués (par exemple, dans l’automobile
ou l’aéronautique), les dispositifs médicaux, ou les logiciels de contrôle où une
défaillance peut avoir des conséquences graves.
— Codes avec des logiques complexes : Les programmes comportant des conditions
imbriquées, des boucles multiples ou des dépendances logiques complexes bénéficient
grandement du Path Coverage, car il permet de tester des scénarios qui pourraient
être négligés par d’autres techniques.
Cette approche est idéale pour garantir que toutes les combinaisons de décisions sont
validées, réduisant ainsi les risques d’erreurs non détectées.

3 Méthodologie du Path Coverage

3.1 Étapes de mise en œuvre
La mise en œuvre du Path Coverage suit un processus systématique pour garantir que
tous les chemins d’exécution d’un programme sont testés :
— Analyse du code source : Examiner le code pour repérer les points de décision,
tels que les instructions if, else, boucles ou switch, qui influencent les flux
d’exécution.
— Construction d’un graphe de flux de contrôle : Représenter le programme sous
forme d’un graphe où les nœuds sont des blocs d’instructions et les arcs indiquent
les transitions possibles.
— Identification des chemins possibles : Lister toutes les séquences d’exécution
uniques (chemins) du graphe, de l’entrée à la sortie du programme.
— Conception de cas de test : Créer des cas de test avec des entrées spécifiques
pour parcourir chaque chemin identifié.
— Exécution et validation : Exécuter les tests et comparer les résultats obtenus
avec les résultats attendus pour vérifier le comportement du programme.

3.2 Exemple illustratif

Pour illustrer le Path Coverage, considérons un exemple simple :

def fonction(a, b):

if a > 0:
print("A positif")
else:
print("A non positif")
if b > 0:
print("B positif")
else:
print("B non positif")

INF 352 Rapport - Groupe 3 - Path Coverage 3

 4 Avantages et limites
# Exemple d’appel de la fonction
fonction(5, -3)
Construction du graphe de flux de contrôle : Le graphe montre deux décisions
(a > 0 et b > 0), générant quatre chemins possibles.
Liste des chemins possibles et cas de test :
— Chemin 1 : a > 0, b > 0
— Cas de test : a = 5, b = 10
— Chemin 2 : a > 0, b ≤ 0
— Cas de test : a = 5, b = −3
— Chemin 3 : a ≤ 0, b > 0
— Cas de test : a = −2, b = 7
— Chemin 4 : a ≤ 0, b ≤ 0
— Cas de test : a = −1, b = −4
Résultats attendus :

Figure 1 – Tableau des cas de test et résultats.

4 Avantages et limites
4.1 Avantages du Path Coverage
Le Path Coverage offre plusieurs atouts significatifs pour le test logiciel :

INF 352 Rapport - Groupe 3 - Path Coverage 4

 4 Avantages et limites
— Couverture exhaustive des flux d’exécution : En testant chaque chemin
possible dans le code, cette technique garantit qu’aucun flux logique n’est négligé,
réduisant les risques d’erreurs non détectées.
— Détection d’erreurs dans des chemins peu probables : Les chemins rarement
exécutés, souvent sources de bogues critiques, sont systématiquement testés.
— Amélioration de la fiabilité pour les systèmes critiques : Particulièrement
adapté aux applications où la fiabilité est essentielle, comme dans l’aéronautique
ou le médical, le Path Coverage renforce la robustesse du logiciel.

4.2 Limites et défis

Malgré ses avantages, le Path Coverage présente des contraintes importantes :
— Explosion combinatoire : Dans les programmes complexes avec de multiples
conditions ou boucles, le nombre de chemins peut croître exponentiellement, rendant
la couverture complète difficile, voire impossible.
— Coût élevé en temps et ressources : L’analyse du code, la construction des
graphes de flux, et la conception des cas de test exigent un investissement significatif
en temps et en expertise.
— Nécessité de mise à jour des tests : Toute modification du code peut invalider
les chemins existants, obligeant à revoir les cas de test, ce qui augmente les coûts
de maintenance.

4.3 Comparaison coût-efficacité

Le Path Coverage offre une couverture rigoureuse, mais son application doit être
équilibrée avec sa faisabilité. Dans les projets critiques, où la fiabilité prime, le coût élevé
peut être justifié par la réduction des risques. Cependant, pour des applications moins
complexes ou à faible criticité, des techniques comme la Statement Coverage ou la Branch
Coverage, moins coûteuses, peuvent suffire. Une analyse coûts-bénéfices est essentielle pour
déterminer si le Path Coverage est approprié, en tenant compte de la complexité du code
et des exigences du projet.

INF 352 Rapport - Groupe 3 - Path Coverage 5

 5 Applications pratiques et outils

Figure 2 – Tableau comparatif coût-efficacité des techniques de couverture.

5 Applications pratiques et outils

5.1 Domaines d’application
Le Path Coverage est largement utilisé dans des contextes exigeant une fiabilité élevée :
— Exemples concrets : Logiciels embarqués (automobile, aéronautique), systèmes
financiers (banques, trading), et applications médicales (moniteurs cardiaques,
dispositifs d’imagerie).
— Normes de qualité : Essentiel pour respecter des normes strictes comme DO-178C
dans l’aéronautique, qui exige une couverture complète des flux d’exécution pour
les logiciels critiques.

5.2 Outils de support

Des outils spécialisés facilitent l’application du Path Coverage :
— Outils de couverture de code : JaCoCo, SonarQube et Coverity analysent le
code et rapportent les chemins exécutés ou manquants.
— Génération de graphes de flux : Des outils comme Understand ou CodeSonar
génèrent automatiquement des graphes de flux de contrôle, simplifiant l’identification
des chemins.

INF 352 Rapport - Groupe 3 - Path Coverage 6

 6 Conclusion

Figure 3 – Capture d’écran d’un outil de couverture de code.

5.3 Bonnes pratiques

Pour optimiser l’utilisation du Path Coverage :
— Priorisation des chemins critiques : Se concentrer sur les chemins à haut risque
ou critiques pour réduire la complexité.
— Collaboration avec les développeurs : Travailler étroitement avec les program-
meurs pour comprendre la logique du code et identifier les chemins pertinents.
— Automatisation partielle : Utiliser des outils pour automatiser la génération des
cas de test et l’analyse des chemins, réduisant ainsi les coûts et le temps requis.

6 Conclusion
La technique de Path Coverage, essentielle au White Box Testing, garantit une couver-
ture exhaustive des chemins d’exécution d’un programme, renforçant la qualité logicielle
en détectant les erreurs dans des flux complexes. Malgré ses avantages, comme la fiabi-
lité accrue pour les systèmes critiques, elle est limitée par son coût élevé et l’explosion
combinatoire dans les codes complexes. Nous recommandons son utilisation ciblée dans
les projets critiques, comme l’aéronautique ou le médical, en combinaison avec d’autres
techniques comme la Branch Coverage pour optimiser la couverture. Avec l’évolution des
outils automatisés et la complexité croissante des logiciels modernes, le Path Coverage
gagnera en importance, nécessitant des solutions pour réduire sa complexité tout en
maintenant son efficacité.

INF 352 Rapport - Groupe 3 - Path Coverage 7