Was ist Modultest? Definition, Beispiele

Was ist Modultest?

Modulprüfung Modultests sind eine Art von Softwaretests, die einzelne Unterprogramme, Unterroutinen, Klassen oder Prozeduren eines Programms überprüfen. Anstatt das gesamte Softwareprogramm auf einmal zu testen, empfiehlt der Modultest, die kleineren Bausteine ​​des Programms zu prüfen.

Modultests sind größtenteils White-Box-orientiert. Ziel von Modultests ist nicht der Nachweis der korrekten Funktion des Moduls, sondern das Aufdecken eines Fehlers. Diese Umkehrung ist wichtig: Ein Testlauf, der nichts findet, hat wenig bestätigt, wohingegen ein Testlauf, der einen Fehler aufdeckt, seinen Zweck erfüllt hat.

Durch das Testen auf Modulebene wird auch die Parallelisierung des Testprozesses ermöglicht, da so die Möglichkeit geschaffen wird, mehrere Module gleichzeitig zu testen, anstatt auf einen vollständigen Build zu warten.

Warum Modultests durchführen?

Modultests werden empfohlen, da sie die Wirtschaftlichkeit der Fehlererkennung verändern.

• Die Wahrscheinlichkeit, Fehler oder Bugs in kleineren Programmteilen zu identifizieren, steigt.
• Mehrere Module können gleichzeitig getestet werden, daher unterstützt der Ansatz parallele Tests.
• Die Komplexität der Tests lässt sich leicht bewältigen, da jedes Modul für sich betrachtet wird.
• Ein Defekt, der in einem Modul gefunden wurde, ist tracEs ist auf eine kleine Menge Code beschränkt, wodurch sich die Debugging-Zeit drastisch reduziert.

Wie führt man Modultests durch?

Designing a Testfall ist ein wichtiger Bestandteil des Modultests. Beim Entwurf von Testfällen für einen Modultest muss der Tester zwei Dinge berücksichtigen.

• Spezifikation für das Modul
• Der Quellcode des Moduls

Analysieren Sie die Logik des Moduls mithilfe einer oder mehrerer der folgenden Methoden: weiße Kiste Methoden anwenden und diese Testfälle anschließend durch die Anwendung ergänzen. Flugschreiber Methoden zur Modulspezifikation. Realistische Werte sind ebenso wichtig wie die gewählten Pfade, also bereiten Sie die Testdaten parallel zu den Fällen und nicht im Nachhinein.

Sobald die Testfälle entworfen sind, besteht der nächste Schritt darin, die Module für die Tests zu kombinieren. Die verwendete Methode ist entweder eine inkremental oder die nicht-inkrementell Methode.

• Nichtinkrementelles Verfahren — Alle Module werden einzeln getestet. Zuerst werden alle Module kombiniert und dann das gesamte Programm getestet.
• Inkrementelle Methode — Jedes Modul wird zunächst getestet und dann schrittweise der Testsammlung hinzugefügt. Es wird ein schrittweiser Wiederholungstest durchgeführt.
• Beim inkrementellen Testen gibt es zwei Ansätze. von oben nach unten und von unten nach oben Testen.
• Um das Modul mit den ausgewählten Daten auszuführen, wird ein Treiber benötigt, der die Testdaten bereitstellt, die Ausführung überwacht und die Ergebnisse erfasst.

Die Wahl zwischen den beiden Methoden ist ein Kompromiss zwischen Einrichtungsaufwand und Diagnostizierbarkeit.

Treiber und Stubs im Modultest

Der oben erwähnte Treiber ist die eine Hälfte eines Paares. Da sich ein zu testendes Modul selten am Anfang oder Ende der Aufrufkette befindet, ersetzen Tester fehlenden Code auf beiden Seiten durch Dummy-Code.

• LED Treiber — ersetzt das aufrufende Modul über dem zu testenden Modul. Es liefert die Testdaten, ruft das Modul auf, überwacht die Ausführung und erfasst die Ergebnisse. Bottom-up-Tests sind von Treibern abhängig, da die unteren Module vor den höheren bereit sind.
• Stummel — ersetzt ein aufgerufenes Modul unterhalb des zu testenden Moduls. Es nimmt den Aufruf entgegen und gibt eine festgelegte, bekannte Antwort zurück, damit das zu testende Modul seinen Ablauf abschließen kann. Top-Down-Tests sind auf Stubs angewiesen, da die übergeordneten Module zuerst bereit sind.

Ein ausgearbeitetes Beispiel verdeutlicht die Zuordnung. Wenn ein Modul zur Zahlungsberechnung fertig ist, die zugehörige Checkout-Seite aber noch nicht, übergibt ein Treiber dem Modul die Bestellsummen und protokolliert die Rückgabewerte. Ist der vom Modul aufgerufene Steuerabfragedienst ebenfalls noch nicht fertig, gibt ein Stub einen festen Steuersatz zurück, damit die Berechnung trotzdem ausgeführt werden kann. Beide Gerüstbausteine ​​werden nicht mitgeliefert; sie werden verworfen, sobald die eigentlichen Module verfügbar sind. Daher wird das Missverständnis von Test-Doubles später als wiederkehrende Herausforderung aufgeführt.

Beispieltipps für Modultests

Hier sind ein paar Tipps, die Sie vor dem Testen von Modulen beachten sollten.

• RevSehen Sie sich die Testfälle an, bevor Sie sie verwenden.
• Vermeiden Sie Verwirrung über die Ursache von Abweichungen.
• Nutzen Sie automatisierte Testwerkzeuge.
• Untersuchen Sie die Variablen, die unverändert bleiben sollten.
• Um Selbsttests zu vermeiden, sollten die Module zwischen den Testern getauscht werden.
• Die Testfälle wiederverwenden.

Der fünfte Tipp ist wichtiger, als seine Kürze vermuten lässt. Ein Entwickler, der nur das gerade geschriebene Modul testet, wiederholt dieselben Annahmen, die den Fehler verursacht haben. Daher ist der Austausch von Modulen zwischen verschiedenen Personen eine der kostengünstigsten Möglichkeiten zur Qualitätsverbesserung.

Unit-Tests vs. Modultests

Die beiden Begriffe werden in vielen Teams synonym verwendet, doch Urheberschaft und Geltungsbereich unterscheiden sich.

Modultests vs. Komponententests vs. Integrationstests

Die Modulprüfung liegt zudem neben zwei benachbarten Ebenen, die leicht mit ihr verwechselt werden können. Die Tabelle unterscheidet sie danach, was geprüft wird und wer die Prüfung üblicherweise durchführt.

Im alltäglichen Gebrauch Komponententests und Modultests werden häufig als ein und dieselbe Aktivität behandelt, Integrationstests beginnt erst, wenn jedes einzelne Modul nacheinander erfolgreich abgeschlossen wurde.

Herausforderungen beim Modultesten

Dies sind die Herausforderungen, denen Teams am häufigsten begegnen, wenn Modultests eingeführt werden.

• Nicht-inkrementelle Tests erfordern mehr Arbeit — Wenn man zuerst alles kombiniert, bedeutet das, dass ein einziger Fehler dazu führen kann, dass die Tester das gesamte Programm erneut durchlaufen müssen.
• Missverständnisse beim Test verdoppeln — Ein Stub, der einen unrealistischen Wert zurückgibt, erzeugt einen grünen Lauf, der nichts beweist.
• Debugging-Tests oft — Gerüstcode birgt seine eigenen Mängel, und Zeit, die mit der Behebung eines Treiberfehlers verbracht wird, ist Zeit, die nicht mit dem Testen des Moduls verbracht werden kann.
• Muss den Code verstehen — Die Ausrichtung nach dem White-Box-Prinzip bedeutet, dass ein Tester, der das Modul nicht lesen kann, auch keine sinnvollen Testfälle dafür entwerfen kann.

Häufig gestellte Fragen