Boîte noire vs Tests en boîte Blanche
Le type de test que vous dites doit être l'accent (pour les testeurs/Sqr), et pourquoi?
Une rapide série de définitions de wikipedia:
Boîte noire
- prend un point de vue externe de l'objet de test à tirer des cas de test. Ces tests peuvent être fonctionnelles ou non fonctionnelles, bien que généralement fonctionnelles. Le test concepteur sélectionne d'entrée valides et invalides et détermine le bon de sortie. Il n'y a pas de connaissance de l'objet d'essai de la structure interne.
Tests en boîte blanche
- utilise un point de vue interne du système de conception de cas de test basée sur la structure interne. Il nécessite des compétences en programmation pour identifier tous les chemins à travers le logiciel. Le testeur choisit de cas de test des entrées à l'exercice des chemins à travers le code et détermine les produits adaptés. Dans les essais de matériel électrique, chaque nœud d'un circuit peut être sondé et mesurés; un exemple est dans le circuit de test (TIC).
edit: juste pour préciser un peu plus, je me rends compte que les deux sont importants, mais ils sont généralement séparés entre développement et d'assurance qualité.
Est à l'intérieur de connaissances importantes pour la tester/QA? J'ai entendu des arguments que les essais avec cette connaissance à l'esprit leur permet de mieux tester les problèmes, mais j'ai aussi entendu des arguments que cette connaissance peut détourner l'attention de besoins fonctionnels et de promouvoir le "test pour le code" plutôt que à la destinée de la solution.
- J'ai trouvé la question et des réponses très utiles et ont volé à répondre à ma propre question stackoverflow.com/questions/402161/...
Vous devez vous connecter pour publier un commentaire.
Tests en Boîte blanche est égale à l'Unité de Logiciel de Test. Le développeur ou testeur de niveau de développement (par exemple, un autre développeur) garantit que le code qu'il a écrit est de fonctionner correctement selon le niveau de détail des exigences avant de l'intégrer dans le système.
Boîte noire est égal à des Tests d'Intégration. Le testeur s'assure que le système fonctionne selon les exigences sur le plan fonctionnel.
Test les deux approches sont tout aussi important à mon avis.
Approfondie de l'unité de test de capture des défauts dans la phase de développement, et non pas après que le logiciel a été intégré dans le système. Un système de niveau de la boîte noire test s'assurera que tous les modules du logiciel se comporter correctement lorsqu'ils sont intégrés ensemble. Un test unitaire dans la phase de développement ne serait pas attraper ces défauts étant donné que les modules sont généralement développés indépendamment les uns des autres.
Boîte Noire
1
Met l'accent sur la fonctionnalité du système
Se concentre sur la structure (Programme) du système
2
Les Techniques utilisées sont :
· Équivalence de partitionnement
· Limites-l'analyse de la valeur
· Erreur de deviner
· Conditions de course
· De Cause à effet graphique
· Syntaxe des tests
· De l'état de transition de test
· Graphe de la matrice
Testeur peut être non technique
Aide à identifier le flou et les contradictions dans les spécifications fonctionnelles
Boîte Blanche
Techniques utilisées sont:
· Base Chemin De Tests
· Graphe De Flot De Notation
· Contrôle De La Structure De Test
Condition De Test
De Flux de données de test
· Tests De Boucle
Simples Boucles
Boucles Imbriquées
Concaténées Boucles
Non Structurées Boucles
Testeur doit être technique
Aide à identifier les logiques et les problèmes de codage.
AQ devrait se concentrer sur boîte Noire. L'objectif principal de l'assurance qualité est de tester ce que le système ne (ne les caractéristiques répondent aux exigences ?), pas comment il le fait.
De toute façon il devrait être difficile pour le contrôle de qualité pour faire des tests en boîte blanche comme la plupart de QA mecs ne sont pas tech les gars, ils ont généralement des fonctions de test par le biais de l'INTERFACE utilisateur (comme les utilisateurs).
Un pas de plus, je pense que développeurs trop devrait se concentrer sur boîte Noire. Je suis en désaccord avec cette vague de l'association entre les tests Unitaires et les tests en boîte Blanche, mais il peut être juste une question de vocabulaire/échelle. À l'échelle d'une Unité de test, le Système Sous Test est une classe/méthode qui a contrat (par le biais de sa signature) et le point le plus important est de tester ce qu'il fait, pas comment.
En outre tests en boîte Blanche suppose que vous savez comment la méthode remplit son contrat, qui semble incompatile TDD pour moi.
À mon humble avis, si votre CIBLE est tellement complexe que vous avez besoin de faire les tests en boîte blanche, il est généralement le temps pour le refactoring.
"Les deux" il a été indiqué ci-dessus, et est la réponse la plus évidente...mais l'OMI, tests en boîte blanche va bien au-delà de développeur de tests unitaires (althoughI suppose que cela pourrait dépendre de l'endroit où tracer la ligne de démarcation entre le blanc et le noir). Par exemple, l'analyse de couverture de code est une commune de la zone blanche de l'approche - c'est à dire exécuter certains scénarios ou des tests, et d'examiner les résultats de la recherche pour les trous dans les tests. Même si les tests unitaires ont 100% de cc, la mesure de la cc sur la commune de scénarios utilisateur peut révéler code peut potentiellement besoin d'encore plus de tests.
Un autre endroit où les tests en boîte blanche aide est de l'examen des données types, constantes et d'autres informations à chercher les limites, les valeurs spéciales, etc. Par exemple, si une application a une entrée qui prend une entrée numérique, un bb à la seule approche pourrait exiger que le testeur de "deviner" ce que des valeurs serait bon pour le test, alors que la banque mondiale, l'approche peut révéler que toutes les valeurs entre 1-256 sont traités d'une seule façon, tandis que les plus grandes valeurs sont traitées d'une autre manière...et peut-être le nombre 42 est encore un autre chemin d'accès du code.
Donc, pour répondre à la question d'origine - deux bb et bm sont essentiels pour de bons tests.
Dans mon expérience, la plupart des développeurs naturellement migrer vers des tests en boîte blanche. Puisque nous devons nous assurer que l'algorithme sous-jacent est "correct", nous avons tendance à se concentrer davantage sur le fonctionnement interne. Mais, comme cela a été souligné, à la fois blanc et noir zone de test est important.
Donc, je préfère avoir des testeurs de se concentrer davantage sur les tests de type Boîte Noire, pour couvrir le fait que la plupart des développeurs n'est pas vraiment le faire, et souvent ne sont pas très bon à cela.
Qui n'est pas à dire que les testeurs devraient être maintenus dans l'obscurité sur la façon dont le système fonctionne, c'est juste que je préfère se concentrer plus sur le domaine du problème et de la façon dont les utilisateurs interagissent avec le système, pas de savoir si la fonction SomeMethod(int x) correctement lever une exception si x est égal à 5.
C'est un peu une porte ouverte, mais à la fin, les deux sont tout aussi importants.
Ce qui est pire?
logiciel qui fait ce qu'il doit faire, mais en interne, a des problèmes?
logiciel qui est censé travailler, si vous regardez les sources, mais ne l'est pas?
Ma réponse:
Il n'est ni tout à fait acceptable, mais le logiciel ne peut pas être prouvée à 100% sans bugs. Donc, vous allez avoir à faire des compromis. Option deux est le plus directement perceptible pour les clients, de sorte que vous allez avoir des problèmes plus tôt. Sur le long terme, l'option va être problématique.
Boîte noire: Boîte Noire est juste de l'observation pas besoin de Connaissances Interne et de la structure du produit logiciel. il suffit de le mettre valides et non valides et les données d'entrée et attend le résultat correct. ici testeur de trouver le défaut, mais impossible de Trouver l'Emplacement du défaut.boîte noire de tests ont été effectués dans tous les tests de niveau.
Boîte noire de tests techniques sont les suivantes:
1. Equivalance partition
2. Limite De L'Analyse De La Valeur
3. Le tableau de décision
4. Diagramme De Transition D'État
4. Diagramme de cas d'utilisation
Tests en Boîte blanche: boîte Blanche est de le tester 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 de la direction générale. ici, nous trouvons non seulement le défaut, mais aussi et localisation de défaut.
Tests en boîte blanche Techniques:
1. Déclaration De La Couverture
2. La Décision De La Couverture
3. Direction Générale De La Couverture
4. Chemin De Couverture.
Généralement le blanc-boîte de test n'est pas possible pour les testeurs. Donc la seule réponse viable pour les testeurs, c'est pour souligner la boîte noire de l'approche.
Cependant, avec aspect-oriented-la programmation et de la conception par contrat méthodologie, lorsque les objectifs des tests sont programmés dans le code cible que les contrats (vu à partir de la vue statique d'un programme), et/ou lorsque les tests de logique temporelle est programmée dans le code de la croix-coupes (point de vue dynamique de la logique du test), blanche-boîte de tests serait devenu non seulement possible, mais également une préféré prendre pour les testeurs. Étant donné que dit, il aura besoin d'être une expertise exigeants en prendre, les testeurs doivent non seulement être de bons testeurs, mais aussi les bons programmeurs ou plus de bons programmeurs.
Boîte noire est un logiciel de méthode de test dans lequel la structure interne/conception/mise en œuvre de l'élément testé est PAS connu pour le testeur.
Tests en Boîte blanche est un logiciel de méthode de test dans lequel la structure interne/conception/mise en œuvre de l'élément testé est connu pour le testeur.
Ce qui constitue, "interne de la connaissance?" Le fait de savoir que tel-et-tel algorithme a été utilisé pour résoudre un problème de qualifier ou ne le testeur devez voir chaque ligne de code pour qu'il soit interne"?"
Je pense que dans tous les cas de test, il devrait être prévu des résultats donnés par la spécification utilisée et n'est pas déterminée par la façon dont le testeur décide d'interpréter le cahier des charges que cela peut entraîner des problèmes où chacun pense qu'ils sont de droite et de blâmer les autres pour le problème.
Voici mes 5 cents:
En tant que développeur, j'ai surtout écrire des tests pour les méthodes (dans une classe) que les tests boîte blanche, simple parce que je ne veux pas que mon test à rompre tout simplement parce que j'ai changer l'intérieur des œuvres de mon code.
Je ne veux mes essais pour briser si ma méthode changements de comportement (par exemple, renvoie un résultat différent qu'avant).
Au cours de la dernière 20 ans de développement, simple je suis fatigué de le faire à un double travail, juste parce que mes tests unitaires a été fortement lié au code et j'ai besoin de maintenir à la fois le code de l'application et le code de test.
Je pense faire de découplage code (également lorsque vous code tests) est une très bonne pratique.
Un autre de 5 cents: j'ai peine à ne jamais utiliser les moqueries des cadres, parce que quand je le trouve nécessairement à se moquer de quelque chose, je préfère dissocier mon code au lieu - et oui, dans de nombreux cas, c'est très possible (surtout si vous ne travaillez pas dans l'ancien code) 🙂
*Boîte noire test:
Si le code source n'est pas disponible, des données de test est basée sur la fonction du logiciel, sans égard à la façon dont il a été mis en œuvre.
forte de textExamples de boîte noire test sont les suivantes: valeur limite d'essais et d'équivalence de partitionnement.
*Blanc-Boîte de test:
Si le code source du système sous test est disponible, alors les données de test est basé sur la structure de ce code source.
-Exemples de blanche-boîte de test sont les suivantes: chemin de tests et de flux de données de test.
Simple...Blackbox, sinon le test est connu comme test de l'Intégration ou de l'écran de fumée de test . C'est surtout utilisé dans un environnement distribué qui reposent sur un événement driven architecture. Test d'un service sur la base d'un autre service pour voir tous les scénarios possibles. Ici, vous ne pouvez pas complètement toutes les prévisions de sortie possible parce que chaque composant de l'architecture SOA/Enterprise application sont destinés à fonctionner de manière autonome. Cela peut être appelé à Haut Niveau de test
tout
Tests en boîte blanche se réfère à des tests unitaires. où tous les scénarios et de sortie peuvent être effectivement prévu de faire. j'.e l'Entrée et la sortie attendue.Cela peut être considéré comme Faible niveau d'essai
J'ai seulement partiellement d'accord avec le top rated de réponse à cette question.
Le type de test que vous dites doit être l'accent (pour les testeurs/Sqr), et pourquoi?
testeurs d'assurance de la qualité."
les développeurs, mais je n'accepte pas que les tests en Boîte Blanche est juste à l'unité
les tests.
Je suis d'accord avec la définition ici, qui stipule que les Tests en Boîte Blanche méthode est applicable pour les niveaux suivants de tests de logiciels: