Testen von serviceorientierten Architekturen ... · Zusammenfassung Serviceorientierte...

Gottfried WilhelmLeibniz Universität Hannover

Fakultät für Elektrotechnik und InformatikInstitut für Praktische InformatikFachgebiet Software Engineering

Testen von serviceorientiertenArchitekturen: Teststrategie und

Implementierung

Masterarbeit

im Studiengang Informatik

von

Dennis Hardt

Prüfer: Prof. Dr. Kurt SchneiderZweitprüfer: Prof. Dr.-Ing. Christian Grimm

Betreuer: Dr. Jan-Mirko MaczewskiBetreuer: Dipl.-Wirt.-Inform. Daniel Lübke

Hannover, 29. Oktober 2007

Zusammenfassung

Serviceorientierte Architekturen (SOA) haben sich zu einem bekannten Paradigma zurStrukturierung von Applikationen entwickelt. An ihre aktiven Einheiten, die Services,werden hohe qualitative Ansprüche gestellt, um sie in einem beliebigen Umfeld ein-setzen zu können. Dabei wird in der Forschung und Entwicklung oftmals speziell dasTesten von Webservices betrachtet; die Beschreibung einer Teststrategie bleibt jedochaus.

Diese Arbeit stellt nicht nur eine Auswahl von potentiellen Problemen vor, die in ei-ner SOA auftreten können, sondern ermöglicht auch diese Probleme als Grundlagezur Formulierung einer Teststrategie zu nehmen. Dazu werden die Artefakte, die ei-ne Teststrategie für eine SOA beschreiben, identifiziert und präsentiert. Die Definitioneiner allgemeinen Vorgehensweise zur Findung einer konkreten Teststrategie erlaubtTeststrategien für beliebige SOA-Projekte zu bestimmen.

Ein im Rahmen dieser Arbeit entwickeltes Werkzeug erlaubt nicht nur die Umsetzungeiner Teststrategie, sondern ermöglicht auch die Realisierung von Teststufen exem-plarisch für in .NET implementierte Webservices. Dazu stellt diese Arbeit eine neueSichtweise auf Komponenten vor und trennt diese klar von Kompositionen ab. Erfah-rungen mit dem Werkzeug und einer konkret entwickelten Teststrategie wurden imRahmen einer Fallstudie bei einem Unternehmen gesammelt.

ii

Inhaltsverzeichnis

1. Einführung 11.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Struktur dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Grundlagen 42.1. Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1. Grundbegriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2. Ausgewählte Testmethoden . . . . . . . . . . . . . . . . . . . . . 52.1.3. Teststufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.4. Teststrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2. Serviceorientierte Architekturen . . . . . . . . . . . . . . . . . . . . . . . 82.2.1. Grundbegriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2. Konsequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3. Plattformen für Unternehmensanwendungen . . . . . . . . . . . . . . . 122.4. Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.1. Grundbegriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.2. Webservice Standards . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3. Ableitung einer Teststrategie für serviceorientierte Architekturen 153.1. Einordnung der Teststrategie . . . . . . . . . . . . . . . . . . . . . . . . 153.2. Einflüsse auf die Teststrategie . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1. Idee, Plattform und Technologie . . . . . . . . . . . . . . . . . . 163.2.2. Projektumfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3. Teststrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.1. Serviceumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.2. Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.3. Testszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4. Komponententests für eine SOA . . . . . . . . . . . . . . . . . . . . . . 223.4.1. Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4.2. Identifikation der Komponente bei Services . . . . . . . . . . . . 233.4.3. Austauschen von Komponenten in Services . . . . . . . . . . . . 23

3.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4. Testaspekte für SOA, Webservices und .NET 274.1. Identifikation von Testaspekten . . . . . . . . . . . . . . . . . . . . . . . 28

4.1.1. SOA als Idee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

iii

Inhaltsverzeichnis

4.1.2. Webservices als Technologie . . . . . . . . . . . . . . . . . . . . 324.1.3. .NET als Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2. Analogien zu Java EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5. Werkzeugunterstützung für die Teststrategie 365.1. Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1.1. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.1.2. Konsequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.1.3. Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.2. Testmöglichkeiten in .NET . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3. Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3.1. Grobarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.3.2. Testablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3.3. Adapter zu einem Unit Test Framework . . . . . . . . . . . . . . 425.3.4. Interaktion mit externen Systemen . . . . . . . . . . . . . . . . . 44

5.4. Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.5. Realisierung von harten Mocks . . . . . . . . . . . . . . . . . . . . . . . 47

5.5.1. Identifikation von auszutauschenden Teilen . . . . . . . . . . . . 475.5.2. Verarbeitung und Austauschen von Code . . . . . . . . . . . . . 47

5.6. Realisierung von weichen Mocks . . . . . . . . . . . . . . . . . . . . . . 495.7. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6. Fallstudie 536.1. Projektumfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.1.1. Betrachtete Webservices . . . . . . . . . . . . . . . . . . . . . . 546.1.2. Bisheriges Vorgehen beim Testen der Webservices . . . . . . . 55

6.2. Eine konkrete Teststrategie . . . . . . . . . . . . . . . . . . . . . . . . . 566.2.1. Annahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.2.2. Testmatrix und Testszenarien . . . . . . . . . . . . . . . . . . . . 56

6.3. Anwendung der Teststrategie . . . . . . . . . . . . . . . . . . . . . . . . 596.3.1. Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.3.2. Gefundene Fehler . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.4. Lektionen und Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . 646.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7. Kritische Würdigung 667.1. Kritischer Rückblick auf den Erarbeitungsprozess . . . . . . . . . . . . . 667.2. Stärken und Schwächen einer Teststrategie . . . . . . . . . . . . . . . . 667.3. Stärken und Schwächen der entwickelten Erweiterungen . . . . . . . . 677.4. Kritischer Rückblick auf die Fallstudie . . . . . . . . . . . . . . . . . . . 68

8. Verwandte Arbeiten 708.1. Andere Ansätze und Werkzeuge . . . . . . . . . . . . . . . . . . . . . . 708.2. Testaspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718.3. Testen von Kompositionen . . . . . . . . . . . . . . . . . . . . . . . . . . 71

iv

Inhaltsverzeichnis

9. Zusammenfassung und Ausblick 739.1. Rückblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749.3. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Literaturverzeichnis 76

A. Testszenarien 79

v

1. Einführung

1.1. Motivation

Serviceorientierte Architekturen (SOA) sind längst mehr als nur ein Schlagwort oderWerbeträger. Das zentrale Ziel einer SOA besteht in der Reduktion von Abhängigkei-ten zwischen Softwarelösungen [Sta06a]. Aber Dienste in heterogenen, dynamischenund verteilten Umgebungen anzubieten, fordert neue Sichtweisen beim Testen einesServices. So sind viele bekannte Testverfahren und -werkzeuge nicht mehr anwendbar[CP06].

Webservices sind nur eine mögliche Implementierung von Services [Sta06a]. Den-noch hat sich diese Technologie als die dominierende und am weitesten verbreiteteRealisierung für SOA etabliert. Nicht zuletzt unterstützen viele Applikationsserver undEntwicklungsumgebungen aus dem Java- oder Microsoft .NET-Umfeld die Bereitstel-lung von Webservices [MTSM03][GP06]. Selbst Unternehmen, unter anderem zu nen-nen seien Amazon1 und Ebay2, lagern Teile ihrer Dienste in Webservices aus. Folglichkönnen Kunden von überall auf der Welt ohne Benutzeroberfläche mit einem Geschäftinteragieren und es sogar in ihre eigenen Geschäftsprozesse einbinden.

Ein Kernkonzept von SOA ist die Komposition oder Zusammenschaltung von Services,um eine Applikation zu bilden [HS05]. Infolgedessen führen Fehler in einem einzelnenService zu fehlerhaftem Gesamtverhalten. Testen wird somit unabdingbar, um die qua-litativ hochwertige Implementierung von jedem Service sicher zu stellen. Insbesonderein den letzten Jahren wurden viele neue Ansätze und Werkzeuge entwickelt, um dasTesten von SOA zu verbessern. Dennoch beruhen alle Entwicklungen auf denselbenAnsätzen und betrachten Services als eine abgeschlossene Einheit, so dass sich dasTesten selbst mitunter als sehr schwierig erweist.

Durch die Verfügbarkeit von einfach zu handhabenden Werkzeugen [BG98] habenKomponententests zunehmend an Bedeutung gewonnen. Für nahezu jede Plattformist ein „xUnit Test Framework“ [Ham04] verfügbar und erlaubt die einheitliche Formu-lierung von Komponententests . Auch die Integration in Entwicklungsumgebungen hatsich stetig verbessert [GP06], so dass Komponententests zu einer entwicklernahenund praktikablen Lösung geworden sind. Auch wenn für eine SOA Werkzeuge wiez.B. BPELUnit [May06] oder WSUnit [WSU] existieren, so nehmen sie eine bestimmteSichtweise bei Komponententests ein. Oft werden jedoch bekannte Bibliotheken undobjektorientierte Programmiersprachen eingesetzt, um einen Service zu realisieren.Speziell in diesem Umfeld versagen beim Testen Konzepte, die für objektorientierte

1http://www.amazon.com2http://www.ebay.com

1

1. Einführung

Software zur täglichen Praxis geworden sind. Sowohl die Interaktion mit einem Ser-vice, als auch das Austauschen von Komponenten, erfordert neue Sichtweisen undIdeen.

Das Testen von Webservices und Kompositionen hat in der Forschung viel Aufmerk-samkeit erfahren. Insbesondere die Eigenschaften, die bei einem Webservice funktio-nal zu testen sind, sind wohl bekannt. Dennoch bleibt beim Testen die genaue Vorge-hensweise unklar. Es fehlt eine Strategie, die Aktivitäten den Teststufen zuordnet undz.B. festlegt welche Tests zu automatisieren sind. Mitunter benötigt auch diese Test-strategie weitere Unterstützung durch Werkzeuge, um erst praktikabel umsetzbar zusein.

1.2. Problemstellung

Diese Arbeit befasst sich im Allgemeinen mit dem Testen von serviceorientierten Ar-chitekturen. Im Einzelnen sind dazu die folgenden Punkte gezielt zu adressieren:

• Ziel dieser Arbeit ist eine Teststrategie für serviceorientierte Architekturen bereitzu stellen, so dass beim Einsatz einer SOA die Vorgehensweise beim Testenbekannt ist. Beginnen soll die Teststrategie bei Komponententests, aber auchhöhere Teststufen sind zu berücksichtigen.

• Falls erforderlich ist ein Werkzeug zu erstellen, das die Umsetzung der Teststra-tegie praktisch ermöglicht. Speziell die Realisierung von Komponententests istdabei zu berücksichtigen.

• Im Rahmen einer Fallstudie ist zu prüfen, ob die vorgeschlagene Teststrate-gie umsetzbar ist und erstellte Werkzeuge praktikabel sind. Als Testobjekte wer-den Webservices dienen, die von einem Unternehmen entwickelt wurden undvon ihren Kunden genutzt werden. Hierbei sollen insbesondere die notwendigenSchritte zur Erzeugung von Testdaten nachvollziehbar sein. Zur Entwicklung wirdvom Unternehmen das Microsoft .NET Framework und die Microsoft Visual Stu-dio Team Edition [GP06] eingesetzt, so dass alle erstellten Werkzeuge und Testsdort anwendbar sein müssen.

1.3. Struktur dieser Arbeit

Diese Arbeit untergliedert sich in die folgenden Kapitel:

• In Kapitel 2 werden einige Grundlagen über Testen und serviceorientierte Archi-tekturen unabhängig voneinander eingeführt. Aufgrund unterschiedlicher Defini-tionen im SOA-Umfeld, werden die verwendete Terminologie und das Verständ-nis von einer SOA definiert.

• Aufgrund bestimmter Einflüsse ist es nicht möglich direkt eine Teststrategie fürSOA anzugeben. Kapitel 3 wird alle Einflüsse analysieren und ein allgemeines

2

1. Einführung

Vorgehen zur Findung einer Teststrategie präsentieren.

• Kapitel 4 wird konkret für Webservices und dem Microsoft .NET Framework po-tentielle Probleme nach dem Vorgehen aus Kapitel 3 vorstellen. Webservicesund das Microsoft .NET Framework werden aufgrund der Relevanz in der Fall-studie in Kapitel 6 betrachtet.

• Kapitel 5 stellt ein Werkzeug vor, mit dem Teststufen für Webservices umgesetztwerden können und eine nach Kapitel 3 angegebene Teststrategie realisierbarwird.

• In Kapitel 6 werden die Ergebnisse aus den Kapiteln 3, 4 und 5 in einer Fallstudiezusammengeführt, um die Webservices eines Unternehmens zu testen.

• Die Stärken und Schwächen der Teststrategie und des Werkzeugs werden ineiner kritischen Würdigung in Kapitel 7 beleuchtet.

• Kapitel 8 zeigt verwandte Arbeiten, um die Einordnung dieser Arbeit in den wis-senschaftlichen Kontext zu erleichtern.

• Diese Arbeit schließt in Kapitel 9 mit einer Zusammenfassung und einem Aus-blick ab.

3

2. Grundlagen

Während der Entwicklung durchlebt Software einen Lebenszyklus, der sich in mehrereAktivitäten unterteilt. Von der Analyse der Anforderungen, über die Programmierung,bis zum Testen, arbeiten in jeder Aktivität verschiedene Persönlichkeiten zusammen.Oftmals wird dieses Vorgehen definiert, sei es durch das V-Modell [Boe79] oder durchagile Entwicklungsmethoden, z.B. Extreme Programming (XP) [Bec00].

Testen ist eine Aktivität, deren Durchführung die Qualität eines Produktes bewertet[IEE04]. Hierbei ist ein Test die Ausführung und Beobachtung von Teilen des Produk-tes. Die sich anschließende Behebung von identifizierten Mängeln und Fehlern verbes-sert das Produkt. Sowohl das V-Modell, als auch XP, sehen Tests als durchzuführendeAktivität vor. Dabei hat jedes Projekt ein individuelles Vorgehen und unterschiedlicheKapazitäten zur Realisierung von Tests. Speziell in XP testen nur Entwickler ihren Co-de durch automatisierte Komponententests.

Serviceorientierte Architekturen (SOA) sind ein Stil zur Strukturierung von Applikatio-nen. Durch viel Aufmerksamkeit in der Industrie sind sehr unterschiedliche Definitio-nen einer SOA entstanden [OAS06]. Besonders die Trennung zu Webservices ist ver-schwommen, weil sich Webservices zur verbreitetsten und bekanntesten Umsetzungvon Services etabliert haben.

Dieses Kapitel wird alle für den Verlauf dieser Arbeit wichtigen Begriffe bezüglich desTestens und SOA definieren. In den Folgekapiteln werden beide Themengebiete dannlangsam einander angenährt, um eine Teststrategie für SOA zu formen.

2.1. Testen

2.1.1. Grundbegriffe

Tester sind die Scheinwerfer in einem Projekt, die die Straße für Programmierer undManager erleuchten [KBP02]. Sie zeigen, ob man sich nahe am Abgrund bewegt oderauf sicherer Spur fährt.

Im Allgemeinen ist das Produkt der Programmierung ein ausführbares Kompilat. BeimTesten sind es Testfälle, die letztendlich genutzt werden, um Aspekte einer Softwa-re in einem bestimmten Umfeld zu testen. Ein Testfall besteht dabei aus Eingabe-daten, Ausführungsbedingungen und erwarteten Ergebnissen [IEE90]. Die Ableitungoder Auswahl von Testfällen ist durch Testmethoden [SLS06] möglich.

Im Allgemeinen lässt sich jeder Test über fünf Dimensionen beschreiben [KBP02]:

4

2. Grundlagen

• Tester: Wer führt einen Test durch? Neben Testern, können auch andere Benut-zergruppen Tests durchführen:

– Entwickler testen ihren Code z.B. durch automatisierte Komponententestsin XP.

– Endnutzer testen ein Produkt im Rahmen eines Betatests.

• Abdeckung: Was wird getestet? Zum Testen wird immer ein Testobjekt benö-tigt, das durch konkrete Testfälle geprüft wird. Hierbei kann es sich z.B. um dieMethode einer Klasse handeln oder die Oberfläche einer Applikation.

• Potentielle Probleme: Warum wird getestet? Welche Fehler können im Produktauftreten?

• Aktivitäten: Wie wird getestet?

• Auswertung: Wann ist ein Test erfolgreich und wann fehlgeschlagen? Tritt dergewünschte Effekt bei Ansteuerung des Testobjekts ein, d.h. sind resultierendeWerte korrekt oder wird eine erwartete Fehlermeldung geliefert.

Beispiel 2.1Bei der Testmethode „Testen von Funktionen“ („function testing“) wird jede Funktioneinzeln nacheinander getestet. Demzufolge wird nur eine Aussage über die Abde-ckung getroffen, aber wer den Test durchführt (Tester) oder was für Fehler (PotentielleProbleme) gesucht werden, bleibt unbekannt. [KBP02]

Testmethoden sind formal anwendbare Methoden, die noch nicht in allen Dimensioneneine Ausprägung besitzen.

Definition 2.1Ein Testaspekt ist eine Ausprägung über der Dimension: Potentielle Probleme. Zu-sätzlich beschreibt ein Testaspekt die Vorgehensweise zur Herleitung von Testfällenunter Einbezug von Testmethoden.

Ein Testaspekt beschreibt somit eine Klasse von Fehlern, die in einem Testobjekt auf-treten können. Insbesondere ist aber auch das Vorgehen zur Findung dieses Fehlerszu beschreiben. Wenn bekannte Testmethoden existieren, sind diese anzugeben, an-sonsten ist eine allgemeine Beschreibung zur Ableitung von Testfällen zu definieren.Im Verlauf dieser Arbeit werden ausschließlich Testaspekte benutzt, um potentielleProbleme in einer SOA zu definieren und die Vorgehensweise zum Auffinden dieserProbleme festzuhalten.

2.1.2. Ausgewählte Testmethoden

In dieser Arbeit werden potentielle Probleme über Testaspekte beschrieben. Dabeistützt sich die Beschreibung der Vorgehensweise zur Identifikation von repräsentier-ten Fehlern auf Testmethoden, von denen eine benutzte Auswahl im Folgenden kurz

5

2. Grundlagen

vorgestellt sei. Jede Testmethode ist durch ihren englischen Namen benannt und fürweitere Informationen sei auf die angegebene Literatur verwiesen:

• Equivalence partitioning ([IEE04], [KBP02]): Unterteilung von Testdaten in Äqui-valenzklassen, d.h. alle Testdaten aus einer Äquivalenzklasse führen bei einemTest zu äquivalentem Verhalten. So genügt es für ausgewählte Elemente einerÄquivalenzklasse zu testen.

• Regression testing ([IEE04], [KBP02], [SLS06]): Erneutes Testen eines Systemsnach einer Modifikation, um zu verifizieren, dass durch Änderungen keine un-beabsichtigten Effekte im System entstanden sind. Dazu werden vorhandeneTestfälle erneut verwendet.

• Statement and branch coverage ([IEE04], [KBP02]): Man erreicht 100% state-ment and branch coverage, wenn ein Test jede Anweisung und jeden Zweig imProgramm ausführt. Tests werden so gestaltet, dass sie eine möglichst hohestatement and branch coverage erzielen.

• Function testing ([KBP02]): Testen von jeder Funktion einzeln und nacheinander.White-Box Ansätze testen dabei jede Funktion wie man sie im Code sieht. Black-Box Ansätze testen jede Funktion wie sie ein Benutzer im System nutzt.

• Specification testing ([KBP02]): Verifizierung sachbezogener Anforderungen, diein Spezifikationen, Handbüchern oder anderen Dokumenten an das Produkt ge-stellt werden.

• Load testing ([KBP02]): An ein System werden viele Anfragen gestellt. Bei einerhohen Auslastung wird das System wahrscheinlich ausfallen, so dass Schwach-stellen offensichtlich werden.

• Performance testing ([IEE04], [KBP02]): Verifiziert, ob ein System Anforderun-gen an die Leistung erfüllt, z.B. an den Durchsatz oder an Antwortzeiten. Er-hebliche Leistungseinbrüche gegenüber einer vorherigen Version des Systemskönnen auf Fehler in der Programmierung hinweisen.

• Long sequence testing ([KBP02]): Über Nacht, Tage oder Wochen werden An-fragen an ein System gestellt.

• Smoke testing ([KBP02]): Testet grundlegende Eigenschaften, von denen erwar-tet wird, dass sie im System funktionsfähig sind. Ziel ist es zu prüfen, ob eineneue Version des Systems würdig ist getestet zu werden. Diese Tests sind oft-mals automatisiert.

• Path testing ([KBP02]): Ein Pfad beinhaltet alle Schritte, die ein Tester ausführt,oder alle Anweisungen, die ein Programm ausführt, um einen bestimmten Zu-stand zu erreichen. Dabei ist es nicht möglich alle Pfade eines nicht trivialenProgramms zu testen.

• Configuration testing ([IEE04], [KBP02]): Analyse von Software unter Einsatzverschiedener spezifizierter Konfigurationen.

• Boundary-value analysis ([IEE04], [KBP02]): Lassen sich Äquivalenzklassen für

6

2. Grundlagen

Zahlenwerte aufstellen, so sind die Grenzen der kleinste und größte Wert dieserKlasse. Testfälle nutzen diese Grenzen und Werte nahe den Grenzen.

2.1.3. Teststufe

Die Ursache eines Mangels in einem großen und komplexen System zu finden, istmitunter ein schwieriges Unterfangen. In der objektorientierten Programmierung inter-agieren am Ende eines Projekts Tausende von Objekten miteinander, um eine Appli-kation zu formen. Existiert in einem dieser vielen Objekte ein Fehler, so lässt er sichnur schwer identifizieren. Eine Abschwächung dieses Problems ist durch den Einsatzvon drei Teststufen möglich:

1. Komponententests (unit test [IEE04]): Eine Komponente sei die kleinste kom-pilierbare Einheit in einer Applikation [Tam02], so sind es z.B. in der objektori-entierten Programmierung die Klassen [SLS06]. Komponententests verifizierenjede einzelne Komponente isoliert von allen anderen Komponenten durch denEinsatz von künstlichen Umgebungen [Tam02]. Praktisch werden dazu Mocks1

eingesetzt, die das Verhalten einer Komponente simulieren [TH02]. Dabei habenMocks das Ziel so einfach wie möglich umgesetzt zu sein und nicht die Logik derersetzten Komponente nachzubilden [MFC01].

Verfasst werden Komponententests z.B. mit Unit Test Frameworks, die für eineVielzahl von Sprachen zur Verfügung stehen [Ham04]. Dennoch setzen Kompo-nententests voraus, dass alle von einer Komponente benutzten Komponentenaustauschbar sind. In der objektorientierten Programmierung kann dies durcheinen Programmierstil erreicht werden, der z.B. auf geringe Komplexität setztund von globalen Objekten unabhängig ist [Goo06]. Zusätzlich haben sich überdie Jahre Werkzeuge entwickelt, die bei der Erstellung von Mocks unterstützen[FMP+] oder auch die Anforderungen an die Testbarkeit reduzieren [Typ].

2. Integrationstests (integration test [IEE04]): Als Folgestufe nach Komponenten-tests werden bei Integrationstests Komponenten zu größeren Teilsystemen inte-griert [SLS06]. Ziel ist es durch schrittweise Integration sicherzustellen, dass alleKomponenten korrekt zusammenarbeiten.

3. Systemtests (system test [IEE04]): Systemtests verifizieren bzw. validieren dasgesamte Produkt, nachdem alle Teile einer Software integriert wurden [Tam02].Insbesondere sind andere Sichtweisen testbar als dies auf niedrigeren Stufender Fall ist - z.B. Performance- und Lasttests.

Der Einsatz von Teststufen erleichtert das Testen, indem nicht immer mit einem evtl.großem und unübersichtlichem Produkt gearbeitet wird. Das Testen von einzelnenKomponenten und deren Zusammenspiel erweist sich oftmals als einfacher. Für dieseArbeit sind Abnahmetests unerheblich und seien daher nicht angeführt.

1Auch: Stub oder Dummy

7

2. Grundlagen

2.1.4. Teststrategie

Bisher wurde eine kleine Auswahl an Grundbegriffen aus dem Bereich des Testensvorgestellt. Dennoch beschreiben all diese Ansätze und Methoden noch nicht wie einProdukt zu testen ist. Es fehlt eine Darlegung der Vorgehensweise, genauer die Test-strategie.

Eine Teststrategie ist mehr als nur eine Sammlung von Testmethoden, aber auch nochkein Testkonzept [KBP02]. Ziel ist die Festlegung eines einheitlichen Ansatzes für diezukünftige Testplanung. Eine Teststrategie legt den Umfang durchzuführender Testsfest und adressiert nur Probleme mit kritischem Risiko [SLS06].

Definition 2.2Eine Teststrategie ist die „(1) Abstrakte Beschreibung der Teststufen und der zugehö-rigen Ein- und Ausgangskriterien . . . (2) Aufteilung von Testaufwand über die zu tes-tenden Teile und/oder zu erfüllende Qualitätsmerkmale des Testobjekts. Auswahl undBestimmung der Reihenfolge von einzelnen Testmethoden und der Reihenfolge ihrerAnwendung auf die verschiedenen Testobjekte . . . “ [imb]

Eine Teststrategie ist in der Regel in mehreren Projekten anwendbar [imb]. Sie be-schreibt den Einsatz von Teststufen und legt das Vorgehen beim Testen fest, wennmöglich unter Angabe von Testmethoden.

