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?

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.

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.

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.

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.

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.

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.