Qu'est-ce que la densité de défauts ? Formule à calculer avec Exemple

Qu’est-ce que la densité des défauts ?

Densité des défauts Le taux de défauts (ou taux de défaillance) correspond au nombre de défauts confirmés dans un logiciel ou un module au cours d'une période donnée d'exploitation ou de développement, divisé par la taille de ce logiciel ou module. Il permet à une équipe de déterminer si un logiciel est prêt à être mis en production.

La densité de défauts est calculée pour mille lignes de code (KLOC). Comme ce nombre est normalisé par la taille du module, il est possible de comparer un grand module comportant de nombreux défauts et un petit module en comportant peu, ce qu'un simple décompte des bogues ne permet pas.

Cette mesure est généralement communiquée à la fin d'un cycle de test et tracsortie ked sur sortie, elle se trouve donc aux côtés du reste des processus de gestion des défauts dans le cycle de vie des tests logiciels.

Comment calculer la densité de défauts

Une formule pour mesurer la densité des défauts :

Defect Density = Defect count/size of the release

La taille d'une version peut être mesurée en termes de lignes de code (LOC).

Trois détails déterminent si le nombre obtenu a une signification :

• L'unité de taille. Les lignes de code (LOC) et les milliers de lignes de code (KLOC) sont les unités les plus courantes. Les points de fonction sont utilisés lorsque les équipes souhaitent une mesure de taille indépendante du langage de programmation ; certaines équipes préfèrent normaliser par module ou par composant.
• Qu'est-ce qui est considéré comme un défaut ? Seuls les défauts confirmés doivent figurer au numérateur. Les doublons, les rapports rejetés et les demandes d'amélioration doivent être exclus, sous peine de voir le chiffre gonfler sans que la qualité du code ne s'en trouve améliorée.
• La fenêtre de mesure. Défauts constatés lors des tests système, pendant les tests de régressionet après la publication, décrivent différentes choses, la période doit donc être indiquée avec le nombre.

Exemple de densité de défauts

Supposons que votre logiciel intègre 3 modules. Chaque module présente le nombre de bogues suivants :

• Module 1 = 10 bogues
• Module 2 = 20 bogues
• Module 3 = 10 bogues

Nombre total de bugs = 10 + 20 + 10 = 40

Le nombre total de lignes de code pour chaque module est :

• Module 1 = 1000 LOC
• Module 2 = 1500 LOC
• Module 3 = 500 LOC

Ligne totale de Code = 1000+1500+500 = 3000

La densité des défauts est calculée comme suit :

Defect Density = 40/3000 = 0.013333 defects/loc = 13.333 defects/Kloc

Le même calcul appliqué à chaque module est plus utile que le chiffre combiné, comme le montre le graphique ci-dessous : le module 2 comporte 20 défauts en 1 500 lignes de code et le module 3 comporte 10 défauts en seulement 500 lignes de code ; le module 3 est donc plus dense et plus risqué des deux, même s’il a signalé moins de bogues.

Une norme pour la densité des défauts

Il n'existe pas de norme fixe pour la densité de défauts. Des études suggèrent que… défaut Le nombre de lignes de code par millier est généralement considéré comme un signe de bonne qualité de projet, et ce chiffre est la règle empirique la plus couramment citée dans le secteur.

Les exigences varient selon le domaine. Les logiciels critiques et réglementés, tels que l'avionique et les dispositifs médicaux, sont soumis à un objectif de défauts bien inférieur à un défaut par kiloligne de code (KLOC), tandis que les applications métiers courantes dépassent généralement ce seuil. Les règles de comptage, les unités de mesure et la profondeur des tests étant différentes d'une organisation à l'autre, une référence issue d'une étude publiée n'est comparable qu'à un projet utilisant la même méthodologie. L'utilisation pratique de cette métrique est donc interne : comparer une version à la version précédente du même produit, mesurée de manière identique.

Facteurs influençant la densité des défauts

Une même base de code peut produire des chiffres de densité de défauts très différents en fonction des facteurs suivants :

• Code complexité. Logique profondément imbriquée et haut niveau complexité cyclomatique produire plus de défauts par ligne qu'un code simple.
• Types de défauts pris en compte. En ne comptant que les défauts fonctionnels, ou en incluant l'utilisabilité, la documentation et non fonctionnel Les résultats modifient sensiblement le numérateur.
• La durée considérée. Une valeur mesurée sur un cycle de test de deux semaines n'est pas comparable à une valeur mesurée sur six mois d'utilisation en production.
• Compétences de développeur et de testeur. Les développeurs expérimentés commettent moins d'erreurs, et les testeurs expérimentés en détectent davantage parmi celles qui existent ; ces deux effets tirent donc la métrique dans des directions opposées.
• Couverture des tests. Les défauts qui n'ont jamais été recherchés ne sont jamais comptabilisés, donc Couverture de test limite silencieusement la valeur maximale que peut atteindre la densité mesurée.