Beispiel 2.2Testgetriebene Entwicklung ist eine Teststrategie, die ein iteratives Vorgehen nahelegt. Bevor Code geschrieben wird, ist immer ein Test zu verfassen, der zunächst fehl-schlagen muss. Als Idee wird jede Methode einzeln mit Komponententests getestet,mit der Besonderheit, dass ein Testfall vor der Implementierung formuliert wird. Hö-here Teststufen werden nicht betrachtet. Insbesondere ist der Testaufwand festgelegt,weil kein Code ohne Test existiert.

Testaspekte beschreiben ein konkretes Problem und bilden eine Sammlung von Test-methoden, um das Problem ausfindig zu machen. Folglich kann eine Teststrategieüber Testaspekte beschrieben werden.

2.2. Serviceorientierte Architekturen


Im Folgenden wird ein einheitlich in dieser Arbeit verwendeter Sprachschatz für SOAeingeführt. Dabei liegt der Fokus auf Einfachheit, so dass für weitere Informationenauf [OAS06], [Sta06a] und [W3C04] verwiesen sei.

Definition 2.3Eine Schnittstelle ist ein Dokument, das beschreibt wie mit einem Objekt zu intera-gieren ist und was von einer Einheit angeboten wird. Erfolgt die Interaktion mit dieser

8

2. Grundlagen

Einheit über Nachrichten, so legt die Schnittstelle das Format der Nachrichten fest.

Zur Auswertung und Interpretation einer Schnittstelle ist eine einheitliche und öffentli-che Beschreibung notwendig. Die Beschreibung ist auch in der Lage mögliche Kom-munikationsformen zu realisieren.

Definition 2.4Eine Dokumentation ist ein Dokument, das die semantischen Eigenschaften, Rand-bedingungen und den Effekt einer Einheit beschreibt.

Die Schnittstelle und die Dokumentation einer Einheit sind Artefakte, durch die eineInteraktion mit der Einheit möglich wird.

Definition 2.5Ein Service ist eine aktive Einheit, die Anderen seine Dienste anbietet. Jeder Servicehat eine Schnittstelle, die Serviceschnittstelle, eine Beschreibung, die Servicebe-schreibung und optional eine Dokumentation, die Servicedokumentation. Die Kom-munikation zwischen Services erfolgt durch den Austausch von Nachrichten. Das Re-sultat einer Interaktion mit einem Service ist ein Effekt.

Ein Service wird in der Fachliteratur und im allgemeinen Gebrauch immer abstrakt alsein Anbieter von Diensten betrachtet. Die gegebene Definition stützt sich auf den Aus-tausch von Nachrichten, um Kopplungen an die Kommunikationsform zu reduzieren.

Eine SOA hat zum Ziel die Abhängigkeiten zwischen „Softwareinseln“ zu reduzieren[Sta06a]. Dabei befasst sich SOA jedoch nicht nur mit Services, sondern stellt auchdie Beziehungen zwischen zunächst drei Rollen her [Pap03]:

• Serviceanbieter (service provider ): Stellt einen Service zur Verfügung und ver-waltet die notwendige Infrastruktur.

• Servicekonsument (service consumer ): Möchte Dienste in Anspruch nehmenund sucht einen entsprechenden Service.

• Serviceregister (service registry ): Stellt ein Verzeichnis von Services bereit.

Jeder Service verwendet das „Bridge“-Entwurfsmuster [GHJV95], um die Service-schnittstelle von der Implementierung zu trennen [Sta06a]. Deshalb muss der Ser-viceanbieter nicht immer zwangsläufig auch der Ersteller des Services sein, so dassdie Rolle des Serviceentwicklers ebenfalls von Bedeutung ist. Diese Arbeit betrachteteine nach Abbildung 2.1 entsprechend erweiterte Darstellung des klassischen SOA-Dreiecks [Pap03].

Definition 2.6Die von einem Serviceentwickler erstellte Implementierung eines Services heißt Ser-viceimplementierung.

Durch die Kenntnis von Services ist es möglich eine serviceorientierte Architektur zudefinieren. Diese stützt sich auf Abbildung 2.1 und das erweiterte SOA-Dreieck. Ge-nauer ist das Zusammenspiel aller beteiligten Rollen die Kerneigenschaft einer SOA.

9

2. Grundlagen

Service-konsument

Finde

n

Veröffentlichen

Binden undAufrufen

Service-register

Service-anbieter

Service-entwicklerBereitstellen

Abbildung 2.1.: Erweitertes SOA-Dreieck

Definition 2.7Eine serviceorientierte Architektur (SOA) ist die Strukturierung einer Lösung nachdem erweiterten SOA-Dreieck.

2.2.2. Konsequenzen

Zum Verständnis dieser Arbeit ist es notwendig, einige Besonderheiten und Konse-quenzen aus dem Einsatz einer SOA zu kennen. Dabei ergibt sich eine Konsequenznicht immer unmittelbar aus vorhergehenden Definitionen, sondern entsteht durch denpraktischen Einsatz einer SOA.

Das erweiterte SOA-Dreieck trifft keine Aussagen darüber wie die Serviceimplementie-rung umgesetzt wird. Insbesondere beim Serviceanbieter wird sie wie eine Black-Boxbehandelt. Wenn ein Service jedoch wieder selbst zu einem Servicekonsument wird,entsteht ein Verbund von Services.

Konsequenz 2.1Eine Serviceimplementierung kann Services nutzen. Ein Szenario, indem ein Servicedurch das Zusammenschalten von Services entsteht, wird als Komposition bezeich-net [Yan03]. SOA begünstigt dadurch Flexibilität, indem auf Änderungen durch denEinsatz von alternativen Services reagiert werden kann [GP06]. Kompositionen wer-den häufig bei der Realisierung von Geschäftsprozessen eingesetzt [ACD+03].

Beispiel 2.3 zeigt ein Szenario aus [KBL06], um den Einsatz von Services und Kom-positionen zu motivieren.

Beispiel 2.3Ein Reisebüro bucht einen Ausflug für einen Kunden. Als Erstes sucht das ReisebüroFlüge bei verschiedenen Fluggesellschaften für das gewünschte Datum. Danach buchtdas Reisebüro den preisgünstigsten Flug. Ähnliche Aktivitäten führt das Reisebüro

10

2. Grundlagen

für eine Hotelreservierung durch und mietet ein Auto. Eigentlich muss das Reisebürodiesen Vorgang für 25 Kunden zur selben Zeit durchführen.

Die Aktivitäten des Reisebüros aus Beispiel 2.3 bilden den Geschäftsprozess des Un-ternehmens. Während der Geschäftsprozess abgearbeitet wird, ist das Reisebüro einServicekonsument und Fluggesellschaften, Hotels, . . . sind Serviceanbieter. Dabei willdas Reisebüro die einzelnen Aktivitäten im Geschäftsprozess automatisiert ausführen.

Zur Interaktion mit einem Service muss der Servicekonsument den Aufbau der Nach-richten kennen, die ein Service erwartet. Folglich muss der Servicekonsument auchdie Servicebeschreibung des Services kennen.

Konsequenz 2.2Auf der Seite des Servicekonsumenten kommt häufig, wenn auch nicht zwingend not-wendig, das „Proxy“-Entwurfsmuster [GHJV95] zum Einsatz [Sta06a]. Ein generierterProxy findet, bindet und benutzt dabei einen Service [MTSM03].

Der Einsatz eines Proxy auf Seiten des Servicekonsumenten vereinfacht die Kommu-nikation mit dem Service, wenn dieser Proxy automatisch generiert wird. Dazu ist unterAnwendung der Servicebeschreibung gezielt die Serviceschnittstelle auszuwerten.

Konsequenz 2.3In der objektorientierten Programmierung müssen Objekte erst instanziiert werden be-vor man mit ihnen interagieren kann. Hingegen interagiert der Servicekonsument miteinem bereits existierenden Service. [OAS06]

Durch die Unkenntnis der Serviceinstanz hat der Servicekonsument keine direkte Kon-trolle über einen Service, sondern kann nur mit ihm interagieren.

Konsequenz 2.4Erst durch die Bereitstellung in einem Container, kann mit einem Service interagiertwerden. D.h. der Vorgang der Bereitstellung macht aus einer Serviceimplementierungeinen Service.

Insbesondere verwaltet ein Container die Serviceinstanz.

Konsequenz 2.5Die SOA Infrastruktur ist zunächst zustandslos [Sta06a]. Folglich ist zwischen mehre-ren Interaktionen mit einem Service nicht garantiert, dass es sich um die selbe Ser-viceinstanz handelt. Auf Seiten des Serviceanbieters sind z.B. Wechsel der Servicein-stanz durch den Einsatz von Service-Pools denkbar [Sta06a].

Servicekonsumenten können an einen Service nahezu beliebige Nachrichten mit be-liebigem Inhalt senden. Entweder wird die Nachricht verworfen oder aber ausgewertetund erhaltene Daten an die Serviceimplementierung weitergereicht.

11

2. Grundlagen

Konsequenz 2.6SOA minimiert Annahmen an das Vertrauen [OAS06]. Daher benötigt ein Service einequalitativ hochwertige Implementierung und Dokumentation, um Wiederverwendbar-keit und Unabhängigkeit zu garantieren.

2.3. Plattformen für Unternehmensanwendungen

Eine SOA wird häufig unter Einsatz einer Plattform zur Realisierung von serverseitigenAnwendungen umgesetzt. Bei der Betrachtung mehrerer Plattform wird ein einheitli-cher Sprachschatz notwendig. Zur Herleitung sei zunächst die Java Enterprise Edition(Java EE) herangezogen und die Begriffe nach [JBC+07] mit neutraler Namensgebungkurz vorgestellt:

• Applikationen werden aus Enterprise Komponenten aufgebaut.

• Ein Container bildet die Schnittstelle zwischen einer Enterprise Komponenteund einer plattformspezifischen Implementierung zur Unterstützung der Enter-prise Komponente. D.h. erst durch einen Container wird eine Enterprise Kompo-nente nutzbar. Ein Web Container verwaltet die Enterprise Komponenten, dieöffentlich in einem Netz angeboten werden. Ein Applikationsserver ist die äu-ßere Verwaltungseinheit von mindestens einem Container.

• Der Vorgang zur Übertragung einer Enterprise Komponente in einen Containerheißt Bereitstellung.

Serverseitige Anwendungen sind mit der Java EE oder dem Microsoft .NET Framework(.NET ) realisierbar. Java EE und .NET heißen Enterprise Plattformen. Als Versionenseien in dieser Arbeit Java EE 5.0 und .NET 2.0 angenommen.

Im Folgenden sei eine Auswahl von verfügbaren Web Containern bzw. Applikations-servern angegeben:

• Java EE: Apache Tomcat (Web Container), JBOSS (Applikationsserver).

• .NET: ASP.NET Development Server (Web Container), Internet Information Ser-vices (Applikationsserver)

2.4. Webservices


Webservices sind eine Möglichkeit eine SOA zu realisieren. Sie sind so entworfen,dass eine plattformunabhängige Kommunikation zwischen Maschinen möglich wird[W3C04]. Deshalb stützen sich Webservices auf die Extensible Markup Language(XML) [W3C], einem Standard zur textbasierten Repräsentation von Daten.

Eine Serviceschnittstelle wird definiert mit der Web Service Description Language

12

2. Grundlagen

(WSDL) [W3C07]. Die Kommunikation erfolgt über Nachrichten, die mit dem SimpleObject Access Protocol kodiert sind (SOAP). Das verwendete Protokoll zur Übertra-gung dieser Nachrichten wird in der Serviceschnittstelle festgelegt. Sowohl die WSDL,als auch SOAP basieren auf XML und sind somit auf mehreren Plattformen einsetz-bar. Das Protokoll zum Auffinden von Webservices ist für den Verlauf dieser Arbeitunerheblich und wird daher nicht angeführt.

Dienste bietet ein Webservice über Operationen an, die ein Servicekonsument nutzt.In der Serviceschnittstelle sind dazu die Eingabeparameter und der Rückgabewertjeder Operation definiert.

Heutzutage werden Webservices oftmals mit Enterprise Plattformen durch Erstellungeiner Enterprise Komponente implementiert. Dabei verbirgt die eingesetzte Entwick-lungsumgebung und Enterprise Plattform die Komplexität bei der Erstellung einesWebservices. In Java EE und analog in .NET erstellt der Entwickler einen Webservicemit Klassen, die durch zusätzliche Metainformationen so annotiert werden [JBC+07],dass ein Web Container automatisch die Serviceschnittstelle generiert. Zur Kommu-nikation und Interaktion wird ein Proxy eingesetzt, der den Austausch von SOAP-Nachrichten versteckt [MTSM03]. Abbildung 2.2 zeigt eine typische Architektur vonEnterprise Komponenten, die einen Webservice implementieren.

Servicevertrag

Serviceadapter

Dienstschnittstellenschicht

Geschäftsschicht

GeschäftsworkflowGeschäftslogik Geschäftselemente

Ressourcenzugriffsschicht

Datenzugriffslogik Dienstagenten

Datenquellen

Services

Sicherheit

Betriebsmanagement

Kommunikation

Konsument

Service

Abbildung 2.2.: Webservice Referenzarchitektur [Sko06]

13

2. Grundlagen

Webservices stellen die Konkretisierung einer SOA dar, so dass neue Konsequenzenentstehen.

Konsequenz 2.7Viele Unternehmen setzen Webservices ohne Serviceregister ein [MTSM03], d.h. dieVollständigkeit bei der Implementierung einer SOA variiert.

Ein Serviceregister erlaubt z.B. den Serviceanbieter zu wechseln, ohne dass ein Ser-vicekonsument Änderungen in seiner Applikation vornehmen muss. Dennoch erhaltenKunden oft direkt die Endpunkte von Webservices.

Konsequenz 2.8Webservices werden in verteilten Anwendungen eingesetzt, d.h. die Interaktion miteinem Webservice ist entfernt.

Jeder Webservice repräsentiert mehrere entfernte Prozeduren. Dabei erfolgt nach De-finition 2.5 die Interaktion mit einem Webservice über Nachrichten.

2.4.2. Webservice Standards

Neben Standards, die grundlegende Eigenschaften für Webservices festlegen, erfor-dern bestimmte Anforderungen an die Kommunikation Erweiterungen des SOAP undder WSDL. Webservice Standards zur interoperablen Realisierung von z.B. Sicher-heit oder Transaktionen adressieren dieses Problem. Für den Verlauf dieser Arbeit istnur die Kenntnis von Webservice Standards relevant, spezielle Eigenschaften sind zuvernachlässigen.

2.5. Zusammenfassung

In diesem Kapitel wurden alle notwendige Grundlagen und Begriffe vorgestellt, die fürden weiteren Verlauf dieser Arbeit von Bedeutung sind:

• Eine Teststrategie als Zuordnung von Testaspekten zu Teststufen.

• Serviceorientierte Architekturen als ein Stil Anwendungen zu strukturieren.

• Die häufige Umsetzung einer SOA mit Enterprise Plattformen.

• Webservices als dominierende Realisierung einer SOA.

In den folgenden Kapiteln sind die vorgestellten Begriffe aus dem Bereich des Testensund SOA zu vereinen, um eine Teststrategie für eine SOA zu definieren. Im Allgemei-nen präsentieren die folgenden Kapitel alle Konzepte, Ergebnisse und Werkzeuge, dieim Rahmen dieser Arbeit entstanden sind.

14

3. Ableitung einer Teststrategie fürserviceorientierte Architekturen

Bevor man eine Teststrategie für eine SOA formulieren kann, sind alle Einflüsse gezieltzu identifizieren. Besonders die möglichen Variationen zur Realisierung einer SOAerfordern zunächst ein allgemeines Vorgehen zur Findung der Teststrategie. Abschnitt3.1 beschreibt das genaue Umfeld, das durch eine gefundene Teststrategie abgedecktwird und welche Besonderheiten zu ignorieren sind.

Services bilden als aktive Einheiten den Kern einer SOA, indem sie Funktionalitätenzur Verfügung stellen. Die Betrachtung von Teststufen in einer Teststrategie erfordertneue Sichtweisen aufgrund der in Kapitel 2 vorgestellten Natur von Services.

Alle Überlegungen berücksichtigen die folgenden vier Anforderungen an eine Teststra-tegie [KBP02]:

• Produktspezifisch: Eine produkt- und technologiespezifische Teststrategie istbesser als eine allgemeine Teststrategie.

• Risikospezifisch: Die Teststrategie adressiert die wichtigsten Probleme.

• Vielfältig: Eine vielfältige Teststrategie setzt auf mehrere Testmethoden, umFehler zu finden, die eine andere Testmethode übersehen hat.

• Praktikabel: Die Teststrategie ist einsetzbar und schlägt nichts vor, dass jenseitsder Ressourcen eines Projekts liegt oder technisch nicht umsetzbar ist.

3.1. Einordnung der Teststrategie

Kapitel 2 hat das Testumfeld einer SOA aufgezeigt. Durch die vielfältigen Einheitenin einer SOA entstehen Fehlerquellen, die es gezielt zu identifizieren gilt. Die beidenHauptmerkmale einer SOA sind das SOA-Dreieck und als Konsequenz der Verbundvon Services zu Kompositionen.

Das erweiterte SOA-Dreieck aus Abbildung 2.1 hat vier Rollen aufgezeigt, von denenjede Einfluss auf die Teststrategie nehmen kann. Die einzelnen Aktivitäten und Inter-essen beim Testen stellen sich für jede Rolle wie folgt dar:

• Servicekonsument: Ein Servicekonsument prüft, ob das Finden eines Servicesund die Interaktion mit ihm korrekt arbeiten.

• Serviceanbieter: Ein Serviceanbieter testet, ob die angebotene Infrastruktur denAnforderungen zur Bereitstellung des Services genügt.

15

3. Ableitung einer Teststrategie für serviceorientierte Architekturen

• Serviceentwickler: Ein Serviceentwickler testet, ob der Service den funktionalenAnforderungen genügt, qualitativ hochwertig ist und Fehler durch eingesetzteTechnologien vermieden werden.

Das Serviceregister wird in dieser Arbeit nicht betrachtet, weil

• es oftmals von Drittanbietern verwaltet wird. Ein Unternehmen, das Funktiona-litäten über einen Service anbietet, wird diesen Service solch einem Registerhinzufügen.

• Unternehmen setzen nach Konsequenz 2.7 oftmals kein Serviceregister ein undstellen ihren Kunden direkt den Endpunkt eines Services zur Verfügung.

In dieser Arbeit betrachtete Teststrategien beschränken sich auf die Sicht des Service-entwicklers und Serviceanbieters, so dass als Testobjekte ein Service selbst und dieServiceimplementierung betrachtet werden. Letztendlich wird ein Unternehmen, dasseine Leistungen über Services anbietet, genau diese zwei Sichten einnehmen.

Die Teststrategie verfolgt die folgenden Ziele:

• Eine qualitativ hochwertige Implementierung des Services sicherstellen. Es istnicht bekannt in welchem Umfeld und von wem eine Serviceimplementierunggenutzt wird. Insbesondere zielen Services auf Wiederverwendbarkeit und soll-ten daher möglichst wartungsarm sein.

• Finden von Fehlern, die sich speziell durch SOA und Webservices ergeben.

Das Testen von Kompositionen hat in der Forschung und Entwicklung viel Aufmerk-samkeit erhalten. Hauptaugenmerk dieser Arbeit liegt nicht auf dem Testen von Kom-positionen. In Kapitel 8 werden Arbeiten und Werkzeuge angeführt, die sich aus-schließlich mit dieser Thematik befassen. Zusätzlich wird der Einfluss auf die Test-strategie aufgezeigt und kurz angedeutet, wie diese entsprechend zu erweitern ist.

3.2. Einflüsse auf die Teststrategie

3.2.1. Idee, Plattform und Technologie

Diese Arbeit schlägt drei Ebenen vor, die in einer SOA eigene Testaspekte beitragen:

1. Idee: Als festlegender Stil beginnen Auswirkungen auf die Teststrategie direktbei der Idee von SOA. Neben den verschiedenen Rollen, prägen auch die Kon-sequenzen einer SOA die Idee.

2. Technologie: Webservices sind die bekannteste Technologie, um eine SOA zurealisieren. Im Allgemeinen führen die technischen Besonderheiten und Konse-quenzen einer Technologie zu unterschiedlichen Problemen.

3. Plattform: Die Realisierung eines Effekts setzt eine Serviceimplementierungvoraus. In Abschnitt 2.3 wurden bekannte Plattformen eingeführt, mit denen eineServiceimplementierung realisiert werden kann. Jede Plattform hat seine eige-

16


nen Besonderheiten, die zu neuen Problemen führen.

Abbildung 3.1 illustriert die drei Ebenen als ein Baukasten. Die konkrete Festlegung ei-ner einzelnen Ebene durch ein Produkt, das diese Ebene umsetzt, heißt Ausprägungeiner Ebene. Werden für eine SOA alle drei Ebenen durch eine Ausprägung festge-legt, so heißt dieser Baukasten Ausprägung einer SOA. Auch wenn für die Techno-logie mehrere Möglichkeiten denkbar sind, dominieren Webservices diese Ebene. DieIdee einer SOA kann durch verschiedene Definitionen variieren, im weiteren Verlaufdieser Arbeit sei jedoch die in Definition 2.7 definierte Idee angenommen und dieseIdee als SOA bezeichnet. Die Abgrenzung zwischen den Ebenen ist bewusst verzahntdargestellt, weil eine klare Abgrenzung oftmals nicht möglich ist.

Serviceorientierte Architektur

Idee

Technologie

Plattform

Java EE

.NET

BPEL

Webservice

Abbildung 3.1.: Drei Ebenen von SOA

Die drei Ebenen nehmen auf die Anforderungen an eine Teststrategie Einfluss undbilden Grundvoraussetzungen:

• Produktspezifisch: Eine in der Praxis umgesetzte SOA wird in allen drei Ebe-nen Ausprägungen vorweisen. Umso mehr Ebenen berücksichtigt werden, umso produktspezifischer ist eine Teststrategie.

• Risikospezifisch: Jede Ebene hat eigene Testaspekte, also eigene potentielleProbleme, die auftreten können. Die Teststrategie muss eine Auswahl berück-sichtigen, um wichtige Probleme schnell zu identifizieren.

• Vielfältig: In jeder Ebene sind mehrere Testmethoden einzusetzen, um Fehler zufinden.

• Praktikabel: Eine Teststrategie wird erst anwendbar, wenn sie eine Idee, Techno-logie und Plattform aufweist. Kapitel 8 wird Ansätze aufzeigen, die eine eigenePlattform schaffen und daher nur von der Technologie abhängig sind.

17


3.2.2. Projektumfeld

Das Projektumfeld in dem ein Service entwickelt wird, beeinflusst die Teststrategiemaßgeblich. Im Speziellen handelt es sich um die folgenden Faktoren:

• Personal: Wer steht für Tests zur Verfügung? Setzen sich Teams nur aus Entwick-lern zusammen oder gibt es eine Testabteilung, deren Aufgabe nur im Finden vonFehlern liegt? Auch Experten in bestimmten Fachbereichen, z.B. Performanceoder Sicherheit, sind bei einer Teststrategie schon zu berücksichtigen.

• Werkzeuge: Welche Werkzeuge stehen zur Testdurchführung, -auswertung und-verwaltung zur Verfügung. Sind neue Werkzeuge notwendig?

• Kapazitäten: Wie sieht die zeitliche Verteilung und Belastung des Teams aus?Kapazitäten schränken den Umfang des Testens ein.

• Vorgehensweise: Entstehen während der Entwicklung Dokumente, die bei derAbleitung von Testfällen von Interesse sind? Welchem Prozess folgt die Soft-ware in ihrem Lebenszyklus. Viele Vorgehensweisen sehen Tests vor, aber mitunterschiedlichen Ausprägungen und Motivationen.

Wird das Projektumfeld bei der Formulierung einer Teststrategie vernachlässigt, läuftman Gefahr, dass die Teststrategie nicht praktikabel ist.

3.3. Teststrategie

3.3.1. Serviceumgebung

Zur Reduktion von Kopplungen stützt sich SOA auf verteilte Systeme [Sta06a], wobeider Ort eines Services durch den Serviceanbieter festgelegt wird. Jeder Test mussdiesen Ort kennen, um praktisch umsetzbar zu sein. Denn ein Test übernimmt dieSicht eines Servicekonsumenten und interagiert nach Konsequenz 2.3 immer mit einerbereits existierenden Instanz eines Services.

Beispiel 3.1Sei als Technologie Webservices angenommen und als Plattform Java EE, so wird einWebservice als Klasse implementiert und mit Metadaten annotiert. Ein Web Container,z.B. der Apache Tomcat mit der Apache AXIS Erweiterung, erstellt für diese Klasseeine Serviceschnittstelle und ermöglicht die Interaktion mit dem Webservice.

Ein Service existiert immer in einer Serviceumgebung. In dieser Arbeit werden insge-samt vier Serviceumgebungen definiert. Dazu sei zunächst eine Umgebung betrach-tet, die unabhängig von SOA ist und durch die Plattform festgelegt wird:

• lokal: Ein Service liegt nur in seiner Serviceimplementierung vor und kann nachKonsequenz 2.4 noch nicht als Service genutzt werden. Ist der Service mit einerEnterprise Plattform implementiert, so liegt er in der Regel als Klasse vor.

18


Die Bereitstellung in einer Umgebung erzeugt einen Service. Es existieren drei ver-schiedene Varianten:

