Ein Black-Box-Test leitet Testfälle aus der Spezifikation ab, ein White-Box-Test aus der internen Struktur des Testobjekts, etwa aus dem Code. So trennt der ISTQB-Lehrplan Certified Tester Foundation Level die beiden Ansätze (ISTQB-Lehrplan CTFL 4.0.2, 2025). Black-Box-Verfahren prüfen, ob sich die Software wie gefordert verhält. White-Box-Verfahren zeigen, welche Anweisungen und Zweige Ihre Tests ausführen.

Manche Vergleichstabellen und KI-Antworten nennen noch den Anwendungsfalltest als Black-Box-Verfahren, obwohl ISTQB ihn mit Version 4.0 aus dem Foundation-Lehrplan gestrichen hat. In der IT-Sicherheit hat „Black-Box“ zudem eine zweite Bedeutung. Die Studienlage spricht dafür, beide Verfahren zu kombinieren.

Kurz gefasst: Black-Box-Tests entstehen aus Anforderungen und User-Storys, White-Box-Tests aus Code und Architektur. ISTQB CTFL 4.0 nennt vier Black-Box-Verfahren (Äquivalenzklassen, Grenzwerte, Entscheidungstabellen, Zustandsübergänge) und zwei White-Box-Verfahren (Anweisungs- und Zweigtest). In Studien seit 1987 findet kein Verfahren durchgängig mehr Fehler. Kombinieren Sie darum fachliche Tests gegen die Spezifikation mit Unit-Tests, die Code-Überdeckung messen.

Abbildung 1: Black-Box-Test und White-Box-Test nach Testbasis

Was ist der Unterschied zwischen Black-Box-Test und White-Box-Test?

Der Unterschied zwischen Black-Box-Test und White-Box-Test liegt in der Testbasis: Black-Box-Verfahren sind spezifikationsbasiert, White-Box-Verfahren strukturbasiert. Der Black-Box-Test, so der deutsche Lehrplan, „basiert auf Spezifikationen und leitet die Tests aus der Dokumentation ab, die sich nicht auf die interne Struktur des Testobjekts bezieht“ (ISTQB-Lehrplan CTFL 4.0.2, 2025). Der White-Box-Test nutzt Code, Architektur, Workflows und Datenflüsse.

Daraus folgt ein Unterschied beim Zeitpunkt. Spezifikationsbasierte Testfälle können Sie schreiben, sobald eine Spezifikation vorliegt, strukturbasierte erst nach Entwurf oder Implementierung. Ändert sich später die Implementierung, das geforderte Verhalten aber nicht, bleiben die spezifikationsbasierten Testfälle laut ISTQB nützlich (ISTQB CTFL v4.0.1, 2024).

Was ist ein Black-Box-Test?

Ein Black-Box-Test ist ein Testverfahren, das Testfälle aus dem spezifizierten Verhalten eines Systems ableitet, ohne dessen interne Struktur zu betrachten. Grundlage sind Anforderungen, Spezifikationen und User-Storys. Wer testet, kennt Eingaben und erwartete Ergebnisse; den Code braucht er für den Testentwurf nicht. Das Verfahren passt auf jede Teststufe.

Abbildung 2: Die Testverfahren im ISTQB-Lehrplan CTFL 4.0

ISTQB CTFL 4.0 nennt vier gängige Black-Box-Testverfahren (ISTQB-Lehrplan CTFL 4.0.2, 2025):

• Äquivalenzklassenbildung (Equivalence Partitioning): teilt Daten in Klassen, die das Testobjekt gleich verarbeitet. Laut Lehrplan „reicht ein Test je Klasse aus“.

• Grenzwertanalyse (Boundary Value Analysis): prüft die Ränder geordneter Klassen, als 2-Wert- oder als strengere 3-Wert-Variante.

• Entscheidungstabellentest (Decision Table Testing): prüft Geschäftsregeln als Kombinationen von Bedingungen.

• Zustandsübergangstest (State Transition Testing): prüft Zustände und Übergänge, zum Beispiel bei einem Konto, das aktiv, gesperrt oder gekündigt ist.

