Ein Angebot von

Die zwei großen Fallen bei der Code Coverage

| Autor / Redakteur: Arthur Hicken * / Sebastian Gerstl

100 Prozent Codeabdeckung beim Testen - diesem hehren Qualitätsziel jagen viele Softwareentwickler oft geradezu fanatisch hinterher. Doch das unbedingte Drängen auf Vollständigkeit kann fast ebenso fatal sein, wie die Code Coverage vollkommen zu ignorieren.
100 Prozent Codeabdeckung beim Testen - diesem hehren Qualitätsziel jagen viele Softwareentwickler oft geradezu fanatisch hinterher. Doch das unbedingte Drängen auf Vollständigkeit kann fast ebenso fatal sein, wie die Code Coverage vollkommen zu ignorieren. (Bild: Clipdealer)

Manche meinen, dass nur 100%-ige Code Coverage auch für gute Softwarequalität stehen kann. Andere haben ihre Codeabdeckung dagegen gar nicht im Blick. Beides kann aber letztendlich für die Softwarequalität und -Sicherheit fatal sein.

Das Messen der Codeabdeckung gehört zu den Dingen, die meine Aufmerksamkeit immer anziehen. Einerseits habe ich oft den Eindruck, dass Unternehmen nicht unbedingt wissen, wieviel Code sie beim Prüfen tatsächlich erfassen – und das ist wirklich überraschend! Andererseits gibt es am anderen Ende des Spektrums Unternehmen, für die diese Zahl so wichtig ist, dass die Qualität und Wirksamkeit der Tests nahezu irrelevant werden. Ohne groß nachzudenken, jagen sie den 100 Prozent hinterher in dem Glauben, dass ihre Software gut oder sogar optimal ist, sobald diese Quote erreicht ist. Dies aber ist mindestens ebenso riskant wie nicht zu wissen, was man getestet hat – wenn nicht sogar noch gefährlicher, weil man sich fälschlicherweise in Sicherheit wiegt.

Tatsächlich kann die Code Coverage eine gute und auch interessante Maßzahl zum Beurteilen Ihrer Softwarequalität sein. Man darf dabei aber nicht vergessen, dass sie lediglich ein Mittel zum Zweck ist. Wir streben eine hohe Codeabdeckung nicht um ihrer selbst willen an, sondern weil sie ein Indikator dafür sein soll, dass wir beim Testen der Software einen guten Job gemacht haben. Sind aber die Tests selbst nicht aussagefähig, deutet es nicht auf bessere Software hin, wenn man mehr solche Tests verwendet.

Das entscheidende Ziel ist es, dass jeder Bestandteil der Software geprüft und nicht einfach nur ausgeführt wird. Wenn schon nicht genug Zeit und Geld vorhanden ist, um wirklich alles zu testen, sollte zumindest sichergestellt werden, dass alles Wichtige geprüft wird.

Das heißt im Klartext: Eine niedrige Codeabdeckung bedeutet, dass wir wahrscheinlich nicht genug prüfen. Im Gegenzug lässt sich eine hohe Code Coverage nicht zwangsläufig mit hoher Qualität gleichsetzen. In Wirklichkeit ist die ganze Sache etwas komplizierter.

Ideal wäre eine ‚ausreichend‘ hohe Codeabdeckung, dann könnte man die Software mit gutem Gewissen mit einer guten, stabilen und leicht zu pflegenden Test Suite herausgeben, die ‚genau den richtigen Umfang an Tests‘ durchführt. Dabei lauern aber einige Fallen.

‚Wir kennen unsere Code Coverage nicht‘

Diese erste Falle erscheint mir widersinnig, schließlich gibt es ein hinreichend großes Angebot an kostengünstigen Coverage-Tools. Einer meiner Freunde hegt den Verdacht, dass den betreffenden Organisationen ihre unzureichende Codeabdeckung durchaus bewusst ist, sodass die Entwickler und Tester die niedrigen Werte nur ungern ihrem Management offenbaren. Ich kann nur hoffen, dass dies nicht die Regel ist.

Ein echtes Problem, mit dem die Teams konfrontiert werden, wenn sie die Codeabdeckung zu messen versuchen, ist ein zu kompliziertes System. Wenn Sie eine Applikation aus Elementen zusammenfügen, die ihrerseits wieder aus anderen, erneut aus untergeordneten Bestandteilen bestehenden Komponenten bestehen, kann allein die Entscheidung, wo die Coverage-Zähler platziert werden müssen, eine höchst unangenehme Aufgabe sein. Mein Rat ist: Wenn es schon schwierig ist zu entscheiden, wo die Codeabdeckung in Ihrer Applikation gemessen werden muss, sollten Sie die Architektur unbedingt noch einmal überdenken.

