Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Nein: 100 Prozent Code Coverage garantieren keine fehlerfreie Software. Der Wert zeigt, dass Code nach einem bestimmten Coverage-Kriterium während der Tests ausgeführt wurde. Er beweist nicht, dass die Tests alle wichtigen Eingaben prüfen, falsche Ergebnisse erkennen oder sämtliche fachlichen Anforderungen abdecken.
Was bedeutet 100 Prozent Code Coverage?
Code Coverage, auf Deutsch Code- oder Testabdeckung, misst, welche Teile des Programmcodes während einer Testsuite ausgeführt wurden. Die Bedeutung eines Prozentwerts hängt davon ab, welches Kriterium das verwendete Werkzeug misst. „100 Prozent Coverage“ ist deshalb ohne diese Angabe unvollständig.
Statement Coverage
Statement Coverage erfasst, ob jede ausführbare Anweisung mindestens einmal erreicht wurde. Ein Test kann eine Zeile also abdecken, ohne damit alle möglichen Wege durch das Programm zu prüfen.
Recommended Free Tools
Branch- oder Decision Coverage
Branch Coverage prüft, ob die möglichen Ergebnisse einer Entscheidung – etwa wahr und falsch – jeweils durch Tests erreicht wurden. Begriffe und genaue Zählweise können je nach Standard und Werkzeug variieren. Googles Erklärung zur Coverage grenzt Statement Coverage als verbreitetes, intuitives Maß von der Abdeckung möglicher Ausführungspfade ab: Google Testing Blog: Understanding Your Coverage Data.
Wie können 100 Prozent Statement Coverage einen Fall übersehen?
Betrachte dieses Beispiel:
if (x == 0) {
y = 1;
}Ein Test mit x = 0 führt die Zuweisung aus. Für dieses Fragment kann er damit 100 Prozent Statement Coverage erreichen. Er prüft aber nicht automatisch den alternativen Fall x != 0. Die ISTQB-Beispielprüfung veranschaulicht, dass vollständige Statement Coverage keine vollständige Branch Coverage garantiert: ISTQB Foundation Level – Beispielprüfung.
Die Abdeckung sagt zudem nur etwas über vorhandenen Code aus. Sie kann nicht zeigen, was nicht geschriebener Code getan hätte. Google beschreibt etwa eine nicht behandelte Fehlerart: Ein Test, der diesen Fehler aufdeckt, führt unter Umständen keinen zusätzlichen vorhandenen Code aus und erhöht daher den Coverage-Wert nicht.
Warum kann ein ausgeführter Fehler unentdeckt bleiben?
Ausführung ist nicht dasselbe wie Fehlererkennung. Eine Zeile kann im Test laufen, ohne dass der Test den problematischen Eingabefall erreicht oder das Ergebnis mit einer passenden Erwartung vergleicht.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Zum Beispiel kann die Anweisung a = b / c mit gewöhnlichen Werten ausgeführt werden. Das deckt die Zeile ab, prüft aber nicht, was bei c = 0 geschieht. Und selbst wenn ein Test die Zeile ausführt, erkennt er einen falschen Wert nur, wenn er das Ergebnis sinnvoll überprüft – etwa mit einer Assertion, die den erwarteten Wert oder das erwartete Fehlerverhalten festlegt.
Die ISTQB-Beispielprüfung weist ebenfalls darauf hin, dass das Ausführen einer fehlerhaften Anweisung nicht zwingend einen Fehler im Test sichtbar macht. Entscheidend sind unter anderem die Eingabe, der erreichte Kontrollfluss und die Prüfung des beobachtbaren Ergebnisses.
Welche Fragen sagen mehr über die Testqualität aus?
Coverage ist als Hinweis auf nicht erreichte Codebereiche nützlich. Für die Einschätzung einer Testsuite zählen daneben mehrere voneinander unabhängige Fragen:
Rank #4
- Was wurde gemessen? Statement-, Branch-/Decision- oder ein anderes Kriterium? Ein Prozentwert ist nur im Kontext seiner Definition interpretierbar.
- Welche Eingaben und Grenzfälle wurden geprüft? Dazu gehören relevante Wertebereiche, Randwerte und Fehlerbedingungen, nicht nur ein typischer Ablauf.
- Prüfen die Tests das richtige Ergebnis? Assertions müssen falsche Rückgaben, unerwartete Zustände oder das Ausbleiben eines erwarteten Fehlers erkennen können.
- Decken die Tests fachliche Anforderungen und Risiken ab? Strukturelle Codeabdeckung belegt nicht, dass alle wichtigen Anforderungen durch sinnvolle Tests repräsentiert sind.
- Ist der zusätzliche Test den Aufwand wert? Tests können Pflegekosten verursachen. Ein höherer Prozentwert ist nicht automatisch besser, wenn die zusätzlichen Tests keinen relevanten Fehlerfall oder keine sinnvolle Anforderung absichern.
Wie sollte ein Team Coverage sinnvoll einsetzen?
- Tests aus Anforderungen und Risiken ableiten. Bestimme zuerst, welche Verhaltensweisen, Eingabeklassen und Fehlerfälle wichtig sind. Mache den Coverage-Wert nicht zum Ersatz für diese Testziele.
- Coverage-Kriterium und Ergebnis auswerten. Prüfe, welche Statements oder Zweige unerreicht bleiben und ob das auf eine relevante Lücke oder auf bewusst nicht getesteten Code hinweist.
- Gezielt ergänzen. Schreibe zusätzliche Tests für konkrete Lücken, etwa einen nicht geprüften Entscheidungszweig oder einen wichtigen Grenzfall. Kontrolliere dabei, dass der Test das erwartete Verhalten tatsächlich prüft.
- Nutzen gegen Wartungsaufwand abwägen. Wiederhole die Auswertung, solange neue Tests relevante Risiken abdecken und ihr Pflegeaufwand vertretbar bleibt. Erhöhe den Wert nicht nur, um ein Prozentziel zu erreichen.
Google empfiehlt diesen iterativen Umgang: Tests nicht auf ein Coverage-Ziel hin entwerfen, sondern die Coverage anschließend nutzen, um sinnvolle Lücken zu finden und zu schließen. Der Beitrag Code Coverage Best Practices warnt außerdem davor, einen hohen Coverage-Prozentsatz mit hoher Qualität der Testabdeckung gleichzusetzen. Dort genannte interne Richtwerte von 60 Prozent als „acceptable“, 75 Prozent als „commendable“ und 90 Prozent als „exemplary“ sind Googles Richtlinien, keine universellen Branchenstandards oder Belege für Fehlerfreiheit.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Was lässt sich aus einer hohen Coverage-Zahl schließen?
Sie kann zeigen, dass nach einem benannten Kriterium wenig vorhandener Code unberührt blieb. Sie belegt weder, dass jeder relevante Eingabefall getestet wurde, noch dass Tests falsche Ergebnisse erkennen oder Software fehlerfrei ist. Google formuliert die Grenze so: „High coverage is a necessary, but not sufficient, condition.“ Hohe Coverage kann ein nützliches Ziel sein, ersetzt aber nicht die Prüfung, ob die Tests fachlich sinnvolle Erwartungen abdecken.
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.