Den Fokus auf Grenzwerte begründet der Lehrplan knapp, „weil Entwicklern bei diesen Grenzwerten eher Fehlhandlungen unterlaufen“. Wie Sie Klassen und Grenzwerte Schritt für Schritt ableiten, zeigt unser Beitrag zu Äquivalenzklassen und Grenzwertanalyse.

Spezifikationsbasiertes Testen braucht Fachwissen und Handwerk im Testentwurf. Wer Äquivalenzklassen bildet, muss Grenzen, Regeln und Zustände in der Spezifikation erkennen. Sind die Anforderungen lückenhaft, werden es die Testfälle auch. Wie Sie fachliches Verhalten systematisch prüfen, beschreibt der Leitfaden zum Funktionstest.

Was ist ein White-Box-Test?

Ein White-Box-Test ist ein strukturbasiertes Testverfahren, das Testfälle aus der Implementierung ableitet: aus Code, Architektur, Workflows oder Datenflüssen (ISTQB CTFL v4.0.1, 2024). Der Foundation-Lehrplan behandelt zwei codebezogene Verfahren, den Anweisungstest und den Zweigtest. Anweisungsüberdeckung misst den Anteil ausgeführter Anweisungen, Zweigüberdeckung den Anteil durchlaufener Zweige, bei einer if-Bedingung etwa den wahren und den falschen Zweig.

Die Stärke ist der Blick auf die gesamte Implementierung. Laut ISTQB hilft das beim Finden von Fehlern, selbst wenn die Spezifikation vage, veraltet oder unvollständig ist.

Setzt die Software eine Anforderung gar nicht um, gibt es keinen Code, den ein Test ausführen könnte. Der englische Lehrplan schreibt, White-Box-Tests „may not detect the resulting defects of omission“ (ISTQB CTFL v4.0.1, 2024).

White-Box-Tests sind nicht auf den Komponententest beschränkt; der Lehrplan erwähnt sie ausdrücklich für höhere Teststufen, etwa beim API-Testing. Wie Entwickler strukturbasierte Tests schreiben, erklärt der Beitrag zum Unit-Test. Warum hohe Überdeckungswerte allein wenig über Testqualität aussagen, steht im Artikel zur Testabdeckung.

Was hat sich im ISTQB-Lehrplan 4.0 geändert?

Mit CTFL 4.0 hat ISTQB den Anwendungsfalltest aus den Black-Box-Verfahren des Foundation Level gestrichen und den Entscheidungstest durch den Zweigtest ersetzt (ISTQB CTFL v4.0.1, Release Notes, 2024). Viele Vergleichsseiten und selbst aktuelle KI-Antworten listen noch den alten Stand. Die Änderungen im Überblick:

• Anwendungsfalltest (Use Case Testing): aus dem Foundation-Lehrplan entfernt, weiterhin Teil des Lehrplans Advanced Test Analyst.

• Entscheidungstest und Entscheidungsüberdeckung: ersetzt durch Zweigtest und Zweigüberdeckung.

• Integrationstest: aufgeteilt in Komponentenintegrationstest und Systemintegrationstest, womit der Lehrplan fünf Teststufen beschreibt.

• Grey-Box: kommt weder in Version 4.0.1 noch in 4.0.2 vor. Grey-Box ist keine Kategorie im ISTQB-Foundation-Lehrplan.

Der Lehrplan führt funktionalen Test, nicht-funktionalen Test, Black-Box-Test und White-Box-Test als vier getrennte Testarten, die auf allen Teststufen anwendbar sind (ISTQB CTFL v4.0.1, 2024). „Funktionstest = Black-Box-Test“ ist deshalb eine Vereinfachung: Funktional beschreibt, was geprüft wird, Black-Box, woraus die Testfälle stammen.

Neben diesen beiden Gruppen kennt der Lehrplan erfahrungsbasierte Testverfahren: intuitive Testfallermittlung, explorativen Test und checklistenbasierten Test. Laut ISTQB können sie Fehler aufdecken, die Black-Box- und White-Box-Verfahren übersehen.

Wann setzen Sie welches Verfahren ein?

