Conception de cas de test: nominaux et limites

1. Pourquoi tester ? Pour trouver des erreurs !

On pourrait penser que le but des tests est de prouver qu'un algorithme est parfait. En réalité, c'est presque le contraire. Comme le disait l'informaticien Edsger Dijkstra, "le test peut montrer la présence de bugs, mais jamais leur absence". L'objectif principal des tests est de trouver des erreurs en soumettant l'algorithme à des épreuves rigoureuses.

Un test isolé ne prouve pas grand-chose. C'est pourquoi nous créons un jeu d'essais (ou suite de tests) : une collection de plusieurs tests soigneusement choisis pour couvrir un large éventail de situations possibles.

Pour approfondir cette idée, je vous invite à lire l'introduction d'un document sur la validation de programmes.

2. L'anatomie d'un cas de test

Pour être rigoureux, un cas de test ne s'écrit pas sur un coin de table. Il suit une structure claire qui permet à n'importe qui (y compris vous-même plus tard) de le comprendre et de le rejouer.

Voici un modèle professionnel pour un cas de test :

Un cas de test bien formulé contient au minimum :

• Identifiant : Un nom ou un code unique (ex: TEST_MAX_01).
• Description : Ce que le test cherche à vérifier (ex: "Vérifie que l'algorithme trouve le max dans un tableau simple").
• Entrées / Pré-requis : Les données que vous allez fournir à votre algorithme (ex: le tableau [5, 1, 9, 3]).
• Action : L'opération à effectuer (ex: "Exécuter la fonction TrouverMax avec le tableau fourni").
• Résultat Attendu : Le résultat que votre algorithme doit produire s'il est correct. C'est votre "oracle". (ex: 9).
• Résultat Réel : Le résultat que votre algorithme a effectivement produit.
• Statut : Succès (si réel = attendu) ou Échec.

Cette structure vous force à réfléchir au comportement attendu de votre algorithme avant même de le tester, une pratique clé pour la rigueur.

3. Les deux familles de cas de test : Nominal et Limite

Pour qu'un jeu d'essais soit efficace, il doit contenir des tests de deux familles très différentes.

a) Les cas nominaux

Ce sont les cas "normaux", "attendus", le "cœur" du fonctionnement de l'algorithme. Ils représentent des situations d'utilisation typiques.

• Exemple pour un algorithme CalculerMoyenne(T):
  • Un cas nominal serait un tableau comme [10, 20, 30]. Résultat attendu : 20.
• Exemple pour un algorithme Trier(T):
  • Un cas nominal serait un tableau en désordre comme [5, 2, 8, 4]. Résultat attendu : [2, 4, 5, 8].

Il est important de les tester pour s'assurer que la logique de base de l'algorithme est correcte, mais ils ne suffisent pas.

b) Les cas limites (ou "edge cases")

C'est là que se cachent la majorité des bugs. Les cas limites testent les "bords" du domaine d'entrée de votre algorithme. Ce sont des situations valides, mais potentiellement délicates.

Pour identifier ces cas, on utilise une technique appelée Analyse des Valeurs Limites (Boundary Value Analysis - BVA). L'idée est de tester les valeurs aux frontières d'une plage de données autorisée.

Quelles sont ces valeurs limites ?

• Tailles : Tableaux vides, tableaux avec un seul élément.
• Positions : L'élément recherché est au début, à la fin du tableau.
• Valeurs : Le nombre 0, le nombre 1, des nombres négatifs, la plus petite ou la plus grande valeur autorisée.
• États : Un tableau déjà trié, trié à l'envers, ou contenant des doublons, que l'on donne à un algorithme de tri.

Pour voir comment appliquer cette idée, lisez l'introduction d'un article qui explique cette technique.

4. Application : L'exemple du triangle

Le "problème du triangle" est un exercice classique pour s'entraîner à la conception de cas de test.

Problème : Un algorithme prend trois longueurs a, b, c (disons, des entiers entre 1 et 100) et doit déterminer s'ils peuvent former un triangle, et si oui, de quel type (équilatéral, isocèle, scalène).

Rappel des règles :

1. Pour former un triangle, la somme de deux côtés doit toujours être supérieure au troisième : a+b > c, a+c > b, et b+c > a.
2. Équilatéral : a = b = c.
3. Isocèle : deux côtés sont égaux.
4. Scalène : tous les côtés sont différents.

L'article que vous venez de commencer à lire fournit un excellent jeu de tests pour ce problème, basé sur la méthode BVA.

Analysons quelques-uns de ces cas :

• T5 (a=50, b=50, c=50) : Cas nominal. Toutes les valeurs sont au milieu de l'intervalle [1, 100]. Résultat attendu : Équilatéral.
• T1 (a=1, b=50, c=50) : Cas limite. On teste la borne inférieure (1) pour la variable a. Résultat attendu : Isocèle.
• T4 (a=100, b=50, c=50) : Cas limite crucial. On teste la borne supérieure (100) pour a. Ici, la condition b+c > a devient 50+50 > 100, ce qui est faux. Résultat attendu : Pas un triangle. C'est un bug facile à manquer sans ce test !
• T9 et T13 font le même test pour les variables b et c.

Ce jeu de 13 tests couvre systématiquement les bornes de chaque variable d'entrée, ce qui le rend très efficace pour trouver des erreurs.

5. À vous de jouer !

Mettons cela en pratique. Vous avez conçu un algorithme TrouverMaximum(T) qui prend en entrée un tableau d'entiers T et renvoie la plus grande valeur. Le tableau ne peut pas être vide.

Concevez un jeu de 5 cas de test pour cet algorithme. Pour chaque cas, spécifiez l'identifiant, les données d'entrée et le résultat attendu. Pensez à inclure au moins un cas nominal et plusieurs cas limites.

Conclusion

Vous savez maintenant comment approcher la validation d'un algorithme de manière structurée et professionnelle. Cette démarche est un pilier pour atteindre votre objectif d'écrire du "code clean" : un code dont on peut avoir confiance car il a été éprouvé dans des conditions variées.

Points clés à retenir :

• Le but principal des tests est de détecter des erreurs.
• Utilisez une structure formelle (Entrées, Résultat Attendu, etc.) pour rédiger vos cas de test.
• Un bon jeu de tests doit inclure des cas nominaux (situations typiques) et des cas limites (valeurs aux frontières).
• L'Analyse des Valeurs Limites (BVA) est une technique simple et puissante pour identifier les cas limites les plus pertinents (taille, position, valeurs extrêmes).

Dans la prochaine leçon, nous ferons un petit retour en arrière stratégique. Nous aborderons la notion de solution par "force brute" : comment trouver une première solution simple et directe à un problème, et comment évaluer son coût. C'est souvent un excellent point de départ avant de chercher des algorithmes plus optimisés.