Modellbasierter Komponententest mit visuellen Kontrakten
Jens Ellerweg1, Gregor Engels1,2, Baris Güldali2
1Institut für Informatik,2Software Quality Lab Universität Paderborn
Warburgerstr. 100, 33098 Paderborn {ellerw01,engels,baris}@upb.de
Abstract:Das Verhalten von quasimodalen Klassen ist abhängig von dem Sys- temzustand, in dem sie ausgeführt werden. Beim Testen von quasimodalen Klassen muss der Systemzustand so gesetzt werden, damit die zu testende Klasse ausge- führt werden kann. Nach der Testausführung müssen die Änderungen im System- zustand evaluiert und so die Korrektheit des Verhaltens der Klasse gegenüber ihrer Spezifikation geprüft werden. In diesem Beitrag stellen wir ein modellbasiertes Verfahren zum Komponententest vor, mit dem das Verhalten der quasimodalen Klassen anhand Vor- und Nachbedingungen modelliert und durch automatisiert generierte Testfälle geprüft wird. Die implementierte Werkzeugunterstützung er- möglicht die Einbindung des Verfahrens in die entwicklungsnahen Aktivitäten des Komponententests.
1 Einleitung
Modellbasiertes Testenbeschreibt, wie Modelle der Software oder ihrer Umgebung oder explizite Testmodelle systematisch für Testaktivitäten eingesetzt werden können, um die Testaktivitäten zu systematisieren und den Testaufwand durch Automatisierung zu redu- zieren. In [5] werden die drei wichtigen Aufgaben von modellbasiertem Testen wie folgt definiert:
1. Generierung von Testfällen aus Modellen 2. Generierung von Testorakeln aus Modellen
3. Generierung der Testausführungsumgebung aus Modellen
Wir verfolgen UML-basierte Modellierungstechniken zur Beschreibung des funktionalen Verhaltens der Software und zum Testen der Software. Dafür wurdenvisuelle Kontrakte [8] basierend auf die Idee des Design-by-Contract [10] entwickelt. Dabei wird das Ver- halten der Software mit Hilfe von Vor- und Nachbedingungen an den Systemzustand be- schrieben. In [4] haben wir beschrieben, wie visuelle Kontrakte zur Formalisierung von UML Use-Case Beschreibungen und für Systemtest eingesetzt werden.
In diesem Beitrag erläutern wir die Verwendung von visuellen Kontrakten für den Kom- ponententest von quasimodalen Klassen.QuasimodaleKlassen sind solche Klassen, de- ren Verhalten von dem Systemzustand abhängig ist [1]. Dabei verwenden wir die Vor- bedingung des visuellen Kontraktes zur Bestimmung des fürs Testen benötigten System- zustandes. Nach der Testausführung wird überprüft, ob die spezifizierte Nachbedingung erfüllt wird. So kann der Testerfolg anhand der Änderungen im Systemzustand bestimmt werden. Unser Verfahren automatisiert die Ausführung und die Evaluierung der Testfäl- le durch die Generierung von ausführbaren Testskripten und die Generierung der einge- betteten Zusicherungen.
211
2 Verhaltensbeschreibung mit visuellen Kontrakten
Für die Verhaltensbeschreibung der Klassenmethoden verwenden wir visuelle Kontrak- te, die das Verhalten durch Vor- und Nachbedingungen an den Systemzustand beschrei- ben [8]. Diese werden durch zwei UML-Objektdiagramme modelliert, die über das Klas- sendiagramm getypt sind.
Abb. 1 (links) zeigt beispielsweise die Klassen und ihre Beziehungen eines OnlineShops, das das Kaufen von Produkten wie Bücher oder DVD’s ermöglicht. Abb. 1 (rechts) zeigt die Beschreibung des erwünschten Verhaltens der Methode „cartAdd“ der Klasse Onli- neShop durch einen visuellen Kontrakt. Die linke Seite des Kontraktes spezifiziert die für die Ausführung der Methode notwendigen Objekte. Die rechte Seite des Kontraktes spezifiziert die während der Ausführung vorzunehmenden Änderungen. Die Verhaltens- beschreibung hat keinen Anspruch auf Vollständigkeit und enthält nur eine partielle Be- schreibung des erwünschten Verhaltens. Konstrukte wie Multiobjekte ermöglichen die Spezifikation von unterschiedlichen Szenarien, in denen mehrere gleichartige Objekte vorkommen können. Dieser Spezifikation liegt die Theorie von Graphtransformationen zugrunde [6].
Abb. 1: OnlineShop Klassendiagramm und visuelle Kontrakt für Methode cartAdd
3 Generierung, Ausführung und Auswertung der Testfälle
Mit den visuellen Kontrakten testen wir das zustandsändernde Verhalten der Klasse un- ter Test (KUT) gegen das in den visuellen Kontrakten spezifizierte Verhalten. DasFeh- lermodellbezieht sich also auf die fehlerhaft implementierten Zustandsänderungen, wie z.B. die fehlerhafte Generierung, Löschung und Änderung der Objekte.
Unser Testansatz besteht aus den folgenden Schritten: (1) Generierung der Testfälle, (2) Testausführung und (3) Testbewertung. Die Funktionsweise dieser Schritte haben wir bereits in [2, 4] beschrieben. In diesem Beitrag möchten wir nach einer kurzen Erläute- rung dieser Schritte auf die Ergebnisse einer durchgeführten Fallstudie und auf die Per- formanzwerte der implementierten Werkzeugunterstützung eingehen.
Im ersten Schritt werden die Eingabewerte aus den Aufrufparametern der Signatur und die Testobjekte und ihre Attributwerte aus der Vorbedingung eines visuellen Kontraktes durch den Einsatz von zufallsbasierter Testdatengenerierung, Grenzwertanalyse und die All-Variants Methode [1] erstellt. Die Testobjekte aus der Vorbedingung stellen sicher,
212
dass die zu testende Methode ausführbar und damit testbar ist. Die Kombinatorik der ge- nerierten Eingabewerte und der Testobjekten liefert eine Menge von Testszenarien. Abb.
2 (links) zeigt ein Beispiel für Testobjekte für die Methode „cartAdd“. Die Testobjekte und ihre Attributwerte wurden zufallsbasiert generiert und die Objekte wurden miteinan- der gemäß dem Klassendiagramm verlinkt und um ein weiteres Objekt erweitert. Für je- de Testobjekt-Struktur wird eine JUnit-Testskript generiert, die den Systemzustand setzt, die Methode unter Test ausführt und nach der Ausführung den resultierenden Systemzu- stand überprüft (Abb. 2, rechts).
Abb. 2: Generierung der Testeingaben und des JUnit-Testskriptes
Während der Testausführung wird die Testbewertung durch die JML (Java Modeling Language) Zusicherungen [7] übernommen, die aus der Vor- und Nachbedingung er- zeugt und in den Quellcode eingebettet wurden [8]. Eine Verletzung der Nachbedingung bedeutet, dass die Zustandsänderungen der Methode unter Test (MUT) nicht dem in den visuellen Kontrakten spezifizierte Verhalten entsprechen. Nach der Ausführung der Me- thode wird zusätzlich die Konsistenz des Nachzustandes bezüglich des Klassendia- gramms geprüft. Ist dies nicht der Fall, dann ist es auch ein Indiz für eine fehlerhafte Programmierung.
4 Werkzeugunterstützung & Fallstudie
Für das vorgestellte Verfahren wurde in [2] ein Eclipse Plug-In zur Automatisierung der beschriebenen Testaktivitäten entwickelt. Dieses Plug-In erweitert Visual Contract Workbench [9], welches die Modellierung und Codegenerierung aus den Klassendia- grammen und den visuellen Kontrakten unterstützt. Für die Generierung der Testobjekte wurden bereits zufallsbasierte Testdatengenerierung, Grenzwertanalyse und die All- Variants Methode implementiert. Ein wesentliches Merkmal des Plug-Ins ist die Erwei- terbarkeit, so dass es um weitere Generatoren für die Eingabewerte (z.B. Äquivalenz- klassenbildung) und Generatoren für den Systemzustand (z.B. durch Modelchecking- basierte Verfahren [3]) erweitert werden kann.
Anhand einer Fallstudie wurden das vorgestellte Verfahren und die implementierte Werkzeugunterstützung evaluiert. Bei dem Fallbeispiel handelt es sich um einen Online- Shop (siehe Abb. 1), das das Kaufen von Produkten wie Bücher oder DVD’s ermöglicht.
Für die Evaluierung wurden 9 Fehler entsprechend dem Fehlermodell in die Software in- jiziert. Mit Hilfe der beiden vorgestellten Verfahren (Grenzwertanalyse und Zufallsgene-
213
rierung) wurden jeweils 134 und 34 Testfälle generiert. Tabelle 1 zeigt die entdeckten und nicht entdeckten Fehler.
Tabelle 1: Fehlerbeschreibungen
# Fehlerbeschreibung Grenzwert-
analyse Zufalls- generierung
1 Generiertes Objekt hat falsche Variablenwerte + +
2 Generiertes Objekt hat falsche Objektbeziehung(en) + +
3 Zu generierende Objekt existiert nicht + +
4 Geändertes Objekt hat falsche Objektbeziehung(en) + +
5 Zu löschendes Objekt wurde nicht gelöscht + +
6 Nicht zu änderndes Objekt existiert nicht + +
7 Verletzung der Kardinalitäten + +
8 Fehlerhafte Fallunterscheidung + -
9 Zu generierende Objekt wird nicht generiert - -
Die Zufallsgenerierung entdeckt im Gegensatz zu der Grenzwertanalyse den Fehler 8 nicht, da nur zufällige Werte verwendet werden. Die Grenzwertanalyse erkennt den Feh- ler, da er im Grenzbereich von den Testeingaben auftritt. Die Ursache weshalb Fehler 9 nicht gefunden wird liegt an der Generierung des Systemzustandes. Um den Fehler fin- den zu können müsste das derzeitige Verfahren so erweitert werden, dass komplexere Systemzustände generiert werden. In der folgenden Tabelle werden die Ausführungszei- ten des Test-Plugins für die beiden verwendeten Verfahren gegenübergestellt.
Tabelle 2: Performanzwerte des Plug-Ins
Grenzwertanalyse Zufallsgenerierung
Anzahl der generierten Testfälle 134 34
Testfallgenerierung 90 ms 50 ms
Java-Code-Generierung 500 ms 500 ms
Testausführung und Testbewertung 200 ms 100 ms
Literaturverzeichnis
[1] Binder, R.V.: Testing Object-Oriented Systems. Addison-Wesley, 2000
[2] Ellerweg, J.: Komponententest mit visuellen Kontrakten, Diplomarbeit, Universität Pader- born, 2008
[3] Engels, G., Güldali, B., Lohmann, M.: Towards Model-Driven Unit Testing. In T. Kühne (ed.), Satellite Events at the MoDELS 2006 Conference, Revised Selected Papers, LNCS Volume 4364, pp. 182 - 192, Springer Berlin / Heidelberg, 2007
[4] Engels, G., Güldali, B., Sauer, S.: Formalisierung der funktionalen Anforderungen mit visuel- len Kontrakten und deren Einsatz für modellbasiertes Testen. Softwaretechnik-Trends, GI, August 2008
[5] Heckel, R., Lohmann, M.: Towards model-driven testing. LNCS 82(6), 2003
[6] Heckel, R., Ehrig, H., Wolter, U., Corradini, A.: Double-pullback transitions and coalgebraic loose semantics for graph transformation systems. APCS, 9(1) 83–110, 2001
[7] Leavens, G., Cheon, Y.: Design by Contract with JML, 2003
[8] Lohmann, M., Sauer, S., Engels, G.: "Executable visual contracts," In Proc. of IEEE Sympo- sium on Visual Languages and Human-Centric Computing, 2005, pp. 63-70, 2005
[9] Lohmann, M.: Kontraktbasierte Modellierung, Implementierung und Suche von Komponen- ten in serviceorientierten Architekturen. Dissertation, Universität Paderborn, 2006
[10] Meyer, B.: Applying “design by contract”. IEEE Computer 25(10) 40–51, 1992 214
