Die zwei großen Fallen der Code-Abdeckung

Sie möchten keine Deckung um der Deckung willen. Sie benötigen eine aussagekräftige Abdeckung, die darauf hinweist, dass Sie die Software gut getestet haben.

Messung der Codeabdeckung ist eines dieser Dinge, die immer meine Aufmerksamkeit erregen. Einerseits stelle ich oft fest, dass Organisationen nicht unbedingt wissen, wie viel Code sie während des Testens abdecken – was wirklich überraschend ist! Am anderen Ende des Abdeckungsspektrums gibt es Organisationen, für die die Anzahl so wichtig ist, dass die Qualität und Wirksamkeit der Tests größtenteils irrelevant geworden ist. Sie jagen gedankenlos den 100%-Drachen und glauben, dass die Software gut oder sogar die beste ist, wenn sie diese Zahl haben. Das ist mindestens so gefährlich, wie nicht zu wissen, was Sie getestet haben, vielleicht sogar noch gefährlicher, da es Ihnen ein falsches Sicherheitsgefühl vermitteln kann.

Die Codeabdeckung kann eine gute und interessante Zahl sein, um die Qualität Ihrer Software zu beurteilen. Es ist jedoch wichtig, sich daran zu erinnern, dass dies eher ein Mittel als ein Zweck ist. Wir wollen keine Deckung um der Deckung willen, wir wollen Deckung, weil es so ist vermutet um anzuzeigen, dass wir die Software gut getestet haben. Wenn die Tests selbst nicht aussagekräftig sind, bedeutet mehr davon sicherlich keine bessere Software. Das wichtige Ziel ist es, sicherzustellen, dass jeder Code getestet und nicht nur ausgeführt wird. Wenn Sie nicht genug Zeit und Geld haben, um alles vollständig zu testen, stellen Sie zumindest sicher, dass alles Wichtige getestet wird.

Dies bedeutet, dass eine geringe Abdeckung zwar bedeutet, dass wir wahrscheinlich nicht genug testen, eine hohe Abdeckung allein jedoch nicht unbedingt mit einer hohen Qualität korreliert - das Bild ist komplizierter.

Es wäre natürlich perfekt, ein fröhliches Medium zu haben, in dem Sie „genug“ Abdeckung haben, um die Software mit einer guten, stabilen und wartbaren Testsuite mit „gerade genug Tests“ zu veröffentlichen. Dennoch sind diese Abdeckungsfallen weit verbreitet.

Falle Nr. 1: „Wir kennen unsere Abdeckung nicht“

Es scheint mir unvernünftig, Ihre Berichterstattung nicht zu kennen - Berichterstattungstools sind billig und reichlich vorhanden. Ein Freund von mir schlägt vor, dass Unternehmen wissen, dass ihre Abdeckungsnummer nicht gut ist. Entwickler und Tester lehnen es daher ab, die schlechte Abdeckung dem Management auszusetzen. Ich würde hoffen, dass dies nicht der übliche Fall ist.

Ein echtes Problem, auf das Teams stoßen, wenn sie versuchen, die Abdeckung zu messen, ist, dass das System zu kompliziert ist. Wenn Sie eine Anwendung aus Teilen auf Teilen auf Teilen erstellen, kann es eine entmutigende Aufgabe sein, nur zu wissen, wo die Abdeckungszähler platziert werden sollen. Ich würde vorschlagen, dass Sie zweimal über die Architektur nachdenken sollten, wenn es tatsächlich schwierig ist, die Abdeckung in Ihrer Anwendung zu messen.

Eine zweite Möglichkeit, in diese Falle zu tappen, besteht in Organisationen, die möglicherweise viele Tests durchführen, jedoch keine echte Abdeckungsnummer, da sie keinen geeigneten Weg gefunden haben, die Zahlen aus verschiedenen Testläufen zu aggregieren. Wenn Sie manuelle Tests, Funktionstests, Komponententests und End-to-End-Tests durchführen, können Sie die Zahlen nicht einfach addieren. Selbst wenn sie jeweils eine Abdeckung von 25% erreichen, ist es unwahrscheinlich, dass sie in Kombination 100% betragen. Tatsächlich ist es wahrscheinlicher, dass es näher an den 25% liegt als an den 100%, wenn Sie sich das ansehen.

Wie sich herausstellt, gibt es tatsächlich eine Möglichkeit, die Abdeckung auf sinnvolle Weise zu messen und zu addieren. Bei Parasoft nutzen wir die enorme Menge an detaillierten Daten, die von unserem Berichts- und Analysetool erfasst werden. Parasoft DTP, die wir in diesem Zusammenhang verwenden können, um eine umfassende, aggregierte Ansicht der Codeabdeckung bereitzustellen. Unsere Anwendungsmonitore können Abdeckungsdaten direkt von der Anwendung erfassen, während sie getestet wird, und diese Informationen dann an Parasoft DTP senden, das Abdeckungsdaten über alle Testpraktiken sowie über Testteams und Testläufe hinweg aggregiert.

Wenn das nach einer ziemlich großen Menge an Informationen klingt, haben Sie Recht! DTP bietet ein interaktives Dashboard, mit dem Sie in diesen Daten navigieren und Entscheidungen darüber treffen können, wo Sie die Testbemühungen konzentrieren möchten. Siehe das Beispiel-Dashboard unten:

Wenn mehrere Tests denselben Code abgedeckt haben, wird dieser nicht überzählt, während nicht getestete Teile des Codes schnell und einfach zu sehen sind. Dies zeigt Ihnen, welche Teile der Anwendung gut getestet wurden und welche nicht. Sie können alles darüber in einem lesen kostenloses Whitepaper.