• lokal/entfernt: Ein Container wird lokal auf der Entwicklermaschine gestartetund der Service wird für einen Test in dieser bereitgestellt. Ziel dieser Umgebungist entwicklungsnah einen Service zu testen.

• entfernt/test: Ein Container liegt auf einem Server entfernt in einem Netzwerkund wird dort für einen Test bereitgestellt. Diese Serviceumgebung sollte derspäteren Produktivumgebung schon nahezu vollständig entsprechen. Es wirdversucht die Infrastruktur des Serviceanbieters zu Testzwecken nachzubildenoder falls möglich direkt zu nutzen.

• entfernt/live: Ein Service wird über die letztendliche Produktivumgebung bereit-gestellt. Diese Serviceumgebung eignet sich im Allgemeinen nur bedingt zumTesten.

Auch wenn die Serviceumgebung eine Voraussetzung zum Testen eines Services ist,so nimmt sie auch direkten Bezug zur Teststufe:

• Komponententests: Komponententests sind Tests, die sehr nahe am Code agie-ren und während oder kurz nach der Entwicklung durchgeführt werden. Sie sinddaher vorrangig in einer lokalen oder lokal/entfernen Serviceumgebung durchzu-führen, weil sie immer Änderungen an Komponenten erfordern. In einer entfern-ten Serviceumgebung fehlt die notwendige Kontrolle über einen Service, um denAustausch mit einer Komponente zu realisieren. Komponententests für Serviceswerden im Abschnitt 3.4 detailliert betrachtet.

• Integrationstests: Ähnlich wie Komponententests erfordern auch Integrations-tests Kontrolle über einen Service, so dass sie ebenfalls vorrangig in einer loka-len oder lokal/entfernten Serviceumgebung durchzuführen sind.

• Systemtests: Die Betrachtung eines Services mit Systemsicht erfordert keineKontrolle über den Service. Die entfernt/test Serviceumgebung ist daher für dieseArt des Testens vorgesehen. Insbesondere erlaubt sie auf Seite des Servicean-bieters zu testen.

3.3.2. Vorgehensweise

Eine Teststrategie kann in mehreren Projekten angewandt werden. Allerdings ist fürjedes Projekt zu prüfen, ob sich die Einflüsse auf die Teststrategie verändert haben.Diese Arbeit schlägt zur Findung einer Teststrategie die folgenden Schritte vor:

1. Bestimmung der Ausprägung einer SOA: Die Umsetzung einer SOA wird indi-viduelle Ausprägungen in allen Ebenen aufweisen. Die Durchführung von Testsverlangt dieses Umfeld genau zu kennen.

2. Identifikation von Testaspekten für jede Ausprägung einer Ebene: Die Kennt-nis von Testaspekten erlaubt in der Teststrategie schon den Testraum einzu-schränken und liefert Anhaltspunkte über die Fehler, die es zu finden gilt. Somit

19


sind für jede Ausprägung einer Ebene Testaspekte zu ermitteln und zunächstformlos niederzuschreiben.

3. Analyse des Projektumfelds: Jeder Testaspekt lässt sich erst adressieren, wenndie Rahmenbedingungen eines Projekts bekannt sind.

4. Zuordnung aller Testaspekte zur Serviceumgebung: Wie in Abschnitt 3.3.1beschrieben, legt die Testumgebung indirekt die Teststufe und das Testobjektfest. D.h. die Zuordnung eines Testaspekts zur Testumgebung definiert automa-tisch in welchen Teststufen zu testen ist. Insbesondere gibt die Beziehung zwi-schen einem Testaspekt und der Testumgebung schon Hinweise auf die Reali-sierung des Tests.

5. Formulierung von Testszenarien: Abschnitt 3.3.3 wird Testszenarien vorstel-len, die es für eine Teststrategie zu formulieren gilt.

Der Nutzen der beschriebenen Vorgehensweise liegt im Erkennen von potentiellenProblemen und der Zuordnung zu einem Testobjekt. Speziell fließt durch die konkreteZuordnung das Projektumfeld mit ein. Als Notation für die Zuordnung von Testaspektenzu Serviceumgebungen wird in dieser Arbeit eine Tabelle eingesetzt. Dazu zeigt Ta-belle 3.1 ein einfaches Beispiel. Die Serviceumgebungen entfernt/test und entfernt/livesind durch eine doppelte Linie abgetrennt, weil sie nur Systemtests erlauben.

Nr. lokal lokal/entfernt entfernt/test entfernt/live

1 Testaspekt 1 X X

2 Testaspekt 2 X

Tabelle 3.1.: Beispiel für eine Testmatrix

Die tabellarische Darstellung erlaubt die Testaspekte in einer Reihenfolge anzuord-nen, die bekannten und etablierten Praktiken entspricht. Sind die Tests während derEntwicklung durchzuführen, so sollte die vorgeschlagene Reihenfolge die Reife desProdukts berücksichtigen [KBP02]: mitfühlend, aggressiv, abwechslungsreich und zu-letzt sorgfältig. Speziell lässt sich durch die Reihenfolge z.B. die Aggressivität steuern,indem man mit Buildverifikationstests [GP06] beginnt und zunehmend Negativtestseinbaut. Der Übergang zwischen den einzelnen Testaspekten lässt sich bei Bedarf umBedingungen oder Eingangs- und Ausgangskriterien erweitern.

Im Allgemeinen ist eine Tabelle, mit dem in Tabelle 3.1 dargestellten Aufbau, ein wich-tiges Produkt der ermittelten Teststrategie. Sie heißt Testmatrix und gibt einen Über-blick über das Vorgehen beim Testen. Die Nummer in der ersten Spalte dient zur Iden-tifizierung eines Testaspekts.

Die beschriebene Vorgehensweise führt zu einer Teststrategie, die aus drei Artefaktenbesteht - in ihrer Entstehungsreihenfolge:

1. Eine Sammlung von Testaspekten

2. Eine Testmatrix

20


3. Eine Sammlung von Testszenarien

Alle drei Artefakte erlauben gezielt und systematisch einen Service zu testen.

3.3.3. Testszenario

Zur Konkretisierung der Teststrategie ist im Rahmen dieser Arbeit die in Tabelle 3.2illustrierte Vorlage entstanden. Sie beschreibt das Vorgehen zur Prüfung eines Testa-spekts und sei als Testszenario bezeichnet.

Nr. / Testaspekt Die Nummer dieses Testszenarios und der Name des Testa-spekts. Die Nummer ist so zu wählen, dass sie mit der Num-mer des zugehörigen Testaspekts in der Testmatrix überein-stimmt. Existieren mehrere Testszenarien für einen Testa-spekt, so ist die Nummer um Buchstaben zu erweitern, z.B.1a, 1b, usw.

Tester Die aktiven Tester, die den beschriebenen Testaspekt testen.

Serviceumgebung Die Umgebung, in der ein zu testender Service bereitgestelltwird.

Abdeckung Die potentiellen Probleme, die dieses Testszenario findet.Gegeben durch eine Beschreibung des Testaspekts.

Risiken Wird ein Testaspekt nicht getestet, können bestimmte Fehlerzu Konsequenzen führen, die ein Risiko darstellen.

Vorbedingungen Bedingungen, die vor der Durchführung dieses Testszenari-os gegeben sein müssen.

Durchführung Wie ist dieser Test durchzuführen? Manuell oder automati-siert?

Mocks Gibt die in einem Service durch Mocks zu ersetzenden Teilean, falls es sich um einen Komponententest handelt.

Aktivitäten Eine Liste von durchzuführenden Aktivitäten.

Erfolgsbedingungen Eine Liste von Bedingungen, von denen mindestens eine er-füllt sein muss, damit dieses Testszenario als bestanden gilt.

Fehlschlagbedingungen Eine Liste von Bedingungen, von denen mindestens eine er-füllt sein muss, damit dieses Testszenario fehlgeschlagen ist.Jeder Fehlschlag deckt einen Fehler auf.

Tabelle 3.2.: Testszenario Vorlage

Der Aufbau eines Testszenarios bezieht die fünf Dimensionen eines Tests nach Ab-schnitt 2.1.1 ein. Zur Definition des Testobjekts werden die Serviceumgebung und evtl.

21


einzusetzende Mocks angeführt. Vorbedingungen stellen notwendige Voraussetzun-gen an die Durchführung eines Testszenarios.

Die Automatisierung von Tests ist sinnvoll, doch nicht Grenzenlos [Bac99]. Es lohntsich nicht jeden Testaspekt automatisiert abzudecken. Ein Testszenario definiert da-her, ob ein Test manuell oder automatisiert durchzuführen ist.

Ein Testszenario stellt die handliche Beschreibung eines Testaspekts dar. Sie solltedie Länge von einer DIN A4 Seite nicht überschreiten. So erhält der aktive Testerdie Möglichkeit ein Szenario z.B. neben seinen Monitor zu heften und seine aktuellenAktivitäten und Ziele immer im Blick zu haben.

Testszenarien sind noch keine Testfälle, sondern beschreiben nur wie diese abzuleitensind. Im Bezug auf die Testmatrix ist für jede Zeile und damit für jeden Testaspekt min-destens ein Testszenario anzugeben. Insgesamt bilden Testszenarien einen wichtigenBestandteil der Teststrategie.

3.4. Komponententests für eine SOA

3.4.1. Vorgehen

Eine SOA erzwingt neue Sichtweisen beim Einsatz von Komponententests. Grund-sätzlich ist jeder Komponententest an mehrere Schritte gebunden, die systematischdurchzuführen sind. Ist es nicht möglich einen dieser Schritte abzuarbeiten, so lässtsich oftmals kein Komponententest erstellen.

1. Identifikation der eigentlichen Komponente. Dabei wird eine externe Sichtweiseauf ein System eingenommen und aktive Einheiten identifiziert, d.h. Komponen-ten sind immer Teile eines Systems.

2. Identifikation aller Komponenten mit denen die Komponente in Beziehung steht.Notwendig ist die Verfügbarkeit der Implementierung in Form des Quellcodesoder andere Informationsquellen, die es erlauben teilnehmende Komponentenabzuleiten.

3. Erstellen von Mocks für alle teilnehmenden Komponenten. Dieser Schritt erfor-dert einen Entwurf, der die Erstellung von Mocks ermöglicht.

4. Austauschen aller teilnehmenden Komponenten durch die erstellten Mocks. Indiesem Vorgang wird eine Komponente manipuliert, so dass zusätzliche Grund-voraussetzungen an die Testbarkeit entstehen. Lässt sich die Beziehung zu einerKomponente nicht ändern, wird ein Komponententest unmöglich.

Beispiel 3.2In der objektorientierten Programmierung sind die Klassen die Komponenten. Bezie-hungen werden durch den Einsatz und die Interaktion mit Instanzenvariablen herge-stellt. Mocks lassen sich durch Vererbung oder Implementierung von Schnittstellenschreiben. Der Austausch erfordert den Zugriff auf die Instanzenvariablen der Klasse.

22


3.4.2. Identifikation der Komponente bei Services

Abbildung 3.2 illustriert, dass ein Service zwei unterschiedliche Realisierungen habenkann:

• Ein Service wurde mit einer Enterprise Plattform und damit in einer objektorien-tierten Programmiersprachen realisiert.

• Ein Service repräsentiert eine Komposition nach Konsequenz 2.1.

Ein Servicekonsument sieht bei der Interaktion keinen Unterschied in der Realisierung.

Class1

«interface»Interface1

Class2

Abbildung 3.2.: Realisierungen eines Services

Beispiel 3.2 hat bereits dargelegt, dass in der objektorientierten Programmierung Klas-sen die Komponenten sind. Die Identifikation der Komponente in einem Service erfor-dert die Realisierung des Service zu kennen, denn die Form der Realisierung und dieBetrachtungsweise vererben die Komponente:

• Ist ein Service in einer objektorientierten Programmiersprache implementiert, sosind die Komponenten Klassen.

• Ist ein Service als Komposition realisiert, so bilden Services die Komponenten.

Zusätzlich sind auch Mischformen denkbar, indem unter Einsatz einer objektorientier-ten Programmiersprache Kompositionen erstellt werden.

3.4.3. Austauschen von Komponenten in Services

Nach der Identifikation der Komponente, sind für alle teilnehmenden Komponenten inAbhängigkeit von der Realisierung Mocks zu schreiben. Sind Teile einer Kompositiondurch Mocks auszutauschen, so müssen die Serviceimplementierungen von ange-sprochenen Services geändert werden - die Serviceschnittstellen bleiben dabei erhal-ten. Kapitel 8 wird Werkzeuge vorstellen, die bei der Erstellung von Mocks für Kom-positionen unterstützen. Der Austausch des Mocks erfolgt dabei mittels Änderung des

23


zugehörigen Endpunkts im Serviceregister.

Betrachtet man nur einen Service an sich und keine Kompositionen, so werden Kom-ponenten durch die Plattform vererbt. Bei der Implementierung eines Services in JavaEE oder mit dem Microsoft .NET Framework, sind Mocks als Klassen zu implementie-ren. Dabei hat die Serviceumgebung, in der ein zu testender Service existiert, Einflussauf den Einsatz von Mocks:

• lokal: Zur Laufzeit werden teilnehmende Komponenten durch Mocks ersetzt. Dieverwendeten Verfahren sind seit Jahren bekannt und werden insbesondere inder testgetriebenen Entwicklung [Bec03] eingesetzt.

• lokal/entfernt: Sobald ein Service in einer entfernten Serviceumgebung verwaltetwird, interagiert ein Servicekonsument nach Konsequenz 2.3 mit einer Instanz,auf die er keinen Einfluss nehmen kann. Es ist daher nicht möglich wie in derlokalen Serviceumgebung eine Komponente zur Laufzeit auszutauschen.

Diese Arbeit schlägt neue Ansätze zum Einsatz von Mocks in einem Service vor. Durchden Vorgang der Bereitstellung hat ein Tester keinen Zugriff mehr auf die Instanz desServices, so dass jede Änderung am Service vor der Bereitstellung erfolgen muss.Insbesondere nach Konsequenz 2.2 wird auch ein Tester evtl. nur über einen Proxymit dem Service kommunizieren.

Diese Arbeit verfolgt zwei verschiedene Ansätze zur Realisierung von Mocks. Dazu seiangenommen, dass eine Klasse in einer Datei definiert wird und zur Laufzeit als einObjekt instanziiert wird.

• Weicher Mock: Bei nach bekannten Methoden umgesetzten Komponententestswird zur Laufzeit ein Objekt ausgetauscht. Die Realisierung eines Mocks erfolgtin einer Klasse durch Implementierung einer Schnittstelle oder mittels Vererbung.Der Austausch einer Komponente geschieht durch das Setzen des Mocks ineiner Instanzenvariable. Abbildung 3.3 zeigt dazu ein Beispiel.

In einer lokal/entfernten Umgebung fehlt der Zugriff auf die Instanz eines Ser-vice, so dass das in Abbildung 3.3 aufgezeigte Vorgehen nicht anwendbar ist.Als Lösung ist der Service vor seiner Bereitstellung, um entsprechende Logikzum Austauschen durch Mocks zu erweitern. Hierzu ist auch die Interaktion sozu ändern, dass vor jedem Benutzen des Services ein Austausch durch Mocksvorgenommen wird. D.h. die Zeilen 9 und 10 aus Abbildung 3.3 sind Teil desServices.

Im Allgemeinen sei dieser Vorgang als weich bezeichnet, weil keine tatsächlicheDefinition einer Klasse geändert wird. Der Austausch durch Mocks erfolgt erstzur Laufzeit und betrifft nur ein Objekt.

24


1 public class Serv iceTest {2 private class SubSystemMock {3 public void Invoke ( ) {4 . . .5 }6 }78 public void Test ( ) {9 Serv ice underTest = new Serv ice ( ) ;

10 underTest . SubSystem = new SubSystemMock ( ) ;1112 . . .13 }14 }

Abbildung 3.3.: Umsetzung eines weichen Mocks

• Harter Mock: Immer wenn ein Programmierer kurzzeitig einen Teil im Quellcodeauskommentiert, um einen bestimmten Aspekt der Software zu prüfen, fügt derProgrammierer im weitesten Sinne einen Mock ein. Ändert man die Definitioneiner teilnehmenden Komponente direkt in der zugehörigen Datei, so sind zurLaufzeit keine weiteren Maßnahmen mehr durchzuführen. Man arbeitet so langemit einem Mock bis alle Änderungen wieder rückgängig gemacht wurden. DieserVorgang einen Mock einzuführen sei als hart bezeichnet, weil eine tatsächlicheÄnderung vorgenommen wird.

Durch den Vorgang der Bereitstellung ist es möglich während eines Testlaufseinen harten Mock in einem Service einzusetzen. In der objektorientierten Pro-grammierung und bekannten Komponententests ist dies nicht während des Test-laufs möglich, weil alle Informationen zur Kompilierzeit bekannt sein müssen.

Abbildung 3.4 zeigt ein Beispiel, das die Logik einer teilnehmenden Komponentedirekt ändert.

1 public class Component {2 public s t r i n g Do ( ) {3 s t r i n g r e s u l t = " " ;45 . . .67 return r e s u l t ;8 }9 }

1 public class Component {2 public s t r i n g Do ( ) {34567 return "mock" ;8 }9 }

Abbildung 3.4.: Einsatz eines harten Mocks

Auf die Realisierung von harten und weichen Mocks wird erst in den Abschnitten 5.5und 5.6 eingegangen.

25



Eine anfängliche Einordnung der Teststrategie hat ihren Fokus gezielt eingeschränkt:

• Die Teststrategie betrachtet nur Services aus der Sicht des Serviceanbieters undServiceentwicklers, d.h. das Serviceregister sei vernachlässigt.

• Kompositionen sind kein primärer Bestandteil der Teststrategie und werden erstin Kapitel 8 behandelt.

Auf die Teststrategie einer SOA nehmen drei Ebenen und das Projektumfeld Einfluss.Abschnitt 3.3.2 präsentiert ein Vorgehen zur Findung einer konkreten Teststrategie, dieaus einer Beschreibung von Testaspekten, einer Testmatrix, sowie Testszenarienbesteht.

Zuletzt sind die Probleme und Lösungsansätze beim Einsatz von Komponententestsin Abschnitt 3.4 vorgestellt. Weiche oder harte Mocks ermöglichen die Komponentenin einem Service gezielt auszutauschen.

Zur Findung einer konkreten Teststrategie für SOA werden im folgenden Kapitel dieersten zwei Schritte der Vorgehensweise aus Abschnitt 3.3.2 durchlaufen.

26

4. Testaspekte für SOA, Webservices und.NET

Services werden mit einer ganz bestimmten Ausprägung einer SOA realisiert. Webser-vices bilden dabei die am weitesten verbreitete Technologie und als Plattform findetman häufig Enterprise Plattformen vor. Bevor die Formulierung einer Teststrategiemöglich ist, sind für jede Ebene nach Kapitel 3 Testaspekte abzuleiten. Daher wirdin diesem Kapitel die in Abbildung 4.1 dargestellte Ausprägung betrachtet.

Abbildung 4.1.: Betrachtete Ausprägung einer SOA

Jede Ebene wird eigene Testaspekte zur Teststrategie beitragen. Webservices als do-minierende Technologie einer SOA erlauben die Wiederverwendung der Testaspektein vielen anderen Projekten. .NET ist sehr verwandt mit Java EE, so dass abgeleiteteTestaspekte beide Plattformen betreffen.

Durch die gewählte Ausprägung entsteht das in Abbildung 4.2 dargestellte Umfeld, indem es zu Testen gilt. Speziell auf Seiten des Servicekonsumenten wird ein Proxynach Konsequenz 2.2 eingesetzt. Der Serviceanbieter stellt einen Web Container zurVerfügung, der die Serviceimplementierung verwaltet.

In einer Microsoft .NET-Umgebung existieren zwei bekannte Web Container:

• ASP.NET Development Server: Wird nur während der Entwicklung eingesetztund erlaubt Webapplikationen zu testen.

• Internet Information Services (IIS): Ein Applikationsserver, der für Produktivsys-teme genutzt wird.

27

4. Testaspekte für SOA, Webservices und .NET

WSDL

Service-implementierung

Web Container

Serviceanbieter

Implementierung Service-proxy

Servicekonsument

Benutzen(SOAP)

Serviceentwicklerimplementiert(Java, .NET, ...)

Abbildung 4.2.: Webservice Umfeld

4.1. Identifikation von Testaspekten

In den folgenden Abschnitten werden zunächst Testaspekte für die Idee, Technologieund Plattform identifiziert. Dazu wird jeder Testaspekt über seine potentiellen Proble-me definiert. Im Rahmen dieser Arbeit wurde für jeden Testaspekt eine Vorgehenswei-se zum Auffinden von Fehlern entwickelt. Die Beschreibung der Vorgehensweise stütztsich falls möglich auf Testmethoden aus Abschnitt 2.1.2. Existieren keine bekanntenTestmethoden wird das allgemeine Vorgehen zum Auffinden von Fehlern beschrieben.

Aufgrund der Verflechtung der einzelnen Ebenen einer SOA, ist es nicht immer möglichTestaspekte unabhängig und isoliert anzugeben. Allgemein sind die dargelegten Tes-taspekte nur als Auswahl anzusehen. Einige potentiellen Probleme, die Testaspekterepräsentieren, sind bereits durch angeführte Literatur bekannt, andere ergeben sichaus Konsequenzen oder dem Umfeld einer SOA.

4.1.1. SOA als Idee

Testaspekte für eine serviceorientierte Architektur leiten sich aus dem SOA-Dreieck,genauer den Beziehungen zwischen den verschiedenen Rollen ab. Insbesondere dieInteraktion mit einem Service, also die Beziehung zwischen Servicekonsument undServiceanbieter, ist dabei von Interesse. Es ergeben sich die folgenden Testaspekte:

• Annahmen an Eingabedaten: Nach Konsequenz 2.6 minimiert ein Service dieAnnahmen an das Vertrauen, so dass alle Eingabedaten in einem Service zuprüfen sind. Insbesondere ist nie bekannt in welchem Umfeld oder auf welcherTiefe in einer Komposition ein Service eingesetzt wird. Dabei können sowohlder Servicekonsument, als auch andere Services, im Allgemeinen immer wennNachrichten ausgetauscht werden, ungültige Daten liefern.

Jedes Datenelement hat eine Semantik, die entweder implizit angenommen oderexplizit angegeben wird. In jedem Fall sind alle Daten, die in einen Service flie-ßen, zu überprüfen. Speziell jede Applikation mit Bedienoberfläche wird auch ei-

28


ne Datenprüfung vornehmen, meistens schon während der Eingabe. Durch z.B.den Wegfall von Benutzeroberflächen bei Webservices muss jeder übergebeneParameter explizit durch den Service validiert werden. Fehlt eine Prüfung derEingabedaten kann nicht vorhersehbares Verhalten auftreten.

Um die potentiellen Probleme dieses Testaspekts zu finden ist zunächst eineAnalyse unter Anwendung der Testmethode Equivalence partitioning durchzu-führen:

1. Für alle möglichen Daten, die an einen Service gestellt werden, sind Äqui-valenzklassen bezüglich gültigen und ungültigen Werten zu bestimmen. ImSpeziellen sind dies Analysen für alle Eingabedaten eines Servicekonsu-menten und alle Ausgabedaten eines genutzten Service. Quellen zur Fest-legung dieser Äquivalenzklassen können Spezifikationen, White-Box Ana-lysen oder Gespräche mit Entwicklern sein.

2. Aus den ermittelten Äquivalenzklassen lassen sich Repräsentanten aus-wählen, so dass gezielt Matrizen für Negativ- und Positivtests entstehen.

Tabelle 4.1 zeigt ein einfaches Beispiel für mögliche Äquivalenzklassen und aus-gewählte Repräsentanten. Die Überprüfung von Grenzen sei dabei an dieserStelle nicht betrachtet.

Element Typ Beschreibung Äquivalenzklasse Repräsentanten

ID Int32

nie ungültig ! 0 0,"1,"2147483648

gültig 1 bis 25 1, 25

zu groß # 26 26, 27, 2147483647

Tabelle 4.1.: Äquivalenzklassen für gültige und ungültige Werte

Services überprüfen alle erhaltenen Daten in der Regel direkt nach Erhalt, sodass alle nicht benötigten Teile durch Mocks zu ersetzen sind. Erst wenn Datennicht überprüft werden, sind Mocks zu entfernen, um das Verhalten des Sys-tems zu beobachten. Aus Sicht des Servicekonsumenten kann unter Verwen-dung der ausgewählten Repräsentanten entsprechend mit dem Service intera-giert werden. Datenflüsse aus Richtung eines anderen Services erfordern, dassein Service zu erstellen ist, der diese Werte zur Verfügung stellt. Dazu stehenfür Webservices Werkzeuge zur Verfügung, die auch bei Kompositionen zum Er-stellen von Mocks genutzt werden und in Kapitel 8.3 angeführt werden.

Dieser Test ist automatisiert umzusetzen, weil mit mehreren Daten gleicherma-ßen mit einem Service interagiert wird. Erkennt der Service ungültige Daten undliefert eine Fehlermeldung, so ist ein Test bestanden, ansonsten nicht.

Bei Verletzung von Randbedingungen kann es zu Problemen bei der Verarbei-tung und Speicherung kommen [KBP02]. Speziell durch die Integration in Ge-schäftsprozessen sind ungültige Daten sehr realistisch und Fehler durch deren

29


Verarbeitung schwer ausfindig zu machen.

