Der Begriff White-Box-Test (seltener auch Glass-Box-Test) bezeichnet eine Methode des Software-Tests, bei der die Tests mit Kenntnissen über die innere Funktionsweise des zu testenden Systems entwickelt werden. Im Gegensatz zum Black-Box-Test ist für diesen Test also ein Blick in den Quellcode gestattet. D. h., es wird am Code geprüft.
Ein Beispiel für einen White-Box-Test ist ablaufbezogenes Testen (Kontrollflussorientierte Testverfahren), bei welchem der Ablaufgraph im Vordergrund steht. Qualitätskriterium des Tests ist es, sicherzustellen, dass Testfälle in Bezug auf die Überdeckung des Quellcodes gewisse Hinlänglichkeitskriterien erfüllen. Gängig sind dabei u. a. folgende Maße (bzw. Qualitätskriterien):
Die Zahl der benötigten Testfälle für die einzelnen Maße unterscheidet sich z. T. deutlich. Kantenüberdeckung wird im Allgemeinen als minimales Testkriterium angesehen. Je nach Art und Struktur der zu testenden Software können andere Maße für ein System als Ganzes oder für Module sinnvoll sein.
Selbst wenn ein Softwaresystem in Bezug auf ein Hinlänglichkeitskriterium erfolgreich getestet wurde, schließt das nicht aus, dass es Fehler enthält. Dies liegt in der Natur des White-Box-Tests begründet und kann eine der folgenden Ursachen haben:
Zusammenfassend kann man sagen, dass White-Box-Tests alleine als Testmethodik nicht ausreichen. Eine sinnvolle Testreihe sollte Black-Box-Tests und White-Box-Tests kombinieren. Nach der Überdeckungsmessung der Testfälle des Black-Box-Tests (durch ein geeignetes Werkzeug) werden durch Betrachten der nicht überdeckten Codeteile neue Testfälle aufgestellt, um die Überdeckung zu erhöhen.
Will man ein System auch in seinen Teilsystemen testen, benötigt man dazu Kenntnisse über die innere Funktionsweise des zu testenden Systems. White-Box-Tests eignen sich besonders gut, um in Erscheinung getretene Fehler zu lokalisieren, d. h., die fehlerverursachende Komponente zu identifizieren und als Regressionstest ein Wiederauftreten des Fehlers bereits in der Komponente zu vermeiden.
Weil die Entwickler der Tests Kenntnisse über die innere Funktionsweise des zu testenden Systems besitzen müssen, werden White-Box-Tests von demselben Team, häufig sogar von denselben Entwicklern entwickelt wie die zu testenden Komponenten. Spezielle Testabteilungen werden für White-Box-Tests in der Regel nicht eingesetzt, da der Nutzen speziell für diese Aufgabe abgestellter Tester meist durch den Aufwand der Einarbeitung in das System eliminiert wird.
White-Box-Tests werden eingesetzt, um Fehler in den Teilkomponenten aufzudecken und zu lokalisieren, sind aber aufgrund ihrer Methodik kein geeignetes Werkzeug, Fehler gegenüber der Spezifikation aufzudecken. Für letzteres benötigt man Black-Box-Tests. Zu bedenken ist auch, dass zwei Komponenten, die für sich genommen korrekt gemäß ihrer jeweiligen Teilspezifikation arbeiten, zusammen nicht zwangsläufig eine korrekte Einheit gemäß der Gesamtspezifikation bilden. Dies kann durch Black-Box-Tests leichter festgestellt werden als durch White-Box-Tests.
Im Vergleich zu Black-Box-Tests sind White-Box-Tests wesentlich einfacher in der Durchführung, da sie keine besondere organisatorische Infrastruktur benötigen.
Vorteile von White-Box-Tests gegenüber Black-Box-Tests
Nachteile von White-Box-Tests gegenüber Black-Box-Tests
Zudem sei genannt, dass die Unterscheidung zwischen Black-Box-Test und White-Box-Test teilweise von der Perspektive abhängt. Das Testen einer Teilkomponente ist aus Sicht des Gesamtsystems ein White-Box-Test, da für das Gesamtsystem aus der Außenperspektive keine Kenntnisse über den Systemaufbau und damit die vorhandenen Teilkomponenten vorliegen. Aus Sicht der Teilkomponente wiederum kann derselbe Test unter Umständen als Black-Box-Test betrachtet werden, wenn er ohne Kenntnisse über die Interna der Teilkomponente entwickelt und durchgeführt wird.