Auf dem Weg zu einer vollständigen Abdeckung durch Regressionstests

So überraschend es auch klingen mag, sogar vollständig Pfadabdeckung bedeutet nicht, dass sich Ihr Code immer korrekt verhält.

Wenn Sie einen testgetriebenen Entwicklungsansatz (TDD) verwenden, sind Sie mit der Idee vertraut, Komponententests als eine Art Spezifikation für den zu testenden Code zu verwenden. Sie schreiben zuerst einen Test, der bestätigt, was eine neue Methode tun soll, beobachten, wie sie fehlschlägt, und fügen gerade genug Implementierungscode hinzu, damit sie erfolgreich ist. Wenn Sie einem Entwickler den Testfall aus Listing 4 zeigen und nach einer Implementierung fragen, ist das Ergebnis möglicherweise eine Methode, die immer 0 zurückgibt, wie in Listing 5 gezeigt. Interessanterweise würde der Entwickler damit nicht einmal den Geist von TDD verletzen . Es würde eine 100% ige Pfadabdeckung und keinen Testfehler geben, aber die Implementierung würde offensichtlich nicht richtig funktionieren. Im wirklichen Leben treten solche Probleme selten in Form einfacher Methoden auf, die zwei Werte hinzufügen, aber normalerweise eine kompliziertere Form annehmen. Das grundlegende Problem besteht darin, dass eine Reihe von Komponententests möglicherweise eine vollständige Pfadabdeckung für eine Methode bietet, gleichzeitig jedoch möglicherweise keine vollständige Spezifikation dieser Methode liefert. Ein typisches Szenario besteht darin, dass ein Entwickler die Implementierung einer vorhandenen Methode so optimiert, dass alle Testfälle noch bestehen, aber zuvor nicht aktivierte Funktionen versehentlich entfernt oder geändert werden. Dies kann auch bei 100% Pfadabdeckung passieren.

Das veranschaulichende Codebeispiel aus Listing 2 würde 256 verschiedene Testfälle (für alle möglichen Werte des Typbytes) erfordern, um vollständig zu sein Regressionstests Abdeckung. Ohne die zusätzlichen Testfälle könnte ein Entwickler die ursprüngliche Implementierung durch vereinfachten Code ersetzen, der nur für die Testeingaben 0, 1, 2 und 3 korrekte Ergebnisse zurückgibt, für alle anderen Eingaben jedoch einfach eine Ausnahme für nicht unterstützte Operationen auslöst. Alle vorhandenen Testfälle bestehen, ein Teil der ursprünglichen Funktionalität geht jedoch verloren. Selbst eine Reihe von Komponententests, die eine vollständige Pfadabdeckung bieten, kann eine solche Regression nicht garantieren.

Wenn es bereits schwierig ist, eine Pfadabdeckung zu erreichen, kann eine vollständige Regressionsabdeckung nur als praktische Unmöglichkeit bezeichnet werden. Die add-Methode aus Listing 4 verwendet zwei ganzzahlige Parameter, von denen jeder 232 verschiedene Werte annehmen kann. Eine vollständige Regressionsabdeckung für diese Methode würde 264 (dh 232 × 232) Testfälle erfordern. Mit einem cleveren parametrisierten Testansatz wäre es möglich, alle diese Testfälle kompakt darzustellen, aber es wäre unmöglich, alle Tests innerhalb eines angemessenen Zeitrahmens durchzuführen. Eine vollständige Regressionsabdeckung würde sogar subtile Probleme wie den berüchtigten Pentium FDIV-Fehler erkennen. Leider ist es in jeder Hinsicht völlig unpraktisch.

Das Versäumnis, das ordnungsgemäße Funktionieren von etwas so Einfachem wie einer Additionsmethode zu gewährleisten, ist nicht gerade vertrauensinspirierend. Was können Sie in der Praxis tun, um ein angemessenes Maß an Schutz vor Regressionsfehlern zu erreichen, ohne Testfälle zu erstellen, in denen jede mögliche Kombination von Eingaben ausgeführt wird? Je mehr verschiedene Eingaben Sie bei einer getesteten Methode ausführen, desto besser ist natürlich Ihre Regressionsabdeckung. Die Frage ist, welche Eingaben Sie für Ihre Testfälle auswählen müssen. Extremwerte (oder sogenannte „Eckfälle“) sind eine gute Wahl. Testeingaben für einen int-Parameter können beispielsweise Integer.MAX_VALUE, Integer.MAX_VALUE-1, 1, 0, -1, Integer.MIN_VALUE + 1 und Integer.MIN_VALUE als Testeingaben verwenden. In ähnlicher Weise sind eine Nullreferenz, eine leere Zeichenfolge und verschiedene Zeichenfolgen, die Sonderzeichen enthalten, gute Testeingaben für einen Zeichenfolgenparameter.

Testfälle, die auf eine verbesserte Regressionsabdeckung abzielen, haben häufig eine gemeinsame Teststruktur, verwenden jedoch unterschiedliche Eingabewerte. In diesen Situationen kann es hilfreich sein, Tools zu verwenden, die die Parametrisierung von Testfällen unterstützen. Diese extrahieren die allgemeine Teststruktur und trennen die Testdaten in eine Excel-Tabelle oder einen anderen externen Datenspeicher. Eine weitere Option zur Verbesserung der Regressionsabdeckung einer Testsuite ist das sogenannte Störungstest, bei dem geringfügige Änderungen (z. B. Hinzufügen oder Subtrahieren einer kleinen Zahl) auf Eingabewerte aus vorhandenen Tests angewendet werden, um neue interessante Codepfade freizulegen und zuvor zu bestätigen unbestätigtes Verhalten. Eckfallwerte und Störungstests sind eher heuristisch als systematisch, aber beide können die Regressionsabdeckung erhöhen und können manuell oder mit automatisierten Tools wie Parasoft Jtest angewendet werden.

Tabelle 1 enthält eine Zusammenfassung der Testfälle, die erforderlich sind, um eine 100% ige Aussage, Verzweigung, Pfad und vollständige Regressionsabdeckung für die getestete Methode aus Listing 2 zu erreichen.

Tabelle 1: Testen Sie die Eingaben, um eine 100% ige Abdeckung von Listing 2 zu erreichen