Les applications logicielles les plus simples mises à part, on considère qu'il est généralement impossible de tester
toutes les combinaisons d'entrée possibles d'un système logiciel. La tâche consistant à sélectionner un bon
sous-ensemble ayant une grande probabilité de trouver le plus d'erreurs possibles est donc une tâche utile et
importante pour les testeurs.
Les tests basés sur l'analyse de classe d'équivalence (synonymes : séparation d'équivalence, analyse du
domaine) sont une forme d'analyse de test fonctionnel qui tente de réduire au maximum le nombre total de tests
potentiels afin d'obtenir le plus petit ensemble de tests couvrant le plus d'erreurs possible. [MYE79]. C'est une méthode qui divise l'ensemble des entrées et des sorties en un
nombre fini de classes
d'équivalence qui permettent de sélectionner une valeur de comparaison représentative pour chaque classe. On
dit du test résultant de la valeur représentative d'une classe qu'il est "équivalent" aux autres valeurs de la même
classe. Si aucune erreur n'est trouvée lors du test de la valeur représentative, il est probable que les autres valeurs
"équivalentes" ne trouvent pas d'erreurs non plus.
La puissance des classes d'équivalence réside dans leur capacité à guider le testeur dans l'utilisation d'une stratégie
d'échantillonnage visant à réduire le trop grand nombre de combinaisons de tests potentiellement nécessaires. Cette
technique donne les bases logiques permettant de sélectionner un sous-ensemble parmi le nombre total de tests
possibles. Voici certaines catégories de problèmes posés par un nombre important de tests pouvant tirer profit des
classes d'équivalence :
-
Les combinaisons de variables indépendantes
-
Les variables dépendantes basées sur une relation hiérarchique
-
Les variables dépendantes basées sur une relation temporelle
-
Les relations groupées basées sur des exemplaires de marché
-
Les relations complexes pouvant être modélisées
Il existe plusieurs stratégies et plusieurs techniques pouvant être utilisées pour les tests avec division
d'équivalence. Exemples :
La théorie de la division d'équivalence selon Glenford Myers [MYE79] a pour
but de réduire le nombre total de cas de test nécessaires en divisant les conditions d'entrée en un nombre fini de
classes d'équivalence. On trouve deux types de classes d'équivalence : l 'ensemble des entrées valides du programme est
considéré comme la classe d'équivalence valide, et toutes les autres entrées sont incluses dans la classe
d'équivalence non valide.
Voici une liste d'instructions pour identifier les classes d'équivalence :
-
Si une condition d'entrée définit un ensemble de valeurs (comme "le programme accepte les valeurs entre 10 et
100"), on identifie une classe d'équivalence valide (entre 10 et 100) et deux classes d'équivalence non valides
(inférieur à 10 et supérieur à 100).
-
Si une condition d'entrée définit un ensemble de valeurs (comme "le tissu peut être de plusieurs couleurs : ROUGE,
BLANC, NOIR, VERT, MARRON"), on identifie une classe d'équivalence valide (les valeurs correctes) et une classe
d'équivalence non valide (toutes les autres valeurs incorrectes). Chaque valeur de la classe d'équivalence valide
doit être traitée de manière indépendante.
-
Si la condition d'entrée est définie comme une situation qui "doit être" (comme "la chaîne d'entrée doit être
écrite en lettres majuscules"), on identifie une classe d'équivalence valide (lettres majuscules) et une classe
d'équivalence non valide (toutes les autres entrées, les lettres majuscules mises à part).
-
Tout ce qui est terminé "longtemps" avant que la tâche soit exécutée est une classe d'équivalence. Tout ce qui est
terminé peu de temps avant que le programme soit terminé est une autre classe. Tout ce qui est terminé avant que le
programme ne lance une autre opération est une autre classe.
-
Si un programme doit fonctionner avec une mémoire entre 64 Mo et 256 Mo, cet intervalle de mémoire est une classe
d'équivalence. Toute mémoire dont la taille est supérieure à 256 Mo ou inférieure à 64 Mo ne peut être acceptée.
-
La division des événements de sortie dépend des entrées du programme. Même si des classes d'équivalence d'entrée
différentes peuvent avoir le même type d'événement de sortie, il vaut mieux traiter les classes d'équivalence
d'entrée de manière distincte.
Dans chacune des classes d'équivalence, les conditions de frontière sont supposées avoir un taux de réussite plus haut
pour l'identification des échecs que les conditions qui ne sont pas de frontière. Les conditions de frontière sont les
valeurs qui se situent juste en dessous ou juste au-dessus de la frontière de chaque classe d'équivalence.
Les tests qui résultent des conditions de frontière utilisent les valeurs minimum (min), juste au-dessus du minimum
(min+), juste en dessous du maximum (max-) et maximum (max) de l'intervalle devant être testé. Lors du test des valeurs
de frontière, les testeurs choisissent quelques cas de test pour chaque classe d'équivalence. Pour un petit échantillon
de tests, la probabilité de découvrir un échec est grande. Le testeur est soulagé du poids d'avoir à tester un grand
nombre de cas dans une classe d'équivalence de valeurs qui ont peu de chance de donner de grandes différences dans les
résultats du test.
Voici quelques recommandations à suivre lors du choix des valeurs de frontière :
-
Pour une variable à virgule flottante, si la condition de validité est entre
-1,0 et 1,0 ,
faites le test pour -1,0 , 1,0 , -1,001 et 1,001 .
-
Pour un entier, si la plage valide pour les entrées est entre
10 et 100 , testez
9 , 10 , 100 , 101 .
-
Si un programme demande une lettre majuscule, testez les frontières A et Z. Testez aussi
@ et
[ , car en code ASCII, @ est juste avant A et [ est juste après Z.
-
Si l'entrée ou la sortie d'un programme est un ensemble ordonné, prêtez attention au premier et au dernier éléments
de l'ensemble.
-
Si la somme des entrées doit être un nombre spécifique (
n ), testez le programme où la somme est
n-1 , n , ou n+1 .
-
Si le programme accepte une liste, testez les valeurs de la liste. Toutes les autres valeurs sont non valides.
-
Lorsque vous lisez ou écrivez un fichier, vérifiez les premières et les dernières lettres du fichier.
-
La plus petite dénomination pour de l'argent est un cent ou équivalent. Si le programme accepte un intervalle
particulier entre a et b, testez a en tant que
-0,01 et b en tant que +0,01 .
-
Pour une variable avec des intervalles multiples, chaque intervalle est une classe d'équivalence. Si les
sous-intervalles ne sont pas recouverts, testez les valeurs sur les frontières, au-dessus de la frontière
supérieure et en dessous de la frontière inférieure.
Après avoir essayé les deux stratégies d'analyse de frontière précédentes, un testeur expérimenté observera les entrées
du programme pour découvrir les cas ayant une "valeur spéciale". Ces derniers sont en effet une source potentielle
permettant de mettre à jour les échecs du logiciel. Exemples :
-
Pour un type entier, zéro doit toujours être testé s'il est dans la classe d'équivalence valide.
-
Lorsqu'un test est effectué sur le temps (heure, minute et seconde), 59 et 0 doivent toujours être testés comme les
frontières supérieure et inférieure de chaque champ, quel que que soit le type de contrainte de la variable
d'entrée. Donc, en dehors des valeurs frontière de l'entrée, -1, 0, 59 et 60 doivent toujours être des cas de test.
-
Lorsqu'on teste une date (année, mois et jour), plusieurs cas de test, comme le nombre de jours dans un mois
particulier, le nombre de jours en février d'une année bissextile ou le nombre de jours en février d'une année non
bissextile, doivent être pris en compte.
Ostrand et Balcer [16] ont mis au point une méthode de division qui aide les testeurs à
analyser les spécifications du système, à écrire les scripts des tests et à les gérer. Contrairement aux stratégies
habituelles qui se concentrent principalement sur le code, leur méthode est basée sur la spécification mais aussi sur
les informations au sujet de la structure.
Le principal intérêt de cette méthode est qu'elle permet de montrer les erreurs avant que le code n'ait été écrit : la
source d'entrée est la spécification et les tests proviennent de l'analyse de cette spécification. Les défauts des
spécifications seront découverts tôt, souvent bien avant d'être implémentés dans le code.
Voici la stratégie de la méthode de la "division par catégorie" :
-
Analysez la spécification : décomposez la fonctionnalité du système en unités fonctionnelles qui peuvent être
testées indépendamment par la spécification et l'implémentation.
Ensuite :
-
Identifiez les paramètres et les conditions de l'environnement qui influenceront l'exécution de la
fonction. Les paramètres sont les entrées de l'unité fonctionnelle. Les conditions environnementales
correspondent aux états du système qui effectueront l'exécution de l'unité fonctionnelle.
-
Identifiez les caractéristiques des paramètres et des conditions environnementales.
-
Classez les caractéristiques en catégories qui réalisent le comportement du système.
Les descriptions de comportement manquantes, ambiguës ou contradictoires seront découvertes à ce stade.
-
Divisez les catégories en choix : les choix sont les différentes situations possibles qui peuvent arriver sans être
prévues. Ils représentent le même type d'informations dans une catégorie.
-
Déterminez les relations et les contraintes parmi les choix. Les choix dans différentes catégories
s'auto-influencent, ce qui influence aussi la construction de la suite de tests. Les contraintes sont ajoutées pour
éliminer les contradictions entre plusieurs choix de paramètres et d'environnements différents.
-
Conceptualisez les cas de test en fonction des informations au sujet des catégories, des choix et des contraintes.
Si un choix entraîne une erreur, ne le combinez pas avec d'autres choix pour créer un cas de test. Si un choix peut
être testé de manière adéquate par un test unique, il est soit le représentant du choix, soit une valeur spéciale.
-
Glenford J. Myers, The Art of Software Testing, John Wiley & Sons, Inc., New York, 1979.
-
White L. J. et Cohen E. I., A domain strategy for computer program testing, IEEE Transaction on Software
Engineering, Vol. SE-6, No. 3, 1980.
-
Lori A. Clarke, Johnhette Hassell, et Debra J Richardson, A Close Look at Domain Testing, IEEE Transaction on
Software Engineering, 8-4, 1992.
-
Steven J. Zeil, Faten H. Afifi et Lee J. White, Detection of Linear Detection via Domain Testing, ACM Transaction
on Software Engineering and Methodology, 1-4, 1992.
-
BingHiang Jeng, Elaine J. Weyuker, A Simplified Domain-Testing Strategy, ACM Transaction on Software Engineering
and Methodology, 3-3, 1994.
-
Paul C. Jorgensen, Software Testing - A Craftsman's Approach, CRC Press LLC, 1995.
-
Martin R. Woodward et Zuhoor A. Al-khanjari, Testability, fault, and the domain-to-range ratio: An eternal
triangle, ACM Press New York, NY, 2000.
-
Dick Hamlet, sur les sous-domaines: Testing, profiles, and components, SIGSOFT: ACM Special Interest Group on
Software Engineering, 71-16, 2000.
-
Cem Kaner, James Bach, et Bret Pettichord, Lessons learned in Software Testing, John Wiley & Sons, Inc., New
York, 2002.
-
Andy Podgurski et Charles Yang, Partition Testing, Stratified Sampling, and Cluster Analysis, SIGSOFT: ACM Special
Interest Group on Software Engineering, 18-5, 1993.
-
Debra J. Richardson et Lori A. Clarke, A partition analysis method to increase program reliability, SIGSOFT: ACM
Special Interest Group on Software Engineering, 1981.
-
Lori A. Clarke, Johnette Hassell,et Debra J Richardson, A system to generate test data and symbolically execute
programs, IEEE Transaction on Software Engineering, SE-2, 1976.
-
Boris Beizer, Black-Box Testing - Techniques for Functional testing of Software and System, John Wiley & Sons,
Inc., 1995.
-
Steven J. Zeil, Faten H. Afifi et Lee J. White, Testing for Liner Errors in Nonlinear computer programs, ACM
Transaction on Software Engineering and Methodology, 1-4, 1992.
-
William E. Howden, Functional Program Testing, IEEE Transactions on Software Engineering, Vol. SE-6, No. 2, 1980.
-
Thomas J. Ostrand et Marc J. Balcer, The Category-Partition method
for specifying and generating functional tests, Communications of ACM 31, 1988.
-
Cem Kaner, Jack Falk et Hung Quoc Nguyen, Testing Computer Software, John Wiley & Sons, Inc., 1999.
|