Glossar · Testgrundlagen
White-Box-Test
Englisch: White-box testing
Auch genannt: White-Box-Testing, Glass-Box-Test, strukturbasierter Test, Strukturtest
Definition
Tests, die aus Kenntnis des internen Codes entworfen werden, etwa seiner Zweige, Bedingungen und Pfade, um das korrekte Verhalten der Implementierung sicherzustellen.
Beim White-Box-Test entstehen die Tests durch das Lesen des Codes. Der Tester (oft der Entwickler) betrachtet Zweige, Bedingungen, Schleifen und Fehlerbehandlung und schreibt Tests, die diese gezielt durchlaufen. Er wird auch Glass-Box-, Clear-Box- oder strukturbasierter Test genannt. Unit-Tests sind die häufigste Form, und die Codeabdeckung ist das übliche Maß dafür.
Beispiel
String grade(int score) {
if (score < 0 || score > 100) {
throw new IllegalArgumentException("score out of range");
}
if (score >= 50) {
return "PASS";
}
return "FAIL";
}
Beim Lesen des Codes sehen Sie drei Ergebnisse (Exception, PASS, FAIL), und das erste if hat zwei getrennte Bedingungen, die jeweils die Exception auslösen können. Aus der Struktur gewählte Tests:
| Eingabe | Durchlaufener Pfad |
|---|---|
| -1 | score < 0 wahr, Exception |
| 101 | score > 100 wahr, Exception |
| 50 | im Wertebereich, score >= 50 wahr, PASS |
| 49 | im Wertebereich, score >= 50 falsch, FAIL |
Diese Tests ergeben vollständige Zweig- und Bedingungsabdeckung. Genau 50 und 49 zu testen findet außerdem ein >=, das versehentlich als > geschrieben wurde.
White-Box- vs. Black-Box-Test
White-Box fragt „Verhält sich jeder Pfad in diesem Code korrekt?“ und benötigt den Quellcode. Black-Box fragt „Tut das System, was die Anforderungen sagen?“ und benötigt nur die Spezifikation. White-Box findet ungetestete Pfade, toten Code und Logikfehler in Zweigen. Black-Box findet fehlende Features und Verhalten, das den Anforderungen widerspricht. Das kann White-Box nicht sehen, denn für ein fehlendes Feature gibt es keinen Code. Gute Suites nutzen beides.
Grenzen
- Tests können die Fehler des Codes übernehmen. Hat der Entwickler die Anforderung missverstanden, bestätigen aus dem Code abgeleitete Tests das falsche Verhalten.
- Enge Kopplung. Tests, die von privaten Methoden oder der internen Struktur abhängen, brechen bei jedem Refactoring, selbst wenn das Verhalten unverändert ist. Testen Sie wo möglich über öffentliche Schnittstellen.
- Abdeckung ist nicht Korrektheit. Dass jeder Zweig ausgeführt wird, sagt nichts darüber aus, ob die Assertions aussagekräftig sind.