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