Wie erfahre ich, wann ich mit dem Testen aufhören soll?

Ich weiß, dass dies eine sehr sehr grundlegende Frage ist. Für einige Softwareanwendungen gibt es eine große, nahezu unbegrenzte Anzahl von Testfällen für eine Anwendung. Es ist nicht praktisch, alle diese Testfälle zu testen. Wie entscheiden wir, wann wir mit dem Testen aufhören sollen? (außer "wenn das Geld ausgeht").

Glenford Myers 'Buch The Art of Software Testing hat eine einfache, aber prinzipielle Regel: Das Testen ist abgeschlossen, wenn Sie keine Bugs mehr finden. Oder praktischer, wenn sich die Geschwindigkeit, mit der Sie neue Fehler finden, erheblich verlangsamt.

Fehler "gruppieren" sich in bestimmten Modulen und Funktionen: Sobald Sie einen Fehler in einem finden, wissen Sie, dass Sie weiter nach weiteren Fehlern suchen sollten. Um Fehler zu finden, können Sie die Techniken des Blackbox-Tests, des Whitebox-Tests und des Mutationstests verwenden. Solange Sie Fehler finden, wissen Sie, dass Ihr Testprozess funktioniert!

Um Ihren Fortschritt zu visualisieren, zeichnen Sie die Anzahl der Fehler auf, die Ihr Team pro Tag gefunden hat. Wenn die Grafik abfällt, wissen Sie, dass die Techniken, die Ihr Team verwendet, sie sowieso nicht finden werden. Wenn Sie der Meinung sind, dass Ihre Techniken nicht den Anforderungen entsprechen, lesen Sie bitte Myers 'Buch und wenden Sie die Prinzipien an.

Jetzt besteht die Möglichkeit, dass Sie möglicherweise nicht genügend neue Fehler finden, und die Häufigkeit, Fehler zu finden, wäre erheblich gestiegen, wenn Sie noch ein bisschen mehr getestet hätten. Wenn Sie jedoch glauben, dass Ihre Techniken solide sind, ist dies unwahrscheinlich.

Die einfache Antwort ist, dass es vom System abhängt. Wenn Sie eingebettete Software für einen Herzmonitor oder Sicherheitsüberwachungs-Tools für einen Kernreaktor schreiben, ist der Standard weit höher als beim Schreiben einer Blogging-Plattform.

Dies ist wirklich eine Frage für einen guten Systemtester (und ich bin keine), aber ich werde es versuchen.

Ihre grundlegende Maßnahme wird die Testabdeckung sein: Wie viel der Anwendung wurde tatsächlich getestet (sowohl durch Komponententest als auch funktionell).

Sie müssen jeden potenziellen Anwendungsfall (und die Parameter für diesen Anwendungsfall) auf die Wahrscheinlichkeit prüfen, dass er tatsächlich verwendet wird (so dass Sie Randfälle löschen können), auf die Komplexität (einfachere Dinge enthalten mit geringerer Wahrscheinlichkeit Fehler oder eher mit geringerer Wahrscheinlichkeit schwerwiegende Fehler) Fehler zu finden), Testkosten (in Bezug auf die Zeit) und mögliche Auswirkungen eines Fehlers, wenn er in diesem Bereich entdeckt wird (hier kommt der Kernreaktor gegen die Blogging-Plattform ins Spiel).

Basierend auf dieser Einschätzung müssen Sie herausfinden, welche davon wie detailliert getestet werden sollen. Sobald Sie eine solche Liste haben, kann das Team (einschließlich eines Produktmanagers / Projektmanagers / Anwendervertreters) diese Liste durchgehen und anhand der von Ihnen festgelegten Einschränkungen Prioritäten setzen.

Eine nützliche Technik, über die Sie nachdenken sollten, ist, dass Sie auch die Anwendungsfälle variieren können, die mit jeder Version getestet werden. Zum Beispiel könnten Sie eine Liste nicht kritischer Testfälle haben und die Hälfte mit einer Version und die andere Hälfte mit der nächsten (dann alternierend) testen. Auf diese Weise erhöhen Sie die gesamte Testabdeckung, die Sie für den Aufwand erhalten (obwohl das Risiko besteht, dass Regressionsfehler auftreten).

