Le partitionnement d'équivalence divise les données d'entrée en classes au sein desquelles le système doit se comporter de la même manière. Au lieu de vérifier des dizaines de valeurs similaires, QA sélectionne un ou deux représentants de chaque classe significative.
L'idée de base
Si le système gère une plage entière de la même manière, tester chaque valeur n’apporte que peu de choses. Identifiez plutôt les classes : formats valides, invalides, vides, surdimensionnés, interdits, etc.
Un exemple simple
Supposons qu'un champ Âge accepte les valeurs de 18 à 60 inclus. Il existe au moins trois classes : inférieure à 18, 18–60 et supérieure à 60. Choisissez une valeur représentative de chaque classe plutôt que d'essayer chaque nombre.
L'appliquer dans la pratique
- →Comprendre d’abord les règles de validation et le sens métier du champ ou du paramètre.
- →Identifiez les classes avec des comportements attendus différents.
- →Sélectionnez une valeur dans chaque classe et considérez les limites séparément.
- →Vérifiez les valeurs valides aux côtés des entrées vides, de mauvais type, interdites et logiquement contradictoires.
Erreurs courantes
- →Définir des classes mécaniquement sans comprendre la logique métier.
- →Oublier que les classes d’équivalence ne remplacent pas l’analyse des valeurs limites.
- →Supposer que les valeurs sont équivalentes lorsque le système les gère différemment.
- →Utiliser uniquement des classes valides et ignorer les entrées négatives.
Le partitionnement d'équivalence est particulièrement utile pour les formulaires, les paramètres API, les filtres, les plages, les statuts et toute entrée pour laquelle des tests exhaustifs sont peu pratiques ou inutiles. Sa force réside dans la réduction du volume de test tout en conservant une couverture logique.
Exemple concret : âge entier d'éligibilité
Règle de formation : une application accepte un âge entier allant de 18 à 65 inclus. Traitez les valeurs entières inférieures à 18, de 18 à 65 et supérieures à 65 comme trois partitions disjointes pour cette règle. Choisissez un représentant de chacun avant d’ajouter des contrôles de limites.
Partition Valeur représentative Résultat attendu
Entier inférieur à 18 16 Refuser : hors de la tranche d’âge admissible
Entier de 18 à 65 40 Accepter
Entier supérieur à 65 70 Refuser : hors de la tranche d’âge admissibleLe modèle suppose que les valeurs à l'intérieur de chaque partition sont traitées de la même manière. Il s’agit d’une hypothèse de conception de test, et non d’une preuve qu’une seule valeur détecte tous les défauts. Si la règle métier introduit un résultat différent pour les âges 60–65, divisez la partition valide en conséquence. Ne combinez pas différents résultats simplement parce que toutes les entrées ont le même type de données.
Séparez les erreurs de représentation
Définissez également le contrat de transport. Dans cet exercice, un champ JSON age doit être présent et contenir un nombre entier ; les chaînes, les fractions et null ne sont pas valides. Les valeurs suivantes ne sont pas des représentants supplémentaires des trois partitions entières.
Corps de la requête Résultat attendu
{} Refuser : champ obligatoire absent
{"age": null} Refuser : entier requis
{"age": "40"} Refuser : entier requis
{"age": 40.5} Refuser : entier requis
{"age": 40} AccepterExercice et réponse
25, 40 et 55 couvriraient-ils les trois partitions entières ? Non : tous les trois sont dans la partition valide. Un ensemble tel que 16, 40 et 70 couvre les trois ; puis ajoutez 17, 18, 19, 64, 65 et 66 pour étudier le comportement spécifique aux limites. Les résultats attendus proviennent de la règle indiquée, tandis que les codes d'état HTTP et les schémas d'erreur nécessitent un contrat API distinct.