Tests en boîte noire, grise ou blanche : quelles différences ?

Lorsqu’un logiciel ou une application sont créés, il est vital de réaliser plusieurs types de tests pour s’assurer que le produit est fini, complet, sécurisé et efficace. Pour réaliser ces tests, plusieurs méthodes sont possibles : les tests en « boîte noire », en « boîte blanche » et en « boîte grise ». Chacune de ces méthodes offre des possibilités différentes, que nous allons exposer dans cet article.

Les tests en « boîte noire »

Les tests en « boite noire » consistent à examiner uniquement les fonctionnalités d’une application, c’est-à-dire si elle fait ce qu’elle est censée faire, peu importe comment elle le fait. Sa structure et son fonctionnement interne ne sont pas étudiés. Le testeur doit donc savoir quel est le rôle du système et de ses fonctionnalités, mais ignore ses mécanismes internes. Il a un profil uniquement « utilisateur ».

Ainsi, cette méthode sert à vérifier, après la finalisation d’un projet, si un logiciel ou une application fonctionne bien et sert efficacement ses utilisateurs. En général, les testeurs sont à la recherche de fonctions incorrectes ou manquantes, d’erreurs d’interface, de performance, d’initialisation et de fin de programme, ou bien encore d’erreurs dans les structures de données ou d’accès aux bases de données externes.

Pour cela, ils préparent des scénarios calqués sur les différents chemins utilisateur possibles sur le système testé. Toutes les fonctionnalités doivent être prises en compte, pour qu’une fois tous les tests effectués, elles aient toutes été éprouvées. Les tests consistent à suivre un scenario, et à vérifier pour chaque fonctionnalité que les entrées (inputs) valides sont acceptées, que celles non valides sont refusées, et bien entendu, qu’à chaque fois, le résultat (sortie ou output) attendu est bien obtenu. C’est ce que l’on appelle la méthode « trial and error » (essais et erreurs).

Les avantages de cette méthode sont les suivants :

• Simplicité : ces tests sont simples à réaliser, car on se concentre sur les entrées et les résultats. Le testeur n’a pas besoin d’apprendre à connaître le fonctionnement interne du système ou son code source, qui n’est pas accessible. Cette méthode est donc également non intrusive.
• Rapidité : en raison du peu de connaissances nécessaires sur le système, le temps de préparation des tests est très court. Les scénarios sont relativement rapides à créer et à tester, puisqu’ils suivent les chemins utilisateurs, qui sont relativement peu nombreux selon la taille du système.
• Impartialité : on est ici dans une optique « utilisateur » et non « développeur ». Les résultats du test sont impartiaux : le système marche, ou il ne marche pas. Il n’y a pas de contestation possible, comme par exemple sur l’utilisation de tel processus plutôt qu’un autre selon l’opinion du développeur.

Mais les tests en « boîte noire » ont également des inconvénients :

• Superficialité : étant donné que le code n’est pas étudié, ces tests ne permettent pas de voir, en cas de problème, quelles parties précises du code sont en cause. De plus, les testeurs peuvent passer à côté de problèmes ou vulnérabilités sous-jacentes. Certains problèmes sont également difficilement repérables avec cette méthode, comme par exemple ceux liés à la cryptographie, ou à des aléas de mauvaise qualité. C’est donc l’un des tests les moins exhaustifs.
• Redondance : si d’autres tests sont effectués, il est possible que celui-ci perde grandement de son intérêt, puisque son champ d’action a tendance à être inclus dans celui d’autres tests.

Dans le cas des tests d’intrusion

Dans le cas particulier des tests d’intrusion, le principe reste le même : les testeurs ne connaissent rien sur le fonctionnement de l’application, et ils n’ont pas accès à son code source. Ils se retrouvent donc dans la peau d’un internaute normal : c’est en général l’état dans lequel se trouvent les pirates, ce qui rend ces tests très réalistes. Cependant, des connaissances en programmation sont dans ce cas utiles, voire nécessaires, pour le testeur (comme pour un pirate), car elles vont l’aider à identifier les tests pertinents à réaliser.

