Ein Team feiert 100% Code Coverage – und wenige Wochen später meldet die Produktion denselben kritischen Bug, den niemand bemerkt hat. Wie passt das zusammen? Coverage misst, welche Zeilen Ihre Tests ausführen, nicht ob diese Tests sinnvoll prüfen. Eine Zeile kann ausgeführt werden, ohne dass eine einzige Assertion ihr Verhalten kontrolliert. Genau hier trennen sich nützliche Messung und gefährliche Selbsttäuschung. Dieser Artikel erklärt den Unterschied zwischen Code Coverage, Testabdeckung und Anforderungsabdeckung, zeigt die wichtigsten Kriterien und beantwortet die Frage, welche Quote für Ihr Projekt wirklich sinnvoll ist. Für tiefere Grundlagen lohnt der Blick in unsere Pillar-Übersicht.

TL;DR: Code Coverage zeigt, welche Codezeilen ausgeführt wurden – nicht, ob sie korrekt getestet sind. Google bezeichnet 75% als solide und 90% als vorbildlich (Google Testing Blog, 2020), schreibt aber keine feste Quote vor. Nutzen Sie Coverage, um ungetesteten Code zu finden, nicht als Qualitätsbeweis. Mutation Testing liefert ein stärkeres Signal.

Abbildung 1: Ausgeführt heißt nicht geprüft – Code Coverage misst Reichweite, nicht Qualität.

Was unterscheidet Testabdeckung, Code Coverage und Anforderungsabdeckung?

Das ISTQB definiert Coverage als den Grad in Prozent, zu dem ein festgelegtes Coverage-Element durch eine Testsuite abgedeckt wird – das kann Code, eine Anforderung oder ein Risiko sein (ISTQB Glossary, o. J.). Coverage ist also ein Oberbegriff. Die konkrete Bedeutung hängt vom gemessenen Element ab.

Code Coverage beantwortet eine sehr enge Frage: *Wurde diese Codezeile beim Testlauf ausgeführt?* Das ISTQB beschreibt sie als Analysemethode, die bestimmt, welche Teile der Software durch die Testsuite ausgeführt wurden – etwa auf Anweisungs-, Entscheidungs- oder Bedingungsebene (ISTQB Glossary, o. J.). Sie sagt nichts darüber, ob das Ergebnis geprüft wurde.

Anforderungsabdeckung fragt etwas völlig anderes: *Wird diese Anforderung überhaupt durch mindestens einen Test geprüft?* Eine hohe Code Coverage kann mit lückenhafter Anforderungsabdeckung koexistieren. Sie testen vielleicht jede Zeile, aber kein Test prüft die wichtigste Geschäftsregel.

In der Praxis sehen wir das Missverständnis fast immer in dieselbe Richtung: Teams behandeln Code Coverage als Stellvertreter für Testqualität. Tatsächlich misst sie nur die Reichweite der Ausführung. Drei Projekte mit identischen 85% können völlig unterschiedlich gut getestet sein.

Code Coverage misst laut ISTQB, welche Codeteile durch die Tests ausgeführt wurden (ISTQB Glossary, o. J.). Anforderungsabdeckung prüft dagegen, ob jede Anforderung getestet wird. Beide ergänzen sich – keine ersetzt die andere.

Mehr zu sauberen Testfällen finden Sie in unserem Beitrag zum Unit-Test.

Welche Code-Coverage-Kriterien gibt es?

Abbildung 2: Die fünf Coverage-Kriterien von schwach (C0) bis streng (Path).

Coverage-Kriterien unterscheiden sich darin, wie streng sie den Code durchdringen – von einfacher Zeilenausführung bis zur Prüfung jeder logischen Bedingung. 100% Branch Coverage impliziert automatisch 100% Statement Coverage, aber nicht umgekehrt (ISTQB Glossary, o. J.). Die folgende Tabelle ordnet die fünf gängigen Kriterien ein.

Statement Coverage ist das schwächste Maß. Eine Bedingung wie `if (a && b)` gilt schon als abgedeckt, wenn nur ein einziger Wert sie auslöst. Branch Coverage verlangt dagegen, dass jeder Verzweigungsausgang einmal genommen wird – deutlich strenger.

MC/DC verdient besondere Aufmerksamkeit. Sie verlangt, dass jede einzelne Bedingung das Gesamtergebnis unabhängig von den anderen beeinflussen kann. Verifysoft beschreibt MC/DC als das Kriterium, das für entscheidungslastigen, sicherheitskritischen Code gefordert wird (Verifysoft, o. J.). Für n Bedingungen reichen meist etwa n+1 Tests – effizient und doch sehr aussagekräftig.

100% Entscheidungsüberdeckung (C1) schließt 100% Anweisungsüberdeckung (C0) ein, aber nicht umgekehrt (ISTQB Glossary, o. J.). Wer Branch Coverage misst, deckt Statement Coverage automatisch ab – ein Grund, C0 selten isoliert zu reporten.

Warum ist 100% Coverage kein Qualitätsbeweis?

