Métriques de test de logiciels : qu'est-ce que c'est, types et exemples ?
Thomas Hamilton
⚡ Résumé intelligent
Les métriques de test logiciel sont des mesures quantitatives de la progression, de la qualité et de la productivité d'un processus de test. Ce guide présente les trois types de métriques, la distinction entre métriques de base et métriques calculées, le cycle de vie des métriques et un glossaire de formules directement applicables.
Que sont les indicateurs de performance des tests logiciels ?
Métriques de test de logiciels sont les mesures quantitatives utilisées pour estimer la progression, la qualité, la productivité et la santé du processus de test de logiciels. L'objectif des mesures de test de logiciels est d'améliorer l'efficience et l'efficacité du processus de test de logiciels et d'aider à prendre de meilleures décisions pour la poursuite du processus de test en fournissant des données fiables sur le processus de test.
Une métrique exprime, en termes quantitatifs, le degré auquel un système, un composant ou un processus possède un attribut donné. On peut la comparer, par analogie, à la consommation hebdomadaire réelle de carburant d'une voiture par rapport à la consommation annoncée par le constructeur.
Métriques de test de logiciels – Améliore l’efficience et l’efficacité d’un processus de test de logiciels.
Les mesures de test de logiciels ou la mesure des tests de logiciels sont l'indication quantitative de l'étendue, de la capacité, de la dimension, de la quantité ou de la taille d'un attribut d'un processus ou d'un produit.
Exemple de mesure de test logiciel: Nombre total de défauts
Pourquoi les indicateurs de test sont-ils importants ?
« On ne peut améliorer ce qu’on ne mesure pas. » Les indicateurs de test existent pour rendre le processus de test mesurable.
- Déterminez quelle devrait être la prochaine phase des activités.
- Fournir des preuves à l'appui d'une affirmation ou d'une prédiction concernant la qualité
- Identifier le type d'amélioration nécessaire
- Justifier un changement de processus ou de technologie
En savoir plus sur son Importance des métriques de test
Types de métriques de test
- Métriques de processus : Il peut être utilisé pour améliorer l'efficacité du processus du SDLC (Cycle de vie du développement logiciel)
- Paramètres du produit : Il traite de la qualité du produit logiciel
-
Paramètres du projet : Il peut être utilisé pour mesurer l'efficacité d'une équipe de projet ou de tout autre outils de test utilisé par les membres de l'équipe
Choisir les bons indicateurs est plus important que d'en collecter un grand nombre. Avant de faire votre choix, tenez compte des points suivants :
- Fixer le public cible pour la préparation des métriques
- Définir l'objectif des métriques
- Introduire toutes les mesures pertinentes en fonction des besoins du projet
- Évaluez le rapport coût-bénéfice de chaque indicateur, ainsi que la phase du cycle de vie du projet au cours de laquelle il apporte le plus de valeur.
Métriques de test manuel
In Génie logiciel, Les métriques de test manuel sont classées en deux classes
- Métriques de base
- Métriques calculées
Les métriques de base sont les données brutes collectées par Test Analyst lors du développement et de l'exécution du scénario de test (# de cas de test exécutés, # de cas de test). Tandis que les métriques calculées sont dérivées des données collectées dans les métriques de base. Les métriques calculées sont généralement suivies par le gestionnaire de tests à des fins de rapport de test (% terminé, % de couverture du test).
Selon le projet ou le modèle économique, les indicateurs les plus importants sont généralement :
- Mesures de productivité de l'exécution des scénarios de test
- Mesures de productivité pour la préparation des cas de test
- Métriques de défauts
- Défauts par priorité
- Défauts par gravité
- Taux de glissement des défauts
Métriques de test manuel vs automatisé
Les indicateurs décrits ci-dessus supposent une suite de tests exécutée manuellement. Une suite automatisée est mesurée différemment, car l'effort d'exécution n'est plus un facteur limitant.
| Critères | Métriques de tests manuels | Métriques des tests d'automatisation |
|---|---|---|
| Objectif principal | Progrès des efforts et de l'exécution | Couverture, stabilité et autonomie |
| Mesure typique | Cas de test exécutés par jour | pourcentage de couverture de l'automatisation |
| Signal de qualité | Défauts constatés par heure de test | Taux de tests instables, la part des tests instables |
| mesure des coûts | Heures de testeur | Heures de maintenance des scripts par version |
| Mesure de vitesse | Durée du cycle en jours | Temps d'exécution de la suite en minutes |
Automation Coverage = (Test cases automated / Total test cases) x 100 Flaky Test Rate = (Tests with inconsistent results / Total automated tests) x 100
Le taux de tests instables mérite une attention particulière. Dès qu'il dépasse les 5 %, les équipes commencent à ignorer les versions défectueuses, et à ce stade, la suite de tests cesse de fournir des informations, quel que soit son niveau de couverture.
Cycle de vie des métriques de test en génie logiciel
| Différentes étapes du cycle de vie des métriques | Étapes à chaque étape |
|---|---|
| Analyse |
|
| Communiquez |
|
| Évaluation |
|
| Rapport |
|
Comment calculer une métrique de test
| Sr # | Étapes pour tester les métriques | Exemple |
|---|---|---|
| 1 | Identifier la clé test logiciel processus à mesurer | État d'avancement des tests tracprocessus roi |
| 2 | Dans cette étape, le testeur utilise les données comme référence pour définir les métriques | Le nombre de cas de test dont l'exécution est prévue par jour |
| 3 | Détermination des informations à suivre, une fréquence de tracroi et la personne responsable | L'exécution réelle des tests par jour sera capturée par le gestionnaire de tests à la fin de la journée. |
| 4 | Calcul, gestion et interprétation efficaces des métriques définies | Les cas de tests réels exécutés par jour |
| 5 | Identifier les axes d'amélioration en fonction de l'interprétation des métriques définies | If cas de test Si l'exécution est inférieure à l'objectif convenu, enquêtez sur la cause et proposez des mesures correctives. |
Exemple de calcul d'une métrique de test
Prenons comme exemple le pourcentage de cas de test exécutés. Pour exprimer l'état d'exécution en pourcentage, utilisez la formule :
Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100
Si 250 cas de test ont été écrits et que 175 ont été exécutés, le résultat est (175 / 250) x 100 = 70 pour cent.
Le même principe s'applique à tous les autres paramètres d'exécution : cas de test non exécutés, réussis, échoués et bloqués. Il s'agit simplement d'un numérateur différent pour un même dénominateur.
Métriques de test les plus importantes Track
Le glossaire à la fin de ce tutoriel répertorie toutes les formules couramment utilisées. En pratique, un ensemble de rapports n'en nécessite généralement que huit. Ce sont celles qui déterminent systématiquement une décision.
| Métrique | Ce que cela répond | Attention à |
|---|---|---|
| Pourcentage d'exécution des cas de test | Où en sommes-nous dans le parcours prévu ? | Cela ne dit rien sur la qualité, seulement sur le progrès. |
| Densité de défauts | Nombre de défauts par unité de taille : quel module est le plus faible ? | Cela dépend d'une mesure de taille cohérente |
| Efficacité d'élimination des défauts | Quel pourcentage de défauts avons-nous détectés avant la mise en production ? | Ne pourra être finalisé qu'après réception des données de production. |
| Fuite de défaut | Combien de défauts sont parvenus au client ? | Le signal de qualité le plus important |
| Couverture de test | Quelle proportion des exigences est mise en œuvre ? | Une forte couverture médiatique accompagnée d'affirmations faibles ne prouve rien. |
| Indice de gravité des défauts | Les défauts apparents sont-ils graves ou simplement d'ordre esthétique ? | Compter les défauts sans les pondérer est trompeur. |
| Délai moyen de réparation | L'équipe met-elle suffisamment de temps pour résoudre un problème ? | Déséquilibré par quelques défauts persistants |
| productivité de l'exécution des tests | Combien de cas un testeur traite-t-il par jour ? | Encourage les tests superficiels s'il est utilisé comme cible |
Deux formules qu'il convient d'ajouter au glossaire car ce sont celles que la direction demande :
Defect Removal Efficiency = (Defects found before release / Total defects found) x 100
Defect Leakage = (Defects found in production / Defects found before release) x 100
Le piège de la mesure. Toute métrique utilisée comme objectif cesse d'être pertinente. Fixez un objectif de productivité de 30 cas de test par jour et les testeurs en écriront 30, tous aussi triviaux les uns que les autres. Présentez les métriques de manière globale, jamais isolément, et associez chaque indicateur de productivité à un indicateur de qualité.
Glossaire des formules des métriques de test logiciel
- Ratio d'effort de reprise = (Efforts de retouche réels dépensés dans cette phase/efforts réels totaux dépensés dans cette phase) X 100
- Fluage des exigences = (Nombre total d'exigences ajoutées/Nombre d'exigences initiales)X100
- Écart d'horaire = (Date réelle de livraison – Date de livraison prévue)
- Coût de recherche d'un défaut lors des tests = (Effort total consacré aux tests/défauts trouvés lors des tests)
- Dérapage d'horaire = (Date de fin réelle – Date de fin estimée) / (Date de fin prévue – Date de début prévue) X 100
- Pourcentage de cas de test réussis = (Nombre de tests réussis/Nombre total de tests exécutés) X 100
- Pourcentage de cas de test ayant échoué = (Nombre de tests ayant échoué/Nombre total de tests exécutés) X 100
- Pourcentage de cas de test bloqués = (Nombre de tests bloqués/Nombre total de tests exécutés) X 100
- Pourcentage de défauts corrigés = (Défauts corrigés/Défauts signalés) X 100
- Pourcentage de défauts acceptés = (Défauts acceptés comme valides par l'équipe de développement / Total des défauts signalés) X 100
- Pourcentage de défauts différés = (Défauts reportés pour les versions futures /Total des défauts signalés) X 100
- Pourcentage de défauts critiques = (Défauts critiques / Total des défauts signalés) X 100
- Temps moyen nécessaire à une équipe de développement pour réparer les défauts = (Temps total nécessaire pour la correction des bugs/Nombre de bugs)
- Nombre de tests exécutés par période = Nombre de tests exécutés/Durée totale
- Efficacité de la conception des tests = Nombre de tests conçus /Durée totale
- Efficacité de l'examen des tests = Nombre de tests revus /Durée totale
- taux de détection des boguesou défauts par heure de test = Nombre total de défauts / Nombre total d'heures de test
