Partition d'Équivalence et Analyse des Valeurs Limites: Guide Pratique

Le partitionnement en classes d'équivalence et l'analyse des valeurs limites sont deux techniques de conception de tests. Elles permettent de sélectionner le nombre minimal d'entrées pour détecter le maximum de bugs.

Qu'est-ce que le partitionnement en classes d'équivalence

Le partitionnement en classes d'équivalence (PE) divise toutes les valeurs d'entrée possibles en groupes, appelés partitions ou classes d'équivalence. Dans chaque groupe, toute valeur est censée se comporter de la même façon. Si le système traite correctement une valeur d'une partition, il traitera toutes les autres de la même façon. On n'a donc besoin de tester qu'un seul représentant par partition.

Exemple : champ âge pour un service de streaming

Supposons que le système ait ces règles :

• les utilisateurs doivent avoir 18 ans ou plus pour s'inscrire
• les utilisateurs de moins de 13 ans sont complètement bloqués
• les utilisateurs de 13 à 17 ans obtiennent un compte "ado" restreint
• les utilisateurs de 18 ans et plus obtiennent un compte complet
• l'âge doit être un nombre entier entre 1 et 120

On identifie immédiatement les partitions :

Depuis ces partitions, on choisit un seul représentant par partition. Inutile de tester âge=19, âge=25, âge=50 et âge=100. Ils sont tous dans la même partition. Tester âge=30 couvre l'ensemble.

Les cas de test deviennent :

• 30 → Compte complet (partition adulte valide)
• 15 → Compte ado (partition ado valide)
• 10 → Bloqué (partition moins de 13 ans)
• -1 → Erreur (partition zéro/négatif)
• 200 → Erreur (partition au-dessus du max)
• "dix-sept" → Erreur de validation (partition non entier)

6 tests au lieu de potentiellement des centaines. Sans perte de couverture.

Qu'est-ce que l'analyse des valeurs limites

L'analyse des valeurs limites (AVL) repose sur un fait bien observé : les bugs se concentrent aux frontières des partitions, pas au milieu.

Les développeurs écrivent du code comme if (age >= 18). Le bug n'est presque jamais "ça marche pour 30, ça casse pour 31". Il est presque toujours à la frontière : "ça marche pour 18, ça casse pour 17", ou "voulait écrire >= mais a écrit >", donc le seuil est décalé d'un.

L'AVL dit : testez toujours les valeurs juste à la frontière, à savoir la dernière valeur valide, la première valeur valide, et éventuellement les valeurs juste en dehors.

Valeurs AVL à tester

Pour toute frontière, on teste :

• Dernière valeur avant la plage valide (juste sous le minimum)
• Première valeur valide (minimum)
• Dernière valeur valide (maximum)
• Première valeur après la plage valide (juste au-dessus du maximum)

Pour notre exemple d'âge avec des frontières à 1, 12, 13, 17, 18, 120 :

Cas de test AVL :

• 0 → Erreur (sous le minimum)
• 1 → Bloqué (entrée valide minimum)
• 12 → Bloqué (dernière valeur de la partition moins de 13 ans)
• 13 → Compte ado (première valeur de la partition ado)
• 17 → Compte ado (dernière valeur de la partition ado)
• 18 → Compte complet (première valeur de la partition adulte)
• 120 → Compte complet (dernière valeur de la plage valide)
• 121 → Erreur (première valeur au-dessus du maximum)

C'est bien plus rigoureux qu'un test aléatoire, et bien plus susceptible de détecter de vraies erreurs de décalage d'un.

PE et AVL fonctionnent ensemble

En pratique, on les utilise conjointement :

1. PE d'abord : identifier toutes les partitions (valides, invalides, cas limites)
2. AVL ensuite : pour toute partition avec une plage numérique ou ordonnée, tester aux frontières au lieu d'une valeur aléatoire au milieu (ou en plus)

Voici à quoi ressemble la couverture combinée pour le champ âge :

13 cas de test. Ils détecteront presque tous les bugs réels de validation d'âge, y compris les plus subtils.

Appliquer ces techniques à de vraies fonctionnalités

Longueur de mot de passe (8 à 64 caractères)

Partitions :

• Vide → erreur
• Trop court (1 à 7) → erreur
• Valide (8 à 64) → accepté
• Trop long (65+) → erreur

Tests AVL à chaque frontière :

• "" (vide) → erreur
• 7 caractères → erreur (dernière valeur sous le minimum)
• 8 caractères → accepté (première valeur valide)
• 64 caractères → accepté (dernière valeur valide)
• 65 caractères → erreur (première valeur au-dessus du maximum)

Milieu de la partition valide : 20 caractères → accepté

6 tests couvrent l'ensemble de la plage valide/invalide.

Champ e-mail

C'est un scénario de partitionnement uniquement (pas de frontières numériques nettes) :

Partitions :

• Vide → erreur
• Format valide (nom@domaine.com) → accepté
• @ manquant → erreur
• Domaine manquant → erreur
• Plusieurs @ → erreur
• Caractères internationaux → dépend de la spec

