Boîte noire contre boîte blanche
Selon vous, quel type de test devrait être prioritaire (pour les testeurs/QA), et pourquoi?
Un ensemble rapide de définitions de wikipedia:
Test boîte noire
- prend une perspective externe de l'objet de test pour dériver des cas de test. Ces tests peuvent être fonctionnels ou non fonctionnels, bien que généralement fonctionnels. Le concepteur de test sélectionne les entrées valides et non valides et détermine la sortie correcte. Il n'y a aucune connaissance de la structure interne de l'objet à tester.
Test de la boîte blanche
- utilise une perspective interne du système pour concevoir des cas de test basés sur la structure interne. Des compétences en programmation sont nécessaires pour identifier tous les chemins à travers le logiciel. Le testeur choisit les entrées de scénario de test pour s’exercer dans le code et détermine les sorties appropriées. Dans les tests de matériel électrique, chaque nœud d’un circuit peut être sondé et mesuré; un exemple est le test en circuit (ICT).
edit: juste pour clarifier un peu plus, je me rends compte que les deux sont importants, mais ils sont généralement séparés entre dev et QA.
Les connaissances internes sont-elles importantes pour le testeur/l'assurance qualité? J'ai entendu des arguments selon lesquels tester en ayant connaissance de ces connaissances leur permettait de mieux détecter les problèmes, mais également que ces connaissances pouvaient détourner l'attention des besoins fonctionnels et favoriser l'utilisation de "tests conformes au code" plutôt qu'à la solution souhaitée .
- Le test de la boîte noire devrait être l’accent mis sur les testeurs/AQ.
- Le test de la boîte blanche doit être l’accent mis sur les développeurs (c’est-à-dire les tests unitaires).
- Les autres personnes ayant répondu à cette question semblaient avoir interprété la question comme Ce qui est plus important, le test de la boîte blanche ou le test de la boîte noire. Moi aussi, je pense que les deux sont importants, mais vous voudrez peut-être consulter cet article Article IEEE qui affirme que le test de la boîte blanche est plus important.
Le test de la boîte blanche équivaut au test unitaire du logiciel. Le développeur ou un testeur de niveau de développement (par exemple un autre développeur) s'assure que le code qu'il a écrit fonctionne correctement conformément aux exigences de niveau détaillé avant de l'intégrer au système.
Les tests Black Box sont équivalents aux tests d'intégration. Le testeur s'assure que le système fonctionne conformément aux exigences sur le plan fonctionnel.
Les deux approches de test sont d'égale importance à mon avis.
Un test unitaire approfondi détectera les défauts lors de la phase de développement et non après l'intégration du logiciel dans le système. Un test de la boîte noire au niveau du système garantira que tous les modules logiciels se comportent correctement lorsqu'ils sont intégrés ensemble. Un test unitaire en phase de développement ne corrigera pas ces défauts car les modules sont développés indépendamment les uns des autres.
Boîte noire
1 Se concentre sur les fonctionnalités du système Se concentre sur la structure (programme) du système
2 Les techniques utilisées sont:
· Partitionnement d'équivalence
· Analyse de la valeur limite
· Erreur de deviner
· Conditions de course
· Représentation graphique cause à effet
· Test de syntaxe
· Test de transition d'état
· Matrice graphique
Testeur peut être non technique
Aide à identifier le flou et la contradiction dans les spécifications fonctionnelles
Boîte blanche
Les techniques utilisées sont:
· Test de base
· Notation graphique de flux
· Test de la structure de contrôle
Test de condition
Test de flux de données
· Test de boucle
Boucles simples
Boucles imbriquées
Boucles concaténées
Boucles non structurées
Testeur devrait être technique
Aide à identifier les problèmes de logique et de codage.
L’AQ devrait se concentrer sur test de la boîte noire. Le principal objectif de l’assurance qualité est de tester ce que le système fait (les fonctionnalités répondent-elles aux exigences?), Et non comment il le fait.
Quoi qu'il en soit, il devrait être difficile pour l'AQ de faire des tests dans les boîtes blanches, car la plupart des responsables de l'AQ ne sont pas des techniciens, alors ils testent généralement les fonctionnalités via l'interface utilisateur (comme les utilisateurs).
Un pas de plus, je pense que développeurs devrait également se concentrer sur test de la boîte noire. Je ne suis pas d'accord avec cette association répandue entre les tests unitaires et les tests de la boîte blanche, mais il peut s'agir simplement d'un vocabulaire/d'une échelle. À l'échelle d'un test unitaire, le System Under Test est une classe/méthode qui a un contrat (par sa signature) et le point important est de tester ce qu'il fait, et non pas comment .. ... implique que vous savez comment la méthode remplira son contrat, ce qui me semble incompatible avec TDD.
À mon humble avis, si votre SUT est si complexe que vous devez effectuer des tests de boîte blanche, il est généralement temps de procéder à une refactorisation.
"Les deux" a été indiqué ci-dessus, et constitue la réponse évidente ... mais les tests de la boîte blanche IMO vont bien au-delà des tests unitaires pour développeurs (bien que je suppose que cela dépend du point où vous tracez la ligne entre noir et blanc). Par exemple, l’analyse de la couverture de code est une approche commune basée sur une boîte blanche - c’est-à-dire exécuter des scénarios ou des tests et examiner les résultats en recherchant des trous dans les tests. Même si les tests unitaires ont 100% cc, mesurer cc sur des scénarios utilisateur courants peut révéler un code pouvant éventuellement nécessiter encore plus de tests.
L’examen des types de données, des constantes et d’autres informations permettant de rechercher des limites, des valeurs spéciales, etc. est également utile. Par exemple, si une application a une entrée prenant une entrée numérique, une approche uniquement bb pourrait obliger le testeur à: "devinez" à quelles valeurs seraient bonnes pour le test, alors qu'une approche wb peut révéler que toutes les valeurs comprises entre 1 et 256 sont traitées d'une manière, alors que les valeurs plus grandes sont traitées d'une autre manière ... et peut-être que le nombre 42 a encore un autre chemin de code .
Donc, pour répondre à la question initiale, bb et wb sont indispensables à un bon test.
D'après mon expérience, la plupart des développeurs migrent naturellement vers les tests de boîte blanche. Puisque nous devons nous assurer que l'algorithme sous-jacent est "correct", nous avons tendance à nous concentrer davantage sur les internes. Mais, comme il a été souligné, le test des boîtes blanches et des boîtes noires est important.
Par conséquent, je préfère que les testeurs se concentrent davantage sur les tests de la Black Box, afin de couvrir le fait que la plupart des développeurs ne le font pas vraiment et qu'ils ne sont souvent pas très bons à cet égard.
Cela ne veut pas dire que les testeurs ne doivent pas connaître le fonctionnement du système, mais simplement que je préfère qu'ils se concentrent davantage sur le domaine problématique et sur la manière dont les utilisateurs interagissent avec le système, et non pas sur la fonction SomeMethod (int x). lancera correctement une exception si x est égal à 5.
C'est un peu une porte ouverte, mais au final, les deux sont à peu près d'égale importance.
Ce qui est pire?
logiciel qui fait ce qu'il doit faire, mais a des problèmes internes?
logiciel qui est censé fonctionner si vous regardez les sources, mais n'est-ce pas?
Ma réponse: Ni est totalement acceptable, mais il ne peut pas être prouvé qu'un logiciel est 100% sans bug. Donc, vous allez devoir faire des compromis. La deuxième option est plus directement visible pour les clients, vous allez donc avoir des problèmes avec cela plus tôt. À long terme, la première option posera problème.
En règle générale, les tests en boîte blanche ne sont pas possibles pour les testeurs. La seule solution viable pour les testeurs est donc de mettre l’accent sur l’approche boîte noire.
Cependant, avec les méthodes de programmation par programme et de conception par contrat, lorsque les objectifs de test sont programmés dans le code cible sous forme de contrats (vus de la vue statique d'un programme) et/ou lorsque la logique temporelle de test est programmée dans le code étant un recoupement (vue dynamique de la logique de test), le test en boîte blanche deviendrait non seulement possible, mais constituerait également un choix privilégié pour les testeurs. Cela dit, les testeurs doivent être non seulement de bons testeurs, mais également de bons programmeurs ou plus que de bons programmeurs.
Test de la boîte noire: Le test de la boîte noire est simplement une observation, pas besoin de connaissances internes ni de la structure du produit logiciel. il suffit de mettre des données valides et invalides et d’attendre le résultat correct. Ici, le testeur trouve le défaut mais est incapable de trouver l'emplacement du test de la boîte defect.black dans tous les niveaux de test.
Les techniques de test de la boîte noire sont les suivantes: 1. Partition d'équivalence 2. Analyse de la valeur limite 3. Table de décision 4. Diagramme de transition d'état 4. Diagramme de cas d'utilisation
Test de la boîte blanche: La boîte blanche est en train de tester si elle nécessite la connaissance de la logique interne et de la structure du produit logiciel. Ici, nous allons vérifier la boucle, la condition et la branche. Ici, nous trouvons non seulement le défaut, mais également son emplacement.
Techniques de test de la boîte blanche: 1. Couverture de relevé 2. Couverture de la décision 3. Couverture de branche 4. Couverture de chemin.
Black Box Testing est une méthode de test logiciel dans laquelle la structure interne/conception/implémentation de l'élément testé n'est PAS connue du testeur . White Box Testing est une méthode de test logiciel dans laquelle la structure l'élément testé est connu du testeur.
Voici mes 5 cents:
En tant que développeur, j'écris principalement des tests de méthodes (dans une classe) sous la forme de tests de type boîte blanche, simple parce que je ne veux pas que mon test soit interrompu simplement parce que je modifie le fonctionnement interne de mon code.
Je souhaite que mes tests ne fonctionnent que si le comportement de ma méthode change (par exemple, renvoie un résultat différent de celui utilisé auparavant).
Au cours des 20 dernières années de développement, je me suis simplement fatigué de faire du double-travail simplement parce que mes tests unitaires étaient fortement liés au code et que je devais maintenir à la fois le code de l'application et le code du test.
Je pense que faire du code de découplage (également lorsque vous codez des tests) est une très bonne pratique.
Encore 5 centimes: je n'utilise presque jamais de frameworks moqueurs, parce que quand je le trouve nécessairement pour me moquer de quelque chose, je préfère découpler mon code - et oui dans de nombreux cas, c'est très possible (surtout si vous ne travaillez pas avec du code hérité): - )
Qu'est-ce qui constitue "la connaissance interne"? Savoir si tel ou tel algorithme a été utilisé pour résoudre un problème est-il admissible ou le testeur doit-il voir chaque ligne de code pour qu'il soit "interne"?
Je pense que dans tous les cas de test, il devrait y avoir des résultats attendus donnés par la spécification utilisée et non pas par la façon dont le testeur décide d'interpréter la spécification car cela peut entraîner des problèmes où chacun pense avoir raison et blâmer l'autre pour le problème.
- * Test de la boîte noire: Le test au niveau du système permet de vérifier la fonctionnalité du système, afin de garantir que le système exécute toutes les fonctions pour lesquelles il a été conçu, principalement pour détecter les défauts détectés au niveau de l'utilisateur. Il est préférable de faire appel à un testeur professionnel pour surveiller votre système », car le développeur teste généralement que les codes qu'il a écrits sont bons et répondent aux exigences fonctionnelles des clients, de sorte qu'il puisse rater beaucoup de choses (je ne veut offenser personne)
- Whitebox est le premier test réalisé dans le SDLC. Il consiste à détecter les bogues tels que les erreurs d’exécution et les erreurs de compilation. Il peut être effectué soit par les testeurs, soit par le développeur lui-même. Il les comprend plus qu'une autre personne. *
* Test Black-Box: Si le code source n'est pas disponible, les données de test sont basées sur la fonction du logiciel, sans tenir compte de la façon dont il a été mis en œuvre. - fort textExemples de test de boîte noire: test de valeur limite et partitionnement d'équivalence.
* Test de la boîte blanche: Si le code source du système testé est disponible, les données de test sont basées sur la structure de ce code source .- Des exemples de tests de la boîte blanche sont les suivants: test de chemin et données test d'écoulement.
Je ne suis que partiellement d'accord avec la réponse la mieux notée pour cette question .. __ Quel type de test, selon vous, devrait être prioritaire (pour les testeurs/QA), et pourquoi?
- Je conviens que: "Le test de la boîte noire devrait être l’emphase pour Testeurs/QA."
- Je conviens que les tests de la boîte blanche devraient être l’accent mis sur les développeurs , Mais je ne suis pas d’accord pour dire que les tests de la boîte blanche sont simplement des tests unitaires.
Je suis d'accord avec la définition ici qui indique que la méthode de test de la boîte blanche est applicable aux niveaux suivants de test de logiciel:
- Unit Testing: Pour tester des chemins dans une unité
- Tests d'intégration: pour tester les chemins entre les unités
- Test du système: pour tester les chemins entre sous-systèmes
Simple ... Le test Blackbox est également appelé test d'intégration ou test d'écran de fumée. Ceci est principalement appliqué dans un environnement distribué qui repose sur une architecture pilotée par les événements. Vous testez un service basé sur un autre service pour voir tous les scénarios possibles. Ici, vous ne pouvez pas prévoir complètement toutes les sorties possibles, car chaque composant de l'application SOA/Enterprise doit fonctionner de manière autonome. Ceci peut être appelé test de haut niveau
tandis que
Le test de la boîte blanche fait référence au test unitaire. où tous les scénarios et les résultats attendus peuvent être efficacement prévus. C'est-à-dire les tests de bas niveau.