Black-box vs. White-box-Tests

https://stackoverflow.com/questions/402161

03-07-2019
|

Frage

Die Art der Prüfung würden Sie sagen, sollte der Schwerpunkt (für die testers/QAs), und warum?

Eine schnelle Reihe von Definitionen aus der wikipedia:

Black-box-Tests

eine externe Sicht des Prüflings Testfälle abgeleitet.Diese tests können funktional oder nicht-funktional, obwohl in der Regel funktionsfähig.Der test designer selects valid and invalid input und bestimmt die richtige Ausgabe.Es gibt keine Kenntnisse des Prüflings ist die interne Struktur.

White-box-Tests

verwendet eine interne Perspektive der system design von Testfällen basierend auf der internen Struktur.Es erfordert Programmierkenntnisse, um alle Pfade, die durch die software.Der tester wählt-test-Fall-Eingänge zur Ausübung Pfade durch den code, und bestimmt die entsprechenden Ausgänge.In Elektro-hardware-Prüfung ist jeder Knoten in einer Schaltung kann werden sondiert und bewertet.ein Beispiel ist die in-circuit-Tests (ICT).

edit:nur um zu klären, ein bisschen mehr, ich merke, dass beide wichtig sind, aber normalerweise getrennt zwischen dev und QA.

Intern ist wissen wichtig für die tester/QA?Ich habe Argumente gehört, dass die Tests mit diesem wissen im Hinterkopf können Sie noch besser testen auf Probleme, aber ich habe auch gehört, dass Argumente, dass dieses wissen kann ablenken von funktionalen Bedürfnisse und fördern "- Tests, um um den code" anstatt der beabsichtigten Lösung.

Lösung

Black-Box-Tests sollte der Schwerpunkt für die Tester / QA sein.
White-Box-Tests sollte der Schwerpunkt für Entwickler sein (das heißt Unit-Tests).
Die anderen Leute, die diese Frage beantwortet war, als die Frage interpretiert haben Was noch wichtiger ist, weiß-Box-Tests oder Black-Box-Test ist . Ich glaube auch, dass sie beide wichtig sind, aber Sie könnten diese IEEE-Artikel prüfen wollen, , die behauptet, dass white-Box-Test ist wichtiger.

Andere Tipps

White Box Testing gleich Software Unit Test. Der Entwickler oder ein Entwicklungsniveau Tester (zum Beispiel ein anderer Entwickler) stellt sicher, dass der Code, den er geschrieben hat einwandfrei funktioniert entsprechend den detaillierten Level-Anforderungen, bevor sie in das System zu integrieren.

Black Box Testing gleich Integrationstests. Der Tester wird sichergestellt, dass das System entsprechend den Anforderungen auf funktionaler Ebene arbeitet.

Beide Testansätze sind ebenso wichtig in meiner Meinung nach.

Ein gründliche Einheit Test Defekte in der Entwicklungsphase fangen und nicht nach der Software in das System integriert. Ein Systemebene Blackbox Test wird sicherstellen, dass alle Software-Module korrekt verhalten, wenn sie miteinander integriert. Ein Unit-Test in der Entwicklungsphase würde diese Mängel seit Module nicht fangen ist in der Regel unabhängig voneinander entwickelt.

Black Box

1 Konzentriert sich auf die Funktionalität des Systems Konzentriert sich auf die Struktur (Programm) des Systems

2 Techniken verwendet werden:

· Äquivalenz

· Grenzwertanalyse

· Fehler erraten

· Race Conditions

· Ursache-Wirkungs-Graphen

· Syntaxprüfung

· Zustandsbasiertes Testen

· Graph Matrix

Tester kann nicht technisch sein

Hilft die Unbestimmtheit und Widerspruch in funktionalen Spezifikationen zu identifizieren

White Box

Techniken verwendet werden:

· Basis Pfad Testing

· Flussdiagramm-Notation

· Kontrollstruktur Testing

