Concept: Mesures clés du test
Les instructions suivantes traitent des mesures de taux de couverture et de qualité relatives aux suites de tests.
Relations
Description principale

Introduction

Les mesures clés d'un test comprennent la couverture et la qualité.

La couverture du test est la mesure de l'exhaustivité du test et se base sur la couverture des tests, exprimée en termes de couverture des exigences des tests et des cas de test, ou de 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é). 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.

Mesures de la couverture

Les mesures de la couverture fournissent des réponses à la question : « Quel est le degré 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 à une exigence (basée sur les exigences), ou aux critères de conception et d'implémentation du code (basée sur le code), comme la vérification des cas d'utilisation (basée sur les exigences) ou l'exécution de toutes les ligne du code (basée sur le code).

Toute tâche de test systématique 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 sont 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 les tests. 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 obtenues 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.

Couverture de test basée sur les exigences

La couverture de test basée sur les exigences, 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és, implémentés, exécutés ou réussis), exprimé sous la forme de procédures de test ou de cas de test.

RfT est le nombre total d'exigences pour le test.

  • Dans la tâche Planifier le test, la couverture du test est calculée afin de déterminer la couverture des tests planifiés de la façon suivante :

Couverture de test (planifiés) = 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 la tâche 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és) = 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.

  • Dans la tâche Exécuter le test, deux mesures de couverture de test sont utilisées, l'une identifie la couverture de test réalisée en exécutant les tests et l'autre identifie la couverture de test réussie (tests exécutés sans problèmes tels que des anomalies ou résultats inattendus).

    Ces mesures de couverture sont calculées à l'aide de l'équation suivante :

    Couverture de test (exécutés) = Tx / RfT

    où :
    Tx est le nombre de tests exécutés, exprimé sous forme de procédures de test ou de cas de test.

    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 la forme de procédures de test ou de cas de test qui se sont terminés avec succès, sans anomalies.

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.

Couverture de test basée sur le code

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ées.

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 (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.

Mesure de la qualité perçue

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 des hypothèses sur les taux de survenue ou de découverte d'anomalies en cours des tests. 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 support 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, une organisation, des tiers, etc.
  • Source - l'endroit et le défaut déclencheur entraînant l'anomalie ou le composant à corriger pour éliminer cette 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 d'être corrigées, ce qui indique des problèmes 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.

Rapports d'anomalie

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 sur 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.

L'utilisation d'outils est généralement requise pour produire efficacement des rapports de ce genre.

Rapports sur la densité des anomalies

Etat de l'anomalie par rapport à la 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 ouvertes ». Un diagramme de répartition des anomalies, comme le suivant, doit être généré.

Diagramme de répartition des anomalies



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 par rapport à la 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 par rapport à l'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.

Rapports sur l'âge des anomalies

L'analyse de l'âge des anomalies donne une bonne indication sur l'efficacité du test et des tâches de suppression des anomalies. Par exemple, si la majorité des anomalies non résolues plus anciennes ont l'état en attente de validation, cela signifie probablement que des ressources insuffisantes ont été attribuées au nouvel effort de test.

Rapports sur la tendance des anomalies

Les rapports sur la tendance des anomalies identifient les taux d'anomalie et fournissent 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.



Diagramme des rapports de tendance des anomalies

Pour identifier les problèmes, le calendrier du projet peut être revu à 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 semaines, 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 constructions 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.

Diagramme du rapport d'analyse des tendances

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.

Mesures de performance

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 la tâche Evaluer le test mais il y a des mesures de performance qui sont utilisées pendant la tâche Exécuter le test pour évaluer l'évolution et l'état du test.

Les mesures de performance de base comprennent :

  • 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.
  • Rapports sur le temps de réponse et le rendement - mesure des temps de réponse et de rendement de la cible de test pour des acteurs et cas d'utilisation spécifiés.
  • Rapports en centiles - mesure en centiles 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.
  • Rapports de trace - détails des messages et conversations entre l'acteur (script de test) et la cible de test.

Contrôle dynamique

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 de performance en affichant l'état actuel, le statut et la progression des scripts de test.

Contrôle dynamique sous forme d'histogramme

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 Connexion 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'un test qui s'exécute normalement et se trouve au milieu de son exécution. Toutefois, si les scripts de test restent dans un état donné 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.

Rapports sur le temps de réponse et le rendement

Les rapports sur le temps de réponse et le rendement, comme leur nom l'indique, mesurent et calculent les comportements de performance en rapport avec le temps et le rendement (nombre de transactions traitées). Généralement, ces rapports apparaissent sous forme de graphique avec le temps de réponse (ou le nombre de transactions) sur l'axe y et les événements sur l'axe x.

Exemple de diagramme de rapport d'analyse et de rendement

Cela vaut souvent la peine de calculer et d'afficher les informations statistiques, comme l'écart moyen et l'écart type des valeurs de données, en plus d'afficher les comportements de performance réels.

Rapports en centiles

Les rapports en centiles fournissent un autre calcul statistique de la performance en affichant des valeurs de population en centiles pour les types de données collectés.

Exemple de diagramme de rapport en centiles

Rapports comparatifs

Il est important de comparer les résultats d'une exécution de test de performance avec ceux 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 des tendances entre plusieurs exécutions de tests.

Rapports de trace et profil

Lorsque les comportements de performance sont inacceptables 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.