• Interoperabilität [App07]: Wenn die Technologie zur Realisierung einer SOAbekannt ist, wird noch keine Aussage über die eingesetzte Plattform getroffen.Dennoch muss ein Service zur Interaktion mit jeder Plattform in der Lage sein[Sta06a], um Kopplungen zu minimieren. Ansonsten steht ein Service nur einereingeschränkten Anzahl von Servicekonsumenten zur Verfügung.

WS-I [The06] ist ein Standard, um Interoperabilität für Webservices zu definie-ren. Werden Webservices als Technologie eingesetzt, ist eine Überprüfung aufInteroperabilität durch Werkzeuge möglich [Par] [Theb], die Konformität zum WS-I Standard prüfen.

Allgemein ist eine Auswahl von Plattformen zu treffen und mit diesen eine In-teraktion mit dem Service durchzuführen. Voraussetzung ist jedoch immer dieKenntnis einer Technologie.

• Rückwärtskompatibilität [App07]: Wenn sich die Serviceimplementierung än-dert, muss die Serviceschnittstelle unverändert bleiben. Jede Änderung an derServiceschnittstelle zieht Änderungen bei allen Servicekonsumenten nach sich.Auch wenn die Erstellung eines neuen Proxy heutzutage einfach durchzuführenist, resultieren aus einer Änderung an der Serviceschnittstelle evtl. auch Ände-rungen im Verhalten.

Grundsätzlich muss nur auf Rückwärtskompatibilität geprüft werden, wenn ei-ne öffentlich zugängliche Version des Services existiert. Immer, wenn eine neueVersion des Services entsteht, ist ein Proxy für den aktuellen Produktiv-Servicezu erstellen und in jedem automatisierten Test einzusetzen. D.h. unter Anwen-dung der Testmethode Regression testing sind alle existierenden Tests mit einemneuen Proxy erneut auszuführen.

• Sicherheit [App07]: Ist das Universum von Benutzern, die mit einem Service in-teragieren dürfen, begrenzt, müssen Maßnahmen zur Absicherung ergriffen wer-den. Allgemein ist sicherzustellen, dass ein Service nur wie vorgesehen genutztwerden kann und ein Ausnutzen jeglicher Art unmöglich ist. Die Auswirkungenbei Vernachlässigung dieses Testaspekts sind kritisch.

Die Umsetzung dieses Testaspekts ist projektabhängig, weil der aktive Tester,der nach Sicherheitslücken sucht, variiert:

1. Der Entwickler des Services testet, ob Funktionen zur Erhöhung der Sicher-heit korrekt implementiert sind.

2. Ein Tester prüft, ob festgelegte Sicherheitsanforderungen eingehalten wer-den.

3. Ein Tiger Team [Bur03] führt Angriffe auf den Service durch, um Sicher-heitslücken aufzudecken.

4. Benutzer nehmen an einem Wettbewerb Teil, um Sicherheitslücken in einemService zu finden.

30


Nach Abschnitt 3.3.2 folgt nach der Ermittlung aller Testaspekte die Zuordnungin einer Testmatrix. Für diesen Testaspekt ist dabei die Zuordnung variabel, weilsie vom gewählten aktiven Tester abhängt. D.h. die Testmatrix spiegelt die Vorge-hensweise zum Auffinden von potentiellen Problemen grob wieder; mindestensein Testszenario für jede Zeile wird das genaue Vorgehen festlegen. Tabelle 4.2illustriert für diesen Testaspekt die Auswirkungen der verschiedenen Rollen aufdie Serviceumgebung.

Tester Testaspekt lokal lokal/entfernt entfernt/test entfernt/live

Entwickler Sicherheit X X

Tester Sicherheit X

Tiger Team Sicherheit X X

Benutzer Sicherheit X

Tabelle 4.2.: Rollen, Testaspekte und Serviceumgebungen

Im Allgemein betrifft der Testaspekt Sicherheit alle drei Ebenen einer SOA. InAbschnitt 8.2 wird auf eine Veröffentlichung verwiesen, die sich speziell mit derSicherheit von Webservices befasst. Dabei geht es hauptsächlich um die poten-tiellen Probleme, die sich hinter diesem Testaspekt verbergen.

• Funktionalität: Jeder Service bietet Dienste an, auf die sich ein Servicekonsu-ment verlässt. Services können Effekte in der realen Welt bewirken und erforderneine qualitativ hochwertige Implementierung.

Das Vorhandensein und die Korrektheit von Funktionalität zu verifizieren, istdurch das Testen der Serviceimplementierung mit einer White-Box Sichtweisemöglich1. Einzusetzende Testmethoden sind Statement and branch coverageund Regression testing. D.h. durch die Tests sind Funktionalitäten zu überprüfen,so dass eine hohe Anweisungs- und Zweigabdeckung entsteht. Die Automatisie-rung dieser Tests erlaubt alle Tests nach Änderungen erneut auszuführen.

Ein Service ist eine existierende Einheit, mit der ein Servicekonsument inter-agiert. Liegt eine Servicedokumentation vor, so ist jede beschriebene Funktio-nalität unter Anwendung der Testmethoden Function testing und Specification-based testing zu testen.

• Last- und Performanceverhalten: Auf Seiten des Serviceanbieters müssen dieKapazitäten ausreichen, um einen Service bereit zu stellen. Unter Anwendungder Testmethoden Load testing, Performance testing und Long sequence tes-ting ist zu verifizieren, dass Anforderungen an das Lastverhalten durch die Infra-struktur erfüllt werden [CP06]. Zusätzlich sind nach [Par06] bereits während derEntwicklung Lasttests durchzuführen, um Fehler in der Serviceimplementierungfrüh zu finden.

1Liegt die Serviceimplementierung in einer objektorientierten Programmiersprache vor, so sind z.B. ausder testgetriebenen Entwicklung [Bec03] bekannte Komponententests anwendbar.

31


4.1.2. Webservices als Technologie

Webservices sind eine Technologie, die Dienste über Operationen anbietet. Ein Ser-vicekonsument ruft eine Operation durch Angabe von Parametern in einer SOAP-Nachricht auf. Als Ergebnis entsteht ein implementierter Effekt und der Webserviceschickt eine SOAP-Nachricht an den Servicekonsumenten zurück. Abbildung 4.3 illus-triert die Interaktion mit einem Webservice.

WebserviceServicekonsument

Operation()

Ergebnis

SOAP

Abbildung 4.3.: Interaktion mit einem Webservice

Für Webservices sind die folgenden Testaspekte von Interesse:

• Datentransferobjekte: Da zur Kommunikation XML-basierte SOAP-Nachrichtenausgetauscht werden, ist zu prüfen, ob die Nachrichten wohlgeformt sind. Spe-ziell arbeiten Plattformen intern nicht direkt mit XML, so dass eine Serialisierungnotwendig wird. Durch diesen Vorgang können neue Fehler entstehen, die esgezielt zu finden gilt.

Die Verifizierung der Datentransferobjekte erfordert alle Objekte, die in Parame-tern oder Rückgaben übermittelt werden, vollständig aufzulösen und nach XMLzu übersetzen. Es werden die folgenden Fehler gesucht:

– Datentypen lassen sich nicht nach XML übersetzen und sind daher nichtverwendbar.

– Unmögliche in XML darstellbare Eigenschaften verhindern eine Überset-zung, z.B. bidirektionale Abhängigkeiten oder allgemein zirkuläre Abhän-gigkeiten.

– Notwendige Informationen zur Übersetzung wurden nicht zur Verfügung ge-stellt.

Zur Durchführung des Tests werden nur die Datentransferobjekte benötigt. Hatman Zugriff auf den XML-Serialisierer, so sind alle Datentransferobjekte zu bau-en und serialisieren. Treten keine Fehler auf und das ursprüngliche Objekt stimmtmit seiner deserialisierten Version überein, so ist dieser Test bestanden. Zusätz-

32


lich existieren Werkzeuge, die eine automatische Überprüfung einer WSDL er-lauben [Par06].

• Webservice Standards: In Abschnitt 2.4.2 wurden Webservice Standards er-wähnt, die erweiterte Funktionalitäten zur Verfügung stellen. Die korrekte Instal-lation und Benutzung dieser Standards ist zu testen, weil Fehler einen Serviceunbrauchbar machen können. Dieser Testaspekt ist sehr verwandt mit dem Tes-taspekt Funktionalität aus Abschnitt 4.1.1.

4.1.3. .NET als Plattform

In .NET entwickelte Webservices können über einen Web Container oder als Prozessin Windows bereitgestellt werden. Die Bereitstellung benötigt ein zunächst hergestell-tes Deployment, das sich aus einem Build und einer Konfiguration zusammensetzt.Für .NET ergeben sich die folgenden Testaspekte:

• Verifizierung des Deployment: Bevor ein Service würdig ist komplexen Testsunterzogen zu werden, sind leichtgewichtige Überprüfungstests durchzuführen.Unter Einsatz der Testmethode Smoke testing ist zu prüfen, ob ein implementier-ter Service überhaupt grundlegend funktioniert.

Durch den Einsatz eines Containers, einer Plattform und Konfigurationen kön-nen eine Vielzahl von möglichen Fehlern auftreten. Ziel der Überprüfung ist fest-zustellen, ob die Bereitstellung erfolgreich war und der Service seine Diensteanbietet.

Subsysteme sind durch Mocks auszutauschen. Andernfalls ist sicherzustellen,dass alle Subsysteme verfügbar sind. Grundsätzlich erfolgt dieser Test durchgezielte Interaktion mit einem Service, so dass möglichst viele einfache Pfadeim Service durchlaufen und Subsysteme angesprochen werden. Pfade könnenunter Einsatz der Testmethode Path testing gefunden werden.

Die Korrektheit des Effekts ist bei diesem Test nicht relevant und ist durch andereTestaspekte abzudecken. Verifikationstests sind zu automatisieren, um nach derTestmethode Regression testing immer wieder einsetzbar zu sein.

• Konfigurationen: Bei der Realisierung von Enterprise Komponenten werdenKonfigurationen eingesetzt, um Teile des Services gezielt maßzuschneidern. EinDeployment kann dabei unterschiedliche Konfigurationen enthalten. Besondershäufig werden verschiedene Konfigurationen eingesetzt, um einen Build in eineranderen Umgebung einzusetzen.

Konkret sind die folgenden Teile eines Services von einer Konfiguration betroffen:

– Ermöglichen des Zugriffs auf Subsysteme, z.B. Datenbanken.

– Bibliotheken, die in der Implementierung eingesetzt werden, um bestimmteFunktionalitäten zu realisieren.

– Anpassen des Verhaltens des eingesetzten Containers.

33


Jede Konfiguration trägt einen Effekt bei, dessen Eintritt zu prüfen ist. Einzuset-zen ist dabei die Testmethode Path testing, um möglichst viele Pfade zu identifi-zieren, die von der Konfiguration betroffen sind.

Neben dem Auffinden von fehlerhaften Konfigurationen, betrifft dieser Testaspektauch unterschiedliche Konfigurationen. Ist vorgesehen einen Service in z.B. meh-reren verschiedenen Containern oder mit unterschiedlichen Subsystemen zunutzen, entsteht ein Universum von Konfigurationen. Dabei ist jede Konfigura-tion einzeln mittels Configuration coverage zu testen. Konfigurationstests sind imAllgemeinen zu automatisieren [GP06] und unter Anwendung der TestmethodeRegression testing nach jeder Änderung auszuführen.

• Fehlendes Subsystem: Services benutzen Subsysteme, z.B. andere Servicesoder Datenbanken. Fehlt eins dieser Subsysteme muss ein Service angemessenreagieren, indem er eine sinnvolle Fehlermeldung liefert oder Alternativen sucht.

Bei der Durchführung ist der Zugriff auf bestimmte Systeme manuell unmöglichzu machen und das Verhalten des Services zu überwachen.

• Versteckte Grenzen: Durch die Verwendung einer Schichtenarchitektur und un-terschiedlicher Subsysteme entstehen mehrere Grenzen, zwischen denen Ob-jekte ausgetauscht werden. Ändern sich die Datentypen oder Definitionsberei-che, so kann ein Informationsverlust auftreten. Diese versteckten Verluste gilt eszu identifizieren, damit ein Service mit beliebigen Daten arbeiten kann.

Zur Identifikation von versteckten Grenzen sind die folgenden zwei Schritte durch-zuführen:

1. Identifikation aller potentiellen Grenzen. Grenzen entstehen zwischen ein-zelnen Schichten in einer Schichtenarchitektur und beim Zugriff auf Sub-systeme.

2. Für jede identifizierte Grenze ist für jedes Objekt, das über diese Grenzeausgetauscht wird, der Datentyp bzw. aufgespannte Datenraum zu bestim-men.

Tabelle 4.3 zeigt beispielhaft ein Produkt der eben beschriebenen Analyse. Dabeitritt bei dem Objekt ID ein Datenverlust zwischen den Grenzen 1 und 2 auf.

Name Grenze 1 Grenze 2 Grenze 3

Typ Typ Typ

ID Int32 > Int16 < Int32

Tabelle 4.3.: Analyse zur Ermittlung versteckter Grenzen

Nach der Bestimmung aller Grenzen und Datentypen, sind Testdaten zu ermit-teln, die zu Fehlern führen können. Als hilfreiche Testmethode kann die Boundary-value analysis eingesetzt werden. Testfälle nutzen diese Testdaten und versu-chen zu zeigen, dass aus der Datenreduktion fehlerhaftes Verhalten folgt.

34


Dieser Testaspekt repräsentiert einen vereinfachten Integrationstest. Die Gren-zen seien als versteckt bezeichnet, weil ein Servicekonsument nur die Service-schnittstelle sieht.

4.2. Analogien zu Java EE

Neben .NET sind heutzutage auch Webapplikationen mit Java EE sehr verbreitet. DiePraktiken, mit denen dabei Applikationen erstellt werden, sind sehr verwandt. Dahersind die vorgestellten Testaspekte aufgrund folgender Gründe auch für Java EE gültig:

• Die Bereitstellung eines Services findet durch einen Applikationsserver gleicher-maßen durch ein Deployment statt.

• Das Deployment setzt sich aus einem Build und einer Konfiguration zusammen.

• Architekturen sind ähnlich mit einer Schichtenarchitektur konstruiert nach Abbil-dung 2.2.


Für jede Ausprägung einer Ebene sind Testaspekte ableitbar. In diesem Kapitel wur-den Testaspekte für Webservices, dem Microsoft .NET Framework und SOA selbstvorgestellt. Die Formulierung einer Teststrategie ist zu diesem Zeitpunkt noch nichtmöglich, weil dazu das Projektumfeld fehlt.

Im folgenden Kapitel wird zunächst ein Werkzeug vorgestellt, das die Umsetzung vonTeststufen und Teststrategien ermöglicht. Erst im Rahmen der Fallstudie in Kapitel 6finden die vorgestellten Testaspekte Anwendung und formen eine Teststrategie.

35

5. Werkzeugunterstützung für dieTeststrategie

Ist ein Testaspekt automatisiert zu testen, so wird ein Werkzeug zur Testdurchführungnotwendig. Allgemein wird in einer SOA ein Werkzeug für die praktikable Umsetzungeiner Teststrategie benötigt. Ähnlich wie eine Teststrategie, ist auch dieses Werkzeugan die Ausprägung einer SOA gebunden.

Ein Werkzeug zur Unterstützung der Teststrategie muss die Realisierung von Ser-viceumgebungen und Komponenten-, Integrations- und Systemtests direkt ermögli-chen. Speziell diese Arbeit wird Komponententests nach den in Abschnitt 3.4.3 vorge-stellten Ansätzen realisieren.

In diesem Kapitel wird zunächst allgemein ein Werkzeug vorgestellt, das sich aufWebservices und eine Enterprise Plattform stützt. Ein konkret in dieser Arbeit ent-wickeltes Werkzeug betrachtet die in Abbildung 5.1 illustrierte Ausprägung und wirdim Anschluss beschrieben.

Abbildung 5.1.: Ausprägung des implementierten Werkzeugs

5.1. Überblick

5.1.1. Anforderungen

Zur Unterstützung der Teststrategie muss ein Werkzeug die Umsetzung von Serviceum-gebungen nach Abschnitt 3.3.1 ermöglichen und die Automation von Tests für Webser-

36

5. Werkzeugunterstützung für die Teststrategie

vices erleichtern. Für die Realisierung von Testfällen gelten zunächst die folgendenAnforderungen:

• Erweiterung vorhandener Werkzeuge: Die Unterstützung fließt nahtlos in vor-handene Unit Test Frameworks ein. Vorhandene Werkzeuge bieten Basisfunk-tionalitäten für die Formulierung, Organisation, Ausführung und Auswertung vonTests an. Sie sind seit Längerem erprobt und getestet. Zusätzlich sind Entwicklermit den Werkzeugen vertraut, so dass der Einstieg beim Testen von Webservicesleichter fällt.

• Unabhängige Testläufe: Testläufe und die Tests selbst sind voneinander unab-hängig.

In jedem Test ist es notwendig das Testobjekt zu kennen. Stellvertretend übernimmtein Proxy diese Funktion:

• Proxy-Integration: Ermöglichen der Interaktion mit einem Service durch Integra-tion eines Proxy-Objekts. Speziell der Endpunkt des Webservices muss beliebigfestlegbar sein.

Auch wenn das Verfassen von herkömmlichen Komponententests für die Serviceim-plementierung möglich ist, hat Abschnitt 3.4.3 neue Ansätze für Komponententestsaufgezeigt. Im Folgenden seien Anforderungen zum Verfassen von Komponententestsfür Webservices vorgestellt:

• Realisierung von Mocks: Anbieten von Möglichkeiten zum Einsatz eines har-ten oder weichen Mocks. Folglich muss sich Code auf einfache Art und Weiseändern lassen, um einen harten oder evtl. weichen Mock zu ermöglichen.

• Aktive Verwaltung des Deployment: Nach Konsequenz 2.3 wird immer miteinem bestehenden Objekt interagiert. Durch die Bereitstellung in einem WebContainer ist es nicht mehr möglich von außen Einfluss auf einen Webservice zunehmen. Folglich muss ein Webservice vor der Bereitstellung manipuliert wer-den. Dazu benötigt man eine aktive Verwaltung der Dateien aus denen sich einDeployment zusammensetzt. Insbesondere muss die kurzzeitige Manipulationvon Dateien und auch deren Inhalten einfach möglich sein, ohne dass sich dierealen Dateien ändern.

Die Manipulation des Deployment muss während der Testdurchführung erfolgen.Dadurch setzt sich evtl. erst zur Laufzeit das eigentliche Testobjekt aus einer Ser-viceumgebung und den Vorschriften zur Manipulation des Deployment zusam-men. In jedem Testlauf kann mit einer einzigartigen Mutation eines Webservicesgearbeitet werden.

• Aktive Bereitstellung: Durchführen einer Bereitstellung in einem Web Contai-ner, um ein manipuliertes Deployment direkt testen zu können. Insbesonderemuss es möglich sein einen lokalen Web Container zu starten.

Das vorgestellte Werkzeug wird nur eine Erweiterung eines Unit Test Frameworks seinund sei daher im weiteren Verlauf als Erweiterung bezeichnet.

37


5.1.2. Konsequenzen

Die im letzten Abschnitt vorgestellten Anforderungen und auch die gewählte Ausprä-gung führt zu folgenden Konsequenzen:

• Ein Proxy-Objekt muss immer bereits zur Kompilierzeit bekannt sein. Mit UnitTest Frameworks werden Testfälle als Code verfasst. Dabei ist jeder Testfall dieMethode einer Klasse und wird kompiliert. Dies erzwingt, dass alle benutzten Ob-jekte zur Kompilierzeit vorliegen müssen, so auch das Proxy-Objekt. Das Proxy-Objekt ist als Stellvertreter zum eigentlichen Testobjekt, dem Webservice, zubetrachten.

• Durch die Manipulation von Code zur Realisierung eines harten Mocks werdenAbhängigkeiten zur Sprache geschaffen. Im Rahmen dieser Arbeit sei C# alsProgrammiersprache betrachtet.

5.1.3. Prozess

Ein Webservice durchläuft immer mehrere Schritte in der Entwicklung. Dies kann be-wusst und geplant passieren, aber auch zufällig aus der Notwendigkeit heraus. In je-dem Fall werden die folgenden Schritte immer in der angegeben Reihenfolge durch-laufen:

1. Verwaltung: Es muss eine übergeordnete Struktur erstellt werden, die den Web-service verwaltet. Dies kann nur ein Verzeichnis mit Quelldateien sein, aber auchumfangreichere Verwaltungsmöglichkeiten, wie z.B. Projekte, sind denkbar.

2. Entwicklung: Der Entwickler implementiert die Serviceimplementierung des Web-services.

3. Build: Der Entwickler veranlasst einen Build, der aus der Serviceimplementie-rung ein Deployment erstellt. Oftmals existieren Skripte, die automatisiert einenBuild durchführen.

4. Bereitstellung: Das erzeugte Deployment wird auf einen Web Container über-tragen und der Webservice steht zur Interaktion bereit.

Ist das Testen von Webservices automatisiert zu unterstützen, so sind Teile der ebengenannten Punkte in die Automatisierung mit einzubeziehen. Es ist erst möglich miteinem Webservice zu interagieren, wenn dieser vollständig und erfolgreich in einenWeb Container übertragen wurde.

Im Allgemeinen untergliedern sich automatisierte Tests in drei Phasen:

• Initialisierung: Vorbereitung eines Testobjekts und herstellen eines definiertenZustandes.

• Testdurchführung: Durchführung des Tests am Testobjekt.

• Aufräumen: Wiederherstellen des Zustands vor der Initialisierung.

38


Abbildung 5.2 zeigt den durchlaufenden Prozess eines Tests für Services. Dieser Pro-zess sei im Folgenden als Testprozess bezeichnet.

Test

Verwaltung

Build

Bereitstellung Bereitstellung

Build

Verwaltung

Rückgängigmachen allerAktivitäten der Initialisierung

TestTest

Abbildung 5.2.: Ablauf eines Tests für Services

Das im Rahmen dieser Arbeit entwickelte Werkzeug wird den vorgestellten Testpro-zess implementieren und auf die drei Phasen von automatisierten Tests abbilden.

5.2. Testmöglichkeiten in .NET

Für .NET existieren mehrere Unit Test Frameworks, die für eine Erweiterung geeignetsind:

• NUnit [Ham04]: Ein Vertreter der xUnit Test Frameworks als Realisierung für.NET.

• Das Unit Test Framework der Microsoft Visual Studio Team Edition: In der Mi-crosoft Visual Studio Team Edition für Softwareentwickler oder Tester ist ein voll-ständiges Unit Test Framework enthalten.

In Rahmen dieser Arbeit ist das Unit Test Framework der Microsoft Visual Studio TeamEdition aus folgenden Gründen zu erweitern:

39


• Die Visual Studio Team Edition wird bei dem in Kapitel 6 vorgestellten Unterneh-men eingesetzt.

• Das Unit Test Framework ist nahtlos in die Entwicklungsumgebung von VisualStudio integriert.

• Die Visual Studio Team Edition ermöglicht einen gesamten Entwicklungsprozessund seine Artefakte zu verwalten [GP06]. Neben Testfällen an sich, ist es auchmöglich den Tests direkt die Ergebnisse von Testläufen und gefundene Bugszuzuordnen.

• Die Integration in einen Build-Prozess ist direkt möglich.

In .NET gibt es bereits einige Möglichkeiten einen Webservice zu testen:

• Das Unit Test Framework der Microsoft Visual Studio Team Edition erlaubt lokaleinen ASP.NET Development Server zu starten, über den ein Webservice bereit-gestellt wird. Dies erlaubt die Interaktion mit einem Webservice, aber erfordert,dass alle teilnehmenden Subsysteme existieren und zugreifbar sind.

• Ein in .NET entwickelter und bereitgestellter Webservice hat eine Bedienoberflä-che, die es erlaubt jede Operation mit einem Browser aufzurufen. Dies ermöglichtdie Interaktion mit einem Webservice, selbst wenn wenig technisches Verständ-nis vorhanden ist.

Alle bekannten Ansätze und Werkzeuge haben gemeinsam, dass das Deployment im-mer vor der Testdurchführung bekannt sein muss und auch eine Bereitstellung bereitserfolgt sein muss. Es ist nicht möglich ein Deployment interaktiv während oder kurzvor der Testdurchführung frei zu gestalten und diesen Vorgang für Regressionstestsaufzuheben. Als Konsequenz ist nach jedem Testlauf ein definierter Zustand herzu-stellen.

5.3. Architektur

5.3.1. Grobarchitektur

Die Architektur der Erweiterungen gliedert sich in drei Teilbereiche, die einzelne Funk-tionalitäten beschreiben. Abbildung 5.3 gibt dazu eine Übersicht, wobei jeder Teilbe-reich die folgenden Aufgaben übernimmt:

• Adapter: Enthält einen Adapter zum bestehenden Unit Test Framework und al-le Klassen, die eine Benutzerschnittstelle zu neu angebotenen Funktionalitätenbilden. Dabei ist das Ziel die bisherige Testausführung um neue Funktionen zuerweitern, die während der Initialisierung und dem Aufräumen abgearbeitet wer-den. Der Adapter veranlasst alle weiteren Schritte, so dass der Testlauf an sichum einen Testprozess dekoriert wird. Die Ausführung und Auswertung des Testsübernimmt weiterhin das Unit Test Framework.

Dieser Adapter ist abhängig vom eingesetzten Unit Test Framework, indem er

40


vorhandene Besonderheiten berücksichtigt und die bestehende Verwaltung derTests nutzt.