Bedingung Testing
Datenflussprüfung

· Loop-Tests

Einfache Loops
Nested Loops
verketteten Loops
Unstructured Loops

Tester sollten technisch sein

Hilft die logischen und Codierung Probleme zu identifizieren.

sollte QA konzentrieren sich auf Black-Box-Tests . Das Hauptziel der QA ist zu prüfen, was das System nicht (tut Merkmale Anforderungen?), Nicht wie sie es tut.

Auf jeden Fall sollte es schwierig sein, für QA White-Box-Tests zu tun, da die meisten von QA Jungs sind nicht Tech-Jungs, so dass sie in der Regel Testfunktionen über die Benutzeroberfläche (wie Benutzer).

Ein Schritt weiter, ich denke developpers sollte konzentrieren sich auf Black-Box-Tests . Ich bin nicht einverstanden mit dieser weit verbreiteten Assoziation zwischen Unit-Tests und White-Box zu testen, aber es kann nur eine Frage einen Vokabular / Maßstab sein. Auf der Skala eines Unit-Test, die System Under Test ist eine Klasse / Methode, den Vertrag (durch seine Unterschrift) hat und der wichtige Punkt ist zu prüfen, was es tut, nicht wie. Außerdem White-Box-Test bedeutet, dass Sie wissen, wie das Verfahren seinen Vertrag erfüllen wird, die mit TDD mir scheint incompatile.

IMHO, wenn Ihr SUT so komplex ist, dass man weiß-Box-Tests tun müssen, ist es in der Regel Zeit für Refactoring.

"Beide", wurde bereits oben erwähnt, und ist die offensichtliche Antwort...aber IMO, white-box-Test geht weit über die developer-unit-Tests (althoughI nehme an, es könnte davon abhängen, wo ziehst du die Linie zwischen weiß und schwarz).Zum Beispiel, code-coverage-Analyse ist eine gängige white-box-Ansatz - d.h.führen Sie einige Szenarios oder die tests, und untersuchen Sie die Ergebnisse der Suche für Löcher in der Prüfung.Auch wenn unit-tests haben 100% cc -, mess-cc über gemeinsame Benutzer-Szenarien offenbaren kann code, der möglicherweise noch mehr testen.

Ein weiterer Ort, wo white-box-Tests wird untersucht, Datentypen, Konstanten und anderen Informationen zu suchen Sie nach Grenzen, spezielle Werte, etc.Zum Beispiel, wenn eine Anwendung hat einen Eingang, der nimmt eine numerische Eingabe, ein bb nur Ansatz könnte die tester zu "erraten", was Werte wäre gut zum testen, in der Erwägung, dass eine wb-Ansatz zeigen, dass alle Werte zwischen 1-256 behandelt werden, eine Möglichkeit, während größere Werte behandelt werden, ein anderer Weg...und vielleicht die Zahl 42 hat noch einen anderen code-Pfad.

Also, die Antwort auf die ursprüngliche Frage - beide bb und wb sind wichtig für eine gute Prüfung.

Nach meiner Erfahrung der meisten Entwickler wandern natürlich in Richtung White-Box-Tests. Da wir, dass der zugrunde liegende Algorithmus „richtiger“ benötigen, um sicherzustellen ist, neigen wir dazu, mehr auf den Interna zu konzentrieren. Aber, wie bereits erwähnt wurde, sowohl weiße als auch schwarze Box-Test ist wichtig.

Deshalb ziehe ich Tester haben sich mehr auf die Black-Box-Tests, um die Tatsache zu decken, dass die meisten Entwickler nicht wirklich tun es, und häufig sind nicht sehr gut darin.

Das ist nicht zu sagen, dass die Tester im Dunkeln gehalten werden sollte, wie das System funktioniert, nur dass ich sie lieber mehr auf den Problembereich konzentrieren und wie tatsächliche Benutzer die Interaktion mit dem System nicht, ob die Funktion Somemethod ( int x) korrekt eine Ausnahme aus, wenn x gleich 5 ist.