100% Code Coverage beweist nur, dass jede Zeile lief – nicht, dass sie richtig getestet wurde. Martin Fowler hält Coverage für nützlich, um ungetesteten Code zu finden, aber “von geringem Wert als Zahlenaussage darüber, wie gut Ihre Tests sind” (martinfowler.com, 2012). Eine Kennzahl, die kein Verhalten prüft, sagt wenig über echte Qualität.

Das ist ein klassischer Fall von Goodharts Gesetz: Sobald eine Messgröße zum Ziel wird, hört sie auf, eine gute Messgröße zu sein. Fowler formuliert es direkt: Macht man ein bestimmtes Coverage-Niveau zum Ziel, versuchen Menschen es zu erreichen – und “hohe Coverage-Zahlen sind mit minderwertigem Testen zu leicht zu erreichen” (martinfowler.com, 2012).

Wir haben Testsuites gesehen, die ohne eine einzige Assertion auf 95% kamen. Die Tests riefen Methoden auf, fingen Exceptions ab und prüften nie ein Ergebnis. Die Zahl glänzte im Dashboard. Der Schutz war praktisch null.

Die Lehre ist nicht, Coverage zu ignorieren, sondern sie richtig zu lesen. Niedrige Coverage ist ein verlässliches Warnsignal: Dieser Code ist ungetestet. Hohe Coverage ist dagegen kein Beweis – nur eine notwendige, keine hinreichende Bedingung. Unser Beitrag zum Regressionstest zeigt, wie sich das im laufenden Betrieb auswirkt.

Welche Coverage-Quote ist wirklich sinnvoll?

Abbildung 4: Coverage-Richtwerte – 60 % akzeptabel, 75 % solide, 90 % vorbildlich (Google, 2020).

Es gibt keine universell richtige Zahl, aber etablierte Richtwerte. Google nennt 60% als akzeptabel, 75% als lobenswert und 90% als vorbildlich – und schreibt bewusst keine organisationsweite Pflichtquote vor, weil das eine “geschäftliche Entscheidung” sei (Google Testing Blog, 2020). Die Schwelle hängt vom Risiko des Codes ab, nicht von einem starren Ideal.

Martin Fowler ist in derselben Größenordnung unterwegs. Er erwartet bei gut getestetem Code Werte “in den oberen 80ern oder 90ern” und zeigt sich ausdrücklich misstrauisch gegenüber allem, was Richtung 100% geht (martinfowler.com, 2012). Der Sprung von 90% auf 100% kostet oft mehr, als er einbringt.

Sinnvoll ist eine differenzierte Betrachtung:

• Risikobasiert priorisieren: Kritische Geschäftslogik verdient höhere Abdeckung als triviale Getter.

• Trend statt Absolutwert: Sinkende Coverage bei neuem Code ist alarmierender als ein stabiler Gesamtwert.

• Coverage-Gates moderat setzen: Verhindern Sie Rückschritte, statt willkürliche 100% zu erzwingen.

• Qualität der Assertions prüfen: Eine Zeile ohne Prüfung ist nicht getestet, nur ausgeführt.

Google formuliert es nüchtern: Coverage “garantiert nicht, dass die abgedeckten Zeilen korrekt getestet wurden, nur dass sie ausgeführt wurden” (Google Testing Blog, 2020).

Google empfiehlt 60% als akzeptabel, 75% als lobenswert, 90% als vorbildlich und verzichtet bewusst auf eine feste Pflichtquote (Google Testing Blog, 2020). Die richtige Schwelle ist risikobasiert, nicht universell.

Warum ist Mutation Testing ein stärkeres Signal?

Abbildung 3: 73 % der echten Fehler sind an Mutanten gekoppelt – Mutation Testing schlägt Code Coverage (Just et al., FSE 2014).

Mutation Testing prüft, ob Ihre Tests Fehler tatsächlich entdecken würden – ein deutlich härteres Kriterium als bloße Ausführung. Eine Studie von Just et al. zeigte, dass die Erkennung von Mutanten stärker mit der Erkennung echter Fehler korreliert als Statement- oder Branch-Coverage; 73% der realen Fehler waren an mindestens einen Mutanten gekoppelt (Just et al., FSE 2014, 2014).

Die Idee ist einfach. Ein Werkzeug verändert den Code minimal – aus `>` wird `>=`, aus `+` wird `-`. Diese Mutanten sollten Ihre Tests rot werden lassen. Bleibt ein Mutant unentdeckt, fehlt eine Assertion. Mutation Testing misst also Wirksamkeit, nicht nur Reichweite.

Der Ansatz ist praxistauglich. Google hat Mutation Testing für rund 6.000 Entwickler im Code-Review-Prozess ausgerollt (Google Research, 2018). Statt die gesamte Codebasis zu mutieren, zeigt das System gezielt überlebende Mutanten in geänderten Zeilen – genau dort, wo Reviewer sie bewerten können.

