Fallstricke der Codeabdeckung

Question

Ich bin auf der Suche nach Beispielen aus der realen Welt, die zeigen, welche negativen Auswirkungen die Codeabdeckung hat.

Ich habe dies kürzlich bei meiner Arbeit bemerkt, weil eine Richtlinie eine 100%ige Codeabdeckung vorschreibt. Die Codequalität hat sich sicherlich verbessert, aber im Gegenzug scheinen die Tester laxere Testpläne zu schreiben, weil "der Code ja vollständig unitgetestet ist". Infolgedessen sind einige logische Fehler durchgeschlüpft. Die Fehlersuche war wirklich sehr mühsam, denn der Code ist ja vollständig unit-getestet".

Ich denke, das lag zum Teil daran, dass unser Tool nur Aussagen erfasst hat. Trotzdem hätte man die Zeit besser nutzen können.

Falls jemand andere negative Auswirkungen einer Code Coverage Policy kennt, bitte ich um Mitteilung. Ich würde gerne wissen, was für andere "Probleme" in der Praxis auftreten.

Vielen Dank im Voraus.

EDIT: Danke für all die wirklich guten Antworten. Es gibt ein paar, die ich als Antwort markieren würde, aber ich kann leider nur eine markieren.

Answer 1

Ich weiß, das ist keine direkte Antwort auf Ihre Frage, aber...

Jede Prüfung, egal welcher Art, ist für sich genommen unzureichend. Unit-Tests/Code Coverage sind etwas für Entwickler. Die Qualitätssicherung muss immer noch das System als Ganzes testen. Auch die Geschäftsanwender müssen das System als Ganzes testen.

Der umgekehrte Fall, dass die Qualitätssicherung den Code vollständig testet, so dass die Entwickler nicht testen sollten, ist ebenso schlecht. Testen ist komplementär und verschiedene Tests liefern unterschiedliche Ergebnisse. Jeder Testtyp kann Dinge übersehen, die ein anderer vielleicht findet.

Wie beim Rest der Entwicklung sollten Sie auch beim Testen keine Abkürzungen nehmen, denn dadurch werden nur Bugs durchgelassen.

Answer 2

1. Schreiben von zu gezielten Testfällen.
2. Unzureichende Prüfung der Eingangsvariabilität des Kodex
3. Große Anzahl von künstlichen Testfällen ausgeführt.
4. Keine Konzentration auf die wichtigen Testausfälle aufgrund von Rauschen.
5. Schwierigkeiten bei der Zuordnung von Fehlern, da viele Bedingungen aus vielen Komponenten zusammenwirken müssen, damit eine Zeile ausgeführt werden kann.

Der schlimmste Nebeneffekt eines 100%igen Abdeckungsziels ist, dass man einen Großteil des Testentwicklungszyklus (75%+) damit verbringt, Eckfälle zu finden. Eine weitere schlechte Auswirkung einer solchen Politik ist die Konzentration auf eine bestimmte Codezeile, anstatt den gesamten Bereich der Eingaben zu berücksichtigen. Es ist mir eigentlich egal, dass die strcpy-Funktion mindestens einmal ausgeführt wurde. Mir ist wichtig, dass sie mit einer Vielzahl von Eingaben funktioniert hat. Es ist gut, eine Richtlinie zu haben. Aber eine extrem drakonische Richtlinie ist schlecht. Eine 100%ige Codeabdeckung ist weder notwendig noch ausreichend, um einen Code als solide zu betrachten.

Answer 3

Einer der größten Fehler bei der Codeabdeckung besteht darin, dass nur von Codeabdeckung gesprochen wird, ohne dass diese tatsächlich spezifiziert wird was die Art der Codeabdeckung, von der sie sprechen. Die Merkmale von C0, C1, C2 und noch höheren Codeabdeckungsgraden sind sehr unterschiedlich, so dass es keinen Sinn macht, nur von "Codeabdeckung" zu sprechen.

So ist es zum Beispiel so gut wie unmöglich, eine 100%ige Pfadabdeckung zu erreichen. Wenn Ihr Programm n Entscheidungspunkte, Sie benötigen 2 n Tests (und je nach Definition ist jedes einzelne Bit in einem Wert ein Entscheidungspunkt. Um also eine 100%ige vollständige Pfadabdeckung für eine extrem einfache Funktion zu erreichen, die lediglich zwei int s, benötigen Sie 18446744073709551616 Tests). Wenn Sie nur eine Schleife, benötigen Sie bereits unendlich viele Tests.

Eine 100-prozentige C0-Abdeckung ist dagegen trivial.

Ein weiterer wichtiger Punkt ist, dass die Codeabdeckung no sagen Ihnen, welcher Code getestet wurde. Es sagt Ihnen nur, welcher Code getestet wurde. laufen. ! Sie können es selbst ausprobieren: Nehmen Sie eine Codebasis, die eine 100%ige Codeabdeckung aufweist. Entfernen Sie alle Assertions aus den Tests. Jetzt ist der Codebase immer noch hat einen 100 %igen Erfassungsbereich, prüft aber keine einzige Sache! Die Codeabdeckung sagt Ihnen also nicht, was getestet wird, sondern nur, was nicht getestet wird.

Answer 4

Es gibt verschiedene Werkzeuge, Durcheinander die eine Analyse durch Zweigabdeckung durchführen, indem Sie Ihren Code verändern, um zu sehen, ob Ihr Test bei allen verschiedenen Permutationen fehlschlägt.

Direkt von ihrer Website:

Jumble ist eine Mutation auf Klassenebene Testwerkzeug, das in Verbindung mit mit JUnit arbeitet. Der Zweck von Mutationstests Tests ist es, ein Maß für die Wirksamkeit von Testfällen. Eine einzelne Mutation wird an dem zu testenden Code durchgeführt Code durchgeführt, die entsprechenden Testfälle Testfälle werden dann ausgeführt. Wenn der veränderte Code die Tests nicht besteht, dann erhöht dies das Vertrauen in die Tests. Umgekehrt, wenn der geänderte Code die Tests besteht, deutet dies auf einen Testmangel hin.

Answer 5

An der Codeabdeckung ist nichts auszusetzen - was ich falsch finde, ist die Zahl von 100 %. Irgendwann tritt das Gesetz des verminderten Ertrags in Kraft und es wird teurer, das letzte 1 % zu testen als die anderen 99 %. Die Codeabdeckung ist ein erstrebenswertes Ziel, aber gesunder Menschenverstand hilft weiter.