Auch bei 100 Prozent Code Coverage kann eine Anwendung Fehler enthalten. Die Kennzahl zeigt, dass bestimmte Codeelemente oder Entscheidungswege während Tests ausgeführt wurden – nicht, dass die Tests die richtigen Ergebnisse prüfen, alle wichtigen Eingaben berücksichtigen oder sämtliche Anforderungen abdecken.
Was Code Coverage misst – und was nicht
Code Coverage beschreibt, welcher Anteil eines festgelegten Kriteriums während einer Testausführung erreicht wurde. Der Prozentwert ist deshalb nur aussagekräftig, wenn klar ist, welches Kriterium ein Testwerkzeug verwendet. Statement Coverage zählt ausgeführte Anweisungen; Branch- oder Decision Coverage betrachtet mögliche Ergebnisse von Entscheidungen. Werkzeuge und Standards können Begriffe und Details unterschiedlich definieren.
As an Amazon Associate I earn from qualifying purchases.
Google bezeichnet hohe Coverage als notwendige, aber nicht hinreichende Bedingung für gut getesteten Code. Eine ausgeführte Anweisung ist noch kein Beleg dafür, dass ein Test einen Fehler darin erkennt. Google Testing Blog: „TotT: Understanding Your Coverage Data“
Warum 100 Prozent Statement Coverage Zweige offenlassen können
Betrachten Sie dieses Fragment:
if (x == 0) { y = 1; }Ein Test mit x = 0 erreicht die Zuweisung und kann für dieses Fragment 100 Prozent Statement Coverage erzielen. Der alternative Fall x != 0 ist damit nicht automatisch geprüft. Statement Coverage beantwortet, ob die Anweisung ausgeführt wurde; Branch Coverage fragt zusätzlich, ob die möglichen Ergebnisse der Entscheidung – hier wahr und falsch – getestet wurden.
Die ISTQB-Beispielprüfung erläutert diese Abgrenzung: 100 Prozent Statement Coverage garantieren keine 100 Prozent Branch Coverage. ISTQB: Certified Tester Foundation Level
Ausführung allein erkennt keinen Fehler
Ein Test kann eine fehlerhafte Zeile ausführen und trotzdem bestehen. Das passiert etwa, wenn die Eingabe den Fehler nicht auslöst oder der Test das Ergebnis nicht mit einer passenden Erwartung vergleicht.
Ein nicht geprüfter Grenzfall
Bei a = b / c lässt sich die Zeile mit gewöhnlichen Werten ausführen. Ein Test mit c = 0 kann jedoch ein Problem sichtbar machen, das durch den gewöhnlichen Test nicht geprüft wird. Die Zeile zählt bereits als ausgeführt – Coverage unterscheidet nicht von selbst, ob die relevante Eingabe vorkam.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Eine fehlende oder unzureichende Assertion
Selbst wenn der Test einen problematischen Wert erzeugt, muss er den Fehler nicht melden. Ohne eine Assertion, die das erwartete Verhalten kontrolliert, kann ein falsches Ergebnis unentdeckt bleiben. Coverage zählt die Ausführung, nicht die Aussagekraft der Prüfung.
Coverage kann fehlendes Verhalten nicht belegen
Coverage-Werkzeuge messen vorhandenen Code. Sie können nicht zeigen, wie nicht implementierter Code ausgeführt worden wäre. Ein Test, der eine bislang nicht behandelte Fehlerart entdeckt und dafür neuen Code erfordert, erhöht nicht automatisch die Coverage einer zuvor nicht vorhandenen Fehlerbehandlung. Genau darin liegt eine wichtige Grenze: Eine vollständig ausgeführte Implementierung kann trotzdem eine Anforderung oder einen Fehlerfall auslassen.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Wie Sie Coverage sinnvoll für die Testplanung nutzen
Verwenden Sie Coverage als Wegweiser zu nicht erreichten Bereichen, nicht als Qualitätsnachweis. Google warnt davor, möglichst nahe an 100 Prozent zu kommen, wenn das zu falscher Sicherheit oder wartungsintensiven Tests führt. Im Beitrag von 2020 nennt Google 60 Prozent „acceptable“, 75 Prozent „commendable“ und 90 Prozent „exemplary“ als interne Richtwerte. Das sind Googles Richtlinien, keine universellen Branchenstandards und keine Schwellenwerte für Fehlerfreiheit. Google Testing Blog: „Code Coverage Best Practices“
Rank #4
- Tests aus Anforderungen und Risiken ableiten. Bestimmen Sie zuerst, welche fachlichen Erwartungen, Eingabeklassen und Grenzfälle geprüft werden müssen.
- Tests mit überprüfbaren Erwartungen schreiben. Prüfen Sie nicht nur, ob Code läuft, sondern ob Ergebnisse und Nebenwirkungen dem erwarteten Verhalten entsprechen.
- Coverage-Kriterium benennen. Halten Sie fest, ob Ihr Prozentwert Statements, Zweige beziehungsweise Entscheidungen oder ein anderes Kriterium erfasst.
- Coverage-Lücken untersuchen. Fragen Sie, ob nicht ausgeführter Code auf einen fehlenden relevanten Test, unerreichbaren Code oder eine andere erklärbare Ursache hinweist.
- Gezielt ergänzen und neu bewerten. Fügen Sie Tests für konkrete Risiken und Lücken hinzu – nicht bloß, um einen Prozentwert zu erhöhen. Beenden Sie die Ergänzung, wenn weitere Tests keinen angemessenen zusätzlichen Nutzen bringen.
Für die Bewertung eines Tests sind mehrere Fragen hilfreicher als eine einzelne Coverage-Zahl: Welches Strukturkriterium ist erfüllt? Welche Eingaben und Grenzfälle wurden geprüft? Sind die Assertions aussagekräftig? Decken die Tests die fachlichen Anforderungen ab? Und stehen Nutzen, Aufwand und Wartbarkeit zusätzlicher Tests in einem sinnvollen Verhältnis?
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