• Testablauf: Die interne Beschreibung des technischen Testprozesses. Weiterhineine Möglichkeit zur Ausführung und Verwaltung des Testprozesses.

• Externe Systeme: Alle externen Systeme, mit denen interagiert werden muss,z.B. das Dateisystem, ein Compiler oder Möglichkeiten zur Bereitstellung.

FrameworkAdapter

InitialisierungAufräum

en

Adapter Testablauf Extern

NeueFunktionalitäten

nutzt

nutzt

nutzt

nutztnutzt

Tester

Abbildung 5.3.: Grobarchitektur

Die Architektur von jedem Teilbereich ist stark durch Entwurfsmuster geprägt und einedetaillierte Darstellung erfolgt in den nächsten Abschnitten.

5.3.2. Testablauf

Abbildung 5.4 illustriert die Architektur des Teilbereichs Testablauf. Ziel ist es den Test-prozess um Logik vor und nach der Testdurchführung zu erweitern. D.h. die Testdurch-führung selbst übernimmt weiterhin das zu erweiternde Unit Test Framework.

41


+Initialize()+CleanUp()

TestProcess

+DoBeforeTest()+DoAfterTest()

+Command : ITestCommand+Preparation : ITestCommand[]

TestProcessNode

1

+Node1..*

+DoBeforeTest()+DoAfterTest()

«interface»ITestCommand

Knoten für:VerwaltungBuildBereitstellungTest

Abbildung 5.4.: Feinarchitektur des Teilbereichs Testablauf

Ein Knoten im Testprozess besteht immer aus einem Command-Objekt zur Durch-führung der eigentlichen Logik und einer Liste von Command-Objekten, die vorherauszuführen sind (Vorbereitung). Insgesamt entsteht eine Hierarchie, in der die Aus-führung des Testprozesses entsprechend an die Knoten delegiert wird, die wiederumjedes Command-Objekt entsprechend ausführen. Die Command-Objekte sind dabeianderorts implementiert und der Teilbereich Testablauf bildet nur einen leeren unddefinierten Rahmen.

5.3.3. Adapter zu einem Unit Test Framework

Das Unit Test Framework der Microsoft Visual Studio Team Edition bietet aufgrundvon fehlenden Schnittstellen und der Tatsache, dass der Quellcode nicht frei verfügbarist, keine Möglichkeiten zur direkten Erweiterung an. Daher gilt es die vom Unit TestFramework bereitgestellten Möglichkeiten zur Initialisierung und zum Aufräumen soerweiterbar zu machen, dass ein Nutzer leicht neue Funktionalitäten einbinden kann.

Die Aktivitäten der Initialisierung und des Aufräumens sind Teile eines jeden Testfallsund werden durch Methoden repräsentiert. Über beide Aktivitäten hat der Verfasserdes Tests die Kontrolle, so dass er einen Adapter einbinden kann. Der Adapter benötigtdabei die folgenden Informationen:

• Die aktuelle Klasse, die Testfälle umsetzt.

• Ein Proxy zur Interaktion mit einem Service.

• Ein Objekt, das alle wichtigen Steuerungsinformationen während des Testlaufsenthält.

42


Zum einfachen Einbinden bietet sich eine statische Methode an, die eine Verbin-dung zwischen dem Unit Test Framework und den Erweiterungen herstellt. Als Aus-kommen dieses Aufrufs wird neue Funktionalität bereitgestellt und ein Objekt desProxy so vorbereitet geliefert, dass dieses direkt zum Testen des Webservices ge-nutzt werden kann. Abbildung 5.5 zeigt die Einbindung des Adapters in einem Testin C#. Dabei enthält der TestContext alle Steuerungsinformationen des Testlaufs.InitializeLink führt die Initialisierung des Testprozesses aus und gibt ein Objektdes Proxy zurück. ReleaseLink führt die Aufräumknoten des Testprozesses aus undlöst dadurch die Verbindung zu den Erweiterungen auf.

1 [ TestClass ]2 public class Test {34 [ T e s t I n i t i a l i z e ]5 public void I n i t i a l i z e ( ) {6 Proxy serv i ce = Adapter <Test , Proxy >. I n i t i a l i z e L i n k ( TestContext ) ;7 }89 [ TestCleanup ]

10 public void CleanUp ( ) {11 Adapter <Test , Proxy >. ReleaseLink ( TestContext ) ;12 }1314 . . .1516 }

Abbildung 5.5.: Einbindung des Adapters in einem Test

Der Adapter stellt die äußere Schnittstelle zum Testprozess dar. Neue Funktionalitätenwerden über Annotationen1 bereitgestellt. Jede Annotation enthält dabei die Logik zurentsprechenden Manipulation des Testprozesses.

Abbildung 5.6 stellt den gesamten Teilbereich Adapter als Klassendiagramm dar. An-notationen werden über eine Vererbungshierarchie identifiziert, wodurch eine gezielteAuswertung möglich wird.

Die Verwaltung von Informationen, die während der Testdurchführung entstehen undanderorts notwendig sind, werden in einem global erreichbarem Kontext abgelegt.

1Annotationen sind in Java Metadaten, die direkt am Code angegeben werden. In .NET werden Anno-tationen als Attribute bezeichnet.

43


+InitializeLink(in testContext) : Proxy+ReleaseLink(in testContext)-EvaluateAttributes(in testName : string)

Adapter

+RegisterAt(in process)

TestAttribute

ScopeAttribute

ConfigurationAttribute

System.Attribute

Wertet Test- und Konfigurationsannotationen aus.

Annotationen zur Bereitstellung unterliegender Einschränkung, dass nur eine Bereit-stellung je Testfall erfolgt.

+RegisterAt(in process)

«interface»ITestProcessRegistration

Abbildung 5.6.: Feinarchitektur des Teilbereich Adapter

5.3.4. Interaktion mit externen Systemen

Zur Realisierung des Testprozesses ist der Einsatz von Systemen zum Kompilierenoder Bereitstellen unabdingbar. Daher seien externe Systeme durch eine Fassade[GHJV95] so implementiert, dass sie in den Erweiterungen wohl definiert nutzbar sind.Dies begünstigt Flexibilität durch eine klare Trennung zwischen den Erweiterungenund externen Systemen. Zusätzlich wird die Testbarkeit erhöht, weil sich Tests durchden Einsatz von Mocks ohne reale Effekte ausführen lassen.

44


+Parse(in code : string)+GetOutput() : string

«interface»IParser

«interface»IFileSystemFacade

«interface»IPathLocator

+Load(in solutionFile : string)+Build()

«interface»ISolutionFacade

+Start()+Shutdown()

«interface»IAspNetDevelopmentServer

+Parse(in code : string)+GetOutput() : string

CSharpParser

+Start()+Shutdown()

AspNetDevelopmentServer

FileSystemFacade

PathLocator

+Load(in solutionFile : string)+Build()

SolutionFacade

Abbildung 5.7.: Feinarchitektur des Teilbereich Extern

Abbildung 5.7 zeigt die Architektur des Teilbereich Extern in vereinfachter Form. JedeFassade ist definiert durch eine Schnittstelle, die für das Umfeld .NET implementiertist. Die Funktionen einer jeden Fassade stellen sich wie folgt dar:

• IParser: Stellt Möglichkeiten zur Manipulation von Code zur Verfügung. Die kon-krete Implementierung ist an eine Sprache gebunden, um harte Mocks zu er-möglichen. Eine detaillierte Beschreibung wird in Abschnitt 5.5 gegeben.

• IAspNetDevelopmentServer: Der ASP.NET Development Server ist ein WebContainer im .NET Umfeld und wird während der Entwicklung zu Testzweckeneingesetzt.

• IFileSystemFacade: Verbirgt Operationen auf dem Dateisystem.

• IPathLocator: Dient zum Auflösen von Pfaden und hält definierte Pfade bereit.

• ISolutionFacade: In .NET heißt die einem Projekt übergeordnete Struktur Solu-tion. Diese Fassade erlaubt die Durchführung eines Builds für eine Solution.

45


5.4. Implementierung

Die Umsetzung von Serviceumgebungen und das Einfügen von Mocks sind neueFunktionalitäten, die die Erweiterungen einem Tester zur Verfügung stellen. Reali-siert sind sie über Annotationen, die den Testprozess mit Command-Objekten ent-sprechend anreichern.

Viele Command-Objekte nehmen Änderungen am Deployment vor, so dass für diesenFall ein Klon von der Solution erstellt wird. Dadurch sind alle Änderungen nur tempo-rär und betreffen den jeweiligen Testlauf. Realisiert wird der Klonvorgang durch wohldefinierte Command-Objekte, die den Verwaltungsknoten des Testprozess erweitern.Konkret wird ein entsprechender Pfad zum Ablegen des Klon gesucht und eine Kopiealler Verzeichnisse rekursiv erstellt. Anderen Command-Objekten steht der Klon übereinen Kontext zur Verfügung.

Umgesetzt sind die folgenden Annotationen:

• Die lokal/entfernt Serviceumgebung stützt sich auf einen lokal zur Verfügunggestellten Web Container. Die Annotation LocalRemote dekoriert den Bereit-stellungsknoten des Testprozess um ein Command-Objekt, das einen ASP.NETDevelopment Server startet und die Bereitstellung eines Projektes durchführt.

• Eine entfernte Serviceumgebung wird manuell bereitgestellt, so dass nur dieURL des Endpunkts von Interesse ist. Die Annotation Remote muss folglich nurden Bereitstellungsknoten des Testprozess um ein Command-Objekt erweitern,das die URL des Proxys auf die URL des Services umleitet.

• Der Einsatz eines harten Mocks nach Abschnitt 3.4 kann durch den Austauschvon Dateien im Deployment oder dem Austauschen von Code umgesetzt wer-den. Entsprechende Annotationen erweitern die Vorbereitung des Buildknotensum Command-Objekte, die eine Datei oder Code austauschen. Die genaue Vor-gehensweise wird in Abschnitt 5.5 vorgestellt.

• Ein weicher Mock zieht nach Abschnitt 3.4.3 die Änderung des Deploymentsnach sich. Dazu muss eine Annotation das Deployment so manipulieren, dassein weicher Mock während der Testdurchführung nutzbar wird. Abschnitt 5.6 wirddiesen Fall genauer betrachten und unterschiedliche Vorgehensweisen beschrei-ben.

Während der Implementierung wurden einige Maßnahmen zur Steigerung der Qualitätunternommen. Zunächst wurde ein Wegwerf-Prototyp entwickelt, um Probleme bei derletztendlichen Implementierung zu vermeiden. Die Erweiterungen selbst sind testge-trieben [Bec03] implementiert, damit schon während der Entwicklung durch kontinu-ierliche Tests die Qualität sichergestellt wird. Zum Abschluss wurden weitere Mängeldurch die statische Codeanalyse von Microsoft Visual Studio identifiziert und behoben.

46


5.5. Realisierung von harten Mocks

5.5.1. Identifikation von auszutauschenden Teilen

Ein nach Abschnitt 3.4.3 eingeführter harter Mock wird Teile eines Deployment aus-tauschen. Entwicklungsumgebungen verwalten Quellcode in Projekten. D.h. existiertbereits ein Klon der Projekte, so ist der Austausch von gesamten Dateien einfachmöglich. Für die gezielte Ersetzung von Teilen im Quellcode präsentiert diese Arbeiteinen neuen Mechanismus.

Vor der Manipulation von Code ist es notwendig den auszutauschenden Teil festzu-legen. Dabei sind einfache Merkmale wie z.B. die Zeilennummern einer Datei unge-eignet, weil sie gegenüber Änderungen nicht konstant sind. In der objektorientiertenProgrammierung dienen Klassen und Methoden zur Strukturierung einer Applikation.Klassen enthalten dabei Methoden und stellen das äußere Gerüst dar, so dass erst inMethoden konkrete Logik implementiert wird. Daher seien Methoden als der Teil vonCode ausgewählt, den es zu ersetzen gilt. Die Identifikationsmerkmale einer Methodesind wie folgt:

• Äußere Klasse

• Methodenname

• Parameter

• Generische Typen

Gilt es eine Methode auszutauschen, so sind alle vier Identifikationsmerkmale, derneue Rumpf der Methode und die zu manipulierende Datei vom Testverfasser anzu-geben.

5.5.2. Verarbeitung und Austauschen von Code

Sind alle notwendigen Informationen zum Austauschen einer Methode bekannt, mussein Mechanismus die Änderungen vornehmen. Dabei gilt es zunächst die Methode imQuellcode zu finden und anschließend den neuen Rumpf zu schreiben. Im Folgendenwird dazu ein Parser vorgestellt, der Zeichenweise einen Text verarbeitet.

Zur Vereinfachung sei die Annahme getroffen, dass der betrachtete Code wohlgeformtist. Diese Annahme kann getroffen werden, weil im Testprozess immer ein Build durch-zuführen ist, wenn sich das Deployment ändert. Dies erlaubt den Parser auf Problemeaus der Zeichenkettensuche zu reduzieren.

Zur kontextuellen Suche einer Methode und zum Schreiben des Ergebnisses setzt derParser das Strategy-Entwurfsmuster [GHJV95] ein. Die Strategien erhalten dabei einZeichen und entscheiden intern über die weitere Verarbeitung:

• Ein Finder ist eine Strategie, deren Implementierung zur Suche von Informatio-nen genutzt wird. Zusätzlich repräsentiert ein Finder den Zustand des Parsers

47


nach dem State-Entwurfsmuster [GHJV95]. Ein Finder definiert jeweils für denErfolgsfall und den Fehlschlag den nachfolgenden Finder.

• Ein Writer ist eine Strategie zum Schreiben von Zeichen.

Generische Typen suchen

Parameter suchen

Anfang des Methoden-

rumpfessuchen

Klassenschlüs-selwort oder

Methodennamesuchen

Methodennamegefunden

Ende der generischenTypen erreicht

Ende der Parameterlisteerreicht

Klassennamesuchen

Klassenschlüssel-wort gefunden

Klassennamegefunden

Abbildung 5.8.: Zustandsübergänge der Finder

Zum Auffinden einer Methode durchläuft der Parser die in Abbildung 5.8 durch Finderrepräsentierten Zustände. Der Misserfolgsfall wird dabei nicht explizit angegeben undsei für alle Kanten ohne Markierung angenommen. Für jeden Knoten existiert eineeigene Klasse, die die Schnittstelle der Finder mit entsprechender Logik implemen-tiert. Zur Erzeugung von Finder -Objekten wird das Factory-Entwurfsmuster [GHJV95]eingesetzt.

Während der Verarbeitung einer Quelldatei ist sowohl die aktuell betrachtete Klasse,als auch der aktuelle Block2 von Interesse. Deshalb existiert ein Stack für die gefun-

2In C# wird ein Block durch geschweifte Klammern eingeleitet und abgeschlossen.

48


denden Klassen und ein zentraler Zähler zur Speicherung des aktuellen Blocks.

Im Allgemeinen wird ein Writer verwendet, der jedes erhaltene Zeichen direkt schreibt.Nur im Fall, dass erfolgreich eine Methode zum Austauschen gefunden wurde, wirdder Writer gewechselt. Dieser neue Writer schreibt den neuen Methodenrumpf und eswird veranlasst alle Zeichen so lange zu überlesen bis das Ende der Methode erreichtwurde; das Ende der Methode stellt ein Beobachter fest.

Die zentrale Steuerung übernimmt nach dem Mediator-Entwurfsmuster [GHJV95] einManager. Dieser erlaubt jedem Finder und Writer kontextsensitive Informationen zunutzen. Abbildung 5.9 zeigt den Parser als Klassendiagramm.

+Parse(in code : string)

Parser+Output : string

+Find(in character : char)+Write(in character : char)

ParserManager+ActiveFinder : IFinder+ActiveWriter : IWriter+MethodsToMock[] : Method

11

Entsprechende Schnittstellenseien nicht angegeben.get- und set-Methoden seiendurch öffentliche Attributerepräsentiert.

+Push(in classToPush : Class)+Pop() : Class+Peek() : Class

ClassStack

11

+Increment()+Decrement()

BlockCounter

11

+Find(in character : char)+DoMatch(in manager : IParserManager)+DoFail(in manager : IParserManager)

«interface»IFinder

+Write(in character : char)

«interface»IWriter

+CreateFinder(in type : int)

«interface»IFinderFactory

Abbildung 5.9.: Architektur des Parser

5.6. Realisierung von weichen Mocks

Die Einführung von weichen Mock-Objekten setzt einen Mechanismus voraus, dereinen Austausch von Objekten zur Laufzeit durchführt. Die Logik, die diesen Austauschvornimmt, ist vor der Bereitstellung dem Webservice hinzuzufügen. Nach der Bereit-stellung kann ein Test nicht mehr von außen Einfluss auf den Webservice nehmen.

Im Verlauf dieser Arbeit wurden drei verschiedene Ansätze verfolgt, die auf den nächs-ten Seiten vorgestellt werden.

49


1. Abbildung 5.10 zeigt die Realisierung eines weichen Mocks unter Einsatz einerSteuereinheit. Die Steuereinheit ist ein Webservice, der zum Deployment deszu testenden Webservices hinzuzufügen ist. Den Austausch von Komponen-ten durch Mocks übernimmt die Steuereinheit. Die eingenommene Sichtweiseder Steuereinheit entspricht der Sichtweise eines Tests in der objektorientiertenProgrammierung (siehe Abbildung 3.3 in Abschnitt 3.4.3). Demnach muss dieSteuereinheit Zugriff auf die Instanz eines Webservices haben.

Test Steuereinheit Webservice

Initialisierung()

Aufräumen()

SetzeKomponente()

Operation()

Ergebnis

SetzeKomponente()

SOAP

Abbildung 5.10.: Weicher Mock mit Steuereinheit

Ein Tester muss nur die Logik zum Austauschen einer Komponente angeben. DieSteuereinheit ist einmalig zu implementieren und die Serviceimplementierungbleibt unverändert.

Dieser Ansatz ist aufgrund von Konsequenz 2.3 nicht anwendbar, weil im WebContainer kein Zugriff auf die Instanz des Webservices möglich ist. Insbesondereist auch nicht bekannt mit welcher Instanz eines Webservices ein Servicekonsu-ment interagieren wird.

50


2. In Abbildung 5.11 wird ein Ansatz unter Einführung einer Initialisierungs- undAufräumoperation im Webservice illustriert. Dabei führen die neuen Operationenden Austausch der Komponenten durch.

Test Webservice

Aufräumen()

Operation()

Ergebnis

Initialisierung()

SOAP

Abbildung 5.11.: Weicher Mock mit neuen Operationen

Ein Tester gibt die Logik der Initialisierungs- und Aufräumoperation an. Die Ser-viceimplementierung bleibt insofern unverändert, als dass sich keine Operatio-nen im Webservice ändern.

Zwischen dem Aufruf von Operationen eines Webservices kann nicht garantiertwerden, dass die Instanz des Webservices identisch bleibt [Sta06a] (siehe auchKonsequenz 2.5). Folglich ist auch dieser Ansatz nicht anwendbar.

51


3. Abbildung 5.12 zeigt einen Ansatz, der die zu testende Operation im Webserviceum Logik zur Durchführung der Initialisierung und dem Aufräumen erweitert. Da-bei wird eine Operation so verändert, dass sich ihr eigentliches Verhalten nichtändert.

Test Webservice

Operation()

Ergebnis

Initialisierung()

Aufräumen()

SOAP

1 public void Operat ion ( ) {2 I n i t i a l i z e ( ) ;3 t ry {4 / / vorhandener Code5 } catch ( Except ion ) {6 throw ;7 } f i n a l l y {8 CleanUp ( ) ;9 }

10 }

Abbildung 5.12.: Weicher Mock mit erweiterter Logik

Zur Implementierung dieses Ansatzes wurde der Parser aus 5.5 wie folgt erwei-tert:

• Der Writer, der einen Mock schreibt, ist so anzupassen, dass bisheriger Co-de erhalten bleibt. D.h. eine Methode wird nur mit neuen Codefragmentendekoriert.

• Einfügen eines Beobachters, der die Klasse des Webservices um eine Ini-tialisierungs- und Aufräummethode erweitert.


Ein Werkzeug zur Unterstützung einer Teststrategie betrifft Ausprägungen in allen dreiEbenen einer SOA. Insbesondere wird man abhängig von der Plattform, ermöglichtaber Komponententests nach Abschnitt 3.4.

Durch den Einsatz von Entwurfsmustern und klarer Trennung der Zuständigkeiten er-hält man eine sehr einfache Architektur, die sich aus einem Adapter, einem Testablaufund externen Systemen zusammensetzt.

52

6. Fallstudie

Kapitel 3 hat gezeigt, wie eine Teststrategie für eine SOA zu finden ist. Dabei hat imAnschluss Kapitel 4 die ersten zwei Schritte dieser Vorgehensweise durchgeführt. Indiesem Kapitel gilt es eine konkrete Teststrategie unter Einbezug der bisherigen Er-gebnisse zu finden. Dazu werden die Webservices eines Unternehmens als Testobjek-te dienen. Die Teststrategie selbst ist angepasst an das vorherrschende Projektumfeldim Unternehmen.

Nach erfolgreicher Festlegung einer Teststrategie, beschrieben durch eine Testmatrixund Testszenarien, ist diese Teststrategie für die bereits erwähnten Webservices um-zusetzen. Zur Ausführung von Testfällen dient das in Kapitel 5 vorgestellte Werkzeug.

6.1. Projektumfeld

Das im Rahmen dieser Fallstudie betrachtete Unternehmen ist im Business-To-Busi-ness Umfeld tätig. Angebotene Dienste werden über ein eigenes entwickeltes undverwaltetes Portal zur Verfügung gestellt. Die Entwicklung betrifft im Allgemeinen dieErweiterung und Wartung dieses Portals.

Abbildung 6.1(a) zeigt eine Übersicht über das hauseigene Portal. Informationen überdie Interaktion mit Objekten werden aktiv verfolgt und gesammelt. Kunden interagie-ren mit dem Geschäftsbereich über eine Website. Webservices sind ein noch weniggenutztes Produkt und bieten bereits vorhandene Funktionalitäten der Website an.

In einer SOA übernimmt das Unternehmen die Rollen des Serviceanbieters und desServiceentwicklers. Das Portal selbst ist nicht serviceorientiert strukturiert, sondernmit herkömmlichen Mitteln in .NET und mit Datenbanken realisiert. Abbildung 6.1(b)definiert allgemein die Ausprägung einer SOA im Unternehmen.

Bisherige Tests wurden für die Webservices nur vereinzelt systematisch durchgeführt.Vorherige Schritte wie das Verfassen einer Teststrategie oder eines Testkonzepts feh-len bisher. Von den Entwicklern werden Komponententests mit einem Unit Test Fra-mework gelegentlich umgesetzt und während der Entwicklung der Webservices wurdenicht auf Testbarkeit geachtet.

Zusätzlich sind die folgenden Vorgehensweisen und Randbedingungen für diese Arbeitvon Bedeutung:

• Ein automatisierter Build-Prozess wird jeden Tag durchlaufen.

• Bisherige Tests werden immer aus Systemsicht durchgeführt, d.h. von Teststufen

53

6. Fallstudie

(a) Architektur (b) Ausprägung

Abbildung 6.1.: Portal des Unternehmens

wird kein Gebrauch gemacht.

• Für Tests existiert eine produktionsnahe Testumgebung, die ein komplettes Ab-bild der Datenbank zu einem gegebenen Stand vorweist.

• Tester sind nicht technisch-orientiert, d.h. sie verfassen keine automatisiertenKomponententests.

6.1.1. Betrachtete Webservices

Im Verlauf dieser Arbeit wurde von den Entwicklern ein Teil des Portals überarbeitetund erweitert. Als Konsequenz waren auch einige Webservices anzupassen, so dassdiese für Tests ausgewählt wurden.

Die betrachteten Webservices sind passiv und rufen nur Daten aus der Geschäftslogikab. Abbildung 6.2 zeigt die Entwicklung der Webservices1, wobei für diese Webser-vices keine Spezifikationen vorliegen. Speziell die Auswahl der Operationen und Para-meter wurde nicht geplant, sondern von den Entwicklern selbst während der Entwick-lung festgelegt.

Als Dokumente zum Ableiten von Testfällen stehen die Servicedokumentation und dieServiceimplementierung als Quellcode zur Verfügung. Weitere Informationen liegennur in „flüssiger“ Form vor und sind gezielt von Mitarbeitern zu erfragen. Im gesamtenVerlauf dieser Arbeit erwies sich die Identifikation von Informationsträgern als schwie-rig, weil oftmals schon die Zuständigkeiten nicht eindeutig geklärt waren. Als Orakel

1Für eine Erklärung der Notation sei auf Kapitel 5 in [Sta06b] verwiesen.

54

6. Fallstudie

Implementierungerstellen

ServicedokumentationQuellcodeWebservice

QuellcodeWebsite

Entwickler

Dokumentationerstellen

Entwickler

WordVisual Studio

Schnittstelleerstellen

Web Container

Web Container

Serviceschnittstelle

Entwickler

Abbildung 6.2.: Entwicklung der eingesetzten Webservices

bei der Überprüfung der Korrektheit von Daten ist die vorhandene Website geeignet2,weil die betrachteten Webservices nur bestehende Funktionalitäten über eine Maschi-ne zu Maschine Schnittstelle anbieten.