Fehlende Angabe der Code Coverage

Eine zweite Falle gibt es bei Unternehmen, die zwar möglicherweise viel testen, aber keine Codeabdeckungs-Angabe haben, weil ihnen noch der geeignete Weg fehlt, die Zahlen verschiedener Testdurchläufe zu bündeln. Wenn man manuelle Tests, Funktionstests, Modultests und End-to-End-Tests durchführt, kann man die Zahlen nicht einfach addieren. Selbst wenn diese Tests einzeln eine Abdeckung von 25% erreichen, ist es unwahrscheinlich, dass sie zusammengenommen auf 100% kommen. Sieht man genauer hin, liegt das finale Resultat wahrscheinlich näher an 25% als an 100%.

Tatsächlich gibt es eine Möglichkeit, Code Coverage auf aussagefähige Weise zu messen und zu addieren. Bei Parasoft nutzen wir dazu den enormen Umfang an granularen Daten, die von unserem Reporting- und Analysetool Parasoft DTP erfasst werden. Wir setzen das Tool in diesem Kontext ein, um ein umfassendes, gebündeltes Bild von der Codeabdeckung zu erhalten. Unsere Applikations-Monitore können unmittelbar während der Tests Coverage-Daten aus der Applikation einholen und diese Informationen an Parasoft DTP weiterleiten. Dort werden die Coverage-Daten über alle Testverfahren sowie über sämtliche Test-Teams und Testdurchläufe hinweg gesammelt.

Dashboard-Ansicht: Parasoft DTP hilft, über alle Testverfahren sowie über sämtliche Test-Teams und Testdurchläufe hinweg den Überblick zu behalten.
Dashboard-Ansicht: Parasoft DTP hilft, über alle Testverfahren sowie über sämtliche Test-Teams und Testdurchläufe hinweg den Überblick zu behalten. (Bild: Parasoft)

Wenn Sie nun den Eindruck haben, dass man es hier mit einer Unmenge an Informationen zu tun hat, liegen Sie vollkommen richtig. Aber DTP stellt ein interaktives Dashboard zur Verfügung, das beim Durchforsten dieser Daten ebenso hilft wie bei den Entscheidungen darüber, worauf Sie Ihre Prüfarbeiten konzentrieren sollten.

Haben mehrere Tests denselben Code abgedeckt, wird kein zu hoher Wert ausgegeben, und andererseits lassen sich nicht geprüfte Codepassagen schnell und einfach erkennen. Somit sieht man unmittelbar, welche Teile einer Applikation gut geprüft wurden und welche nicht.

Ist Code Coverage alles?

Es gibt also keine Entschuldigung mehr dafür, die Codeabdeckung nicht zu messen - damit sind wir schon bei der nächsten Falle, nämlich bei der Einschätzung „Code Coverage ist alles“. Wenn Teams einmal in der Lage sind, die Codeabdeckung zu messen, sagt das Management nicht selten: „Lasst uns diese Zahl steigern“. Damit wird der reine Zahlenwert irgendwann wichtiger als das Testen. Die vielleicht beste Analogie hierzu hörte ich von Parasoft-Gründer Adam Kolawa:

„Es ist genau so, als würde man von einem Pianisten verlangen, alle Tasten seines Instruments zu betätigen anstatt nur jene, die im Kontext des jeweiligen Musikstücks sinnvoll sind. Wenn er ein bestimmtes Stück spielt, nutzt er genau jenen Prozentsatz der Tasten, der sinnvoll ist.“

Übrigens steigen die für Codeabdeckung entstehenden Kosten, je höher die Code Coverage wird. Schließlich müssen die Tests nicht nur erstellt, sondern im weiteren Verlauf auch gepflegt werden. Wenn Sie die Wiederverwendung und Pflege eines Tests nicht von Anfang an einplanen, sollten Sie ihn gar nicht erst erstellen. Je größer eine Test Suite wird, umso mehr nimmt auf unerwartete Weise das Rauschen zu. Bei doppelt so vielen Tests kann sich deshalb das Rauschen um den Faktor zwei oder gar drei erhöhen. Die sinnlosen Tests aber erzeugen im Endeffekt mehr Rauschen als gute Tests, da sie keinen wirklichen Kontext haben, sondern bei jeder Ausführung des Tests Aufmerksamkeit erfordern. Ein Paradebeispiel für technische Schuld! Sinnlose Tests stellen eine echte Gefahr dar.

