Testresultatsvergleich mit UML-Analysemodellen und OCL-Ausdrücken
Rainer Schmidberger, Sascha Biermann rainer.schmidberger@informatik.uni-stuttgart.de Universität Stuttgart, Institut für Softwaretechnologie
Abteilung Software Engineering Universitätsstr. 38
70569 Stuttgart
Abstract:Testautomatisierung kann einen erheblichen Beitrag zur Aufwandsredu- zierung im Programmtest leisten. In diesem Artikel wird ein Verfahren zur auto- matischen Prüfung der Vorbedingungen und der Soll-Resultate von Testfällen vorgestellt. Es werden hierzu UML-Klassendiagramme der Analyse und die Object Constraint Language (OCL) verwendet. Für die Auswertung der Ausdrücke wurde ein Werkzeug implementiert und bei einem Informationssystem aus der Industrie angewendet und evaluiert.
1 Einführung
Testautomatisierung automatisiert die Ausführung von Testfällen und kann einen erheb- lichen Beitrag zur Aufwandsreduzierung im Programmtest leisten [Fe99]. Neben der Kostenersparnis gibt es aber noch eine ganze Reihe weiterer Vorteile der Testautomati- sierung: Es können sehr viele Testfälle und diese auch in kürzerer Zeit, oft über Nacht, ausgeführt werden; die Testfälle müssen formal beschrieben werden und fordern damit Systematik in der Erstellung; und die Testdurchführungen haben eine gleich bleibende und damit kalkulierbare Qualität. Testautomatisierung ist die Voraussetzung, um Reg- ressionstests wirtschaftlich durchführen zu können [Be90].
In diesem Artikel wird ein Verfahren zur automatischen Prüfung der Vorbedingungen und der Soll-Resultate von Testfällen vorgestellt. Es werden hierzu UML- Klassendiagramme und die Object Constraint Language (OCL) verwendet. Der Vorteil besteht darin, dass speziell das Klassendiagramm der UML in der industriellen Praxis weit verbreitet ist und von vielen Unternehmen in der Analyse zur Darstellung des Do- mänenmodells genutzt wird. Mit der UML Version 2.0 gehört auch die Object Constraint Language (OCL) zum UML-Sprachumfang. OCL dient der detaillierteren Beschreibung der UML-Modelle.
Zur automatischen Auswertung der so formulierten Vorbedingungen und Soll-Resultate wurde ein Werkzeug implementiert und bei einem Informationssystem aus der Industrie angewendet und evaluiert. In diesem Artikel wird die Prüfung von Vorbedingungen und Soll-Resultaten betrachtet, die Benutzeraktion wird nicht behandelt.
1.1 Verwandte Arbeiten
Wenn in der Literatur von Testautomatisierung die Rede ist, sind fast immer Tests an der (grafischen) Benutzungsschnittstelle (GUI) gemeint. Es handelt sich dann um System- tests, die in der Regel über sogenannte Capture/Replay-Werkzeuge durchgeführt werden [Fe99][Ka97][Th02][Me02]. Die Programmierung dieser GUI-Tests erfolgt üblicherwei- se mit den speziellen Skriptsprachen der Testwerkzeuge; in vielen Werkzeugen können Benutzeraktionen auch über einen integrierten „Recorder“ aufgenommen werden. Über Ausdrücke der jeweiligen Skriptsprache lassen sich die Ist-Resultate ermitteln und mit den hinterlegten Soll-Resultaten vergleichen. Bei Unit- oder Integrationstests erfolgt die Programmierung in der Regel in der Sprache des zu testenden Moduls, teilweise – wie beispielsweise in der Nachrichtenvermittlung – werden aber auch spezielle Testtreiber- sprachen wie TTCN-3 [Gr03] eingesetzt. Bei den Unit-Test-Frameworks wie z. B. JUnit [Be03] stehen für Resultatvergleiche die Vergleichsoperationen der verwendeten Pro- grammiersprache zur Verfügung. Der Vergleich erfolgt aber jeweils durch Programmco- de und nicht durch anschauliche Modelle.
Richardson et al. [Ri89] schlagen Testfälle mit formal beschriebenen Vor- und Nachbe- dingungen vor. Sie beschreiben eine formale, z. B. algebraische Spezifikation der Vor- und Nachbedingungen, die für einzelne Prozeduren angewendet werden. Boyapati et al.
beschreiben das Rahmenwerk Korat [Bo02], das aus einer formalen Spezifikation zu einzelnen Java-Methoden Vor- und Nachbedingungen sowie Testfälle generiert. Als formale Sprache wird die Java Modelling Language (JML) [Bu05] verwendet, die als Annotationen in den Java-Programmcode eingefügt wird. Sehr ähnlich verhält sich das Werkzeug Autotest von Ciupa et al. [Ci05], das noch weiterführende Automatisierungs- unterstützung liefert.
Im Unterschied zu den beschriebenen Arbeiten wird in diesem Artikel ein Verfahren vorgestellt, das nicht einzelne Methoden oder Prozeduren des Programmcodes, sondern Vor- und Nachbedingungen für Testfälle des Systemtests betrachtet. Zur Erstellung der Testfälle ist auch keine Kenntnis des Programmcodes erforderlich. Die Testfälle basieren statt dessen auf dem Analysemodell.
1.2 Definitionen
In diesem Artikel wird Test im Sinne der Definition von Myers [My79] verstanden als
„Programmausführung in der Absicht, Fehler zu finden“. Das System under Test (SUT) wird als deterministischer endlicher Automat aufgefasst. Die möglichen Systemzustände werden durch ein Analysemodell bestimmt.Definition:Das SUT ist ein TupelSUT = (E, Z, M, f, s0).Eist die Menge der möglichen Eingaben;Zist die Zustandsmenge, die alle für das verwendete AnalysemodellMmöglichen Systemzustände enthält;Mist das Ana- lysemodell;f: Z#E"Zist die totale Überführungsfunktion, die Anwendungsfunktion;
unds0 % Zist der Startzustand. Ein Testfall prüft eine Funktion des SUT.Definition:
Ein Testfall ist ein Tupel T = (SUT, zA, e, zR);zA%Zist der Ausgangszustand;e%E eine Eingabe, die Benutzeraktion;zR%Zist der Zielzustand, das Soll-Resultat.
Die Resultatsprüfung ist der Prozess, der prüft, ob das SUT das erwartete Resultat gelie- fert hat.
1.3 OCL
Die Object Constraint Language (OCL) ist eine formale, prädikatenlogikbasierte Sprache und Teil der UML 2.0 Spezifikation [Wa03]. OCL dient der ergänzenden Spezifikation von UML-Modellen, speziell dem Klassendiagramm. Die Ausdrücke sind deklarativ, d.
h. sie ändern den Zustand des Systems nicht. In der von der UML vorgesehenen Nut- zungsform dient OCL zur Formulierung von Invarianten von Klassen sowie für Vor- und Nachbedingungen für Methoden. OCL-Ausdrücke werden relativ zu einem Systemzu- stand S ausgewertet und sind vom Typ Boolean; sie sind wahr oder falsch bezüglich S.
Invarianten sollen in jedem feststellbaren Zustand des Systems gelten und beschränken so die erlaubten Systemzustände eines UML-Klassendiagramms.
2 OCL zur Resultatsprüfung
In diesem Artikel werden OCL-Ausdrücke zur Resultatsüberprüfung verwendet. Ist der OCL-Ausdruck für das Resultat true, dann hat der Testfall das Soll-Resultat ergeben; ist der OCL-Ausdruck für das Resultat false, dann hat der Testfall das Soll-Resultat nicht ergeben, ein Fehler ist aufgetreten. Ausgangspunkt des Verfahrens sind die Klassendia- gramme der Analyse. Diese oft als Domänenmodelle bezeichneten Klassendiagramme werden in der Regel von den Fachexperten und in der Begriffswelt der Fachdomäne geschrieben. Enthalten sind die Klassen mit Beziehungen, Attributen und – in geringe- rem Umfang – Methoden. Abbildung 1 zeigt als Beispiel ein einfaches Domänenmodell einer Seminarverwaltung. Eine Person kann mehrere Anmeldungen zu Veranstaltungen haben. Eine Anmeldung hat einen Status zur Kennzeichnung als reguläre Anmeldung, Storno oder Wartelistenbuchung. Das Attribut „id“ der Person sei als eindeutiges, identifizierendes Attribut angenommen.
Person id
name vorname
Veranstaltung titel
datum maxTln Anmeldung
status 0..*
1 1
0..*
Abbildung 1: Beispiel eines Domänenmodells
Es wird nun ein Testfall angenommen, bei dem zu einer ausgewählten Veranstaltung eine weitere Anmeldung vorgenommen wird. Eine verbale Testfallbeschreibung könnte wie in Tabelle 1 lauten.
Testfall Nr.: 4711 Vorbedingung:
(Ausgangszustand) 1. Die Veranstaltung „Excel Grundkurs“ vom 17.02.07 ist ausgewählt.
nicht angemeldet
3. Die Veranstaltung hat noch mindestens einen freien Platz Aktion: „Liese Testperson“ anmelden
Resultatsprüfung:
(Nachbedingung) Liese Testperson ist nun angemeldet
Tabelle 1: Testfall mit verbaler Beschreibung zur Resultatsprüfung
Statt dieser verbalen Beschreibung für Vor- und Nachbedingung kann die Formulierung mit OCL wie in Tabelle 2 erfolgen (reguläre Anmeldung sei status=0).
Testfall Nr.: 4711
Vorbedingung context Veranstaltung
inv: self.title='Excel Grundkurs' and self.date='17.02.2007' and not
self.anmeldung->exists(person.id='007') and self.anmeldung->select(status=0)->size()
<self.maxTln
Aktion: „Liese Testperson“ anmelden Resultatsprüfung:
(Nachbedingung) context Veranstaltung
inv: self.title='Excel Grundkurs' and self.date='17.02.2007' and
self.anmeldung->exists(person.id='007' and status=0)
Tabelle 2: Testfall mit formaler Beschreibung zur Resultatsprüfung
Die Vorbedingung legt den für die Testausführung geforderten Startzustand des SUT fest, die Resultatsprüfung den gültigen Zielzustand.
Der Ausdruckself, der in OCL als der kontextuelle Bezug bezeichnet wird, referenziert das Objekt, das zentraler Gegenstand des Tests ist. Im Beispiel ist es das Veranstaltungs- objekt. Es ist das Objekt, das im SUT aktuell in der Bearbeitung ist. Von diesem kontex- tuellen Bezug aus wird zu Attributen und Assoziationen navigiert.
Beziehen sich Soll-Resultate auf das Domänenmodell, lassen sie sich so recht anschau- lich formulieren. Auch hat OCL ausreichend Mächtigkeit um komplexere Ausdrücke gut verständlich formulieren zu können. Das Verfahren eignet sich dagegen nicht um z.B.
Laufzeiten zu prüfen oder andere Eigenschaften, die sich nicht durch gespeicherte Daten manifestieren und darum auch nicht über das Domänenmodell erreichbar sind.
3 Technische Realisierung
Die technische Realisierung kann im Wesentlichen in drei Bereiche unterteilt werden:
den OCL-Parser, die OCL-Auswertung und einen Konnektor, der die Objekte mit Attri- buten und Assoziationen des Domänenmodells auf physische Repräsentationen im SUT abbildet. Um diesen Zugriff in das Domänenmodell des SUT zu ermöglichen, wird dort ein Implantat, also für den Test zusätzlich benötigter Programmcode, eingefügt.
In einer Beispielimplementierung, die im Rahmen einer Diplomarbeit entstand [Bi07], wurde die Verbindung zum Konnektor-Implantat des SUT über Java Remote Methode Invocation (RMI) realisiert. Dies hat den Vorteil, dass das SUT nicht auf dem selben Rechner wie die OCL-Auswertung ausgeführt werden muss.
SUT Konnektor
AuswertungOCL- OCL-Parser
Konnektor- Implantat
Abbildung 2: Architektur der OCL-Resultatsprüfung
Der OCL-Parser wurde weitestgehend mit dem Dresden OCL Toolkit [Dr07] aufgebaut.
Zur Erfassung der OCL-Ausdrücke wurde eine Eclipse-Erweiterung implementiert, von der auch die Auswertung gestartet und das Resultat angezeigt wird. Der Aufwand zur Implementierung des Konnektor-Implantats hängt wesentlich davon ab, wie verändert das Domänenmodell im SUT enthalten ist, und in wie weit über generische Mechanis- men (wie z.B. Reflexion) ein Zugriff auf Attribute und Beziehungsnavigation möglich ist. Liegt einer Anwendung kein Domänenmodell der Analyse zugrunde, ist das hier beschriebene Verfahren nicht sinnvoll anwendbar.
4 Beispielanwendung und Evaluation
Zur Evaluation des Verfahrens wurde ein Informationssystem aus der Industrie ausge- wählt. Konkret handelte es sich um ein Katalogsystem für Seminare mit Online- Anmeldefunktion. Das gewählte Informationssystem ist in Java geschrieben und ver- wendet intern ein Domänenmodell, das nahezu vollständig über Reflektion erreichbar war. Der Aufwand zur Implementierung des Konnektor-Implantats lag bei etwa einem Tag. Das aktuelle Domänenmodell lag als UML-Klassendiagramm vor und war den Fachexperten bekannt. Insgesamt wurden gemeinsam mit einem Fachexperten acht Test- fälle mit Vorbedingung und Soll-Resultat erstellt und ausgeführt. Die Testfälle betrafen im Wesentlichen die Online-Anmeldefunktion. Testfälle waren z.B. eine Wartelistenbu- chung für bereits ausgebuchte Veranstaltungen oder eine Stornierung, in deren Folge ggf. Wartelistenbuchungen nachrücken. Diese Vorbedingungen und Soll-Resultate konn- ten anschaulich mit OCL formuliert werden und waren von Hand, also ohne automati- sche Prüfung, nur mit einigem Aufwand zu bewerten.
Bei einer Befragung weiterer Fachexperten wurde OCL zur Formalisierung der Resul- tatsprüfung als gut lesbar und nützlich bezeichnet. Als besonderer Vorteil wurde ge- nannt, dass die Attributs- und Assoziationsbezeichner genau der Begriffswelt der Domä- ne entsprachen. Ein weiterer Vorteil wurde darin gesehen, dass die formale Beschrei- bung der Resultate zu mehr Präzision und Systematik beim Erstellen der Testfälle führt.
Als Mangel wurde genannt, dass die Benutzeraktion noch von Hand ausgeführt werden musste, da ja nur die Prüfung der Vorbedingung und der Resultatsvergleich automatisiert waren. Eine Kombination mit einem GUI-Testwerkzeug wird angestrebt.
5 Zusammenfassung
Auch wenn OCL-Ausdrücke in ihrer ursprünglichen Nutzungsform nicht zur Formulie- rung von Vorbedingung und Soll-Resultaten des Tests vorgesehen sind, hat sich ihr Einsatz als sehr nützlich herausgestellt. Besondere Vorteile sind die Verwendungsmög- lichkeit der Analysemodelle, die damit verbundene domänenspezifische Begriffswelt und die Mächtigkeit der Sprache OCL. Die Resultatsprüfung kann so durch anschauliche Modelle, die auch von einem Fachexperten erstellt oder geprüft werden können, vorge- nommen werden. Allerdings bleibt das Verfahren auf die Systeme oder Systemteile begrenzt, denen ein Domänenmodell der Analyse zugrunde liegt.
Literaturverzeichnis
[Be03] Beck, K..: “Test-Driven Development”.Addison-Wesly, 2003
[Bu05] Burdy, L. et al.: “An overview of JML tools and applications”, Int. J. Softw. Tools Tech- nol. Transf. 7, 3 (Jun. 2005), 212-232.
[Bo02] Boyapati, C. et al.: “Korat: automated testing based on Java predicates”, Proceedings of the ACM SIGSOFT Int. Symposium on Software Testing and Analysis, 2002
[Ci05] Ciupa, I., Leitner, A.: “Automatic testing based on design by contract”, Proceedings of Net.ObjectDays 2005, 545-557
[Bi07] Biermann, S.: “Modellbasierte Konsistenzprüfung für die GUI-Testautomation“, Stutt- gart, Univ., Studiengang Softwaretechnik, Diplomarbeit Nr. 2501
[Fe99] Fewster, M., Graham, D.: “Software test Automation”.Addison-Wesly, 1999 [Dr07] Homepage des Dresden OCL Toolkits, http://dresden-ocl.sourceforge.net/
[Ka97] Kaner, C: “Pitfalls and Strategies in Automated Testing”, IEEE Computer, Vol. 30, Nr.
4, 1997, S. 114-116
[Lu07] Ludewig, J., Lichter, H.: “Software Engineering”. dpunkt Verlag 2007
[Me02] Memon, A.: “GUI Testing: Pitfalls and Process “. IEEE Software, August 2002 [My79] Myers, G. J.: “Art of Software Testing”, John Wiley & Sons, Inc., New York, 1979 [Ri89] Richardson, D., O'Malley, O., Tittle, C. “Approaches to specification-based testing”,
Proceedings of the ACM SIGSOFT '89 Third Symposium on Software Testing, Analy- sis, and Verification, 1989
[Wa03] Warmer, J., Anneke Kleppe, A.: “The Object Constraint Language”. 2. Auflage, Addi- son-Wesley, 20032
[Th02] Thaller, G. E.: “Software-Test”. 2. Auflage, Verlag Heinz Heise, Hannover 2002 [Gr03] Grabowski, J. et al. “An introduction to the testing and test control notation (TTCN-3)“,
Comput. Networks 42, 3 (Jun. 2003), 375-403.
