Instructions: Analyse de classes d'équivalence
L'analyse de classe d'équivalence est une technique permettant de réduire le nombre de cas de test. Ces instructions définissent cette technique et décrivent comment l'utiliser.
Relations
Description principale

Introduction

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 :

  1. Les combinaisons de variables indépendantes
  2. Les variables dépendantes basées sur une relation hiérarchique
  3. Les variables dépendantes basées sur une relation temporelle
  4. Les relations groupées basées sur des exemplaires de marché
  5. Les relations complexes pouvant être modélisées

Stratégies

Il existe plusieurs stratégies et plusieurs techniques pouvant être utilisées pour les tests avec division d'équivalence. Exemples :

Division des classes d'équivalence

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 :

  1. 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).
  2. 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.
  3. 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).
  4. 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.
  5. 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.
  6. 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.

Analyse de la valeur de la frontière

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 :

  1. 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.
  2. Pour un entier, si la plage valide pour les entrées est entre 10 et 100, testez 9, 10, 100, 101.
  3. 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.
  4. 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.
  5. 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.
  6. Si le programme accepte une liste, testez les valeurs de la liste. Toutes les autres valeurs sont non valides.
  7. Lorsque vous lisez ou écrivez un fichier, vérifiez les premières et les dernières lettres du fichier.
  8. 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.
  9. 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.

Valeurs spéciales

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 :

  1. Pour un type entier, zéro doit toujours être testé s'il est dans la classe d'équivalence valide.
  2. 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.
  3. 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.

Méthode de la "division par catégorie"

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" :

  1. 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 :

    1. 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.
    2. Identifiez les caractéristiques des paramètres et des conditions environnementales.
    3. 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.

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

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

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

Lectures et références supplémentaires

  1. Glenford J. Myers, The Art of Software Testing, John Wiley & Sons, Inc., New York, 1979.
  2. 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.
  3. Lori A. Clarke, Johnhette Hassell, et Debra J Richardson, A Close Look at Domain Testing, IEEE Transaction on Software Engineering, 8-4, 1992.
  4. 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.
  5. BingHiang Jeng, Elaine J. Weyuker, A Simplified Domain-Testing Strategy, ACM Transaction on Software Engineering and Methodology, 3-3, 1994.
  6. Paul C. Jorgensen, Software Testing - A Craftsman's Approach, CRC Press LLC, 1995.
  7. 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.
  8. Dick Hamlet, sur les sous-domaines: Testing, profiles, and components, SIGSOFT: ACM Special Interest Group on Software Engineering, 71-16, 2000.
  9. Cem Kaner, James Bach, et Bret Pettichord, Lessons learned in Software Testing, John Wiley & Sons, Inc., New York, 2002.
  10. Andy Podgurski et Charles Yang, Partition Testing, Stratified Sampling, and Cluster Analysis, SIGSOFT: ACM Special Interest Group on Software Engineering, 18-5, 1993.
  11. Debra J. Richardson et Lori A. Clarke, A partition analysis method to increase program reliability, SIGSOFT: ACM Special Interest Group on Software Engineering, 1981.
  12. 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.
  13. Boris Beizer, Black-Box Testing - Techniques for Functional testing of Software and System, John Wiley & Sons, Inc., 1995.
  14. 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.
  15. William E. Howden, Functional Program Testing, IEEE Transactions on Software Engineering, Vol. SE-6, No. 2, 1980.
  16. Thomas J. Ostrand et Marc J. Balcer, The Category-Partition method for specifying and generating functional tests, Communications of ACM 31, 1988.
  17. Cem Kaner, Jack Falk et Hung Quoc Nguyen, Testing Computer Software, John Wiley & Sons, Inc., 1999.