Strenge bei der Erfassung von Testfällen für Einheitstests

Question

Nehmen wir an, wir haben eine einfache Funktion in einer Pseudosprache definiert.

List<Numbers> SortNumbers(List<Numbers> unsorted, bool ascending);

Wir übergeben eine unsortierte Liste von Zahlen und einen Booleschen Wert, der die aufsteigende oder absteigende Sortierreihenfolge angibt. Im Gegenzug erhalten wir eine sortierte Liste von Zahlen.

Meiner Erfahrung nach sind manche Leute besser im Erfassen von Randbedingungen als andere. Die Frage ist: "Woher wissen Sie, wann Sie mit der Erfassung von Testfällen 'fertig' sind"?

Wir können jetzt mit der Aufzählung der Fälle beginnen, und irgendeinem klugen Kopf wird zweifellos noch ein weiterer Fall einfallen, der von keinem der bisherigen Fälle abgedeckt wird.

Answer 1

Vergeuden Sie nicht zu viel Zeit mit dem Gedanken an jede Randbedingung. Ihre Tests werden nicht in der Lage sein, die jede Fehler beim ersten Mal. Die Idee ist, Tests zu haben, die ziemlich gut und dann jedes Mal, wenn ein Fehler tut Oberfläche, schreiben Sie einen neuen Test speziell für diesen Fehler, so dass Sie nie wieder etwas von ihm hören.

Noch eine Anmerkung zu Code Coverage Tools. In einer Sprache wie C# oder Java, in der Sie viele get/set- und ähnliche Methoden haben, sollten Sie pas eine 100%ige Abdeckung anstreben. Das bedeutet, dass Sie zu viel Zeit damit verschwenden, Tests für trivialen Code zu schreiben. Sie nur eine 100%ige Abdeckung Ihrer komplexen Geschäftslogik wünschen. Wenn Ihre gesamte Codebasis zu 70-80 % abgedeckt ist, haben Sie gute Arbeit geleistet. Wenn Ihr Codeabdeckungstool mehrere Abdeckungsmetriken zulässt, ist die beste die "Blockabdeckung", die die Abdeckung der "Basisblöcke" misst. Andere Typen sind Klassen- und Methodenabdeckung (die nicht so viele Informationen liefern) und Zeilenabdeckung (die zu feinkörnig ist).

Answer 2

Woher wissen Sie, wann Sie mit der Erfassung von Testfällen "fertig" sind?

Das ist nicht der Fall. Sie können keine 100 % erreichen, außer in den trivialsten Fällen. Auch eine 100%ige Abdeckung (von Linien, Pfaden, Bedingungen...) sagt nicht aus, dass Sie alle Randbedingungen getroffen haben.

Am wichtigsten ist, dass die Testfälle nicht einfach geschrieben und vergessen werden können. Jedes Mal, wenn Sie einen Fehler finden, schreiben Sie einen zusätzlichen Test. Prüfen Sie, ob es mit dem ursprünglichen Programm fehlschlägt, prüfen Sie, ob es mit dem korrigierten Programm funktioniert, und fügen Sie es zu Ihrem Testsatz hinzu.

Ein Auszug aus Die Kunst des Softwaretestens von Glenford J. Myers:

1. Wenn eine Eingabebedingung einen Wertebereich vorgibt, schreiben Sie Testfälle für die Enden des Bereichs und Testfälle mit ungültigen Eingaben für Situationen, die direkt hinter den Enden liegen.
2. Wenn eine Eingabebedingung eine Anzahl von Werten vorgibt, schreiben Sie Testfälle für die minimale und maximale Anzahl von Werten und einen darunter und darüber hinaus.
3. Verwenden Sie Leitfaden 1 für jede Ausgabebedingung.
4. Verwenden Sie Leitfaden 2 für jede Ausgabebedingung.
5. Wenn die Eingabe oder Ausgabe eines Programms eine geordnete Menge ist, konzentrieren Sie sich auf das erste und das letzte Element der Menge.
6. Suchen Sie darüber hinaus mit Ihrem Einfallsreichtum nach weiteren Randbedingungen

( Aus urheberrechtlichen Gründen habe ich nur das Nötigste eingefügt. )

Die Punkte 3. und 4. oben sind sehr wichtig. Man vergisst oft die Randbedingungen für die Ausgänge. 5. ist in Ordnung. 6. hilft nicht wirklich weiter :-)

Kurze Prüfung

Das ist schwieriger, als es aussieht. Myers bietet diesen Test an:

Das Programm liest drei ganzzahlige Werte aus einem Eingabedialog. Die drei Werte stellen die Längen der Seiten eines Dreiecks dar. Das Programm zeigt eine Meldung an, die angibt, ob es sich um ein schalenförmiges, gleichschenkliges oder gleichseitiges Dreieck handelt.

Erinnern Sie sich daran, dass ein ungleichseitiges Dreieck ein Dreieck ist, bei dem keine zwei Seiten gleich lang sind, während ein gleichschenkliges Dreieck zwei gleiche Seiten hat und ein gleichseitiges Dreieck drei gleich lange Seiten hat. Außerdem sind die Winkel, die den gleichen Seiten in einem gleichschenkligen Dreieck gegenüberliegen, ebenfalls gleich (daraus folgt auch, dass die Seiten, die gleichen Winkeln in einem Dreieck gegenüberliegen, gleich sind), und alle Winkel in einem gleichseitigen Dreieck sind gleich.

Schreiben Sie Ihre Testfälle. Wie viele haben Sie? Myers stellt 14 Fragen zu Ihrem Testsatz und berichtet, dass hochqualifizierte professionelle Programme im Durchschnitt 7,8 von 14 möglichen Punkten erreichen.

Answer 3

Aus praktischer Sicht erstelle ich eine Liste von Tests, die meiner Meinung nach vor der Annahme bestanden werden müssen. Ich teste diese Tests und automatisiere sie, wo es möglich ist. Je nachdem, wie viel Zeit ich für die Aufgabe veranschlagt habe oder wie viel Zeit mir zur Verfügung steht, erweitere ich meine Testabdeckung um die Punkte, die vor der Abnahme bestanden werden sollten. Natürlich ist die Grenze zwischen "müssen" und "sollen" subjektiv. Danach aktualisiere ich die automatisierten Tests, wenn Fehler entdeckt werden.

Answer 4

Ein gutes Code-Coverage-Tool ist sehr hilfreich.

Eine 100-prozentige Abdeckung bedeutet nicht, dass sie definitiv angemessen getestet ist, aber sie ist ein guter Indikator.

Für .Net ist NCover recht gut, ist aber nicht mehr quelloffen.

---

@Mike Stone - Ja, vielleicht hätte es "hohe Abdeckung" heißen sollen - wir streben mindestens 80 % an, über 95 % hinaus sinkt die Rentabilität in der Regel, vor allem, wenn man Code mit geschweiften Klammern hat.

Answer 5

@Keith

Ich denke, Sie haben es auf den Punkt gebracht. Codeabdeckung ist wichtig, wenn Sie sehen wollen, wie "fertig" Sie sind, aber ich denke, 100% ist ein etwas unrealistisches Ziel. Wenn Sie 75-90% anstreben, erhalten Sie eine ziemlich gute Abdeckung, ohne zu übertreiben... Testen Sie nicht nur, um 100% zu erreichen, denn dann verschwenden Sie nur Ihre Zeit.