Cet article fait partie d’une série de sept articles consacrés à la catégorie des techniques de conception de cas de test basée sur les spécifications. Vous y trouverez une brève introduction sur ces différentes catégories.

Introduction

Tous les testeurs sont confrontés à la problématique de la conception des cas de test, que ces derniers soient manuels ou automatisés.

Cette activité de conception peut être faite de plusieurs manières différentes.

L’ISTQB en distingue trois grandes catégories:

• celle basée sur les spécifications, aussi appelée boîte noire;
• celle basée sur la structure, aussi appelée boîte blanche (ou boite en verre);
• celle basée sur l’expérience.

La technique des partitions d’équivalence appartient à la catégorie basée sur les spécifications.

Présentation de la technique

Définition ISTQB

La technique des partitions d’équivalence est utilisée pour réduire le nombre de cas de test nécessaire pour tester un ensemble d’entrées, de sorties, d’intervalles de valeurs ou de temps.

Le découpage en partitions est utilisé pour créer des classes d’équivalence (souvent appelées partitions d’équivalence) qui sont constituées d’ensembles de valeurs qui sont traités de la même manière.

En sélectionnant dans chaque partition une valeur représentative, la couverture de tous les éléments de la même partition est assurée.

Application

Cette technique est :

• applicable à tous les niveaux de test: unitaire, intégration, système et acceptation;
• adaptée lorsque tous les éléments d’un même ensemble de valeurs sont supposés être traitées de la même façon. Notons que l’ensemble peut être ordonnée ou non:
  • exemple d’ensemble ordonné: une application prenant en entrée l’âge d’un individu.
  • exemple d’ensemble non ordonné: une application prenant en entrée des formes géométriques de différentes dimensions –> Carré, Cercle, Triangle, Rectangle, …
• pertinente pour des tests fumigatoires sur une nouvelle version ou une nouvelle livraison afin de rapidement déterminer si les fonctionnalités de base fonctionnent;
• peut être utilisée pour déterminer des ensembles de données pour tester la performance de l’application.

Limitations/difficultés/risques

Une des difficultés est de correctement choisir les partitions. Si au sein d’une partition, toutes les données ne sont pas traitées de manière identiques, il y a un risque de laisser passer des défauts.

Une limitation de la technique est de choisir une donnée au hasard dans la partition et considérer que toutes les autres ne poseront pas de problème. C’est un risque à considérer comme pour toutes réductions de couverture de tests. Le second article de cette série qui se focalisera sur l’analyse des valeurs limites permettra de réduire ce risque.

Couverture

La couverture est calculée en prenant le nombre de partitions pour lesquelles une valeur a été testée et en le divisant par le nombre de partitions définies.

Utiliser plusieurs valeurs pour une même partition n’augmente pas le pourcentage de couverture.

Type de défaut

Cette technique trouve des défauts fonctionnels dans la gestion des différentes données.

Elle peut aussi trouver des défauts non-fonctionnels lorsqu’elle est utilisée pour des tests de performance.

Mise en œuvre

La démarche de mise en œuvre est la suivante (selon la norme BS-7925-2):

1. Identifier les partitions de valeurs  valides et invalides en entrée
2. Identifier les partitions de valeurs valides et invalides en sorties.
3. Dériver les cas de tests à partir des partitions

Prenons un exemple pour illustrer la technique.

Une application Web calcule le taux d’imposition et le taux de réduction en fonction du revenu du foyer et du nombre d’enfants selon les règles suivantes:

• Le revenu doit être compris entre 0€ et 100K€;
• Les revenus de moins de 10K€ ne sont pas imposables;
• Les revenus à partir de 10k€ sont imposés au taux de 20%;
• Les foyers avec 2 enfants scolarisés ou plus ont une réduction de 15%;
• Le montant des revenus et le nombre d’enfants (de 0 à 10) sont fournis via un formulaire avec des champs de saisie libres. Seuls des entiers positifs sont acceptés par le système pour les deux champs.

Lisons la spécification ligne par ligne.

« Une application Web calcule le taux d’imposition et le taux de réduction en fonction du revenu du foyer et du nombre d’enfants selon les règles suivantes » –> nous en déduisons qu’il y a deux entrées, le revenu du foyer et le nombre d’enfants, et au moins deux sorties, le taux d’imposition et le taux de réduction.

