Boundary Value Analysis & Equivalence Partitioning - Short

Courte version pour présenter ces deux concepts

Transcript

1. TESTS LOGICIELS Boundary Value Analysis & Equivalence Partitioning Deux techniques complémentaires pour tester efficacement Moins de cas de test — plus de bugs détectés
2. Le problème : on ne peut pas tout tester Une fonction qui prend un entier 32 bits accepte plus de 4 milliards de valeurs. SI ON TESTAIT TOUT... 4 294 967 296 valeurs possibles pour un seul int À 1 microseconde par test : ≈ 71 minutes pour un seul paramètre. Avec deux paramètres → 15 000 ans. LA SOLUTION Tester intelligemment → Regrouper les valeurs qui se comportent pareil (Equivalence Partitioning) → Tester aux frontières où les bugs se cachent (Boundary Value Analysis) → Quelques cas bien choisis valent mieux que des milliers de cas au hasard. 2 / 10
3. Equivalence Partitioning Partitionnement par classes d'équivalence DÉFINITION On divise l'espace d'entrée en classes telles que, pour chaque classe, le programme est supposé se comporter de la même manière. Idée visuelle Invalides (trop petit) Valides Invalides (trop grand) PRINCIPES 1. Identifier les classes (valides et invalides) 2. Choisir un représentant par classe 3. Supposer qu'un représentant suffit pour révéler le comportement de toute la classe 3 / 10
4. Boundary Value Analysis Analyse des valeurs aux frontières DÉFINITION On teste en priorité les valeurs situées sur et autour des bornes (limites) de chaque classe d'équivalence — là où les bugs apparaissent le plus souvent. B-2 B-1 B B+1 B+2 Zoom autour d'une frontière frontière B = dernière valeur valide POURQUOI LES BORNES ? → Erreurs classiques : < au lieu de <=, > au lieu de >=, boucles for qui loupent le dernier élément → Règle pratique : pour chaque borne B, tester B-1, B, B+1. → Intuition : les bugs se concentrent aux transitions entre classes, pas au milieu. 4 / 10
5. Exemple simple : validation d'âge # Spécification def isEligible(age: int) -> bool: # valide si 18 <= age <= 65 return 18 <= age <= 65 3 CLASSES D'ÉQUIVALENCE Trop jeune age < 18 Éligible 18 ≤ age ≤ 65 Trop vieux age > 65 Visualisation sur l'axe des âges age < 18 18 ≤ age ≤ 65 (éligible) age > 65 0 100 frontière : 18 frontière : 65 6 tests suffisent pour couvrir frontières + classes isEligible(17) == False isEligible(18) == True isEligible(19) == True isEligible(64) == True isEligible(65) == True isEligible(66) == False 5 / 10
6. Exemple complexe : frais de port par paliers La fonction prend un nombre entier d'articles et renvoie les frais (en centimes). SPÉCIFICATION qty <= 0 → ValueError 1 ≤ qty ≤ 5 → 500 centimes 6 ≤ qty ≤ 20 → 300 centimes 21 ≤ qty ≤ 100 → 100 centimes qty ≥ 101 → 0 (livraison gratuite) 5 CLASSES D'ÉQUIVALENCE ≤ 0 → erreur 1 — 5 → 500 6 — 20 → 300 21 — 100 → 100 ≥ 101 → 0 bornes à tester : 0 | 1 5 | 6 20 | 21 100 | 101 CAS DE TEST RECOMMANDÉS qty=0 → Error qty=-1 → Error qty=1 → 500 qty=5 → 500 qty=6 → 300 qty=20 → 300 qty=21 → 100 qty=100 → 100 qty=101 → 0 SYNTHÈSE 5 classes × 2 bornes × 3 valeurs (B-1, B, B+1) → 9 tests au lieu de ∞. Astuce : les bornes se chevauchent (5 et 6 sont des voisines), donc on n'a pas besoin de B-1 et B+1 séparés pour chaque classe. 6 / 10
7. Pourquoi ces techniques donnent de bons résultats 01 Les bugs ne sont pas uniformes Ils se concentrent aux frontières : < vs ≤, erreurs d'index, off-by-one. Tester au milieu d'une classe détecte peu de défauts. 02 Les classes capturent la structure Si le code traite deux valeurs de la même manière, une seule suffit. Couvrir les classes, c'est couvrir les branches. 03 Études empiriques Plusieurs études (Myers, Beizer) montrent que BVA détecte 30–50% plus de bugs que des tests aléatoires de même taille. 04 Effort rationnel Le nombre de tests est linéaire en nombre de classes, pas exponentiel en taille du domaine. Idéal pour le TDD et la CI. 7 / 10
8. Combien de cas de test faut-il ? Une formule simple donne une borne raisonnable pour un paramètre entier. FORMULE N = C + 3 × B C = nombre de classes d'équivalence B = nombre de bornes (B-1, B, B+1) (souvent on fusionne : N ≈ 2C + nombre de bornes internes) EXEMPLES CHIFFRÉS Cas Classes Bornes Tests isEligible(age) 3 2 6 shippingCost(qty) 5 4 9 daysInMonth(m, y) 4 3 ≈ 10 Une fonction à 2 paramètres C1 × C2 B1 + B2 ≥ 10 ATTENTION — EXPLOSION COMBINATOIRE Avec plusieurs paramètres, ne pas multiplier toutes les classes entre elles ! Utiliser « pairwise testing » (couvrir toutes les paires de valeurs) pour garder un nombre de cas gérable. 8 / 10
9. Application aux tests unitaires Ce qu'on peut demander / écrire pour utiliser ces techniques en pratique. CHECKLIST AVANT D'ÉCRIRE LES TESTS ✓ Lister le domaine d'entrée de chaque paramètre ✓ Identifier les classes d'équivalence (valides ET invalides) ✓ Repérer chaque borne : <, ≤, ==, ≥, > ✓ Pour chaque borne B, tester B-1, B, B+1 ✓ Un représentant suffit pour le cœur de la classe ✓ Paramétrer les tests (ex. pytest.parametrize, JUnit @ParameterizedTest) EXEMPLE EN PYTEST import pytest @pytest.mark.parametrize( "qty, expected", [ (0, ValueError), # borne + classe (1, 500), (5, 500), (6, 300), (20, 300), (21, 100), (100, 100), (101, 0), ]) def test_shipping(qty, expected): if isinstance(expected, type): with pytest.raises(expected): shipping_cost(qty) else: assert shipping_cost(qty) == expected Un test paramétré = un tableau de cas issus directement de l'analyse des classes et des bornes. 9 / 10
10. À RETENIR Tester aux bons endroits, pas partout. Equivalence Partitioning Réduit l'infini à quelques classes qui se comportent pareil. Boundary Value Analysis Cible les frontières — là où 80% des bugs se trouvent. Tests paramétrés Traduit directement l'analyse en une liste de cas à exécuter. « Moins de cas, mieux choisis » — telle est la promesse de BVA & EP.