Testabdeckung

Als Testabdeckung bezeichnet man das Verhältnis an tatsächlich getroffenen Aussagen eines Tests gegenüber den theoretisch möglich treffbaren Aussagen bzw. der Menge der gewünschten treffbaren Aussagen. Die Testabdeckung spielt als Metrik zur Qualitätssicherung und zur Steigerung der Qualität insbesondere im Maschinenbau und der Softwaretechnik eine große Rolle.

In der Praxis wird die Testabdeckung durch verschiedene Kriterien beeinflusst. Die Testabdeckung lässt sich durch eine Erhöhung der Zahl an Messungen, Stichproben und Testfällen verbessern. Begrenzt wird die Testabdeckung in der Praxis jedoch durch die Kosten, die mit jedem Test verbunden sind.

Je nach Art, Aufwand und Nutzen der Tests werden einige Tests stichprobenartig, andere Tests vollständig durchgeführt. Ein einfach und automatisch durchzuführender Test wird mit jedem Produkt durchgeführt, da seine Kosten die Produktionskosten nur geringfügig erhöhen. Ein Crashtest mit einem Fahrzeug wird jedoch natürlich nur mit Stichproben durchgeführt, da das getestete Produkt anschließend unbrauchbar wird.

Für 1000 produzierte Fahrzeuge könnte dies z. B. bedeuten, dass besonders aufwendige Tests und Crashtests nur mit einem einzigen Fahrzeug durchgeführt werden, während weniger aufwendige Tests mit einer größeren Zahl oder gar allen Fahrzeugen durchgeführt werden.

Notwendige, aber aufwendige Tests werden in ihrer Häufigkeit und damit der Testabdeckung variiert. Liefert ein Test überwiegend oder ausschließlich positive Ergebnisse, wird seine Zahl verringert. Liefert ein Test negative Ergebnisse, wird er häufiger eingesetzt, bis die Veränderungen an der Produktion zu einer deutlichen Steigerung positiver Ergebnisse und damit wieder einer höheren Produktqualität geführt hat.

Die Kosten-Nutzen-Rechnung solcher Tests wird mit Hilfe der Stochastik durchgeführt. Wird z. B. nur mit 5 von 1000 Fahrzeugen ein Test durchgeführt, ob die elektrischen Fensterheber einwandfrei funktionieren, lässt sich mit Hilfe der Stochastik die statistische Relevanz und die Wahrscheinlichkeit einer Fehleinschätzung aufgrund des Testergebnisses berechnen.

Für die Testabdeckung in der Softwaretechnik (engl. Test Coverage bzw. Code Coverage) spielt die Stochastik praktisch keine Rolle, da es sich bei Computerprogrammen nicht um seriengefertigte Einzelprodukte handelt, bei denen Tests mit Stichproben durchgeführt werden. Stattdessen werden Tests anhand der Spezifikation (Eigenschaften der Schnittstelle) oder der inneren Struktur einer zu testenden Software-Einheit definiert.

In der Softwaretechnik wird die Testabdeckung für unterschiedliche Bereiche der Software ermittelt. Zu diesen gehört die Abdeckung des Codes, der Daten oder der Fachlichkeit. Um eine möglichst hohe Testabdeckung zu erreichen, müssen je nach abzudeckendem Bereich unterschiedliche Testfälle geschrieben werden. Nicht für alle kontrollflussorientierten Testverfahren ist beim Softwaretest die Angabe eines Maßes für die Testabdeckung möglich, da die Bestimmung der Anzahl der möglichen Testfälle für reale Probleme oft nicht möglich ist.

Eine vollständige Testabdeckung der Fachlichkeit stellt eine Ausnahme dar, weil die Anzahl möglicher Testfälle sehr schnell ungeheuer groß wird (durch kombinatorische Explosion). Ein vollständiger Funktionstest für eine einfache Funktion, die zwei 16-Bit-Werte als Argument erhält, würde schon 2 16 + 16 {\displaystyle 2^{16+16}} , also ca. 4 Milliarden Testfälle bedeuten, um die Spezifikation vollständig zu testen. Stattdessen beschränkt man sich auf eine Auswahl sinnvoll erscheinender Tests für Grenzfälle (Grenzwertanalyse). Beispiel: Eine Wurzelfunktion für rationale Zahlen könnte z. B. mit sämtlichen Elementen der Menge { − m a x , − 1 , − ε , − 0 , + 0 , + ε , + 1 , + m a x } {\displaystyle \left\{-{\mathit {max}},-1,-\varepsilon ,-0,+0,+\varepsilon ,+1,+{\mathit {max}}\right\}} getestet werden. Als sinnvolle Auswahl von Testfällen für eine angemessene Testabdeckung gelten in der Regel verschiedenartige gültige Argumente, für Komponenten mit Robustheitsanforderung zusätzlich Grenzelemente (gerade noch gültige Argumente und gerade ungültige Argumente). Es hat sich zudem als erfolgreich erwiesen, im Fehlerfall das den Fehler auslösende Argument in die Menge der Testelemente aufzunehmen.

