Techniques de test
Concevoir des cas de test ne signifie pas en écrire beaucoup, mais en écrire des bons. Les techniques ISTQB structurent la conception pour couvrir le risque avec le moins de cas possible.
01 - Les grandes familles
Trois grandes familles
Boîte noire
Tests basés sur les spécifications
Le testeur conçoit ses cas sans connaître le code interne. Il s'appuie sur les exigences, les règles métier et les contrats d'interface.
Exemples :
-
Partitions d'équivalence
-
Valeurs limites
-
Tables de décisions
-
Transitions d'état
-
Cas d'utilisation.
Boîte blanche
Tests basés sur la structure
Le testeur exploite la connaissance du code pour couvrir instructions, branches et chemins. Souvent porté par les développeurs.
Exemples :
-
Couverture d'instructions, de décisions, de conditions, MC/DC.
-
Couverture de chemins.
Basés sur l'expérience
Tests basés sur l'intuition du testeur
Quand la spécification est incomplète ou que le temps manque. La valeur vient de l'expertise et de la connaissance du domaine.
Exemples :
-
Tests exploratoires
-
Estimation d'erreurs (error guessing)
-
Tests basés sur des checklists
-
Attaques logicielles.
02 - Boîte noire
Techniques boîte noire
Les techniques boîte noire consistent à tester le logiciel de l’extérieur, en se basant sur les exigences, les entrées et les sorties attendues, sans regarder le code ni l’implémentation interne.
Partitions d'équivalence
Quand : Quand les entrées peuvent être groupées en classes traitées de la même façon.
Comment : Identifier les classes valides et invalides, puis un représentant par classe.
Exemple :
Champ âge :
[0–17] mineur, [18–64] adulte, [65+] senior, < 0 invalide, > 120 invalide. → 5 cas.
Valeurs limites
Quand : Aux frontières des partitions - c'est là que se cachent la majorité des bugs.
Comment : Tester min, min−1, min+1, max, max−1, max+1.
Exemple :
Mot de passe entre 8 et 32 caractères → tester 7, 8, 9, 31, 32, 33.
Tables de décision
Quand : Plusieurs règles métier se combinent et produisent des résultats différents.
Comment : Lister les conditions en colonnes, les actions en lignes, couvrir chaque combinaison utile.
Exemple :
Calcul d'une remise selon (client fidèle ? × panier > 100 € ? × code promo ?). 8 combinaisons à tester.
Transition d'état
Quand : Un système passe par des états successifs.
Comment : Modéliser les états, transitions, événements.
Exemple :
Statut d'une commande : Panier > Payée > Préparée > Expédiée > Livrée. /!\ Tester aussi Payée > Remboursée.
Cas d'utilisation
Quand : Valider un parcours utilisateur de bout en bout.
Comment : Dérouler le scénario nominal, puis les scénarios alternatifs et d'exception.
Exemple :
Acheter en ligne : ajout au panier > checkout > paiement OK / KO / 3DS / annulation.
Test par paires
Quand : Trop de combinaisons possibles entre paramètres (explosion combinatoire).
Comment : Couvrir toutes les paires de valeurs au lieu de toutes les combinaisons. Outils : PICT (Pairwise Independent Combinatorial Tool - Microsoft), AllPairs.
Exemple :
5 navigateurs × 4 OS × 3 langues × 2 thèmes = 120 combinaisons > ~20 avec pairwise.
03 - Boîte blanche
Techniques boîte blanche
Les niveaux de couverture s'empilent : chaque niveau supérieur implique le précédent. Plus c'est strict, plus c'est cher. À adapter selon le risque.
01 - Couverture d'instructions
Chaque ligne de code est exécutée au moins une fois.
Niveau le plus faible.
02 - Couverture de décisions (branches)
Chaque condition if / else est évaluée à vrai ET à faux. Standard pour la plupart des projets.
03 - Couverture de conditions
Chaque sous-condition booléenne prend les deux valeurs. Plus fin que la couverture de décisions.
04 - MC/DC
Modified Condition / Decision Coverage (Couverture des conditions / décisions modifiées). Exigée pour le logiciel critique (DO-178C, aéronautique).
05 - Couverture de chemins
Tous les chemins d'exécution. Théorique : explose vite avec les boucles.
Tests exploratoires
Apprentissage, conception et exécution en parallèle. Cadré par des chartes (session-based test management).
"Error guessing" (test par estimation d’erreurs)
Le testeur expérimenté anticipe les zones fragiles : champs vides, débordement, dates aux changements d'heure, caractères spéciaux.
Checklists
Listes de vérifications réutilisables (formulaires, accessibilité, sécurité, mobile). Complètent sans remplacer une conception structurée.
Attaques logicielles
Souvent utilisées en test d'intrusion : attaquer l'entrée, la sortie, la donnée, le calcul, l'interface. Pensée d'attaquant appliquée au test.
04 - L'exploratoire
Tests basés sur l'expérience
Une approche de test logiciel dans laquelle le testeur explore l’application en temps réel, en combinant à la fois la découverte du produit, la conception et l’exécution des tests, plutôt que de suivre un plan de test prédéfini ligne par ligne.
05 - Exemple
Exemple combiné - un champ "code postal"
01 - Exigence
Le champ « code postal » accepte 5 chiffres pour la France.
02 - Partitions
Valides : 5 chiffres
Invalides : <5 chiffres, >5 chiffres, lettres, vide.
03 - Valeurs limites
Tester en FR : 4 chiffres, 5 chiffres, 6 chiffres.
04 - Table de décision
Code rempli ? × Format valide ? > on garde les 3 réalisables.
05 - Résultat
≈3 cas de test couvrent la règle - au lieu d'en écrire 50 au hasard.
À éviter
"Tout tester" : impossible, coûteux, inutile. Préférer un mix risque / couverture.
Spécifications claires & règle métier
Tables de décision, partitions, valeurs limites.
Workflow / cycle de vie
Transitions d'état, cas d'utilisation.
Spécifications floues ou peu de temps
Tests exploratoires + deviner où pourraient se cacher les erreurs.
Combinaisons multiples
En paire pour éviter l'explosion de cas possibles.
06 - Comment choisir
Choisir la bonne technique
07 - A retenir
En bref :
-
Boîte noire : partir des exigences et du comportement attendu.
-
Boîte blanche : partir du code et des chemins d’exécution.
-
Expérience : exploiter intuition, contexte et connaissance du produit.
-
Le bon mix de techniques dépend des risques et du temps disponible.