Angenommen, Sie arbeiten an einem Projekt und das Zeit- / Geldbudget erlaubt keine 100% ige Abdeckung aller Codes / Pfade.
Daraus folgt, dass eine kritische Teilmenge Ihres Codes getestet werden muss. Ein "Gut-Check" -Ansatz kann eindeutig verwendet werden, um das System zu testen, wobei Intuition und manuelle Analyse eine Art Testabdeckung erzeugen können, die "in Ordnung" ist.
Ich gehe jedoch davon aus, dass es Best Practices / Ansätze / Prozesse gibt, die kritische Elemente bis zu einem bestimmten Schwellenwert identifizieren und Ihre Testelemente auf diese Blöcke konzentrieren können.
Ein gängiger Prozess zum Identifizieren von Fehlern in der Fertigung ist beispielsweise die Fehlermöglichkeits- und Einflussanalyse. Ich suche nach einem Prozess, um kritische Testblöcke in Software zu identifizieren.
100% ige Codeabdeckung ist kein wünschenswertes Ziel. Siehe dieses Blog aus einigen Gründen.
Meine bewährte Methode besteht darin, Testfälle aus Anwendungsfällen abzuleiten. Erstellen Sie eine konkrete Rückverfolgbarkeit (ich verwende ein UML-Tool, aber auch eine Tabellenkalkulation) zwischen den Anwendungsfällen, die Ihr System implementieren soll, und testen Sie Fälle, die beweisen, dass es funktioniert.
Identifizieren Sie die kritischsten Anwendungsfälle explizit. Sehen Sie sich nun die Testfälle an, zu denen sie suchen. Haben Sie viele Testfälle für die kritischen Anwendungsfälle? Umfassen sie alle Aspekte des Anwendungsfalls? Bedecken sie negative und Ausnahmefälle?
Ich habe herausgefunden, dass dies die beste Formel ist (und die Zeit des Teams am besten nutzt), um eine gute Abdeckung sicherzustellen.
BEARBEITEN:
Einfaches, durchdachtes Beispiel, warum eine 100% ige Codeabdeckung nicht garantiert, dass Sie 100% der Fälle testen. Angenommen, CriticalProcess () soll AppendFile () aufrufen, um Text anzufügen, ruft jedoch WriteFile () auf, um Text zu überschreiben.
%Vor%Wenn Sie keine Greenfield-Entwicklung mit TDD durchführen, ist es unwahrscheinlich, dass Sie eine 100% ige Testabdeckung erhalten (oder wollen). Code Coverage ist eher eine Richtlinie, etwas zu fragen "was habe ich nicht getestet?"
Sie können sich andere Metriken ansehen, z. B. zyklomatische Komplexität . Finden Sie die komplexen Bereiche Ihres Codes und testen Sie diese (dann Refactor zur Vereinfachung).
Es gibt 3 Hauptkomponenten, die Sie beachten sollten:
Wenn Sie diese Informationen haben, wird es wahrscheinlich nicht schwer sein zu entscheiden, wie Sie Ihre Testressourcen verteilen.
Falsches Sicherheitsgefühl: Sie sollten sich immer bewusst sein, dass die Testabdeckung zu einem falschen Sicherheitsgefühl führen kann. Ein toller Artikel über diese Tatsache findet sich im Disco-Blog . Wenn man sich jedoch auf die Informationen von "grünen" Indikatoren verlässt, kann man ungeprüfte Pfade übersehen.
Guter Indikator für nicht getestete Pfade: Andererseits ist die fehlende Testabdeckung, die meistens in Rot angezeigt wird, immer ein guter Indikator für Pfade, die nicht abgedeckt sind. Sie können diese zuerst überprüfen, da sie leicht zu erkennen sind und Ihnen erlauben, zu bewerten, ob Sie hier Testabdeckung hinzufügen möchten oder nicht.
Code-zentrierter Ansatz zum Identifizieren kritischer Elemente: Es gibt eine großartige Tool-Unterstützung, die Ihnen hilft, das Chaos und mögliche Fehler in Ihrem Code zu finden. Vielleicht möchten Sie sich die IntelliJ-IDE und ihre Funktionen zur Codeanalyse ansehen, zum Beispiel Findbugs, Checkstyle und PMD. Ein großartiges Werkzeug, das diese statischen Code-Analyse-Tools kombiniert, die kostenlos zur Verfügung steht, ist Sonar .
Feature-orientierte Annäherung zur Identifizierung kritischer Elemente: Bewerten Sie Ihre Software und teilen Sie sie in Funktionen auf. Stellen Sie sich Fragen wie: "Welche Funktionen sind am wichtigsten und sollten am zuverlässigsten sein? Wo müssen wir uns um die Korrektheit der Ergebnisse kümmern? Wo wäre ein Fehler oder ein Fehler am schädlichsten für die Software?"
Vielleicht ist der beste Hinweis, dass ein Modul nicht ausreichend behandelt wird, ein Fehlerbericht. Jedes Modul, das Sie immer wieder bearbeiten, sollte gut abgedeckt sein. Aber die zyklomatische Komplexität korreliert ziemlich gut mit der Fehlerhäufigkeit - und Sie können das messen, bevor die Fehler angezeigt werden!
Wenn Sie eine Legacy-Codebasis haben, ist ein guter Ausgangspunkt:
Fügen Sie einen Komponententest für jeden Fehler hinzu, den Sie finden und beheben. Der Komponententest sollte den Fehler reproduzieren, dann behebt du den Code und verwendest den Komponententest, um zu verifizieren, dass er behoben ist, und um dann sicher zu sein, dass er in Zukunft aus keinem Grund wieder bricht.
Wenn möglich, fügen Sie Tests zu wichtigen übergeordneten Komponenten hinzu, so dass viele Low-Level-Brüche immer noch einen Komponententestfehler verursachen (z. B. anstatt jede Datenbankzugriffsroutine unabhängig zu testen, einen Test hinzufügen, der eine Datenbank erstellt, fügt 100 Benutzer hinzu, löscht 50 davon, überprüft das Ergebnis und löscht die Datenbank.Sie werden nicht leicht sehen, wo der Fehler ist (Sie müssen debuggen, um herauszufinden, warum es fehlgeschlagen ist), aber Zumindest wissen Sie, dass Sie einen Test haben, der das gesamte Datenbanksystem ausübt und Sie schnell warnen wird, wenn in diesem Bereich des Codes etwas schief geht. Sobald Sie die Bereiche auf höherer Ebene abgedeckt haben, können Sie sich tiefer in die Sache vertiefen. p>
Fügen Sie Einheitentests für Ihren neuen Code hinzu oder wenn Sie einen Code ändern.
Im Laufe der Zeit wird dies Ihnen helfen, die Berichterstattung an den wichtigsten Orten aufzubauen.
(Denken Sie daran, dass, wenn Ihre Codebase Code verarbeitet, der seit Jahren funktioniert, Sie meistens keine Unit-Tests benötigen, um zu beweisen, dass sie funktioniert. Wenn Sie nur Unit-Tests hinzufügen, Sie werden praktisch alle bestehen und werden Ihnen daher nicht viel erzählen.Nachdem Ihre Abdeckung wächst, können Sie mit der Zeit anfangen, Regressionen aus diesen Tests zu erkennen, und Sie werden Fehler durch den Prozess des Hinzufügens von Komponententests für bisher ungeprüfte finden Code, aber wenn Sie nur durch den Code schlugen blind Blind Unit-Tests für alles hinzufügen, erhalten Sie ein sehr schlechtes Preis-pro-Fehler-Verhältnis)
An alle 90% -Tester:
Das Problem dabei ist, dass der 10% schwer zu testende Code auch der nicht-triviale Code ist, der 90% des Fehlers enthält! Dies ist die Schlussfolgerung, die ich nach vielen Jahren TDD empirisch erhielt.
Und nach all dem ist das ziemlich einfache Schlussfolgerung. Dieser 10% schwer zu testende Code ist schwer zu testen, weil er knifflige Geschäftsprobleme oder knifflige Designfehler oder beides widerspiegelt. Diese genauen Gründe führen oft zu fehlerhaften Code.
Aber auch:
Das hängt ganz von der Art der Software ab, die Sie entwickeln. Wenn es remote zugänglich ist, sollte die Sicherheitsprüfung die höchste Priorität haben. Bei Webanwendungen gibt es automatisierte Tests wie Sitewatch oder Wapiti, die verwendet werden können. Es gibt auch Tools, mit denen Sie Komponententests für SOAP generieren können.
Tags und Links testing