Eine weitgehend vollständige Testabdeckung des Codes hingegen ist häufig das Ziel für Modultests bzw. Komponententests: Durch hochgradige Testabdeckung für 'kleine' Funktionseinheiten ergibt sich die Anzahl der insgesamt erforderlichen Testfälle lediglich aus der Addition dieser Testfälle und nicht aus der Kombinatorik der größeren Funktionalität. Doch auch hier kann dieses Ziel wegen verbleibender Restrisiken (unerwartete 'Fernwirkung' von Fehlern) und auch aus Kosten-Nutzen-Gründen in den meisten Fällen nicht zu 100 % erreicht werden.

Da eine hohe Codeabdeckung auch mit Tests erreicht werden kann, die nichts überprüfen, hat die Codeabdeckung für die Qualität der Tests eine nur eingeschränkte Aussagekraft. Um die Qualität von Tests sicherzustellen, wird daher üblicherweise mit Mutationstests gearbeitet. Dazu werden in den zu testenden Code automatisch Fehler bzw. Mutationen eingebaut und dann die Tests ausgeführt. Schlagen daraufhin Tests fehl, die davor funktioniert haben, so wurde die Mutation erkannt. Die Qualität der Tests kann aus dem Anteil der erkannten Mutationen abgeleitet werden. Die damit errechnete Testabdeckung bestimmt also die Abdeckung des Codes, der bei einer Mutation zu einem Fehlschlagen eines der Tests geführt hatte.

Die Codeabdeckung wird auch von diversen internationalen Normen für Empfehlungen bzw. Mindestanforderungen herangezogen:

• IEEE 1008 „Software Unit Testing“: 100 % Statement-Abdeckung als Anforderung für Fertigstellung der Modultests, 100 % Verzweigungs-Abdeckung für Module mit kritischem Code oder ungenügende Spezifikation.
• ISO 26262 „Road vehicles – Functional safety“: Je nach Kritikalität wird entsprechende Testabdeckung für Modultests und Integrationstests empfohlen bzw. stark empfohlen.
• IEC 61508 „Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems“: Empfiehlt bzw. empfiehlt stark eine 100-%-Abdeckung von Eingängen, Statements, Verzweigungen, Bedingungen je nach Sicherheitsanforderungsstufe, beispielsweise wird bei der kleinsten Stufe eine 100-%-Testabdeckung der Eingänge stark empfohlen, die der Statements, Verzweigungen und Bedingungen empfohlen.
• DO-178B „Software Considerations in Airborne Systems and Equipment Certification“: Verlangt eine 100-%-Testabdeckung von Statements, Entscheidungen, veränderten Entscheidungen je nach Auswirkung eines Systemfehlers. Beispielsweise wird ab Verletzungsgefahr von Passagieren eine 100-%-Testabdeckung der Statements verlangt.

Programmiersprache	Tools
Ada	gcov
C	BTC EmbeddedTester, Cantata++, froglogic Squish Coco, gcov, TESSY, Testwell CTC++
C++	Bullseye Coverage, Cantata++, froglogic Squish Coco, gcov, LDRA Testbed, OpenCppCoverage, TESSY, Testwell CTC++
C#	froglogic Squish Coco
Cobol	CC ANALYZER, CodeCover
Delphi	Delphi Code Coverage
Groovy	Clover
IEC 61131-3 Applikationscode (z. B. im Maschinen- und Anlagenbau)	CODESYS Profiler
Java	Clover, Cobertura, CodeCover, EMMA, JaCoCo, Testwell CTC++
Simulink	BTC EmbeddedTester
JavaScript	coveraje, JSCoverage, script-cover
.Net-Framework	JetBrains dotCover, NCover, PartCover
Perl	Devel::Cover
PHP	XDebug
Python	coverage.py
Ruby	rcov
Shell	shcov
Simulink-Modelle	Simulink Verification and Validation
Verilog	Code Coverage
VHDL	Code Coverage
Visual Basic	VBWatch

• PIT – Java

• Gürkan Aydin und Hartmut Pohl: Code Coverage Tools (PDF; 1,1 MB) In: Hackin9, 06/2012
• Prof. Dr. Daniel Fischer: Code-Coverage auf Embedded-Systemen (PDF; 920 kB) Vortrag auf dem Embedded Software Engineering Kongress 2012

• Kontrollflussorientierte Testverfahren
• Dynamisches Software-Testverfahren