<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="de">
	<id>https://wiki-de.moshellshocker.dns64.de/index.php?action=history&amp;feed=atom&amp;title=White-Box-Test</id>
	<title>White-Box-Test - Versionsgeschichte</title>
	<link rel="self" type="application/atom+xml" href="https://wiki-de.moshellshocker.dns64.de/index.php?action=history&amp;feed=atom&amp;title=White-Box-Test"/>
	<link rel="alternate" type="text/html" href="https://wiki-de.moshellshocker.dns64.de/index.php?title=White-Box-Test&amp;action=history"/>
	<updated>2026-05-26T10:35:58Z</updated>
	<subtitle>Versionsgeschichte dieser Seite in Wikipedia (Deutsch) – Lokale Kopie</subtitle>
	<generator>MediaWiki 1.43.8</generator>
	<entry>
		<id>https://wiki-de.moshellshocker.dns64.de/index.php?title=White-Box-Test&amp;diff=44971&amp;oldid=prev</id>
		<title>imported&gt;Okoska-törp: /* growthexperiments-addlink-summary-summary:2|0|0 */</title>
		<link rel="alternate" type="text/html" href="https://wiki-de.moshellshocker.dns64.de/index.php?title=White-Box-Test&amp;diff=44971&amp;oldid=prev"/>
		<updated>2025-03-10T21:10:41Z</updated>

		<summary type="html">&lt;p&gt;&lt;span class=&quot;autocomment&quot;&gt;growthexperiments-addlink-summary-summary:2|0|0&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;Neue Seite&lt;/b&gt;&lt;/p&gt;&lt;div&gt;Der Begriff &amp;#039;&amp;#039;&amp;#039;White-Box-Test&amp;#039;&amp;#039;&amp;#039; (seltener auch &amp;#039;&amp;#039;&amp;#039;Glass-Box-Test&amp;#039;&amp;#039;&amp;#039;) bezeichnet eine Methode des [[Software-Test]]s, 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 [[Quelltext|Quellcode]] gestattet. D.&amp;amp;nbsp;h., es wird am Code geprüft.&lt;br /&gt;
&lt;br /&gt;
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 &amp;#039;&amp;#039;Hinlänglichkeitskriterien&amp;#039;&amp;#039; erfüllen. Gängig sind dabei u.&amp;amp;nbsp;a. folgende Maße (bzw. Qualitätskriterien):&lt;br /&gt;
&lt;br /&gt;
* &amp;#039;&amp;#039;Zeilenüberdeckung&amp;#039;&amp;#039;: Ausführung aller Quellcode-Zeilen&lt;br /&gt;
* &amp;#039;&amp;#039;Anweisungsüberdeckung&amp;#039;&amp;#039; bzw. &amp;#039;&amp;#039;Knotenüberdeckung&amp;#039;&amp;#039;: Ausführung aller Anweisungen&lt;br /&gt;
* &amp;#039;&amp;#039;Zweigüberdeckung&amp;#039;&amp;#039; bzw. &amp;#039;&amp;#039;Kantenüberdeckung&amp;#039;&amp;#039;: Durchlaufen aller möglichen Kanten von Verzweigungen des Kontrollflusses&lt;br /&gt;
* &amp;#039;&amp;#039;Bedingungsüberdeckung&amp;#039;&amp;#039; bzw. &amp;#039;&amp;#039;Termüberdeckung&amp;#039;&amp;#039; (mehrere Varianten): Durchlaufen aller möglichen ausschlaggebenden Belegungen bei logischen Ausdrücken in Bedingungen&lt;br /&gt;
* &amp;#039;&amp;#039;Pfadüberdeckung&amp;#039;&amp;#039; (mehrere Varianten): Betrachtung der Pfade durch ein Modul&lt;br /&gt;
&lt;br /&gt;
Die Zahl der benötigten Testfälle für die einzelnen Maße unterscheidet sich z.&amp;amp;nbsp;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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
* 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.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&amp;amp;nbsp;h., die fehlerverursachende [[Modul (Softwarearchitektur)|Komponente]] zu identifizieren und als [[Regressionstest]] ein Wiederauftreten des Fehlers bereits in der Komponente zu vermeiden.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Vergleich mit Black-Box-Tests ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Im Vergleich zu [[Black-Box-Test]]s sind White-Box-Tests wesentlich einfacher in der Durchführung, da sie keine besondere organisatorische Infrastruktur benötigen.&lt;br /&gt;
&lt;br /&gt;
Vorteile von White-Box-Tests gegenüber Black-Box-Tests&lt;br /&gt;
* Testen von Teilkomponenten und der internen Funktionsweise&lt;br /&gt;
* Geringerer organisatorischer Aufwand&lt;br /&gt;
* Automatisierung durch gute Tool-Unterstützung&lt;br /&gt;
&lt;br /&gt;
Nachteile von White-Box-Tests gegenüber Black-Box-Tests&lt;br /&gt;
* Erfüllung der Spezifikation nicht überprüft&lt;br /&gt;
* Eventuell Testen „um Fehler herum“&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Literatur ==&lt;br /&gt;
* Andreas Spillner, Tilo Linz: &amp;#039;&amp;#039;Basiswissen Softwaretest – Basiswissen Softwaretest: Aus- und Weiterbildung zum Certified Tester: Foundation Level nach ISTQB-Standard.&amp;#039;&amp;#039; 3., überarbeitete und aktualisierte Auflage, dpunkt.verlag GmbH, Heidelberg 2005, ISBN 3-89864-358-1.&lt;br /&gt;
* Lee Copeland: &amp;#039;&amp;#039;A Practitioner&amp;#039;s Guide to Software Test Design.&amp;#039;&amp;#039; first printing, Artech House Publishers, Norwood MA, USA 2003, ISBN 1-58053-791-X.&lt;br /&gt;
* BCS SIGIST (British Computer Society Specialist Interest Group in Software Testing): [http://www.testingstandards.co.uk/BS7925_3_4.zip &amp;#039;&amp;#039;Standard for Software Component Testing&amp;#039;&amp;#039;] ([[ZIP-Dateiformat|ZIP]]; 340&amp;amp;nbsp;kB), Working Draft 3.4, 27. April 2001.&lt;br /&gt;
&lt;br /&gt;
== Siehe auch ==&lt;br /&gt;
* [[Anweisungsüberdeckungstest]]&lt;br /&gt;
* [[Bedingungsüberdeckungstest]]&lt;br /&gt;
* [[Zweigüberdeckungstest]]&lt;br /&gt;
* [[Pfadüberdeckungstest]]&lt;br /&gt;
* [[Testmethode]]n&lt;br /&gt;
&lt;br /&gt;
[[Kategorie:Testen (Software)]]&lt;/div&gt;</summary>
		<author><name>imported&gt;Okoska-törp</name></author>
	</entry>
</feed>