Testmethoden: Black-Box und White-Box
Du hast eine Funktion entwickelt, die prüft, ob ein eingegebenes Alter gültig ist. Wie testest du sie? Probierst du einfach ein paar Zahlen aus und hoffst das Beste? Oder gehst du systematisch vor? Professionelles Testen folgt klaren Methoden. Die zwei wichtigsten Grundprinzipien sind Black-Box-Testing und White-Box-Testing – sie unterscheiden sich fundamental darin, ob der Tester weiß, wie die Software intern aufgebaut ist.
1) Black-Box vs. White-Box: Das Grundprinzip
Stell dir eine Kaffeemaschine vor. Beim Black-Box-Test interessiert dich nicht, wie die Maschine intern funktioniert. Du drückst auf Knöpfe und schaust, ob der Kaffee richtig herauskommt – genau das, was ein Nutzer tun würde. Beim White-Box-Test (auch Glas-Box oder Clear-Box genannt) öffnest du die Maschine und schaust, ob jede interne Komponente – Pumpe, Heizstab, Filter – korrekt funktioniert. Du testest die innere Logik, nicht nur das äußere Verhalten.
In der Softwareentwicklung: Black-Box-Tester kennen nur die Anforderungen (Was soll die Software tun?), nicht den Code. White-Box-Tester kennen den Source Code und testen gezielt einzelne Pfade, Schleifen und Bedingungen.
Du weißt nur: Gültige Eingabe = Zahl zwischen 0 und 120. Du testest Eingaben und beobachtest das Ergebnis.
Du kennst den Code. Teste alle drei Zweige gezielt:
2) Black-Box-Testtechniken
Black-Box-Testen hat eigene systematische Techniken, die sicherstellen, dass möglichst viele Fehlerfälle abgedeckt werden – ohne den kompletten Wertebereich durchzuprobieren (was bei einem Textfeld mit Millionen möglichen Eingaben unmöglich wäre).
| Technik | Prinzip | Beispiel |
|---|---|---|
| Äquivalenzklassenanalyse | Eingaben in Gruppen (Klassen) aufteilen, die sich gleich verhalten. Aus jeder Klasse nur einen Repräsentanten testen. | Alter 0–120 gültig: Testfall 25 repräsentiert alle gültigen Werte. Testfall −5 repräsentiert alle negativen Werte. |
| Grenzwertanalyse | Genau an den Grenzen der Äquivalenzklassen testen – dort passieren die meisten Fehler. | Für Alter 0–120: Teste 0, 1, 119, 120, −1, 121 |
| Entscheidungstabellen | Alle Kombinationen von Eingabebedingungen und ihre erwarteten Ergebnisse tabellarisch erfassen. | Login: Korrekte E-Mail + korrektes Passwort → Zugang. Falsche E-Mail + beliebiges Passwort → Fehler. Usw. |
| Zustandsbasiertes Testen | Das System hat verschiedene Zustände – teste alle Zustandsübergänge. | Bestellsystem: Neu → Bezahlt → Versendet → Geliefert. Alle Übergänge und ungültige Übergänge testen. |
3) White-Box-Testtechniken
White-Box-Tests messen die Testabdeckung (Coverage) – wie viel Prozent des Codes wurde durch die Tests tatsächlich ausgeführt? Je höher die Abdeckung, desto wahrscheinlicher, dass versteckte Fehler gefunden werden.
| Technik | Was wird gemessen | Ziel |
|---|---|---|
| Anweisungsüberdeckung (C0) | Jede Anweisung im Code mindestens einmal ausgeführt | 100 % C0: Kein toter Code – alle Zeilen wurden getestet |
| Zweigüberdeckung (C1) | Jeder Zweig jeder Bedingung (true und false) mindestens einmal ausgeführt | Stärker als C0 – deckt auch if-else-Pfade ab |
| Pfadüberdeckung (C2) | Alle möglichen Pfade durch den Code getestet | Vollständig, aber bei Schleifen oft unrealistisch |
4) Wann welche Methode?
In der Praxis werden beide Methoden kombiniert. Black-Box-Tests stellen sicher, dass die Software das tut, was der Nutzer erwartet. White-Box-Tests stellen sicher, dass keine interne Logik kaputt ist. Für automatisierte Tests in der CI/CD-Pipeline werden vor allem White-Box-Tests (Unit Tests) eingesetzt – sie laufen schnell und prüfen präzise. Black-Box-Tests werden häufig manuell oder als Integrations- und Systemtests durchgeführt.
| Black-Box | White-Box | |
|---|---|---|
| Tester kennt Code? | Nein | Ja |
| Basis | Anforderungen / Spezifikation | Source Code / Implementierung |
| Findet | Fehlende Funktionen, falsche Ausgaben | Logikfehler, toten Code, falsche Pfade |
| Kann nicht finden | Interne Logikfehler ohne äußere Auswirkung | Fehlende Anforderungen |
| Typischer Einsatz | System- und Abnahmetests | Unit Tests, Code Reviews |
Zusammenfassung
Black-Box-Testing prüft Software aus Nutzersicht – ohne Kenntnisse des internen Codes. Techniken sind Äquivalenzklassenanalyse, Grenzwertanalyse, Entscheidungstabellen und zustandsbasiertes Testen. White-Box-Testing prüft die interne Logik – der Tester kennt den Code und misst die Testabdeckung (C0 Anweisung, C1 Zweig, C2 Pfad). Beide Methoden ergänzen sich: Black-Box prüft das Was, White-Box das Wie. In der Praxis werden beide kombiniert und in Testprotokollen dokumentiert.