Glossaire · Fondamentaux du test
Test boîte noire
En anglais : Black-box testing
Également appelé : tests boîte noire, test en boîte noire, test fonctionnel, test basé sur les spécifications
Définition
Tester un système par ses entrées et ses sorties au regard des exigences, sans examiner ni utiliser le code ou la conception interne.
Le test boîte noire considère le système comme une boîte fermée : vous fournissez des entrées, observez les sorties et les comparez à ce que la spécification prévoit. Le testeur n’a pas besoin de connaître le langage de programmation, l’architecture ni la structure du code. La plupart des tests fonctionnels, système, d’API et d’acceptation sont des tests boîte noire.
Exemple
Une API de virement accepte des montants de 1 à 10 000. Sans voir le moindre code, un testeur boîte noire dérive des tests à partir de la règle :
- Classes d’équivalence : sous la plage (0), valide (500), au-dessus de la plage (10 001), non numérique (
"abc"). - Valeurs limites : 0, 1, 2, 9 999, 10 000, 10 001.
- Résultats attendus : les montants valides renvoient
201 Created; les montants invalides renvoient400 Bad Requestavec un message d’erreur et ne déplacent pas d’argent.
Les techniques utilisées ici, partitionnement en classes d’équivalence et analyse des valeurs limites, ainsi que les tables de décision, le test de transitions d’état et le test pairwise, sont les principales techniques de conception boîte noire.
Test boîte noire et test boîte blanche
| Boîte noire | Boîte blanche | |
|---|---|---|
| Base | Exigences et spécifications | Structure interne du code |
| Connaissances requises | Ce que le système doit faire | Comment le code est écrit |
| Niveaux typiques | Système, API, acceptation | Unitaire, une partie de l’intégration |
| Mesuré par | Couverture des exigences | Couverture de code (instructions, branches) |
| Détecte | Comportement manquant ou erroné, écarts avec la spécification | Chemins non testés, code mort, erreurs de logique |
L’un ne remplace pas l’autre. Le test boîte noire peut révéler des fonctionnalités qui n’ont jamais été implémentées, ce que le test boîte blanche ne peut pas faire puisqu’il n’y a aucun code à inspecter. Le test boîte blanche peut révéler des chemins que la spécification ne mentionne jamais. Le test boîte grise combine les deux : on teste via l’interface tout en utilisant certaines connaissances internes, par exemple en vérifiant la base de données après un appel d’API ou en sachant quel service une requête atteint.
Forces et limites
Les tests boîte noire sont indépendants de l’implémentation : ils survivent donc au refactoring et peuvent être écrits à partir des exigences avant même que le code existe. Leur limite est que vous ne pouvez pas savoir quels chemins internes vous avez manqués, et sans techniques systématiques il est facile de ne tester que les cas nominaux évidents.