White-Box-Test: Zweig- und Pfadüberdeckung

In L3 hast du Black-Box-Tests kennengelernt – Tests, die das System nur über seine Schnittstelle prüfen. Diese Lektion zeigt das Gegenstück: White-Box-Tests. Hier hast du den Quellcode vor dir und entwirfst Tests basierend auf der Code-Struktur. Ziel: jede Anweisung, jeden Zweig, jeden Pfad mindestens einmal durchlaufen.

Dies ist ein klassisches IHK-Klausur-Thema: Überdeckungsmaße C0, C1, C2 berechnen, Kontrollflussgraphen zeichnen, Testfälle dafür ableiten. Wer das mechanisch beherrscht, holt sichere Punkte.

1) Black-Box vs. White-Box – die Perspektive umkehren

Zwei Test-Perspektiven im Vergleich

Black-Box

Sicht: von außen, kennt Spezifikation

Basis: Anforderungen, Use-Cases

Wer: QA, Tester, Kunde

Stufen: System, Abnahme

Findet: fehlende Features, falsche Outputs

Übersieht: toten Code, unerreichbare Zweige

White-Box

Sicht: von innen, kennt den Code

Basis: Quellcode, Kontrollfluss

Wer: Entwickler

Stufe: Unit-Test (siehe L6)

Findet: alle Code-Pfade, tote Codestellen

Übersieht: fehlende, in Spec geforderte Funktionen

Beide Ansätze ergänzen sich. Black-Box prüft ob die richtige Funktion da ist, White-Box prüft wie sie intern arbeitet. In professionellen Projekten laufen beide parallel – auf unterschiedlichen Stufen.

2) Konkreter Code als Lauf-Beispiel

Damit wir gemeinsam rechnen können, hier eine einfache Funktion. Sie klassifiziert eine Zahl als „positiv", „negativ" oder „null":

Beispielcode für die Überdeckungs-Berechnung

1function klassifiziere(x) { 2 if (x > 0) { 3 return "positiv"; 4 } else if (x < 0) { 5 return "negativ"; 6 } else { 7 return "null"; 8 } 9}

Drei Verzweigungen, drei mögliche Rückgabewerte. Sieht trivial aus – aber genau bei solchen Beispielen lernt man die Überdeckungsmaße sauber. In echten Codebases wird das schnell komplex (verschachtelte if-else, Schleifen, switch-case).

3) Kontrollflussgraph zeichnen

Der erste Schritt im White-Box-Test: den Code als Kontrollflussgraph (CFG) visualisieren. Knoten = Anweisungen oder Bedingungen, Kanten = mögliche Übergänge:

Kontrollflussgraph für unsere Beispielfunktion

Der Graph zeigt: zwei Verzweigungs-Knoten (Raute), drei Anweisungs-Knoten (Rechteck), Start- und End-Knoten. Vom Start gehen drei mögliche Pfade zum Ende: über „positiv", „negativ", oder „null". Das ist die Basis für alle Überdeckungs-Maße.

4) Die Überdeckungsmaße C0, C1, C2

Es gibt verschiedene Kriterien, wie „vollständig" man testet. Sie bauen aufeinander auf – jedes höhere ist strenger als das vorherige:

Überdeckungsmaße (Coverage-Kriterien)

C0: Anweisungsüberdeckung

Statement Coverage – jede Code-Zeile mindestens einmal

Jede ausführbare Anweisung wird mindestens einmal durchlaufen. Schwächstes Kriterium. Für unser Beispiel: 3 Tests, weil jeder Pfad zu einer anderen Anweisung führt – x = 5 (positiv), x = -3 (negativ), x = 0 (null). Dieselben 3 Tests reichen hier zufällig für C0.

C0 = ausgeführte Anweisungen / alle Anweisungen × 100 %

Wichtiger Klausur-Trick: C1 erfordert automatisch C0 (wer alle Zweige durchläuft, durchläuft auch alle Anweisungen). C2 erfordert C1. Aber: 100 % C0 garantiert nicht 100 % C1! Beispiel: if (a) anweisung; – ein Test mit a=true deckt die einzige Anweisung ab (C0 = 100 %), aber nicht den false-Zweig (C1 nur 50 %).

5) C0 – Anweisungsüberdeckung berechnen

Schauen wir konkret in unser Beispiel: 3 Anweisungen (return "positiv", return "negativ", return "null"). Mit den drei Tests x=5, x=-3, x=0 werden alle drei Returns durchlaufen → C0 = 100 %.

Mit nur zwei Tests, z.B. x=5 und x=-3, würde die return "null"-Anweisung nie ausgeführt → C0 = 2/3 = 67 %. In großen Projekten ist C0 das Mindestmaß, das man fordert (typische Schwelle: 80 %).

6) C1 – Zweigüberdeckung

Strenger als C0: jeder Zweig in jeder Verzweigung muss durchlaufen werden. Bei einer if-Bedingung also true-Zweig und false-Zweig. In unserem Beispiel: zwei if-Bedingungen, jede mit true/false → 4 Zweige.