Cependant, les tests d’intrusion en boîte noire peuvent prendre beaucoup de temps (les testeurs vont vérifier de nombreuses méthodes d’attaques différentes pour s’assurer qu’aucune ne fonctionne). De plus, comme précisé plus haut, certaines parties de l’infrastructure du système ne seront pas testées, car elles n’ont aucune influence sur l’interface utilisateur sur laquelle le test a lieu.

Les tests en « boîte blanche »

Les tests en « boîte blanche » consistent à examiner le fonctionnement d’une application et sa structure interne, ses processus, plutôt que ses fonctionnalités. Sont ici testés l’ensemble des composants internes du logiciel ou de l’application, par l’intermédiaire du code source, principale base de travail du testeur.

Pour réaliser un test en « boîte blanche », ce dernier doit donc avoir des compétences de programmation, afin de comprendre le code qu’il étudie. Il doit également avoir une vue globale du fonctionnement de l’application, des éléments qui la composent, et naturellement de son code source. Contrairement aux tests en « boîte noire », le testeur ici a un profil développeur, et non pas utilisateur.

En effectuant un test en « boîte blanche », on voit en effet quelle ligne de code est appelée pour chaque fonctionnalité. Cela permet de tester le flux de données ainsi que la gestion des exceptions et des erreurs. On s’intéresse également à la dépendance des ressources, ainsi qu’à la logique interne et justesse du code. C’est pourquoi ces tests sont surtout utiles pendant le développement d’une application, même s’ils peuvent être effectués durant de nombreuses phases de la vie d’un projet. La méthode en « boîte blanche » peut être appliquée pour les tests unitaires (majoritairement), les tests d’intégration et les tests système.

La méthode en « boîte blanche » utilise des scénarios de test, créés par le testeur selon ce qu’il a appris du code source de l’environnement. L’objectif est qu’en testant l’ensemble de ces scénarios, toutes les lignes de code soient vérifiées. Ce qui est regardé, c’est le processus effectué par l’application après une entrée (input) pour obtenir un résultat. On ne fait que vérifier si le code produit les résultats espérés.

Cette méthode a plusieurs avantages :

• Anticipation : effectuer ces tests au cours du développement d’un programme permet de repérer des points bloquants qui pourraient se transformer en erreurs ou 

• problèmes dans le futur (par exemple lors d’une montée en version, ou même lors de l’intégration du composant testé dans le système principal).
• Optimisation : étant donné qu’il travaille sur le code, le testeur peut également profiter de son accès pour optimiser le code, pour apporter de meilleures performances au système étudié (sans parler de sécurité…).
• Exhaustivité : étant donné que le testeur travaille sur le code, il est possible de vérifier intégralement ce dernier. C’est le type de test qui permet, s’il est bien fait, de tester l’ensemble du système, sans rien laisser passer. Il permet de repérer des bugs et vulnérabilités cachées intentionnellement (comme par exemple des portes dérobées). C’est notamment pour cela que l’ARJEL impose des audits de code en « boîte blanche » aux opérateurs de jeux en ligne, afin de s’assurer qu’aucun mécanisme caché ne vienne désavantager les joueurs.

Mais on ne peut pas tout avoir… C’est pourquoi ces tests ont également des inconvénients.

• Complexité : ces tests nécessitent des compétences en programmation, et une connaissance accrue du système étudié.
• Durée : de par la longueur du code source étudié, ces tests peuvent être très longs.
• Industrialisation : pour réaliser des tests en « boîte blanche », il est nécessaire de se munir d’outils tels que des analyseurs de code, des débogueurs… Cela peut avoir un impact négatif sur les performances du système, voire même impacter les résultats.
• Cadrage : il peut être très compliqué de cadrer le projet. Le code source d’un programme est souvent très long, il peut donc être difficile de déterminer ce qui est testé, ce qui peut être mis de côté… En effet, il n’est pas toujours réaliste de tout tester, ce qui prendrait trop de temps. Il est également possible que le testeur ne se rende pas compte qu’une fonctionnalité prévue dans le programme n’y a pas été intégrée. Il n’est donc pas dans le scope du testeur de vérifier si tout est là : il ne fait que tester ce qui est effectivement présent dans le code.
• Intrusion : cette méthode est très intrusive. Il peut en effet être risqué de laisser son code à la vue d’une personne externe à son entreprise : il y a des risques de casse, de vol, voire même d’intégration de portes dérobées… Choisissez donc toujours des testeurs professionnels !