Also keine Ausreden mehr, die Abdeckung nicht zu messen.

Falle Nr. 2: „Abdeckung ist alles!“

Es ist üblich, fälschlicherweise zu glauben, dass Abdeckung alles ist. Sobald Teams in der Lage sind, die Abdeckung zu messen, ist es nicht ungewöhnlich, dass Manager sagen: „Lasst uns diese Zahl erhöhen.“ Irgendwann wird die Zahl selbst wichtiger als das Testen. Die vielleicht beste Analogie habe ich von Adam Kolawa, dem Gründer von Parasoft, gehört:

„Es ist, als würde man einen Pianisten bitten, 100% der Klaviertasten abzudecken, anstatt nur die Tasten zu drücken, die im Kontext eines bestimmten Musikstücks sinnvoll sind. Wenn er das Stück spielt, bekommt er jede Menge Key-Coverage, die Sinn macht. “

Darin liegt das Problem – gedankenlose Berichterstattung ist dasselbe wie gedankenlose Musik. Die Berichterstattung muss eine echte, sinnvolle Verwendung des Codes widerspiegeln, sonst ist es nur Lärm.

Apropos Lärm … die Deckungskosten steigen mit zunehmender Deckung. Denken Sie daran, dass Sie Tests nicht nur erstellen, sondern auch in Zukunft pflegen müssen. Wenn Sie nicht vorhaben, einen Test wiederzuverwenden und zu warten, sollten Sie wahrscheinlich nicht die Zeit damit verschwenden, ihn überhaupt zu erstellen. Wenn die Testsuite größer wird, nimmt die Anzahl des Rauschens auf unerwartete Weise zu. Doppelt so viele Tests können zwei- oder sogar dreimal so viel Lärm bedeuten. Die bedeutungslosen Tests verursachen am Ende mehr Lärm als gute Tests, weil sie keinen wirklichen Kontext haben, sondern bei jeder Ausführung der Tests behandelt werden müssen. Sprechen Sie über technische Schulden! Unnütze Tests sind eine echte Gefahr.

In bestimmten Branchen, beispielsweise in sicherheitskritischen Branchen, ist die Metrik der 100% igen Abdeckung eine Anforderung. Aber selbst in diesem Fall ist es allzu einfach, die Ausführung einer Codezeile als aussagekräftigen Test zu behandeln, was einfach nicht stimmt. Ich habe zwei grundlegende Fragen, um festzustellen, ob ein Test ein guter Test ist:

1. Was bedeutet es, wenn der Test fehlschlägt?
2. Was bedeutet es, wenn der Test bestanden wird?

Wenn ein Test fehlschlägt, wissen wir im Idealfall etwas darüber, was schief gelaufen ist, und wenn der Test wirklich gut ist, zeigt er uns in die richtige Richtung, um ihn zu beheben. Nur allzu oft, wenn ein Test fehlschlägt, weiß niemand warum, niemand kann ihn reproduzieren und der Test wird ignoriert. Wenn ein Test bestanden wird, sollten wir in der Lage sein zu wissen, was getestet wurde - dies sollte bedeuten, dass ein bestimmtes Merkmal oder eine bestimmte Funktionalität ordnungsgemäß funktioniert.

Wenn Sie eine dieser Fragen nicht beantworten können, haben Sie wahrscheinlich ein Problem mit Ihrem Test. Wenn Sie keine der beiden Fragen beantworten können, ist der Test wahrscheinlich schwieriger als es sich lohnt.

Der Ausweg aus dieser Falle besteht darin, zunächst zu verstehen, dass der Abdeckungsprozentsatz selbst nicht das Ziel ist. Das eigentliche Ziel ist es, nützliche aussagekräftige Tests zu erstellen. Das braucht natürlich Zeit. In einfachem Code Unit-Tests schreiben ist einfach, aber in komplexen realen Anwendungen bedeutet es, Stubs und Mocks zu schreiben und Frameworks zu verwenden. Dies kann einige Zeit in Anspruch nehmen, und wenn Sie dies nicht ständig tun, vergisst man leicht die Nuancen der beteiligten APIs. Selbst wenn Sie es mit dem Testen ernst meinen, kann die Erstellung eines wirklich guten Tests mehr Zeit in Anspruch nehmen, als Sie erwarten.

Wir haben tatsächlich eine neue Technologie dafür bei Parasoft, die sich im Inneren befindet Parasoft Jtest, unser Java-Entwicklungstest-Tool. Der Unit Test Assistant übernimmt die mühsamen Aufgaben, Mocks und Stubs richtig zu machen. Es kann auch dazu beitragen, vorhandene Tests auf nützliche Weise zu erweitern, um die Abdeckung zu erhöhen. So können Sie gute Komponententests erstellen und Empfehlungen zur Verbesserung der Testabdeckung und der Testqualität abgeben.

Hoffentlich haben Sie gelernt, dass die Abdeckung wichtig ist und die Verbesserung der Abdeckung ein lohnendes Ziel ist. Aber denken Sie daran, dass es nicht annähernd so wertvoll ist, einfach dem Prozentsatz hinterherzujagen, wie stabile, wartbare und aussagekräftige Tests zu schreiben.

Von Arthur Hicken

Arthur ist seit über 25 Jahren bei Parasoft im Bereich Software-Sicherheit und Testautomatisierung tätig. Er hilft bei der Erforschung neuer Methoden und Techniken (einschließlich 5 Patente) und hilft Kunden dabei, ihre Software-Praktiken zu verbessern.