Test de la boîte noire : Supposons que vous soyez un fabricant cherchant à introduire une nouvelle bouilloire électrique. Votre équipe produit la développe et la commercialise sans vérifier qu’elle n’est pas défectueuse. Un client le branche et la bouilloire fonctionne mal. Les plaintes s’accumulent. Donc que faies-vous ? Avant de relancer la bouilloire, vous vous assurerez de la «tester».
De la même manière pour leur sécurité les applications web, doivent être testées avant le déploiement pour s’assurer qu’elles sont sans erreur et fonctionnent comme prévu. Les tests en boîte noire et en boîte blanche sont les deux principaux types de tests logiciels qui s’avèrent utiles ici.
Les tests logiciels ne doivent pas être une phase isolée du cycle de vie du développement logiciel. Cela doit être fait à différentes étapes du cycle de développement. La précision et l’exactitude d’une application peuvent être testées dès la conception et le prototypage jusqu’à la phase qui précède le lancement.
Qu’est-ce que le test black box ?
Le test de la boîte noire fait référence à un type de processus de test logiciel qui oblige le testeur à tester une application sans posséder aucune connaissance de la structure interne de l’application. L’application qui est testée peut être considérée comme une boîte noire dans laquelle il est impossible de voir à l’intérieur. Cependant, ils ne sont pas complètement aveugles.
Les testeurs de la boîte noire sont informés du comportement attendu du logiciel. Au lieu de se soucier des technologies qui ont été utilisées pour assembler et développer l’application, le testeur se concentre sur le fait que l’application répond ou non à toutes les exigences répertoriées dans la spécification des exigences logicielles. À l’aide d’une interface utilisateur, ils peuvent vérifier les différentes fonctionnalités de l’application et voir si chacune de ces fonctionnalités remplit sa ou ses fonctions désignées.
Les testeurs sont censés s’assurer que l’application exécute toutes ses fonctions non seulement correctement, mais aussi efficacement. Il peut y avoir certaines exigences non fonctionnelles qui doivent être satisfaites, telles que la sécurité des données ou la facilité d’utilisation de l’interface.
Cela semble assez simple, n’est-ce pas ? Eh bien non ! Le testeur doit savoir comment déterminer soigneusement les cas de test à exécuter en fonction des exigences spécifiées, puis analyser les résultats obtenus.
Le test de la boîte noire est également connu sous le nom de:
- Tests basés sur les spécifications
- Test comportemental
- Tests basés sur les données
- Test d’entrée-sortie
- Test black box
Quel que soit le stade de test auquel vous vous trouvez (test unitaire, test d’acceptation ou autre), vous pouvez effectuer des tests boîte noire à tout moment.
Qu’est-ce que le test de la boîte blanche ?
Les tests en boîte blanche font référence à un type de processus de test logiciel qui oblige le testeur à posséder une connaissance approfondie de la structure de code interne de l’application qu’il teste. Le testeur doit non seulement s’assurer que l’application fonctionne correctement, mais également savoir comment l’application exécute ses fonctions.
Par rapport aux tests de la boîte noire, les tests de la boîte blanche sont effectués à un niveau beaucoup plus bas. Souvent, seuls ceux qui ont travaillé sur le code d’une application particulière sont en mesure de le tester en profondeur. Cela inclut les développeurs et les ingénieurs techniques qui connaissent la structure interne et les technologies utilisées dans le processus de développement. En effet, ils devraient être en mesure de bien comprendre ce qui se passe derrière chaque fonctionnalité ou fonctionnalité présente dans l’application. Les entrées qu’ils choisissent pour effectuer les tests doivent être basées sur leur connaissance de la conception et de la structure internes de l’application.
Les tests en boîte blanche aident à déterminer et à confirmer l’exactitude de chaque chemin emprunté par l’application lorsqu’elle est alimentée par différents types d’entrées.
En raison de la nature transparente du processus de test où le testeur doit être en mesure de voir au-delà du fonctionnement au niveau de la surface de l’application, les tests en boîte blanche sont parfois également appelés tests en boîte transparente, en verre, transparent ou ouvert. D’autres noms incluent :
- Test basé sur le code
- Couverture logique ou tests pilotés par la logique
- Essais structurels ou basés sur la structure
- Test white box
Alors que les tests en boîte blanche sont généralement effectués au niveau le plus bas, c’est-à-dire les tests unitaires, ils peuvent également être appliqués à l’intégration ou aux tests de système.
Quelle est la différence entre les tests black box et white box ?
Une brève comparaison des tests de boîte blanche et de boîte noire peut être établie à l’aide de l’exemple suivant :
Supposons que votre réfrigérateur vous cause des problèmes. Tout ce que vous y stockez devient détrempé à cause de la condensation. Maintenant, vous savez que c’est un comportement inattendu, donc quelque chose ne va vraiment pas.
Pour tester le réfrigérateur, vous essayez d’ajuster la température et d’autres paramètres, mais vous continuez à faire face au même problème: la condensation.
Vous décidez d’appeler une personne de l’entreprise de réfrigération pour qu’elle vienne voir ce qui cause le problème. L’expert que l’entreprise envoie récupère le réfrigérateur, le démonte pour inspection et découvre où était le défaut.
Dans ce cas, vous pourriez dire que vous avez effectué des tests de boîte noire et que le spécialiste a agi en tant que testeur de boîte blanche.
Il existe de nombreuses autres différences entre les tests boîte noire et boîte blanche. Ils sont résumés dans le tableau ci-dessous.
| TEST DE LA BOÎTE NOIRE | TEST DE LA BOÎTE BLANCHE |
| Il ne nécessite pas que le testeur connaisse la structure interne de l’application. | Cela nécessite que le testeur connaisse la structure interne de l’application. |
| Le testeur n’a pas besoin de posséder des compétences en programmation. Ainsi, même un utilisateur final peut l’exécuter. | Le testeur doit posséder des connaissances en programmation. Ainsi, seuls les développeurs ou testeurs ayant des connaissances en codage peuvent l’exécuter. |
| Elle est réalisée du point de vue de l’utilisateur final. | Il est effectué du point de vue du codeur. |
| Il vise à garantir que le logiciel exécute correctement ses fonctions, en produisant des extrants qui correspondent aux résultats attendus. | Il se concentre sur la précision et l’efficacité du code et de sa structure. |
| Les cas de test sont rédigés sur la base de ce qui est spécifié dans le SRS. | Les cas de test sont rédigés sur la base du document de conception détaillée. |
| Ce n’est pas un processus très poussé, il ne prend donc pas beaucoup de temps et peut ne pas produire de rapports très détaillés. | Cela peut prendre beaucoup de temps car il consiste à effectuer des tests exhaustifs et à générer des rapports très détaillés. |
| En raison de la simplicité du processus de test et de la nécessité de s’assurer que l’application est adaptée à un usage humain, il est préférable que ce type de test soit effectué manuellement. | Étant donné que ce processus peut s’avérer très long, en particulier pour les projets plus importants, il peut être nécessaire d’utiliser certains outils de test et d’automatisation. Cependant, il peut également être effectué manuellement. |
| Il est le plus approprié pour des niveaux de test plus élevés, tels que les tests d’acceptation. | Il est le plus approprié pour les niveaux de test inférieurs, tels que les tests unitaires. |
| De nombreux essais et erreurs sont impliqués dans ce type de test, car le testeur n’a aucune idée du fonctionnement interne du logiciel. | Étant donné que la structure interne de l’application est connue du testeur, il peut adopter une stratégie de test qui pourrait (mais ne devrait pas!) Casser l’application. |
En conclusion
Si des applications logicielles sont mises à la disposition des utilisateurs finaux sans avoir été testées correctement, cela peut causer de graves dommages. Cela peut laisser les utilisateurs totalement impuissants et frustrés s’ils rencontrent des erreurs ou des défauts inattendus, ce qui entraîne des critiques négatives pour les développeurs.
Ainsi, les ingénieurs et testeurs d’assurance qualité des logiciels doivent effectuer une diligence raisonnable avant de mettre en œuvre de nouvelles applications. Qu’il s’agisse d’une application Web sur mesure ou d’un projet de développement d’applications mobiles natives ou hybrides , les tests boîte noire et boîte blanche doivent faire partie de la phase de test de chaque application logicielle. Plus la conception et le plan de test sont bons, plus il sera facile d’attraper les bogues au début, meilleures seront les performances de l’application et moins il sera probable qu’elle causera des problèmes aux utilisateurs finaux.
