Test de la boîte noire et test de la boîte blanche : différences et usages

Le test de la boîte noire vérifie qu’un logiciel fait ce qu’on attend de lui, sans regarder son code : on lui donne des entrées et on compare les sorties au comportement prévu par les spécifications. Le test de la boîte blanche, à l’inverse, s’appuie sur la connaissance du code pour vérifier que chaque instruction, chaque branche et chaque chemin se comporte correctement. Les deux ne s’opposent pas : la boîte noire contrôle ce que voit l’utilisateur, la boîte blanche contrôle comment c’est construit, et un projet sérieux combine les deux (souvent avec une approche intermédiaire, la boîte grise).

On détaille ici chaque approche, leurs techniques, leurs différences dans un tableau, la boîte grise, leur usage en sécurité, et la façon de les intégrer dans un projet web.

• Pourquoi tester un logiciel ?
• Qu’est-ce que le test de la boîte noire ?
• Qu’est-ce que le test de la boîte blanche ?
• Quelle est la différence entre boîte noire et boîte blanche ?
• Qu’est-ce que le test de la boîte grise ?
• Boîte noire, grise ou blanche en test d’intrusion ?
• Comment les utiliser dans un projet web ?
• Quelles erreurs éviter ?
• Questions fréquentes
• Sources

Pourquoi tester un logiciel ?

Imaginez un fabricant qui lance une nouvelle bouilloire électrique sans vérifier qu’elle fonctionne. Les clients la branchent, elle chauffe mal, les réclamations s’accumulent. Avant de la remettre en vente, il va la tester. Une application web, c’est pareil : elle doit être testée avant sa mise en ligne pour s’assurer qu’elle fonctionne comme prévu, qu’elle ne perd pas de données et qu’elle ne présente pas de faille exploitable.

Le test n’est pas une phase isolée à la fin du projet. Il intervient tout au long du cycle de vie du développement logiciel, dès la conception et le prototypage, jusqu’à la mise en production et à chaque évolution. Plus un défaut est trouvé tôt, moins il coûte à corriger.

Le référentiel de certification des testeurs ISTQB (programme Foundation Level, version 4.0) classe les techniques de test en trois familles : boîte noire, boîte blanche et techniques fondées sur l’expérience. Ce sont les deux premières qui nous intéressent ici.

Qu’est-ce que le test de la boîte noire ?

Le test de la boîte noire (black box testing) examine le fonctionnement d’une application sans regarder sa structure interne. Le logiciel est vu comme une boîte opaque : le testeur connaît ce qui entre et ce qui doit sortir, pas ce qui se passe à l’intérieur. Il n’est pas aveugle pour autant : il s’appuie sur les spécifications, le cahier des charges, les récits utilisateurs ou les critères d’acceptation.

Il vérifie que chaque fonctionnalité fait ce qui est attendu, mais aussi des exigences non fonctionnelles : performance, facilité d’utilisation, compatibilité, sécurité vue de l’extérieur. On l’appelle aussi test fonctionnel, test comportemental, test basé sur les spécifications ou test entrée-sortie.

Les principales techniques de boîte noire

• Partitions d’équivalence : on regroupe les entrées qui doivent produire le même comportement et on teste une valeur par groupe (un âge valide, un âge négatif, un texte à la place d’un nombre).
• Analyse des valeurs limites : on teste aux frontières, là où se cachent beaucoup d’erreurs (panier à 0, à 1, au maximum autorisé, au maximum plus un).
• Tables de décision : pour les règles métier qui combinent plusieurs conditions (remise selon statut client et montant du panier).
• Transitions d’état : pour ce qui change d’état (commande en attente, payée, expédiée, annulée).
• Tests de cas d’utilisation : dérouler un parcours complet comme un utilisateur (créer un compte, commander, payer).

Contrairement à une idée reçue, le test de la boîte noire n’est pas réservé aux tests manuels ni aux tests d’acceptation. Il s’applique à tous les niveaux (unitaire, intégration, système, acceptation) et s’automatise très bien : scénarios de bout en bout avec des outils comme Playwright ou Selenium, tests d’API qui envoient une requête et vérifient la réponse.

Qu’est-ce que le test de la boîte blanche ?

Le test de la boîte blanche (white box testing) teste la structure interne de l’application : le testeur connaît le code, l’architecture et les choix techniques, et conçoit ses tests à partir d’eux. Il ne vérifie pas seulement que le résultat est juste, mais que chaque chemin emprunté par le programme selon les entrées est correct. On l’appelle aussi test structurel, test en boîte transparente ou en boîte de verre, ou test basé sur le code.

Il est surtout mené par les développeurs, au niveau des tests unitaires et d’intégration, mais peut s’appliquer au niveau système.

Les principales techniques de boîte blanche

• Couverture des instructions : chaque ligne de code est-elle exécutée au moins une fois par les tests ?
• Couverture des branches (ou décisions) : chaque if a-t-il été testé dans le cas vrai et dans le cas faux ?
• Couverture des conditions et MC/DC : dans une condition composée, chaque sous-condition influence-t-elle bien le résultat ? Ce niveau exigeant est utilisé dans les logiciels critiques.
• Test des chemins : parcourir les différents chemins possibles dans une fonction.
• Test des flux de données : suivre la vie d’une variable, de sa définition à ses utilisations.