Testez une valeur par partition. Pas besoin de tester 50 formats d'e-mail valides : ils appartiennent tous à la partition "format valide".

Liste déroulante à valeurs fixes

Si un champ n'accepte que des valeurs spécifiques (Petit/Moyen/Grand), il n'y a pas de frontières à analyser avec l'AVL. Le PE suffit :

Une valeur valide (Moyen) est acceptée, une valeur invalide hors liste (XL) génère une erreur, et le champ vide aussi.

Erreurs courantes à éviter

Tester trop de valeurs dans la même partition

Tester les âges 20, 25, 30, 35 et 45 donne 5 tests qui vivent tous dans la même partition. Ils passeront ou échoueront ensemble. Les 4 tests supplémentaires n'apportent rien.

Choisissez un représentant par partition, testez aux frontières.

Oublier les partitions invalides

Les débutants ne pensent souvent qu'aux entrées valides. Les vrais bugs se cachent dans ce qui se passe avec des entrées invalides : nombres négatifs, chaînes vides, valeurs légèrement trop grandes.

Listez toujours les partitions invalides explicitement. C'est souvent là que les bugs intéressants se cachent.

Passer à côté des partitions non évidentes

Pour un champ "code de réduction" :
Les partitions communes sont le code valide, le code invalide et le vide. Les partitions faciles à manquer incluent le code expiré, le code déjà utilisé, le code pour un autre produit, et la sensibilité à la casse.

Pensez au comportement du système, pas seulement au format. Des comportements différents = des partitions différentes.

Appliquer l'AVL à des données non ordonnées

L'AVL n'a de sens que pour des données avec un ordre naturel : nombres, dates, longueurs. On ne peut pas l'appliquer à une liste de codes pays ou un ensemble de valeurs d'énumération. Utilisez le PE pour ça.

Un processus pratique

Face à n'importe quel champ de saisie ou règle métier, suivez ces étapes :

Étape 1 : Quelles valeurs ce champ accepte-t-il ? Quelles sont les règles ?

Étape 2 : Listez toutes les partitions, valides et invalides. Notez le comportement attendu pour chacune.

Étape 3 : Pour toute partition avec une plage numérique ou ordonnée, identifiez les frontières. Listez les valeurs dernier-invalide/premier-valide et dernier-valide/premier-invalide.

Étape 4 : Choisissez un représentant par partition non frontière (pour le milieu des plages valides). Ajoutez les valeurs frontières.

Étape 5 : Rédigez vos cas de test, un par valeur identifiée.

Ça prend 5 à 10 minutes par fonctionnalité et donne un ensemble de tests défendable et efficace, que vous pouvez expliquer à n'importe qui.

Pourquoi ça compte pour l'automatisation QA

Quand vous écrivez des tests Playwright, ces techniques aident à décider ce qu'il faut paramétrer. Au lieu d'écrire 20 tests quasi-identiques qui changent juste la valeur d'entrée, vous en écrivez un seul paramétré avec les 6 à 8 valeurs identifiées par le PE et l'AVL :

const AGE_CASES = [
  { input: '-1',   expect: 'error',        label: 'below minimum' },
  { input: '1',    expect: 'blocked',      label: 'minimum valid' },
  { input: '12',   expect: 'blocked',      label: 'last blocked' },
  { input: '13',   expect: 'teen account', label: 'first teen' },
  { input: '17',   expect: 'teen account', label: 'last teen' },
  { input: '18',   expect: 'full account', label: 'first adult' },
  { input: '120',  expect: 'full account', label: 'last valid' },
  { input: '121',  expect: 'error',        label: 'over maximum' },
];

for (const { input, expect, label } of AGE_CASES) {
  test(`age ${label}: ${expect}`, async ({ page }) => {
    await page.fill('[data-testid="age-input"]', input);
    await page.click('[data-testid="submit"]');
    await expect(page.locator('[data-testid="result"]')).toContainText(expect);
  });
}

Lisible, clair, et chaque test a une raison d'exister.

Points clés

• Le partitionnement en classes d'équivalence regroupe les entrées par comportement attendu : testez une valeur par groupe
• L'analyse des valeurs limites cible les frontières entre groupes, là où vivent les erreurs de décalage d'un
• Utilisez le PE pour identifier les partitions, l'AVL pour choisir les valeurs exactes à tester
• Incluez toujours les partitions invalides : les tests "que se passe-t-il avec une mauvaise entrée" détectent de vrais bugs
• L'objectif est le minimum de tests pour le maximum de couverture, pas tester tout, mais tester les bonnes choses

Ces deux techniques forment la base de la conception de tests structurée. Une fois intégrées, vous les appliquerez instinctivement chaque fois que vous examinez une nouvelle fonctionnalité, avant même d'ouvrir votre éditeur de tests.

→ Voir aussi: Techniques de Conception de Cas de Test: EP, BVA, Tables de Décision, Transition d'États | Comment Écrire un Cas de Test: Format, Exemples et Erreurs Courantes | Tests Basés sur les Risques: Prioriser ce qu'il Faut Tester Quand On Ne Peut Pas Tout Tester