Un champ d’âge qui accepte les 18 à 60 ans comporte un nombre énorme d’entrées possibles, une fois que vous comptez les négatifs, les nombres énormes, le texte et les espaces. Personne ne peut tous les essayer. Le partitionnement d’équivalence résout ce problème en regroupant les entrées que le logiciel doit traiter de la même manière, puis en testant une valeur de chaque groupe.

C’est l’une des premières techniques de conception de tests que tout testeur devrait apprendre. Dans ce guide, nous le parcourons étape par étape et testons un exemple en Python. Nous avons exécuté ce code sur Python 3.13 et sa sortie est incluse. Les règles de mot de passe et de coupon ci-dessous sont des exemples illustratifs, non tirés d’un système réel.

Qu’est-ce que le partitionnement d’équivalence ?

Le partitionnement d’équivalence, également appelé partitionnement de classe d’équivalence (ECP), est une technique de conception de tests en boîte noire. Il divise les entrées possibles d’une fonctionnalité en partitions ou classes. Chaque valeur à l’intérieur d’une partition est censée produire le même type de comportement.

Comme vous n’avez pas besoin de voir le code, vous pouvez l’appliquer directement à partir d’une exigence. Pour en savoir plus sur ce style de test, lisez Tests en boîte noire ou en boîte blanche.

Pourquoi ça marche

La technique repose sur une hypothèse : si une valeur dans une partition trouve un bogue, les autres valeurs dans cette partition le trouveront probablement aussi. Et si une valeur passe, les autres passeront probablement aussi. Tester 25, 26 et 27 ans dans un domaine d’âge adulte ne vous apprendra probablement rien que le test de 25 ans seul ne vous apprendra rien.

Il s’agit cependant d’une hypothèse et non d’une garantie. Les logiciels peuvent avoir des cas particuliers cachés dans une partition, une limitation sur laquelle nous reviendrons plus tard.

Comment le faire en cinq étapes

1. Lisez l’exigence et identifiez l’entrée et ses règles.
2. Trouvez les partitions valides, qui sont les groupes de valeurs qui doivent être acceptées, et notez si différentes plages se comportent différemment.
3. Trouvez les partitions invalides, y compris les valeurs trop faibles, trop élevées, de mauvais type et vides.
4. Choisissez une valeur représentative dans chaque partition, généralement quelque part au milieu.
5. Notez le résultat attendu pour chacun, comme dans tout bon cas de test.

Exemple concret : un champ d’âge

Exigence : Les utilisateurs âgés de 18 à 60 ans peuvent s’inscrire.

Cinq tests vous permettent de couvrir chaque comportement de l’exigence. De nombreux didacticiels s’arrêtent aux trois premières lignes, mais les deux dernières sont celles que les vrais utilisateurs déclenchent par accident. Vous pouvez également ajouter des lignes pour les nombres négatifs ou décimaux, si ceux-ci peuvent raisonnablement être traités différemment.

Le tester dans le code

Voici cette règle sous forme de fonction, avec un test unitaire par partition, en utilisant le module intégré de Python unittest :

import unittest

def can_register(age):
    if not isinstance(age, int) or isinstance(age, bool):
        raise TypeError("age must be a whole number")
    return 18 <= age <= 60

class EquivalenceTests(unittest.TestCase):
    def test_valid_partition(self):
        self.assertTrue(can_register(35))

    def test_too_young_partition(self):
        self.assertFalse(can_register(10))

    def test_too_old_partition(self):
        self.assertFalse(can_register(75))

    def test_wrong_type_partition(self):
        with self.assertRaises(TypeError):
            can_register("abc")

Notre course a réussi :

test_too_old_partition ... ok
test_too_young_partition ... ok
test_valid_partition ... ok
test_wrong_type_partition ... ok

Dans un projet réel, la fonctionnalité de paramétrage de pytest est un moyen intéressant d’exécuter une table de valeurs de partition via un seul test.

Exemple concret : un mot de passe

Exigence : Un mot de passe doit comporter de 8 à 20 caractères et contenir au moins un chiffre.

