Ich bin mir also nicht sicher, was die Vor- und Nachteile von du-path coverage (oder z. B. Kriterien für die Datenflussabdeckung) im Vergleich zu Prädikatskriterien oder Zweig- / Knotenkriterien sind.
Ich kann sehen, dass in bestimmten Fällen die Vorteile einer Art von Deckung für die andere klar sind. Zum Beispiel, wenn eine Menge meines Algorithmus in etwas ähnlich dem nächsten Beispiel besteht
%Vor%Es ist klar, dass die Verwendung jeglicher Art von Kriterien für die Datenflussabdeckung eine Menge Logik ungetestet lässt (was wir gerne vermeiden würden). Für den gegebenen Fall wäre ein Prädikat / Klausel-Kriterium viel besser.
Nun, was ich gerne wissen möchte, ist der allgemeine Fall, nach dem Sie in einem Algorithmus Ausschau halten, wenn Sie entscheiden, welche Art von Abdeckungskriterien Sie zwischen
befolgenArten von Abdeckungskriterien (im Wesentlichen diejenigen, die in Einführung in den Softwaretest gefunden werden). Das heißt, ich suche grundsätzlich nach allgemeinen Heuristiken für den allgemeinen Fall.
Danke
Zugegebenermaßen habe ich in diesem Bereich nicht viel geforscht und folge Ihnen nicht unbedingt vollständig (hauptsächlich aufgrund meiner mangelnden Erfahrung in diesem Bereich). Aber hoffentlich ist das nicht zu weit von der Basis entfernt.
Mein Verständnis von Code Coverage war schon immer, dass Sie jeden möglichen Ausführungspfad abdecken möchten. Jetzt weiß ich, dass einige Wege viel wichtiger sind als andere (zum Beispiel: der "glückliche Weg" ist viel wichtiger als irgendein obskurer Pfad, um eine Eigenschaft zu setzen), aber unabhängig von Wetter oder nicht "bedecken" Sie jeden Pfad, mindestens Sie wollen sich ihrer Existenz bewusst sein und bewusst eine Entscheidung darüber treffen, was und was nicht zu verdecken ist (über Unit-Tests oder manuell).
Sie können damit beginnen, Methoden anzuschauen und Testfälle zu schreiben, aber das wird schnell unzuverlässig, da Sie garantiert NICHT jeden möglichen Ausführungspfad sehen, egal welchen Algorithmus Sie verwenden. Selbst sehr kleine Programme erzeugen Fehler, die nicht berücksichtigt wurden, da der Tester nicht daran dachte, es auf diese Weise zu versuchen.
Was Sie wirklich brauchen, ist ein Code-Coverage-Tool, das Ihnen sagt, welche Ausführungspfade von Ihren Komponententests abgedeckt wurden und welche nicht. An diesem Punkt können Sie logische Entscheidungen über das Wetter treffen oder diese fehlenden Fälle nicht abdecken (da nicht alle Fälle Ihre Zeit wert sind). Ohne ein solches Werkzeug würde ich denken, dass Sie unzählige Mannstunden damit verbringen würden, Zeile für Zeile zu verfolgen und zu verfolgen, welche Testfälle das abdecken ... Auch wenn das Tool mehrere hundert Dollar (oder sogar mehrere tausend Dollar) kostet, denke ich Sie Ich werde diese Gelder schnell in Zeit sparen.
Meine allgemeine Heuristik für Sie besteht darin, ein solches Tool zu verwenden, um Ihre Testabdeckung zu verfolgen und Entscheidungen basierend auf den Ergebnissen zu treffen.
Einige Code-Coverage-Tools (nicht umfassend):
Tags und Links unit-testing testing