code coverage tutorial
Ce didacticiel complet explique ce qu'est la couverture du code dans les tests logiciels, ses types, ses avantages et ses inconvénients:
Le but ultime de toute entreprise de développement de logiciels est de développer des logiciels de bonne qualité. Pour atteindre cet objectif, le logiciel doit être minutieusement testé.
Les tests font donc partie intégrante du développement d'une application logicielle. Par conséquent, il est essentiel que le logiciel développé soit examiné par le développeur (ce qui est fait pendant la phase de test unitaire) puis transmis à l'équipe de contrôle de la qualité pour être minutieusement testé afin de s'assurer qu'il a peu ou pas de bogues.
Le logiciel est testé unitaire avant d'être mis à la disposition de l'équipe de test réelle pour des tests. Comme ces tests impliquent des tests au niveau du code, ils sont effectués par le développeur. Cela permet de garantir que chaque partie du code testé fonctionne comme prévu.
Ici, de petits morceaux de code qui ont été développés sont testés isolément pour garantir leur exactitude. Mais, la question qui se pose souvent dans l'esprit d'un développeur est combien de tests unitaires doivent être effectués et la réponse à cela réside dans la couverture du code.
Ce tutoriel vous donnera une connaissance approfondie de ce qu'est la couverture de code et pourquoi nous en avons besoin. Vous découvrirez en quoi cela diffère de la couverture de test.
Nous examinerons également les outils et les méthodologies utilisés pour la couverture du code et vers la fin de ce tutoriel, nous verrions les avantages ainsi que ses inconvénients. Certains des mythes associés à la couverture du code seraient également traités ici.
Ce que vous apprendrez:
Qu'est-ce que la couverture du code
Il s'agit d'une métrique de test unitaire importante. Il est utile de connaître l'efficacité des tests unitaires. C'est une mesure qui indique le pourcentage de code source qui serait exécuté lors des tests.
En termes simples, la mesure dans laquelle le code source d'un programme logiciel ou d'une application sera exécuté pendant les tests est ce que l'on appelle la couverture du code.
Si les tests exécutent l'intégralité du code, y compris toutes les branches, conditions ou boucles, alors nous dirions qu'il y a une couverture complète de tous les scénarios possibles et que la couverture du code est donc de 100%. Pour mieux comprendre cela, prenons un exemple.
Vous trouverez ci-dessous un code simple utilisé pour ajouter deux nombres et afficher le résultat en fonction de la valeur du résultat.
Input a, b Let c = a + b If c <10, print c Else, print ‘Sorry’
Le programme ci-dessus prend en deux entrées, à savoir «a» et «b». La somme des deux est stockée dans la variable c. Si la valeur de c est inférieure à 10, alors la valeur de «c» est imprimée sinon «Désolé» est imprimé.
Maintenant, si nous avons des tests pour valider le programme ci-dessus avec les valeurs de a & b telles que la somme est toujours inférieure à 10, alors la partie autre du code n'est jamais exécutée. Dans un tel scénario, nous dirions que la couverture n'est pas complète.
Ce n'était qu'un petit exemple pour clarifier la signification de la couverture du code. Au fur et à mesure que nous explorerons davantage, vous gagnerez en clarté.
Pourquoi nous avons besoin d'une couverture de code
(image la source )
Diverses raisons rendent la couverture du code essentielle et certaines d'entre elles sont énumérées ci-dessous:
à quoi ressemble un fichier json
- Cela aide à vérifier que le logiciel a moins de bogues par rapport au logiciel qui n'a pas une bonne couverture de code.
- En aidant à améliorer la qualité du code, il contribue indirectement à fournir un logiciel de meilleure «qualité».
- C'est une mesure qui peut être utilisée pour connaître l'efficacité des tests (efficacité des tests unitaires qui sont écrits pour tester le code).
- Aide à identifier les parties du code source qui ne seraient pas testées.
- Il aide à déterminer si les tests actuels (tests unitaires) sont suffisants ou non et si d'autres tests sont également nécessaires.
Couverture de code vs couverture de test
Pour comprendre la différence entre la couverture de code et la couverture de test, commençons par comprendre la signification de la couverture de test.
Couverture de test
Il s'agit d'une mesure du nombre de parties des tests attendus qui ont été couvertes lors du test d'un logiciel. Par «Test attendu» nous entendons l'ensemble complet des cas de test qui sont écrits pour être exécutés pour tester un logiciel donné.
Supposons que pour tester un logiciel, un ensemble de 500 cas de test au total ait été écrit. Désormais, dans le cadre de l'activité de test, seuls 300 cas de test ont été exécutés. Supposons que cela soit dû au manque de temps. Dans ce cas, ce qui suit serait la couverture du test.
Couverture de test = (Scénarios de test exécutés / Total des cas de test) * 100
= (300/500) * 100
= 60%
Comparons cela à ce qu'est la couverture du code.
Couverture de code
C'est une mesure qui montre dans quelle mesure un code source d'une application est exécuté pendant le test du code. Il montre ainsi dans quelle mesure un code source serait testé.
Supposons de tester une application avec 500 lignes de code, seules 400 lignes de code sont exécutées par des tests. Supposons que cela soit dû à une certaine boucle / condition qui n’est pas exécutée. Dans ce cas, ce qui suit serait la couverture du code.
Couverture du code = (nombre de lignes de code exécutées / nombre total de lignes de code) * 100
= (400/500) * 100
= 80%
Vous trouverez ci-dessous les différences entre la couverture de code et la couverture de test:
Couverture de test | Couverture de code |
---|---|
Il s'agit d'une mesure de la part des tests attendus qui a été couverte lors du test d'un logiciel. | C'est une mesure qui montre dans quelle mesure un code source d'une application est exécuté pendant le test du code. |
La couverture du test peut être calculée à l'aide de la formule ci-dessous: Couverture de test = (Scénarios de test exécutés / Total des cas de test) * 100 | La couverture du code peut être calculée à l'aide de la formule ci-dessous: Couverture du code = (nombre de lignes de code exécutées / nombre total de lignes de code) * 100 |
Méthodologies
Ici, nous discuterons des différentes méthodes qui sont / peuvent être utilisées pour mesurer la couverture du code.
Pour comprendre ces méthodologies, jetons un coup d'œil à l'extrait de code ci-dessous:
Add (int a, int b) { If (b > a) { b = b - a Print b } If (a > b) { b = a – b Print b } Else Print ‘0’ }
Couverture du relevé
Cette méthodologie est une mesure qui indique si toutes les instructions exécutables possibles de code dans le code source ont été exécutées au moins une fois. C'est une méthode pour s'assurer que chaque ligne du code source est couverte au moins une fois par les tests.
Cela peut sembler simple, mais il faut faire preuve de prudence lors de la mesure de la couverture du relevé. La raison en est que, dans un code source, il peut y avoir une certaine condition qui pourrait ne pas être exécutée en fonction des valeurs d'entrée.
Cela signifierait que toutes les lignes de code ne seraient pas couvertes par les tests. Ainsi, nous pouvons avoir à utiliser différents ensembles de valeurs d'entrée pour couvrir toutes ces conditions dans le code source.
Par exemple, dans le code source ci-dessus, si les valeurs d’entrée sont prises comme 2 et 3, la partie «Sinon» du code ne sera pas exécutée. Cependant, si les valeurs d’entrée sont de type 3 et 2, la partie «Si» du code ne sera pas exécutée.
Cela signifie qu'avec l'un ou l'autre ensemble de valeurs de notre couverture de relevé ne serait pas de 100%. Dans un tel cas, il se peut que nous devions exécuter les tests avec les trois ensembles de valeurs ((2, 3), (3, 2), (0, 0)) pour garantir une couverture de déclaration à 100%.
Couverture des fonctions
Comme son nom l'indique, cette méthodologie mesure dans quelle mesure les fonctions présentes dans le code source sont couvertes lors des tests. Toutes les fonctions présentes dans le code source sont testées lors de l'exécution du test. Encore une fois, il faut s'assurer que nous testons ces fonctions pour des valeurs variables afin que la fonction soit testée à fond.
Dans un code source, il peut y avoir plusieurs fonctions et, selon les valeurs d'entrée utilisées, une fonction peut ou non être appelée. Ainsi, le but de la couverture des fonctions est de garantir que chaque fonction est requise.
Par exemple, dans le code source ci-dessus, si nos tests appellent la fonction «Ajouter» une seule fois, alors nous l'appellerons comme une couverture de fonction complète.
Couverture de l'état
Dans un code source partout où nous avons une condition, le résultat serait une valeur booléenne vraie ou fausse. La couverture des conditions vise à déterminer si les tests couvrent les deux valeurs, c'est-à-dire vrai, faux.
comment déclarer la liste en java
Dans le code source, lorsque chaque condition se produisant est évaluée à la fois pour les états vrai et faux, alors la couverture de condition pour le code est dite complète.
Par exemple, dans le code ci-dessus, si les ensembles de valeurs (2, 3) et (4, 2) sont utilisés, la couverture de condition serait de 100%. Lorsque l'ensemble de données (2, 3) est utilisé, alors (b> a) prend la valeur true et (a> b) prend la valeur false. De même, lorsque l'ensemble de données (4, 2) est utilisé, alors (b> a) prend la valeur false et (a> b) prend la valeur true.
Ainsi, les deux conditions ont à la fois les valeurs, c'est-à-dire vrai et faux. Par conséquent, la couverture conditionnelle serait de 100%.
Couverture de la succursale
Cette méthodologie vise à garantir que chaque branche apparaissant dans chaque structure conditionnelle soit exécutée dans le code source. Par exemple, dans le code ci-dessus, toutes les instructions «Si» et toute instruction «Sinon» qui l’accompagne doivent toutes être couvertes par le test pour une couverture de succursale à 100%.
Par exemple, dans le code ci-dessus, si les ensembles de valeurs (2, 3), (4, 2), (1, 1) sont utilisés, la couverture de la succursale serait de 100%. Lorsque le jeu de données (2, 3) est utilisé, alors (b> a) et la première branche «If» est exécutée. De même, lorsque l’ensemble de données (4, 2) est utilisé, alors (a> b) s’évalue à vrai et la deuxième branche «If» est exécutée.
Ensuite, avec l'ensemble de données (1, 1), la branche «Else» prend la valeur true et est exécutée. Ainsi, assurant une couverture de succursale à 100%.
Couverture de la succursale par rapport à la couverture de l'état
La couverture des succursales est souvent confondue avec la couverture des maladies, mais les deux sont différentes.
Comprenons cela avec un exemple simple.
If (a >0) & (b >0) Then Print “Hello” Else Print “Bye”
Écrivons l'ensemble de données nécessaire pour terminer Couverture de la succursale:
(1, 1) - Dans ce cas, 'a' et 'b' sont tous les deux vrais, donc la condition If est exécutée.
(1, 0) - Dans ce cas, «a» est vrai et «b» serait faux, donc la partie Else du code est exécutée.
Comme nous le savons, l'objectif de la couverture des succursales est d'exécuter chaque succursale au moins une fois et cet objectif est atteint.
Couverture de l'état:
(1, 0) - Dans ce cas, «a» est vrai et «b» serait faux.
(0, 1) - Dans ce cas, «a» est faux et «b» serait vrai.
Le but de la couverture de condition est d'obtenir chacun des vrais et des faux pour chaque condition exécutée et cet objectif est atteint ici.
Avez-vous remarqué que l'autre partie n'est pas exécutée dans la couverture Condition? C'est là que la couverture des conditions diffère de la couverture des succursales.
Outils pour la couverture du code
Pour mesurer la couverture du code de n'importe quel logiciel, il existe plusieurs outils disponibles sur le marché.
Voici quelques-uns des outils pour votre référence:
- Parasoft JTest
- Testwell CTC ++
- Couverture
- JaCoCo
- CodeCover
- BullseyeCouverture
- EMMA
- OpenCover
- NCover
- Squish COCO
- CoverageMeter
- GCT
- TCAT C / C ++
- Gretel
- JCov
Lecture recommandée => Outils de couverture de code
Le lien ci-dessus comprendra les informations suivantes sur ces outils:
- Principales caractéristiques
- Type de licence
- URL officielle
- Avantages et inconvénients
- Dernière version
Avantages
Comme vu ci-dessus, il s'agit d'une métrique de test très utile pour les raisons ci-dessous:
- Cela aide à identifier les zones d'un code source qui resteraient non testées / découvertes par les tests.
- Il est pratique pour identifier le code utilisé / mort, améliorant ainsi la qualité du code.
- L'efficacité des tests unitaires peut être connue à l'aide de Code Coverage.
- Des logiciels de meilleure qualité peuvent être livrés à l'aide de ces métriques.
Désavantages
- Essayer de viser une couverture de code à 100% entraîne parfois un manque de robustesse des tests, ce qui fait passer à côté de la capture des scénarios sujets aux défauts.
- Contrairement à la perception courante, il ne peut garantir que le logiciel conçu répond à toutes les exigences.
Mythes vs faits
Mythe | Fait |
---|---|
Le fait d'avoir une couverture de code à 100% garantit que le logiciel n'aurait aucun bogue. | Non, une couverture de code à 100% ne peut garantir un logiciel sans bogue. Une bonne couverture de code associée à de bons efforts de la part de l'équipe de contrôle qualité peut garantir un logiciel avec peu ou pas de bogues. |
Avoir une couverture de code à 100% signifie que le code écrit est parfait. | Non, en fait, si des exigences importantes n'ont pas été capturées par le code en premier lieu, alors le code ne peut pas être qualifié de parfait bien que la couverture du code soit de 100%. |
La couverture de code mesure l'efficacité des tests effectués sur un produit logiciel. | Non, la couverture du code est simplement une mesure utilisée pour tester l'efficacité des tests unitaires, c'est-à-dire les tests exécutés sur le code source d'un logiciel uniquement. |
FAQ
Q # 1) Qu'est-ce qu'une couverture de code acceptable?
Répondre: Atteindre une couverture de code à 100% ne devrait pas être l'objectif lors du test unitaire du code logiciel. Mais pourquoi pas? Pour comprendre la raison, vous devrez peut-être plonger un peu plus profondément pour comprendre la signification sous-jacente.
Lorsque nous ciblons une couverture de 100%, il arrive plus souvent que toute l'attention dans la conception des tests soit de s'assurer que chaque instruction, boucle, branche ou condition est testée. Nous finissons donc par mettre trop d'efforts qui pourraient ne pas valoir la peine compte tenu du temps passé.
De plus, se concentrer sur une couverture élevée conduit également à passer à côté des scénarios importants susceptibles de présenter des défauts, car tout ce que nous visons est de nous assurer que chaque ligne de code est testée.
Se concentrer sur une couverture de code élevée n'est pas toujours aussi important et cela ne peut pas non plus être un nombre fixe à cibler pour tester différents codes. Cependant, en général, une couverture de 75% à 80% devrait être un nombre idéal.
Lors du test de notre code, l'objectif principal doit être de garantir la couverture des scénarios critiques et susceptibles de générer des erreurs. Si ceux-ci sont omis, malgré une couverture de code à 100%, nos tests auraient simplement une efficacité médiocre.
Q # 2) Comment vérifier ma couverture de code?
Répondre: Pour tester le pourcentage de couverture de code que vous pourriez avoir atteint par les tests conçus pour tester le code, nous avons plusieurs outils sur le marché. En fonction du langage de programmation utilisé, nous disposons de divers outils.
Certains d'entre eux sont énumérés ci-dessous:
- Java - Couverture, JaCoCo
- Javascript - Blanket.js, Istanbul
- Python - Coverage.py
- Rubis - SimpleCov
En utilisant ces outils, nous pouvons obtenir un rapport de couverture complet de nos tests qui nous aident à savoir quelle partie du code serait exécutée et laquelle serait manquée par nos tests.
Q # 3) La couverture de code est-elle une bonne métrique?
Répondre: Dans des scénarios réels, cela est utile dans une certaine mesure et de certaines manières particulières.
En regardant d'abord ses limites, nous savons très bien qu'avoir une couverture à 100% ne garantit pas que le code est exempt de bogues, ni ne garantit que toutes les exigences ont été couvertes dans le code, c'est-à-dire malgré une couverture de code à 100%, nous sommes très susceptible d'avoir des bogues dans le code, la raison étant que la couverture ne garantit pas que tous les scénarios ont été testés.
De plus, si des exigences ont été ignorées lors de l'écriture du code, il n'y a aucun mappage des exigences avec le code qui est pris en charge dans le cadre de la couverture du code.
Cela dit, nous ne pouvons pas nier que lorsque nous utilisons la couverture du code comme métrique, cela nous donne une idée si nous avons couvert les exigences de base pour tester chaque ligne de notre code. Ce pourcentage de couverture nous donne une idée du nombre de parties de notre code exécutées avec nos tests unitaires.
Nous arrivons à savoir combien de notre code ne serait pas exécuté. Cela nous aide à décider combien de tests unitaires supplémentaires sont nécessaires et pour quelles parties du code.
Nous pouvons donc conclure qu'une mauvaise couverture nous donne une idée de l'inefficacité des tests unitaires. En même temps, assurer une couverture à 100% n'est pas une garantie d'un code sans défaut. Il faut donc avoir une approche équilibrée dans laquelle nous ne surestimons pas l'importance de cibler un pourcentage de couverture de code élevé.
Q # 4) Comment puis-je améliorer ma couverture de code?
Répondre: Le rapport de couverture du code fourni par des outils de couverture tels que JaCoCo, Istanbul, etc. montre les zones couvertes par les tests ainsi que celles qui ne seraient pas testées.
En connaissant les parties non testées du code, les tests peuvent être écrits manuellement ou à l'aide de n'importe quel outil d'automatisation pour couvrir les zones qui autrement ne seraient pas testées et augmenter ainsi la couverture du code.
commande cut sous unix avec exemples
Une chose importante à noter ici est que bien que nous puissions écrire des centaines de lignes de code pour tester une fonction dans le code, la couverture peut être très inférieure. La raison en est qu'être trop profond pour tester une partie de l'énorme code n'aidera pas à augmenter la couverture du code.
Ainsi, si l'objectif est d'augmenter la couverture, il faut prendre soin de couvrir toutes les fonctions, conditions et boucles au lieu de plonger profondément dans une seule fonction et d'écrire de gros tests pour cette seule fonction.
Conclusion
Un produit logiciel de haute qualité est ce qui est requis dans le monde Internet en constante évolution.
Assurer un logiciel de bonne qualité n'est pas seulement la responsabilité d'un ingénieur QA, mais c'est également la responsabilité du développeur. Code Coverage est donc d'une grande utilité lorsqu'il s'agit de fournir un produit de qualité à l'équipe QA par le (s) développeur (s).
Ce didacticiel a tout expliqué sur la couverture du code et ses utilisations. Nous avons également approfondi notre compréhension de la différence entre la couverture du code et la couverture de test. En plus de cela, nous avons compris les méthodologies utilisées avec une variété d'outils de couverture de code.
Les avantages et les inconvénients ont été présentés ici. Enfin, nous avons brisé certains des mythes et FAQ associés à la couverture du code
Bonne lecture!!
lecture recommandée
- Top 15 des outils de couverture de code (pour Java, JavaScript, C ++, C #, PHP)
- 15 meilleurs outils JAVA pour le développement, la construction, le profilage, la couverture de code et la révision
- Tutoriel sur les fonctions / méthodes C # avec des exemples de code
- Tutoriel sur la gestion des exceptions C # avec des exemples de code
- Tutoriel Tortoise SVN: Révisions dans le référentiel de code
- Tutoriel Java Array Length avec des exemples de code
- Didacticiel AWS CodeBuild: extraction de code à partir de Maven Build
- Tutoriel SVN: Gestion du code source à l'aide de Subversion