« Le revenu doit être compris entre 0€ et 100K€ » –> une précision est donnée sur l’entrée concernant le revenu. Le système doit accepter les valeurs entre 0 et 100. Il n’est pour le moment pas précisé l’attendu pour les autres valeurs. À noter que la spécification ne précise pas non plus si le 0 et le 100K sont inclus. Cela peut être vu comme un manque de précision de la spécification. Pour l’exercice, on va considérer qu’ils le sont. Cela donne ceci pour l’entrée E1 concernant les revenus:

• Une partition valide E1V1 : [0; 100k]
• Une partition invalide E1I1 : ]-INF;0[
• Une partition invalide E1I2 : ]100k;+INF[

En revanche, rien n’est explicitement fourni sur ce qui est attendu en sortie.

Nous allons tout de même considérer la sortie invalide S1 correspondant au rejet du revenu.

« Les revenus de moins de 10K€ ne sont pas imposables » –> Ici, nous avons une précision sur la donnée d’entrée E1 concernant les revenus avec un comportement attendu. Nous pouvons donc déterminer une nouvelle sortie S2: les revenus sont non imposables, ce qui revient à dire que le taux d’imposition est de 0%. Néanmoins, la spécification ne le dit pas explicitement et le métier devrait confirmer cette interprétation. Il est aussi implicitement dit qu’une donnée en dessous de 0 est non imposable et en même temps doit être rejetée (voir première phrase de la spécification). On va considérer que le rejet d’une donnée implique le non calcul du taux d’imposition et du taux de réduction.

Nous avons désormais:

• une entrée E1 sur le revenu:
  • Une partition valide E1V1 : [0; 100k]
  • Une partition invalide E1I1 : ]-INF;0[
  • Une partition invalide E1I2 : ]100k;+INF[
• une sortie S1 : rejet du revenu
• une sortie S2 : taux d’imposition = 0%

« Les revenus à partir de 10k€ sont imposés au taux de 20%« 

Ici, nous ré-appliquons la logique précédente avec une nouvelle sortie S3 correspondant à un taux d’imposition de 20%. Comme précédemment, cette phrase de la spécification entre en conflit avec la première phrase de la spécification au delà de 100k.

Nous avons désormais:

• une entrée E1 sur le revenu:
  • Une partition valide E1V1 : [0; 100k] que l’on divisera en deux un peu plus loin.
  • Une partition invalide E1I1 : ]-INF;0[
  • Une partition invalide E1I2 : ]100k;+INF[
• une sortie S1 : rejet du revenu
• une sortie S2 : taux d’imposition = 0%
• une sortie S3 : taux d’imposition = 20%

« Les foyers avec 2 enfants scolarisés ou plus ont une réduction de 15%« 

Ici, nous basculons sur le traitement de la seconde entrée, le nombre d’enfants du foyer. Nous avons aussi une nouvelle sortie possible concernant le taux de réduction.

• une entrée E1 sur le revenu:
  • Une partition valide E1V1 : [0; 100k]
  • Une partition invalide E1I1 : ]-INF;0[
  • Une partition invalide E1I2 : ]100k;+INF[
• une entrée E2 sur le nombre d’enfants dans le foyer:
  • Une partition valide E2V1 : [2;+INF[
• une sortie S1 : rejet du revenu
• une sortie S2 : taux d’imposition = 0%
• une sortie S3 : taux d’imposition = 20%
• Une sortie S4 : taux de réduction = 15%

« Le montant des revenus et le nombre d’enfants (de 0 à 10) sont fournis via un formulaire avec des champs de saisie libres. Seuls des entiers positifs sont acceptés par le système pour les deux champs.« 

Enfin, nous avons plusieurs éléments à récupérer dans le dernier point de la spécification. Nous apprenons:

• « le nombre d’enfants (de 0 à 10) » : celle remet en cause le point précédent en réduisant la réduction octroyée à l’ensemble [2;10]. Ici encore, nous allons considérer que le 10 est inclus mais ça reste à confirmer par les métiers. Nous apprenons aussi que le système doit accepter l’ensemble de valeurs [0;2[  mais sans savoir ce qu’il en fait. Nous en déduisons une nouvelle partition invalide. Nous identifions aussi que les ensembles ]-INF;0[ et ]10;+INF[ sont des valeurs rejetées mais là encore, nous ne savons pas comment elles le seront.
• « des champs de saisie libres » puis « Seuls des entiers positifs sont acceptés par le système pour les deux champs »: Ici, nous pouvons en déduire que le système doit refuser le nombre d’enfant si E2 n’est pas un entier positif. Mais la spécification ne dit pas comment le rejet s’effectue. Nous avons donc de nouvelles partitions invalides pour E2. Cela est aussi valable pour E1. Considérerons les deux partitions suivantes pour chaque entrée comme invalides: valeurs décimales et valeurs alphabétiques.

Enfin, si nous regardons attentivement la partition E1V1 (revenu dans [0; 10k[) qui produit soit S2 (taux d’imposition = 0%), soit S3 (taux d’imposition = 20%), nous pouvons la découper en deux partitions distinctes où chacune produira respectivement S2 ou S3.

Au final, nous avons:

• une entrée E1 sur le revenu:
  • Une partition valide E1V1 : [0; 10k[
  • Une partition valide E1V2 : [10k; 100k]
  • Une partition invalide E1I1 : ]-INF;0[
  • Une partition invalide E1I2 : ]100k;+INF[
  • Une partition invalide E1I3 : ensemble des décimales
  • Une partition invalide E1I4 : ensemble des alphabétiques
• une entrée E2 sur le nombre d’enfants dans le foyer:
  • Une partition valide E2V1 : [2;10]
  • Une partition invalide E2I1 : [0;2[
  • Une partition invalide E2I2 : ]-INF;0[
  • Une partition invalide E2I3 : ]10;+INF[
  • Une partition invalide E2I4 : ensemble des décimales
  • Une partition invalide E2I5 : ensemble des alphabétiques
• une sortie S1 : rejet du revenu
• une sortie S2 : taux d’imposition = 0%
• une sortie S3 : taux d’imposition = 20%
• Une sortie S4 : taux de réduction = 15%
• Une sortie S5 : rejet du nombre d’enfants

A noter que la partition invalide E2I1 (enfants dont l’âge est compris dans [0;2[) est un vrai trou de spécification car le développeur ne sait pas ce que le logiciel doit faire. Ce qui n’est pas complètement le cas des autres partitions invalides où il est précisé que le système doit rejeter les valeurs. Même si ce n’est pas précis, le développeur pourra développer un mécanisme de rejet et cela même si ce dernier n’est pas celui attendu par les métiers.

Au final, notre lecture de la spécification donne 3 partitions d’équivalence valides et 9 partitions d’équivalence invalides.

Nous voyons que la technique, avant même d’avoir identifier un cas de test permet de relire efficacement la spécification et il convient d’éliminer toutes les partitions invalides en les rendant valides avec la mise à jour de la spécification. De même, toutes les hypothèses que nous avons prises devront être confirmés, idéalement de manière explicite dans la spécification.

Maintenant que nous avons nos partitions d’équivalence, il convient de créer des cas de test pour couvrir chaque partition.

Il est important de noter ici que la technique ne cherche pas à faire de la combinatoire entre les données d’entrée. Cela ne veut pas dire qu’une bonne couverture de test ne va pas considérer la combinatoire mais ce n’est pas l’objet de cette technique. D’autres techniques vont se charger de faire cette combinatoire en s’appuyant sur des données issues des partitions d’équivalence.

Dans le tableau suivant, j’ai fait le choix de dériver les cas de test en prenant les partitions d’équivalence dans l’ordre de mon schéma précédent. Il faut donc 6 cas de test pour couvrir l’ensemble des partitions identifiées. Il va de soi que ce choix n’est surement pas le plus pertinent et qu’on cherchera à combiner différemment pour obtenir la même couverture.

Conclusion

Cette technique est particulièrement efficace pour pointer des erreurs de spécifications: omissions, ambiguïtés, contradictions, manques de précision, ….

Elle sera d’une grande aide pour choisir des valeurs dans chaque partition qui seront ensuite utilisées dans d’autres techniques traitant de la combinatoire (Tables de décision, pairwise , classification arborescente entre autres).

Il convient de ne pas oublier que réduire la combinatoire impose de gérer le risque qualité associée.

Sources et remerciements

Le syllabus ISTQB niveau avancé Test Analyste traduit en français par le CFTL

La norme BS-7925-2  « Software component testing standard »

Merci à Marc Hage Chahine pour sa relecture.