Holen Sie sich die neuesten wichtigen Update-Informationen für die Log4j-Sicherheitslücke. Sehen Sie sich an, wie Sie das Problem mithilfe der Parasoft-Anleitung beheben können. Erfahren Sie mehr >>

X
BLOG

Die zwei großen Fallen der Code-Abdeckung

Die zwei großen Fallen der Code-Abdeckung Lesezeit: 5 Minuten
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.

Die Messung der Codeabdeckung ist eines der Dinge, die meine Aufmerksamkeit immer wieder auf sich ziehen. Einerseits stelle ich oft fest, dass Unternehmen nicht unbedingt wissen, wie viel Code sie beim Testen 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 das Beste ist, was sie sein kann, wenn sie diese Nummer haben. Dies ist mindestens so gefährlich, als ob Sie nicht 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 Berichterstattung 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 denken, dass Berichterstattung alles ist. Sobald die Teams in der Lage sind, die Abdeckung zu messen, sagen Manager nicht selten: "Erhöhen wir diese Anzahl." Schließlich wird die Nummer selbst wichtiger als das Testen. Die vielleicht beste Analogie ist eine, die ich von Parasofts Gründer Adam Kolawa gehört habe:

„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 Abdeckung muss die tatsächliche, sinnvolle Verwendung des Codes widerspiegeln, andernfalls handelt es sich nur um Rauschen.

Apropos Lärm… die Kosten für die Abdeckung steigen mit zunehmender Abdeckung. Denken Sie daran, dass Sie nicht nur Tests erstellen, sondern diese 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 zu erstellen. Wenn die Testsuite größer wird, nimmt das Rauschen 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 Rauschen als gute Tests, da sie keinen realen Kontext haben, sondern bei jeder Ausführung der Tests behandelt werden müssen. Sprechen Sie über technische Schulden! Nutzlose 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 Berichterstattung wichtig ist, und die Verbesserung der Berichterstattung ist ein würdiges Ziel. Beachten Sie jedoch, dass die einfache Verfolgung des Prozentsatzes bei weitem nicht so wertvoll ist wie das Schreiben stabiler, wartbarer und aussagekräftiger Tests.

Neuer Call-to-Action

Geschrieben von

Artur 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.

Erhalten Sie die neuesten Nachrichten und Ressourcen zum Testen von Software sofort.