Concepts : Mesures clés du test
Rubriques
Les mesures clés d'un test comprennent la couverture et la qualité.
La couverture du test est la mesure de l'achèvement du test et se base sur la couverture des tests exprimée par la couverture des exigences du test et des cas de test ou par la couverture du code exécuté.
La qualité est une mesure de la fiabilité, de la stabilité et de la performance de la cible du test (système ou application testée). La qualité se base sur l'évaluation des résultats du test et l'analyse des demandes de changement (anomalies) identifiées pendant le test.
Les mesures de la couverture fournissent des réponses à la question: "Quel est l'état d'achèvement du test ?" Les mesures de couverture les plus couramment utilisées sont basées sur la couverture des exigences logicielles et du code source. En fait, la couverture du test est toute mesure de l'état d'achèvement par rapport à soit une exigence (basée exigence), soit les critères de conception et d'implémentation du code (basée code), comme la vérification des cas d'utilisation (basée exigence) ou l'exécution des toutes les ligne du code (basée code).
Toute activité de test symétrique se base sur au moins une stratégie de couverture de test. La stratégie de couverture oriente la conception des cas de test en indiquant l'objet général du test. La déclaration de stratégie de couverture peut être aussi simple que la vérification de toutes les performances.
Une stratégie de couverture basée sur les exigences peut être suffisante pour produire une mesure quantifiable de l'état d'achèvement du test si les exigences en entièrement cataloguées.
Par exemple, si toutes les exigences du test de performance ont été identifiées, les résultats du test peuvent donc être référencés pour prendre les mesures ; par exemple, 75% des exigences du test de performance ont été vérifiées.
Si la couverture basée sur le code est appliquée, les stratégies de test sont formulées dans les termes suivants : combien du code source a été exécuté par test. Ce type de stratégie de couverture de test est très important pour les systèmes pour lesquels la sécurité est critique.
Les deux mesures peuvent être prises manuellement (à l'aide des équations données dans les deux rubriques suivantes) ou peuvent être calculées à l'aide d'outils d'automatisation de test.
La couverture de test basée sur les exigence, mesurée plusieurs fois pendant le cycle de vie du test, identifie la couverture du test à un jalon dans le cycle de vie du test, comme la couverture de test planifiée, implémentée, exécutée et réussie.
- La couverture de test est calculée à l'aide de l'équation suivante :
Couverture de test = T(p,i,x,s) / RfT
où :
T est le nombre de Tests (planifié, implémenté, exécuté, ou réussi), exprimé sous forme de procédures de test ou de cas de test.
RfT est le nombre total d'exigences pour le test.
- Dans l'activité Planifier le test, la couverture du test est calculée afin de déterminer la couverture de test planifié de la façon suivante :
Couverture de test (planifié) = Tp / RfT
où :
Tp est le nombre de tests planifiés, exprimé sous forme de procédures de test ou de cas de test.
RfT est le nombre total d'exigences pour le test.
- Dans l'activité Implémenter le test, alors que les procédures de test sont en cours d'implémentation (sous forme de scripts de test), la couverture de test est calculée avec l'équation suivante :
Couverture de test (implémenté) = Ti /
RfT
où :
Ti est le nombre de tests implémentés, exprimé par le nombre de procédures de test ou de cas de test pour lesquels il existe des scripts de test correspondants.
RfT est le nombre total d'exigences pour le test.
Couverture de test réussi (exécuté) = Ts
/ RfT
où :
Ts est le nombre de Tests exécutés, exprimé sous forme de procédures de test ou de cas de test qui se sont terminés avec succès, sans anomalie.
RfT est le nombre total d'exigences pour le test.
Transformer les rapports ci-dessus en pourcentages permet d'affirmer ce qui suit sur la couverture de test basée sur les exigences :
x% des cas de test (T(p,i,x,s) dans les équations ci-dessus) ont été couverts avec un taux de réussite de y%
Cette affirmation significative de la couverture de test peut être mise en relation avec des critères de réussite définis. Si les critères sont remplis, l'affirmation sert donc de base pour prévoir l'effort de test restant à fournir.
La couverture de test basée sur le code mesure la quantité de code exécutée pendant le test par rapport à la quantité de code restant à exécuter. La couverture du code peut se baser sur des flux de contrôle (instruction, branche ou chemins) ou flux de données.
- Dans la couverture flux de contrôle, l'objectif est de tester des lignes de code, des conditions de branche, des chemins à travers le code, ou d'autres éléments du flux de contrôle du logiciel.
- Dans la couverture flux de données, l'objectif est de tester que les états des données restent valides tout au long de l'exécution du logiciel ; par exemple, qu'un élément de donnée est défini avant d'être utilisé.
La couverture de test basée sur le code se calcule avec l'équation suivante :
Couverture de test = Ie / TIic
où :
Ie est le nombre d'éléments exécutés, exprimé sous forme d'instructions de code, de branches de code, de chemins de code, de points de décision d'état de données, ou de noms d'élément de donnée.
TIic est le nombre total d'éléments du code.
Transformer ce rapport en pourcentage permet d'affirmer ce qui suit sur la couverture de test basée sur le code :
x% des cas de test cases (I dans l'équation ci-dessus) ont été couverts avec un taux de réussite de y%
Cette affirmation significative de la couverture de test peut être mise en relation avec des critères de réussite définis. Si les critères sont remplis, l'affirmation sert donc de base pour prévoir l'effort de test restant à fournir.
Bien que l'évaluation de la couverture de test fournisse une mesure de l'étendue de l'état d'achèvement d'un effort de test, l'évaluation des anomalies pendant le test fournit la meilleure indication sur la qualité du logiciel telle qu'elle a été perçue. Cette perception de qualité peut servir à réfléchir sur la qualité générale du système logiciel dans son ensemble. La qualité perçue du logiciel est une mesure du niveau de conformité du logiciel aux exigences. Dans ce contexte, les anomalies sont donc considérées comme un type de demande de changement dans lequel la cible du test n'a pas répondu aux exigences logicielles.
L'évaluation des anomalies peut se baser sur des méthodes allant du simple décompte des anomalies à une modélisation statistique rigoureuse.
Une évaluation rigoureuse utilise les hypothèses sur les taux d'arrivée ou de découverte d'anomalies en cours de test. Un modèle commun part du principe que le taux suit la loi de Poisson. Les données réelles sur les taux d'anomalies correspondent alors au modèle. L'évaluation qui en résulte estime la fiabilité actuelle du logiciel et prévoit combien sa fiabilité évoluera si l'on poursuit les tests et la suppression des anomalies.
Cette évaluation est appelée modélisation de l'évolution de la fiabilité du logiciel et constitue un domaine activement étudié. En raison du manque d'outils de soutien pour ce type d'évaluation, il vous faudra étudier soigneusement le coût d'utiliser cette approche par rapport aux avantages que vous en tirerez.
L'analyse des anomalies implique l'analyse de la distribution des anomalies sur les valeurs d'un ou plusieurs des attributs associés à l'anomalie.
L'analyse des anomalies fournit une indication sur la fiabilité du logiciel.
Dans l'analyse des anomalies, quatre principaux attributs d'anomalie sont couramment analysés :
- Etat - l'état actuel de l'anomalie (ouverte, en cours de correction, fermée, etc.).
- Priorité - l'importance relative de l'anomalie en cours de résolution.
- Gravité - l'impact relatif de cette anomalie sur l'utilisateur final, une organisation, des tiers, etc.
- Source - l'endroit et l'élément déclencheur de l'erreur entraînant l'anomalie ou l'élément à corriger pour éliminer l'anomalie.
Le nombre d'anomalies peut être rapporté sous forme de fonction de temps, en créant un diagramme ou un rapport de tendance des anomalies. Elles peuvent également être signalées dans un rapport de densité en tant que fonction d'un ou plusieurs attributs d'anomalie, comme la gravité ou l'état. Ces types d'analyse fournissent une perspective sur les tendances ou sur la distribution des anomalies qui révèle la fiabilité du logiciel.
Par exemple, on s'attend à ce que le taux de découverte des anomalies finisse par baisser au fur et à mesure des tests et corrections. Un seuil d'anomalie ou de mauvaise qualité au-dessous duquel la qualité du logiciel est jugée inacceptable peut être fixé. Le nombre d'anomalies peut également être signalé sur la base de l'origine dans le modèle d'implémentation, permettant de détecter les "modules faibles", les "points sensibles", et les parties du logiciel nécessitant toujours une correction, ce qui indique des défauts de conception plus fondamentaux.
Seuls les défauts confirmés sont compris dans une analyse de ce genre. Toutes les anomalies signalées ne signifient pas un défaut ; certaines peuvent être des demandes d'amélioration dépassant la portée du projet, ou peuvent décrire une anomalie déjà signalée.
Toutefois, cela vaut la peine d'étudier et d'analyser pourquoi beaucoup d'anomalies, soit des doublons soit des anomalies non confirmées, sont signalées.
Le Rational Unified Process recommande une évaluation des anomalies basée sur diverses catégories de rapports, comme suit :
- Les rapports sur la distribution des anomalies (Densité) permettent de montrer le nombre d'anomalies sous forme de fonction d'un ou deux attributs d'anomalie.
- Les rapports sur l'âge des anomalies sont un type spécial de rapport de distribution. Les rapports du l'âge des anomalies montrent depuis quand l'anomalie possède un état particulier, tel que l'état Ouvert. Quelle que soit la catégorie d'âge, les anomalies peuvent également être classées selon un autre attribut, comme le Propriétaire.
- Les rapports sur la tendance des anomalies montrent le nombre d'anomalies, par état (nouveau, ouvert ou fermé),
sous forme de fonction du temps. Les rapports de tendance peuvent être cumulatifs ou non-cumulatifs.
Beaucoup de ces rapports sont précieux pour évaluer la qualité du logiciel. Ils sont davantage utiles lorsqu'ils sont analysés en conjonction avec les résultats de test et les rapports d'avancement qui montrent les résultats des tests effectués sur un certain nombre d'itérations et cycles de test pour l'application testée. Les critères de test habituels comprennent une affirmation sur le nombre tolérable d'anomalies ouvertes dans des catégories particulières, comme la classe de gravité, qui se vérifie facilement avec une évaluation de la distribution des anomalies. En triant ou regroupant cette distribution par motivateurs de test, l'évaluation peut se concentrer sur des domaines importants.
Le soutien d'outils est généralement requis pour produire efficacement des rapports de ce genre.
Etat de l'anomalie X priorité
Donnez une priorité à chaque anomalie. Il est généralement pratique et suffisant de disposer de quatre niveaux de priorité, par exemple :
- Priorité urgente (à résoudre immédiatement)
- Haute priorité
- Priorité normale
- Faible priorité
Remarque : les critères de réussite d'un test peuvent être exprimés en termes de distribution des anomalies parmi ces niveaux de priorités. Par exemple, un critère de réussite de test pourrait être "aucune anomalie de Priorité 1 et moins de cinq anomalies de Priorité 2 sont ouvertes". Un diagramme de répartition des anomalies, comme le suivant, doit être généré.

Il est clair que le critère n'a pas été rempli. Ce diagramme doit inclure un filtre pour montrer uniquement les anomalies, comme requis par le critère du test.
Etat de l'anomalie X gravité
Les rapports sur la gravité de l'anomalie montrent le nombre d'anomalies par classe de gravité ; par exemple, erreurs fatales, fonction majeure non exécutée, légers désagréments.
Etat de l'anomalie X emplacement dans le modèle d'implémentation
Les rapports sur la source des anomalies montrent la distribution des anomalies sur des éléments du modèle d'implémentation.
L'analyse de l'âge des anomalies donne une bonne indication sur l'efficacité du test et des activités de suppression des anomalies. Par exemple, si la majorité des anomalies irrésolues plus anciennes ont l'état en attente de validation, cela signifie probablement que des ressources insuffisantes ont été attribuées à l'effort de re-test.
Rapports sur la tendance des anomalies identifie les taux d'anomalie et fourni une vision particulièrement bonne de l'état du test. Les tendances des anomalies suivent un schéma relativement prévisible dans un cycle de test. Au début du cycle, les taux d'anomalies augmentent rapidement pour atteindre un pic et ensuite diminuer à un rythme plus lent dans le temps.

Pour trouver des problèmes, le calendrier du projet peut être révisé à la lumière de cette tendance.
Par exemple, si le taux d'anomalies continue d'augmenter la troisième semaine d'un cycle de test de quatre semaine, il est clair que le projet ne respecte pas son calendrier.
Cette simple analyse de la tendance part du principe que les anomalies sont corrigées rapidement et que les corrections sont testées dans les versions suivantes afin que le taux de fermeture des anomalies suive le même profil que le taux de découverte d'anomalies. Quand ce n'est pas le cas, cela indique un problème dans le processus de résolution des anomalies ; les ressources pour la correction des anomalies ou les ressources pour re-tester et valider les correctifs peuvent être inadaptées.

La tendance que reflète ce rapport montre que de nouvelles anomalies sont découvertes et ouvertes rapidement au début du projet et qu'elles diminuent dans le temps. La tendance des anomalies ouvertes est similaire à celle des nouvelles anomalies mais reste légèrement en arrière. La tendance des anomalies fermées augmente dans le temps au fur et à mesure que les anomalies ouvertes sont corrigées et vérifiées. Ces tendances représentent un effort réussi.
Si vos tendances s'éloignent considérablement de celles-ci, elles peuvent indiquer un problème et identifier un moment où des ressources supplémentaires doivent être affectées à des domaines de développement ou de test spécifiques.
Lorsqu'elle est combinée avec les mesures de la couverture du test, l'analyse des anomalies fournit une excellente évaluation sur laquelle baser les critères d'achèvement du test.
Plusieurs mesures servent à évaluer les comportements de performance de la cible du test et à se concentrer sur la capture des données relatives aux comportements comme le temps de réaction, les profils de temps, le flux d'exécution, la fiabilité opérationnelle et les limites. Tout d'abord, ces mesures sont évaluées dans l'activité Evaluer le test mais il y a des mesures de performance qui sont utilisées pendant l'activité Exécuter le test pour évaluer l'évolution et l'état du test.
Les mesures de performance de base comprennent :
- Le Contrôle dynamique - capture en temps réel et affichage du statut et de l'état de chaque script de test exécuté pendant l'exécution du test.
- Les rapports sur le temps de réaction et le volume traité - mesure des temps de réaction et du volume traité de la cible de test pour des acteurs et cas d'utilisation spécifiés.
- Rapports centiles - mesure centile et calcul des valeurs collectées des données.
- Rapports de comparaison - différences ou tendances entre deux (ou plus) ensembles de données représentant différentes exécutions de test.
- Rapport de trace - détails des messages et conversations entre l'acteur (script de test) et la cible de test.
Le contrôle dynamique fournit un affichage et des rapports en temps réel pendant l'exécution du test, généralement sous forme d'histogramme ou de graphique. Le rapport contrôle et évalue l'exécution du test performance en affichant l'état actuel, le statut et l'évolution des scripts de test.

Par exemple, dans l'histogramme précédent, il y a 80 scripts de test exécutant le même cas d'utilisation. Dans ce graphique, 14 scripts de test ont l'état Inactif, 12 l'état Requête, 34 l'état Exécution SQL, 4 l'état Connecter SQL, et 16 l'état Autre.
Au fur et à mesure que le test progresse, vous vous attendez à voir le nombre de scripts dans chaque état changer. L'illustration est typique d'une exécution de test qui s'exécute normalement et se trouve au milieu de son exécution. Toutefois, si les scripts de test conservent un état ou ne changent pas pendant l'exécution du test, cela peut indiquer un problème dans l'exécution du test ou le besoin d'implémenter ou d'évaluer d'autres mesures de performance.
Les rapports sur le temps de réaction et le volume traité, comme leur nom l'indique, mesurent et calculent les comportements de performance en rapport avec le temps et le volume traité (nombre de transactions traitées). Généralement, ces rapports apparaissent sous forme de graphique avec le temps de réaction (ou le nombre de transactions) sur l'axe"y" et les événements sur l'axe
"x".

Cela vaut souvent la peine de calculer et afficher les informations statistiques, comme l'écart moyen et standard des valeurs de données en plus d'afficher les comportements de performance réels.
Les rapports centiles fournissent un autre calcul statistique de la performance en affichant des valeurs de population centiles pour les types de données collectés.

Il est important de comparer les résultats d'une exécution de test de performance avec celui d'un autre afin de pouvoir évaluer l'impact des changements effectués entre les exécutions de test sur les comportements de performance. Utilisez les rapports de comparaison pour afficher la différence entre deux ensembles de données (chacun représentant différentes exécutions de tests) ou tendances entre plusieurs exécutions de tests.
Lorsque les comportements de performance sont acceptables ou lorsque le contrôle de performance indique d'éventuels goulots d'étranglement (comme quand les scripts de test restent sur un état donné pendant une période très longue), les rapports de trace peuvent s'avérer être les rapports les plus utiles.
Les rapports de trace et profil affichent des informations plus détaillées. Ces informations comprennent les messages entre l'acteur et la cible du test, le flux d'exécution, l'accès aux données et les appels de fonction et système.
|