Modellbasierte Oberfl¨achen f¨ur Abnahmetests
Stefan B¨arisch
GESIS Informationszentrum Sozialwissenschaften, Bonn bs@bonn.iz-soz.de
Universit¨at Oldenburgund Abteilung Softwareengineering
Abstract:Die Durchf¨uhrung von Tests ist eine Voraussetzung zur Erstellung qualitativ hochwertiger, nicht trivialer Softwaresysteme. Das modellgetriebene Testen erm¨oglicht eine hohe Testabdeckung bei gleichzeitiger Abstraktion von der zu testenden Imple- mentierung, was insbesondere beim Testen innerhalb von Produktfamilien von Vorteil ist. Als Alternative zur vollst¨andigen Generierung von Testmodellen stellen wir unse- ren Ansatz zur modellgetriebenen Konstruktion von Testf¨allen mittels einer dom¨anen- spezifischen Testspezifikationsoberfl¨ache vor. Dieser Ansatz, MTCC (Model-Driven Test Case Construction), erlaubt es Anwendern und Dom¨anenexperten ohne Program- mierkenntnisse auf Basis von Modellen der Anwendungsdom¨ane und des zu testenden Systems erstellte Oberfl¨achen direkt in die Testerstellung zu involvieren. Wir stellen die Vorgehensmodelle zur Anwendung von MTCC und relevante Konzepte vor und diskutieren den Wert einer auf abstrakten Modellen basierenden Testspezifikationso- berfl¨ache.
1 Einleitung
Das modellgetriebene Testen erlaubt die Durchf¨uhrung von automatischen Systemtests.
Die Bereitstellung einer modellgest¨utzten Oberfl¨ache zur Testspezifikation erm¨oglicht die Einbeziehung von Dom¨anenexperten und somit die modellgetriebene Konstruktion, Aus- f¨uhrung und Bewertung von Akzeptanztests. Die Einbeziehung von Dom¨anenexperten er- laubt die Anwendung des modellgetriebenen Testens auch in F¨allen, in denen die Beschrei- bung des korrekten Verhaltens des Testlings in Form formaler Modelle nicht vollst¨andig abgeschlossen oder nicht m¨oglich ist.
Gegen¨uber dem manuellen Testen bietet die Automatisierung des Testvorgangs sowohl un- ter dem Aspekt der Fehlerfindung als auch unter wirtschaftlichen Gesichtspunkten Vortei- le. Um automatisches Testen leisten zu k¨onnen, m¨ussen geeignete Tests konzipiert und um- gesetzt werden. Diese T¨atigkeiten setzen detaillierte Kenntnis sowohl der Anwendungs- dom¨ane als auch der Schnittstellen des zu testenden Systems voraus. Wenn Testprogram- me manuell erstellt und ¨uber den gesamten Entwicklungszyklus eines Systems heraus ge- pflegt und angepasst werden m¨ussen, nimmt die Etablierung automatischer Tests einen betr¨achtlichen Teil der Arbeit bei der Erstellung eines Systems ein, insbesondere, wenn im Rahmen einer Softwareproduktfamilie nicht nur Tests f¨ur eine Variante von Software er- stellt werden m¨ussen, sondern die Erstellung und Pflege von Tests f¨ur Implementierungen
mit verschiedenen Eigenschaften und Schnittstellen n¨otig ist.
Ein Ansatz zur Verringerung des Aufwands zur Testerstellung ist das modellgetriebene Testen. Hier werden Testprogramme nicht individuell programmiert, sondern aus einem Modell von System und Systemumgebung automatisch generiert. Ein Problem, das so- wohl beim automatischen Testen mittels manuell erstellter Testprogramme als auch beim modellgetriebenen Testen auftritt, ist die mangelnde Einbeziehung von Dom¨anenexperten oder Anwendern des zu testenden Systems. Sowohl das Programmieren von Tests, als auch die Modellierung des Testlings, setzt technisches Wissen voraus, das, abh¨angig von der Anwendungsdom¨ane, nicht von allen Beteiligten vorausgesetzt werden kann. Dies schließt einen Personenkreis mit detaillierten fachlichen Kenntnissen von der Testerstel- lung in Form von Akzeptanztests aus.
Um die Konstruktion von Tests durch Anwender und Dom¨anenexperten ohne Program- mierkenntnisse zu erm¨oglichen und zugleich die durch das modellgetriebene Testen erm¨og- lichte Entkopplung von Testspezifikation und Testausf¨uhrung zu erhalten, schlagen wir die Spezifikation von Tests in Form von Testmodellen mittels einer Benutzungsoberfl¨ache zur Testerstellung im Rahmen des MTCC (Model-Driven Test Case Construction) vor. MT- CC sieht die Instanzierung von Editoren auf Basis eines Metamodells f¨ur ein zu testendes System vor. Aus den mittels dieser Editorinstanz erzeugten Testmodellen werden in ei- nem Folgeschritt konkrete Testf¨alle generiert, wir bezeichnen diese Form des Testens als automatische Akzeptanztests. Durch die Trennung von dom¨anen- und systemspezifischen Bestandteilen des Testlings im Metamodell zielt MTCC dabei insbesonders auf die Tester- stellung f¨ur Systemfamilien ab.
Motivation f¨ur MTCC ist die Tatsache, dass bestehende Verfahren zur Automatisierung von Akzeptanztests, etwa Capture Replay oder Actionwords [BBN04, GF00], entweder zu abh¨angig von Implementierungsdetails sind oder sich nicht f¨ur die Verwendung durch Anwender eignen. Insbesonders sehen wir die folgenden Vorteile bez¨uglich Testqualit¨at und Testaufwand in der Spezifikation und Ausf¨uhrung automatischer Tests durch MTCC:
• Es wird eine Oberfl¨ache bereitgestellt, die Anwender bei der Testspezifikation un- terst¨utzt und den Aufwand der Testerstellung vermindert.
• Durch die Verwendung der Testspezifikationsoberfl¨ache werden Dom¨anenexperten in den Testprozess einbezogen und in die Lage versetzt, sowohl das Verhalten des Testlings als auch die zur Verf¨ugung stehenden Testm¨oglichkeiten zu beurteilen.
• Tests werden als Modelle entkoppelt von Umsetzungsdetails gespeichert. Dies er- laubt die Verwendung von Tests f¨ur unterschiedliche Systeme, Systemvarianten und Versionen; das Ausprogrammieren spezifischer Tests f¨ur diese Versionen entf¨allt.
• Da Tests als Modelle vorliegen, ist die Introspektion der vorhandenen Tests m¨oglich.
Dies bildet die Grundlage f¨ur Verfahren zur Ermittlung der Testabdeckung.
Im Anschluss stellt Abschnitt 2 den MTCC-Ansatz vor. Abschnitt 3 nennt verwandte Ar- beiten und Themenbereiche. Abschnitt 4 schließt den Text ab.
2 MTCC - Modellgetriebene Testfallkonstruktion
MTCC ist ein Ansatz, um Anwendern eines Systems und Dom¨anenexperten die Modellie- rung automatisch durchf¨uhrbarer Tests durch Bereitstellung einer Benutzungsoberfl¨ache zu erm¨oglichen.
Abbildung 1 gibt einen ¨Uberblick der in MTCC verwandten Komponenten und des zu- grunde liegenden Prozesses: Eine Instanz der Benutzungsoberfl¨ache wird instanziert, mit- tels dieser Oberfl¨ache wird das Modell eines Testfalls spezifiziert, dieser wird in einen ausf¨uhrbaren Testfall transformiert, welcher schließlich ausgef¨uhrt wird.
SystemModel«Model»
EditorInstance SpecificTestModel«Model»
TestGenerator«Generator» Testling
Test
«Generated»
TestMetaModel«MetaModel»
TestRunner eingeschränkt
durch
Instanz von verwendet
gibt aus
wird ausgeführt von Eingabe
für gibt aus
testet
EditorPlatform Instanz von repräsentiert durch
eingeschränkt durch
Abbildung 1: Grundlegender Prozess und Konzepte von MTCC
Grundlage f¨ur die Bereitstellung der Testspezifikationsoberfl¨ache in Form einerEditorIn- stance(EI) sind dasSystemModel(SM), dasTestMetaModel (TMM) und dieEditorPlat- form (EP). Beim SMhandelt es sich um ein spezialisiertes Featuremodell [CHE05] der testrelevanten Merkmale der fachlichen Dom¨ane. Das TM ist ein Katalog von parame- trisierbaren Aktionen und Tests mit Referenzen auf die f¨ur die Durchf¨uhrung der Tests ben¨otigten Merkmale des Testlings. Die Testplattform verwendet das durch die imSMvor- handenen Features eingeschr¨ankteTMM, um eineEIzu konfigurieren oder aus den Mo- dellen zu transformieren, durch die Implementierung verschiedenerEPs k¨onnen mehrere Editierumgebungen bereitgestellt werden.
Abbildung 2 zeigt eine Editierumgebung f¨ur einen Test aus der Dom¨ane der Information Retrieval Systems f¨ur bibliographische Daten. Im vorliegenden Fall wird dasSTMals Fol- ge von Eingabemasken dargestellt, wobei die Parametrisierung der Eingabemasken fest- legt, welche Elemente desSTMund somit welche Masken im Folgeschritt zur Verf¨ugung stehen.
Im ersten Schritt werden Testling und Fixture ausgew¨ahlt, hier der GIRT4-Textkorpus, und globale Optionen f¨ur das zu testende System festgelegt, hier die Erweiterung von Anfra- geergebnissen um externe Daten. Nach dieser Festlegung kann eine Aktion ausgew¨ahlt werden, die auf dem System ausgef¨uhrt wird, im dargestellten Fall dieFeldbasierte Su- che. Diese Aktion kann nun parametrisiert werden, wobei die zu Verf¨ugung stehenden
Min 5 Ergebnisgrösse
100 Max Anfragezeit
Min (Sekunden) 5 Relevanz
Titel Jugend in der ...
Document
Jahr 1999
...
ID iz-solis-910001
Document ...
Bedingung Zeitbedingung ...
IR System System
Setup
Duplettenentfernung Anfrageerweiterung GIRT4
Fixture
Name Beispieltest
Szenario Feldbasierte Suche ...
Titel Entwicklungen der A
Thema Jugend
Text AND
OR
2 1 3
Abbildung 2: Mockup einer generierten Testoberfl¨ache f¨ur Information Retrieval Systeme M¨oglichkeiten zur Parametrisierung durch das vomSMbeschr¨ankte und spezialisierteTMM vorgegeben sind.
In einem dritten Schritt werden drei Bedingungen angegeben, von denen erwartet wird, dass sie nach der Ausf¨uhrung derFeldbasierten Sucheerf¨ullt sind. Die zur Auswahl ste- henden Bedingungen sind von der vorangegangenen Aktion abh¨angig. Im Beispiel werden Erwartungen zur Dauer der Anfragebearbeitung, zum Umfang der Ergebnismenge und zu Dokumenten und Dokumentenreihenfolge formuliert.
UML-Diagramme sind nach unserem Daf¨urhalten nicht f¨ur die Spezifikation von Abnah- metests geeignet. F¨ur eine Modellierung von Tests m¨ussten die Diagramme formalisiert werden [Bin99], als Folge einer solchen Formalisierung w¨are jedoch die Eignung der Dia- gramme zur Testmodellierung durch Anwender in Frage gestellt, gleiches gilt f¨ur die Ver- wendung von Notation wie der TTCN [SDGR03].
Nach der Beschreibung des Testszenarios gibt dieEIdas vollst¨andig parametrisierteSTM aus, dieses wird vom TestGenerator, eventuell unter Einbeziehung externer Daten wie Templates [CH06], in selbst¨andig ausf¨uhrbare Testf¨alle f¨ur einen geeignetenTestRunner transformiert.
3 Verwandte Arbeiten
MTCC verbindet Konzepte der modellgetriebenen Softwareentwicklung und der Automa- tisierung von Akzeptanztests.
Mit Automatisierung von Akzeptanztests weist MTCC in der Zielsetzung Parallelen zu FIT [MC05] auf, unterscheidet sich jedoch insofern, als dass FIT generische Modelle f¨ur die Beschreibung von Tests entweder in Form von Tabellen oder Aktionen verwendet,
w¨ahrend MTCC die Besonderheiten der fachlichen Dom¨ane und des jeweiligen Testlings bewusst durch die Verwendung von Metamodellen einbezieht. Weiterhin betrachtet FIT nur ein zu testendes System, MTCC betrachtet dagegen explizit die Testerstellung f¨ur Sys- temfamilien.
Mit der Betrachtung von Software Systemfamilien weist MTCC Verwandtschaft mit Soft- wareproduktlinien [CN01] und der Generativen Softwareentwicklung [CE00] auf, auch verwendet MTCC f¨ur die Darstellung von Systemen die in diesem Kontext eingef¨uhrten Featuremodelle und besch¨aftigt sich mit der Fragestellung, wie ausgehend von Feature- modellen, Modelle eines Produkts parametrisiert werden k¨onnen [CA05].
Konzeptionell handelt es sich bei MTCC um einen Ansatz zum dom¨anenspezifischen Tes- ten [vMMW94, Sin05], wobei jedoch mit der Betrachtung von automatischen Akzeptanz- tests und der Verwendung von modellgetriebenen Methoden Unterschiede in Zielsetzung und Methodik vorliegen.
Durch die Kombination von formalen Modellen und der Verwendung von explizit mo- dellierten Tests handelt es sich bei MTCC um einen Ansatz zum modellgetriebenen Tes- ten von Software. Verwandtschaft besteht zu Ans¨atzen, die empirisch gewonnene Daten zur Erg¨anzung von Testmodellen verwenden [EKR03], MTCC unterscheidet sich hinge- gen durch die Einbeziehung von Dom¨anenexperten von Ans¨atzen, die sowohl Testf¨alle als auch Oracles aus einem Modell des Testlings und dessen Umgebung erzeugen [GHK+00].
Auch unterscheidet sich MTCC von Arbeiten, die Konstruktionsmodelle neben der Erstel- lung einer Implementierung auch zur Implementierung von Tests nutzen [Dai04].
4 Fazit
Durch die Verwendung von Modellen als Mittel der Testspezifikation kann eine Trennung von Testintention und Testausf¨uhrung erreicht werden. Diese Trennung vereinfacht die Erstellung, Pflege und Ausf¨uhrung von Testf¨allen f¨ur Systeme oder Systemfamilien. Um Personen ohne Programmiererfahrung in den Testprozess einzubinden, sieht MTCC vor auf Basis von Modellen zur Beschreibung eines Testlings wie der Anwendungsdom¨ane eine dedizierte Benutzungsoberfl¨ache f¨ur die Spezifikation von Testf¨allen bereitzustellen.
MTCC befindet sich zur Zeit in der Entwurfphase, eine Implementierung und Evaluation bez¨uglich der Eignung des Ansatzes und des Testaufwands im Vergleich zum automa- tischen Testen und zum manuellen Testen ist in der Dom¨ane der Information Retrieval Systeme f¨ur wissenschaftliche Fachinformation vorgesehen. Gegenstand der Evaluation ist der Test einer Familie von Systemen mit ¨ahnlichen Anforderungen, aber unterschiedli- chen Merkmalen und technischen Grundlagen.
Literatur
[BBN04] M. Blackburn, R. Busser und A. Nauman. Why Model-Based Test Automation is Different and What You Should Know to Get Started. InInternational Conference on Practical Software Quality, 2004.
[Bin99] Robert V. Binder. Testing Object-Oriented Systems: Models, Patterns, and Tools.
Addison-Wesley, 1999.
[CA05] Krzysztof Czarnecki und Michal Antkiewicz. Mapping Features to Models: A Tem- plate Approach Based on Superimposed Variants. InInternational Conference on Ge- nerative Programming and Component Engineering, 2005.
[CE00] Krysztof Czarnecki und Ulrich W. Eisenecker. Generative Programming. Methods, Tools and Applications. Addison-Wesley, 2000.
[CH06] Krzysztof Czarnecki und Simon Helsen. Feature-Based Survey of Model Transfor- mation Approaches. IBM Systems Journal, special issue on Model-Driven Software Development, 45(3):621–645, 2006.
[CHE05] Krzysztof Czarnecki, Simon Helsen und Ulrich Eisenecker. Formalizing Cardinality- based Feature Models and their Specialization. Software Process Improvement and Practice, special issue of best papers from SPLC04, 10(1):7 – 29, 2005.
[CN01] Paul Clements und Linda M. Northrop. Software Product Lines : Practices and Pat- terns. Addison Wesley, 3rd. Auflage, 2001.
[Dai04] Zhen Ru Dai. Model-Driven Testing with UML 2.0. InSecond European Workshop on Model Driven Architecture (MDA) EWMDA, Seiten 179–188, 2004.
[EKR03] Sebastian Elbaum, Srikanth Karre und Gregg Rothermel. Improving web application testing with user session data. InICSE ’03: Proceedings of the 25th International Con- ference on Software Engineering, Seiten 49–59, Washington, DC, USA, 2003. IEEE Computer Society.
[GF00] Dorothy Graham und Mark Fewster, Hrsg.Software Test Automation: Effective Use of Test Execution Tools. Addison-Wesley, 2000.
[GHK+00] Ilan Gronau, Alan Hartman, Andrei Kirshin, Kenneth Nagin und Sergey Olvovsky. A Methodology and Architecture for Automated Software Testing. Bericht, IBM Rese- arch Laboratory Haifa, 2000.
[MC05] Rick Mugridge und Ward Cunningham. FIT for Developing Software. Framework for Integrated Tests. Prentice Hall PTR, 2005.
[SDGR03] Ina Schieferdecker, Zhen Ru Dai, Jens Grabowski und A. Rennoch. The UML 2.0 Testing Profile and its relation to TTCN-3. InTestCom 2003 : testing of communicating systems, Jgg. 2644 ofLecture Notes of Computer Science, Seiten 79–94, 2003.
[Sin05] Avik Sinha. DOMAIN SPECIFIC TEST CASE GENERATION USING HIGHER OR- DERED TYPED LANGUAGES FOR SPECIFICATION. Dissertation, University of Maryland, April 2005.
[vMMW94] Anneliese von Mayrhauser, Richard T. Mraz und Jeff Walls. Domain Based Regres- sion Testing. InICSM ’94: Proceedings of the International Conference on Software Maintenance, Seiten 26–35, Washington, DC, USA, 1994. IEEE Computer Society.