Es ist ein bisschen von einer offenen Tür, aber am Ende sind beide etwa gleich wichtig.

Was ist schlimmer?

Software das tut, was es tun muss, aber intern hat Probleme?
Software, die funktionieren sollte, wenn man sich die Quellen suchen, aber nicht?

Meine Antwort: Weder ist völlig akzeptabel, aber Software kann nicht zu 100% bugfree nachgewiesen werden. So wirst du einige Kompromisse machen müssen. Option zwei ist mehr direkt noticable an Kunden, so dass Sie gehen Probleme mit, dass früher zu bekommen. Auf lange Sicht Option man geht, als problematisch.

Black Box Testing: Black Box-Test ist nur Beobachtung keine Notwendigkeit, internes Wissen oder die Struktur der Software-Produkt. nur darum, gültige und ungültige Dateneingabe und erwartet das richtige Ergebnis. hier Tester die Fehler aber nicht in der Lage zu finden, die Lage von defect.black-Box-Tests durchgeführt in alle Test Ebene finden.

Black-Box-Tests tecniques sind: 1. Gleichwertigkeit Partition 2. Randwertanalyse 3. Entscheidungstabelle 4. Zustandsdiagramm 4. Anwendungsfalldiagramm

White Box Testing: White-Box testet es die Kenntnis der internen Logik und Struktur der Software-Produkt erfordert. hier werden wir die Schleife, Zustand und Zweig überprüfen. hier finden wir den Mangel nicht nur, sondern auch und Lage des Defekts.

White Box Testing Techniques: 1. Erklärung Coverage 2. Decision Coverage 3. Zweigüberdeckung 4. Pfadüberdeckung.

Normalerweise ist der White-Box-Test ist nicht möglich, für die Tester. So ist die einzige praktikable Lösung für Tester ist Black-Box-Ansatz zu betonen.
Doch mit aspektorientierte Programmierung und Design-by-Contract-Methode, wenn die Testziele in den Zielcode als Verträge programmiert werden (von der statischen Sicht eines Programm zu sehen ist), und / oder wenn die temporale Logik Testen in den Code als Querschnitte (dynamische Sicht der Testlogik) so programmiert ist, würden white-Box-Tests nicht nur möglich, sondern auch eine bevorzugte Aufnahme für Tester. Da sagte, muss es eine Know-how-anspruchsvolle nehmen sein, die Tester brauchen nicht nur gute Tester sein, aber auch gute Programmierer oder mehr als gute Programmierer.

Black Box Testing ist ein Software-Test-Verfahren, bei dem die interne Struktur / Design / Umsetzung des Elements getestet wird, an den Tester nicht bekannt. White Box Testing ist ein Software-Test-Verfahren, bei dem die interne Struktur / Design / Umsetzung des zu prüfenden Teil mit dem Tester bekannt ist.

Was macht "internes Wissen?" Ist zu wissen, dass so und so Algorithmus verwendet wurde, um ein Problem zu qualifizieren oder sich die Tester jede Codezeile sehen muß zu lösen, dafür zu sein „intern?“

ich in jedem Testfall denken, sollte es Ergebnisse von der Beschreibung und nicht bestimmt gegeben zu erwarten, wie die Tester entscheiden die Spezifikation, da dies zu interpretieren kann zu Problemen führen, wo jeder denkt, dass sie Recht hat und die Schuld des anderes für die Problem dar.