Black-Box-Tests setzen Sie ein, sobald Anforderungen vorliegen und das Verhalten des Systems zählt; White-Box-Tests, wenn Entwickler die Code-Pfade einer Komponente absichern. Die meisten Projekte brauchen beides. Diese Situationen helfen bei der Entscheidung:

Abbildung 3: Welches Verfahren zu welcher Situation passt

• Anforderungen stehen, Code fehlt noch: spezifikationsbasierte Testfälle jetzt entwerfen.

• Systemtest und Abnahme: Black-Box, denn hier zählt das Gesamtverhalten gegen die Spezifikation. Details im Beitrag zum Systemtest.

• Neue oder geänderte Komponente: White-Box im Unit-Test, gemessen an Anweisungs- und Zweigüberdeckung.

• Schnittstellen: beides, wie der Leitfaden zum API-Testing zeigt.

• Code-Überdeckung als Nachweis gefordert: nur White-Box. ISTQB hält fest: „Performing only black-box testing does not provide a measure of actual code coverage.“ (ISTQB CTFL v4.0.1, 2024)

Wie kombinieren Sie beide Verfahren im Projekt?

1. Leiten Sie aus Anforderungen und User-Storys Testfälle ab, mit Äquivalenzklassen, Grenzwerten und Entscheidungstabellen.

2. Lassen Sie Entwickler parallel Unit-Tests schreiben und Anweisungs- und Zweigüberdeckung messen.

3. Prüfen Sie nicht ausgeführten Code: Fehlt ein Test, oder ist der Code überflüssig?

4. Verknüpfen Sie jede Anforderung mit mindestens einem Testfall. So fallen Anforderungen auf, die nie umgesetzt wurden.

5. Ergänzen Sie explorative Tests und automatisieren Sie stabile fachliche Tests als Regressionstests.

Wo setzt Autemos an?

Autemos automatisiert funktionale Tests auf der Black-Box-Seite. Teams bauen sie aus Anforderungen, Jira-Tickets oder User-Storys, per AI Recorder oder in visuellen Testabläufen, und führen sie gegen Web, Mobile, API und Desktop aus. Jeden KI-generierten Schritt gibt das Team frei, bevor er läuft. Web-Tests lassen sich als Playwright-Code in Java oder TypeScript exportieren und laufen ohne Autemos weiter.

Autemos misst keine Code-Überdeckung und ersetzt keine White-Box-Unit-Tests; diese bleiben bei Ihren Entwicklern. Liegen Anforderungen oder fachliche Testfälle bereits in Jira, setzt der Black-Box-Test dort an.

Was bedeuten Black-Box, White-Box und Grey-Box im Penetrationstest?

Im Penetrationstest beschreiben Black-Box, Grey-Box und White-Box, wie viel der Prüfer über das Zielsystem weiß; mit der ISTQB-Einteilung nach Testbasis teilen die Begriffe nur den Namen. NIST definiert Black-Box-Testing als „A test methodology that assumes no knowledge of the internal structure and implementation detail of the assessment object“ (NIST SP 800-53A Rev. 5, CSRC-Glossar).

Abbildung 4: Black-Box im Testentwurf (ISTQB) und im Penetrationstest (NIST)

Beim Grey-Box-Test geht NIST von teilweisem Wissen über die interne Struktur aus (NIST CSRC), beim White-Box-Test von explizitem und umfangreichem Wissen (NIST CSRC). Der OWASP Web Security Testing Guide v4.2 nennt Penetrationstests „commonly known as black-box testing or ethical hacking“ (OWASP WSTG v4.2).

Laut BSI-Leitfaden für IS-Penetrationstests erhält der Prüfer beim Blackbox-Test wenige Informationen, beim Whitebox-Test interne Informationen. Tendenziell empfiehlt der Leitfaden Whitebox-Tests (BSI Praxis-Leitfaden IS-Penetrationstests).

Autemos führt keine Sicherheits- oder Penetrationstests durch. Spricht ein Pentest-Dienstleister von Black-Box, meint er den Wissensstand seines Teams und keinen spezifikationsbasierten Testentwurf.

Welches Verfahren findet mehr Fehler?