Ursprünglich war geplant Teile des Portals serviceorientiert umzusetzen. Aber die Im-plementierung erwies sich als kein Service, weil sie nicht Definition 2.5 entspricht. EineServiceschicht ist mit der Windows Communication Foundation (WCF) [Micb] umge-setzt, jedoch wird nie mit einem Service interagiert. Nach Konsequenz 2.3 wird in ei-ner SOA mit einer bestehenden Instanz interagiert, die Interaktion im vorliegenden Fallgeschah jedoch über ein neu erzeugtes Objekt. Gespräche haben ergeben, dass andieser Stelle eine SOA zum jetzigen Zeitpunkt nicht zweckmäßig ist und daher auchkein Service eingesetzt wird. Stattdessen wird mit herkömmlichen objektorientiertenMitteln ein Facade-Entwurfsmuster [GHJV95] benutzt.

6.1.2. Bisheriges Vorgehen beim Testen der Webservices

Vor dieser Arbeit erfolgte die Testdurchführung nicht unter Einsatz einer Teststrategie.Tester prüften die Webservices eher erforschend ohne konkrete Testfälle. Dabei wirdmit einem manuell bereitgestellten Webservice interagiert. Zur Validierung der Datendiente eine entsprechende Version der Website, die dieselbe Datenbank nutzt.

Wie bereits in Abschnitt 5.2 beschrieben stellt ein in .NET umgesetzter Webserviceeine grafische Benutzerschnittstelle zur Verfügung, so dass ein Tester mit einem Brow-ser jede Operation des Webservices durch Eingabe der Parameter in Textfeldern auf-

2Die Korrektheit der Website kann allerdings nicht angenommen werden, so dass bei Abweichungensowohl der Webservice als auch die Website zu prüfen sind.

55

6. Fallstudie

rufen kann. Als Ergebnis sieht der Tester ein XML-Dokument, das den Rückgabewertder Operation darstellt.

Folglich erlaubt .NET das Testen eines Webservices auch ohne Einsatz von zusätz-lichen Werkzeugen. Dieses Vorgehen sei im Folgenden als manuell bezeichnet, weildie Eingabedaten von einem Tester manuell eingegeben werden und auch die Auswer-tung der Ergebnisse manuell geschieht. Wird ein Werkzeug für die Interaktion mit demWebservice und die Auswertung der Ergebnisse eingesetzt, z.B. ein Unit Test Frame-work mit den Erweiterungen aus Kapitel 5, so heißt dieses Vorgehen automatisch.

6.2. Eine konkrete Teststrategie

6.2.1. Annahmen

Die angestrebte Teststrategie beginnt bei Komponententests, um die Tests zu verein-fachen und unabhängiger zu machen. Ist ein komplexes System involviert, z.B. eineDatenbank, das Dateisystem oder andere Services, so sind immer Kopplungen vor-handen, die das Testen erschweren [TH02]. Es ist oftmals aufwändiger eine Daten-bank durch eine „virtuelle“ neue Datenbank zu ersetzen, als die entsprechende Kom-ponente auszutauschen, die die Datenbank nutzt.

Um praktikabel zu sein, wird angenommen, dass Tests mit einen Unit Test Frame-work geschrieben oder manuell durchgeführt werden. Die vorgestellte Teststrategiewird Abhängigkeiten zur Idee, Technologie und Plattform von SOA haben, sowie zumProjektumfeld. Dabei leiten sich Testaspekte nur aus den genannten drei Ebenen ab,das Projektumfeld definiert die letztendliche Durchführung der Tests.

Mit dem Microsoft .NET Framework werden Applikationen in einer objektorientiertenSprache umgesetzt. Demnach sind auch aus der testgetriebenen Entwicklung [Bec03]bekannte Komponententests einsetzbar. Zur Interaktion mit einem Webservice kommtvorrangig ein Proxy zum Einsatz, aber auch andere Formen der Interaktion sind mög-lich [McC06]. Alle Sichtweisen haben gemeinsam, dass die Rolle eines Servicekonsu-menten eingenommen wird.

6.2.2. Testmatrix und Testszenarien

Kapitel 4 hat bereits Testaspekte für die betrachtete Ausprägung beschrieben. Tabel-le 6.1 zeigt die für das Unternehmen ausgewählte Zuordnung von Testaspekten zurServiceumgebung. Lokale und lokal/entfernte Serviceumgebungen sehen nur Kompo-nententests und Integrationstests vor. Systemtests werden erst in einer entfernt/testServiceumgebung eingesetzt.

56

6. Fallstudie

Nr. lokal lokal/entfernt entfernt/test entfernt/live

1 Funktionalität X

2 Datentransferobjekte X

3 Verifizierung des Deployment X X X

4 Konfigurationen X X

5 Autorisierung und Authentifizierung X

6 Fehlendes Subsystem X X

7 Annahmen an Eingabedaten X

8 Versteckte Grenzen X X

9 Rückwärtskompatibilität X X

10 Interoperabilität X

11 Funktionalität X

Tabelle 6.1.: Zuordnung von Testaspekten zur Serviceumgebung

Die Testmatrix aus Tabelle 6.1 ist durch doppelte horizontale Linien in Bereiche ge-trennt. Jeder Bereich bildet dabei eine Gruppe von zum Teil verwandten Tests:

• Nr. 1: Als Geschäftsentscheidung gilt für Projekte, dass Entwickler ihren Codemit Komponententests zu überprüfen haben. Entsprechend beginnt diese Test-strategie mit solchen Tests in einer lokalen Serviceumgebung unter dem Testa-spekt Funktionalität. Dabei handelt es sich um Komponententests, die aus derobjektorientierten Programmierung schon länger bekannt sind.

• Nr. 2-4: Ein Webservice kann nur eingesetzt werden, wenn sich gültige Objekteübertragen lassen und das Deployment funktionstüchtig ist. Folglich sind Verifi-kationstests für die Datentransferobjekte, das Deployment und alle Konfiguratio-nen durchzuführen. Dies verhindert, dass spätere Tests aufgrund von Fehlern,die ein vorheriger Testaspekt findet, fehlschlagen. Die Automation dieser Testserlaubt schnell eine neue Version der Webservices grundlegend zu prüfen.

• Nr. 5: Der Testaspekt Sicherheit beschränkt sich auf eine funktionale Überprü-fung der Autorisierung und Authentifizierung, weil Kapazitäten im Unternehmenund Projekt begrenzt sind. Jeder Nutzer mit einem Account ist explizit für einenWebservice freizuschalten und erhält ein eigenes Passwort. Die dadurch reali-sierte Absicherung ist automatisiert zu prüfen.

• Nr. 6-8: In der Mitte folgen Negativtests durch das Verhalten bei fehlenden Sub-systemen und die Überprüfung von Eingabedaten. Versteckte Grenzen stelleneinen vereinfachten Integrationstest dar.

57

6. Fallstudie

• Nr. 9-10: Rückwärtskompatibilität und Interoperabilität sind spezielle Eigenschaf-ten in einer SOA.

• Nr. 11: Jeder Webservice bietet Dienste an, die die Servicedokumentation be-schreibt oder eine Spezifikation fordert. Eine Überprüfung gegen diese Doku-mente folgt durch Test der Funktionalität mit Systemsicht.

Einige der in Kapitel 4 vorgestellten Testaspekte sind in der vorgestellten Teststrategiebewusst nicht aufgeführt:

• Webservice Standards werden nicht eingesetzt und sind daher nicht zu testen.

• Last- und Performancetests sind im Rahmen dieser Arbeit nicht betrachtet, weilsie auf bekannten Methoden basieren und keinen Beitrag zu dieser Arbeit leisten.

Ziel bei allen Testaspekten ist mit Komponententests zu arbeiten, um die Tests unab-hängiger zu halten. Tests in der entfernt/test Serviceumgebung sind nicht zwingend zuautomatisieren und können manuell erfolgen. Allgemein sei angemerkt, dass die vor-gestellte Testmatrix nur ein Vorschlag ist, aber ein wichtiges Produkt der Teststrategiedarstellt. Die Testmatrix lässt sich beliebig anpassen, um die Teststrategie in verschie-denen Projekten und Unternehmen zu steuern. Allerdings können alle Artefakte derTeststrategie auch in andere Projekte übernommen werden, die die gleiche Ausprä-gung einer SOA vorweisen.

Die Abarbeitung der Testaspekte erfolgt in einer Reihenfolge wie in Tabelle 6.1 ange-geben von oben nach unten. Die Übergänge sind dabei nicht starr, sondern könnenflexibel bei der Testdurchführung gewählt werden. Die Vorbedingungen der Testsze-narien legen fest, wann ein Testaspekt getestet werden kann. Die Reihenfolge derTestaspekte in der Testmatrix ist nach den folgenden Kriterien bestimmt:

• Während des Projektverlaufs nimmt die Aggressivität beim Testen stetig zu. DieAnordnung der Testaspekte entspricht einem Vorgehen, indem mit bekanntenKomponententests begonnen wird, bevor der Sprung zu einem Service vollzogenwird. Das Testen eines Services beginnt mit Verifikationstests, bevor in der Mitteder Testmatrix Negativtests folgen. Insbesondere ist es nicht sinnvoll mit umfang-reichen Tests zu beginnen, bevor grundlegende Funktionsfähigkeit sichergestelltist.

• Die Zuordnung zur Serviceumgebung beginnt bei einer lokalen Serviceumge-bung und sieht erst später höhere Serviceumgebungen vor, weil dies einer Zu-ordnung zur Teststufe entspricht (niedrige Teststufen sind vor höheren Teststufeneinzusetzen). Die lokale und lokal/entfernte Umgebung eignet sich für Kompo-nententests oder Integrationstests, die entfernt/test Umgebung eignet sich fürSystemtests.

Anhang A ist die Sammlung aller Testszenarien für die entwickelte Teststrategie. DieTestszenarien beziehen sich auf die Testmatrix aus Tabelle 6.1 und basieren auf derVorlage aus Abschnitt 3.3.3.

58

6. Fallstudie

6.3. Anwendung der Teststrategie

6.3.1. Umsetzung

Die Umsetzung der in Abschnitt 6.2 vorgestellten Teststrategie wird im Folgenden auf-gezeigt. Als Grundlage für die Ableitung von Testfällen dienen die in Anhang A gege-benen Testszenarien. Erzeugt wurden die Testfälle für den in Abschnitt 6.1.1 beschrie-benen Webservice. Die Testautomation und alle Komponententests wurden mit demin Kapitel 5 vorgestellten Werkzeug umgesetzt.

Komponententests haben die Eigenschaft oftmals White-Box Analysen zur Erzeugungvon Testfällen einzusetzen. Zusätzlich werden die Tests abgekoppelt von anderen Sys-temen durch den Einsatz von Mocks. Die Trennung von der Datenbank erlaubt nur denService an sich zu testen, unabhängig von bestimmten Daten, d.h. die Erzeugung vonTestfällen wird vereinfacht.

Im Folgenden sei jeder Testaspekt der Testmatrix aus Abschnitt 6.2.2 betrachtet:

• Funktionalität (Nr. 1): Fehlende Testbarkeit erlaubte nur rudimentär die Verfas-sung von herkömmlichen Komponententests. Speziell die Webservice Fassadeund die Datenbankanbindung sind nicht direkt testbar aufgrund von anonymerErzeugung von Objekten und anschließender Benutzung. Auch die Grenzen zwi-schen den einzelnen Schichten sind fließend umgesetzt und die Einführung vonMocks wird erschwert. Die Tests selbst haben noch keinen Bezug zu einer SOA,so dass nicht weiter auf diese eingegangen wird.

• Datentransferobjekte (Nr. 2): In .NET steht der XML-Serialisierer als Klasse zurVerfügung und ist somit explizit nutzbar. Erzeugt man vollständig aufgelöste Ob-jekte für die Eingabe und Ausgabe, ist durch entsprechende Übergabe der Ob-jekte an den XML-Serialisierer prüfbar, ob eine Serialisierung bidirektional mög-lich ist. Der Test führt diese Übersetzung durch und vergleicht das ursprünglichemit dem serialisierten Objekt. Die Überprüfung der Datentransferobjekte erfolgtinsgesamt automatisiert.

• Verifizierung des Deployment (Nr. 3): Die betrachteten Webservices sind nurpassiv, indem sie Daten beziehen. In der lokal/entfernt Serviceumgebung wurdedie Datenbank durch einen Mock ersetzt. Verifikationstests in der entfernt/testund entfernt/live Serviceumgebung sind identisch und in beiden Serviceumge-bungen einsetzbar, wobei ein Systemtest durchgeführt wird. Testfälle leiten sichab über eine Pfadanalyse im Quellcode. Es gilt möglichst viele Pfade durch denWebservice zu nehmen und alle Bibliotheken bzw. Subsysteme anzusprechen.Alle Tests zur Verifizierung sind automatisiert und erlauben schnell festzustellen,ob sich komplexere Tests am Testobjekt lohnen.

• Konfiguration (Nr. 4): Die zu testenden Webservices setzen Konfigurationen ein,um das Logging von Informationen im Fehlerfall und den Datenbankzugriff maß-zuschneidern.

Effektiv lässt sich die Korrektheit der Konfiguration für das Logging zunächst in ei-

59

6. Fallstudie

ner lokal/entfernten Serviceumgebung prüfen. Durch die Kombination von Mocksund Testdaten wurden Pfade so durch den Webservice gelegt, dass das Loggingangesprochen und die Konfiguration vollständig genutzt wird. In der lokal/ent-fernt Serviceumgebung hat der Tester vollständige Kontrolle über die Konfigu-ration und wird diese so anpassen, dass ein automatisierter Test möglich wird.Grundsätzlich wurde in der lokal/entfernt Serviceumgebung ausschließlich dieKorrektheit der Funktionalität geprüft. In der entfernt/test Serviceumgebung än-dert sich nur das Ausgabeziel des Logging und es ist prüfen, ob der Effekt über-haupt eintritt. In der entfernt/test Serviceumgebung ist dieser Test nur bedingtautomatisierbar, weil kein äußerer Zugriff auf das System möglich ist.

Bei der Überprüfung der Datenbankkonfiguration gilt es in der entfernt/test Ser-viceumgebung Pfade durch den Service zu finden, so dass mit den verschiede-nen Datenbanken interagiert wird.

• Autorisierung und Authentifizierung (Nr. 5): Mittels automatisierten Tests ist zuprüfen, ob ein gültiger Benutzer den Webservice nutzen kann und auch nur fürihn ersichtliche Daten erhält. Im Anschluss wurden Negativtests durchgeführt,um den Webservice anzugreifen.

• Fehlendes Subsystem (Nr. 6): Als einzige Subsysteme wurden Datenbanken ein-gesetzt. Ein entsprechender Test verhindert den Zugriff des Webservices aufdie Datenbank und ist manuell durchzuführen. Durchgeführt wurde er in einerlokal/entfernt Serviceumgebung und blockieren entsprechenden Netzwerkver-kehrs.

• Annahmen an Eingabedaten (Nr. 7): Die Ableitung von Testfällen erfordert dieParameter jeder Operation zu analysieren. Tabelle 6.2 stellt einen Ausschnitt derdurchgeführten Analyse dar.

Webservice Operation Parameter TypAnnahmen an Eingaben

Explizit Implizit

Statistik

GibTäglicheDatenID Integer > 0

Datum String Konvertierbar zuDatum, <= heute

GibNeueDatenModus Int 0 oder 1

Typ String Durch Kommagetrennte Listeder Zahlen 1, 2oder 3

Tabelle 6.2.: Analyse zur Ermittlung von ungültigen und gültigen Eingaben

Annahmen an Eingabedaten werden in explizite und implizite Annahmen unter-

60

6. Fallstudie

teilt. Explizite Annahmen sind in Dokumenten festgehalten, implizite Annahmenergeben sich aus dem Projektumfeld bzw. dem Parameter heraus und wurdenbei der Implementierung von den Entwicklern angenommen. Implizite Annah-men erhält man nur durch White-Box Analysen oder durch Gespräche mit denEntwicklern.

Die durchgeführte Analyse erlaubt für jeden Parameter, selbst bei komplexenObjekten, Äquivalenzklassen für ungültige und gültige Werte aufzustellen. An-schließend sind aus den Klassen Repräsentanten auszuwählen, so dass eineMatrix entsteht, die in einem automatisierten Test eingesetzt wird. Das Unit TestFramework der Visual Studio Team Edition erlaubt die Realisierung von daten-getriebenen Tests [Mica], die direkt erstellte Matrizen nutzen. Es ist nur ein Ope-rationsaufruf im Test und ein Adapter zwischen diesem Aufruf und der Matrix zuschreiben. Neben einer Durchführung dieses Tests für die ungültigen Daten, sindals Gegenprobe auch ausgewählte gültige Werte zu nutzen.

Im Rahmen der Tests wurden zusätzliche Testpunkte im Logging so konfiguriert,dass resultierende Fehler durch ungültige Daten sichtbar werden. Dies erlaubtnicht nur festzustellen welche Eingabedaten ungeprüft verarbeitet werden, son-dern auch welche Konsequenzen entstehen können.

• Versteckte Grenzen (Nr. 8): Zur Ableitung von Testfällen ist zunächst eine Analy-se durchzuführen, die Grenzen und potentielle Problemfälle identifiziert. Tabelle6.3 zeigt diese Analyse, wobei Grenzen schon zwischen Schichten angenom-men seien3.

Zwischen den einzelnen Grenzen wird über eine ’<’-, ’=’ oder ’>’-Relation ange-geben, ob sich der Datenraum vergrößert, gleich bleibt oder verkleinert. JedeReduktion, repräsentiert durch ’>’, kann zu Problemen bei der Verarbeitung vonDaten führen. Denn bei einer Zeichenkette werden z.B. nur die ersten x Zeichenbetrachtet, wobei x die durch den Typ festgelegte Länge ist.

OperationService/DTO Parameter/BO Datenbank/DAO Datenbank/Real

Name Typ Typ Typ Typ

GibAusgabenID Integer = Integer = Integer = Integer

SubID String = String > VarChar(80) < VarChar(4000)

Tabelle 6.3.: Auffinden von versteckten Grenzen

In Tabelle 6.3 sind für den Type Testdaten abzuleiten, die mit Zeichenketten ar-beiten, die länger als 80 Zeichen sind. Im Besonderen ist bei den getestetenWebservices die längste mögliche Zeichenkette durch Einsatz von „Wildcards“81 Zeichen lang und führt zu einem Fehler. Im Falle der ID handelt es sich um

3Zwischen zwei Grenzen kommt es zu Übergängen zwischen verschiedenen Objekten, mit denen ineiner Schicht gearbeitet wird. Konkret sind dies Data Transfer Objects (DTO), Business Objects (BO)und Data Access Objects (DAO).

61

6. Fallstudie

einen 32-Bit Integer, der denselben Wertebereich auf allen Schichten beschreibt- d.h. es kommt zu keiner Reduktion im Datenraum.

• Rückwärtskompatibilität (Nr. 9): Alle automatisierten Tests, die mit einem Proxyarbeiten, werden bei diesem Testaspekt erneut eingesetzt. Es gilt einen Proxyfür den aktuellen Service, der im produktiven Einsatz ist, zu erstellen. Dabei istder Endpunkt des Proxys so zu ändern, dass er auf den sich in der Entwicklungbefindlichen Webservice zeigt. Wird jeder Test mit diesem Proxy ausgeführt, darfsich das Verhalten der Tests nicht ändern.

• Interoperabilität (Nr. 10): WS-I Konformität ist mit Werkzeugen von [Theb] prüf-bar. Beim Test wurde Java als potentielle Plattform eingesetzt. Im Allgemeinensind die vorhandenen Webservices sehr einfach gehalten, so dass umfangreicheTests für diesen Testaspekt nicht möglich waren.

• Funktionalität (Nr. 11): Durchführung von Tests gegen eine Servicedokumen-tation, die für jede Operation die Parameter und den Effekt beschreibt. Fehlerbetreffen daher entweder die Implementierung oder die Dokumentation.

Geprüft wird z.B. ob die Daten richtige Zeiträume umfassen, vom Service durch-geführte Berechnungen korrekt sind oder die Effekte durch die Parameter ein-treten. Zur Überprüfung der Korrektheit der Daten kann die bestehende Websitegenutzt werden.

6.3.2. Gefundene Fehler

Die in Abschnitt 6.3.1 vorgestellte Umsetzung der Teststrategie führte zu Testfällen,die im Verlauf dieser Arbeit mehrfach ausgeführt wurden. Hierbei sind Fehler sichtbargeworden, von denen eine Auswahl vorgestellt wird. Dabei beschränkt sich die Aus-wahl auf Fehler, die einen Beitrag zu dieser Arbeit leisten. Einige Fehler wurden nochim Rahmen dieser Arbeit von den Entwicklern behoben.

Verifikationstests für ein Deployment erlaubten nach jeder Änderung direkt das De-ployment selbst und manuelle Bereitstellungen zu verifizieren. Tabelle 6.4 zeigt eineAuswahl von Fehlern, die schon durch diese sehr einfachen Tests gefunden wurden.

62

6. Fallstudie

Verifizierungdes

Deploym

ent

Ein Datentransferobjekt wurde mittels Vererbung erweitert. Die Sichtbarkeitder neuen Klasse wurde beschränkt, so dass der XML-Serialisierer nicht aufdiese neue Klasse zugreifen konnte. Der Aufruf der zugehörigen Operationlieferte somit einen Fehler.

Ein durch Vererbung von einem Datentransferobjekt eingefügter Adapterkonnte nicht serialisiert werden. Abbildung 6.3 zeigt die entstandene Verer-bungshierarchie. Dem XML-Serialisierer standen nicht alle benötigten Infor-mationen zur Serialisierung des RecordAdapter zur Verfügung. Zur Lösungdieses Problems wurde die Struktur geändert.

Zwei Operationen haben nie Werte oder Fehlermeldungen geliefert. Vermut-liche Ursache waren fehlende Zugriffsrechte auf benutzte Datenbanken, weildieselben Tests unter Einsatz von Mocks für die Datenzugriffsschicht nichtfehlschlugen.

Tabelle 6.4.: Fehler bei der Verifizierung des Deployment

Record

+LoadRecord()

RecordAdapter

+Load() : Record

Webservice

public Record Load() { RecordAdapter adapter = new RecordAdapter(); adapter.LoadRecord(); return (Record) adapter;}

Abbildung 6.3.: Fehler aufgrund eines Adapters

Tabelle 6.5 zeigt exemplarisch Fehler, die beim Testen der Konfigurationen gefundenwurden. Konfigurations- und Verifikationstests haben gezeigt, dass sie sehr grundle-gende Eigenschaften in einem Service testen. Schlägt ein Testfall fehl, so ist oftmalsals Konsequenz eine Operation nicht nutzbar. Fehler müssen erst behoben werden,bevor komplexere Tests durchführbar werden.

Fehlt ein Subsystem, so reagiert der Webservice mit einer unangemessenen, detail-lierten und sehr technischen Fehlermeldung. Letztendlich wird direkt die vom Systemgenerierte Ausnahme als Fehlermeldung verschickt. Bei der Analyse von verstecktenGrenzen führte der Datenverlust bei zwei Parametern zu fehlerhaftem Verhalten beider Selektion von Daten. Speziell wurden Zeichenketten abgeschnitten und dadurchfalsche Werte ausgewählt.

Durch die Kenntnis von Äquivalenzklassen für gültige und ungültige Eingaben, ließensich Repräsentanten finden, die der Webservice nicht korrekt als ungültig filterte. Diese

63

6. Fallstudie

Konfigurationen

Zum Logging und Tracking von Ausnahmen wird eine Bibliothek eingesetzt,die eine Konfiguration voraussetzt. Das XML-Dokument war dabei nicht wohl-geformt, indem einige Elemente mehrfach als Kind definiert waren.

Es fehlte eine Bibliothek beim Ansprechen des eben erwähnten Loggings inder entfernt/test Serviceumgebung. Derselbe Test lief in der lokal/entfernt Ser-viceumgebung ohne Fehler.

Tabelle 6.5.: Fehler in Konfigurationen

ungültigen Werte wurden intern weiterverarbeitet und führten z.B. zu falschen Indizes,arithmetischen Überläufen oder null-Objekten. Der Einsatz von Positivtests als Ge-genprobe bei der Überprüfung von Eingabedaten, zeigte Inkonsistenzen gegenüberder Servicedokumentation auf.

Aus der Servicedokumentation abgeleitete Testfälle zur Überprüfung der Funktiona-lität offenbarten fehlerhaftes Verhalten des Services. Auch bei diesen Tests wurdenInkonsistenzen zwischen Service und Servicedokumentation festgestellt.

Bei den Testaspekten Datentransferobjekte, Autorisierung und Authentifizierung, Rück-wärtskompatibilität und Interoperabilität wurden keine Fehler gefunden.

6.4. Lektionen und Bewertung

Die Durchführung dieser Fallstudie hat nicht nur Fehler in den Webservices gefunden,sondern auch Probleme bei der Durchführung aufgezeigt. Diese Probleme seien inunternehmensspezifischen und allgemeinen Lektionen dargestellt.

Unternehmensspezifische Lektionen:

• Der Einsatz von Mocks zur Ersetzung der Datenbank erleichterte viele Tests.Eine hohe Abhängigkeit von der Datenbank erschwert die Überprüfung der Ge-schäftslogik, weil Testdaten geschickt auszuwählen sind. D.h. die Testdaten müs-sen die Geschäftslogik wie gewünscht nutzen und zur Testautomation über derZeit konstant sein.

• Das Verfassen von Komponententests muss erlernt werden. Nicht jeder Entwick-ler ist sofort in der Lage gute Tests für seinen Code zu schreiben. Insbesonderedas testbare Programmieren erfordert einen anderen Programmierstil, den sichjeder Entwickler zunächst aneignen muss.