Densité de défauts par rapport à d'autres indicateurs de défauts

La densité des défauts répond à une question : quel est le niveau de concentration des défauts connus ? Trois indicateurs complémentaires répondent aux questions auxquelles elle ne peut répondre, et la plupart des équipes les communiquent conjointement.

Pris ensemble, ces quatre éléments donnent une image plus complète : une faible densité de défauts avec des points de fuite de défauts élevés lors de tests superficiels plutôt que dans un code propre, ce qui correspond précisément à l’erreur d’interprétation que la section suivante met en garde.

Avantages de la densité de défauts

Voici les avantages de la densité de défauts :

• Cela permet de mesurer l'efficacité des tests.
• Cela permet de différencier la concentration des défauts entre les composants et les modules logiciels.
• Il est utile pour identifier les domaines qui nécessitent une correction ou une amélioration.
• Il est utile pour identifier les composants à haut risque, ce qui alimente directement tests basés sur les risques.
• Cela permet d'identifier les besoins de formation des différentes ressources.
• Cela peut s'avérer utile pour estimer les efforts de test et de retouche engendrés par les défauts.
• Il peut estimer les défauts restants dans le logiciel.
• Avant la mise en production, cela permet de déterminer si les tests effectués jusqu'à présent sont suffisants.
• Elle permet d'établir une base de référence historique par rapport à laquelle les versions ultérieures pourront être évaluées.

Limites de la densité de défauts

Cet indicateur est facile à calculer, mais aussi facile à mal interpréter. Les limitations suivantes déterminent son importance dans une décision de publication :

• Les défauts non détectés sont invisibles. Le numérateur ne tient compte que des défauts effectivement détectés lors des tests ; un module peu testé affichera donc un chiffre flatteur.
• La gravité n'est pas prise en compte. Un défaut qui compromet un paiement et un problème d'alignement cosmétique ont le même impact, c'est pourquoi une analyse pondérée par la gravité est nécessaire en parallèle.
• Les définitions des défauts varient. Deux équipes qui comptent différemment produisent des chiffres qui ne sont pas comparables, même au sein d'une même organisation.
• Le nombre de lignes de code est un indicateur de taille peu fiable. Un code verbeux diminue la densité sans rien améliorer, et l'unité n'est pas comparable d'un langage de programmation à l'autre.
• Cette mesure peut être manipulée. Rejeter les rapports limites ou gonfler le nombre de lignes améliorent tous deux le chiffre sans améliorer le produit.

Rien de tout cela ne rend la densité de défauts inutile. Cela en fait un indicateur de tendance pour un produit, mesuré de manière constante, plutôt qu'un score permettant de comparer des équipes entre elles.

Comment réduire la densité des défauts

Réduire réellement la densité des défauts, et non pas seulement sur le papier, signifie prévenir les défauts plus tôt et détecter les autres avant la mise en production. Les pratiques ci-dessous sont celles qui reviennent fréquemment dans les guides publiés :

• Avancer les tests. Impliquer les testeurs dès la phase de définition des exigences et de conception permet de déceler les ambiguïtés avant qu'elles ne se transforment en code, là où les défauts sont les plus faciles à corriger.
• RevVérifiez le code avant la fusion. L'évaluation par les pairs permet de déceler les erreurs de logique, les interprétations erronées des exigences et les défauts de conception qui ne sont pas détectés par les pairs. Test de l'unité a été écrit pour rechercher.
• Automatisez la suite de tests de régression. Exécution de vérifications sur chaque commit via intégration continue empêche la réapparition d'anciens défauts pendant l'écriture du nouveau code.
• Commencez par rédiger les tests. Développement piloté par les tests oblige à spécifier chaque comportement avant sa mise en œuvre, et test de mutation peut alors confirmer que les tests obtenus affirment bien quelque chose.
• Utilisez l'analyse statique. L'analyse automatisée du code détecte les déréférencements nuls, les fuites de ressources et les points chauds de complexité avant même l'exécution du premier test.
• Refactorisez les modules denses. Une fois que l'analyse de la densité des défauts a identifié les composants les plus problématiques, leur division et leur simplification permettent généralement de réduire à la fois la complexité et le nombre de défauts.
• Réintégrer les défauts dans le processus. L'analyse des causes profondes lors des rétrospectives transforme les défauts individuels en correctifs de processus plutôt qu'en solutions ponctuelles.

TracSortie de Ked sur sortie parallèle techniques de test de logiciels et grâce aux données de couverture, la densité des défauts devient un système d'alerte précoce plutôt qu'un bulletin scolaire.

FAQ