Wir betrachten Mutation Testing als logische Antwort auf das Goodhart-Problem. Coverage lässt sich vortäuschen, indem man Code ausführt, ohne zu prüfen. Einen überlebenden Mutanten kann man nicht wegtäuschen – er beweist, dass eine echte Verhaltensänderung unbemerkt blieb. Mehr dazu im Leitfaden zur KI-Testautomatisierung.

Wo schreiben regulierte Branchen bestimmte Coverage vor?

In sicherheitskritischen Domänen ist Coverage keine Empfehlung, sondern Vorschrift – mit MC/DC als Goldstandard. Für Luftfahrtsoftware der höchsten Kritikalität verlangt DO-178C Level A nachweislich MC/DC (LDRA, o. J.). Hier geht es nicht um Dashboards, sondern um Zulassung und Menschenleben.

In der Automobilindustrie gilt Ähnliches. Für ASIL D, die höchste Sicherheitsstufe nach ISO 26262, wird MC/DC dringend empfohlen (Parasoft, o. J.). Der Grund ist genau die Schwäche schwächerer Kriterien: Statement Coverage kann komplexe Bedingungen durchwinken, ohne deren Logik je vollständig zu prüfen.

Diese Anforderungen zeigen, dass die Wahl des Kriteriums vom Risiko abhängt. Eine Marketing-Website braucht kein MC/DC. Ein Bremssteuergerät schon. Für die meisten Geschäftsanwendungen liegt der sinnvolle Bereich zwischen solider Branch Coverage und gezieltem Mutation Testing für kritische Pfade. Wer einen strukturierten Einstieg sucht, findet ihn in unserem Testplan-Beitrag.

DO-178C Level A fordert für die kritischste Avionik-Software MC/DC (LDRA, o. J.); ISO 26262 empfiehlt MC/DC dringend für die höchste Automotive-Stufe ASIL D (Parasoft, o. J.). Das Kriterium richtet sich nach dem Risiko.

Häufige Fragen zu Code Coverage und Testabdeckung

Ist 100% Code Coverage erstrebenswert?

Selten. Martin Fowler zeigt sich misstrauisch gegenüber allem nahe 100% und erwartet bei gutem Code eher Werte in den oberen 80ern oder 90ern (martinfowler.com, 2012). Der letzte Sprung kostet meist mehr Aufwand, als er an echtem Schutz bringt. Investieren Sie die Zeit lieber in bessere Assertions.

Was ist der Unterschied zwischen Statement und Branch Coverage?

Statement Coverage (C0) prüft, ob jede Anweisung ausgeführt wurde. Branch Coverage (C1) verlangt, dass jeder Verzweigungsausgang durchlaufen wird. 100% Branch Coverage schließt 100% Statement Coverage automatisch ein, aber nicht umgekehrt (ISTQB Glossary, o. J.). Branch ist daher die aussagekräftigere Standardmetrik.

Ersetzt Mutation Testing die Code Coverage?

Nein, es ergänzt sie. Coverage findet ungetesteten Code; Mutation Testing prüft, ob vorhandene Tests Fehler erkennen. Mutantenerkennung korreliert stärker mit echter Fehlererkennung als Coverage-Metriken (Just et al., FSE 2014, 2014). Beide zusammen ergeben ein vollständigeres Bild der Testqualität.

Welche Coverage-Quote sollte mein Team anstreben?

Es gibt keine Pflichtzahl. Google nennt 75% als solide und 90% als vorbildlich, betont aber, dass die Schwelle eine geschäftliche Entscheidung ist (Google Testing Blog, 2020). Priorisieren Sie risikobasiert: hohe Abdeckung für kritische Logik, weniger für triviale Pfade. Mehr im Testplan-Beitrag.

Warum kann hohe Coverage trügerisch sein?

Weil Ausführung nicht gleich Prüfung ist. Ein Test kann eine Zeile durchlaufen, ohne ihr Ergebnis mit einer Assertion zu kontrollieren. Coverage “garantiert nicht, dass die abgedeckten Zeilen korrekt getestet wurden, nur dass sie ausgeführt wurden” (Google Testing Blog, 2020). Genau hier entstehen falsche Sicherheit und übersehene Bugs.

Fazit

Code Coverage ist ein nützliches Werkzeug mit einem engen Auftrag: Sie findet ungetesteten Code. Sie beweist nicht, dass Ihre Tests gut sind. Behandeln Sie sie als Warnsignal, nicht als Erfolgsmedaille. Die belastbaren Richtwerte – Google nennt 75% solide, Fowler erwartet 80-90% – sind Orientierung, kein Selbstzweck. Wer Qualität wirklich messen will, ergänzt Coverage um Anforderungsabdeckung und, wo es zählt, um Mutation Testing. In regulierten Branchen wird aus der Empfehlung eine Pflicht mit MC/DC. Der gemeinsame Nenner: Messen Sie, was Verhalten prüft, nicht nur, was ausgeführt wird.

Möchten Sie Ihre Testabdeckung mit KI-gestützter Automatisierung aussagekräftiger machen? Sehen Sie sich den AI Recorder an oder sprechen Sie mit uns.