• Den Webservices wird noch nicht soviel Aufmerksamkeit gewidmet wie der Web-site. Dennoch setzen Kunden die Webservices ein und müssen sich auf derenKorrektheit verlassen.

Allgemeine Lektionen:

• Der Einsatz von harten Mocks, die Code anhand von Methoden tauschen, er-

64

6. Fallstudie

fordert ein gewisses Maß an Testbarkeit. Ist viel Logik in einer Methode ohneTrennung und Zugriff auf andere Komponenten realisiert, so wird der Austauschvon Methoden erschwert.

• Fehler, die durch Abarbeitung der Matrix früh gefunden werden, zeigen nicht test-würdige oder testbare Operationen. Insbesondere die Verifizierung des Deploy-ment stellt dies schnell durch ihren einfachen Charakter fest. Gefundene Fehlermüssen erst behoben werden, bevor weitere Tests möglich sind.

• Die Automatisierung von Tests wird schwerer, wenn bestimmte Effekte nur an-hand von externen Systemen sichtbar werden. So erzeugt das Logging beispiels-weise direkt Dateien oder E-Mails, so dass anhand derer zu überprüfen ist, obeine Information festgehalten wurde.

• Unter Einsatz des Werkzeugs aus Kapitel 5 ist es möglich mit Servicesicht zutesten, ohne das ein bereitgestellter Service notwendig ist. Im Test ist nur dieServiceimplementierung notwendig.

• Nicht jeder Tester und Entwickler ist mit den Fallstricken einer SOA vertraut.Durch Testaspekte werden potentielle Probleme offen gelegt, die unter Anwen-dung von Testmethoden und Testszenarien gezielt gesucht werden. Eine Test-strategie als definierender Rahmen hilft die Qualität von Services allgemein zumessen.

Die in Abschnitt 6.3.2 beschriebenen Fehler haben die Qualität der Webservices ermit-telt. Diese Informationen können dem Unternehmen helfen die Qualität ihrer Webser-vices gezielt zu verbessern. Für zukünftige Projekte steht bereits eine praktikable Test-strategie zur Verfügung.


In diesem Kapitel wurde für die Webservices eines Unternehmens eine Teststrategienach Kapitel 3 unter Bezug auf die Testaspekte aus Kapitel 4 entwickelt.

Die Umsetzung der Teststrategie erfolgte unter Einsatz von Testszenarien, die im An-hang A zu finden sind. Für jeden Testaspekt ist die Vorgehensweise beschrieben unddie Durchführung lehnt sich an das zugehörige Testszenario an. Die Realisierung derTests erfolgte größtenteils mit dem in Kapitel 5 vorgestellten Werkzeug.

Im nächsten Kapitel wird kritisch auf diese Arbeit zurückgeblickt. Speziell die Erfahrun-gen aus der Fallstudie sind wertvoll, weil alle in dieser Arbeit vorgestellten Verfahrenund Konzepte zum Einsatz kamen.

65

7. Kritische Würdigung

In der Fallstudie in Kapitel 6 wurden alle in dieser Arbeit vorgestellten Konzepte undWerkzeuge konkret eingesetzt. Dadurch haben sich bestimmte Stärken und Schwä-chen herauskristallisiert, die in den folgenden Abschnitten gezielt betrachtet werden.

7.1. Kritischer Rückblick auf den Erarbeitungsprozess

Diese Arbeit wurde vor dem Hintergrund erstellt dem in Kapitel 6 genannten Unterneh-men eine Teststrategie und eine mögliche Umsetzung für SOA zu liefern. Die vorge-stellten Ergebnisse sind dennoch allgemein nutzbar und insbesondere unter Kenntnisder Vorgehensweise aus Kapitel 3 an individuelle Gegebenheiten anpassbar.

Die Erarbeitung dieser Arbeit begann durch eine gezielte Analyse des Unternehmensund der zur Verfügung gestellten Services. Dabei haben sich die folgenden Problemeergeben:

• Das ursprüngliche für Tests ausgewählte Projekt war nicht serviceorientiert um-gesetzt. Auch wenn alle Klassen notwendige Metainformationen enthielten, fehl-te eine nach Konsequenz 2.4 notwendige Bereitstellung. D.h. die Klassen habennie den Übergang zu einem Service vollzogen und das Projekt war für dieseArbeit ungeeignet.

• Die Unterschiede zwischen einem Webservice und einer SOA sind nicht jedemgleichermaßen bekannt. Eine SOA dient zur Strukturierung von Lösungen, wobeiein Webservice eine bestimmte Technologie ist, mit der sich diese Strukturierungumsetzen lässt.

Services bilden als aktive Einheiten die Wurzel einer SOA und sind bei Tests beson-ders von Interesse.

7.2. Stärken und Schwächen einer Teststrategie

Aus der Trennung zwischen Service und Serviceimplementierung folgt, dass ein Ser-vice nur einen definierten Rahmen für umgesetzte Logik zur Verfügung stellt. Es er-weist sich als schwierig festzulegen wo Funktionalität zu testen ist. Betrachtet man nurdie Serviceimplementierung, sind alle für die eingesetzte Plattform bekannten Metho-den und Verfahren einsetzbar. Testet man einen Service, so nimmt man die Sichtweise

66


eines Servicekonsumenten ein und muss gegen etwas testen, das auch der Service-konsument kennt bzw. ihm zur Verfügung steht: die Servicedokumentation.

Die in Kapitel 4 vorgestellten Testaspekte sind nur als Auswahl anzusehen. Besondersdie Ableitung von Testaspekten für eine bestimmte Ebene erweist sich als schwierig,weil oftmals die Ebenen untereinander verwoben sind. Z.B. wird die Trennung zwi-schen Webservices und SOA schon in der Literatur häufig als fließend angenommen.

Komponententests für Services nach Abschnitt 3.4 weisen die folgende Schwächeauf:

• Die Realisierung von Serviceumgebungen und weichen bzw. harten Mocks setztWerkzeuge voraus, die nicht immer existieren.

Die Stärken einer Teststrategie nach Kapitel 3 sind:

• Im herkömmlichen Sinne testet man mit einem Komponententest eine Kompo-nente in Isolation. Services bieten Servicekonsumenten die Logik der Serviceim-plementierung an. Durch die verschiedenen Ebenen einer SOA entstehen jedochpotentielle Probleme, die erst bei Interaktion mit einem Service getestet werdenkönnen.

Mocks in einem Service einzusetzen, erlaubt Tests zu vereinfachen und unab-hängig gegenüber Daten zu machen. Automatisierte Tests sind nicht mehr ab-hängig von der Datenbank und es ist nicht mehr nötig nach bzw. vor jedem Test-lauf einen definierten Zustand herzustellen. Als Tester gelingt es mehr Kontrollezu erhalten, so dass gezielter und einfacher getestet werden kann.

• Durch die Findung von Testaspekten werden nur potentielle Probleme gesucht,die überhaupt auftreten können und von Interesse sind. Die Testmatrix zur Zuord-nung der Serviceumgebung trifft gezielt eine Auswahl und wird zu einem über-sichtlichen und wichtigen Produkt.

• Gefundene Testaspekte, die Testmatrix und Testszenarien lassen sich in Projek-ten mit gleicher Ausprägung wieder verwenden.

7.3. Stärken und Schwächen der entwickeltenErweiterungen

Der Einsatz der entwickelten Erweiterungen zeigte in der Fallstudie die folgendenSchwächen auf:

• Das Werkzeug ist nicht nur an eine Technologie gebunden, sondern auch aneine Plattform und Sprache. Es ist dadurch in allen drei Ebenen abhängig undkann nur in diesem beschränkten Rahmen eingesetzt werden.

• Im Werkzeug wird der Build schnell zum Flaschenhals, weil oftmals die Projektenicht mehr klein sind und die Erzeugung des Deployment lange dauert. Dadurchwird oftmals eine performante und schnelle Ausführung verhindert.

67


• Der Einsatz von harten oder weichen Mocks macht jeden Test anfällig dafür,dass er bei Änderungen im Code nicht mehr funktioniert, weil die Serviceimple-mentierung zur Laufzeit modifiziert wird. In den vorgestellten Erweiterungen wirdman nicht zur Kompilierzeit über die Funktionstüchtigkeit des Tests informiert,sondern erst bei Ausführung des Tests.

• Das eingesetzte Werkzeug bestimmt oftmals, ob die Tests wieder verwendbarsind, wenn sich die Serviceimplementierung ändert, aber die Serviceschnittstellegleich bleibt. Setzt man auf Werkzeuge, die Services immer als abgeschlosseneEinheit betrachten und nur mit Serviceschnittstellen arbeiten, so lassen sich un-terschiedliche Implementierungen mit denselben Tests testen. Testfälle, die unterEinsatz der Erweiterungen erstellt werden, sind abhängig von der Serviceimple-mentierung.

• Bei der Realisierung von Komponententests sind die Tests und die Applikati-on oftmals getrennt. Jede Änderung, die ein Test innerhalb der Applikation vor-nimmt, wird von außen vollzogen. Der Einsatz der Erweiterungen hingegen än-dert die Applikation, genauer die Serviceimplementierung. Werkzeuge, die beider Erstellung von Mocks unterstützen, müssen Teil des Services sein und sinddaher nicht direkt anwendbar. Im Allgemeinen müssen sehr viele Variablen in ei-nem Projekt änderbar sein, um z.B. dieselbe Mächtigkeit bei der Erstellung vonMocks zu ermöglichen.

• Tests unter Einsatz eines Proxy erlauben nicht mit einer allgemeingültigen Sichtzu testen. Man verlässt nicht die ursprüngliche Plattform, so dass durch denTestaspekt Interoperabilität Fehler gesondert zu identifizieren sind.

• Die Messung von Testabdeckungen ist nicht möglich, weil das zu verfolgendeObjekt entfernt liegt. Der Test agiert wie ein Servicekonsument und hat mitunterkeinen Zugriff auf den eingesetzten Container.

Der Einsatz der Erweiterungen bietet jedoch auch Vorteile, die Stärken:

• Testfälle für Webservices lassen sich einfach mit bekannten Mitteln erstellen.

• Durch die Beschreibung eines Mocks nahe am Testfall selbst, ist sofort ersicht-lich, was genau getestet wird. Die Annotationen weisen jede Methode, die einenTestfall beschreibt, eindeutig aus.

• Das Werkzeug verringert die Anforderungen an Testbarkeit, indem es durch har-te Mocks das direkte Austauschen von Code ermöglicht. Allerdings ist der Ein-satz von harten Mocks nur bei Software mit einem Deployment praktisch möglich,weil sonst alle Informationen schon zu Kompilierzeit vorliegen müssen.

7.4. Kritischer Rückblick auf die Fallstudie

Die in Kapitel 6 konkret vorgestellte Teststrategie hat Folgendes aufgezeigt:

• Datentransferobjekte zu verifizieren ist sehr aufwendig, weil alle Objekte vollstän-

68


dig aufzulösen sind. Hier sind nach Möglichkeit Werkzeuge einzusetzen, die au-tomatisiert eine Überprüfung vornehmen. Letztendlich sind erstellte Tests immeranzupassen, wenn sich die Parameter einer Operation ändern, so dass Tests fürDatentransferobjekte wenig lohnenswert sind. Nur wenn Änderungen auftreten,können sie später Fehler finden und erfordern Änderungen an den Tests. DerEinsatz von Reflektionen wäre ebenfalls sinnvoll, um die Erzeugung der Objektezu automatisieren.

• Auch wenn die Tests für Rückwärtskompatibilität und Interoperabilität keine Feh-ler gefunden haben, wäre es ein Trugschluss diese Testaspekte bei zukünftigenTests zu ignorieren. Setzt man z.B. Erweiterungen ein, die zusätzliche Informa-tionen im SOAP-Header erfordern, kann sich das Verhalten bezüglich der zweiTestaspekte verändern.

• Das Testen von Funktionalitäten in einer entfernt/test Umgebung erschwert dieTestautomation. Jeder Test ist abhängig von allen Subsystemen, so dass sichdie Ableitung von Testdaten als schwierig erweist.

Liegen für ein Testobjekt keine oder nur wenig Artefakte vor, so lässt sich oftmals beiden Diensten, die ein Service anbietet, kein „Soll“ bestimmen. Es fehlt eine Referenz,die das Verhalten des Services allgemein beschreibt.

69

8. Verwandte Arbeiten

8.1. Andere Ansätze und Werkzeuge

In [Par06] wird eine Vorgehensweise zum Testen von Webservices vorgestellt, die einVerwaltungswerkzeug für Quellcode und einen täglichen Build-Prozess voraussetzt.Während des täglichen Build-Prozess ist ein Webservice automatisch in einer wohldefinierten entfernt/test Umgebung bereitzustellen und alle Daten in einen definiertenZustand zu überführen.

Die Reihenfolge bei der Erstellung von Testfällen sieht zunächst Komponententestsmit JUnit vor, bevor der Webservice zu testen ist. Dabei ist funktional jede Operationzu testen. Im Unterschied zum Verständnis von Komponententests in dieser Arbeit,wird in [Par06] ein Test, der nur eine Operation betrifft als Komponententest bezeich-net. Werden mehrere Operationen in einem Test genutzt, so wird dies als Szenariotestbezeichnet. Diese Arbeit betrachtet bei Komponententests einen individuellen Service,der nur während eines bestimmten Testlaufs mit einer angepassten Serviceimplemen-tierung existiert. Die Anzahl von genutzten Operationen ist dabei unerheblich.

Abbildung 8.1.: In-Container Tests mit Cactus

Cactus [Thea] ist ein Werkzeug, das so genannte In-Container Tests ermöglicht. Da-bei wird eine Enterprise Komponente zusammen mit einem Test in einem Containerbereitgestellt und dieser Test wird entfernt über einen Proxy aufgerufen. Ziel ist esSoftware so zu testen, dass man erweiterte Funktionalitäten und Eigenschaften desContainers nutzen kann. Abbildung 8.1 stellt die Arbeitweise von Cactus dar. Die Num-

70


mern geben die Reihenfolge der Aktivitäten bei der Ausführung an. Die Aktivitäten 1,4 und 8 enthalten Methoden zur Initialisierung und zum Aufräumen des Tests.

8.2. Testaspekte

Viele Veröffentlichungen beschreiben oftmals die Testaspekte, die es in einer SOA zutesten gilt. Im Folgenden seien zwei Veröffentlichungen kurz vorgestellt:

• In [YSA05] wird der Testaspekt Sicherheit speziell für Webservices betrachtet.Dabei werden mögliche Angriffe aus bekannten Angriffszenarien für Webappli-kationen abgeleitet. Besonders durch die Bereitstellung in einem Web Contai-ner, der den Zugriff auf eine Datenbank oder das Dateisystem ermöglicht, sindWebservices sehr mit Webapplikationen verwandt. So kann auch ein Webser-vice anfällig sein gegenüber Cross-site scripting, SQL injections, Buffer over-flows, . . . Auch das SOA-Dreieck ist verwundbar, wenn ein Angreifer z.B. gezielteinen Denial-of-Service Angriff auf das Serviceregister durchführt.

• [App07] gibt eine Übersicht über Testaspekte, die es in einer SOA zu testen gilt.Unter Anderem werden Rückwärtskompatibilität, Interoperabilität und Sicherheitkurz beschrieben. Die Sammlung von Testaspekten aus Kapitel 4 hat diese Ver-öffentlichung bereits berücksichtigt.

8.3. Testen von Kompositionen

Nach Konsequenz 2.1 ist eine Komposition ein Verbund von Services, d.h. in einerServiceimplementierung werden andere Services genutzt. Letztendlich wird eine Kom-position durch einen äußeren Service repräsentiert. Daher ist eine nach Kapitel 3 ent-wickelte Teststrategie auch bei Kompositionen anwendbar, wobei das Testobjekt deräußere Service ist.

Bei Einsatz einer Komposition ist die Plattform zu vernachlässigen, weil sie durch dieTechnologie vollständig überschattet wird. D.h. alle Werkzeuge arbeiten nur mit derTechnologie ohne Berücksichtigung der Plattform. Abbildung 8.2 illustriert eine ver-breitete Ausprägung einer SOA bei Kompositionen, die Webservices als Technologieeinsetzt.

Im Falle einer Komposition wird ein Service als Komponente vererbt. Die Serviceim-plementierung muss nicht geändert werden, weil andere Services kein Bestandteil derServiceimplementierung sind. Für die Technologie Webservices befinden sich einigeWerkzeuge auf dem Markt, mit denen ein Tester Komponententests für Kompositionenrealisieren kann:

• BPELUnit [May06]: Ein Werkzeug, das speziell Komponententests für in BPELrealisierte Geschäftsprozesse ermöglicht. Webservices können durch Mocks er-setzt werden, so dass nur der in BPEL realisierte Geschäftsprozess getestet

71


Abbildung 8.2.: Eine verbreitete Ausprägung einer SOA bei Kompositionen

wird.

• soapUI [MRHB]: Ein Werkzeug zum Testen von Webservices, dass die Erstel-lung von Mocks für Kompositionen ermöglicht.

Alle vorgestellten Werkzeuge haben gemeinsam, dass unter Kenntnis der Service-schnittstelle eine Serviceimplementierung erstellt werden kann. Diese neue Serviceim-plementierung wird in einem eigenen Container bereitgestellt und steht als Mock zurVerfügung. Dem äußeren Service ist nur der Endpunkt des Mocks bekannt zu machen.

Im Falle einer Komposition können die Serviceanbieter variieren, d.h. jeder Servicean-bieter bzw. -entwickler muss die Qualität seiner Services selbst sicherstellen. Für eineKomposition ist unter Einsatz von Mocks zu testen, ob die Einbindung eines Serviceserfolgreich ist.

72

9. Zusammenfassung und Ausblick

9.1. Rückblick

Services sind die aktiven und individuellen Einheiten in einer SOA. Jeder Service bie-tet Dienste an, die ein Servicekonsument nutzt. Dabei verlässt sich der Servicekonsu-ment auf den Service, so dass Tests unabdingbar werden. Speziell das Umfeld in demletztendlich ein Service eingesetzt wird, ist nicht immer bekannt.

In dieser Arbeit wird eine Teststrategie für eine SOA über drei Artefakte beschrieben:

• Ein Katalog von Testaspekten, in dem potentielle Probleme und ein Vorgehenzur Identifikation dieser Probleme beschrieben werden.

• Eine Testmatrix, die Testaspekte einer Serviceumgebung zuordnet.

• Testszenarien, die detailliert das Vorgehen zur Identifikation eines Testaspektsbeschreiben.

Für eine SOA leiten sich nach Abschnitt 3.2.1 Testaspekte aus drei verschiedenenEbenen ab: Idee, Technologie und Plattform. Die Kenntnis von konkreten Testaspektenerlaubt unter Einbezug des Projektumfelds eine Testmatrix aufzustellen. Abschließendsieht das in Abschnitt 3.3.2 beschriebene Vorgehen zur Findung einer Teststrategie dieFormulierung von Testszenarien vor.

Moderne Entwicklungsumgebungen und Plattformen für Unternehmensanwendungenverbergen die Komplexität von Webservices bei der Entwicklung. Ein Entwickler schreibteine normale Klasse, die gezielt annotiert, direkt als Webservice nutzbar ist. Folglichsind Kenntnisse in der XML, WSDL, . . . nicht mehr notwendig. Dennoch ist ein Webser-vice anfällig gegenüber den in Kapitel 4 genannten Testaspekten, die als verborgeneFehlerquellen entstehen.

Gilt es eine Serviceimplementierung zu testen, so sind oftmals bekannte Verfahrenund Methoden anwendbar. Betrachtet man jedoch einen Service, so versagen vieleKonzepte, weil ein Service durch die Bereitstellung einer Serviceimplementierung ent-steht. Dadurch liegt ein Service entfernt und kann während eines Tests nicht mehrmanipuliert werden.

Diese Arbeit hat in Abschnitt 3.4.3 im Rahmen von Komponententests ein Vorgehenbeschrieben, dass gezielt eine Serviceimplementierung manipuliert. Durch eine sichanschließende Bereitstellung entsteht ein einzigartiger Service, so dass gezielt Tei-le dieses Service isoliert getestet werden können. In Kapitel 5 wurde ein Werkzeugvorgestellt, das den Einsatz von harten und weichen Mocks in einem Webservice er-möglicht.

73


Abschließend betrachtete diese Arbeit die Webservices eines Unternehmens unterAnwendung einer zuvor nach Kapitel 3 ermittelten Teststrategie. Als Grundlage dientendie Testaspekte aus Kapitel 4 und Testfälle wurden mit dem Werkzeug aus Kapitel 5formuliert.

9.2. Ausblick

Kapitel 3 stellt das Vorgehen zur Findung einer Teststrategie zunächst ausschließlichfür SOA vor. Dennoch sind die Artefakte allgemeingültig einsetzbar, aber auch leichtanpassbar an individuelle Gegebenheiten, z.B.:

• Die Testmatrix ist auch bei Tests für Webapplikationen einsetzbar.

• Testszenarien können in anderen Applikationen eingesetzt werden, um die Ab-leitung von Testfällen detailliert zu beschreiben. Dazu ist evtl. die präsentierteVorlage aus Abschnitt 3.3.3 individuell anzupassen.

Nach Abschnitt 3.2.1 kann jede Ebene einer SOA verschiedene Ausprägungen auf-weisen. Auch wenn in dieser Arbeit für die Idee und Technologie keine Alternativenangegeben wurden, so kann deren Existenz nicht ausgeschlossen werden. Im Allge-meinen entsteht durch die Ableitung von Testaspekten für verschiedene Ausprägun-gen ein Katalog, aus dem man sich bei der Definition einer Teststrategie frei bedienenkann. Neuen Testaspekten sind dabei keine Grenzen gesetzt, denn selbst die Samm-lung aus Kapitel 4 ist nur als Auswahl zu betrachten.

Die Erweiterungen lassen sich vielfältig zur Manipulation eines Deployment erweitern.Bisher ist es nur möglich Methoden und Dateien auszutauschen, aber eine Serviceim-plementierung setzt sich aus sehr viel mehr Einheiten zusammen. Vielleicht gelingt essogar den Austausch durch Mocks in die Entwicklungsumgebung zu integrieren, sodass eine einfachere Verwaltung des Deployment entsteht.

Services erben nach Abschnitt 3.4.2 die Komponente durch die zugrunde liegendeImplementierung. In-Container Tests, wie sie Cactus nach Abschnitt 8.1 durchführtsind auch für Services sinnvoll. Vielmehr aber wäre eine Kombination von Ansätzeninteressant:

• Abschnitt 5.6 hat aufgezeigt, dass eine Steuerungseinheit zur Manipulation einesbestimmten Service praktisch nicht umsetzbar ist. Gelingt es für einen bestimm-ten Endpunkt einen Service anzubieten, auf den die Steuereinheit Zugriff hat, soist keine Änderung im Quellcode der zugehörigen Serviceimplementierung mehrnötig. Es muss nur ein spezielles Deployment bestehend aus Steuereinheit undService hergestellt werden.

• Die Manipulation eines Services durch eine Steuereinheit erfolgt durch das Ein-fügen von Mock-Objekten zur Laufzeit. Dazu ist ähnlich wie bei bekannten Werk-zeugen (siehe z.B. [FMP+]) eine Fabrik für Mock-Objekte anzubieten.

Der Einsatz einer Steuereinheit ändert nicht die Serviceimplementierung, sondern nurdas Deployment. Dies erlaubt z.B. in .NET oder Java EE den Einsatz von Komponen-

74


tentests, wie sie aus der objektorientierten Programmierung bekannt sind.

9.3. Fazit

Diese Arbeit hat ein Vorgehen aufgezeigt, mit dem sich in jedem Projekt eine Test-strategie für eine SOA ermitteln lässt. Die Ergebnisse einer einmaligen Analyse sindin ähnlichen Projekten wieder verwendbar. Die im Rahmen der Fallstudie vorgeschla-gene Teststrategie kann als Grundlage für eine eigene Teststrategie dienen. DurchKenntnis der eingeführten Begriffe und Artefakte ist es möglich eine Teststrategie andie eigenen Bedürfnisse anzupassen.

Diese Arbeit stellt für die Microsoft Visual Studio Team Edition ein vollfunktionsfähigesWerkzeug zur Verfügung. Ein Tester kann nicht nur einfach Serviceumgebungen rea-lisieren, sondern erhält auch die Kontrolle über das Deployment eines Services. Dieserlaubt Teile eines Services isoliert zu testen, so dass die Ableitung von Testfällenerleichtert wird.

Im Rahmen der Fallstudie entstanden automatisierte Testfälle, die dem vorgestelltenUnternehmen helfen, die Qualität ihrer Webservices kontinuierlich zu überwachen. DieFallstudie hat gezeigt, dass schon das Testen von einzelnen Services eine starke He-belwirkung hat. Es genügt nicht nur die Serviceimplementierung in einer lokalen Ser-viceumgebung zu testen, sondern auch der Übergang zu einem Service muss vollzo-gen werden. Dabei hilft das systematische Vorgehen einer Teststrategie, die gezieltnach vorher identifizierten Problemen sucht.

Diese Arbeit schafft eine allgemeine Grundlage zum Testen in einer SOA. Durch dieKenntnis der beschriebenen Konzepte, können alle Produkte dieser Arbeit in beliebi-gen Projekten praktisch eingesetzt werden.

75

Literaturverzeichnis