Dies könnte sich auch auf Plattformtests auswirken - wenn Sie zwei Datenbank-Back-Ends (oder mehrere Browser) unterstützen, testen Sie die eine Hälfte der App auf der anderen, die andere Hälfte auf der anderen und tauschen Sie dann die nächste Version aus.

(Ich denke, dies wird als Striping bezeichnet, aber zitiere mich nicht dazu.)

Und dann ist das Letzte, worüber Sie nachdenken müssen, nicht das, was Sie testen, sondern das, was Sie tatsächlich beheben, wenn Probleme entdeckt werden. Es ist üblich zu sagen "alle Fehler beheben", aber die Realität ist, dass es Zeitdruck gibt und nicht alle Fehler gleich sind. Auch hier sind regelmäßige Bug-Scrubs mit allen relevanten Parteien der beste Weg nach vorne. Dies ist besonders relevant, wenn eine Fehlerbehebung besonders aufdringlich sein kann, da der zusätzliche Aufwand beim erneuten Testen und Regressionstesten den Nutzen der Fehlerbehebung überwiegen kann.

Wenn das mit der Verwendung der Software verbundene Risiko auf ein akzeptables Maß gesenkt wurde.

"Programmtests können verwendet werden, um das Vorhandensein von Fehlern anzuzeigen, aber niemals, um deren Abwesenheit zu zeigen!" - Edsger Dijkstra

Etwas Gutes, das Sie beim Testen beachten sollten, sei es automatisiert oder auf andere Weise. Sie können nur beweisen, dass Sie keine Bugs mehr gefunden haben, nicht, dass es keine mehr gibt.

Je mehr Augen Sie jedoch auf einen Codeabschnitt richten, desto sicherer können Sie sein, dass er ordnungsgemäß funktioniert. Diesbezüglich ähnelt es Knuths Zitat zur Optimierung: Sie können das falsche Zeug sehr einfach testen und Sie können es zu den falschen Zeitpunkten in Ihrer Entwicklung testen.

Im Wesentlichen möchten Sie an zwei großen Orten abgedeckt werden:

1. Besteht die Software die BDD-Tests, die belegen, dass sie die angegebenen Anforderungen erfüllt? Die Software kann nicht einmal als erledigt bezeichnet werden, wenn dies nicht zutrifft.

2. Haben die kritischsten, komplexesten und unsichersten Segmente angemessene Tests, um Vertrauen zu schaffen? Wenn es sich um eine Kernschleife handelt oder etwas, das Sie optimieren oder hacken mussten: Testen Sie es. Wenn es kompliziert ist und viele logische Spaltungen aufweist: Machen Sie viele Tests damit. Wenn Sie es nicht als Unit testen können oder es zu tief eingebettet ist, um es praktisch direkt zu testen: Stellen Sie sicher, dass der Code überprüft und der Code indirekt von Hand getestet wurde.

Wenn Sie warten, bis das Projekt abgeschlossen ist, haben Sie in der Tat eine sehr große Anzahl von Testfällen. Wenn Sie kontinuierlich liefern und sich auf kleine Lieferungen konzentrieren, haben Sie bei jeder Iteration weniger Testfälle und können alles testen. Wenn Sie keine kleinen Lieferungen durchführen können, setzen Sie Prioritäten und beginnen Sie mit dem Testen mit der höchsten Priorität, und testen Sie, bis Sie aufhören müssen.

Wenn Sie über Komponententests sprechen und TDD durchführen (schreiben Sie zuerst die Tests), ist dies kein Problem: Sie hören einfach auf zu testen, wenn die Funktionen fertig sind.

In inkrementellen TDD schreiben Sie einen Test, der fehlschlägt, implementieren dann die kleinste Menge an Code, die durchgelassen werden kann, und refaktorisieren dann. Fügen Sie weitere Tests auf diese Weise hinzu, bis die Methode vollständig ist.

Hier ist ein gutes Beispiel.

Auch Statistiker haben sich mit diesem Thema befasst - eigentlich schon in den 1970er- und 1980er-Jahren. Bei angemessenen Annahmen darüber, wie Fehler entdeckt werden, wird versucht, die Anzahl der Fehler anhand der Testdaten zu schätzen. Dies wird dann verwendet, um basierend auf der Optimierung einer Verlustfunktion zu bestimmen, wann zu stoppen ist. Unter https://rpubs.com/hoehle/17920 ... finden Sie eine kurze Beschreibung eines der Artikel zu diesem Thema, einschließlich eines R-Codes, wie dies in der Praxis durchgeführt wird.

