Test de boîte noire ou de boîte blanche - que faites-vous en premier?
14
Dans une très petite équipe, où les tests de boîte noire et de boîte blanche sont effectués par la même personne, que doit faire le testeur en premier?
Je pense que cela dépend du contexte. Avez-vous fini de mettre en œuvre les spécifications principalement et souhaitez-vous commencer vos tests finaux ou parlez-vous généralement à tout moment pendant le cycle de développement? Comme certains le mentionnent dans les réponses, vos implémenteurs écrivent généralement des tests unitaires qui peuvent être considérés comme faisant partie de vos tests de boîte blanche car ces codeurs comprennent le fonctionnement interne et souhaitent affirmer la fonctionnalité de leur implémentation avant de s'engager.
Chris
Réponses:
11
Tout ce qui doit être le plus correct.
Sérieusement, les tests en boîte blanche (c'est-à-dire tester les composants internes du code) devraient idéalement être effectués avec des tests unitaires par le développeur qui a écrit le code. Les tests unitaires seraient construits au fil du temps et font partie du processus de génération afin que nous ne perdions pas le temps du pauvre testeur avec du code que nous savons ne fonctionne pas comme il se doit. Les tests unitaires deviennent plus importants plus votre équipe est petite - en particulier parce que vous n'avez pas une armée de testeurs pour éliminer les problèmes.
Les tests en boîte noire (c'est-à-dire les tests via l'interface utilisateur / système) sont généralement ce que font la plupart des testeurs.
Tous les tests doivent être hiérarchisés en fonction de l'importance d'une fonction pour le produit fini. Si la mission est de fournir un outil pour faire X et que le produit ne fait pas X, c'est un gros problème.
Bien dit, meilleure réponse que j'ai lue jusqu'à présent.
Chris
5
Noir
Test en boîte noire pour vérifier les fonctionnalités. Test en boîte blanche si nécessaire en cas de bris. Si tous les tests de boîte noire réussissent et que la couverture est bonne, le test de boîte blanche n'est pas nécessaire.
À moins, bien sûr, que les tests de la boîte noire aient manqué de tester un élément clé de la fonctionnalité ou de la configuration:}
Alan
3
@Alan: le même argument s'applique aux tests en boîte blanche, d'où la mise en garde «la couverture est bonne»
Steven A. Lowe
1
D'accord - je suppose que ma déclaration dépend de votre définition d'une bonne couverture.
Alan
1
@DocBrown Je ne vois absolument pas comment ce que vous avez expliqué ressemble à distance à un test de boîte blanche. Le test de la Whitebox consiste à suivre les chemins de branchement d'une implémentation donnée et à écrire des cas de test qui exerceront tous les chemins. Si vous n'avez pas encore d'implémentation, vous ne pouvez pas, par définition, faire des tests de boîte blanche. Avec TDD et BDD, vous écrivez des tests de la forme générale donnée quand. Vous configurez les données d'entrée ou l'état préconditionnel, déclenchez l'unité et effectuez des vérifications sur les données de sortie ou l'état final ou les appels de tiers. Ceci est la définition des tests de blackbox.
Sammi
1
@SamJudge: à ma connaissance, lorsque vous regardez à l'intérieur du code d'implémentation et utilisez ces informations pour concevoir des données de test très spécifiques (qui sont ensuite transmises via l'interface publique), il était alors justifié d'appeler ce test de boîte blanche. Un tel test échoue également si le résultat n'est pas celui auquel on s'attend. Si vous regardez plus tard le test, vous ne pourrez peut-être pas dire clairement "ce test a été produit par une approche en boîte blanche (ou boîte noire)", bien sûr.
Doc Brown
3
Boîte noire.
Les composants de la boîte blanche dépendent généralement des composants de la boîte noire, donc je voudrais d'abord tester la boîte noire, puis passer à la boîte blanche.
Je ne suis pas sûr de ce que vous entendez par "composants de boîte noire" et "composants de boîte blanche" - pour moi ce ne sont que des "composants" (qui peuvent être testés avec ou sans connaissance du code ou de l'architecture sous-jacents.
Alan
Je ne comprends pas la relation "dépendante" que vous proposez ici. La boîte blanche noire et noire ne sont pas des composants, plus un style de test de n'importe quel composant comme Alan le mentionne. La différence réside dans l'approche adoptée pour tester le composant en question.
Chris
2
Vous effectuez d'abord des tests blancs en tant que codeur / développeur pour vous assurer que les choses fonctionnent bien. Ensuite, vous effectuez des tests de boîte noire en essayant généralement de penser comme si vous étiez l'utilisateur final, sans penser à la structure interne du programme. Parfois, vous devez penser comme un codeur / développeur même si vous effectuez un test noir, car vous testez peut-être un module interne écrit par une autre personne et vous n'avez pas accès au code.
Si vous voulez avoir un bon cycle de test, vous devriez avoir différentes personnes qui font les deux :
Un développeur axé principalement sur les tests en boîte blanche sait ce qui a changé récemment dans le code, quels domaines sont plus complexes (et donc susceptibles de casser), etc. et peut concentrer les efforts de manière appropriée dans ces domaines les plus susceptibles d'introduire de nouveaux défauts.
D'un autre côté, un testeur d'assurance qualité axé sur les tests en boîte noire peut plus facilement aborder les tests comme un utilisateur final. Sans aucune connaissance interne du code, ils peuvent adopter une nouvelle approche et ne sont pas biaisés par la connaissance de la façon dont les différentes parties de la solution sont implémentées. Ils intercepteront les bogues que le développeur aurait pu ignorer ou les régressions des modifications de code qui ont accidentellement cassé d'autres zones de l'application.
Pour répondre à votre question, le test en boîte blanche doit être effectué en premier. Mais vous devez vraiment avoir une personne différente pour faire le test de la boîte noire si vous voulez que ce soit efficace.
J'aime commencer par les tests de boîte noire, puis utiliser les informations de couverture de code ou le débogueur pour comprendre ce que je fais et analyser ce qui se passe.
Mais la vraie réponse est que cela dépend . Je suis susceptible de plonger dans le code plus tôt (ou même en premier) si je fais des tests d'API, mais beaucoup plus tard si mon objectif est d'examiner des scénarios de bout en bout.
Je dirais que le test de la Black Box est d' abord, simplement parce qu'en tant que promoteur du TDD, les tests sont écrits avant que le code (ou la boîte) n'existe de toute façon :)
Les tests de la White Box (pour autant que je comprends) sont plus utiles dans un état d'esprit de débogage.
-1, TDD est un test en boîte blanche. Dans TDD, il est essentiel de savoir ce que le code impliqué dans le test fait (et ce qu'il ne fait pas) pour écrire le prochain test. Boîte noire test que quelqu'un moyen qui n'a aucune idée du code (un testeur, quelqu'un qui ne doit même pas savoir comment le code), conçoit les tests.
Doc Brown
1
Ensuite, nous ne pratiquons pas le TDD de la même manière. Pour moi, TDD consiste à appliquer les spécifications d'une classe / fonction: les tests sont écrits pour vérifier que la classe / fonction se comporte comme spécifié, mais peu importe comment le code se comporte en arrière-plan tant que ces spécifications sont respectées ... ce qui est nécessaire étant donné que les tests sont écrits avant la fonctionnalité.
Matthieu M.
1
Test de la boîte noire, car vous écrivez des tests avant que le code n'existe. Le testeur doit développer des tests automatiques chronophages en parallèle avec le code d'écriture du développeur pour être efficace dans une petite équipe.
Si le code est déjà écrit, je vous suggère de passer un peu de temps à esquisser la couverture du test d'un point de vue boîte noire pour vous assurer d'obtenir un certain temps de remue-méninges avant d'encombrer votre cerveau avec le code réel. Cependant, vous pouvez ensuite passer à la boîte blanche et consulter le code avant d'aller trop loin avec les tests réels pour avoir une idée des zones à risque et prioriser les tests que vous avez réfléchis plus tôt (et les compléter avec de nouveaux tests pensés par regarder des parties du code qui semblent compliquées ou discutables).
Ni. J'essaie d'écrire de bons tests en utilisant mon BICEP droit , en gardant à l'esprit les conditions limites CORRECTES , quel que soit l'ordre dans lequel elles me viennent à l'esprit. Ce sont les deux acronymes proposés dans Pragmatic Unit Testing .
Mon objectif est de me concentrer sur la rédaction de bons tests, et non sur la couleur à écrire en premier.
«Blanc» et «noir» ne sont pas des termes de test unitaire, alors bien sûr, vous ne vous en faites pas. Les tests unitaires sont de facto une boîte blanche.
Ethel Evans
@Ethel Evans: Ce ne sont pas des tests en boîte blanche par définition. La grande majorité des tests unitaires sont des tests en boîte blanche, mais ce n'est pas une exigence. Tout test qui mappe le domaine des entrées à la plage de sorties d'une fonction est un test unitaire, mais n'a pas besoin de connaître les détails de l'implémentation.
Steven Evers
0
Faites d'abord des tests en boîte blanche .
Deuxième rendez-vous pour les tests de la boîte noire.
> Test de la boîte noire
I. Le testeur doit vérifier le fonctionnement de l'application, telle que la zone de texte, le bouton radio, la zone de liste, le bouton de commande, ... etc.,
II. Le testeur doit vérifier le non fonctionnement de l'application, tels que logo, image, orthographe, etc., etc.
III. Le testeur doit vérifier l'intégralité du flux de l'application.
Remarque: pour vérifier les conditions positives et négatives.
Réponses:
Tout ce qui doit être le plus correct.
Sérieusement, les tests en boîte blanche (c'est-à-dire tester les composants internes du code) devraient idéalement être effectués avec des tests unitaires par le développeur qui a écrit le code. Les tests unitaires seraient construits au fil du temps et font partie du processus de génération afin que nous ne perdions pas le temps du pauvre testeur avec du code que nous savons ne fonctionne pas comme il se doit. Les tests unitaires deviennent plus importants plus votre équipe est petite - en particulier parce que vous n'avez pas une armée de testeurs pour éliminer les problèmes.
Les tests en boîte noire (c'est-à-dire les tests via l'interface utilisateur / système) sont généralement ce que font la plupart des testeurs.
Tous les tests doivent être hiérarchisés en fonction de l'importance d'une fonction pour le produit fini. Si la mission est de fournir un outil pour faire X et que le produit ne fait pas X, c'est un gros problème.
la source
Noir
Test en boîte noire pour vérifier les fonctionnalités. Test en boîte blanche si nécessaire en cas de bris. Si tous les tests de boîte noire réussissent et que la couverture est bonne, le test de boîte blanche n'est pas nécessaire.
la source
Boîte noire.
Les composants de la boîte blanche dépendent généralement des composants de la boîte noire, donc je voudrais d'abord tester la boîte noire, puis passer à la boîte blanche.
la source
Vous effectuez d'abord des tests blancs en tant que codeur / développeur pour vous assurer que les choses fonctionnent bien. Ensuite, vous effectuez des tests de boîte noire en essayant généralement de penser comme si vous étiez l'utilisateur final, sans penser à la structure interne du programme. Parfois, vous devez penser comme un codeur / développeur même si vous effectuez un test noir, car vous testez peut-être un module interne écrit par une autre personne et vous n'avez pas accès au code.
la source
Si vous voulez avoir un bon cycle de test, vous devriez avoir différentes personnes qui font les deux :
Un développeur axé principalement sur les tests en boîte blanche sait ce qui a changé récemment dans le code, quels domaines sont plus complexes (et donc susceptibles de casser), etc. et peut concentrer les efforts de manière appropriée dans ces domaines les plus susceptibles d'introduire de nouveaux défauts.
D'un autre côté, un testeur d'assurance qualité axé sur les tests en boîte noire peut plus facilement aborder les tests comme un utilisateur final. Sans aucune connaissance interne du code, ils peuvent adopter une nouvelle approche et ne sont pas biaisés par la connaissance de la façon dont les différentes parties de la solution sont implémentées. Ils intercepteront les bogues que le développeur aurait pu ignorer ou les régressions des modifications de code qui ont accidentellement cassé d'autres zones de l'application.
Pour répondre à votre question, le test en boîte blanche doit être effectué en premier. Mais vous devez vraiment avoir une personne différente pour faire le test de la boîte noire si vous voulez que ce soit efficace.
la source
J'aime commencer par les tests de boîte noire, puis utiliser les informations de couverture de code ou le débogueur pour comprendre ce que je fais et analyser ce qui se passe.
Mais la vraie réponse est que cela dépend . Je suis susceptible de plonger dans le code plus tôt (ou même en premier) si je fais des tests d'API, mais beaucoup plus tard si mon objectif est d'examiner des scénarios de bout en bout.
la source
Je dirais que le test de la Black Box est d' abord, simplement parce qu'en tant que promoteur du TDD, les tests sont écrits avant que le code (ou la boîte) n'existe de toute façon :)
Les tests de la White Box (pour autant que je comprends) sont plus utiles dans un état d'esprit de débogage.
la source
Test de la boîte noire, car vous écrivez des tests avant que le code n'existe. Le testeur doit développer des tests automatiques chronophages en parallèle avec le code d'écriture du développeur pour être efficace dans une petite équipe.
Si le code est déjà écrit, je vous suggère de passer un peu de temps à esquisser la couverture du test d'un point de vue boîte noire pour vous assurer d'obtenir un certain temps de remue-méninges avant d'encombrer votre cerveau avec le code réel. Cependant, vous pouvez ensuite passer à la boîte blanche et consulter le code avant d'aller trop loin avec les tests réels pour avoir une idée des zones à risque et prioriser les tests que vous avez réfléchis plus tôt (et les compléter avec de nouveaux tests pensés par regarder des parties du code qui semblent compliquées ou discutables).
la source
Ni. J'essaie d'écrire de bons tests en utilisant mon BICEP droit , en gardant à l'esprit les conditions limites CORRECTES , quel que soit l'ordre dans lequel elles me viennent à l'esprit. Ce sont les deux acronymes proposés dans Pragmatic Unit Testing .
Mon objectif est de me concentrer sur la rédaction de bons tests, et non sur la couleur à écrire en premier.
la source
Faites d'abord des tests en boîte blanche .
Deuxième rendez-vous pour les tests de la boîte noire.
> Test de la boîte noire
I. Le testeur doit vérifier le fonctionnement de l'application, telle que la zone de texte, le bouton radio, la zone de liste, le bouton de commande, ... etc.,
II. Le testeur doit vérifier le non fonctionnement de l'application, tels que logo, image, orthographe, etc., etc.
III. Le testeur doit vérifier l'intégralité du flux de l'application.
Remarque: pour vérifier les conditions positives et négatives.
la source