Zum Inhalt springen
SDETRole
SDETRole

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.

Tippen Sie, um SDETRole zu durchsuchen.

Volltextsuche mit Pagefind · läuft in Ihrem Browser Suchseite öffnen →