 | | | | | |||||||
| | | | | |||||||
| |
| | | |||||||
| | | | | |||||||
| | | | |
|
Methodisches Testen von Programmen |
Didaktische Reduktion Modultest
Um bei umfangreichen Programmen nicht zu aufwendige und unübersichtliche Testfälle zu erzeugen und zu testen, ist es auch in der Schule angebracht, Modultests durchzuführen. Dies ist vorteilhaft, da man den Ort des Fehlers besser bestimmen kann. Außerdem muß man beim Einzeltest nicht alle Eingangsbedingungen kombinieren. Zum dritten hat man einen Zeitvorteil, da man parallel und in Gruppen testen kann.
Für den Test des einzelnen Moduls werden wieder die Verfahren verwendet, die den Schülern bereits bekannt sind. Die Modullogik wird mit Hilfe einer oder mehrerer Whitebox-Methoden analysiert, indem das Modul wie ein selbständiges Programm betrachtet wird. Danach wird dieser Test durch Blackbox-Methoden ergänzt, die die Modulspezifikation, also Schnittstellen (Ein- und Ausgabeparameter) und Funktion, prüft.
Zur Einführung sollten nur solche Module getestet werden, die lediglich von einem Modul aufgerufen werden und selbst keine Module aufrufen. Dazu braucht dann nur ein Testrahmen (Treiber) erstellt zu werden, der die Benutzung des Testobjekts simuliert und dieses aufruft.
Damit kann das oberste Modul, das alle anderen Module aufruft, am Anfang nicht einzeln getestet werden. Der Test wird hier durchgeführt, indem alle anderen Module eingefügt werden, um das aufwendige Erzeugen der notwendigen STUBs zu vermeiden. Damit wird inkrementell nach dem Bottomup-Verfahren getestet.
Später kann man auch Module testen, die andere Module aufrufen. Die dabei zu erstellenden STUBs dürfen aber nicht zu kompliziert sein. Am Anfang sollten nur solche STUBs erzeugt werden, bei denen es reicht, daß sie ihre Ausführung zurückgeben.
Hier kann jetzt auch das oberste Modul leicht getestet werden, indem man sich nur die Ausführung des Moduls bzw. jeweils nur einen der möglichen zu erzeugenden Werte zurückgeben läßt. Dabei sollte aber ein Hinweis erfolgen, daß hiermit nur die Lauffähigkeit getestet wird.
Es werden also alle Module einzeln getestet und erst danach zusammengefügt. Hierzu ist Gruppenarbeit eine günstige Variante, da man das Modul jeweils in einer Gruppe erstellen und danach von einer anderen testen lassen kann. Gefundene Fehler können also sofort zugeordnet werden. Dadurch kommt man zum nichtinkrementellen Testen. Fügt man jetzt alle getesteten Module auf einmal zu einem Programm zusammen, dann hat man folgende Nachteile:
Es bietet sich aber an, daß die schnelleren Gruppen für ihr zu testendes Modul bzw. für andere Gruppen weitere STUBs erzeugen. Dadurch kann man jetzt auch das oberste Modul intensiver testen.
Treten Fehler erst beim Zusammenfügen auf, so fügt jede Gruppe bestimmte Module jeweils einzeln zu dem bereits von ihr getesteten Modul dazu. Dabei wird das aufrufende Modul bzw. einer der STUBs hinzugefügt. Dadurch können jetzt Fehler bei den Schnittstellen gefunden werden.
Inkrementelles Testen ist im Unterricht immer dann angebracht, wenn komplizierte STUBs getestet werden müßten. Denn hier kann man durch Einsatz des Bottomup-Verfahrens erst das aufzurufende Modul testen und dieses dann als STUB einsetzen.
Im Grundkurs Informatik ist nach Rahmenplan "Modultesten" als Gegenstand des Unterrichts nicht explizit vorgegeben. Dies gehört aber zum Thema C: Algorithmisches Problemlösen zum 2. Thema (Unterprogrammtechniken) sowie zum 4. Thema (Methoden systematischer Programmentwicklung). Deshalb ist es nicht notwendig, daß die Schüler die verschiedenen Verfahren (inkrementell bzw. nichtinkrementell) beim Namen kennen und unterscheiden können. Auch der Begriff STUB muß weder eingeführt noch verwendet werden.
zurück zur Didaktischen Reduktion Blackbox-Testen
|