In Experimenten seit 1987 findet weder spezifikationsbasiertes noch strukturbasiertes Testen durchgängig mehr Fehler; die Ergebnisse hängen vom Programm und von den Testpersonen ab. Basili und Selby verglichen 1987 Code-Lesen, funktionales und strukturelles Testen mit Profis und Studierenden (Basili & Selby, IEEE TSE, 1987). Bei den Profis fand Code-Lesen die meisten Fehler, funktionales Testen mehr als strukturelles, mit Schwankungen je nach Programm und Gruppe.

Juristo, Moreno und Vegas werteten 2004 Experimente aus 25 Jahren aus. Laut dieser Überblicksstudie war das Wissen über Testverfahren noch unreif (Juristo, Moreno & Vegas, Empirical Software Engineering, 2004).

Eine Studie von Vegas, Riofrío, Marcos und Juristo zeigt ein zweites Problem: Die Teilnehmer schätzten falsch ein, welches Testverfahren am wirksamsten ist. Die Autoren schreiben, „participants’ perceptions are wrong and that this mismatch is costly in terms of quality“ (Vegas et al., Empirical Software Engineering, 2020).

Kombinieren Sie darum spezifikationsbasierte Tests gegen die Anforderungen, White-Box-Tests im Code und explorative Tests.

Häufig gestellte Fragen

Ist ein Black-Box-Test dasselbe wie ein Funktionstest?

Ein Black-Box-Test ist nicht dasselbe wie ein Funktionstest; ISTQB führt beide als getrennte Testarten. Funktional beschreibt die geprüften Funktionen des Systems, Black-Box die Herkunft der Testfälle aus der Spezifikation. In der Praxis werden Funktionstests oft spezifikationsbasiert entworfen.

Welche Black-Box-Testverfahren nennt ISTQB CTFL 4.0?

ISTQB CTFL 4.0 nennt vier Black-Box-Verfahren: Äquivalenzklassenbildung, Grenzwertanalyse, Entscheidungstabellentest und Zustandsübergangstest. Der Anwendungsfalltest gehört seit Version 4.0 nicht mehr dazu und steht nur noch im Lehrplan Advanced Test Analyst.

Ist Grey-Box-Testing ein ISTQB-Begriff?

Grey-Box ist keine Kategorie im ISTQB-Foundation-Lehrplan, weder in Version 4.0.1 noch in 4.0.2. In der Sicherheitsprüfung beschreiben NIST und OWASP damit Tests, bei denen der Prüfer teilweises Wissen über das Zielsystem hat.

Wer führt Black-Box- und White-Box-Tests durch?

Spezifikationsbasierte Tests führen meist Tester, Analysten und Fachbereiche durch, White-Box-Tests meist Entwickler. Wer die Anforderungen kennt, testet gegen die Spezifikation. Wer den Code kennt, deckt Anweisungen und Zweige gezielt ab.

Misst ein Black-Box-Test die Code-Überdeckung?

Ein spezifikationsbasierter Test liefert keine Code-Überdeckung. Er misst Überdeckung an der Spezifikation: an Äquivalenzklassen, Grenzwerten, Regeln einer Entscheidungstabelle oder Zustandsübergängen. Anweisungs- und Zweigüberdeckung liefern nur White-Box-Tests, meist in den Unit-Tests der Entwickler.

Fazit

Ein Black-Box-Test prüft, ob die Software tut, was die Spezifikation verlangt, und deckt dabei auch nie umgesetzte Anforderungen auf; ein White-Box-Test zeigt, welcher Code ungetestet bleibt. Nach ISTQB CTFL 4.0 gehören vier Verfahren zur Black-Box-Gruppe und zwei zur White-Box-Gruppe; Grey-Box und Anwendungsfalltest stehen nicht im Foundation-Lehrplan.

Die Studien seit 1987 geben keinem Ansatz klar den Vorzug. Kombinieren Sie beide und ergänzen Sie explorative Tests. Autemos übernimmt die Black-Box-Seite: funktionale Tests aus Anforderungen, ausführbar auf Web, Mobile, API und Desktop. Code-Überdeckung und Unit-Tests bleiben bei Ihren Entwicklern. Wenn Sie sehen möchten, wie das in Ihren Projekten aussieht, sprechen Sie mit unserem Team.