Dans le cas des tests de pénétration

Si cette méthode est utilisée dans le cadre d’un test de pénétration, cela signifie que les testeurs connaissent le fonctionnement du système attaqué : ils ont accès au code source, au design de l’architecture de l’application… Les testeurs se basent alors sur ces connaissances pour élaborer des tests permettant de vérifier la sécurité de l’application.

Cela permet notamment, par rapport à la méthode en « boîte noire », de tester la qualité de code, et d’avoir un champ d’action beaucoup plus étendu. Cependant, cette méthode ne permet pas de tester l’application en conditions « réelles », car aucun pirate n’aurait accès à autant d’information ; elle permet pourtant de sécuriser efficacement son application, notamment contre les menaces internes !

Les tests en « boîte grise »

Les tests en « boîte grise » compilent ces deux précédentes approches : ils éprouvent à la fois les fonctionnalités et le fonctionnement d’un système. C’est-à-dire qu’un testeur va par exemple donner une entrée (input) à un système, vérifier que la sortie obtenue est celle attendue, et vérifier par quel processus ce résultat a été obtenu.

Dans ce type de tests, le testeur connaît le rôle du système et de ses fonctionnalités, et a également une connaissance, bien que relativement limitée, de ses mécanismes internes (en particulier la structure des données internes et les algorithmes utilisés). Attention cependant, il n’a pas accès au code source !

Ces tests peuvent difficilement être effectués pendant la phase de développement du projet, car elle implique des tests sur les fonctionnalités du programme : celui-ci doit déjà être dans un état proche de final pour que ces tests puissent être pertinents. En effet, pendant les tests en « boîte grise », ce sont surtout des techniques de « boîte noire » qui sont utilisées, puisque le code n’est pas accessible. Cependant, les scénarios sont orientés pour jouer sur les processus sous-jacents, et ainsi les tester également.

Bien entendu, la méthode « boîte grise » combine surtout les avantages des méthodes « boîte blanche » et « boîte noire ». On peut cependant noter deux gros bénéfices de cette technique :

• Impartialité : les tests en « boîte grise » gardent une démarcation entre les développeurs et le testeur, puisque ce dernier n’étudie par le code source et peut s’appuyer sur les résultats obtenus en testant l’interface utilisateur.
• Intelligence : en connaissant la structure interne du programme, un testeur peut créer des scénarios plus variés et intelligents, afin d’être certain de tester toutes les fonctionnalités mais également tous les processus correspondants du programme.

En parallèle, l’un des inconvénients les plus importants de ces tests est le suivant :

• Non exhaustivité : étant donné que le code source n’est pas accessible, il est impossible avec des tests en « boîte grise » d’espérer avoir une couverture complète du programme.

Dans le cas des tests de pénétration

Dans le cas des tests de pénétration, la méthode « boîte grise » consiste à effectuer les tests en étant logué sur l’application avec un compte utilisateur. C’est un niveau intermédiaire, où les testeurs connaissent les mécanismes internes de l’application, et qui les oriente dans leurs choix de tests. Il permet de créer des tests relativement exhaustifs, tout en les maintenant dans une optique relativement réaliste et proche de ce que pourrait faire un réel pirate.

Pour mieux comprendre…

Une analogie est souvent utilisée pour différencier ces techniques, en comparant le système testé à une voiture.

• En méthode « boîte noire », on vérifie que la voiture fonctionne en allumant les lumières, en klaxonnant et en tournant la clé pour que le moteur s’allume. Si tout se passe comme prévu, la voiture fonctionne.
• En méthode « boîte blanche », on emmène la voiture chez le garagiste, qui regarde le moteur ainsi que toutes les autres parties (mécaniques comme électriques) de la voiture. Si elle est en bon état, elle fonctionne.
• En méthode « boîte grise », on emmène la voiture chez le garagiste, et en tournant la clé dans la serrure, on vérifie que le moteur s’allume, et le garagiste observe en même temps le moteur pour s’assurer qu’il démarre bien selon le bon processus.

Vous souhaitez faire appel à nos équipes ? Contactez-nous !