Testresultatsvergleich mit UML-Analysemodellen und OCL-Ausdrücken

Transkript

1 Testresultatsvergleich mit UML-Analysemodellen und OCL-Ausdrücken Rainer Schmidberger, Sascha Biermann Universität Stuttgart, Institut für Softwaretechnologie Abteilung Software Engineering Universitätsstr Stuttgart Abstract: Testautomatisierung kann einen erheblichen Beitrag zur Aufwandsreduzierung im Programmtest leisten. 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 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 erheblichen Beitrag zur Aufwandsreduzierung im Programmtest leisten [Fe99]. Neben der Kostenersparnis gibt es aber noch eine ganze Reihe weiterer Vorteile der Testautomatisierung: 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 Regressionstests 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 Domä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. 392

2 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 Systemtests, die in der Regel über sogenannte Capture/Replay-Werkzeuge durchgeführt werden [Fe99][Ka97][Th02][Me02]. Die Programmierung dieser GUI-Tests erfolgt üblicherweise 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 Testtreibersprachen wie TTCN-3 [Gr03] eingesetzt. Bei den Unit-Test-Frameworks wie z. B. JUnit [Be03] stehen für Resultatvergleiche die Vergleichsoperationen der verwendeten Programmiersprache zur Verfügung. Der Vergleich erfolgt aber jeweils durch Programmcode und nicht durch anschauliche Modelle. Richardson et al. [Ri89] schlagen Testfälle mit formal beschriebenen Vor- und Nachbedingungen vor. Sie beschreiben eine formale, z. B. algebraische Spezifikation der Vorund 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 Automatisierungsunterstü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 Tupel SUT = (E, Z, M, f, s0). E ist die Menge der möglichen Eingaben; Z ist die Zustandsmenge, die alle für das verwendete Analysemodell M möglichen Systemzustände enthält; M ist das Analysemodell; f: Z E Z ist die totale Überführungsfunktion, die Anwendungsfunktion; und s0 Z ist der Startzustand. Ein Testfall prüft eine Funktion des SUT. Definition: Ein Testfall ist ein Tupel T = (SUT, za, e, zr); za Z ist der Ausgangszustand; e E eine Eingabe, die Benutzeraktion; zr Z ist der Zielzustand, das Soll-Resultat. 393

3 Die Resultatsprüfung ist der Prozess, der prüft, ob das SUT das erwartete Resultat geliefert 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 Nutzungsform dient OCL zur Formulierung von Invarianten von Klassen sowie für Vor- und Nachbedingungen für Methoden. OCL-Ausdrücke werden relativ zu einem Systemzustand 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 Klassendiagramme 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 geringerem 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 1 Anmeldung 1 Veranstaltung id name vorname 0..* status 0..* titel datum maxtln 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 ist ausgewählt. 2. Die Person Liese Testperson mit id= 007 ist hierzu noch 394

4 Aktion: Resultatsprüfung: (Nachbedingung) nicht angemeldet 3. Die Veranstaltung hat noch mindestens einen freien Platz Liese Testperson anmelden 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=' ' 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=' ' 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 Ausdruck self, der in OCL als der kontextuelle Bezug bezeichnet wird, referenziert das Objekt, das zentraler Gegenstand des Tests ist. Im Beispiel ist es das Veranstaltungsobjekt. Es ist das Objekt, das im SUT aktuell in der Bearbeitung ist. Von diesem kontextuellen Bezug aus wird zu Attributen und Assoziationen navigiert. Beziehen sich Soll-Resultate auf das Domänenmodell, lassen sie sich so recht anschaulich 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. 395

5 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 Attributen 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. Konnektor- Implantat OCL-Parser OCL- Auswertung Konnektor SUT 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 Mechanismen (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 ausgewählt. Konkret handelte es sich um ein Katalogsystem für Seminare mit Online- Anmeldefunktion. Das gewählte Informationssystem ist in Java geschrieben und verwendet 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 Testfä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 Wartelistenbuchung für bereits ausgebuchte Veranstaltungen oder eine Stornierung, in deren Folge ggf. Wartelistenbuchungen nachrücken. Diese Vorbedingungen und Soll-Resultate konnten anschaulich mit OCL formuliert werden und waren von Hand, also ohne automatische Prüfung, nur mit einigem Aufwand zu bewerten. 396

6 Bei einer Befragung weiterer Fachexperten wurde OCL zur Formalisierung der Resultatsprüfung als gut lesbar und nützlich bezeichnet. Als besonderer Vorteil wurde genannt, dass die Attributs- und Assoziationsbezeichner genau der Begriffswelt der Domäne entsprachen. Ein weiterer Vorteil wurde darin gesehen, dass die formale Beschreibung 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 Formulierung von Vorbedingung und Soll-Resultaten des Tests vorgesehen sind, hat sich ihr Einsatz als sehr nützlich herausgestellt. Besondere Vorteile sind die Verwendungsmöglichkeit 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, vorgenommen 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 Technol. Transf. 7, 3 (Jun. 2005), [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, [Bi07] Biermann, S.: Modellbasierte Konsistenzprüfung für die GUI-Testautomation, Stuttgart, Univ., Studiengang Softwaretechnik, Diplomarbeit Nr [Fe99] Fewster, M., Graham, D.: Software test Automation.Addison-Wesly, 1999 [Dr07] Homepage des Dresden OCL Toolkits, [Ka97] Kaner, C: Pitfalls and Strategies in Automated Testing, IEEE Computer, Vol. 30, Nr. 4, 1997, S [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, Analysis, and Verification, 1989 [Wa03] Warmer, J., Anneke Kleppe, A.: The Object Constraint Language. 2. Auflage, Addison-Wesley, [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),