Katalog
method#Qualitätssicherung#Software-Engineering#Zuverlässigkeit

White Box Testing

Testmethode, die interne Implementierung und Codepfade gezielt prüft, um Fehlerquellen früh zu finden.

White-Box-Testing ist eine Testmethode, bei der interne Strukturen, Implementierungen und Programmlogik gezielt geprüft werden.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Design
  • Fortgeschritten

Technischer Kontext

CI/CD-Systeme (z. B. Jenkins, GitHub Actions)Unit-Test-Frameworks (z. B. JUnit, pytest)Code-Coverage-Tools (z. B. JaCoCo, Coverage.py)

Prinzipien & Ziele

Tests sollten interne Pfade und Bedingungen explizit adressieren.Automatisierung und Integration in CI erhöhen Reaktionsgeschwindigkeit.Kombination von white-box und black-box erhöht Gesamtnutzen.
Umsetzung
Team, Domäne

Use Cases & Szenarien

Kompromisse

  • Fokus auf Implementation statt Anforderungen kann falsche Priorisierung erzeugen.
  • Unzureichende Tests bei mangelhafter Pfadauswahl.
  • Hoher Wartungsaufwand bei häufigen Code-Änderungen.
  • Fokus auf kritische und risikobehaftete Pfade.
  • Kombination von statischer Analyse und dynamischen Tests.
  • Automatisierte Ausführung in der CI-Pipeline.

I/O & Ressourcen

  • Quellcode und Implementierungsdetails
  • Zugriff auf Testinfrastruktur (CI)
  • Anforderungen und Schnittstellenspezifikationen
  • Automatisierte Testfälle mit Pfaddefinitionen
  • Berichte zur Abdeckung und gefundenen Fehlern
  • Empfehlungen für Codeverbesserungen

Beschreibung

White-Box-Testing ist eine Testmethode, bei der interne Strukturen, Implementierungen und Programmlogik gezielt geprüft werden. Entwickler oder Tester nutzen Kenntnis des Codes, um Testfälle granular zu entwerfen und Pfade, Bedingungen sowie Datenflüsse abzudecken. Geeignet für Unit- und Integrationslevel, liefert schnellen Fehlerfeedback.

✔

  • Frühe Fehlererkennung im Implementierungsstadium.
  • Gezielte Abdeckung komplexer Kontrollflüsse.
  • Fundament für Regressionstests nach Änderungen.

✖

  • Bindet Entwicklerkapazität und detailliertes Codewissen.
  • Kann Architekturfehler übersehen, wenn nur Implementierungsdetails betrachtet werden.
  • Skalierung auf große Systeme erfordert Selektionsstrategien.

  • Code-Pfad-Abdeckung

    Misst den Anteil der ausgeführten Codepfade durch Tests.

  • Fehlerentdeckungsrate pro Testlauf

    Anzahl gefundener Fehler pro automatischem Testlauf.

  • Wartungsaufwand für Tests

    Zeitaufwand zur Anpassung von Tests nach Codeänderungen.

Unit-Tests einer Parser-Komponente

Testfälle prüfen verschiedene Eingabeszenarien und Bedingungszweige im Parser.

Pfadabdeckung in Authentifizierungslogik

Überprüfung aller Entscheidungszweige für Login, Token-Handling und Fehlerzustände.

Grenzfalltests für numerische Berechnungen

Gezielte Tests für Überlauf, Genauigkeitsgrenzen und spezielle Eingabewerte.

1

Identifikation kritischer Module und Pfade.

2

Entwurf granularer Testfälle für Bedingungen und Grenzfälle.

3

Automatisierung der Tests und Integration in CI.

4

Regelmäßige Überprüfung und Anpassung der Test-Suite.

⚠️ Technische Schulden & Engpässe

  • Alte Tests mit enger Kopplung an veraltete Implementierungen.
  • Unzureichende Testinfrastruktur für schnelle Ausführung.
  • Fehlende Testdatenverwaltung für deterministische Tests.
Komplexe KontrollflüsseFehlende ModularisierungMangelnde Testinfrastruktur
  • Schreiben von Tests, die jede interne Variable fest codieren.
  • Ausschließliche Abhängigkeit von white-box Tests ohne Systemtests.
  • Verwendung von White-Box-Tests zur Kompensation fehlender Anforderungen.
  • Unterschätzung des Wartungsaufwands bei häufiger Refaktorierung.
  • Falsche Annahme, dass hohe Pfadabdeckung alle Fehler verhindert.
  • Mangelnde Abstimmung mit Anforderungsseite führt zu irrelevanten Tests.
Gute Kenntnisse der Programmiersprache und ArchitekturErfahrung im Testdesign und mit TestframeworksVerständnis von Kontrollfluss- und Datenflussanalysen
Testbarkeit des CodesModularität und Trennung von VerantwortlichkeitenAutomatisierungsfähigkeit in CI/CD
  • • Zeitliche Begrenzungen im Sprint
  • • Begrenzte Ressourcen für umfangreiche Tests
  • • Privilegien für Zugriff auf Quellcode nötig