Celui-ci a deux règles, longueur et contenu, nous considérons donc des partitions pour les deux :

Notez que chaque test invalide enfreint une seule règle. Si une valeur était à la fois trop courte et qu’il manquait un chiffre, un test de réussite ne pourrait pas vous dire quel contrôle a fonctionné. Un chèque peut être brisé, tandis que l’autre le cache.

Exemple concret : entrées non numériques

La technique ne se limite pas aux plages de numéros. Les options, catégories et états discrets forment également des partitions. Supposons qu’un magasin ait cette règle :

Exigence : La livraison est gratuite pour les membres Gold, 50 pour les Silver et 100 pour tous les autres. Les valeurs de niveau inconnues sont des erreurs.

Ici, chaque option est sa propre partition, car chacune doit se comporter différemment. D’autres partitions courantes incluent les types de fichiers, tels que les téléchargements valides et non valides, et les groupes basés sur les résultats, tels qu’un prêt approuvé ou refusé.

Plusieurs entrées à la fois

Avec plusieurs champs, le nombre de combinaisons augmente rapidement. Trois champs avec quatre partitions chacun donnent 64 combinaisons. Deux stratégies aident :

• Faible couverture : assurez-vous que chaque partition apparaît dans au moins un test, en combinant plusieurs valeurs valides par test. Pour les valeurs non valides, testez-les une par une afin que les erreurs ne se masquent pas.
• Couverture basée sur des règles : lorsque les combinaisons modifient réellement le résultat, comme le statut du membre avec la valeur de la commande, utilisez tests de table de décision pour les répertorier correctement.

Couplage avec l’analyse des valeurs limites

Le partitionnement vous indique les groupes à tester. Cela en dit peu sur où dans un groupe les bogues aiment se cacher, et beaucoup se cachent juste sur les bords. Pour le montrer, nous avons écrit une version boguée avec l’erreur classique :

def buggy(age):
    return 18 < age <= 60     # should be 18 <= age

[buggy(a) for a in (35, 10, 75)]   # [True, False, False]
buggy(18)                          # False

Nos valeurs de partition, 35, 10 et 75, ont toutes donné les bonnes réponses, donc ces tests seraient réussis. Pourtant, un jeune de 18 ans est rejeté à tort. C’est pourquoi les deux techniques vont de pair :

Utilisez le partitionnement pour trouver les groupes, puis les limites pour tester où les groupes se rencontrent. Dans notre code, un test distinct pour 17, 18, 60 et 61 a réussi la fonction correcte et détecterait ce bug. Notre guide d’analyse des valeurs limites couvre ce sujet dans son intégralité.

Avantages et limites

Le plus grand risque est une hypothèse erronée. Si le code comporte une règle cachée pour une valeur spécifique, le test que vous avez choisi risque tout simplement de ne pas l’atteindre. Les tests exploratoires et la couverture du code vous aident à trouver ce que les partitions ont manqué.

Erreurs courantes

• Oubli des partitions invalides. Tester uniquement les chemins heureux laisse la gestion des erreurs décochée.
• Test de plusieurs valeurs à partir d’une seule partition. Cela ajoute des coûts sans nouvelles informations.
• Combinaison de plusieurs valeurs invalides dans un seul test. Une erreur peut en cacher une autre.
• Sauter les limites. Les tests de partition seuls manquent souvent des bogues isolés.
• Deviner les règles. Si une exigence n’est pas claire, demandez. Est-ce que 60 ans devrait inclure les personnes de 60 ans et demi ?

Pour conclure

Le partitionnement d’équivalence remplace « combien de tests dois-je écrire ? » avec une bien meilleure question : “quels comportements existent et ai-je couvert chacun d’entre eux ?” Pour l’essayer, prenez un formulaire que vous testez aujourd’hui et listez ses partitions sur papier, y compris celles invalides. Ajoutez ensuite des limites. Vous vous retrouverez souvent avec moins de tests qui trouvent plus de bugs.

Questions fréquentes

Continuez à apprendre