[ACD+03] ANDREWS, Tony ; CURBERA, Francisco ; DHOLAKIA, Hitesh ; GOLAND,Yaron ; KLEIN, Johannes ; LEYMANN, Frank ; LIU, Kevin ; ROLLER, Die-ter ; SMITH, Doug ; THATTE, Satish ; TRICKOVIC, Ivana ; WEERAWA-RANA, Sanjiva: Business Process Execution Language for Web Ser-vices Version 1.1. http://www.ibm.com/developerworks/library/specification/ws-bpel. Version: May 2003

[App07] APPLABS: Approach to Testing SOA Applications. Mai 2007

[Bac99] BACH, James: Test Automation Snake Oil. 1999

[Bec00] BECK, Kent: Extreme Programming Explained: Embrace Change. Addison-Wesley, 2000

[Bec03] BECK, Kent: Test-driven Development: By Example. Addison Wesley, 2003

[BG98] BECK, Kent ; GAMMA, Erich: Test infected: Programmers love writing tests.In: Java Report 3(7) (1998), S. 51–56

[Boe79] BOEHM, B. W.: Guidelines for Verifying and Validating Software Require-ments and Design Specifications. In: SAMET, P. A. (Hrsg.): Euro IFIP 79,North Holland, 1979, S. 711–719

[Bur03] BURNSTEIN, Ilene: Practical Software Testing: A Process-Oriented Ap-proach. Springer, 2003

[CP06] CANFORA, Gerardo ; PENTA, Massimiliano D.: Testing Services and Service-Centric Systems: Challenges and Opportunities. In: IT Pro March/April(2006), S. 10–17

[FMP+] FREEMAN, Steve ; MACKINNON, Tim ; PRYCE, Nat ; TALEVI, Mauro ; WAL-NES, Joe: jMock. http://www.jmock.org

[GHJV95] GAMMA, Erich ; HELM, Richard ; JOHNSON, Ralph ; VLISSIDES, John:Design Patterns: elements of reusable object-oriented software. Addison-Wesley, 1995

[Goo06] GOODLIFFE, Pete: Code Craft: The Practice of Writing Excellent Code. NoStarch Press, 2006

[GP06] GUCKENHEIMER, Sam ; PEREZ, Juan J.: Software Engineering with Micro-soft Visual Studio Team System. Addison-Wesley, 2006

[Ham04] HAMILL, Paul: Unit Test Frameworks. O’Reilly Media, Inc, 2004

[HS05] HUHNS, Michael ; SINGH, Munindar P.: Service-Oriented Computing: Key

76

http://www.jmock.org

http://www.ibm.com/developerworks/library/specification/ws-bpel

http://www.ibm.com/developerworks/library/specification/ws-bpel


Concepts and Principles. In: IEEE Internet Computing January/February(2005), S. 75–81

[IEE90] IEEE COMPUTER SOCIETY: IEEE Std 610.12-1990 - IEEE Standard Glossa-ry of Software Engineering Terminology. IEEE Computer Society, 1990

[IEE04] IEEE COMPUTER SOCIETY: Guide to the Software Engineering Body ofKnowledge. Angela Burgess, 2004

[imb] IMBUS AG: Testing Glossary. http://www.imbus.de/glossary/glossary.pl?show_Deutsch&sort=Deutsch

[JBC+07] JENDROCK, Eric ; BALL, Jennifer ; CARSON, Debbie ; EVANS, Ian ;FORDIN, Scott ; HAASE, Kim: The Java EE 5 Tutorial. Addison-Wesley, 2007 http://java.sun.com/javaee/5/docs/tutorial/doc/JavaEETutorial.pdf

[KBL06] KIFER, Michael ; BERNSTEIN, Arthur ; LEWIS, Philip M.: Database Systems:An Application Oriented Approach (Complete Version). Second. AddisonWesley, 2006

[KBP02] KANER, Cem ; BACH, James ; PETTICHORD, Bret: Lessons learned in soft-ware testing: a context-driven approach. John Wiley & Sons, 2002

[May06] MAYER, Philip: Design and Implementation of a Framework for Testing BPELCompositions, Leibniz Universität Hannover, Masterarbeit, 2006

[McC06] MCCAFFREY, James D.: .NET Test Automation Recipes: A Problem-SolutionApproach. Apress, 2006

[MFC01] MACKINNON, Tim ; FREEMAN, Steve ; CRAIG, Philip: Endo-Testing: UnitTesting with Mock Objects. In: Extreme programming examined, Addison-Wesley Longman Publishing Co., Inc., 2001, 287-301

[Mica] MICROSOFT CORPORATION: Overview of Data-Driven Unit Tests. http://msdn2.microsoft.com/library/ms182519.aspx

[Micb] MICROSOFT CORPORATION: Windows Communication Foundation. http://msdn2.microsoft.com/netframework/aa663324.aspx

[MRHB] MATZURA, Ole ; REIMERTZ, Niclas ; HOIDAHL, Lars ; BREDING, Emil: soapUI.http://www.soapui.org/

[MTSM03] MCGOVERN, James ; TYAGI, Sameer ; STEVENS, Michael ; MATHEW, Sunil:Java Web Services Architecture. Morgan Kaufmann, 2003

[OAS06] OASIS OPEN: Reference Model for Service Oriented Architecture 1.0. 2006

[Pap03] PAPAZOGLOU, Mike P.: Service-Oriented Computing: Concepts, Characteri-stics and Directions. In: WISE ’03: Proceedings of the Fourth InternationalConference on Web Information Systems Engineering, IEEE Computer So-ciety, 2003, S. 3

[Par] PARASOFT CORPORATION: SOAtest. http://www.parasoft.com

77

http://www.parasoft.com

http://www.imbus.de/glossary/glossary.pl?show_Deutsch&sort=Deutsch

http://www.imbus.de/glossary/glossary.pl?show_Deutsch&sort=Deutsch

http://java.sun.com/javaee/5/docs/tutorial/doc/JavaEETutorial.pdf

http://java.sun.com/javaee/5/docs/tutorial/doc/JavaEETutorial.pdf

http://msdn2.microsoft.com/library/ms182519.aspx

http://msdn2.microsoft.com/library/ms182519.aspx

http://msdn2.microsoft.com/netframework/aa663324.aspx

http://msdn2.microsoft.com/netframework/aa663324.aspx

http://www.soapui.org/


[Par06] PARASOFT CORPORATION: Bulletproofing Web Services. http://www.parasoft.com/jsp/printables/BulletproofingWebServices.pdf. Version: 2006

[Sko06] SKONNARD, Aaron: Service Station: Web Service Software Factory. In:MSDN Magazine December (2006)

[SLS06] SPILLNER, Andreas ; LINZ, Tilo ; SCHAEFER, Hans: Software Testing Foun-dations - A Study Guide for the Certified Tester Exam. dpunkt.verlag GmbH,2006

[Sta06a] STAL, Michael: Using Architectural Patterns and Blueprints for Service-Oriented Architecture. In: IEEE Software 23 (2006), Nr. 2, S. 54–61

[Sta06b] STAPEL, Kai: Informationsflussoptimierung eines Softwareentwicklungspro-zesses aus der Bankenbranche, Leibniz Universität Hannover, Masterarbeit,2006

[Tam02] TAMRES, Louise: Introducing Software Testing. Addison-Wesley, 2002

[TH02] THOMAS, Dave ; HUNT, Andy: Mock Objects. In: IEEE Software 19 (2002),Nr. 3, S. 22–24

[Thea] THE APACHE SOFTWARE FOUNDATION: Cactus. http://jakarta.apache.org/cactus/

[Theb] THE WEB SERVICES-INTEROPERABILITY ORGANIZATION: Interopera-bility Testing Tools 1.1. http://www.ws-i.org/deliverables/workinggroup.aspx?wg=testingtools

[The06] THE WEB SERVICES-INTEROPERABILITY ORGANIZATION: Basic ProfileVersion 1.1. http://www.ws-i.org/Profiles/BasicProfile-1.1.html. Version: 10 2006

[Typ] TYPEMOCK LTD.: TypeMock.NET. http://www.typemock.com

[W3C] W3C: Extensible Markup Language (XML). http://www.w3.org/XML/

[W3C04] W3C: Web Services Architecture. http://www.w3.org/TR/ws-arch/.Version: 2004

[W3C07] W3C: Web Services Description Language (WSDL) Version 2.0 Part 1: CoreLanguage. http://www.w3.org/TR/wsdl20. Version: 2007

[WSU] WSUNIT: WSUnit. https://wsunit.dev.java.net/

[Yan03] YANG, Jian: Web Service Componentization. In: Commun. ACM 46 (2003),Nr. 10, S. 35–40

[YSA05] YU, Weider D. ; SUPTHAWEESUK, Passarawarin ; ARAVIND, Dhanya: Trust-worthy Web Services Based on Testing. In: SOSE ’05: Proceedings of theIEEE International Workshop, IEEE Computer Society, 2005, S. 167–177

78

https://wsunit.dev.java.net/

http://www.parasoft.com/jsp/printables/BulletproofingWebServices.pdf



http://jakarta.apache.org/cactus/

http://jakarta.apache.org/cactus/

http://www.ws-i.org/deliverables/workinggroup.aspx?wg=testingtools

http://www.ws-i.org/deliverables/workinggroup.aspx?wg=testingtools

http://www.ws-i.org/Profiles/BasicProfile-1.1.html

http://www.ws-i.org/Profiles/BasicProfile-1.1.html

http://www.typemock.com

http://www.w3.org/XML/

http://www.w3.org/TR/ws-arch/

http://www.w3.org/TR/wsdl20

A. Testszenarien

1 / Testaspekt Funktionalität

Tester Entwickler

Serviceumgebung lokal

Abdeckung Einsatz von bekannten Methoden und Werkzeugen zurDurchführung von Komponententests bei objektorientierterSoftware. Für weitere Informationen sei z.B. auf [Bec03]oder [McC06] verwiesen.

Risiken Der Webservice zeigt unerwartetes Verhalten aufgrund einerfehlerhaften oder unvollständigen Implementierung. Wennsich der Code ändert, z.B. durch Einfügen einer neuen Funk-tionalität, können Fehler versteckt bleiben.

Vorbedingungen Die Serviceimplementierung ist vorhanden und testbar.

Durchführung Automatisiert

Mocks Mocks sind so einzusetzen, dass ein Teil der Serviceimple-mentierung einzeln und isoliert getestet wird.

Aktivitäten

1. Testen der funktionalen Korrektheit und Vollständigkeitder zu testenden Komponente.

2. Testen von angemessener Fehlerbehandlung.

Erfolgsbedingungen Ein erwarteter Effekt tritt ein.

Fehlschlagbedingungen

• Ein erwarteter Effekt bleibt aus.

• Eine unerwartete Fehlermeldung tritt auf.

79

A. Testszenarien

2 / Testaspekt Datentransferobjekte

Tester Entwickler

Serviceumgebung lokal

Abdeckung Grundlegende Prüfung der WSDL, um

• zirkuläre Abhängigkeiten

• nicht unterstützte XML Abbildungen

zu identifizieren.

Risiken Der Webservice ist bei Verwendung bestimmter Eingabe-oder Ausgabedaten nicht nutzbar. Zirkuläre Abhängigkeitenkönnen verborgen sein.

Vorbedingungen Eine Webservice Operation benutzt komplexe Datentypen,d.h. es werden nicht nur primitive Datentypen eingesetzt. Be-trifft Eingabe- und Ausgabedaten.


Mocks keine

Aktivitäten

1. Erstellen von vollständig aufgelösten Datentransferob-jekten, d.h. komplexe Objekte sind nicht null.

2. Durchführen einer XML-Serialisierung zur Erzeugungeiner entsprechenden XML-Repräsentation.

3. Deserialiserung der XML-Repräsentation aus Schritt2 zur Erzeugung eines mehrfach umgewandelten Ob-jekts.

Erfolgsbedingungen

• Es wird keine Ausnahme erzeugt.

• Das ursprüngliche und mehrfach umgewandelte Ob-jekt sind identisch.


• Eine Ausnahme wird geworfen.

• Das ursprüngliche und mehrfach umgewandelte Ob-jekt sind unterschiedlich.

80

A. Testszenarien

3a / Testaspekt Verifizierung des Deployment

Tester Entwickler

Serviceumgebung lokal/entfernt

Abdeckung Überprüft die Existenz von grundlegenden Funktionalitäten,die ein Service anbietet.

Risiken Der Service ist nicht nutzbar.

Vorbedingungen

• Eine Serviceimplementierung ist vorhanden.

• Interne Testpunkte sind vorhanden und erlauben auf-tretende Fehler gezielt zu verfolgen.


Mocks Die Datenzugriffsschicht.

Aktivitäten

1. Interaktion mit dem Service, so dass möglichst viele In-teraktionsmöglichkeiten ausgenutzt werden. So ist z.B.für Webservices jede Operation mindestens einmal an-zusprechen.

Erfolgsbedingungen Der Service erzeugt den erwarteten Effekt.


• Der Service liefert eine Fehlermeldung.

• Ein interner Testpunkt wirft eine Fehlermeldung.

81

A. Testszenarien

3b / Testaspekt Verifizierung des Deployment

Tester Entwickler

Serviceumgebung entfernt/test



Vorbedingungen

• Der Service wurde bereitgestellt.



Mocks keine

Aktivitäten

1. Interaktion mit dem Service, so dass alle Subsysteme,die der Service nutzt, angesprochen werden.





82

A. Testszenarien

3c / Testaspekt Verifizierung des Deployment

Tester Entwickler

Serviceumgebung entfernt/live



Vorbedingungen Der Service wurde mit einer endgültigen Konfiguration in ei-ner produktiven Serivceumgebung bereitgestellt.


Mocks keine

Aktivitäten

1. Defensive Interaktion mit dem Service, d.h. der inne-re Zustand des Service oder von anderen beteiligtenSystemen darf sich nicht ändern. Dennoch sollte dieInteraktion so viele Subsysteme wie möglich anspre-chen.


Fehlschlagbedingungen Der Service liefert eine Fehlermeldung.

83

A. Testszenarien

4a / Testaspekt Konfigurationen

Tester Entwickler

Serviceumgebung lokal/entfernt, entfernt/test

Abdeckung Überprüft die Korrektheit von allen in einem Service genutz-ten Konfiguration. Im Allgemeinen benötigen z.B. die folgen-den Einheiten eine gültige Konfiguration:

• der Container

• Ressourcen, die in der Datenzugriffsschicht genutztwerden

• eingesetzte Bibliotheken


Vorbedingungen

• Die Konfiguration einer Einheit ist verfügbar.



Mocks Nicht benötigte Ressourcen.

Aktivitäten

1. Interaktion mit dem Service, so dass eine Einheit ge-nutzt wird.

Erfolgsbedingungen Der Effekt der Einheit tritt ein.




84

A. Testszenarien

4b / Testaspekt Konfigurationen

Tester Entwickler


Abdeckung Ein Service wird mit unterschiedlichen Konfigurationen insehr unterschiedlichen Umgebungen eingesetzt.


Vorbedingungen

• Alle neuen Umgebungen sind verfügbar.

• Die Konfiguration für jede neue Umgebung ist verfüg-bar.



Mocks Nicht benötigte Ressourcen.

Aktivitäten

1. Interaktion mit dem Service, so dass eine Konfigurationverarbeitet wird.

Erfolgsbedingungen Der Service erzeugt einen erwarteten Effekt.




85

A. Testszenarien

5a / Testaspekt Autorisierung und Authentifizierung

Tester Entwickler, Tester


Abdeckung Überprüft, ob nur berechtigte Nutzer mit einem Service in-teragieren können.

Risiken Services können mit vertraulichen Daten arbeiten oder lö-sen Effekte in der realen Welt aus. Daher sind Services vorunberechtigten Zugriffen zu schützen.

Vorbedingungen

• Der Service ist öffentlich zugänglich, aber die Interak-tion mit dem Service soll nur einem beschränkten Nut-zerkreis möglich sein.



Mocks Die Geschäftslogikschicht und/oder Datenzugriffsschicht.

Aktivitäten

1. Aufrufen einer Operation ohne Übermittlung von Datenzur Authentifizierung.

2. Aufrufen einer Operation mit verschiedenen ungültigenDaten zur Authentifizierung.

Erfolgsbedingungen Der Service liefert eine Fehlermeldung.


• Der Service verarbeitet die Anfrage und erzeugt einenEffekt.


86

A. Testszenarien

5b / Testaspekt Autorisierung und Authentifizierung



Abdeckung Eine Authentifizierung prüft, ob ein Benutzer die Erlaubnishat mit einem Service überhaupt zu interagieren. Eine Auto-risierung überprüft, ob ein Benutzer die Rechte hat angefor-derte Dienste in Anspruch zu nehmen.

Risiken Einem authentifizierten Benutzer ist nicht immer erlaubt alleAktionen auszuführen, die durch einen Service angebotenwerden.

Vorbedingungen

• Der Service ist öffentlich zugänglich und seine Dienstesollen nur einem beschränkten Nutzerkreis zur Verfü-gung stehen.



Mocks Die Geschäftslogikschicht und/oder Datenzugriffsschicht.

Aktivitäten

1. Interaktion mit dem Service unter Angabe von gülti-gen Daten zur Authentifizierung, aber mit dem Versuchauf Dienste zuzugreifen, für die entsprechende Rechtefehlen.

Erfolgsbedingungen


• Der Service erzeugt keinen Effekt.


• Der Service verarbeitet die Anfrage und erzeugt einenEffekt.


87

A. Testszenarien

6 / Testaspekt Fehlendes Subsystem

Tester Entwickler

Serviceumgebung lokal/entfernt oder entfernt/test

Abdeckung Das Verhalten des Services, wenn ein Subsystem nicht ver-fügbar ist.


Vorbedingungen Ein Subsystem ist nicht verfügbar.

Durchführung Manuell

Mocks keine

Aktivitäten

1. Interaktion mit dem Service, so dass das nicht verfüg-bare Subsystem angesprochen wird.

Erfolgsbedingungen

• Der Service sucht nach Alternativen oder wirft eine an-gemessene Fehlermeldung.

• Die Abwesenheit des Subsystems wird festgehaltenund eine zuständige Person informiert.


• Der Service stellt das fehlende Subsystem nicht fest,so dass ein unerwarteter Effekt entsteht.

• Der Service wirft eine unangemessene Fehlermel-dung.

88

A. Testszenarien

7a / Testaspekt Annahmen an Eingabedaten



Abdeckung Jeder Service muss alle Eingabedaten auf Gültigkeit über-prüfen und Fehler durch eine Meldung anzeigen. Eingabeda-ten werden sowohl von Servicekonsumenten, als auch vonanderen Services, bezogen.

Risiken Ungültige Eingabedaten gefährden die Integrität des Ser-vices, indem es z.B. zu langen Verarbeitungszeiten, Angrif-fen oder allgemein unberechenbarem Verhalten kommt.

Vorbedingungen

• Eine Serviceimplementierung liegt vor.



Mocks Die Geschäftslogikschicht. Wenn ein Test fehlschlägt, ist die-ser Test erneut ohne Mocks durchzuführen und das Verhal-ten zu beobachten.

Aktivitäten

1. Identifikation aller Annahmen an Eingabedaten.

2. Auswahl von Repräsentanten für ungültige Eingabeda-ten.

3. Interaktion mit dem Service mit ausgewählten Reprä-sentanten.

4. Andere Services sind so durch Mocks zu ersetzen,dass sie ausgewählte Repräsentanten liefern.

Erfolgsbedingungen Der Service liefert eine Fehlermeldung, die angibt, dass zurVerfügung gestellte Eingabedaten nicht verarbeitet werdenkönnen.


• Der Service arbeitet ohne Fehlermeldung weiter underzeugt einen Effekt.

• Der Service liefert eine unerwartete Fehlermeldung.


89

A. Testszenarien

7b / Testaspekt Annahmen an Eingabedaten



Abdeckung Gegenprobe zu Testszenario 7a unter Verwendung von gül-tigen Eingabedaten.

Risiken Dokumente und andere Quellen, die zur Analyse von Annah-men an Eingabedaten in Testszenario 7a genutzt wurden,können fehlerhaft sein.

Vorbedingungen



• Testszenario 7a wurde durchgeführt und die Ergebnis-se der anfänglichen Analyse sind noch verfügbar.


Mocks Die Geschäftslogikschicht.

Aktivitäten

1. Interaktion mit dem Service mit gültigen Eingabedaten.

2. Andere Services sind so durch Mocks zu ersetzen,dass sie gültige Eingabedaten liefern.

Erfolgsbedingungen Der Service erzeugt einen erwarteten Effekt.




90

A. Testszenarien

8 / Testaspekt Versteckte Grenzen



Abdeckung Durch den Einsatz einer Schichtenarchitektur oder dem Nut-zen von Subsystemen entstehen Grenzen, an denen unter-schiedliche Datentypen und Annahmen an die Daten zu Feh-lern führen können. Probleme sind versteckt und schwierigzu identifizieren.

Risiken Der Service kann intern mit ungültigen Werten arbeiten.

Vorbedingungen


• Falls erforderlich, ist der Service in einer entfernt/testServiceumgebung bereitzustellen.


Mocks keine

Aktivitäten

1. Identifikation von Grenzen zwischen allen Schichtenund Ressourcen, d.h. die Grenzen selbst und alle aus-getauschten Objekte sind bekannt.

2. Für jedes Objekt, das über eine Grenze ausgetauschtwird, ist der Datentyp bzw. aufgespannte Datenraumzu bestimmen.

3. Reduktionen im Datenraum identifizieren.

4. Falls erforderlich sind Daten so in den Service ein-zupflegen, dass eine potentielle Reduktion im Daten-raum entsteht.

5. Interaktion mit dem Service, so dass potentiell redu-zierte Daten genutzt werden.

Erfolgsbedingungen

• Der Service kompensiert eine Reduktion im Daten-raum und arbeitet in jedem Fall korrekt.

• Der Service wirft eine angemessene Fehlermeldung.

Fehlschlagbedingungen Der Service verwendet die potentiell reduzierten Daten, sodass der Effekt des Services fehlerhaft ist.

91

A. Testszenarien

9 / Testaspekt Rückwärtskompatibilität

Tester Entwickler


Abdeckung Die Serviceschnittstellte ist ein einzuhaltender Vertrag. Im-mer wenn sich Änderungen am Service ergeben, muss dieServiceschnittstelle rückwärtskompatibel bleiben.

Risiken Jede Änderung in der Serviceschnittstelle kann zu Ände-rungen bei allen Servicekonsumenten führen. Die Service-konsumenten werden unzufrieden, weil sie evtl. zeitintensiveÄnderungen in ihrer eigenen Software vornehmen müssen.Fehler treten evtl. nur bei bestimmten Interaktionen auf undsind daher zunächst versteckt.

Vorbedingungen

1. Für den Service existieren automatische Tests und die-se Tests setzen einen Proxy zur Interaktion mit demService ein.

2. Keiner der Tests aus Vorbedingung 1 schlägt fehl.


Mocks Werden vom eingesetzten Test übernommen.

Aktivitäten

1. Erstellen eines Proxy für den aktuellen produktivenService.

2. Ausführen aller verfügbaren Tests mit dem neuenProxy.

Erfolgsbedingungen Alle Tests sind erfolgreich.

Fehlschlagbedingungen Ein Test schlägt fehl.

92

A. Testszenarien

10 / Testaspekt Interoperabilität

Tester Tester


Abdeckung Der Service kann von beliebigen Plattformen eingesetzt wer-den, ist aber gebunden an eine Technologie.

Risiken Der Service steht nur einem beschränkten Kreis von Nutzernzur Verfügung.

Vorbedingungen

• Der Service ist in einer entfernt/test Serviceumgebungverfügbar.

• Eine andere Plattform, die sich von der zur Bereitstel-lung genutzten Plattform unterscheidet, ist verfügbar.Bevorzugt sind für den Test verbreitete Plattformen zuwählen, die vorrangig von Kunden eingesetzt werden.


Mocks keine

Aktivitäten

1. Benutzen des Services mit einer anderen Plattform.

Erfolgsbedingungen Der Service bearbeitet die Anfrage wie erwartet.

Fehlschlagbedingungen Der Service liefert eine Fehlermeldung.

93

A. Testszenarien

11 / Testaspekt Funktionalität

Tester Tester


Abdeckung Spezifikationen und die Servicedokumentation beschreibendas Verhalten eines Services.

Risiken Der Service arbeitet nicht wie es von einem Servicekon-sument erwartet wird. Dadurch lässt er sich nicht wie ge-wünscht einsetzen.

Vorbedingungen

• Dokumente, die den Effekt eines Services beschrei-ben, wurden identifiziert.

• Der Service ist in einer entfernt/test Serviceumgebungverfügbar.


Mocks keine

Aktivitäten

1. Überprüfen, ob eine Funktion oder ein Effekt, den derService liefern soll, eintritt.

Erfolgsbedingungen Der Service bearbeitet die Anfrage wie in einem Dokumentfestgelegt.


• Der Service zeigt vom Dokument abweichendes Ver-halten.

• Der Service wirft eine unerwartete Fehlermeldung.

94

Erklärung der Selbstständigkeit

Hiermit versichere ich, dass ich die vorliegende Masterarbeit selbständig und ohnefremde Hilfe verfasst und keine anderen als die in der Arbeit angegebenen Quellenund Hilfsmittel verwendet habe. Die Arbeit hat in gleicher oder ähnlicher Form nochkeinem anderen Prüfungsamt vorgelegen.

Hannover, den 29. Oktober 2007

Dennis Hardt

95

Testen von serviceorientierten Architekturen ... · Zusammenfassung Serviceorientierte...

Documents

Transcript of Testen von serviceorientierten Architekturen ... · Zusammenfassung Serviceorientierte...