Tests de la boîte noire et de la boîte blanche (blackbox / whitebox)

Pour comprendre le principe des tests d’application de type « boîte noire » et « blanche », je vais faire un parallèle avec ma chaudière à gaz et en profiter pour lui dire combien je la kiffe quand elle fonctionne alors qu’il fait -6°c dehors.

Test de la boîte noire

Le test de la boîte noire, c’est le test le plus simple car il est effectué par un utilisateur lambda et on teste tout simplement l’application.

Pour revenir à l’exemple de la chaudière, on va donc vérifier que

• la chaudière soit branchée,
• qu’elle soit allumée,
• que quand je bidouille le thermostat pour qu’il fasse 18°c dans l’appart, elle ne s’allume que quand il fait moins de 18°c.
• que quand je fais un appel d’eau chaude sous ma douche, la chaudière m’envoie bien de l’eau chaude.

Y’a pas besoin d’être technicien pour vérifier si la chaudière fonctionne. Si je me gèle le cul et que la chaudière ne se lance pas, c’est qu’elle ne fonctionne pas. Si quand j’actionne un robinet d’eau chaude et que même au bout de 5min je n’ai toujours pas d’eau chaude, c’est qu’il faut que j’appelle un technicien.

Bah c’est le test de la boîte noire.

Sur mon joli schéma, je représente le fait que l’utilisateur entre une commande (ouverture robinet d’eau chaude) et observe la sortie (la chaudière se met en route). La boîte noire symbolise le fait que l’utilisateur n’a pas accès au processus interne de fonctionnement de la chaudière mais peut quand même dire que ça marche.

Simplicité : n’importe qui peut réaliser ce type de test. Il est même parfois nécessaire de n’avoir aucune connaissance en informatique pour le réaliser pour vérifier que l’application est bel et bien à la portée de tout le monde. Rapidité : Pas besoin de former le testeur, on le met devant l’application, on lui donne une série de scenarii à réaliser et voilà. Impartialité : Soit l’application fonctionne, soit elle ne fonctionne pas. Il n’y a pas matière à discuter.

Superficialité : si l’utilisateur rencontre un problème, puisqu’il n’a pas accès au code (et que dans certains cas, il ne sait même pas coder), il ne saura pas dire d’où peut venir le problème. Également, les codeurs peuvent penser à des problèmes ou des failles de vulnérabilité auxquels certains utilisateurs ne penseront jamais. C’est donc l’un des tests les moins exhaustifs.

Test de la boîte blanche

Dans ce cas-là, c’est quand le technicien vient faire l’entretien de la machine. Il regarde l’intérieur de la bête, vérifie toutes les parties mécaniques, électriques, fait un peu le ménage pour éviter les panne liées à la poussière et en théorie, si tout à l’intérieur fonctionne, tout devrait fonctionner au niveau du fonctionnement final de la chaudière. (bon, il est pas con, il vérifie quand même que ça fonctionne bien, comme un utilisateur lambda…)

Sur le schéma, je représente le test de la boîte blanche de sorte qu’on voie bien que le technicien a accès à l’intérieur de la chaudière. Pour en revenir au test d’une application, ça signifie que le testeur a accès au code et peut le tester, vérifier qu’il soit correct, complet, fonctionnel.

Anticipation : On effectue souvent ce type de test pendant qu’on code l’application et on peut s’apercevoir assez rapidement si il y a un problème de fonctionnement et anticiper les problèmes ou bugs futurs. Optimisation : On travaille sur le code, donc on peut en profiter pour l’améliorer. Vérifier le bon fonctionnement d’une fonctionnalité permet souvent de penser à d’autres aspects, d’autres risques de sécurité, d’autres trucs auxquels on avait pas pensé en premier lieu. Exhaustivité : Comme on a les mains dans le code, on peut vérifier le code intégralement et vérifier notamment, que le ou les codeurs de l’application n’ont pas laissé, parfois intentionnellement, des failles qui peuvent être utilisées par les utilisateurs (avec certains jeux par exemple)

Complexité : Il faut avoir des compétences en informatique et connaître un minimum le programme qu’on teste. Durée : plus le code est long, plus le test va durer longtemps. D’autant que tout ne sera pas forcément à tester. C’est difficile de dire ce qu’il faut inspecter et ce qui n’en a pas l’intérêt. Intrusion : Laissez son code dans les mains d’un autre nécessite d’avoir un minimum confiance à cette personne. Il y a toujours des risques de vols, de modifications malintentionnées, de préparation au piratage,…

---

Crédits icônes :

• Zaff Studio
• S.Shohei
• KΛPKLΛM
• Connor Fowler