White-Box-Test
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): Zeilenüberdeckung: Ausführung aller Quellcode-Zeilen Anweisungsüberdeckung bzw. Knotenüberdeckung: Ausführung aller Anweisungen Zweigüberdeckung bzw. Kantenüberdeckung: Durchlaufen aller möglichen Kanten von Verzweigungen des Kontrollflusses Bedingungsüberdeckung bzw. Termüberdeckung (mehrere Varianten): Durchlaufen aller möglichen ausschlaggebenden Belegungen bei logischen Ausdrücken in Bedingungen Pfadüberdeckung (mehrere Varianten): Betrachtung der Pfade durch ein Modul 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: Der White-Box-Test leitet Testfälle nicht aus der Spezifikation des Programms her, sondern aus dem Programm selbst. Getestet werden kann nur die Korrektheit eines Systems, nicht, ob es eine geforderte Semantik erfüllt. Auch wenn alle Programmpfade getestet worden sind, bedeutet dies nicht, dass ein Programm fehlerfrei arbeitet. Der Fall, dass im Graphen des Kontrollflusses Kanten fehlen, wird nicht erkannt. 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.
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):
- Zeilenüberdeckung: Ausführung aller Quellcode-Zeilen
- Anweisungsüberdeckung bzw. Knotenüberdeckung: Ausführung aller Anweisungen
- Zweigüberdeckung bzw. Kantenüberdeckung: Durchlaufen aller möglichen Kanten von Verzweigungen des Kontrollflusses
- Bedingungsüberdeckung bzw. Termüberdeckung (mehrere Varianten): Durchlaufen aller möglichen ausschlaggebenden Belegungen bei logischen Ausdrücken in Bedingungen
- Pfadüberdeckung (mehrere Varianten): Betrachtung der Pfade durch ein Modul
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:
- Der White-Box-Test leitet Testfälle nicht aus der Spezifikation des Programms her, sondern aus dem Programm selbst. Getestet werden kann nur die Korrektheit eines Systems, nicht, ob es eine geforderte Semantik erfüllt.
- Auch wenn alle Programmpfade getestet worden sind, bedeutet dies nicht, dass ein Programm fehlerfrei arbeitet. Der Fall, dass im Graphen des Kontrollflusses Kanten fehlen, wird nicht erkannt.
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.
Vergleich mit Black-Box-Tests
[Bearbeiten | Quelltext bearbeiten]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
- Testen von Teilkomponenten und der internen Funktionsweise
- Geringerer organisatorischer Aufwand
- Automatisierung durch gute Tool-Unterstützung
Nachteile von White-Box-Tests gegenüber Black-Box-Tests
- Erfüllung der Spezifikation nicht überprüft
- Eventuell Testen „um Fehler herum“
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.
Literatur
[Bearbeiten | Quelltext bearbeiten]- Andreas Spillner, Tilo Linz: Basiswissen Softwaretest – Basiswissen Softwaretest: Aus- und Weiterbildung zum Certified Tester: Foundation Level nach ISTQB-Standard. 3., überarbeitete und aktualisierte Auflage, dpunkt.verlag GmbH, Heidelberg 2005, ISBN 3-89864-358-1.
- Lee Copeland: A Practitioner's Guide to Software Test Design. first printing, Artech House Publishers, Norwood MA, USA 2003, ISBN 1-58053-791-X.
- BCS SIGIST (British Computer Society Specialist Interest Group in Software Testing): Standard for Software Component Testing (ZIP; 340 kB), Working Draft 3.4, 27. April 2001.