Tatsache ist allerdings auch, dass in manchen Bereichen, so zum Beispiel in sicherheitskritischen Branchen, eine Codeabdeckung von 100% verlangt wird. Aber auch in diesem Fall ist es allzu leicht, jegliche Ausführung einer Codezeile als aussagefähigen Test zu betrachten, was schlicht nicht zutrifft. Ob ein bestimmter Test wirklich gut ist, lässt sich mit zwei einfachen Fragen herausfinden:

  • 1. Welche Relevanz hat es, wenn der Test fehlschlägt?
  • 2. Welche Relevanz hat es, wenn der Test bestanden wird?

Im Idealfall wissen wir bei einem fehlgeschlagenen Test etwas darüber, was schiefgelaufen ist. Ist der Test wirklich gut, leitet er uns in die richtige Richtung, um den Fehler zu beheben. Nur leider weiß bei einem fehlgeschlagenen Test allzu oft keiner, weshalb der Test nicht bestanden wurde, niemand kann ihn reproduzieren, und folglich wird er ignoriert. Umgekehrt sollten wir bei einem erfolgreichen Test wissen, was getestet wurde – es sollte bedeuten, dass ein bestimmtes Feature oder ein bestimmter Teil der Funktionalität korrekt funktioniert hat.

Wenn Sie auf eine der beiden Fragen keine Antwort haben, gibt es bei Ihrem Test wahrscheinlich ein Problem. Können Sie beide nicht beantworten, bringt der Test wahrscheinlich mehr Probleme als Nutzen.

Wege heraus aus den Code-Coverage-Fallen

Wie können Sie die geschilderten Fallen umgehen? Erstens müssen Sie sich klarmachen, dass die Codeabdeckungs-Angabe für sich genommen nicht das Ziel ist. In Wirklichkeit geht es darum, aussagefähige Tests zu erstellen, was allerdings zeitaufwändig ist. Bei einfachem Code ist das Schreiben von Modultests nicht schwierig. In komplexen realen Applikationen aber müssen Stubs und Mocks geschrieben werden und man muss mit Frameworks arbeiten, was recht viel Zeit beanspruchen kann. Tun Sie dies nicht regelmäßig, vergessen Sie außerdem leicht die Feinheiten der verwendeten APIs. Selbst wenn Sie das Testen noch so ernst nehmen, kann der Zeitaufwand zum Erstellen wirklich guter Tests Ihre Vorstellungen übersteigen.

Hier können Testtools weiterhelfen. Der im Parasoft Jtest für Java enthaltene Unit Test Assistant übernimmt beispielsweise die mühsame Aufgabe, die Mocks und Stubs richtig hinzubekommen. Er kann auch bestehende Tests so erweitern, dass sich die Code Coverage erhöht. Dies hilft Ihnen beim Erstellen guter Modultests und gibt Empfehlungen, wie sich die Codeabdeckung und Qualität der Tests erhöhen lässt.

Code Coverage ist ein wichtiges Element, und das Steigern der Codeabdeckung stellt ein lohnendes Ziel dar. Vergessen Sie aber bitte nicht: das reine Steigern der Prozentzahl ist nicht annähernd so wichtig ist wie das Schreiben stabiler, leicht pflegbarer und aussagefähiger Tests.

Rasch aufgebaut: Software-Testumgebung für Mikrocontroller

Rasch aufgebaut: Software-Testumgebung für Mikrocontroller

05.02.18 - Oft entfallen Tests von Mikrocontroller-Software, da es schwierig ist, moderne Testmethoden für Prozessoren auf Geräten mit eingeschränkten Ressourcen anzuwenden. Doch neues Debugging schafft Abhilfe. lesen

Test-Chaos vermeiden mit der Deploy-and-Destroy-Strategie

Test-Chaos vermeiden mit der Deploy-and-Destroy-Strategie

08.11.17 - Software ist oft die primäre Schnittstelle zwischen Unternehmen und ihren Kunden. Einbußen in der Qualität zugunsten der Durchlaufzeit sind hier keine Option. Wie ist also hohe Qualität zu garantieren? lesen

Code-Coverage undercover: Nutzen und Tücken Trace-basierter Codeabdeckung

Code-Coverage undercover: Nutzen und Tücken Trace-basierter Codeabdeckung

13.02.15 - Der Nachweis der Testqualität für sicherheitskritische Embedded-Systeme mit Hilfe von Code-Coverage-Analysen ist ein äußerst wichtiges, aber auch diffiziles Unterfangen. lesen

* Arthur Hicken ist Software Evangelist bei Parasoft Inc.

Kommentar zu diesem Artikel abgeben
Vielen Dank für diesen Artikel zur Code Coverage. Ich möchte gerne auf eine weitere Falle...  lesen
posted am 13.06.2018 um 15:18 von Hitex125


Mitdiskutieren
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45346057 / Test & Qualität)