Mit den Tests x=5, x=-3, x=0 sieht es so aus:

x=5: erste Bedingung true → der true-Zweig der ersten if. ✓
x=-3: erste Bedingung false (✓), zweite true (✓)
x=0: erste false (✓), zweite false (✓)

Alle vier Zweige getroffen → C1 = 100 %. Hier reichen also dieselben drei Tests, weil unser Code linear strukturiert ist. Bei verschachtelten Bedingungen wäre das anders.

7) C2 – Pfadüberdeckung

Noch strenger: jeder mögliche Pfad durch den Kontrollflussgraphen muss durchlaufen werden. In unserem Beispiel gibt es 3 Pfade (Start → positiv → Ende, Start → negativ → Ende, Start → null → Ende). Auch hier reichen unsere 3 Tests.

Aber Achtung: bei Schleifen wird C2 schnell unmöglich. Eine for-Schleife mit n möglichen Iterationen erzeugt n+1 verschiedene Pfade. Bei verschachtelten Schleifen explodiert die Zahl exponentiell. In der Praxis fordert man C2 nur für sicherheitskritische Teile (Medizin, Avionik). C1 = 100 % ist das praktische Maximum für die meisten Projekte.

8) Bedingungsüberdeckung

Eine vierte Stufe, die in Klausuren gerne abgefragt wird: Bedingungsüberdeckung. Sie ist relevant, wenn eine Bedingung aus mehreren Teilbedingungen besteht, etwa if (a > 0 && b < 10). Hier reicht es nicht, einfach true/false der Gesamtbedingung zu testen – auch jede Teilbedingung muss in beiden Wahrheitswerten getestet werden.

Beispiel: für if (a > 0 && b < 10) bräuchte man mindestens Tests für: a>0=true mit b<10=true, a>0=true mit b<10=false, a>0=false (Kurzschluss-Auswertung – b wird nicht mehr geprüft). Die strengste Variante (Modified Condition / Decision Coverage, MC/DC) ist in Avionik (DO-178B) und Automotive (ISO 26262) Pflicht.

9) Tools zur Coverage-Messung

Niemand zählt Coverage von Hand – das machen Tools:

Java: JaCoCo (in Maven/Gradle eingebaut), Cobertura.
Python: coverage.py, pytest-cov.
JavaScript: Istanbul / nyc, eingebaut in Jest, Vitest.
C/C++: gcov, lcov.
.NET: Coverlet, dotCover.

Sie laufen mit den Unit-Tests (vgl. L6) und produzieren HTML-Reports, die zeilen-genau zeigen, was wann durchlaufen wurde – oder eben nicht.

10) Grenzen von White-Box

White-Box ist mächtig, hat aber Grenzen:

100 % Coverage ≠ fehlerfrei. Code kann alle Pfade abdecken und trotzdem die falsche Logik haben – wenn die Anforderungen schon falsch sind, hilft auch perfekte Coverage nicht.
Fehlende Funktionen unentdeckt. Wenn in der Spec ein Feature gefordert wird, das gar nicht implementiert ist, kann White-Box es nicht finden – Code, der nicht existiert, hat keine Coverage.
Konzentration auf Implementierungs-Details. Tests werden brüchig, wenn der Code refactored wird, auch wenn Funktionalität gleich bleibt.

Deshalb: White-Box ergänzt Black-Box, ersetzt es nicht. Eine Test-Strategie braucht beide Perspektiven.

11) Verbindung zu UML

Kontrollflussgraphen sind nahe verwandt mit UML-Aktivitätsdiagrammen. Wer Klausuren mit Aktivitätsdiagrammen kann, kommt auch mit White-Box-Aufgaben klar – die Notation ähnelt sich, die Logik (Entscheidungen, Verzweigungen) ist identisch.

12) Klausur-Highlights

C0 Anweisung = jede Zeile mindestens einmal.
C1 Zweig = jeder if-true und if-false. Praxis-Standard.
C2 Pfad = jede mögliche Pfad-Kombination. Bei Schleifen explosiv.
Bedingungsüberdeckung für zusammengesetzte Bedingungen.
C1 = 100 % ≠ C2 = 100 %. Hierarchie kennen!
100 % Coverage garantiert keine Korrektheit.

Zusammenfassung

White-Box-Test: Tests basierend auf Code-Struktur, typisch im Unit-Test. Kontrollflussgraph visualisiert Anweisungen und Verzweigungen. Überdeckungs-Hierarchie: C0 (Anweisungen), C1 (Zweige – Praxis-Standard, ≥80%), C2 (alle Pfade – bei Schleifen explosiv). C2 ⊃ C1 ⊃ C0. Aber: 100% Coverage ≠ Fehlerfreiheit. Tools: JaCoCo, coverage.py, Istanbul. Black-Box + White-Box ergänzen sich. Nächste: TDD.