Les outils de mesure de couverture (fournis avec PHPUnit, Jest ou coverage.py, par exemple) indiquent quelles lignes et branches n’ont jamais été exécutées. C’est un bon indicateur de ce qui manque, mais un taux de couverture élevé ne prouve pas l’absence de bugs : il dit ce qui a été exécuté, pas ce qui a été vérifié.

Quelle est la différence entre boîte noire et boîte blanche ?

Une image simple : votre réfrigérateur produit de la condensation et tout ce que vous y rangez devient humide. Vous changez la température, les réglages, rien n’y fait : vous testez en boîte noire, en observant le comportement. Le technicien envoyé par le fabricant démonte l’appareil et trouve la pièce défectueuse : il teste en boîte blanche, en connaissant le fonctionnement interne.

Les deux angles morts sont complémentaires : c’est précisément pour cela qu’on combine les deux approches.

Qu’est-ce que le test de la boîte grise ?

C’est l’intermédiaire : le testeur a une connaissance partielle de la structure interne (schéma de la base de données, documentation de l’API, architecture générale) sans travailler au niveau du code. Il teste par l’extérieur, comme en boîte noire, mais choisit ses cas de test en s’appuyant sur ce qu’il sait de l’intérieur. Exemple : vérifier via l’interface qu’une commande annulée remet bien le stock à jour, puis contrôler la valeur en base.

Boîte noire, grise ou blanche en test d’intrusion ?

Les mêmes termes sont utilisés en sécurité, avec un sens voisin, pour décrire ce que l’on donne à l’auditeur qui tente de pénétrer le système :

• Boîte noire : l’auditeur part de zéro, comme un attaquant extérieur, avec seulement l’adresse du site.
• Boîte grise : il dispose d’un compte utilisateur ou d’une documentation, comme un client ou un employé malveillant.
• Boîte blanche : il a accès au code source et à l’architecture, ce qui permet l’audit le plus complet.

Le guide de test de sécurité des applications web de l’OWASP (Web Security Testing Guide) est la référence pour organiser ces tests. Pour les risques à couvrir, voir notre article sur la sécurité des applications web.

Comment les utiliser dans un projet web ?

1. Tests unitaires en boîte blanche écrits par les développeurs sur la logique métier (calculs de prix, règles de remise, validation des données), avec un suivi de la couverture.
2. Tests d’intégration sur les échanges entre composants : base de données, API internes et externes, paiement.
3. Tests de bout en bout en boîte noire sur les parcours critiques (inscription, commande, paiement, formulaire de contact), automatisés et rejoués à chaque déploiement.
4. Recette par le client en boîte noire sur un serveur de préproduction, à partir des critères d’acceptation définis au départ.
5. Tests de sécurité adaptés à l’enjeu, en boîte grise ou blanche pour les applications sensibles.

L’automatisation de ces tests, et des méthodes comme le TDD, sont détaillées dans notre article sur les tests automatisés en développement web. Si vous faites développer une application web sur mesure, demandez dès le devis quels tests sont prévus et à quel niveau : c’est un bon indicateur du sérieux d’un prestataire.

Quelles erreurs éviter ?

• Ne tester qu’à la fin : les défauts découverts juste avant la mise en ligne sont les plus coûteux et les plus stressants à corriger.
• Opposer les deux approches : ne faire que de la boîte blanche laisse passer les incompréhensions du besoin, ne faire que de la boîte noire laisse des pans de code jamais exécutés.
• Viser 100 % de couverture comme objectif : cela pousse à écrire des tests qui exécutent le code sans rien vérifier.
• Tester sans spécifications : sans comportement attendu écrit, un test de boîte noire n’a pas de référence.
• Oublier les cas d’erreur : champs vides, valeurs limites, connexion perdue, double clic sur « payer ».

Questions fréquentes

Un test unitaire est-il forcément un test de boîte blanche ?

Non. Un test unitaire peut vérifier une fonction uniquement à partir de ce qu’elle doit renvoyer (boîte noire) ou être conçu pour couvrir ses branches internes (boîte blanche). C’est la façon de concevoir le test qui compte, pas son niveau.

Lequel est le plus important ?

Aucun des deux ne suffit seul. Pour un client, les tests de boîte noire sur les parcours critiques sont les plus visibles ; pour la robustesse du code dans le temps, les tests de boîte blanche sont indispensables.

Faut-il savoir programmer pour faire des tests de boîte noire ?

Pas pour les tests manuels : un utilisateur final peut dérouler un scénario. Pour les automatiser, en revanche, des bases de programmation ou un outil d’enregistrement de scénarios sont nécessaires.

Le test de la boîte noire est-il plus rapide ?

Pas forcément. Concevoir de bons cas de test à partir des exigences demande de la méthode, et les tests de bout en bout sont plus lents à exécuter que des tests unitaires. Le temps dépend de la taille de l’application et du niveau d’exigence.

Qu’est-ce qu’un test de régression ?

C’est le fait de rejouer les tests existants après une modification pour vérifier qu’elle n’a rien cassé ailleurs. Il utilise des tests de boîte noire comme de boîte blanche, et c’est là que l’automatisation est la plus rentable.

Sources

• ISTQB : Certified Tester Foundation Level (CTFL) v4.0
• Wikipédia : Black-box testing
• Wikipédia : White-box testing
• Wikipédia : Gray-box testing
• OWASP : Web Security Testing Guide