White-Box-Test: Unterschied zwischen den Versionen

Aus FI-Wiki
 
(4 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== White-Box-Test ==
Der '''White-Box-Test''' ist ein [[Dynamisches Testen|dynamisches Testverfahren]], bei dem der Tester die '''interne Struktur und den Quellcode des Programms kennt'''.   
Der '''White-Box-Test''' ist ein [[Dynamisches Testen|dynamisches Testverfahren]], bei dem der Tester die '''interne Struktur und den Quellcode des Programms kennt'''.   
Im Gegensatz zum [[Black-Box-Test]] wird hier gezielt überprüft, ob alle Codepfade, Verzweigungen und internen Abläufe korrekt funktionieren.
Im Gegensatz zum [[Black-Box-Test]] wird hier gezielt überprüft, ob alle Codepfade, Verzweigungen und internen Abläufe korrekt funktionieren.


=== Merkmale ===
== Merkmale ==
* Tester kennt den Quellcode   
* Tester kennt den Quellcode   
* Fokus auf **Programmstruktur und Logik**  
* Fokus auf '''Programmstruktur und Logik'''  
* Ziel: maximale Abdeckung interner Wege ([[Code Coverage]])   
* Ziel: maximale Abdeckung interner Wege ([[Code Coverage]])   
* sehr gut für Unit-Tests geeignet
* sehr gut für Unit-Tests geeignet


=== Was wird getestet? ===
== Was wird getestet? ==
* Wird jede Zeile Code mindestens einmal ausgeführt?   
* Wird jede Zeile Code mindestens einmal ausgeführt?   
* Sind alle Verzweigungen korrekt implementiert?   
* Sind alle Verzweigungen korrekt implementiert?   
Zeile 16: Zeile 14:
* Gibt es toten Code (unerreichbare Bereiche)?   
* Gibt es toten Code (unerreichbare Bereiche)?   


=== Typische Methoden ===
== Typische Methoden ==
* '''Anweisungsüberdeckung''' – jede Anweisung wird ausgeführt   
* '''[[Code_Coverage#Anweisungsüberdeckung_(Statement_Coverage)|Anweisungsüberdeckung]]''' – jede Anweisung wird ausgeführt   
* '''Zweigüberdeckung''' – alle möglichen „Wege“ durch If/Else   
* '''[[Code_Coverage#Zweigüberdeckung_(Branch_Coverage)|Zweigüberdeckung]]''' – alle möglichen „Wege“ durch If/Else   
* '''Pfadüberdeckung''' – alle vollständigen Kombinationen von Pfaden   
* '''[[Code_Coverage#Pfadüberdeckung_(Path_Coverage)|Pfadüberdeckung]]''' – alle vollständigen Kombinationen von Pfaden   
* '''Schleifen- und Bedingungstests'''
* '''Schleifen- und Bedingungstests'''


=== Vorteile ===
== Vorteile ==
* sehr hohe Testtiefe   
* sehr hohe Testtiefe   
* entdeckt Fehler in der Logik und internen Struktur   
* entdeckt Fehler in der Logik und internen Struktur   
Zeile 28: Zeile 26:
* deckt auch versteckte oder seltene Codepfade auf
* deckt auch versteckte oder seltene Codepfade auf


=== Nachteile ===
== Nachteile ==
* erfordert Programmierkenntnisse   
* erfordert Programmierkenntnisse   
* zeitaufwendig bei großen Systemen   
* zeitaufwendig bei großen Systemen   
Zeile 34: Zeile 32:
* kann blind für fehlende Funktionen sein (wenn etwas gar nicht implementiert wurde)
* kann blind für fehlende Funktionen sein (wenn etwas gar nicht implementiert wurde)


=== Kurzmerksatz ===
== Kurzmerksatz ==
'''White-Box-Test bedeutet Testen mit Blick in den Code. Ideal für Logik-, Struktur- und Pfadprüfungen.'''
'''White-Box-Test bedeutet Testen mit Blick in den Code. Ideal für Logik-, Struktur- und Pfadprüfungen.'''

Aktuelle Version vom 7. April 2026, 07:19 Uhr

Der White-Box-Test ist ein dynamisches Testverfahren, bei dem der Tester die interne Struktur und den Quellcode des Programms kennt. Im Gegensatz zum Black-Box-Test wird hier gezielt überprüft, ob alle Codepfade, Verzweigungen und internen Abläufe korrekt funktionieren.

Merkmale

  • Tester kennt den Quellcode
  • Fokus auf Programmstruktur und Logik
  • Ziel: maximale Abdeckung interner Wege (Code Coverage)
  • sehr gut für Unit-Tests geeignet

Was wird getestet?

  • Wird jede Zeile Code mindestens einmal ausgeführt?
  • Sind alle Verzweigungen korrekt implementiert?
  • Funktionieren Schleifen, Bedingungen und Ausnahmen richtig?
  • Gibt es toten Code (unerreichbare Bereiche)?

Typische Methoden

Vorteile

  • sehr hohe Testtiefe
  • entdeckt Fehler in der Logik und internen Struktur
  • gute Grundlage für robuste Unit-Tests
  • deckt auch versteckte oder seltene Codepfade auf

Nachteile

  • erfordert Programmierkenntnisse
  • zeitaufwendig bei großen Systemen
  • testet nicht die funktionalen Anforderungen aus Benutzersicht
  • kann blind für fehlende Funktionen sein (wenn etwas gar nicht implementiert wurde)

Kurzmerksatz

White-Box-Test bedeutet Testen mit Blick in den Code. Ideal für Logik-, Struktur- und Pfadprüfungen.