* Black-Box-Test: Ist der Test auf Systemebene, die Funktionalität des Systems zu überprüfen, um sicherzustellen, dass das System alle Funktionen ausführt, die es für entworfen wurde, seine hauptsächlich Mängel aufzudecken auf Benutzerpunkt gefunden. Es ist besser, einen professionellen Tester Black Box System ‚zu mieten Coz der Entwickler in der Regel mit einer Perspektive prüft, dass die Codes er geschrieben hatte, ist gut und erfüllt die funktionalen Anforderungen der Kunden, so dass er eine Menge Dinge zu kurz kommen könnte (I don ‚t bedeutet, jemanden zu beleidigen)
Whitebox ist der erste Test, der in dem SDLC.This erfolgt ist, um Fehler wie Laufzeitfehler aufzudecken und Kompilation errrors Es kann entweder durch Prüfer oder dem Entwicklers erfolgt selbst, aber ich denke, es ist besser, immer, dass die Person, die schrieb Code testet it.He versteht sich mehr als eine andere Person. *

Hier ist mein 5 Cent:

Als Entwickler, ich schreibe meistens Tests für Methoden (in einer Klasse) als White-Box-Tests, einfach, weil ich gerade brechen nicht mein Test will, weil ich die inneren Werke meines Code ändern.

ich nur meine Tests will brechen, wenn meine Methode Verhaltensänderungen (zum Beispiel gibt ein anderes Ergebnis als zuvor).

In den letzten 20 Jahren der Entwicklung, ich einfach müde zu tun, up-to doppelte Arbeit, nur weil meine Unit-Tests stark an den Code gebunden waren, und ich brauche beide Anwendungscode und Testcode zu erhalten.

Ich denke, machen Code Entkopplung (auch wenn Sie Code-Tests) ist eine sehr gute Praxis.

Weitere 5 Cent: Ich kaum nie Frameworks spöttisch, denn wenn ich es unbedingt etwas finden, ich meinen Code lieber verspotten, anstatt zu entkoppeln - und ja, in vielen Fällen, die sehr gut möglich sind (vor allem, wenn Sie nicht in Legacy-Code arbeiten ): -)

* Black-Box-Tests: Wenn der Quellcode nicht verfügbar ist, dann werden Testdaten auf der Funktion der Software basieren, ohne Rücksicht darauf, wie es durchgeführt wurde. -kräftigen textExamples von Black-Box-Tests sind: Randwertprüfung und Äquivalenz

* White-Box-Test: Wenn der Quellcode des zu testenden Systems verfügbar ist, dann werden die Testdaten über die Struktur dieses Quellcodes basiert. -Beispiele von White-Box-Tests sind: Pfadtest und Datenfluss-Tests

Einfache ... Blackbox-Tests werden auch als Integrationstest oder Rauch-Screen-Tests bekannt. Dies ist vor allem in einer verteilten Umgebung angewandt, die auf einem ereignisgesteuerten Architektur verlassen. Sie testen, einen Dienst auf einem anderen Dienst auf Basis alle möglichen Szenarien zu sehen. Hier können Sie nicht vollständig prognostizieren alle möglichen Ausgang, da jede Komponente der SOA / Enterprise-App sollen autonom funktionieren. Dies kann als High-Level-Prüfung bezeichnet werden

, während

White-Box-Test bezieht sich auf Komponententests. wo alle erwarteten Szenarien und Ausgabe effektiv prognostiziert werden. d.h Eingang und erwartet output.This kann als Low-Level-Tests bezeichnet werden

ich mit der am besten bewerteten Antwort auf diese Frage nur teilweise zustimmen. Welche Art von Tests würde sagen, man sollte der Schwerpunkt sein (für Tester / QAs), und warum?

Ich bin damit einverstanden, dass: „Black-Box-Tests der Schwerpunkt sein sollten Tester / QA ".
Ich bin damit einverstanden, dass White-Box-Tests der Schwerpunkt sein sollten Entwickler, aber ich bin nicht einverstanden, dass White-Box-Test nur Einheit Tests.

ich mit der Definition einverstanden hier die besagt, dass White Box Testing-Methode die anwendbar ist, folgende Ebenen der Software-Test:

Unit Testing: Zum Testen Pfade innerhalb einer Einheit
Integrationstests: Für Testpfade zwischen den Einheiten
Systemtest: Für Testpfade zwischen Subsystemen

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow