Modultest

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Ein Modultest (auch Komponententest oder oft vom engl. unit test als Unittest bezeichnet) wird in der Softwareentwicklung angewendet, um die funktionalen Einzelteile ('Module') von Computerprogrammen zu testen, d. h. sie auf korrekte Funktionalität zu prüfen.

Der Ausdruck 'Modultest' wird auch als eine frühe Teststufe verstanden[1], in der die inneren, detailliertesten Komponenten der Software getestet werden. Siehe dazu auch die Grafik 'Stufen des V-Modells' und V-Modell (nach Barry Boehm).

Inhaltsverzeichnis

Einordnung im Testprozess [Bearbeiten]

Da Algorithmen auf Modulebene meist nur eine begrenzte Komplexität aufweisen und über klar definierte Schnittstellen aktiviert werden, können sie mit relativ wenigen Testfällen weitgehend vollständig getestet werden. Dies gilt als Voraussetzung für die anschließende Teststufe Integrationstest, um dort die Testfälle auf das integrierte Zusammenwirken größerer Funktionsteile oder der gesamten Anwendung ausrichten zu können; die modulspezifischen Detailkonstellationen lassen sich damit dort auf Stichproben beschränken, was die Anzahl der erforderlichen Testfälle drastisch reduziert.

Zum Vergleich: Ein Gerät wird erst dann als Ganzes getestet, wenn die Funktionsfähigkeit seiner Einzelteile als gesichert gilt.

Testtechniken [Bearbeiten]

Aus dem Spektrum der zahlreichen Bezeichnungen für Testarten/Testtechniken treffen für Modultests besonders die folgenden zu:

  • Entwicklertest; zum Testen werden häufig Testversionen der Software bereitgestellt, um z. B. Eingaben zu simulieren oder Ergebnisse zu protokollieren.
  • White-Box-Test; die zu testenden funktionalen Details und ihre möglichen Kombinationen sind oft nur aus dem Quellcode oder sehr detaillierten technischen Spezifikationen ableitbar.
  • Äquivalenzklassentest; die Testkonstellationen können damit auf das Testen bestimmter Grenzwerte beschränkt werden.

Verfahren zur Testfalldefinition [Bearbeiten]

Modultests zählen zu den White-Box-Tests. Das heißt, dass bei der Definition der Testfälle der zu testende Quellcode bekannt ist. Die Spezifikation der Software wird lediglich für die Bestimmung der Soll-Ergebnisse benutzt. Prinzipiell müssen alle Quellcode-Teile mindestens einmal ausgeführt werden. Anweisungsüberdeckung, Zweigüberdeckung oder Pfadüberdeckung können dabei helfen festzustellen, welche Testfälle hierzu in der Theorie mindestens erforderlich sind (siehe dazu Kontrollflussorientierte Testverfahren). In der Praxis versucht man in aller Regel, das gesetzte Überdeckungsziel mit möglichst wenigen Testfällen zu erreichen, da alle Modultests auch laufend gepflegt werden müssen.

Verfahren zum Erstellen von Modultests [Bearbeiten]

Üblicherweise orientieren sich alle Modultests an einem einheitlichen Grundaufbau. Dabei wird zunächst (1) ein Ausgangszustand initialisiert, hierauf (2) die zu testende Operation ausgeführt und zuletzt (3) das Ist-Ergebnis mit einem aus der Spezifikation abgeleiteten Sollwert verglichen. Für diese Vergleiche stellen die Test Frameworks "assert"-Methoden (deutsch etwa: feststellen, versichern) zur Verfügung.

Eigenschaften von Modultests [Bearbeiten]

Isoliert
Modultests testen die Module isoliert, d. h. ohne die Interaktion der Module mit anderen. Ist das nicht der Fall spricht man stattdessen von Integrationstests. Deshalb müssen bei Modultests andere Module beziehungsweise externe Komponenten wie etwa eine Datenbank, Dateien oder Backendsysteme durch sogenannte Mock-Objekte simuliert (engl. to mock) werden, soweit das Modul diese benötigt. Auch dafür verwendet man üblicherweise Frameworks wie beispielsweise Easymock. Die Funktionalität der Module kann so meist einfacher getestet werden, als wenn die Module bereits integriert sind, da in diesem Fall die Abhängigkeit der Einzelmodule mit in Betracht gezogen werden muss.
Test des 'Vertrages' und nicht der Algorithmen
Modultests testen gemäß dem Design-by-contract-Prinzip möglichst nicht die Interna einer Methode, sondern nur ihre externen Auswirkungen (Rückgabewerte, Ausgaben, Zustandsänderungen, Zusicherungen). Werden die internen Details der Methode geprüft (dies wird als White-Box-Testing bezeichnet), könnte der Test fehlschlagen, obwohl sich die externen Auswirkungen nicht geändert haben. Daher wird in der Regel das sogenannte Black-Box-Testing empfohlen, bei dem man sich auf das Prüfen der externen Auswirkungen beschränkt.

Automatisierte Modultests [Bearbeiten]

Mit der Verbreitung von agilen Softwareentwicklungsmethoden und insbesondere testgetriebener Entwicklung ist es üblich geworden, Modultests möglichst automatisiert auszuführen. Dazu werden üblicherweise mit Hilfe von Test Frameworks wie beispielsweise JUnit Testprogramme geschrieben. Über die Test Frameworks werden die einzelnen Testklassen aufgerufen und deren Komponententests ausgeführt. Die meisten Test Frameworks geben eine grafische Zusammenfassung der Testergebnisse aus.

Die automatisierten Modultests haben den Vorteil, dass sie rasch und von jedermann ausgeführt werden können. Somit besteht die Möglichkeit, nach jeder Programmänderung durch Ausführen aller Modultests nach Programmfehlern zu suchen. Etwaige neu entstandene Fehler können auf diese Weise schnell entdeckt und somit kostengünstiger behoben werden. Dies setzt allerdings voraus, dass alle Modultests vor Programmänderungen erfolgreich durchlaufen.

Kritik [Bearbeiten]

Modultests können (wie jeder Test) die Fehlerfreiheit des getesteten Moduls nicht garantieren oder nachweisen, sondern lediglich unterstützen. Die Grenzen von Modultests liegen notwendigerweise darin, dass nur solche Fehler gefunden werden können, zu deren Entdeckung die verwendeten Tests geeignet sind. Eine Softwarekomponente, die „grün“ testet, ist also nicht unbedingt fehlerfrei.

Das Merkmal von Code, „grün“ zu testen, und durchaus auch der Wunsch nach diesem Ergebnis, könnte dazu führen, dass tatsächlich (unbewusst) nur soviel getestet wird, dass alle Tests „grün“ sind. Module, die keine fehlschlagenden Modultests haben, als fehlerfrei zu behandeln ist ein häufiges Anti-Pattern in der Praxis testgetriebener Entwicklung.

Bei der Änderung von Code stellen Modultests sicher, dass keine solchen Fehler unbemerkt eingefügt werden, die der vorhandene Bestand an Tests sicher aufdeckt. Das Problem, eine ausreichende Testabdeckung herzustellen, kann nur durch entsprechende Beachtung und geeignete Maßnahmen gelöst werden.

Wenn wie üblicherweise der Autor von Modultests mit dem Autor der Module identisch ist, können Denkfehler in der Implementierung auch im Test erscheinen und nicht aufgedeckt werden. Wenn es sich um dieselbe Person handelt, wird dies auch nicht dadurch ausgeschlossen, dass die Tests zuerst entwickelt werden, da sowohl die beabsichtigte Funktionsweise des Codes, als auch seine zukünftige Gestalt bereits im Denken des Testautors und späteren Codeautors präsent sein können.

Siehe auch [Bearbeiten]

Literatur [Bearbeiten]

Weblinks [Bearbeiten]

Einzelnachweise [Bearbeiten]

  1. ↑ M. Pol, T. Koomen, A. Spillner: Management und Optimierung des Testprozesses. dpunkt.Verlag, Heidelberg 2002, ISBN 3-89864-156-2.
Von „http://de.wikipedia.org/w/index.php?title=Modultest&oldid=115687206“