Ein Problem werden natürlich immer die Annahmen über den Fehlererkennungsprozess sein. Beispielsweise wird in der obigen Behandlung angenommen, dass Fehler unabhängig voneinander entdeckt werden. In der Praxis kann das Beheben eines großen Fehlers z. B. zu neuen Fehlern usw. führen. Es gibt jedoch einen Anfang und ergänzt das Bauchgefühl.

Wann ist das Versanddatum eingetroffen? Das Testen einer Software hat kein Ende. Aber andererseits gibt es etwas, das als Zeitplan bekannt ist. Sie müssen den größten Teil Ihrer Funktionen in der geplanten Zeit testen und die aufgetretenen Fehler beheben. Sie können nicht garantieren, dass die Software perfekt ist.

Die ersten Dinge, die getestet werden müssen, sind der "Happy Path", Randfälle und ungültige Eingaben. Wenn es mehr als einen Benutzer gleichzeitig gibt, müssen Sie auf Parallelitätsprobleme wie Sperren und Rennbedingungen prüfen. Wenn die App externe Ressourcen verwendet, müssen Sie testen, wie sich die App verhält, wenn diese Ressourcen nicht verfügbar sind. Danach können Sie den Code verwenden, um nach Dingen zu suchen, die dazu führen könnten, dass er beschädigt wird, und diese testen. Wenn alle diese Tests bestanden sind, steigt das Kosten-Nutzen-Verhältnis der weiteren Tests. Es ist also sinnvoll, an diesem Punkt anzuhalten.

Auf das Vertrauen kommt es an. Sind Sie zuversichtlich, dass das System ausreichend getestet wurde?

Offensichtlich ist das "Vertrauensniveau" sehr subjektiv, da Sie sich nie ganz sicher, aber sicher genug fühlen können - und das ist es, wonach wir suchen. Dazu müssen Sie eine Liste von Indikatoren erstellen, die gemeinhin als Definition von „erledigt“ bezeichnet werden und auf die sich Ihr gesamtes Team einigen sollte.

Hier sind einige testbezogene "Done-Indikatoren":

• Ist Ihr Build und Ihre Installation vollständig automatisiert und werden alle Tests (Unit, GUI, Integration) automatisch ausgeführt?
• Schreiben Sie Ihre Tests eher während (oder vorzugsweise vor) dem Schreiben des Codes als nach?
• Fühlen Sie sich sicher genug, um umfangreiches Code-Refactoring durchzuführen, ohne Fehler einzuführen?
• Ist Ihre Codeabdeckung hoch genug?
• Haben Sie einen engagierten Tester in Ihrem Team? Ist er / sie während der gesamten Entwicklung täglich involviert und nicht nur am Ende?
• Hat Ihr Tester manuell (explorativ) versucht, es ohne Erfolg zu brechen?

Wenn Sie diese Punkte überprüfen können, können Sie wahrscheinlich sagen, dass Sie genug getestet haben.

Niemals, ich glaube, Sie werden das Testen in einem System nie zu Ende bringen. Es gibt so viele Variablen, die Sie nicht verwalten können.

Aber, wie wir wissen, kann man nicht "für immer" testen, daher denke ich, dass das Limit im Wesentlichen von Folgendem abhängt:

• Wenn das mit der Verwendung der Software verbundene Risiko auf ein akzeptables Maß gesenkt wurde. (wie @ Abraham Lee sagt)
• Wer ist der Systembenutzer? Es kann Sie oder der Präsident der Vereinigten Staaten sein. Im ersten Fall ist es dir egal, ob ein Fehler auftritt, weil du ihn behebst und er erledigt ist. Im zweiten Fall soll KEIN Fehler auftreten.
• In welcher Beziehung stehen Sie zu Ihrem Kunden? Vielleicht ist der Kunde dein Vater, also ist es nicht so schlimm, oder vielleicht ist es eine große Firma.
• Wie ernst ist ein Fehler für die Systembenutzer? Verursacht es den dritten Weltkrieg oder nur eine hässliche Botschaft?

Wenn die Personen, die sich bei der Bereitstellung abmelden müssen, zufrieden sind.

oder in einigen Fällen ist die Mehrheit der Verantwortlichen zufrieden.