Testen von serviceorientierten Architekturen: Teststrategie und ...

Gottfried Wilhelm
Leibniz Universität Hannover
Fakultät für Elektrotechnik und Informatik
Institut für Praktische Informatik
Fachgebiet Software Engineering
Testen von serviceorientierten
Architekturen: Teststrategie und
Implementierung
Masterarbeit
im Studiengang Informatik
von
Dennis Hardt
Prüfer: Prof. Dr. Kurt Schneider
Zweitprüfer: Prof. Dr.-Ing. Christian Grimm
Betreuer: Dr. Jan-Mirko Maczewski
Betreuer: Dipl.-Wirt.-Inform. Daniel Lübke
Hannover, 29. Oktober 2007

Zusammenfassung
Serviceorientierte Architekturen (SOA) haben sich zu einem bekannten Paradigma zur
Strukturierung von Applikationen entwickelt. An ihre aktiven Einheiten, die Services,
werden hohe qualitative Ansprüche gestellt, um sie in einem beliebigen Umfeld einsetzen
zu können. Dabei wird in der Forschung und Entwicklung oftmals speziell das
Testen von Webservices betrachtet; die Beschreibung einer Teststrategie bleibt jedoch
aus.
Diese Arbeit stellt nicht nur eine Auswahl von potentiellen Problemen vor, die in einer
SOA auftreten können, sondern ermöglicht auch diese Probleme als Grundlage
zur Formulierung einer Teststrategie zu nehmen. Dazu werden die Artefakte, die eine
Teststrategie für eine SOA beschreiben, identifiziert und präsentiert. Die Definition
einer allgemeinen Vorgehensweise zur Findung einer konkreten Teststrategie erlaubt
Teststrategien für beliebige SOA-Projekte zu bestimmen.
Ein im Rahmen dieser Arbeit entwickeltes Werkzeug erlaubt nicht nur die Umsetzung
einer Teststrategie, sondern ermöglicht auch die Realisierung von Teststufen exemplarisch
für in .NET implementierte Webservices. Dazu stellt diese Arbeit eine neue
Sichtweise auf Komponenten vor und trennt diese klar von Kompositionen ab. Erfahrungen
mit dem Werkzeug und einer konkret entwickelten Teststrategie wurden im
Rahmen einer Fallstudie bei einem Unternehmen gesammelt.
ii

Inhaltsverzeichnis
1. Einführung 1
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Struktur dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Grundlagen 4
2.1. Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Grundbegriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Ausgewählte Testmethoden . . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Teststufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4. Teststrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Serviceorientierte Architekturen . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Grundbegriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. Konsequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Plattformen für Unternehmensanwendungen . . . . . . . . . . . . . . . 12
2.4. Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1. Grundbegriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.2. Webservice Standards . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Ableitung einer Teststrategie für serviceorientierte Architekturen 15
3.1. Einordnung der Teststrategie . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Einflüsse auf die Teststrategie . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1. Idee, Plattform und Technologie . . . . . . . . . . . . . . . . . . 16
3.2.2. Projektumfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3. Teststrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.1. Serviceumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.2. Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3. Testszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4. Komponententests für eine SOA . . . . . . . . . . . . . . . . . . . . . . 22
3.4.1. Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.2. Identifikation der Komponente bei Services . . . . . . . . . . . . 23
3.4.3. Austauschen von Komponenten in Services . . . . . . . . . . . . 23
3.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4. Testaspekte für SOA, Webservices und .NET 27
4.1. Identifikation von Testaspekten . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.1. SOA als Idee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
iii

Inhaltsverzeichnis
4.1.2. Webservices als Technologie . . . . . . . . . . . . . . . . . . . . 32
4.1.3. .NET als Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2. Analogien zu Java EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5. Werkzeugunterstützung für die Teststrategie 36
5.1. Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.1. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.2. Konsequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.3. Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2. Testmöglichkeiten in .NET . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3. Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.1. Grobarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.2. Testablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.3. Adapter zu einem Unit Test Framework . . . . . . . . . . . . . . 42
5.3.4. Interaktion mit externen Systemen . . . . . . . . . . . . . . . . . 44
5.4. Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.5. Realisierung von harten Mocks . . . . . . . . . . . . . . . . . . . . . . . 47
5.5.1. Identifikation von auszutauschenden Teilen . . . . . . . . . . . . 47
5.5.2. Verarbeitung und Austauschen von Code . . . . . . . . . . . . . 47
5.6. Realisierung von weichen Mocks . . . . . . . . . . . . . . . . . . . . . . 49
5.7. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6. Fallstudie 53
6.1. Projektumfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1.1. Betrachtete Webservices . . . . . . . . . . . . . . . . . . . . . . 54
6.1.2. Bisheriges Vorgehen beim Testen der Webservices . . . . . . . 55
6.2. Eine konkrete Teststrategie . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.1. Annahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.2. Testmatrix und Testszenarien . . . . . . . . . . . . . . . . . . . . 56
6.3. Anwendung der Teststrategie . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3.1. Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3.2. Gefundene Fehler . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.4. Lektionen und Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7. Kritische Würdigung 66
7.1. Kritischer Rückblick auf den Erarbeitungsprozess . . . . . . . . . . . . . 66
7.2. Stärken und Schwächen einer Teststrategie . . . . . . . . . . . . . . . . 66
7.3. Stärken und Schwächen der entwickelten Erweiterungen . . . . . . . . 67
7.4. Kritischer Rückblick auf die Fallstudie . . . . . . . . . . . . . . . . . . . 68
8. Verwandte Arbeiten 70
8.1. Andere Ansätze und Werkzeuge . . . . . . . . . . . . . . . . . . . . . . 70
8.2. Testaspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.3. Testen von Kompositionen . . . . . . . . . . . . . . . . . . . . . . . . . . 71
iv

Inhaltsverzeichnis
9. Zusammenfassung und Ausblick 73
9.1. Rückblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
9.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 oder
Werbeträger. Das zentrale Ziel einer SOA besteht in der Reduktion von Abhängigkeiten
zwischen Softwarelösungen [Sta06a]. Aber Dienste in heterogenen, dynamischen
und verteilten Umgebungen anzubieten, fordert neue Sichtweisen beim Testen eines
Services. So sind viele bekannte Testverfahren und -werkzeuge nicht mehr anwendbar
[CP06].
Webservices sind nur eine mögliche Implementierung von Services [Sta06a]. Dennoch
hat sich diese Technologie als die dominierende und am weitesten verbreitete
Realisierung für SOA etabliert. Nicht zuletzt unterstützen viele Applikationsserver und
Entwicklungsumgebungen aus dem Java- oder Microsoft .NET-Umfeld die Bereitstellung
von Webservices [MTSM03][GP06]. Selbst Unternehmen, unter anderem zu nennen
seien Amazon 1 und Ebay 2 , lagern Teile ihrer Dienste in Webservices aus. Folglich
können Kunden von überall auf der Welt ohne Benutzeroberfläche mit einem Geschäft
interagieren 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 einzelnen
Service zu fehlerhaftem Gesamtverhalten. Testen wird somit unabdingbar, um die qualitativ
hochwertige Implementierung von jedem Service sicher zu stellen. Insbesondere
in den letzten Jahren wurden viele neue Ansätze und Werkzeuge entwickelt, um das
Testen von SOA zu verbessern. Dennoch beruhen alle Entwicklungen auf denselben
Ansätzen und betrachten Services als eine abgeschlossene Einheit, so dass sich das
Testen selbst mitunter als sehr schwierig erweist.
Durch die Verfügbarkeit von einfach zu handhabenden Werkzeugen [BG98] haben
Komponententests zunehmend an Bedeutung gewonnen. Für nahezu jede Plattform
ist ein „xUnit Test Framework“ [Ham04] verfügbar und erlaubt die einheitliche Formulierung
von Komponententests . Auch die Integration in Entwicklungsumgebungen hat
sich stetig verbessert [GP06], so dass Komponententests zu einer entwicklernahen
und praktikablen Lösung geworden sind. Auch wenn für eine SOA Werkzeuge wie
z.B. BPELUnit [May06] oder WSUnit [WSU] existieren, so nehmen sie eine bestimmte
Sichtweise bei Komponententests ein. Oft werden jedoch bekannte Bibliotheken und
objektorientierte Programmiersprachen eingesetzt, um einen Service zu realisieren.
Speziell in diesem Umfeld versagen beim Testen Konzepte, die für objektorientierte
1 http://www.amazon.com
2 http://www.ebay.com
1

1. Einführung
Software zur täglichen Praxis geworden sind. Sowohl die Interaktion mit einem Service,
als auch das Austauschen von Komponenten, erfordert neue Sichtweisen und
Ideen.
Das Testen von Webservices und Kompositionen hat in der Forschung viel Aufmerksamkeit
erfahren. Insbesondere die Eigenschaften, die bei einem Webservice funktional
zu testen sind, sind wohl bekannt. Dennoch bleibt beim Testen die genaue Vorgehensweise
unklar. Es fehlt eine Strategie, die Aktivitäten den Teststufen zuordnet und
z.B. festlegt welche Tests zu automatisieren sind. Mitunter benötigt auch diese Teststrategie
weitere Unterstützung durch Werkzeuge, um erst praktikabel umsetzbar zu
sein.
1.2. Problemstellung
Diese Arbeit befasst sich im Allgemeinen mit dem Testen von serviceorientierten Architekturen.
Im Einzelnen sind dazu die folgenden Punkte gezielt zu adressieren:
• Ziel dieser Arbeit ist eine Teststrategie für serviceorientierte Architekturen bereit
zu stellen, so dass beim Einsatz einer SOA die Vorgehensweise beim Testen
bekannt ist. Beginnen soll die Teststrategie bei Komponententests, aber auch
höhere Teststufen sind zu berücksichtigen.
• Falls erforderlich ist ein Werkzeug zu erstellen, das die Umsetzung der Teststrategie
praktisch ermöglicht. Speziell die Realisierung von Komponententests ist
dabei zu berücksichtigen.
• Im Rahmen einer Fallstudie ist zu prüfen, ob die vorgeschlagene Teststrategie
umsetzbar ist und erstellte Werkzeuge praktikabel sind. Als Testobjekte werden
Webservices dienen, die von einem Unternehmen entwickelt wurden und
von ihren Kunden genutzt werden. Hierbei sollen insbesondere die notwendigen
Schritte zur Erzeugung von Testdaten nachvollziehbar sein. Zur Entwicklung wird
vom Unternehmen das Microsoft .NET Framework und die Microsoft Visual Studio
Team Edition [GP06] eingesetzt, so dass alle erstellten Werkzeuge und Tests
dort 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 Architekturen
unabhängig voneinander eingeführt. Aufgrund unterschiedlicher Definitionen
im SOA-Umfeld, werden die verwendete Terminologie und das Verständnis
von einer SOA definiert.
• Aufgrund bestimmter Einflüsse ist es nicht möglich direkt eine Teststrategie für
SOA 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 potentielle
Probleme nach dem Vorgehen aus Kapitel 3 vorstellen. Webservices
und das Microsoft .NET Framework werden aufgrund der Relevanz in der Fallstudie
in Kapitel 6 betrachtet.
• Kapitel 5 stellt ein Werkzeug vor, mit dem Teststufen für Webservices umgesetzt
werden können und eine nach Kapitel 3 angegebene Teststrategie realisierbar
wird.
• In Kapitel 6 werden die Ergebnisse aus den Kapiteln 3, 4 und 5 in einer Fallstudie
zusammengeführt, um die Webservices eines Unternehmens zu testen.
• Die Stärken und Schwächen der Teststrategie und des Werkzeugs werden in
einer kritischen Würdigung in Kapitel 7 beleuchtet.
• Kapitel 8 zeigt verwandte Arbeiten, um die Einordnung dieser Arbeit in den wissenschaftlichen
Kontext zu erleichtern.
• Diese Arbeit schließt in Kapitel 9 mit einer Zusammenfassung und einem Ausblick
ab.
3

2. Grundlagen
Während der Entwicklung durchlebt Software einen Lebenszyklus, der sich in mehrere
Aktivitä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 durch
agile 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 Produktes.
Die sich anschließende Behebung von identifizierten Mängeln und Fehlern verbessert
das Produkt. Sowohl das V-Modell, als auch XP, sehen Tests als durchzuführende
Aktivität vor. Dabei hat jedes Projekt ein individuelles Vorgehen und unterschiedliche
Kapazitäten zur Realisierung von Tests. Speziell in XP testen nur Entwickler ihren Code
durch automatisierte Komponententests.
Serviceorientierte Architekturen (SOA) sind ein Stil zur Strukturierung von Applikationen.
Durch viel Aufmerksamkeit in der Industrie sind sehr unterschiedliche Definitionen
einer SOA entstanden [OAS06]. Besonders die Trennung zu Webservices ist verschwommen,
weil sich Webservices zur verbreitetsten und bekanntesten Umsetzung
von Services etabliert haben.
Dieses Kapitel wird alle für den Verlauf dieser Arbeit wichtigen Begriffe bezüglich des
Testens und SOA definieren. In den Folgekapiteln werden beide Themengebiete dann
langsam 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 und
Manager erleuchten [KBP02]. Sie zeigen, ob man sich nahe am Abgrund bewegt oder
auf sicherer Spur fährt.
Im Allgemeinen ist das Produkt der Programmierung ein ausführbares Kompilat. Beim
Testen sind es Testfälle, die letztendlich genutzt werden, um Aspekte einer Software
in einem bestimmten Umfeld zu testen. Ein Testfall besteht dabei aus Eingabedaten,
Ausführungsbedingungen und erwarteten Ergebnissen [IEE90]. Die Ableitung
oder 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 Benutzergruppen
Tests durchführen:
– Entwickler testen ihren Code z.B. durch automatisierte Komponententests
in 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 die
Methode einer Klasse handeln oder die Oberfläche einer Applikation.
• Potentielle Probleme: Warum wird getestet? Welche Fehler können im Produkt
auftreten?
• Aktivitäten: Wie wird getestet?
• Auswertung: Wann ist ein Test erfolgreich und wann fehlgeschlagen? Tritt der
gewünschte Effekt bei Ansteuerung des Testobjekts ein, d.h. sind resultierende
Werte korrekt oder wird eine erwartete Fehlermeldung geliefert.
Beispiel 2.1
Bei der Testmethode „Testen von Funktionen“ („function testing“) wird jede Funktion
einzeln nacheinander getestet. Demzufolge wird nur eine Aussage über die Abdeckung
getroffen, aber wer den Test durchführt (Tester) oder was für Fehler (Potentielle
Probleme) gesucht werden, bleibt unbekannt. [KBP02]
Testmethoden sind formal anwendbare Methoden, die noch nicht in allen Dimensionen
eine Ausprägung besitzen.
Definition 2.1
Ein Testaspekt ist eine Ausprägung über der Dimension: Potentielle Probleme. Zusätzlich
beschreibt ein Testaspekt die Vorgehensweise zur Herleitung von Testfällen
unter Einbezug von Testmethoden.
Ein Testaspekt beschreibt somit eine Klasse von Fehlern, die in einem Testobjekt auftreten
können. Insbesondere ist aber auch das Vorgehen zur Findung dieses Fehlers
zu beschreiben. Wenn bekannte Testmethoden existieren, sind diese anzugeben, ansonsten
ist eine allgemeine Beschreibung zur Ableitung von Testfällen zu definieren.
Im Verlauf dieser Arbeit werden ausschließlich Testaspekte benutzt, um potentielle
Probleme in einer SOA zu definieren und die Vorgehensweise zum Auffinden dieser
Probleme festzuhalten.
2.1.2. Ausgewählte Testmethoden
In dieser Arbeit werden potentielle Probleme über Testaspekte beschrieben. Dabei
stützt sich die Beschreibung der Vorgehensweise zur Identifikation von repräsentierten
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ür
weitere Informationen sei auf die angegebene Literatur verwiesen:
• Equivalence partitioning ([IEE04], [KBP02]): Unterteilung von Testdaten in Äquivalenzklassen,
d.h. alle Testdaten aus einer Äquivalenzklasse führen bei einem
Test zu äquivalentem Verhalten. So genügt es für ausgewählte Elemente einer
Äquivalenzklasse zu testen.
• Regression testing ([IEE04], [KBP02], [SLS06]): Erneutes Testen eines Systems
nach einer Modifikation, um zu verifizieren, dass durch Änderungen keine unbeabsichtigten
Effekte im System entstanden sind. Dazu werden vorhandene
Testfälle erneut verwendet.
• Statement and branch coverage ([IEE04], [KBP02]): Man erreicht 100% statement
and branch coverage, wenn ein Test jede Anweisung und jeden Zweig im
Programm ausführt. Tests werden so gestaltet, dass sie eine möglichst hohe
statement 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, die
in Spezifikationen, Handbüchern oder anderen Dokumenten an das Produkt gestellt
werden.
• Load testing ([KBP02]): An ein System werden viele Anfragen gestellt. Bei einer
hohen Auslastung wird das System wahrscheinlich ausfallen, so dass Schwachstellen
offensichtlich werden.
• Performance testing ([IEE04], [KBP02]): Verifiziert, ob ein System Anforderungen
an die Leistung erfüllt, z.B. an den Durchsatz oder an Antwortzeiten. Erhebliche
Leistungseinbrüche gegenüber einer vorherigen Version des Systems
können auf Fehler in der Programmierung hinweisen.
• Long sequence testing ([KBP02]): Über Nacht, Tage oder Wochen werden Anfragen
an ein System gestellt.
• Smoke testing ([KBP02]): Testet grundlegende Eigenschaften, von denen erwartet
wird, dass sie im System funktionsfähig sind. Ziel ist es zu prüfen, ob eine
neue Version des Systems würdig ist getestet zu werden. Diese Tests sind oftmals
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 Zustand
zu erreichen. Dabei ist es nicht möglich alle Pfade eines nicht trivialen
Programms zu testen.
• Configuration testing ([IEE04], [KBP02]): Analyse von Software unter Einsatz
verschiedener 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 dieser
Klasse. 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, ist
mitunter ein schwieriges Unterfangen. In der objektorientierten Programmierung interagieren
am Ende eines Projekts Tausende von Objekten miteinander, um eine Applikation
zu formen. Existiert in einem dieser vielen Objekte ein Fehler, so lässt er sich
nur schwer identifizieren. Eine Abschwächung dieses Problems ist durch den Einsatz
von drei Teststufen möglich:
1. Komponententests (unit test [IEE04]): Eine Komponente sei die kleinste kompilierbare
Einheit in einer Applikation [Tam02], so sind es z.B. in der objektorientierten
Programmierung die Klassen [SLS06]. Komponententests verifizieren
jede einzelne Komponente isoliert von allen anderen Komponenten durch den
Einsatz von künstlichen Umgebungen [Tam02]. Praktisch werden dazu Mocks 1
eingesetzt, die das Verhalten einer Komponente simulieren [TH02]. Dabei haben
Mocks das Ziel so einfach wie möglich umgesetzt zu sein und nicht die Logik der
ersetzten Komponente nachzubilden [MFC01].
Verfasst werden Komponententests z.B. mit Unit Test Frameworks, die für eine
Vielzahl von Sprachen zur Verfügung stehen [Ham04]. Dennoch setzen Komponententests
voraus, dass alle von einer Komponente benutzten Komponenten
austauschbar sind. In der objektorientierten Programmierung kann dies durch
einen Programmierstil erreicht werden, der z.B. auf geringe Komplexität setzt
und von globalen Objekten unabhängig ist [Goo06]. Zusätzlich haben sich über
die 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 Komponententests
werden bei Integrationstests Komponenten zu größeren Teilsystemen integriert
[SLS06]. Ziel ist es durch schrittweise Integration sicherzustellen, dass alle
Komponenten korrekt zusammenarbeiten.
3. Systemtests (system test [IEE04]): Systemtests verifizieren bzw. validieren das
gesamte Produkt, nachdem alle Teile einer Software integriert wurden [Tam02].
Insbesondere sind andere Sichtweisen testbar als dies auf niedrigeren Stufen
der 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 einzelnen
Komponenten und deren Zusammenspiel erweist sich oftmals als einfacher. Für diese
Arbeit sind Abnahmetests unerheblich und seien daher nicht angeführt.
1 Auch: Stub oder Dummy
7

2. Grundlagen
2.1.4. Teststrategie
Bisher wurde eine kleine Auswahl an Grundbegriffen aus dem Bereich des Testens
vorgestellt. Dennoch beschreiben all diese Ansätze und Methoden noch nicht wie ein
Produkt zu testen ist. Es fehlt eine Darlegung der Vorgehensweise, genauer die Teststrategie.
Eine Teststrategie ist mehr als nur eine Sammlung von Testmethoden, aber auch noch
kein Testkonzept [KBP02]. Ziel ist die Festlegung eines einheitlichen Ansatzes für die
zukünftige Testplanung. Eine Teststrategie legt den Umfang durchzuführender Tests
fest und adressiert nur Probleme mit kritischem Risiko [SLS06].
Definition 2.2
Eine Teststrategie ist die „(1) Abstrakte Beschreibung der Teststufen und der zugehörigen
Ein- und Ausgangskriterien . . . (2) Aufteilung von Testaufwand über die zu testenden
Teile und/oder zu erfüllende Qualitätsmerkmale des Testobjekts. Auswahl und
Bestimmung der Reihenfolge von einzelnen Testmethoden und der Reihenfolge ihrer
Anwendung auf die verschiedenen Testobjekte . . . “ [imb]
Eine Teststrategie ist in der Regel in mehreren Projekten anwendbar [imb]. Sie beschreibt
den Einsatz von Teststufen und legt das Vorgehen beim Testen fest, wenn
möglich unter Angabe von Testmethoden.
Beispiel 2.2
Testgetriebene Entwicklung ist eine Teststrategie, die ein iteratives Vorgehen nahe
legt. Bevor Code geschrieben wird, ist immer ein Test zu verfassen, der zunächst fehlschlagen
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 Testmethoden,
um das Problem ausfindig zu machen. Folglich kann eine Teststrategie
über Testaspekte beschrieben werden.
2.2. Serviceorientierte Architekturen
2.2.1. Grundbegriffe
Im Folgenden wird ein einheitlich in dieser Arbeit verwendeter Sprachschatz für SOA
eingeführt. Dabei liegt der Fokus auf Einfachheit, so dass für weitere Informationen
auf [OAS06], [Sta06a] und [W3C04] verwiesen sei.
Definition 2.3
Eine Schnittstelle ist ein Dokument, das beschreibt wie mit einem Objekt zu interagieren
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 öffentliche
Beschreibung notwendig. Die Beschreibung ist auch in der Lage mögliche Kommunikationsformen
zu realisieren.
Definition 2.4
Eine Dokumentation ist ein Dokument, das die semantischen Eigenschaften, Randbedingungen
und den Effekt einer Einheit beschreibt.
Die Schnittstelle und die Dokumentation einer Einheit sind Artefakte, durch die eine
Interaktion mit der Einheit möglich wird.
Definition 2.5
Ein Service ist eine aktive Einheit, die Anderen seine Dienste anbietet. Jeder Service
hat eine Schnittstelle, die Serviceschnittstelle, eine Beschreibung, die Servicebeschreibung
und optional eine Dokumentation, die Servicedokumentation. Die Kommunikation
zwischen Services erfolgt durch den Austausch von Nachrichten. Das Resultat
einer Interaktion mit einem Service ist ein Effekt.
Ein Service wird in der Fachliteratur und im allgemeinen Gebrauch immer abstrakt als
ein Anbieter von Diensten betrachtet. Die gegebene Definition stützt sich auf den Austausch
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 auch
die Beziehungen zwischen zunächst drei Rollen her [Pap03]:
• Serviceanbieter (service provider): Stellt einen Service zur Verfügung und verwaltet
die notwendige Infrastruktur.
• Servicekonsument (service consumer): Möchte Dienste in Anspruch nehmen
und sucht einen entsprechenden Service.
• Serviceregister (service registry): Stellt ein Verzeichnis von Services bereit.
Jeder Service verwendet das „Bridge“-Entwurfsmuster [GHJV95], um die Serviceschnittstelle
von der Implementierung zu trennen [Sta06a]. Deshalb muss der Serviceanbieter
nicht immer zwangsläufig auch der Ersteller des Services sein, so dass
die Rolle des Serviceentwicklers ebenfalls von Bedeutung ist. Diese Arbeit betrachtet
eine nach Abbildung 2.1 entsprechend erweiterte Darstellung des klassischen SOA-
Dreiecks [Pap03].
Definition 2.6
Die von einem Serviceentwickler erstellte Implementierung eines Services heißt Serviceimplementierung.
Durch die Kenntnis von Services ist es möglich eine serviceorientierte Architektur zu
definieren. Diese stützt sich auf Abbildung 2.1 und das erweiterte SOA-Dreieck. Genauer
ist das Zusammenspiel aller beteiligten Rollen die Kerneigenschaft einer SOA.
9

2. Grundlagen
Serviceregister
Veröffentlichen
Finden
Servicekonsument
Binden und
Aufrufen
Bereitstellen
Serviceanbieter
Serviceentwickler
Abbildung 2.1.: Erweitertes SOA-Dreieck
Definition 2.7
Eine serviceorientierte Architektur (SOA) ist die Strukturierung einer Lösung nach
dem erweiterten SOA-Dreieck.
2.2.2. Konsequenzen
Zum Verständnis dieser Arbeit ist es notwendig, einige Besonderheiten und Konsequenzen
aus dem Einsatz einer SOA zu kennen. Dabei ergibt sich eine Konsequenz
nicht immer unmittelbar aus vorhergehenden Definitionen, sondern entsteht durch den
praktischen Einsatz einer SOA.
Das erweiterte SOA-Dreieck trifft keine Aussagen darüber wie die Serviceimplementierung
umgesetzt wird. Insbesondere beim Serviceanbieter wird sie wie eine Black-Box
behandelt. Wenn ein Service jedoch wieder selbst zu einem Servicekonsument wird,
entsteht ein Verbund von Services.
Konsequenz 2.1
Eine Serviceimplementierung kann Services nutzen. Ein Szenario, indem ein Service
durch das Zusammenschalten von Services entsteht, wird als Komposition bezeichnet
[Yan03]. SOA begünstigt dadurch Flexibilität, indem auf Änderungen durch den
Einsatz von alternativen Services reagiert werden kann [GP06]. Kompositionen werden
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 Kompositionen
zu motivieren.
Beispiel 2.3
Ein Reisebüro bucht einen Ausflug für einen Kunden. Als Erstes sucht das Reisebüro
Flüge bei verschiedenen Fluggesellschaften für das gewünschte Datum. Danach bucht
das 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üro
diesen 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 Unternehmens.
Während der Geschäftsprozess abgearbeitet wird, ist das Reisebüro ein
Servicekonsument und Fluggesellschaften, Hotels, . . . sind Serviceanbieter. Dabei will
das Reisebüro die einzelnen Aktivitäten im Geschäftsprozess automatisiert ausführen.
Zur Interaktion mit einem Service muss der Servicekonsument den Aufbau der Nachrichten
kennen, die ein Service erwartet. Folglich muss der Servicekonsument auch
die Servicebeschreibung des Services kennen.
Konsequenz 2.2
Auf der Seite des Servicekonsumenten kommt häufig, wenn auch nicht zwingend notwendig,
das „Proxy“-Entwurfsmuster [GHJV95] zum Einsatz [Sta06a]. Ein generierter
Proxy findet, bindet und benutzt dabei einen Service [MTSM03].
Der Einsatz eines Proxy auf Seiten des Servicekonsumenten vereinfacht die Kommunikation
mit dem Service, wenn dieser Proxy automatisch generiert wird. Dazu ist unter
Anwendung der Servicebeschreibung gezielt die Serviceschnittstelle auszuwerten.
Konsequenz 2.3
In der objektorientierten Programmierung müssen Objekte erst instanziiert werden bevor
man mit ihnen interagieren kann. Hingegen interagiert der Servicekonsument mit
einem bereits existierenden Service. [OAS06]
Durch die Unkenntnis der Serviceinstanz hat der Servicekonsument keine direkte Kontrolle
über einen Service, sondern kann nur mit ihm interagieren.
Konsequenz 2.4
Erst durch die Bereitstellung in einem Container, kann mit einem Service interagiert
werden. D.h. der Vorgang der Bereitstellung macht aus einer Serviceimplementierung
einen Service.
Insbesondere verwaltet ein Container die Serviceinstanz.
Konsequenz 2.5
Die SOA Infrastruktur ist zunächst zustandslos [Sta06a]. Folglich ist zwischen mehreren
Interaktionen mit einem Service nicht garantiert, dass es sich um die selbe Serviceinstanz
handelt. Auf Seiten des Serviceanbieters sind z.B. Wechsel der Serviceinstanz
durch den Einsatz von Service-Pools denkbar [Sta06a].
Servicekonsumenten können an einen Service nahezu beliebige Nachrichten mit beliebigem
Inhalt senden. Entweder wird die Nachricht verworfen oder aber ausgewertet
und erhaltene Daten an die Serviceimplementierung weitergereicht.
11

2. Grundlagen
Konsequenz 2.6
SOA minimiert Annahmen an das Vertrauen [OAS06]. Daher benötigt ein Service eine
qualitativ hochwertige Implementierung und Dokumentation, um Wiederverwendbarkeit
und Unabhängigkeit zu garantieren.
2.3. Plattformen für Unternehmensanwendungen
Eine SOA wird häufig unter Einsatz einer Plattform zur Realisierung von serverseitigen
Anwendungen umgesetzt. Bei der Betrachtung mehrerer Plattform wird ein einheitlicher
Sprachschatz notwendig. Zur Herleitung sei zunächst die Java Enterprise Edition
(Java EE) herangezogen und die Begriffe nach [JBC + 07] mit neutraler Namensgebung
kurz vorgestellt:
• Applikationen werden aus Enterprise Komponenten aufgebaut.
• Ein Container bildet die Schnittstelle zwischen einer Enterprise Komponente
und einer plattformspezifischen Implementierung zur Unterstützung der Enterprise
Komponente. D.h. erst durch einen Container wird eine Enterprise Komponente
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 Container
heiß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 Versionen
seien in dieser Arbeit Java EE 5.0 und .NET 2.0 angenommen.
Im Folgenden sei eine Auswahl von verfügbaren Web Containern bzw. Applikationsservern
angegeben:
• Java EE: Apache Tomcat (Web Container), JBOSS (Applikationsserver).
• .NET: ASP.NET Development Server (Web Container), Internet Information Services
(Applikationsserver)
2.4. Webservices
2.4.1. Grundbegriffe
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 Simple
Object Access Protocol kodiert sind (SOAP). Das verwendete Protokoll zur Übertragung
dieser Nachrichten wird in der Serviceschnittstelle festgelegt. Sowohl die WSDL,
als auch SOAP basieren auf XML und sind somit auf mehreren Plattformen einsetzbar.
Das Protokoll zum Auffinden von Webservices ist für den Verlauf dieser Arbeit
unerheblich 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ückgabewert
jeder Operation definiert.
Heutzutage werden Webservices oftmals mit Enterprise Plattformen durch Erstellung
einer Enterprise Komponente implementiert. Dabei verbirgt die eingesetzte Entwicklungsumgebung
und Enterprise Plattform die Komplexität bei der Erstellung eines
Webservices. In Java EE und analog in .NET erstellt der Entwickler einen Webservice
mit Klassen, die durch zusätzliche Metainformationen so annotiert werden [JBC + 07],
dass ein Web Container automatisch die Serviceschnittstelle generiert. Zur Kommunikation
und Interaktion wird ein Proxy eingesetzt, der den Austausch von SOAP-
Nachrichten versteckt [MTSM03]. Abbildung 2.2 zeigt eine typische Architektur von
Enterprise Komponenten, die einen Webservice implementieren.
Konsument
Dienstschnittstellenschicht
Servicevertrag
Kommunikation
Betriebsmanagement
Sicherheit
Geschäftsschicht
Geschäftslogik
Serviceadapter
Geschäftsworkflow
Geschäftselemente
Ressourcenzugriffsschicht
Datenzugriffslogik
Dienstagenten
Service
Datenquellen
Services
Abbildung 2.2.: Webservice Referenzarchitektur [Sko06]
13

2. Grundlagen
Webservices stellen die Konkretisierung einer SOA dar, so dass neue Konsequenzen
entstehen.
Konsequenz 2.7
Viele Unternehmen setzen Webservices ohne Serviceregister ein [MTSM03], d.h. die
Vollständigkeit bei der Implementierung einer SOA variiert.
Ein Serviceregister erlaubt z.B. den Serviceanbieter zu wechseln, ohne dass ein Servicekonsument
Änderungen in seiner Applikation vornehmen muss. Dennoch erhalten
Kunden oft direkt die Endpunkte von Webservices.
Konsequenz 2.8
Webservices werden in verteilten Anwendungen eingesetzt, d.h. die Interaktion mit
einem Webservice ist entfernt.
Jeder Webservice repräsentiert mehrere entfernte Prozeduren. Dabei erfolgt nach Definition
2.5 die Interaktion mit einem Webservice über Nachrichten.
2.4.2. Webservice Standards
Neben Standards, die grundlegende Eigenschaften für Webservices festlegen, erfordern
bestimmte Anforderungen an die Kommunikation Erweiterungen des SOAP und
der WSDL. Webservice Standards zur interoperablen Realisierung von z.B. Sicherheit
oder Transaktionen adressieren dieses Problem. Für den Verlauf dieser Arbeit ist
nur die Kenntnis von Webservice Standards relevant, spezielle Eigenschaften sind zu
vernachlässigen.
2.5. Zusammenfassung
In diesem Kapitel wurden alle notwendige Grundlagen und Begriffe vorgestellt, die für
den 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 Testens
und SOA zu vereinen, um eine Teststrategie für eine SOA zu definieren. Im Allgemeinen
präsentieren die folgenden Kapitel alle Konzepte, Ergebnisse und Werkzeuge, die
im Rahmen dieser Arbeit entstanden sind.
14

3. Ableitung einer Teststrategie für
serviceorientierte Architekturen
Bevor man eine Teststrategie für eine SOA formulieren kann, sind alle Einflüsse gezielt
zu identifizieren. Besonders die möglichen Variationen zur Realisierung einer SOA
erfordern zunächst ein allgemeines Vorgehen zur Findung der Teststrategie. Abschnitt
3.1 beschreibt das genaue Umfeld, das durch eine gefundene Teststrategie abgedeckt
wird und welche Besonderheiten zu ignorieren sind.
Services bilden als aktive Einheiten den Kern einer SOA, indem sie Funktionalitäten
zur Verfügung stellen. Die Betrachtung von Teststufen in einer Teststrategie erfordert
neue Sichtweisen aufgrund der in Kapitel 2 vorgestellten Natur von Services.
Alle Überlegungen berücksichtigen die folgenden vier Anforderungen an eine Teststrategie
[KBP02]:
• Produktspezifisch: Eine produkt- und technologiespezifische Teststrategie ist
besser als eine allgemeine Teststrategie.
• Risikospezifisch: Die Teststrategie adressiert die wichtigsten Probleme.
• Vielfältig: Eine vielfältige Teststrategie setzt auf mehrere Testmethoden, um
Fehler zu finden, die eine andere Testmethode übersehen hat.
• Praktikabel: Die Teststrategie ist einsetzbar und schlägt nichts vor, dass jenseits
der 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 Einheiten
in einer SOA entstehen Fehlerquellen, die es gezielt zu identifizieren gilt. Die beiden
Hauptmerkmale einer SOA sind das SOA-Dreieck und als Konsequenz der Verbund
von Services zu Kompositionen.
Das erweiterte SOA-Dreieck aus Abbildung 2.1 hat vier Rollen aufgezeigt, von denen
jede Einfluss auf die Teststrategie nehmen kann. Die einzelnen Aktivitäten und Interessen
beim Testen stellen sich für jede Rolle wie folgt dar:
• Servicekonsument: Ein Servicekonsument prüft, ob das Finden eines Services
und die Interaktion mit ihm korrekt arbeiten.
• Serviceanbieter: Ein Serviceanbieter testet, ob die angebotene Infrastruktur den
Anforderungen zur Bereitstellung des Services genügt.
15

3. Ableitung einer Teststrategie für serviceorientierte Architekturen
• Serviceentwickler: Ein Serviceentwickler testet, ob der Service den funktionalen
Anforderungen genügt, qualitativ hochwertig ist und Fehler durch eingesetzte
Technologien vermieden werden.
Das Serviceregister wird in dieser Arbeit nicht betrachtet, weil
• es oftmals von Drittanbietern verwaltet wird. Ein Unternehmen, das Funktionalitäten
über einen Service anbietet, wird diesen Service solch einem Register
hinzufügen.
• Unternehmen setzen nach Konsequenz 2.7 oftmals kein Serviceregister ein und
stellen ihren Kunden direkt den Endpunkt eines Services zur Verfügung.
In dieser Arbeit betrachtete Teststrategien beschränken sich auf die Sicht des Serviceentwicklers
und Serviceanbieters, so dass als Testobjekte ein Service selbst und die
Serviceimplementierung betrachtet werden. Letztendlich wird ein Unternehmen, das
seine Leistungen über Services anbietet, genau diese zwei Sichten einnehmen.
Die Teststrategie verfolgt die folgenden Ziele:
• Eine qualitativ hochwertige Implementierung des Services sicherstellen. Es ist
nicht bekannt in welchem Umfeld und von wem eine Serviceimplementierung
genutzt wird. Insbesondere zielen Services auf Wiederverwendbarkeit und sollten
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 Aufmerksamkeit
erhalten. Hauptaugenmerk dieser Arbeit liegt nicht auf dem Testen von Kompositionen.
In Kapitel 8 werden Arbeiten und Werkzeuge angeführt, die sich ausschließlich
mit dieser Thematik befassen. Zusätzlich wird der Einfluss auf die Teststrategie
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 direkt
bei der Idee von SOA. Neben den verschiedenen Rollen, prägen auch die Konsequenzen
einer SOA die Idee.
2. Technologie: Webservices sind die bekannteste Technologie, um eine SOA zu
realisieren. Im Allgemeinen führen die technischen Besonderheiten und Konsequenzen
einer Technologie zu unterschiedlichen Problemen.
3. Plattform: Die Realisierung eines Effekts setzt eine Serviceimplementierung
voraus. In Abschnitt 2.3 wurden bekannte Plattformen eingeführt, mit denen eine
Serviceimplementierung realisiert werden kann. Jede Plattform hat seine eige-
16

3. Ableitung einer Teststrategie für serviceorientierte Architekturen
nen Besonderheiten, die zu neuen Problemen führen.
Abbildung 3.1 illustriert die drei Ebenen als ein Baukasten. Die konkrete Festlegung einer
einzelnen Ebene durch ein Produkt, das diese Ebene umsetzt, heißt Ausprägung
einer Ebene. Werden für eine SOA alle drei Ebenen durch eine Ausprägung festgelegt,
so heißt dieser Baukasten Ausprägung einer SOA. Auch wenn für die Technologie
mehrere Möglichkeiten denkbar sind, dominieren Webservices diese Ebene. Die
Idee einer SOA kann durch verschiedene Definitionen variieren, im weiteren Verlauf
dieser Arbeit sei jedoch die in Definition 2.7 definierte Idee angenommen und diese
Idee als SOA bezeichnet. Die Abgrenzung zwischen den Ebenen ist bewusst verzahnt
dargestellt, weil eine klare Abgrenzung oftmals nicht möglich ist.
Plattform
BPEL
Technologie
.NET
Webservice
Idee
Java EE
Serviceorientierte
Architektur
Abbildung 3.1.: Drei Ebenen von SOA
Die drei Ebenen nehmen auf die Anforderungen an eine Teststrategie Einfluss und
bilden Grundvoraussetzungen:
• Produktspezifisch: Eine in der Praxis umgesetzte SOA wird in allen drei Ebenen
Ausprägungen vorweisen. Umso mehr Ebenen berücksichtigt werden, um
so produktspezifischer ist eine Teststrategie.
• Risikospezifisch: Jede Ebene hat eigene Testaspekte, also eigene potentielle
Probleme, die auftreten können. Die Teststrategie muss eine Auswahl berücksichtigen,
um wichtige Probleme schnell zu identifizieren.
• Vielfältig: In jeder Ebene sind mehrere Testmethoden einzusetzen, um Fehler zu
finden.
• Praktikabel: Eine Teststrategie wird erst anwendbar, wenn sie eine Idee, Technologie
und Plattform aufweist. Kapitel 8 wird Ansätze aufzeigen, die eine eigene
Plattform schaffen und daher nur von der Technologie abhängig sind.
17

3. Ableitung einer Teststrategie für serviceorientierte Architekturen
3.2.2. Projektumfeld
Das Projektumfeld in dem ein Service entwickelt wird, beeinflusst die Teststrategie
maßgeblich. Im Speziellen handelt es sich um die folgenden Faktoren:
• Personal: Wer steht für Tests zur Verfügung? Setzen sich Teams nur aus Entwicklern
zusammen oder gibt es eine Testabteilung, deren Aufgabe nur im Finden von
Fehlern liegt? Auch Experten in bestimmten Fachbereichen, z.B. Performance
oder 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 der
Ableitung von Testfällen von Interesse sind? Welchem Prozess folgt die Software
in ihrem Lebenszyklus. Viele Vorgehensweisen sehen Tests vor, aber mit
unterschiedlichen Ausprägungen und Motivationen.
Wird das Projektumfeld bei der Formulierung einer Teststrategie vernachlässigt, läuft
man 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], wobei
der Ort eines Services durch den Serviceanbieter festgelegt wird. Jeder Test muss
diesen Ort kennen, um praktisch umsetzbar zu sein. Denn ein Test übernimmt die
Sicht eines Servicekonsumenten und interagiert nach Konsequenz 2.3 immer mit einer
bereits existierenden Instanz eines Services.
Beispiel 3.1
Sei als Technologie Webservices angenommen und als Plattform Java EE, so wird ein
Webservice als Klasse implementiert und mit Metadaten annotiert. Ein Web Container,
z.B. der Apache Tomcat mit der Apache AXIS Erweiterung, erstellt für diese Klasse
eine Serviceschnittstelle und ermöglicht die Interaktion mit dem Webservice.
Ein Service existiert immer in einer Serviceumgebung. In dieser Arbeit werden insgesamt
vier Serviceumgebungen definiert. Dazu sei zunächst eine Umgebung betrachtet,
die unabhängig von SOA ist und durch die Plattform festgelegt wird:
• lokal: Ein Service liegt nur in seiner Serviceimplementierung vor und kann nach
Konsequenz 2.4 noch nicht als Service genutzt werden. Ist der Service mit einer
Enterprise Plattform implementiert, so liegt er in der Regel als Klasse vor.
18

3. Ableitung einer Teststrategie für serviceorientierte Architekturen
Die Bereitstellung in einer Umgebung erzeugt einen Service. Es existieren drei verschiedene
Varianten:
• lokal/entfernt: Ein Container wird lokal auf der Entwicklermaschine gestartet
und der Service wird für einen Test in dieser bereitgestellt. Ziel dieser Umgebung
ist entwicklungsnah einen Service zu testen.
• entfernt/test: Ein Container liegt auf einem Server entfernt in einem Netzwerk
und wird dort für einen Test bereitgestellt. Diese Serviceumgebung sollte der
späteren Produktivumgebung schon nahezu vollständig entsprechen. Es wird
versucht die Infrastruktur des Serviceanbieters zu Testzwecken nachzubilden
oder falls möglich direkt zu nutzen.
• entfernt/live: Ein Service wird über die letztendliche Produktivumgebung bereitgestellt.
Diese Serviceumgebung eignet sich im Allgemeinen nur bedingt zum
Testen.
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 agieren
und während oder kurz nach der Entwicklung durchgeführt werden. Sie sind
daher vorrangig in einer lokalen oder lokal/entfernen Serviceumgebung durchzuführen,
weil sie immer Änderungen an Komponenten erfordern. In einer entfernten
Serviceumgebung fehlt die notwendige Kontrolle über einen Service, um den
Austausch mit einer Komponente zu realisieren. Komponententests für Services
werden im Abschnitt 3.4 detailliert betrachtet.
• Integrationstests: Ähnlich wie Komponententests erfordern auch Integrationstests
Kontrolle über einen Service, so dass sie ebenfalls vorrangig in einer lokalen
oder lokal/entfernten Serviceumgebung durchzuführen sind.
• Systemtests: Die Betrachtung eines Services mit Systemsicht erfordert keine
Kontrolle über den Service. Die entfernt/test Serviceumgebung ist daher für diese
Art des Testens vorgesehen. Insbesondere erlaubt sie auf Seite des Serviceanbieters
zu testen.
3.3.2. Vorgehensweise
Eine Teststrategie kann in mehreren Projekten angewandt werden. Allerdings ist für
jedes 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 individuelle
Ausprägungen in allen Ebenen aufweisen. Die Durchführung von Tests
verlangt dieses Umfeld genau zu kennen.
2. Identifikation von Testaspekten für jede Ausprägung einer Ebene: Die Kenntnis
von Testaspekten erlaubt in der Teststrategie schon den Testraum einzuschränken
und liefert Anhaltspunkte über die Fehler, die es zu finden gilt. Somit
19

3. Ableitung einer Teststrategie für serviceorientierte Architekturen
sind für jede Ausprägung einer Ebene Testaspekte zu ermitteln und zunächst
formlos niederzuschreiben.
3. Analyse des Projektumfelds: Jeder Testaspekt lässt sich erst adressieren, wenn
die Rahmenbedingungen eines Projekts bekannt sind.
4. Zuordnung aller Testaspekte zur Serviceumgebung: Wie in Abschnitt 3.3.1
beschrieben, legt die Testumgebung indirekt die Teststufe und das Testobjekt
fest. D.h. die Zuordnung eines Testaspekts zur Testumgebung definiert automatisch
in welchen Teststufen zu testen ist. Insbesondere gibt die Beziehung zwischen
einem Testaspekt und der Testumgebung schon Hinweise auf die Realisierung
des Tests.
5. Formulierung von Testszenarien: Abschnitt 3.3.3 wird Testszenarien vorstellen,
die es für eine Teststrategie zu formulieren gilt.
Der Nutzen der beschriebenen Vorgehensweise liegt im Erkennen von potentiellen
Problemen und der Zuordnung zu einem Testobjekt. Speziell fließt durch die konkrete
Zuordnung das Projektumfeld mit ein. Als Notation für die Zuordnung von Testaspekten
zu Serviceumgebungen wird in dieser Arbeit eine Tabelle eingesetzt. Dazu zeigt Tabelle
3.1 ein einfaches Beispiel. Die Serviceumgebungen entfernt/test und entfernt/live
sind 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 anzuordnen,
die bekannten und etablierten Praktiken entspricht. Sind die Tests während der
Entwicklung durchzuführen, so sollte die vorgeschlagene Reihenfolge die Reife des
Produkts berücksichtigen [KBP02]: mitfühlend, aggressiv, abwechslungsreich und zuletzt
sorgfältig. Speziell lässt sich durch die Reihenfolge z.B. die Aggressivität steuern,
indem man mit Buildverifikationstests [GP06] beginnt und zunehmend Negativtests
einbaut. Der Übergang zwischen den einzelnen Testaspekten lässt sich bei Bedarf um
Bedingungen oder Eingangs- und Ausgangskriterien erweitern.
Im Allgemeinen ist eine Tabelle, mit dem in Tabelle 3.1 dargestellten Aufbau, ein wichtiges
Produkt der ermittelten Teststrategie. Sie heißt Testmatrix und gibt einen Überblick
über das Vorgehen beim Testen. Die Nummer in der ersten Spalte dient zur Identifizierung
eines Testaspekts.
Die beschriebene Vorgehensweise führt zu einer Teststrategie, die aus drei Artefakten
besteht - in ihrer Entstehungsreihenfolge:
1. Eine Sammlung von Testaspekten
2. Eine Testmatrix
20

3. Ableitung einer Teststrategie für serviceorientierte Architekturen
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.2
illustrierte Vorlage entstanden. Sie beschreibt das Vorgehen zur Prüfung eines Testaspekts
und sei als Testszenario bezeichnet.
Nr. / Testaspekt
Tester
Serviceumgebung
Abdeckung
Risiken
Vorbedingungen
Durchführung
Mocks
Aktivitäten
Erfolgsbedingungen
Fehlschlagbedingungen
Die Nummer dieses Testszenarios und der Name des Testaspekts.
Die Nummer ist so zu wählen, dass sie mit der Nummer
des zugehörigen Testaspekts in der Testmatrix übereinstimmt.
Existieren mehrere Testszenarien für einen Testaspekt,
so ist die Nummer um Buchstaben zu erweitern, z.B.
1a, 1b, usw.
Die aktiven Tester, die den beschriebenen Testaspekt testen.
Die Umgebung, in der ein zu testender Service bereitgestellt
wird.
Die potentiellen Probleme, die dieses Testszenario findet.
Gegeben durch eine Beschreibung des Testaspekts.
Wird ein Testaspekt nicht getestet, können bestimmte Fehler
zu Konsequenzen führen, die ein Risiko darstellen.
Bedingungen, die vor der Durchführung dieses Testszenarios
gegeben sein müssen.
Wie ist dieser Test durchzuführen? Manuell oder automatisiert?
Gibt die in einem Service durch Mocks zu ersetzenden Teile
an, falls es sich um einen Komponententest handelt.
Eine Liste von durchzuführenden Aktivitäten.
Eine Liste von Bedingungen, von denen mindestens eine erfüllt
sein muss, damit dieses Testszenario als bestanden gilt.
Eine Liste von Bedingungen, von denen mindestens eine erfü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 Abschnitt
2.1.1 ein. Zur Definition des Testobjekts werden die Serviceumgebung und evtl.
21

3. Ableitung einer Teststrategie für serviceorientierte Architekturen
einzusetzende Mocks angeführt. Vorbedingungen stellen notwendige Voraussetzungen
an die Durchführung eines Testszenarios.
Die Automatisierung von Tests ist sinnvoll, doch nicht Grenzenlos [Bac99]. Es lohnt
sich nicht jeden Testaspekt automatisiert abzudecken. Ein Testszenario definiert daher,
ob ein Test manuell oder automatisiert durchzuführen ist.
Ein Testszenario stellt die handliche Beschreibung eines Testaspekts dar. Sie sollte
die Länge von einer DIN A4 Seite nicht überschreiten. So erhält der aktive Tester
die Möglichkeit ein Szenario z.B. neben seinen Monitor zu heften und seine aktuellen
Aktivitäten und Ziele immer im Blick zu haben.
Testszenarien sind noch keine Testfälle, sondern beschreiben nur wie diese abzuleiten
sind. Im Bezug auf die Testmatrix ist für jede Zeile und damit für jeden Testaspekt mindestens
ein Testszenario anzugeben. Insgesamt bilden Testszenarien einen wichtigen
Bestandteil der Teststrategie.
3.4. Komponententests für eine SOA
3.4.1. Vorgehen
Eine SOA erzwingt neue Sichtweisen beim Einsatz von Komponententests. Grundsätzlich
ist jeder Komponententest an mehrere Schritte gebunden, die systematisch
durchzuführen sind. Ist es nicht möglich einen dieser Schritte abzuarbeiten, so lässt
sich oftmals kein Komponententest erstellen.
1. Identifikation der eigentlichen Komponente. Dabei wird eine externe Sichtweise
auf ein System eingenommen und aktive Einheiten identifiziert, d.h. Komponenten
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 Quellcodes
oder andere Informationsquellen, die es erlauben teilnehmende Komponenten
abzuleiten.
3. Erstellen von Mocks für alle teilnehmenden Komponenten. Dieser Schritt erfordert
einen Entwurf, der die Erstellung von Mocks ermöglicht.
4. Austauschen aller teilnehmenden Komponenten durch die erstellten Mocks. In
diesem Vorgang wird eine Komponente manipuliert, so dass zusätzliche Grundvoraussetzungen
an die Testbarkeit entstehen. Lässt sich die Beziehung zu einer
Komponente nicht ändern, wird ein Komponententest unmöglich.
Beispiel 3.2
In der objektorientierten Programmierung sind die Klassen die Komponenten. Beziehungen
werden durch den Einsatz und die Interaktion mit Instanzenvariablen hergestellt.
Mocks lassen sich durch Vererbung oder Implementierung von Schnittstellen
schreiben. Der Austausch erfordert den Zugriff auf die Instanzenvariablen der Klasse.
22

3. Ableitung einer Teststrategie für serviceorientierte Architekturen
3.4.2. Identifikation der Komponente bei Services
Abbildung 3.2 illustriert, dass ein Service zwei unterschiedliche Realisierungen haben
kann:
• Ein Service wurde mit einer Enterprise Plattform und damit in einer objektorientierten
Programmiersprachen realisiert.
• Ein Service repräsentiert eine Komposition nach Konsequenz 2.1.
Ein Servicekonsument sieht bei der Interaktion keinen Unterschied in der Realisierung.
«interface»
Interface1
Class1
Class2
Abbildung 3.2.: Realisierungen eines Services
Beispiel 3.2 hat bereits dargelegt, dass in der objektorientierten Programmierung Klassen
die Komponenten sind. Die Identifikation der Komponente in einem Service erfordert
die Realisierung des Service zu kennen, denn die Form der Realisierung und die
Betrachtungsweise vererben die Komponente:
• Ist ein Service in einer objektorientierten Programmiersprache implementiert, so
sind die Komponenten Klassen.
• Ist ein Service als Komposition realisiert, so bilden Services die Komponenten.
Zusätzlich sind auch Mischformen denkbar, indem unter Einsatz einer objektorientierten
Programmiersprache Kompositionen erstellt werden.
3.4.3. Austauschen von Komponenten in Services
Nach der Identifikation der Komponente, sind für alle teilnehmenden Komponenten in
Abhängigkeit von der Realisierung Mocks zu schreiben. Sind Teile einer Komposition
durch Mocks auszutauschen, so müssen die Serviceimplementierungen von angesprochenen
Services geändert werden - die Serviceschnittstellen bleiben dabei erhalten.
Kapitel 8 wird Werkzeuge vorstellen, die bei der Erstellung von Mocks für Kompositionen
unterstützen. Der Austausch des Mocks erfolgt dabei mittels Änderung des
23

3. Ableitung einer Teststrategie für serviceorientierte Architekturen
zugehörigen Endpunkts im Serviceregister.
Betrachtet man nur einen Service an sich und keine Kompositionen, so werden Komponenten
durch die Plattform vererbt. Bei der Implementierung eines Services in Java
EE oder mit dem Microsoft .NET Framework, sind Mocks als Klassen zu implementieren.
Dabei hat die Serviceumgebung, in der ein zu testender Service existiert, Einfluss
auf den Einsatz von Mocks:
• lokal: Zur Laufzeit werden teilnehmende Komponenten durch Mocks ersetzt. Die
verwendeten Verfahren sind seit Jahren bekannt und werden insbesondere in
der testgetriebenen Entwicklung [Bec03] eingesetzt.
• lokal/entfernt: Sobald ein Service in einer entfernten Serviceumgebung verwaltet
wird, 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 der
lokalen Serviceumgebung eine Komponente zur Laufzeit auszutauschen.
Diese Arbeit schlägt neue Ansätze zum Einsatz von Mocks in einem Service vor. Durch
den Vorgang der Bereitstellung hat ein Tester keinen Zugriff mehr auf die Instanz des
Services, so dass jede Änderung am Service vor der Bereitstellung erfolgen muss.
Insbesondere nach Konsequenz 2.2 wird auch ein Tester evtl. nur über einen Proxy
mit dem Service kommunizieren.
Diese Arbeit verfolgt zwei verschiedene Ansätze zur Realisierung von Mocks. Dazu sei
angenommen, dass eine Klasse in einer Datei definiert wird und zur Laufzeit als ein
Objekt instanziiert wird.
• Weicher Mock: Bei nach bekannten Methoden umgesetzten Komponententests
wird zur Laufzeit ein Objekt ausgetauscht. Die Realisierung eines Mocks erfolgt
in einer Klasse durch Implementierung einer Schnittstelle oder mittels Vererbung.
Der Austausch einer Komponente geschieht durch das Setzen des Mocks in
einer Instanzenvariable. Abbildung 3.3 zeigt dazu ein Beispiel.
In einer lokal/entfernten Umgebung fehlt der Zugriff auf die Instanz eines Service,
so dass das in Abbildung 3.3 aufgezeigte Vorgehen nicht anwendbar ist.
Als Lösung ist der Service vor seiner Bereitstellung, um entsprechende Logik
zum Austauschen durch Mocks zu erweitern. Hierzu ist auch die Interaktion so
zu ändern, dass vor jedem Benutzen des Services ein Austausch durch Mocks
vorgenommen wird. D.h. die Zeilen 9 und 10 aus Abbildung 3.3 sind Teil des
Services.
Im Allgemeinen sei dieser Vorgang als weich bezeichnet, weil keine tatsächliche
Definition einer Klasse geändert wird. Der Austausch durch Mocks erfolgt erst
zur Laufzeit und betrifft nur ein Objekt.
24

3. Ableitung einer Teststrategie für serviceorientierte Architekturen
1 public class ServiceTest {
2 private class SubSystemMock {
3 public void Invoke ( ) {
4 . . .
5 }
6 }
7
8 public void Test ( ) {
9 Service underTest = new Service ( ) ;
10 underTest . SubSystem = new SubSystemMock ( ) ;
11
12 . . .
13 }
14 }
Abbildung 3.3.: Umsetzung eines weichen Mocks
• Harter Mock: Immer wenn ein Programmierer kurzzeitig einen Teil im Quellcode
auskommentiert, um einen bestimmten Aspekt der Software zu prüfen, fügt der
Programmierer im weitesten Sinne einen Mock ein. Ändert man die Definition
einer teilnehmenden Komponente direkt in der zugehörigen Datei, so sind zur
Laufzeit keine weiteren Maßnahmen mehr durchzuführen. Man arbeitet so lange
mit einem Mock bis alle Änderungen wieder rückgängig gemacht wurden. Dieser
Vorgang 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 Testlaufs
einen harten Mock in einem Service einzusetzen. In der objektorientierten Programmierung
und bekannten Komponententests ist dies nicht während des Testlaufs
möglich, weil alle Informationen zur Kompilierzeit bekannt sein müssen.
Abbildung 3.4 zeigt ein Beispiel, das die Logik einer teilnehmenden Komponente
direkt ä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 = " " ;
4
5 . . .
6
7 return r e s u l t ;
8 }
9 }
1 public class Component {
2 public s t r i n g Do ( ) {
3
4
5
6
7 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.5
und 5.6 eingegangen.
25

3. Ableitung einer Teststrategie für serviceorientierte Architekturen
3.5. Zusammenfassung
Eine anfängliche Einordnung der Teststrategie hat ihren Fokus gezielt eingeschränkt:
• Die Teststrategie betrachtet nur Services aus der Sicht des Serviceanbieters und
Serviceentwicklers, d.h. das Serviceregister sei vernachlässigt.
• Kompositionen sind kein primärer Bestandteil der Teststrategie und werden erst
in 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, die
aus einer Beschreibung von Testaspekten, einer Testmatrix, sowie Testszenarien
besteht.
Zuletzt sind die Probleme und Lösungsansätze beim Einsatz von Komponententests
in Abschnitt 3.4 vorgestellt. Weiche oder harte Mocks ermöglichen die Komponenten
in einem Service gezielt auszutauschen.
Zur Findung einer konkreten Teststrategie für SOA werden im folgenden Kapitel die
ersten 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. Webservices
bilden dabei die am weitesten verbreitete Technologie und als Plattform findet
man häufig Enterprise Plattformen vor. Bevor die Formulierung einer Teststrategie
möglich ist, sind für jede Ebene nach Kapitel 3 Testaspekte abzuleiten. Daher wird
in 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 dominierende
Technologie einer SOA erlauben die Wiederverwendung der Testaspekte
in vielen anderen Projekten. .NET ist sehr verwandt mit Java EE, so dass abgeleitete
Testaspekte beide Plattformen betreffen.
Durch die gewählte Ausprägung entsteht das in Abbildung 4.2 dargestellte Umfeld, in
dem es zu Testen gilt. Speziell auf Seiten des Servicekonsumenten wird ein Proxy
nach Konsequenz 2.2 eingesetzt. Der Serviceanbieter stellt einen Web Container zur
Verfü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 eingesetzt
und erlaubt Webapplikationen zu testen.
• Internet Information Services (IIS): Ein Applikationsserver, der für Produktivsysteme
genutzt wird.
27

4. Testaspekte für SOA, Webservices und .NET
Implementierung
Serviceimplementierung
Serviceproxy
Benutzen
(SOAP)
W
S
D
L
implementiert
(Java, .NET, ...)
Serviceentwickler
Servicekonsument
Web Container
Serviceanbieter
Abbildung 4.2.: Webservice Umfeld
4.1. Identifikation von Testaspekten
In den folgenden Abschnitten werden zunächst Testaspekte für die Idee, Technologie
und Plattform identifiziert. Dazu wird jeder Testaspekt über seine potentiellen Probleme
definiert. Im Rahmen dieser Arbeit wurde für jeden Testaspekt eine Vorgehensweise
zum Auffinden von Fehlern entwickelt. Die Beschreibung der Vorgehensweise stützt
sich falls möglich auf Testmethoden aus Abschnitt 2.1.2. Existieren keine bekannten
Testmethoden wird das allgemeine Vorgehen zum Auffinden von Fehlern beschrieben.
Aufgrund der Verflechtung der einzelnen Ebenen einer SOA, ist es nicht immer möglich
Testaspekte unabhängig und isoliert anzugeben. Allgemein sind die dargelegten Testaspekte
nur als Auswahl anzusehen. Einige potentiellen Probleme, die Testaspekte
repräsentieren, sind bereits durch angeführte Literatur bekannt, andere ergeben sich
aus 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 die
Interaktion mit einem Service, also die Beziehung zwischen Servicekonsument und
Serviceanbieter, ist dabei von Interesse. Es ergeben sich die folgenden Testaspekte:
• Annahmen an Eingabedaten: Nach Konsequenz 2.6 minimiert ein Service die
Annahmen an das Vertrauen, so dass alle Eingabedaten in einem Service zu
prüfen sind. Insbesondere ist nie bekannt in welchem Umfeld oder auf welcher
Tiefe in einer Komposition ein Service eingesetzt wird. Dabei können sowohl
der Servicekonsument, als auch andere Services, im Allgemeinen immer wenn
Nachrichten ausgetauscht werden, ungültige Daten liefern.
Jedes Datenelement hat eine Semantik, die entweder implizit angenommen oder
explizit 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

4. Testaspekte für SOA, Webservices und .NET
ne Datenprüfung vornehmen, meistens schon während der Eingabe. Durch z.B.
den Wegfall von Benutzeroberflächen bei Webservices muss jeder übergebene
Parameter explizit durch den Service validiert werden. Fehlt eine Prüfung der
Eingabedaten kann nicht vorhersehbares Verhalten auftreten.
Um die potentiellen Probleme dieses Testaspekts zu finden ist zunächst eine
Analyse unter Anwendung der Testmethode Equivalence partitioning durchzuführen:
1. Für alle möglichen Daten, die an einen Service gestellt werden, sind Äquivalenzklassen
bezüglich gültigen und ungültigen Werten zu bestimmen. Im
Speziellen sind dies Analysen für alle Eingabedaten eines Servicekonsumenten
und alle Ausgabedaten eines genutzten Service. Quellen zur Festlegung
dieser Äquivalenzklassen können Spezifikationen, White-Box Analysen
oder Gespräche mit Entwicklern sein.
2. Aus den ermittelten Äquivalenzklassen lassen sich Repräsentanten auswählen,
so dass gezielt Matrizen für Negativ- und Positivtests entstehen.
Tabelle 4.1 zeigt ein einfaches Beispiel für mögliche Äquivalenzklassen und ausgewählte
Repräsentanten. Die Überprüfung von Grenzen sei dabei an dieser
Stelle 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, so
dass alle nicht benötigten Teile durch Mocks zu ersetzen sind. Erst wenn Daten
nicht überprüft werden, sind Mocks zu entfernen, um das Verhalten des Systems
zu beobachten. Aus Sicht des Servicekonsumenten kann unter Verwendung
der ausgewählten Repräsentanten entsprechend mit dem Service interagiert
werden. Datenflüsse aus Richtung eines anderen Services erfordern, dass
ein Service zu erstellen ist, der diese Werte zur Verfügung stellt. Dazu stehen
für Webservices Werkzeuge zur Verfügung, die auch bei Kompositionen zum Erstellen
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 und
liefert eine Fehlermeldung, so ist ein Test bestanden, ansonsten nicht.
Bei Verletzung von Randbedingungen kann es zu Problemen bei der Verarbeitung
und Speicherung kommen [KBP02]. Speziell durch die Integration in Geschäftsprozessen
sind ungültige Daten sehr realistisch und Fehler durch deren
29

4. Testaspekte für SOA, Webservices und .NET
Verarbeitung schwer ausfindig zu machen.
• Interoperabilität [App07]: Wenn die Technologie zur Realisierung einer SOA
bekannt 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 einer
eingeschränkten Anzahl von Servicekonsumenten zur Verfügung.
WS-I [The06] ist ein Standard, um Interoperabilität für Webservices zu definieren.
Werden Webservices als Technologie eingesetzt, ist eine Überprüfung auf
Interoperabilitä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 Interaktion
mit dem Service durchzuführen. Voraussetzung ist jedoch immer die
Kenntnis einer Technologie.
• Rückwärtskompatibilität [App07]: Wenn sich die Serviceimplementierung ändert,
muss die Serviceschnittstelle unverändert bleiben. Jede Änderung an der
Serviceschnittstelle zieht Änderungen bei allen Servicekonsumenten nach sich.
Auch wenn die Erstellung eines neuen Proxy heutzutage einfach durchzuführen
ist, resultieren aus einer Änderung an der Serviceschnittstelle evtl. auch Änderungen
im Verhalten.
Grundsätzlich muss nur auf Rückwärtskompatibilität geprüft werden, wenn eine
öffentlich zugängliche Version des Services existiert. Immer, wenn eine neue
Version des Services entsteht, ist ein Proxy für den aktuellen Produktiv-Service
zu erstellen und in jedem automatisierten Test einzusetzen. D.h. unter Anwendung
der Testmethode Regression testing sind alle existierenden Tests mit einem
neuen Proxy erneut auszuführen.
• Sicherheit [App07]: Ist das Universum von Benutzern, die mit einem Service interagieren
dürfen, begrenzt, müssen Maßnahmen zur Absicherung ergriffen werden.
Allgemein ist sicherzustellen, dass ein Service nur wie vorgesehen genutzt
werden kann und ein Ausnutzen jeglicher Art unmöglich ist. Die Auswirkungen
bei 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 Sicherheit
korrekt implementiert sind.
2. Ein Tester prüft, ob festgelegte Sicherheitsanforderungen eingehalten werden.
3. Ein Tiger Team [Bur03] führt Angriffe auf den Service durch, um Sicherheitslücken
aufzudecken.
4. Benutzer nehmen an einem Wettbewerb Teil, um Sicherheitslücken in einem
Service zu finden.
30

4. Testaspekte für SOA, Webservices und .NET
Nach Abschnitt 3.3.2 folgt nach der Ermittlung aller Testaspekte die Zuordnung
in einer Testmatrix. Für diesen Testaspekt ist dabei die Zuordnung variabel, weil
sie vom gewählten aktiven Tester abhängt. D.h. die Testmatrix spiegelt die Vorgehensweise
zum Auffinden von potentiellen Problemen grob wieder; mindestens
ein Testszenario für jede Zeile wird das genaue Vorgehen festlegen. Tabelle 4.2
illustriert für diesen Testaspekt die Auswirkungen der verschiedenen Rollen auf
die 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. In
Abschnitt 8.2 wird auf eine Veröffentlichung verwiesen, die sich speziell mit der
Sicherheit von Webservices befasst. Dabei geht es hauptsächlich um die potentiellen
Probleme, die sich hinter diesem Testaspekt verbergen.
• Funktionalität: Jeder Service bietet Dienste an, auf die sich ein Servicekonsument
verlässt. Services können Effekte in der realen Welt bewirken und erfordern
eine qualitativ hochwertige Implementierung.
Das Vorhandensein und die Korrektheit von Funktionalität zu verifizieren, ist
durch das Testen der Serviceimplementierung mit einer White-Box Sichtweise
möglich 1 . Einzusetzende Testmethoden sind Statement and branch coverage
und Regression testing. D.h. durch die Tests sind Funktionalitäten zu überprüfen,
so dass eine hohe Anweisungs- und Zweigabdeckung entsteht. Die Automatisierung
dieser Tests erlaubt alle Tests nach Änderungen erneut auszuführen.
Ein Service ist eine existierende Einheit, mit der ein Servicekonsument interagiert.
Liegt eine Servicedokumentation vor, so ist jede beschriebene Funktionalität
unter Anwendung der Testmethoden Function testing und Specificationbased
testing zu testen.
• Last- und Performanceverhalten: Auf Seiten des Serviceanbieters müssen die
Kapazitäten ausreichen, um einen Service bereit zu stellen. Unter Anwendung
der Testmethoden Load testing, Performance testing und Long sequence testing
ist zu verifizieren, dass Anforderungen an das Lastverhalten durch die Infrastruktur
erfüllt werden [CP06]. Zusätzlich sind nach [Par06] bereits während der
Entwicklung Lasttests durchzuführen, um Fehler in der Serviceimplementierung
früh zu finden.
1 Liegt die Serviceimplementierung in einer objektorientierten Programmiersprache vor, so sind z.B. aus
der testgetriebenen Entwicklung [Bec03] bekannte Komponententests anwendbar.
31

4. Testaspekte für SOA, Webservices und .NET
4.1.2. Webservices als Technologie
Webservices sind eine Technologie, die Dienste über Operationen anbietet. Ein Servicekonsument
ruft eine Operation durch Angabe von Parametern in einer SOAP-
Nachricht auf. Als Ergebnis entsteht ein implementierter Effekt und der Webservice
schickt eine SOAP-Nachricht an den Servicekonsumenten zurück. Abbildung 4.3 illustriert
die Interaktion mit einem Webservice.
Servicekonsument
Webservice
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-Nachrichten
ausgetauscht werden, ist zu prüfen, ob die Nachrichten wohlgeformt sind. Speziell
arbeiten Plattformen intern nicht direkt mit XML, so dass eine Serialisierung
notwendig wird. Durch diesen Vorgang können neue Fehler entstehen, die es
gezielt zu finden gilt.
Die Verifizierung der Datentransferobjekte erfordert alle Objekte, die in Parametern
oder Rückgaben übermittelt werden, vollständig aufzulösen und nach XML
zu übersetzen. Es werden die folgenden Fehler gesucht:
– Datentypen lassen sich nicht nach XML übersetzen und sind daher nicht
verwendbar.
– Unmögliche in XML darstellbare Eigenschaften verhindern eine Übersetzung,
z.B. bidirektionale Abhängigkeiten oder allgemein zirkuläre Abhängigkeiten.
– Notwendige Informationen zur Übersetzung wurden nicht zur Verfügung gestellt.
Zur Durchführung des Tests werden nur die Datentransferobjekte benötigt. Hat
man Zugriff auf den XML-Serialisierer, so sind alle Datentransferobjekte zu bauen
und serialisieren. Treten keine Fehler auf und das ursprüngliche Objekt stimmt
mit seiner deserialisierten Version überein, so ist dieser Test bestanden. Zusätz-
32

4. Testaspekte für SOA, Webservices und .NET
lich existieren Werkzeuge, die eine automatische Überprüfung einer WSDL erlauben
[Par06].
• Webservice Standards: In Abschnitt 2.4.2 wurden Webservice Standards erwähnt,
die erweiterte Funktionalitäten zur Verfügung stellen. Die korrekte Installation
und Benutzung dieser Standards ist zu testen, weil Fehler einen Service
unbrauchbar machen können. Dieser Testaspekt ist sehr verwandt mit dem Testaspekt
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 Prozess
in Windows bereitgestellt werden. Die Bereitstellung benötigt ein zunächst hergestelltes
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 Tests
unterzogen zu werden, sind leichtgewichtige Überprüfungstests durchzuführen.
Unter Einsatz der Testmethode Smoke testing ist zu prüfen, ob ein implementierter
Service überhaupt grundlegend funktioniert.
Durch den Einsatz eines Containers, einer Plattform und Konfigurationen können
eine Vielzahl von möglichen Fehlern auftreten. Ziel der Überprüfung ist festzustellen,
ob die Bereitstellung erfolgreich war und der Service seine Dienste
anbietet.
Subsysteme sind durch Mocks auszutauschen. Andernfalls ist sicherzustellen,
dass alle Subsysteme verfügbar sind. Grundsätzlich erfolgt dieser Test durch
gezielte Interaktion mit einem Service, so dass möglichst viele einfache Pfade
im Service durchlaufen und Subsysteme angesprochen werden. Pfade können
unter Einsatz der Testmethode Path testing gefunden werden.
Die Korrektheit des Effekts ist bei diesem Test nicht relevant und ist durch andere
Testaspekte abzudecken. Verifikationstests sind zu automatisieren, um nach der
Testmethode Regression testing immer wieder einsetzbar zu sein.
• Konfigurationen: Bei der Realisierung von Enterprise Komponenten werden
Konfigurationen eingesetzt, um Teile des Services gezielt maßzuschneidern. Ein
Deployment kann dabei unterschiedliche Konfigurationen enthalten. Besonders
häufig werden verschiedene Konfigurationen eingesetzt, um einen Build in einer
anderen 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 bestimmte
Funktionalitäten zu realisieren.
– Anpassen des Verhaltens des eingesetzten Containers.
33

4. Testaspekte für SOA, Webservices und .NET
Jede Konfiguration trägt einen Effekt bei, dessen Eintritt zu prüfen ist. Einzusetzen
ist dabei die Testmethode Path testing, um möglichst viele Pfade zu identifizieren,
die von der Konfiguration betroffen sind.
Neben dem Auffinden von fehlerhaften Konfigurationen, betrifft dieser Testaspekt
auch unterschiedliche Konfigurationen. Ist vorgesehen einen Service in z.B. mehreren
verschiedenen Containern oder mit unterschiedlichen Subsystemen zu
nutzen, entsteht ein Universum von Konfigurationen. Dabei ist jede Konfiguration
einzeln mittels Configuration coverage zu testen. Konfigurationstests sind im
Allgemeinen zu automatisieren [GP06] und unter Anwendung der Testmethode
Regression testing nach jeder Änderung auszuführen.
• Fehlendes Subsystem: Services benutzen Subsysteme, z.B. andere Services
oder Datenbanken. Fehlt eins dieser Subsysteme muss ein Service angemessen
reagieren, indem er eine sinnvolle Fehlermeldung liefert oder Alternativen sucht.
Bei der Durchführung ist der Zugriff auf bestimmte Systeme manuell unmöglich
zu machen und das Verhalten des Services zu überwachen.
• Versteckte Grenzen: Durch die Verwendung einer Schichtenarchitektur und unterschiedlicher
Subsysteme entstehen mehrere Grenzen, zwischen denen Objekte
ausgetauscht werden. Ändern sich die Datentypen oder Definitionsbereiche,
so kann ein Informationsverlust auftreten. Diese versteckten Verluste gilt es
zu identifizieren, damit ein Service mit beliebigen Daten arbeiten kann.
Zur Identifikation von versteckten Grenzen sind die folgenden zwei Schritte durchzuführen:
1. Identifikation aller potentiellen Grenzen. Grenzen entstehen zwischen einzelnen
Schichten in einer Schichtenarchitektur und beim Zugriff auf Subsysteme.
2. Für jede identifizierte Grenze ist für jedes Objekt, das über diese Grenze
ausgetauscht wird, der Datentyp bzw. aufgespannte Datenraum zu bestimmen.
Tabelle 4.3 zeigt beispielhaft ein Produkt der eben beschriebenen Analyse. Dabei
tritt 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 ermitteln,
die zu Fehlern führen können. Als hilfreiche Testmethode kann die Boundaryvalue
analysis eingesetzt werden. Testfälle nutzen diese Testdaten und versuchen
zu zeigen, dass aus der Datenreduktion fehlerhaftes Verhalten folgt.
34

4. Testaspekte für SOA, Webservices und .NET
Dieser Testaspekt repräsentiert einen vereinfachten Integrationstest. Die Grenzen
seien als versteckt bezeichnet, weil ein Servicekonsument nur die Serviceschnittstelle
sieht.
4.2. Analogien zu Java EE
Neben .NET sind heutzutage auch Webapplikationen mit Java EE sehr verbreitet. Die
Praktiken, mit denen dabei Applikationen erstellt werden, sind sehr verwandt. Daher
sind die vorgestellten Testaspekte aufgrund folgender Gründe auch für Java EE gültig:
• Die Bereitstellung eines Services findet durch einen Applikationsserver gleichermaßen
durch ein Deployment statt.
• Das Deployment setzt sich aus einem Build und einer Konfiguration zusammen.
• Architekturen sind ähnlich mit einer Schichtenarchitektur konstruiert nach Abbildung
2.2.
4.3. Zusammenfassung
Für jede Ausprägung einer Ebene sind Testaspekte ableitbar. In diesem Kapitel wurden
Testaspekte für Webservices, dem Microsoft .NET Framework und SOA selbst
vorgestellt. Die Formulierung einer Teststrategie ist zu diesem Zeitpunkt noch nicht
möglich, weil dazu das Projektumfeld fehlt.
Im folgenden Kapitel wird zunächst ein Werkzeug vorgestellt, das die Umsetzung von
Teststufen und Teststrategien ermöglicht. Erst im Rahmen der Fallstudie in Kapitel 6
finden die vorgestellten Testaspekte Anwendung und formen eine Teststrategie.
35

5. Werkzeugunterstützung für die
Teststrategie
Ist ein Testaspekt automatisiert zu testen, so wird ein Werkzeug zur Testdurchführung
notwendig. Allgemein wird in einer SOA ein Werkzeug für die praktikable Umsetzung
einer Teststrategie benötigt. Ähnlich wie eine Teststrategie, ist auch dieses Werkzeug
an die Ausprägung einer SOA gebunden.
Ein Werkzeug zur Unterstützung der Teststrategie muss die Realisierung von Serviceumgebungen
und Komponenten-, Integrations- und Systemtests direkt ermöglichen.
Speziell diese Arbeit wird Komponententests nach den in Abschnitt 3.4.3 vorgestellten
Ansätzen realisieren.
In diesem Kapitel wird zunächst allgemein ein Werkzeug vorgestellt, das sich auf
Webservices und eine Enterprise Plattform stützt. Ein konkret in dieser Arbeit entwickeltes
Werkzeug betrachtet die in Abbildung 5.1 illustrierte Ausprägung und wird
im 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 Serviceumgebungen
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 folgenden
Anforderungen:
• Erweiterung vorhandener Werkzeuge: Die Unterstützung fließt nahtlos in vorhandene
Unit Test Frameworks ein. Vorhandene Werkzeuge bieten Basisfunktionalitäten
für die Formulierung, Organisation, Ausführung und Auswertung von
Tests an. Sie sind seit Längerem erprobt und getestet. Zusätzlich sind Entwickler
mit den Werkzeugen vertraut, so dass der Einstieg beim Testen von Webservices
leichter fällt.
• Unabhängige Testläufe: Testläufe und die Tests selbst sind voneinander unabhängig.
In jedem Test ist es notwendig das Testobjekt zu kennen. Stellvertretend übernimmt
ein Proxy diese Funktion:
• Proxy-Integration: Ermöglichen der Interaktion mit einem Service durch Integration
eines Proxy-Objekts. Speziell der Endpunkt des Webservices muss beliebig
festlegbar sein.
Auch wenn das Verfassen von herkömmlichen Komponententests für die Serviceimplementierung
möglich ist, hat Abschnitt 3.4.3 neue Ansätze für Komponententests
aufgezeigt. Im Folgenden seien Anforderungen zum Verfassen von Komponententests
für Webservices vorgestellt:
• Realisierung von Mocks: Anbieten von Möglichkeiten zum Einsatz eines harten
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 mit
einem bestehenden Objekt interagiert. Durch die Bereitstellung in einem Web
Container ist es nicht mehr möglich von außen Einfluss auf einen Webservice zu
nehmen. Folglich muss ein Webservice vor der Bereitstellung manipuliert werden.
Dazu benötigt man eine aktive Verwaltung der Dateien aus denen sich ein
Deployment zusammensetzt. Insbesondere muss die kurzzeitige Manipulation
von Dateien und auch deren Inhalten einfach möglich sein, ohne dass sich die
realen 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 Serviceumgebung
und den Vorschriften zur Manipulation des Deployment zusammen.
In jedem Testlauf kann mit einer einzigartigen Mutation eines Webservices
gearbeitet werden.
• Aktive Bereitstellung: Durchführen einer Bereitstellung in einem Web Container,
um ein manipuliertes Deployment direkt testen zu können. Insbesondere
muss es möglich sein einen lokalen Web Container zu starten.
Das vorgestellte Werkzeug wird nur eine Erweiterung eines Unit Test Frameworks sein
und sei daher im weiteren Verlauf als Erweiterung bezeichnet.
37

5. Werkzeugunterstützung für die Teststrategie
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 Unit
Test Frameworks werden Testfälle als Code verfasst. Dabei ist jeder Testfall die
Methode einer Klasse und wird kompiliert. Dies erzwingt, dass alle benutzten Objekte
zur Kompilierzeit vorliegen müssen, so auch das Proxy-Objekt. Das Proxy-
Objekt ist als Stellvertreter zum eigentlichen Testobjekt, dem Webservice, zu
betrachten.
• Durch die Manipulation von Code zur Realisierung eines harten Mocks werden
Abhängigkeiten zur Sprache geschaffen. Im Rahmen dieser Arbeit sei C# als
Programmiersprache betrachtet.
5.1.3. Prozess
Ein Webservice durchläuft immer mehrere Schritte in der Entwicklung. Dies kann bewusst
und geplant passieren, aber auch zufällig aus der Notwendigkeit heraus. In jedem
Fall werden die folgenden Schritte immer in der angegeben Reihenfolge durchlaufen:
1. Verwaltung: Es muss eine übergeordnete Struktur erstellt werden, die den Webservice
verwaltet. Dies kann nur ein Verzeichnis mit Quelldateien sein, aber auch
umfangreichere Verwaltungsmöglichkeiten, wie z.B. Projekte, sind denkbar.
2. Entwicklung: Der Entwickler implementiert die Serviceimplementierung des Webservices.
3. Build: Der Entwickler veranlasst einen Build, der aus der Serviceimplementierung
ein Deployment erstellt. Oftmals existieren Skripte, die automatisiert einen
Build durchführen.
4. Bereitstellung: Das erzeugte Deployment wird auf einen Web Container übertragen
und der Webservice steht zur Interaktion bereit.
Ist das Testen von Webservices automatisiert zu unterstützen, so sind Teile der eben
genannten Punkte in die Automatisierung mit einzubeziehen. Es ist erst möglich mit
einem Webservice zu interagieren, wenn dieser vollständig und erfolgreich in einen
Web Container übertragen wurde.
Im Allgemeinen untergliedern sich automatisierte Tests in drei Phasen:
• Initialisierung: Vorbereitung eines Testobjekts und herstellen eines definierten
Zustandes.
• Testdurchführung: Durchführung des Tests am Testobjekt.
• Aufräumen: Wiederherstellen des Zustands vor der Initialisierung.
38

5. Werkzeugunterstützung für die Teststrategie
Abbildung 5.2 zeigt den durchlaufenden Prozess eines Tests für Services. Dieser Prozess
sei im Folgenden als Testprozess bezeichnet.
Verwaltung
Verwaltung
Build
Build
Rückgängigmachen aller
Aktivitäten der Initialisierung
Bereitstellung
Bereitstellung
Test
Test
Test
Abbildung 5.2.: Ablauf eines Tests für Services
Das im Rahmen dieser Arbeit entwickelte Werkzeug wird den vorgestellten Testprozess
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 geeignet
sind:
• 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 Microsoft
Visual Studio Team Edition für Softwareentwickler oder Tester ist ein vollständiges
Unit Test Framework enthalten.
In Rahmen dieser Arbeit ist das Unit Test Framework der Microsoft Visual Studio Team
Edition aus folgenden Gründen zu erweitern:
39

5. Werkzeugunterstützung für die Teststrategie
• Die Visual Studio Team Edition wird bei dem in Kapitel 6 vorgestellten Unternehmen
eingesetzt.
• Das Unit Test Framework ist nahtlos in die Entwicklungsumgebung von Visual
Studio integriert.
• Die Visual Studio Team Edition ermöglicht einen gesamten Entwicklungsprozess
und seine Artefakte zu verwalten [GP06]. Neben Testfällen an sich, ist es auch
möglich den Tests direkt die Ergebnisse von Testläufen und gefundene Bugs
zuzuordnen.
• 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 lokal
einen ASP.NET Development Server zu starten, über den ein Webservice bereitgestellt
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öglicht
die Interaktion mit einem Webservice, selbst wenn wenig technisches Verständnis
vorhanden ist.
Alle bekannten Ansätze und Werkzeuge haben gemeinsam, dass das Deployment immer
vor der Testdurchführung bekannt sein muss und auch eine Bereitstellung bereits
erfolgt sein muss. Es ist nicht möglich ein Deployment interaktiv während oder kurz
vor der Testdurchführung frei zu gestalten und diesen Vorgang für Regressionstests
aufzuheben. Als Konsequenz ist nach jedem Testlauf ein definierter Zustand herzustellen.
5.3. Architektur
5.3.1. Grobarchitektur
Die Architektur der Erweiterungen gliedert sich in drei Teilbereiche, die einzelne Funktionalitäten
beschreiben. Abbildung 5.3 gibt dazu eine Übersicht, wobei jeder Teilbereich
die folgenden Aufgaben übernimmt:
• Adapter: Enthält einen Adapter zum bestehenden Unit Test Framework und alle
Klassen, die eine Benutzerschnittstelle zu neu angebotenen Funktionalitäten
bilden. Dabei ist das Ziel die bisherige Testausführung um neue Funktionen zu
erweitern, die während der Initialisierung und dem Aufräumen abgearbeitet werden.
Der Adapter veranlasst alle weiteren Schritte, so dass der Testlauf an sich
um 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

5. Werkzeugunterstützung für die Teststrategie
vorhandene Besonderheiten berücksichtigt und die bestehende Verwaltung der
Tests nutzt.
• Testablauf: Die interne Beschreibung des technischen Testprozesses. Weiterhin
eine 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.
Adapter Testablauf Extern
nutzt
Tester
nutzt
nutzt
FrameworkAdapter
Neue
Funktionalitäten
Initialisierung Aufräumen
nutzt
nutzt
Abbildung 5.3.: Grobarchitektur
Die Architektur von jedem Teilbereich ist stark durch Entwurfsmuster geprägt und eine
detaillierte Darstellung erfolgt in den nächsten Abschnitten.
5.3.2. Testablauf
Abbildung 5.4 illustriert die Architektur des Teilbereichs Testablauf. Ziel ist es den Testprozess
um Logik vor und nach der Testdurchführung zu erweitern. D.h. die Testdurchführung
selbst übernimmt weiterhin das zu erweiternde Unit Test Framework.
41

5. Werkzeugunterstützung für die Teststrategie
TestProcess
+Initialize()
+CleanUp()
1
1..*
+Node
Knoten für:
Verwaltung
Build
Bereitstellung
Test
TestProcessNode
+Command : ITestCommand
+Preparation : ITestCommand[]
+DoBeforeTest()
+DoAfterTest()
«interface»
ITestCommand
+DoBeforeTest()
+DoAfterTest()
Abbildung 5.4.: Feinarchitektur des Teilbereichs Testablauf
Ein Knoten im Testprozess besteht immer aus einem Command-Objekt zur Durchführung
der eigentlichen Logik und einer Liste von Command-Objekten, die vorher
auszuführen sind (Vorbereitung). Insgesamt entsteht eine Hierarchie, in der die Ausführung
des Testprozesses entsprechend an die Knoten delegiert wird, die wiederum
jedes Command-Objekt entsprechend ausführen. Die Command-Objekte sind dabei
anderorts implementiert und der Teilbereich Testablauf bildet nur einen leeren und
definierten Rahmen.
5.3.3. Adapter zu einem Unit Test Framework
Das Unit Test Framework der Microsoft Visual Studio Team Edition bietet aufgrund
von fehlenden Schnittstellen und der Tatsache, dass der Quellcode nicht frei verfügbar
ist, keine Möglichkeiten zur direkten Erweiterung an. Daher gilt es die vom Unit Test
Framework bereitgestellten Möglichkeiten zur Initialisierung und zum Aufräumen so
erweiterbar zu machen, dass ein Nutzer leicht neue Funktionalitäten einbinden kann.
Die Aktivitäten der Initialisierung und des Aufräumens sind Teile eines jeden Testfalls
und werden durch Methoden repräsentiert. Über beide Aktivitäten hat der Verfasser
des Tests die Kontrolle, so dass er einen Adapter einbinden kann. Der Adapter benötigt
dabei 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 Testlaufs
enthält.
42

5. Werkzeugunterstützung für die Teststrategie
Zum einfachen Einbinden bietet sich eine statische Methode an, die eine Verbindung
zwischen dem Unit Test Framework und den Erweiterungen herstellt. Als Auskommen
dieses Aufrufs wird neue Funktionalität bereitgestellt und ein Objekt des
Proxy so vorbereitet geliefert, dass dieses direkt zum Testen des Webservices genutzt
werden kann. Abbildung 5.5 zeigt die Einbindung des Adapters in einem Test
in C#. Dabei enthält der TestContext alle Steuerungsinformationen des Testlaufs.
InitializeLink führt die Initialisierung des Testprozesses aus und gibt ein Objekt
des Proxy zurück. ReleaseLink führt die Aufräumknoten des Testprozesses aus und
löst dadurch die Verbindung zu den Erweiterungen auf.
1 [ TestClass ]
2 public class Test {
3
4 [ 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 s e r v i c e = Adapter . I n i t i a l i z e L i n k ( TestContext ) ;
7 }
8
9 [ TestCleanup ]
10 public void CleanUp ( ) {
11 Adapter . ReleaseLink ( TestContext ) ;
12 }
13
14 . . .
15
16 }
Abbildung 5.5.: Einbindung des Adapters in einem Test
Der Adapter stellt die äußere Schnittstelle zum Testprozess dar. Neue Funktionalitäten
werden über Annotationen 1 bereitgestellt. Jede Annotation enthält dabei die Logik zur
entsprechenden Manipulation des Testprozesses.
Abbildung 5.6 stellt den gesamten Teilbereich Adapter als Klassendiagramm dar. Annotationen
werden über eine Vererbungshierarchie identifiziert, wodurch eine gezielte
Auswertung möglich wird.
Die Verwaltung von Informationen, die während der Testdurchführung entstehen und
anderorts notwendig sind, werden in einem global erreichbarem Kontext abgelegt.
1 Annotationen sind in Java Metadaten, die direkt am Code angegeben werden. In .NET werden Annotationen
als Attribute bezeichnet.
43

5. Werkzeugunterstützung für die Teststrategie
Wertet Test- und Konfigurationsannotationen aus.
Adapter
+InitializeLink(in testContext) : Proxy
+ReleaseLink(in testContext)
-EvaluateAttributes(in testName : string)
«interface»
ITestProcessRegistration
+RegisterAt(in process)
System.Attribute
TestAttribute
ConfigurationAttribute
+RegisterAt(in process)
ScopeAttribute
Annotationen zur Bereitstellung unterliegen
der Einschränkung, dass nur eine Bereitstellung
je Testfall erfolgt.
Abbildung 5.6.: Feinarchitektur des Teilbereich Adapter
5.3.4. Interaktion mit externen Systemen
Zur Realisierung des Testprozesses ist der Einsatz von Systemen zum Kompilieren
oder 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 Erweiterungen
und externen Systemen. Zusätzlich wird die Testbarkeit erhöht, weil sich Tests durch
den Einsatz von Mocks ohne reale Effekte ausführen lassen.
44

5. Werkzeugunterstützung für die Teststrategie
«interface»
IParser
+Parse(in code : string)
+GetOutput() : string
CSharpParser
+Parse(in code : string)
+GetOutput() : string
«interface»
IAspNetDevelopmentServer
+Start()
+Shutdown()
AspNetDevelopmentServer
+Start()
+Shutdown()
«interface»
IFileSystemFacade
FileSystemFacade
«interface»
IPathLocator
PathLocator
«interface»
ISolutionFacade
+Load(in solutionFile : string)
+Build()
SolutionFacade
+Load(in solutionFile : string)
+Build()
Abbildung 5.7.: Feinarchitektur des Teilbereich Extern
Abbildung 5.7 zeigt die Architektur des Teilbereich Extern in vereinfachter Form. Jede
Fassade ist definiert durch eine Schnittstelle, die für das Umfeld .NET implementiert
ist. Die Funktionen einer jeden Fassade stellen sich wie folgt dar:
• IParser: Stellt Möglichkeiten zur Manipulation von Code zur Verfügung. Die konkrete
Implementierung ist an eine Sprache gebunden, um harte Mocks zu ermöglichen.
Eine detaillierte Beschreibung wird in Abschnitt 5.5 gegeben.
• IAspNetDevelopmentServer: Der ASP.NET Development Server ist ein Web
Container im .NET Umfeld und wird während der Entwicklung zu Testzwecken
eingesetzt.
• 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 Solution.
Diese Fassade erlaubt die Durchführung eines Builds für eine Solution.
45

5.4. Implementierung
5. Werkzeugunterstützung für die Teststrategie
Die Umsetzung von Serviceumgebungen und das Einfügen von Mocks sind neue
Funktionalitäten, die die Erweiterungen einem Tester zur Verfügung stellen. Realisiert
sind sie über Annotationen, die den Testprozess mit Command-Objekten entsprechend
anreichern.
Viele Command-Objekte nehmen Änderungen am Deployment vor, so dass für diesen
Fall ein Klon von der Solution erstellt wird. Dadurch sind alle Änderungen nur temporär
und betreffen den jeweiligen Testlauf. Realisiert wird der Klonvorgang durch wohl
definierte Command-Objekte, die den Verwaltungsknoten des Testprozess erweitern.
Konkret wird ein entsprechender Pfad zum Ablegen des Klon gesucht und eine Kopie
aller Verzeichnisse rekursiv erstellt. Anderen Command-Objekten steht der Klon über
einen Kontext zur Verfügung.
Umgesetzt sind die folgenden Annotationen:
• Die lokal/entfernt Serviceumgebung stützt sich auf einen lokal zur Verfügung
gestellten Web Container. Die Annotation LocalRemote dekoriert den Bereitstellungsknoten
des Testprozess um ein Command-Objekt, das einen ASP.NET
Development Server startet und die Bereitstellung eines Projektes durchführt.
• Eine entfernte Serviceumgebung wird manuell bereitgestellt, so dass nur die
URL des Endpunkts von Interesse ist. Die Annotation Remote muss folglich nur
den 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 Austausch
von Dateien im Deployment oder dem Austauschen von Code umgesetzt werden.
Entsprechende Annotationen erweitern die Vorbereitung des Buildknotens
um Command-Objekte, die eine Datei oder Code austauschen. Die genaue Vorgehensweise
wird in Abschnitt 5.5 vorgestellt.
• Ein weicher Mock zieht nach Abschnitt 3.4.3 die Änderung des Deployments
nach sich. Dazu muss eine Annotation das Deployment so manipulieren, dass
ein weicher Mock während der Testdurchführung nutzbar wird. Abschnitt 5.6 wird
diesen Fall genauer betrachten und unterschiedliche Vorgehensweisen beschreiben.
Während der Implementierung wurden einige Maßnahmen zur Steigerung der Qualität
unternommen. Zunächst wurde ein Wegwerf-Prototyp entwickelt, um Probleme bei der
letztendlichen Implementierung zu vermeiden. Die Erweiterungen selbst sind testgetrieben
[Bec03] implementiert, damit schon während der Entwicklung durch kontinuierliche
Tests die Qualität sichergestellt wird. Zum Abschluss wurden weitere Mängel
durch die statische Codeanalyse von Microsoft Visual Studio identifiziert und behoben.
46

5. Werkzeugunterstützung für die Teststrategie
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 austauschen.
Entwicklungsumgebungen verwalten Quellcode in Projekten. D.h. existiert
bereits ein Klon der Projekte, so ist der Austausch von gesamten Dateien einfach
möglich. Für die gezielte Ersetzung von Teilen im Quellcode präsentiert diese Arbeit
einen neuen Mechanismus.
Vor der Manipulation von Code ist es notwendig den auszutauschenden Teil festzulegen.
Dabei sind einfache Merkmale wie z.B. die Zeilennummern einer Datei ungeeignet,
weil sie gegenüber Änderungen nicht konstant sind. In der objektorientierten
Programmierung dienen Klassen und Methoden zur Strukturierung einer Applikation.
Klassen enthalten dabei Methoden und stellen das äußere Gerüst dar, so dass erst in
Methoden konkrete Logik implementiert wird. Daher seien Methoden als der Teil von
Code ausgewählt, den es zu ersetzen gilt. Die Identifikationsmerkmale einer Methode
sind wie folgt:
• Äußere Klasse
• Methodenname
• Parameter
• Generische Typen
Gilt es eine Methode auszutauschen, so sind alle vier Identifikationsmerkmale, der
neue Rumpf der Methode und die zu manipulierende Datei vom Testverfasser anzugeben.
5.5.2. Verarbeitung und Austauschen von Code
Sind alle notwendigen Informationen zum Austauschen einer Methode bekannt, muss
ein Mechanismus die Änderungen vornehmen. Dabei gilt es zunächst die Methode im
Quellcode zu finden und anschließend den neuen Rumpf zu schreiben. Im Folgenden
wird dazu ein Parser vorgestellt, der Zeichenweise einen Text verarbeitet.
Zur Vereinfachung sei die Annahme getroffen, dass der betrachtete Code wohlgeformt
ist. Diese Annahme kann getroffen werden, weil im Testprozess immer ein Build durchzuführen
ist, wenn sich das Deployment ändert. Dies erlaubt den Parser auf Probleme
aus der Zeichenkettensuche zu reduzieren.
Zur kontextuellen Suche einer Methode und zum Schreiben des Ergebnisses setzt der
Parser das Strategy-Entwurfsmuster [GHJV95] ein. Die Strategien erhalten dabei ein
Zeichen und entscheiden intern über die weitere Verarbeitung:
• Ein Finder ist eine Strategie, deren Implementierung zur Suche von Informationen
genutzt wird. Zusätzlich repräsentiert ein Finder den Zustand des Parsers
47

5. Werkzeugunterstützung für die Teststrategie
nach dem State-Entwurfsmuster [GHJV95]. Ein Finder definiert jeweils für den
Erfolgsfall und den Fehlschlag den nachfolgenden Finder.
• Ein Writer ist eine Strategie zum Schreiben von Zeichen.
Klassenname
suchen
Klassenname
gefunden
Klassenschlüsselwort
gefunden
Klassenschlüsselwort
oder
Methodenname
suchen
Methodenname
gefunden
Generische
Typen suchen
Ende der generischen
Typen erreicht
Parameter
suchen
Ende der Parameterliste
erreicht
Anfang des
Methodenrumpfes
suchen
Abbildung 5.8.: Zustandsübergänge der Finder
Zum Auffinden einer Methode durchläuft der Parser die in Abbildung 5.8 durch Finder
repräsentierten Zustände. Der Misserfolgsfall wird dabei nicht explizit angegeben und
sei für alle Kanten ohne Markierung angenommen. Für jeden Knoten existiert eine
eigene Klasse, die die Schnittstelle der Finder mit entsprechender Logik implementiert.
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 Block 2 von Interesse. Deshalb existiert ein Stack für die gefun-
2 In C# wird ein Block durch geschweifte Klammern eingeleitet und abgeschlossen.
48

5. Werkzeugunterstützung für die Teststrategie
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, wird
der Writer gewechselt. Dieser neue Writer schreibt den neuen Methodenrumpf und es
wird veranlasst alle Zeichen so lange zu überlesen bis das Ende der Methode erreicht
wurde; das Ende der Methode stellt ein Beobachter fest.
Die zentrale Steuerung übernimmt nach dem Mediator-Entwurfsmuster [GHJV95] ein
Manager. Dieser erlaubt jedem Finder und Writer kontextsensitive Informationen zu
nutzen. Abbildung 5.9 zeigt den Parser als Klassendiagramm.
Entsprechende Schnittstellen
seien nicht angegeben.
get- und set-Methoden seien
durch öffentliche Attribute
repräsentiert.
Parser
+Output : string
+Parse(in code : string)
1
1
ParserManager
+ActiveFinder : IFinder
+ActiveWriter : IWriter
+MethodsToMock[] : Method
+Find(in character : char)
+Write(in character : char)
1
1
1
1
«interface»
IFinderFactory
+CreateFinder(in type : int)
«interface»
IFinder
+Find(in character : char)
+DoMatch(in manager : IParserManager)
+DoFail(in manager : IParserManager)
«interface»
IWriter
+Write(in character : char)
ClassStack
BlockCounter
+Push(in classToPush : Class)
+Pop() : Class
+Peek() : Class
+Increment()
+Decrement()
Abbildung 5.9.: Architektur des Parser
5.6. Realisierung von weichen Mocks
Die Einführung von weichen Mock-Objekten setzt einen Mechanismus voraus, der
einen Austausch von Objekten zur Laufzeit durchführt. Die Logik, die diesen Austausch
vornimmt, ist vor der Bereitstellung dem Webservice hinzuzufügen. Nach der Bereitstellung
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ächsten
Seiten vorgestellt werden.
49

5. Werkzeugunterstützung für die Teststrategie
1. Abbildung 5.10 zeigt die Realisierung eines weichen Mocks unter Einsatz einer
Steuereinheit. Die Steuereinheit ist ein Webservice, der zum Deployment des
zu testenden Webservices hinzuzufügen ist. Den Austausch von Komponenten
durch Mocks übernimmt die Steuereinheit. Die eingenommene Sichtweise
der Steuereinheit entspricht der Sichtweise eines Tests in der objektorientierten
Programmierung (siehe Abbildung 3.3 in Abschnitt 3.4.3). Demnach muss die
Steuereinheit Zugriff auf die Instanz eines Webservices haben.
Test Steuereinheit Webservice
Initialisierung()
SetzeKomponente()
Operation()
Ergebnis
Aufräumen()
SetzeKomponente()
SOAP
Abbildung 5.10.: Weicher Mock mit Steuereinheit
Ein Tester muss nur die Logik zum Austauschen einer Komponente angeben. Die
Steuereinheit ist einmalig zu implementieren und die Serviceimplementierung
bleibt unverändert.
Dieser Ansatz ist aufgrund von Konsequenz 2.3 nicht anwendbar, weil im Web
Container kein Zugriff auf die Instanz des Webservices möglich ist. Insbesondere
ist auch nicht bekannt mit welcher Instanz eines Webservices ein Servicekonsument
interagieren wird.
50

5. Werkzeugunterstützung für die Teststrategie
2. In Abbildung 5.11 wird ein Ansatz unter Einführung einer Initialisierungs- und
Aufräumoperation im Webservice illustriert. Dabei führen die neuen Operationen
den Austausch der Komponenten durch.
Test
Webservice
Initialisierung()
Operation()
Ergebnis
Aufräumen()
SOAP
Abbildung 5.11.: Weicher Mock mit neuen Operationen
Ein Tester gibt die Logik der Initialisierungs- und Aufräumoperation an. Die Serviceimplementierung
bleibt insofern unverändert, als dass sich keine Operationen
im Webservice ändern.
Zwischen dem Aufruf von Operationen eines Webservices kann nicht garantiert
werden, dass die Instanz des Webservices identisch bleibt [Sta06a] (siehe auch
Konsequenz 2.5). Folglich ist auch dieser Ansatz nicht anwendbar.
51

5. Werkzeugunterstützung für die Teststrategie
3. Abbildung 5.12 zeigt einen Ansatz, der die zu testende Operation im Webservice
um Logik zur Durchführung der Initialisierung und dem Aufräumen erweitert. Dabei
wird eine Operation so verändert, dass sich ihr eigentliches Verhalten nicht
ändert.
Test
Webservice
Operation()
Ergebnis
SOAP
Initialisierung()
Aufräumen()
1 public void Operation ( ) {
2 I n i t i a l i z e ( ) ;
3 t r y {
4 / / vorhandener Code
5 } catch ( Exception ) {
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 erweitert:
• Der Writer, der einen Mock schreibt, ist so anzupassen, dass bisheriger Code
erhalten bleibt. D.h. eine Methode wird nur mit neuen Codefragmenten
dekoriert.
• Einfügen eines Beobachters, der die Klasse des Webservices um eine Initialisierungs-
und Aufräummethode erweitert.
5.7. Zusammenfassung
Ein Werkzeug zur Unterstützung einer Teststrategie betrifft Ausprägungen in allen drei
Ebenen einer SOA. Insbesondere wird man abhängig von der Plattform, ermöglicht
aber Komponententests nach Abschnitt 3.4.
Durch den Einsatz von Entwurfsmustern und klarer Trennung der Zuständigkeiten erhält
man eine sehr einfache Architektur, die sich aus einem Adapter, einem Testablauf
und externen Systemen zusammensetzt.
52

6. Fallstudie
Kapitel 3 hat gezeigt, wie eine Teststrategie für eine SOA zu finden ist. Dabei hat im
Anschluss Kapitel 4 die ersten zwei Schritte dieser Vorgehensweise durchgeführt. In
diesem Kapitel gilt es eine konkrete Teststrategie unter Einbezug der bisherigen Ergebnisse
zu finden. Dazu werden die Webservices eines Unternehmens als Testobjekte
dienen. Die Teststrategie selbst ist angepasst an das vorherrschende Projektumfeld
im Unternehmen.
Nach erfolgreicher Festlegung einer Teststrategie, beschrieben durch eine Testmatrix
und Testszenarien, ist diese Teststrategie für die bereits erwähnten Webservices umzusetzen.
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-Business
Umfeld tätig. Angebotene Dienste werden über ein eigenes entwickeltes und
verwaltetes Portal zur Verfügung gestellt. Die Entwicklung betrifft im Allgemeinen die
Erweiterung und Wartung dieses Portals.
Abbildung 6.1(a) zeigt eine Übersicht über das hauseigene Portal. Informationen über
die Interaktion mit Objekten werden aktiv verfolgt und gesammelt. Kunden interagieren
mit dem Geschäftsbereich über eine Website. Webservices sind ein noch wenig
genutztes Produkt und bieten bereits vorhandene Funktionalitäten der Website an.
In einer SOA übernimmt das Unternehmen die Rollen des Serviceanbieters und des
Serviceentwicklers. Das Portal selbst ist nicht serviceorientiert strukturiert, sondern
mit 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 fehlen
bisher. Von den Entwicklern werden Komponententests mit einem Unit Test Framework
gelegentlich umgesetzt und während der Entwicklung der Webservices wurde
nicht auf Testbarkeit geachtet.
Zusätzlich sind die folgenden Vorgehensweisen und Randbedingungen für diese Arbeit
von 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 Abbild
der Datenbank zu einem gegebenen Stand vorweist.
• Tester sind nicht technisch-orientiert, d.h. sie verfassen keine automatisierten
Komponententests.
6.1.1. Betrachtete Webservices
Im Verlauf dieser Arbeit wurde von den Entwicklern ein Teil des Portals überarbeitet
und erweitert. Als Konsequenz waren auch einige Webservices anzupassen, so dass
diese für Tests ausgewählt wurden.
Die betrachteten Webservices sind passiv und rufen nur Daten aus der Geschäftslogik
ab. Abbildung 6.2 zeigt die Entwicklung der Webservices 1 , wobei für diese Webservices
keine Spezifikationen vorliegen. Speziell die Auswahl der Operationen und Parameter
wurde nicht geplant, sondern von den Entwicklern selbst während der Entwicklung
festgelegt.
Als Dokumente zum Ableiten von Testfällen stehen die Servicedokumentation und die
Serviceimplementierung als Quellcode zur Verfügung. Weitere Informationen liegen
nur in „flüssiger“ Form vor und sind gezielt von Mitarbeitern zu erfragen. Im gesamten
Verlauf dieser Arbeit erwies sich die Identifikation von Informationsträgern als schwierig,
weil oftmals schon die Zuständigkeiten nicht eindeutig geklärt waren. Als Orakel
1 Für eine Erklärung der Notation sei auf Kapitel 5 in [Sta06b] verwiesen.
54

6. Fallstudie
Entwickler
Entwickler
Entwickler
Implementierung
erstellen
Dokumentation
erstellen
Visual Studio
Quellcode
Webservice
Word
Servicedokumentation
Quellcode
Website
Web Container
Schnittstelle
erstellen
Serviceschnittstelle
Web Container
Abbildung 6.2.: Entwicklung der eingesetzten Webservices
bei der Überprüfung der Korrektheit von Daten ist die vorhandene Website geeignet 2 ,
weil die betrachteten Webservices nur bestehende Funktionalitäten über eine Maschine
zu Maschine Schnittstelle anbieten.
Ursprünglich war geplant Teile des Portals serviceorientiert umzusetzen. Aber die Implementierung
erwies sich als kein Service, weil sie nicht Definition 2.5 entspricht. Eine
Serviceschicht ist mit der Windows Communication Foundation (WCF) [Micb] umgesetzt,
jedoch wird nie mit einem Service interagiert. Nach Konsequenz 2.3 wird in einer
SOA mit einer bestehenden Instanz interagiert, die Interaktion im vorliegenden Fall
geschah jedoch über ein neu erzeugtes Objekt. Gespräche haben ergeben, dass an
dieser Stelle eine SOA zum jetzigen Zeitpunkt nicht zweckmäßig ist und daher auch
kein Service eingesetzt wird. Stattdessen wird mit herkömmlichen objektorientierten
Mitteln 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 wird
mit einem manuell bereitgestellten Webservice interagiert. Zur Validierung der Daten
diente eine entsprechende Version der Website, die dieselbe Datenbank nutzt.
Wie bereits in Abschnitt 5.2 beschrieben stellt ein in .NET umgesetzter Webservice
eine grafische Benutzerschnittstelle zur Verfügung, so dass ein Tester mit einem Browser
jede Operation des Webservices durch Eingabe der Parameter in Textfeldern auf-
2 Die Korrektheit der Website kann allerdings nicht angenommen werden, so dass bei Abweichungen
sowohl 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ückgabewert
der Operation darstellt.
Folglich erlaubt .NET das Testen eines Webservices auch ohne Einsatz von zusätzlichen
Werkzeugen. Dieses Vorgehen sei im Folgenden als manuell bezeichnet, weil
die Eingabedaten von einem Tester manuell eingegeben werden und auch die Auswertung
der Ergebnisse manuell geschieht. Wird ein Werkzeug für die Interaktion mit dem
Webservice und die Auswertung der Ergebnisse eingesetzt, z.B. ein Unit Test Framework
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 vereinfachen
und unabhängiger zu machen. Ist ein komplexes System involviert, z.B. eine
Datenbank, das Dateisystem oder andere Services, so sind immer Kopplungen vorhanden,
die das Testen erschweren [TH02]. Es ist oftmals aufwändiger eine Datenbank
durch eine „virtuelle“ neue Datenbank zu ersetzen, als die entsprechende Komponente
auszutauschen, die die Datenbank nutzt.
Um praktikabel zu sein, wird angenommen, dass Tests mit einen Unit Test Framework
geschrieben oder manuell durchgeführt werden. Die vorgestellte Teststrategie
wird Abhängigkeiten zur Idee, Technologie und Plattform von SOA haben, sowie zum
Projektumfeld. 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 objektorientierten
Sprache umgesetzt. Demnach sind auch aus der testgetriebenen Entwicklung [Bec03]
bekannte Komponententests einsetzbar. Zur Interaktion mit einem Webservice kommt
vorrangig ein Proxy zum Einsatz, aber auch andere Formen der Interaktion sind möglich
[McC06]. Alle Sichtweisen haben gemeinsam, dass die Rolle eines Servicekonsumenten
eingenommen wird.
6.2.2. Testmatrix und Testszenarien
Kapitel 4 hat bereits Testaspekte für die betrachtete Ausprägung beschrieben. Tabelle
6.1 zeigt die für das Unternehmen ausgewählte Zuordnung von Testaspekten zur
Serviceumgebung. Lokale und lokal/entfernte Serviceumgebungen sehen nur Komponententests
und Integrationstests vor. Systemtests werden erst in einer entfernt/test
Serviceumgebung 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 getrennt.
Jeder Bereich bildet dabei eine Gruppe von zum Teil verwandten Tests:
• Nr. 1: Als Geschäftsentscheidung gilt für Projekte, dass Entwickler ihren Code
mit Komponententests zu überprüfen haben. Entsprechend beginnt diese Teststrategie
mit solchen Tests in einer lokalen Serviceumgebung unter dem Testaspekt
Funktionalität. Dabei handelt es sich um Komponententests, die aus der
objektorientierten 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 Verifikationstests
für die Datentransferobjekte, das Deployment und alle Konfigurationen
durchzuführen. Dies verhindert, dass spätere Tests aufgrund von Fehlern,
die ein vorheriger Testaspekt findet, fehlschlagen. Die Automation dieser Tests
erlaubt 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 Unternehmen
und Projekt begrenzt sind. Jeder Nutzer mit einem Account ist explizit für einen
Webservice freizuschalten und erhält ein eigenes Passwort. Die dadurch realisierte
Absicherung ist automatisiert zu prüfen.
• Nr. 6-8: In der Mitte folgen Negativtests durch das Verhalten bei fehlenden Subsystemen
und die Überprüfung von Eingabedaten. Versteckte Grenzen stellen
einen vereinfachten Integrationstest dar.
57

6. Fallstudie
• Nr. 9-10: Rückwärtskompatibilität und Interoperabilität sind spezielle Eigenschaften
in einer SOA.
• Nr. 11: Jeder Webservice bietet Dienste an, die die Servicedokumentation beschreibt
oder eine Spezifikation fordert. Eine Überprüfung gegen diese Dokumente
folgt durch Test der Funktionalität mit Systemsicht.
Einige der in Kapitel 4 vorgestellten Testaspekte sind in der vorgestellten Teststrategie
bewusst nicht aufgeführt:
• Webservice Standards werden nicht eingesetzt und sind daher nicht zu testen.
• Last- und Performancetests sind im Rahmen dieser Arbeit nicht betrachtet, weil
sie auf bekannten Methoden basieren und keinen Beitrag zu dieser Arbeit leisten.
Ziel bei allen Testaspekten ist mit Komponententests zu arbeiten, um die Tests unabhängiger
zu halten. Tests in der entfernt/test Serviceumgebung sind nicht zwingend zu
automatisieren und können manuell erfolgen. Allgemein sei angemerkt, dass die vorgestellte
Testmatrix nur ein Vorschlag ist, aber ein wichtiges Produkt der Teststrategie
darstellt. Die Testmatrix lässt sich beliebig anpassen, um die Teststrategie in verschiedenen
Projekten und Unternehmen zu steuern. Allerdings können alle Artefakte der
Teststrategie 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 angegeben
von oben nach unten. Die Übergänge sind dabei nicht starr, sondern können
flexibel bei der Testdurchführung gewählt werden. Die Vorbedingungen der Testszenarien
legen fest, wann ein Testaspekt getestet werden kann. Die Reihenfolge der
Testaspekte in der Testmatrix ist nach den folgenden Kriterien bestimmt:
• Während des Projektverlaufs nimmt die Aggressivität beim Testen stetig zu. Die
Anordnung der Testaspekte entspricht einem Vorgehen, indem mit bekannten
Komponententests begonnen wird, bevor der Sprung zu einem Service vollzogen
wird. Das Testen eines Services beginnt mit Verifikationstests, bevor in der Mitte
der Testmatrix Negativtests folgen. Insbesondere ist es nicht sinnvoll mit umfangreichen
Tests zu beginnen, bevor grundlegende Funktionsfähigkeit sichergestellt
ist.
• Die Zuordnung zur Serviceumgebung beginnt bei einer lokalen Serviceumgebung
und sieht erst später höhere Serviceumgebungen vor, weil dies einer Zuordnung
zur Teststufe entspricht (niedrige Teststufen sind vor höheren Teststufen
einzusetzen). Die lokale und lokal/entfernte Umgebung eignet sich für Komponententests
oder Integrationstests, die entfernt/test Umgebung eignet sich für
Systemtests.
Anhang A ist die Sammlung aller Testszenarien für die entwickelte Teststrategie. Die
Testszenarien beziehen sich auf die Testmatrix aus Tabelle 6.1 und basieren auf der
Vorlage 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 aufgezeigt.
Als Grundlage für die Ableitung von Testfällen dienen die in Anhang A gegebenen
Testszenarien. Erzeugt wurden die Testfälle für den in Abschnitt 6.1.1 beschriebenen
Webservice. Die Testautomation und alle Komponententests wurden mit dem
in Kapitel 5 vorgestellten Werkzeug umgesetzt.
Komponententests haben die Eigenschaft oftmals White-Box Analysen zur Erzeugung
von Testfällen einzusetzen. Zusätzlich werden die Tests abgekoppelt von anderen Systemen
durch den Einsatz von Mocks. Die Trennung von der Datenbank erlaubt nur den
Service an sich zu testen, unabhängig von bestimmten Daten, d.h. die Erzeugung von
Testfä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 Verfassung
von herkömmlichen Komponententests. Speziell die Webservice Fassade
und die Datenbankanbindung sind nicht direkt testbar aufgrund von anonymer
Erzeugung von Objekten und anschließender Benutzung. Auch die Grenzen zwischen
den einzelnen Schichten sind fließend umgesetzt und die Einführung von
Mocks 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 zur
Verfügung und ist somit explizit nutzbar. Erzeugt man vollständig aufgelöste Objekte
für die Eingabe und Ausgabe, ist durch entsprechende Übergabe der Objekte
an den XML-Serialisierer prüfbar, ob eine Serialisierung bidirektional möglich
ist. Der Test führt diese Übersetzung durch und vergleicht das ursprüngliche
mit dem serialisierten Objekt. Die Überprüfung der Datentransferobjekte erfolgt
insgesamt automatisiert.
• Verifizierung des Deployment (Nr. 3): Die betrachteten Webservices sind nur
passiv, indem sie Daten beziehen. In der lokal/entfernt Serviceumgebung wurde
die Datenbank durch einen Mock ersetzt. Verifikationstests in der entfernt/test
und entfernt/live Serviceumgebung sind identisch und in beiden Serviceumgebungen
einsetzbar, wobei ein Systemtest durchgeführt wird. Testfälle leiten sich
ab über eine Pfadanalyse im Quellcode. Es gilt möglichst viele Pfade durch den
Webservice 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 Mocks
und Testdaten wurden Pfade so durch den Webservice gelegt, dass das Logging
angesprochen und die Konfiguration vollständig genutzt wird. In der lokal/entfernt
Serviceumgebung hat der Tester vollständige Kontrolle über die Konfiguration
und wird diese so anpassen, dass ein automatisierter Test möglich wird.
Grundsätzlich wurde in der lokal/entfernt Serviceumgebung ausschließlich die
Korrektheit der Funktionalität geprüft. In der entfernt/test Serviceumgebung ändert
sich nur das Ausgabeziel des Logging und es ist prüfen, ob der Effekt überhaupt
eintritt. In der entfernt/test Serviceumgebung ist dieser Test nur bedingt
automatisierbar, weil kein äußerer Zugriff auf das System möglich ist.
Bei der Überprüfung der Datenbankkonfiguration gilt es in der entfernt/test Serviceumgebung
Pfade durch den Service zu finden, so dass mit den verschiedenen
Datenbanken interagiert wird.
• Autorisierung und Authentifizierung (Nr. 5): Mittels automatisierten Tests ist zu
prüfen, ob ein gültiger Benutzer den Webservice nutzen kann und auch nur für
ihn ersichtliche Daten erhält. Im Anschluss wurden Negativtests durchgeführt,
um den Webservice anzugreifen.
• Fehlendes Subsystem (Nr. 6): Als einzige Subsysteme wurden Datenbanken eingesetzt.
Ein entsprechender Test verhindert den Zugriff des Webservices auf
die Datenbank und ist manuell durchzuführen. Durchgeführt wurde er in einer
lokal/entfernt Serviceumgebung und blockieren entsprechenden Netzwerkverkehrs.
• Annahmen an Eingabedaten (Nr. 7): Die Ableitung von Testfällen erfordert die
Parameter jeder Operation zu analysieren. Tabelle 6.2 stellt einen Ausschnitt der
durchgeführten Analyse dar.
Webservice Operation Parameter Typ
Annahmen an Eingaben
Explizit
Implizit
Statistik
GibTäglicheDaten
GibNeueDaten
ID Integer > 0
Datum String Konvertierbar zu
Datum,

6. Fallstudie
teilt. Explizite Annahmen sind in Dokumenten festgehalten, implizite Annahmen
ergeben sich aus dem Projektumfeld bzw. dem Parameter heraus und wurden
bei der Implementierung von den Entwicklern angenommen. Implizite Annahmen
erhält man nur durch White-Box Analysen oder durch Gespräche mit den
Entwicklern.
Die durchgeführte Analyse erlaubt für jeden Parameter, selbst bei komplexen
Objekten, Äquivalenzklassen für ungültige und gültige Werte aufzustellen. Anschließend
sind aus den Klassen Repräsentanten auszuwählen, so dass eine
Matrix entsteht, die in einem automatisierten Test eingesetzt wird. Das Unit Test
Framework der Visual Studio Team Edition erlaubt die Realisierung von datengetriebenen
Tests [Mica], die direkt erstellte Matrizen nutzen. Es ist nur ein Operationsaufruf
im Test und ein Adapter zwischen diesem Aufruf und der Matrix zu
schreiben. Neben einer Durchführung dieses Tests für die ungültigen Daten, sind
als 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 erlaubt
nicht nur festzustellen welche Eingabedaten ungeprüft verarbeitet werden, sondern
auch welche Konsequenzen entstehen können.
• Versteckte Grenzen (Nr. 8): Zur Ableitung von Testfällen ist zunächst eine Analyse
durchzuführen, die Grenzen und potentielle Problemfälle identifiziert. Tabelle
6.3 zeigt diese Analyse, wobei Grenzen schon zwischen Schichten angenommen
seien 3 .
Zwischen den einzelnen Grenzen wird über eine ’’-Relation angegeben,
ob sich der Datenraum vergrößert, gleich bleibt oder verkleinert. Jede
Reduktion, repräsentiert durch ’>’, kann zu Problemen bei der Verarbeitung von
Daten führen. Denn bei einer Zeichenkette werden z.B. nur die ersten x Zeichen
betrachtet, wobei x die durch den Typ festgelegte Länge ist.
Operation
GibAusgaben
Service/DTO Parameter/BO Datenbank/DAO Datenbank/Real
Name Typ Typ Typ Typ
ID 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 arbeiten,
die länger als 80 Zeichen sind. Im Besonderen ist bei den getesteten
Webservices 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
3 Zwischen zwei Grenzen kommt es zu Übergängen zwischen verschiedenen Objekten, mit denen in
einer 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 Proxy
arbeiten, werden bei diesem Testaspekt erneut eingesetzt. Es gilt einen Proxy
für den aktuellen Service, der im produktiven Einsatz ist, zu erstellen. Dabei ist
der Endpunkt des Proxys so zu ändern, dass er auf den sich in der Entwicklung
befindlichen Webservice zeigt. Wird jeder Test mit diesem Proxy ausgeführt, darf
sich das Verhalten der Tests nicht ändern.
• Interoperabilität (Nr. 10): WS-I Konformität ist mit Werkzeugen von [Theb] prüfbar.
Beim Test wurde Java als potentielle Plattform eingesetzt. Im Allgemeinen
sind die vorhandenen Webservices sehr einfach gehalten, so dass umfangreiche
Tests für diesen Testaspekt nicht möglich waren.
• Funktionalität (Nr. 11): Durchführung von Tests gegen eine Servicedokumentation,
die für jede Operation die Parameter und den Effekt beschreibt. Fehler
betreffen daher entweder die Implementierung oder die Dokumentation.
Geprüft wird z.B. ob die Daten richtige Zeiträume umfassen, vom Service durchgeführte
Berechnungen korrekt sind oder die Effekte durch die Parameter eintreten.
Zur Überprüfung der Korrektheit der Daten kann die bestehende Website
genutzt 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 sichtbar
geworden, von denen eine Auswahl vorgestellt wird. Dabei beschränkt sich die Auswahl
auf Fehler, die einen Beitrag zu dieser Arbeit leisten. Einige Fehler wurden noch
im Rahmen dieser Arbeit von den Entwicklern behoben.
Verifikationstests für ein Deployment erlaubten nach jeder Änderung direkt das Deployment
selbst und manuelle Bereitstellungen zu verifizieren. Tabelle 6.4 zeigt eine
Auswahl von Fehlern, die schon durch diese sehr einfachen Tests gefunden wurden.
62

6. Fallstudie
Verifizierung des Deployment
Ein Datentransferobjekt wurde mittels Vererbung erweitert. Die Sichtbarkeit
der neuen Klasse wurde beschränkt, so dass der XML-Serialisierer nicht auf
diese neue Klasse zugreifen konnte. Der Aufruf der zugehörigen Operation
lieferte somit einen Fehler.
Ein durch Vererbung von einem Datentransferobjekt eingefügter Adapter
konnte nicht serialisiert werden. Abbildung 6.3 zeigt die entstandene Vererbungshierarchie.
Dem XML-Serialisierer standen nicht alle benötigten Informationen
zur Serialisierung des RecordAdapter zur Verfügung. Zur Lösung
dieses Problems wurde die Struktur geändert.
Zwei Operationen haben nie Werte oder Fehlermeldungen geliefert. Vermutliche
Ursache waren fehlende Zugriffsrechte auf benutzte Datenbanken, weil
dieselben Tests unter Einsatz von Mocks für die Datenzugriffsschicht nicht
fehlschlugen.
Tabelle 6.4.: Fehler bei der Verifizierung des Deployment
public Record Load() {
RecordAdapter adapter = new RecordAdapter();
adapter.LoadRecord();
return (Record) adapter;
}
Record
Webservice
RecordAdapter
+Load() : Record
+LoadRecord()
Abbildung 6.3.: Fehler aufgrund eines Adapters
Tabelle 6.5 zeigt exemplarisch Fehler, die beim Testen der Konfigurationen gefunden
wurden. Konfigurations- und Verifikationstests haben gezeigt, dass sie sehr grundlegende
Eigenschaften in einem Service testen. Schlägt ein Testfall fehl, so ist oftmals
als 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, detaillierten
und sehr technischen Fehlermeldung. Letztendlich wird direkt die vom System
generierte Ausnahme als Fehlermeldung verschickt. Bei der Analyse von versteckten
Grenzen führte der Datenverlust bei zwei Parametern zu fehlerhaftem Verhalten bei
der Selektion von Daten. Speziell wurden Zeichenketten abgeschnitten und dadurch
falsche Werte ausgewählt.
Durch die Kenntnis von Äquivalenzklassen für gültige und ungültige Eingaben, ließen
sich 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 wohlgeformt,
indem einige Elemente mehrfach als Kind definiert waren.
Es fehlte eine Bibliothek beim Ansprechen des eben erwähnten Loggings in
der entfernt/test Serviceumgebung. Derselbe Test lief in der lokal/entfernt Serviceumgebung
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 Gegenprobe
bei der Überprüfung von Eingabedaten, zeigte Inkonsistenzen gegenüber
der Servicedokumentation auf.
Aus der Servicedokumentation abgeleitete Testfälle zur Überprüfung der Funktionalität
offenbarten fehlerhaftes Verhalten des Services. Auch bei diesen Tests wurden
Inkonsistenzen zwischen Service und Servicedokumentation festgestellt.
Bei den Testaspekten Datentransferobjekte, Autorisierung und Authentifizierung, Rückwä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 in
unternehmensspezifischen 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 Geschäftslogik,
weil Testdaten geschickt auszuwählen sind. D.h. die Testdaten müssen
die Geschäftslogik wie gewünscht nutzen und zur Testautomation über der
Zeit konstant sein.
• Das Verfassen von Komponententests muss erlernt werden. Nicht jeder Entwickler
ist sofort in der Lage gute Tests für seinen Code zu schreiben. Insbesondere
das testbare Programmieren erfordert einen anderen Programmierstil, den sich
jeder Entwickler zunächst aneignen muss.
• Den Webservices wird noch nicht soviel Aufmerksamkeit gewidmet wie der Website.
Dennoch setzen Kunden die Webservices ein und müssen sich auf deren
Korrektheit 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 ohne
Trennung und Zugriff auf andere Komponenten realisiert, so wird der Austausch
von Methoden erschwert.
• Fehler, die durch Abarbeitung der Matrix früh gefunden werden, zeigen nicht testwürdige
oder testbare Operationen. Insbesondere die Verifizierung des Deployment
stellt dies schnell durch ihren einfachen Charakter fest. Gefundene Fehler
müssen erst behoben werden, bevor weitere Tests möglich sind.
• Die Automatisierung von Tests wird schwerer, wenn bestimmte Effekte nur anhand
von externen Systemen sichtbar werden. So erzeugt das Logging beispielsweise
direkt Dateien oder E-Mails, so dass anhand derer zu überprüfen ist, ob
eine Information festgehalten wurde.
• Unter Einsatz des Werkzeugs aus Kapitel 5 ist es möglich mit Servicesicht zu
testen, ohne das ein bereitgestellter Service notwendig ist. Im Test ist nur die
Serviceimplementierung notwendig.
• Nicht jeder Tester und Entwickler ist mit den Fallstricken einer SOA vertraut.
Durch Testaspekte werden potentielle Probleme offen gelegt, die unter Anwendung
von Testmethoden und Testszenarien gezielt gesucht werden. Eine Teststrategie
als definierender Rahmen hilft die Qualität von Services allgemein zu
messen.
Die in Abschnitt 6.3.2 beschriebenen Fehler haben die Qualität der Webservices ermittelt.
Diese Informationen können dem Unternehmen helfen die Qualität ihrer Webservices
gezielt zu verbessern. Für zukünftige Projekte steht bereits eine praktikable Teststrategie
zur Verfügung.
6.5. Zusammenfassung
In diesem Kapitel wurde für die Webservices eines Unternehmens eine Teststrategie
nach Kapitel 3 unter Bezug auf die Testaspekte aus Kapitel 4 entwickelt.
Die Umsetzung der Teststrategie erfolgte unter Einsatz von Testszenarien, die im Anhang
A zu finden sind. Für jeden Testaspekt ist die Vorgehensweise beschrieben und
die Durchführung lehnt sich an das zugehörige Testszenario an. Die Realisierung der
Tests erfolgte größtenteils mit dem in Kapitel 5 vorgestellten Werkzeug.
Im nächsten Kapitel wird kritisch auf diese Arbeit zurückgeblickt. Speziell die Erfahrungen
aus der Fallstudie sind wertvoll, weil alle in dieser Arbeit vorgestellten Verfahren
und Konzepte zum Einsatz kamen.
65

7. Kritische Würdigung
In der Fallstudie in Kapitel 6 wurden alle in dieser Arbeit vorgestellten Konzepte und
Werkzeuge 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 Unternehmen
eine Teststrategie und eine mögliche Umsetzung für SOA zu liefern. Die vorgestellten
Ergebnisse sind dennoch allgemein nutzbar und insbesondere unter Kenntnis
der Vorgehensweise aus Kapitel 3 an individuelle Gegebenheiten anpassbar.
Die Erarbeitung dieser Arbeit begann durch eine gezielte Analyse des Unternehmens
und der zur Verfügung gestellten Services. Dabei haben sich die folgenden Probleme
ergeben:
• Das ursprüngliche für Tests ausgewählte Projekt war nicht serviceorientiert umgesetzt.
Auch wenn alle Klassen notwendige Metainformationen enthielten, fehlte
eine nach Konsequenz 2.4 notwendige Bereitstellung. D.h. die Klassen haben
nie den Übergang zu einem Service vollzogen und das Projekt war für diese
Arbeit ungeeignet.
• Die Unterschiede zwischen einem Webservice und einer SOA sind nicht jedem
gleichermaßen bekannt. Eine SOA dient zur Strukturierung von Lösungen, wobei
ein Webservice eine bestimmte Technologie ist, mit der sich diese Strukturierung
umsetzen lässt.
Services bilden als aktive Einheiten die Wurzel einer SOA und sind bei Tests besonders
von Interesse.
7.2. Stärken und Schwächen einer Teststrategie
Aus der Trennung zwischen Service und Serviceimplementierung folgt, dass ein Service
nur einen definierten Rahmen für umgesetzte Logik zur Verfügung stellt. Es erweist
sich als schwierig festzulegen wo Funktionalität zu testen ist. Betrachtet man nur
die Serviceimplementierung, sind alle für die eingesetzte Plattform bekannten Methoden
und Verfahren einsetzbar. Testet man einen Service, so nimmt man die Sichtweise
66

7. Kritische Würdigung
eines Servicekonsumenten ein und muss gegen etwas testen, das auch der Servicekonsument
kennt bzw. ihm zur Verfügung steht: die Servicedokumentation.
Die in Kapitel 4 vorgestellten Testaspekte sind nur als Auswahl anzusehen. Besonders
die Ableitung von Testaspekten für eine bestimmte Ebene erweist sich als schwierig,
weil oftmals die Ebenen untereinander verwoben sind. Z.B. wird die Trennung zwischen
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äche
auf:
• Die Realisierung von Serviceumgebungen und weichen bzw. harten Mocks setzt
Werkzeuge voraus, die nicht immer existieren.
Die Stärken einer Teststrategie nach Kapitel 3 sind:
• Im herkömmlichen Sinne testet man mit einem Komponententest eine Komponente
in Isolation. Services bieten Servicekonsumenten die Logik der Serviceimplementierung
an. Durch die verschiedenen Ebenen einer SOA entstehen jedoch
potentielle Probleme, die erst bei Interaktion mit einem Service getestet werden
können.
Mocks in einem Service einzusetzen, erlaubt Tests zu vereinfachen und unabhängig
gegenüber Daten zu machen. Automatisierte Tests sind nicht mehr abhängig
von der Datenbank und es ist nicht mehr nötig nach bzw. vor jedem Testlauf
einen definierten Zustand herzustellen. Als Tester gelingt es mehr Kontrolle
zu 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 Zuordnung
der Serviceumgebung trifft gezielt eine Auswahl und wird zu einem übersichtlichen
und wichtigen Produkt.
• Gefundene Testaspekte, die Testmatrix und Testszenarien lassen sich in Projekten
mit gleicher Ausprägung wieder verwenden.
7.3. Stärken und Schwächen der entwickelten
Erweiterungen
Der Einsatz der entwickelten Erweiterungen zeigte in der Fallstudie die folgenden
Schwächen auf:
• Das Werkzeug ist nicht nur an eine Technologie gebunden, sondern auch an
eine Plattform und Sprache. Es ist dadurch in allen drei Ebenen abhängig und
kann nur in diesem beschränkten Rahmen eingesetzt werden.
• Im Werkzeug wird der Build schnell zum Flaschenhals, weil oftmals die Projekte
nicht mehr klein sind und die Erzeugung des Deployment lange dauert. Dadurch
wird oftmals eine performante und schnelle Ausführung verhindert.
67

7. Kritische Würdigung
• 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 Serviceimplementierung
zur Laufzeit modifiziert wird. In den vorgestellten Erweiterungen wird
man 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 verwendbar
sind, wenn sich die Serviceimplementierung ändert, aber die Serviceschnittstelle
gleich bleibt. Setzt man auf Werkzeuge, die Services immer als abgeschlossene
Einheit betrachten und nur mit Serviceschnittstellen arbeiten, so lassen sich unterschiedliche
Implementierungen mit denselben Tests testen. Testfälle, die unter
Einsatz der Erweiterungen erstellt werden, sind abhängig von der Serviceimplementierung.
• Bei der Realisierung von Komponententests sind die Tests und die Applikation
oftmals getrennt. Jede Änderung, die ein Test innerhalb der Applikation vornimmt,
wird von außen vollzogen. Der Einsatz der Erweiterungen hingegen ändert
die Applikation, genauer die Serviceimplementierung. Werkzeuge, die bei
der Erstellung von Mocks unterstützen, müssen Teil des Services sein und sind
daher nicht direkt anwendbar. Im Allgemeinen müssen sehr viele Variablen in einem
Projekt änderbar sein, um z.B. dieselbe Mächtigkeit bei der Erstellung von
Mocks zu ermöglichen.
• Tests unter Einsatz eines Proxy erlauben nicht mit einer allgemeingültigen Sicht
zu testen. Man verlässt nicht die ursprüngliche Plattform, so dass durch den
Testaspekt Interoperabilität Fehler gesondert zu identifizieren sind.
• Die Messung von Testabdeckungen ist nicht möglich, weil das zu verfolgende
Objekt entfernt liegt. Der Test agiert wie ein Servicekonsument und hat mitunter
keinen 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 ersichtlich,
was genau getestet wird. Die Annotationen weisen jede Methode, die einen
Testfall beschreibt, eindeutig aus.
• Das Werkzeug verringert die Anforderungen an Testbarkeit, indem es durch harte
Mocks das direkte Austauschen von Code ermöglicht. Allerdings ist der Einsatz
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

7. Kritische Würdigung
dig aufzulösen sind. Hier sind nach Möglichkeit Werkzeuge einzusetzen, die automatisiert
eine Überprüfung vornehmen. Letztendlich sind erstellte Tests immer
anzupassen, wenn sich die Parameter einer Operation ändern, so dass Tests für
Datentransferobjekte wenig lohnenswert sind. Nur wenn Änderungen auftreten,
können sie später Fehler finden und erfordern Änderungen an den Tests. Der
Einsatz von Reflektionen wäre ebenfalls sinnvoll, um die Erzeugung der Objekte
zu automatisieren.
• Auch wenn die Tests für Rückwärtskompatibilität und Interoperabilität keine Fehler
gefunden haben, wäre es ein Trugschluss diese Testaspekte bei zukünftigen
Tests zu ignorieren. Setzt man z.B. Erweiterungen ein, die zusätzliche Informationen
im SOAP-Header erfordern, kann sich das Verhalten bezüglich der zwei
Testaspekte verändern.
• Das Testen von Funktionalitäten in einer entfernt/test Umgebung erschwert die
Testautomation. Jeder Test ist abhängig von allen Subsystemen, so dass sich
die Ableitung von Testdaten als schwierig erweist.
Liegen für ein Testobjekt keine oder nur wenig Artefakte vor, so lässt sich oftmals bei
den 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 ein
Verwaltungswerkzeug für Quellcode und einen täglichen Build-Prozess voraussetzt.
Während des täglichen Build-Prozess ist ein Webservice automatisch in einer wohl
definierten entfernt/test Umgebung bereitzustellen und alle Daten in einen definierten
Zustand zu überführen.
Die Reihenfolge bei der Erstellung von Testfällen sieht zunächst Komponententests
mit JUnit vor, bevor der Webservice zu testen ist. Dabei ist funktional jede Operation
zu testen. Im Unterschied zum Verständnis von Komponententests in dieser Arbeit,
wird in [Par06] ein Test, der nur eine Operation betrifft als Komponententest bezeichnet.
Werden mehrere Operationen in einem Test genutzt, so wird dies als Szenariotest
bezeichnet. Diese Arbeit betrachtet bei Komponententests einen individuellen Service,
der nur während eines bestimmten Testlaufs mit einer angepassten Serviceimplementierung
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. Dabei
wird eine Enterprise Komponente zusammen mit einem Test in einem Container
bereitgestellt und dieser Test wird entfernt über einen Proxy aufgerufen. Ziel ist es
Software so zu testen, dass man erweiterte Funktionalitäten und Eigenschaften des
Containers nutzen kann. Abbildung 8.1 stellt die Arbeitweise von Cactus dar. Die Num-
70

8. Verwandte Arbeiten
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 zu
testen 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 Webapplikationen
abgeleitet. Besonders durch die Bereitstellung in einem Web Container,
der den Zugriff auf eine Datenbank oder das Dateisystem ermöglicht, sind
Webservices sehr mit Webapplikationen verwandt. So kann auch ein Webservice
anfällig sein gegenüber Cross-site scripting, SQL injections, Buffer overflows,
. . . Auch das SOA-Dreieck ist verwundbar, wenn ein Angreifer z.B. gezielt
einen 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 Sicherheit
kurz 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 einer
Serviceimplementierung werden andere Services genutzt. Letztendlich wird eine Komposition
durch einen äußeren Service repräsentiert. Daher ist eine nach Kapitel 3 entwickelte
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 die
Technologie vollständig überschattet wird. D.h. alle Werkzeuge arbeiten nur mit der
Technologie ohne Berücksichtigung der Plattform. Abbildung 8.2 illustriert eine verbreitete
Ausprägung einer SOA bei Kompositionen, die Webservices als Technologie
einsetzt.
Im Falle einer Komposition wird ein Service als Komponente vererbt. Die Serviceimplementierung
muss nicht geändert werden, weil andere Services kein Bestandteil der
Serviceimplementierung sind. Für die Technologie Webservices befinden sich einige
Werkzeuge auf dem Markt, mit denen ein Tester Komponententests für Kompositionen
realisieren kann:
• BPELUnit [May06]: Ein Werkzeug, das speziell Komponententests für in BPEL
realisierte Geschäftsprozesse ermöglicht. Webservices können durch Mocks ersetzt
werden, so dass nur der in BPEL realisierte Geschäftsprozess getestet
71

8. Verwandte Arbeiten
Abbildung 8.2.: Eine verbreitete Ausprägung einer SOA bei Kompositionen
wird.
• soapUI [MRHB]: Ein Werkzeug zum Testen von Webservices, dass die Erstellung
von Mocks für Kompositionen ermöglicht.
Alle vorgestellten Werkzeuge haben gemeinsam, dass unter Kenntnis der Serviceschnittstelle
eine Serviceimplementierung erstellt werden kann. Diese neue Serviceimplementierung
wird in einem eigenen Container bereitgestellt und steht als Mock zur
Verfü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 Serviceanbieter
bzw. -entwickler muss die Qualität seiner Services selbst sicherstellen. Für eine
Komposition ist unter Einsatz von Mocks zu testen, ob die Einbindung eines Services
erfolgreich ist.
72

9. Zusammenfassung und Ausblick
9.1. Rückblick
Services sind die aktiven und individuellen Einheiten in einer SOA. Jeder Service bietet
Dienste an, die ein Servicekonsument nutzt. Dabei verlässt sich der Servicekonsument
auf den Service, so dass Tests unabdingbar werden. Speziell das Umfeld in dem
letztendlich 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 Vorgehen
zur Identifikation dieser Probleme beschrieben werden.
• Eine Testmatrix, die Testaspekte einer Serviceumgebung zuordnet.
• Testszenarien, die detailliert das Vorgehen zur Identifikation eines Testaspekts
beschreiben.
Für eine SOA leiten sich nach Abschnitt 3.2.1 Testaspekte aus drei verschiedenen
Ebenen ab: Idee, Technologie und Plattform. Die Kenntnis von konkreten Testaspekten
erlaubt unter Einbezug des Projektumfelds eine Testmatrix aufzustellen. Abschließend
sieht das in Abschnitt 3.3.2 beschriebene Vorgehen zur Findung einer Teststrategie die
Formulierung von Testszenarien vor.
Moderne Entwicklungsumgebungen und Plattformen für Unternehmensanwendungen
verbergen die Komplexität von Webservices bei der Entwicklung. Ein Entwickler schreibt
eine normale Klasse, die gezielt annotiert, direkt als Webservice nutzbar ist. Folglich
sind Kenntnisse in der XML, WSDL, . . . nicht mehr notwendig. Dennoch ist ein Webservice
anfällig gegenüber den in Kapitel 4 genannten Testaspekten, die als verborgene
Fehlerquellen entstehen.
Gilt es eine Serviceimplementierung zu testen, so sind oftmals bekannte Verfahren
und Methoden anwendbar. Betrachtet man jedoch einen Service, so versagen viele
Konzepte, weil ein Service durch die Bereitstellung einer Serviceimplementierung entsteht.
Dadurch liegt ein Service entfernt und kann während eines Tests nicht mehr
manipuliert werden.
Diese Arbeit hat in Abschnitt 3.4.3 im Rahmen von Komponententests ein Vorgehen
beschrieben, dass gezielt eine Serviceimplementierung manipuliert. Durch eine sich
anschließende Bereitstellung entsteht ein einzigartiger Service, so dass gezielt Teile
dieses Service isoliert getestet werden können. In Kapitel 5 wurde ein Werkzeug
vorgestellt, das den Einsatz von harten und weichen Mocks in einem Webservice ermöglicht.
73

9. Zusammenfassung und Ausblick
Abschließend betrachtete diese Arbeit die Webservices eines Unternehmens unter
Anwendung einer zuvor nach Kapitel 3 ermittelten Teststrategie. Als Grundlage dienten
die Testaspekte aus Kapitel 4 und Testfälle wurden mit dem Werkzeug aus Kapitel 5
formuliert.
9.2. Ausblick
Kapitel 3 stellt das Vorgehen zur Findung einer Teststrategie zunächst ausschließlich
für SOA vor. Dennoch sind die Artefakte allgemeingültig einsetzbar, aber auch leicht
anpassbar 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 Ableitung
von Testfällen detailliert zu beschreiben. Dazu ist evtl. die präsentierte
Vorlage aus Abschnitt 3.3.3 individuell anzupassen.
Nach Abschnitt 3.2.1 kann jede Ebene einer SOA verschiedene Ausprägungen aufweisen.
Auch wenn in dieser Arbeit für die Idee und Technologie keine Alternativen
angegeben wurden, so kann deren Existenz nicht ausgeschlossen werden. Im Allgemeinen
entsteht durch die Ableitung von Testaspekten für verschiedene Ausprägungen
ein Katalog, aus dem man sich bei der Definition einer Teststrategie frei bedienen
kann. Neuen Testaspekten sind dabei keine Grenzen gesetzt, denn selbst die Sammlung
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 Serviceimplementierung
setzt sich aus sehr viel mehr Einheiten zusammen. Vielleicht gelingt es
sogar den Austausch durch Mocks in die Entwicklungsumgebung zu integrieren, so
dass eine einfachere Verwaltung des Deployment entsteht.
Services erben nach Abschnitt 3.4.2 die Komponente durch die zugrunde liegende
Implementierung. In-Container Tests, wie sie Cactus nach Abschnitt 8.1 durchführt
sind auch für Services sinnvoll. Vielmehr aber wäre eine Kombination von Ansätzen
interessant:
• Abschnitt 5.6 hat aufgezeigt, dass eine Steuerungseinheit zur Manipulation eines
bestimmten Service praktisch nicht umsetzbar ist. Gelingt es für einen bestimmten
Endpunkt einen Service anzubieten, auf den die Steuereinheit Zugriff hat, so
ist keine Änderung im Quellcode der zugehörigen Serviceimplementierung mehr
nötig. Es muss nur ein spezielles Deployment bestehend aus Steuereinheit und
Service hergestellt werden.
• Die Manipulation eines Services durch eine Steuereinheit erfolgt durch das Einfügen
von Mock-Objekten zur Laufzeit. Dazu ist ähnlich wie bei bekannten Werkzeugen
(siehe z.B. [FMP + ]) eine Fabrik für Mock-Objekte anzubieten.
Der Einsatz einer Steuereinheit ändert nicht die Serviceimplementierung, sondern nur
das Deployment. Dies erlaubt z.B. in .NET oder Java EE den Einsatz von Komponen-
74

9. Zusammenfassung und Ausblick
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 Teststrategie
für eine SOA ermitteln lässt. Die Ergebnisse einer einmaligen Analyse sind
in ähnlichen Projekten wieder verwendbar. Die im Rahmen der Fallstudie vorgeschlagene
Teststrategie kann als Grundlage für eine eigene Teststrategie dienen. Durch
Kenntnis der eingeführten Begriffe und Artefakte ist es möglich eine Teststrategie an
die eigenen Bedürfnisse anzupassen.
Diese Arbeit stellt für die Microsoft Visual Studio Team Edition ein vollfunktionsfähiges
Werkzeug zur Verfügung. Ein Tester kann nicht nur einfach Serviceumgebungen realisieren,
sondern erhält auch die Kontrolle über das Deployment eines Services. Dies
erlaubt Teile eines Services isoliert zu testen, so dass die Ableitung von Testfällen
erleichtert wird.
Im Rahmen der Fallstudie entstanden automatisierte Testfälle, die dem vorgestellten
Unternehmen helfen, die Qualität ihrer Webservices kontinuierlich zu überwachen. Die
Fallstudie hat gezeigt, dass schon das Testen von einzelnen Services eine starke Hebelwirkung
hat. Es genügt nicht nur die Serviceimplementierung in einer lokalen Serviceumgebung
zu testen, sondern auch der Übergang zu einem Service muss vollzogen
werden. Dabei hilft das systematische Vorgehen einer Teststrategie, die gezielt
nach vorher identifizierten Problemen sucht.
Diese Arbeit schafft eine allgemeine Grundlage zum Testen in einer SOA. Durch die
Kenntnis der beschriebenen Konzepte, können alle Produkte dieser Arbeit in beliebigen
Projekten praktisch eingesetzt werden.
75

Literaturverzeichnis
[ACD + 03] ANDREWS, Tony ; CURBERA, Francisco ; DHOLAKIA, Hitesh ; GOLAND,
Yaron ; KLEIN, Johannes ; LEYMANN, Frank ; LIU, Kevin ; ROLLER, Dieter
; SMITH, Doug ; THATTE, Satish ; TRICKOVIC, Ivana ; WEERAWA-
RANA, Sanjiva: Business Process Execution Language for Web Services
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 Requirements
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 Approach.
Springer, 2003
[CP06]
[FMP + ]
CANFORA, Gerardo ; PENTA, Massimiliano D.: Testing Services and Service-
Centric Systems: Challenges and Opportunities. In: IT Pro March/April
(2006), S. 10–17
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]
[GP06]
GOODLIFFE, Pete: Code Craft: The Practice of Writing Excellent Code. No
Starch Press, 2006
GUCKENHEIMER, Sam ; PEREZ, Juan J.: Software Engineering with Microsoft
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

Literaturverzeichnis
[IEE90]
Concepts and Principles.
(2005), S. 75–81
In: IEEE Internet Computing January/February
IEEE COMPUTER SOCIETY: IEEE Std 610.12-1990 - IEEE Standard Glossary
of Software Engineering Terminology. IEEE Computer Society, 1990
[IEE04] IEEE COMPUTER SOCIETY: Guide to the Software Engineering Body of
Knowledge. 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. Addison
Wesley, 2006
[KBP02] KANER, Cem ; BACH, James ; PETTICHORD, Bret: Lessons learned in software
testing: a context-driven approach. John Wiley & Sons, 2002
[May06]
MAYER, Philip: Design and Implementation of a Framework for Testing BPEL
Compositions, Leibniz Universität Hannover, Masterarbeit, 2006
[McC06] MCCAFFREY, James D.: .NET Test Automation Recipes: A Problem-Solution
Approach. Apress, 2006
[MFC01] MACKINNON, Tim ; FREEMAN, Steve ; CRAIG, Philip: Endo-Testing: Unit
Testing with Mock Objects. In: Extreme programming examined, Addison-
Wesley Longman Publishing Co., Inc., 2001, 287-301
[Mica]
[Micb]
[MRHB]
MICROSOFT CORPORATION: Overview of Data-Driven Unit Tests. http:
//msdn2.microsoft.com/library/ms182519.aspx
MICROSOFT CORPORATION: Windows Communication Foundation. http:
//msdn2.microsoft.com/netframework/aa663324.aspx
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]
[Par]
PAPAZOGLOU, Mike P.: Service-Oriented Computing: Concepts, Characteristics
and Directions. In: WISE ’03: Proceedings of the Fourth International
Conference on Web Information Systems Engineering, IEEE Computer Society,
2003, S. 3
PARASOFT CORPORATION: SOAtest. http://www.parasoft.com
77

Literaturverzeichnis
[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 Foundations
- 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 Softwareentwicklungsprozesses
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: Interoperability
Testing Tools 1.1. http://www.ws-i.org/deliverables/
workinggroup.aspx?wg=testingtools
[The06] THE WEB SERVICES-INTEROPERABILITY ORGANIZATION: Basic Profile
Version 1.1. http://www.ws-i.org/Profiles/BasicProfile-1.1.
html. Version: 10 2006
[Typ]
[W3C]
TYPEMOCK LTD.: TypeMock.NET. http://www.typemock.com
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: Core
Language. 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: Trustworthy
Web Services Based on Testing. In: SOSE ’05: Proceedings of the
IEEE International Workshop, IEEE Computer Society, 2005, S. 167–177
78

A. Testszenarien
1 / Testaspekt Funktionalität
Tester
Serviceumgebung
Abdeckung
Risiken
Vorbedingungen
Durchführung
Mocks
Aktivitäten
Entwickler
lokal
Einsatz von bekannten Methoden und Werkzeugen zur
Durchführung von Komponententests bei objektorientierter
Software. Für weitere Informationen sei z.B. auf [Bec03]
oder [McC06] verwiesen.
Der Webservice zeigt unerwartetes Verhalten aufgrund einer
fehlerhaften oder unvollständigen Implementierung. Wenn
sich der Code ändert, z.B. durch Einfügen einer neuen Funktionalität,
können Fehler versteckt bleiben.
Die Serviceimplementierung ist vorhanden und testbar.
Automatisiert
Mocks sind so einzusetzen, dass ein Teil der Serviceimplementierung
einzeln und isoliert getestet wird.
1. Testen der funktionalen Korrektheit und Vollständigkeit
der zu testenden Komponente.
2. Testen von angemessener Fehlerbehandlung.
Erfolgsbedingungen
Fehlschlagbedingungen
Ein erwarteter Effekt tritt ein.
• Ein erwarteter Effekt bleibt aus.
• Eine unerwartete Fehlermeldung tritt auf.
79

A. Testszenarien
2 / Testaspekt Datentransferobjekte
Tester
Serviceumgebung
Abdeckung
Entwickler
lokal
Grundlegende Prüfung der WSDL, um
• zirkuläre Abhängigkeiten
• nicht unterstützte XML Abbildungen
zu identifizieren.
Risiken
Vorbedingungen
Durchführung
Mocks
Aktivitäten
Der Webservice ist bei Verwendung bestimmter Eingabeoder
Ausgabedaten nicht nutzbar. Zirkuläre Abhängigkeiten
können verborgen sein.
Eine Webservice Operation benutzt komplexe Datentypen,
d.h. es werden nicht nur primitive Datentypen eingesetzt. Betrifft
Eingabe- und Ausgabedaten.
Automatisiert
keine
1. Erstellen von vollständig aufgelösten Datentransferobjekten,
d.h. komplexe Objekte sind nicht null.
2. Durchführen einer XML-Serialisierung zur Erzeugung
einer entsprechenden XML-Repräsentation.
3. Deserialiserung der XML-Repräsentation aus Schritt
2 zur Erzeugung eines mehrfach umgewandelten Objekts.
Erfolgsbedingungen
• Es wird keine Ausnahme erzeugt.
• Das ursprüngliche und mehrfach umgewandelte Objekt
sind identisch.
Fehlschlagbedingungen
• Eine Ausnahme wird geworfen.
• Das ursprüngliche und mehrfach umgewandelte Objekt
sind unterschiedlich.
80

A. Testszenarien
3a / Testaspekt
Tester
Serviceumgebung
Abdeckung
Risiken
Vorbedingungen
Verifizierung des Deployment
Entwickler
lokal/entfernt
Überprüft die Existenz von grundlegenden Funktionalitäten,
die ein Service anbietet.
Der Service ist nicht nutzbar.
• Eine Serviceimplementierung ist vorhanden.
• Interne Testpunkte sind vorhanden und erlauben auftretende
Fehler gezielt zu verfolgen.
Durchführung
Mocks
Aktivitäten
Automatisiert
Die Datenzugriffsschicht.
1. Interaktion mit dem Service, so dass möglichst viele Interaktionsmöglichkeiten
ausgenutzt werden. So ist z.B.
für Webservices jede Operation mindestens einmal anzusprechen.
Erfolgsbedingungen
Fehlschlagbedingungen
Der Service erzeugt den erwarteten Effekt.
• Der Service liefert eine Fehlermeldung.
• Ein interner Testpunkt wirft eine Fehlermeldung.
81

A. Testszenarien
3b / Testaspekt
Tester
Serviceumgebung
Abdeckung
Risiken
Vorbedingungen
Verifizierung des Deployment
Entwickler
entfernt/test
Überprüft die Existenz von grundlegenden Funktionalitäten,
die ein Service anbietet.
Der Service ist nicht nutzbar.
• Der Service wurde bereitgestellt.
• Interne Testpunkte sind vorhanden und erlauben auftretende
Fehler gezielt zu verfolgen.
Durchführung
Mocks
Aktivitäten
Automatisiert
keine
1. Interaktion mit dem Service, so dass alle Subsysteme,
die der Service nutzt, angesprochen werden.
Erfolgsbedingungen
Fehlschlagbedingungen
Der Service erzeugt den erwarteten Effekt.
• Der Service liefert eine Fehlermeldung.
• Ein interner Testpunkt wirft eine Fehlermeldung.
82

A. Testszenarien
3c / Testaspekt
Tester
Serviceumgebung
Abdeckung
Risiken
Vorbedingungen
Durchführung
Mocks
Aktivitäten
Verifizierung des Deployment
Entwickler
entfernt/live
Überprüft die Existenz von grundlegenden Funktionalitäten,
die ein Service anbietet.
Der Service ist nicht nutzbar.
Der Service wurde mit einer endgültigen Konfiguration in einer
produktiven Serivceumgebung bereitgestellt.
Automatisiert
keine
1. Defensive Interaktion mit dem Service, d.h. der innere
Zustand des Service oder von anderen beteiligten
Systemen darf sich nicht ändern. Dennoch sollte die
Interaktion so viele Subsysteme wie möglich ansprechen.
Erfolgsbedingungen
Fehlschlagbedingungen
Der Service erzeugt den erwarteten Effekt.
Der Service liefert eine Fehlermeldung.
83

A. Testszenarien
4a / Testaspekt
Tester
Serviceumgebung
Abdeckung
Konfigurationen
Entwickler
lokal/entfernt, entfernt/test
Überprüft die Korrektheit von allen in einem Service genutzten
Konfiguration. Im Allgemeinen benötigen z.B. die folgenden
Einheiten eine gültige Konfiguration:
• der Container
• Ressourcen, die in der Datenzugriffsschicht genutzt
werden
• eingesetzte Bibliotheken
Risiken
Vorbedingungen
Der Service ist nicht nutzbar.
• Die Konfiguration einer Einheit ist verfügbar.
• Interne Testpunkte sind vorhanden und erlauben auftretende
Fehler gezielt zu verfolgen.
Durchführung
Mocks
Aktivitäten
Automatisiert
Nicht benötigte Ressourcen.
1. Interaktion mit dem Service, so dass eine Einheit genutzt
wird.
Erfolgsbedingungen
Fehlschlagbedingungen
Der Effekt der Einheit tritt ein.
• Der Service liefert eine Fehlermeldung.
• Ein interner Testpunkt wirft eine Fehlermeldung.
84

A. Testszenarien
4b / Testaspekt
Tester
Serviceumgebung
Abdeckung
Risiken
Vorbedingungen
Konfigurationen
Entwickler
lokal/entfernt, entfernt/test
Ein Service wird mit unterschiedlichen Konfigurationen in
sehr unterschiedlichen Umgebungen eingesetzt.
Der Service ist nicht nutzbar.
• Alle neuen Umgebungen sind verfügbar.
• Die Konfiguration für jede neue Umgebung ist verfügbar.
• Interne Testpunkte sind vorhanden und erlauben auftretende
Fehler gezielt zu verfolgen.
Durchführung
Mocks
Aktivitäten
Automatisiert
Nicht benötigte Ressourcen.
1. Interaktion mit dem Service, so dass eine Konfiguration
verarbeitet wird.
Erfolgsbedingungen
Fehlschlagbedingungen
Der Service erzeugt einen erwarteten Effekt.
• Der Service liefert eine Fehlermeldung.
• Ein interner Testpunkt wirft eine Fehlermeldung.
85

A. Testszenarien
5a / Testaspekt
Tester
Serviceumgebung
Abdeckung
Risiken
Vorbedingungen
Autorisierung und Authentifizierung
Entwickler, Tester
lokal/entfernt
Überprüft, ob nur berechtigte Nutzer mit einem Service interagieren
können.
Services können mit vertraulichen Daten arbeiten oder lösen
Effekte in der realen Welt aus. Daher sind Services vor
unberechtigten Zugriffen zu schützen.
• Der Service ist öffentlich zugänglich, aber die Interaktion
mit dem Service soll nur einem beschränkten Nutzerkreis
möglich sein.
• Interne Testpunkte sind vorhanden und erlauben auftretende
Fehler gezielt zu verfolgen.
Durchführung
Mocks
Aktivitäten
Automatisiert
Die Geschäftslogikschicht und/oder Datenzugriffsschicht.
1. Aufrufen einer Operation ohne Übermittlung von Daten
zur Authentifizierung.
2. Aufrufen einer Operation mit verschiedenen ungültigen
Daten zur Authentifizierung.
Erfolgsbedingungen
Fehlschlagbedingungen
Der Service liefert eine Fehlermeldung.
• Der Service verarbeitet die Anfrage und erzeugt einen
Effekt.
• Ein interner Testpunkt wirft eine Fehlermeldung.
86

A. Testszenarien
5b / Testaspekt
Tester
Serviceumgebung
Abdeckung
Risiken
Vorbedingungen
Autorisierung und Authentifizierung
Entwickler, Tester
lokal/entfernt
Eine Authentifizierung prüft, ob ein Benutzer die Erlaubnis
hat mit einem Service überhaupt zu interagieren. Eine Autorisierung
überprüft, ob ein Benutzer die Rechte hat angeforderte
Dienste in Anspruch zu nehmen.
Einem authentifizierten Benutzer ist nicht immer erlaubt alle
Aktionen auszuführen, die durch einen Service angeboten
werden.
• Der Service ist öffentlich zugänglich und seine Dienste
sollen nur einem beschränkten Nutzerkreis zur Verfügung
stehen.
• Interne Testpunkte sind vorhanden und erlauben auftretende
Fehler gezielt zu verfolgen.
Durchführung
Mocks
Aktivitäten
Automatisiert
Die Geschäftslogikschicht und/oder Datenzugriffsschicht.
1. Interaktion mit dem Service unter Angabe von gültigen
Daten zur Authentifizierung, aber mit dem Versuch
auf Dienste zuzugreifen, für die entsprechende Rechte
fehlen.
Erfolgsbedingungen
• Der Service liefert eine Fehlermeldung.
• Der Service erzeugt keinen Effekt.
Fehlschlagbedingungen
• Der Service verarbeitet die Anfrage und erzeugt einen
Effekt.
• Ein interner Testpunkt wirft eine Fehlermeldung.
87

A. Testszenarien
6 / Testaspekt Fehlendes Subsystem
Tester
Serviceumgebung
Abdeckung
Risiken
Vorbedingungen
Durchführung
Mocks
Aktivitäten
Entwickler
lokal/entfernt oder entfernt/test
Das Verhalten des Services, wenn ein Subsystem nicht verfügbar
ist.
Der Service ist nicht nutzbar.
Ein Subsystem ist nicht verfügbar.
Manuell
keine
1. Interaktion mit dem Service, so dass das nicht verfügbare
Subsystem angesprochen wird.
Erfolgsbedingungen
• Der Service sucht nach Alternativen oder wirft eine angemessene
Fehlermeldung.
• Die Abwesenheit des Subsystems wird festgehalten
und eine zuständige Person informiert.
Fehlschlagbedingungen
• Der Service stellt das fehlende Subsystem nicht fest,
so dass ein unerwarteter Effekt entsteht.
• Der Service wirft eine unangemessene Fehlermeldung.
88

A. Testszenarien
7a / Testaspekt
Tester
Serviceumgebung
Abdeckung
Risiken
Vorbedingungen
Annahmen an Eingabedaten
Entwickler, Tester
lokal/entfernt
Jeder Service muss alle Eingabedaten auf Gültigkeit überprüfen
und Fehler durch eine Meldung anzeigen. Eingabedaten
werden sowohl von Servicekonsumenten, als auch von
anderen Services, bezogen.
Ungültige Eingabedaten gefährden die Integrität des Services,
indem es z.B. zu langen Verarbeitungszeiten, Angriffen
oder allgemein unberechenbarem Verhalten kommt.
• Eine Serviceimplementierung liegt vor.
• Interne Testpunkte sind vorhanden und erlauben auftretende
Fehler gezielt zu verfolgen.
Durchführung
Mocks
Aktivitäten
Automatisiert
Die Geschäftslogikschicht. Wenn ein Test fehlschlägt, ist dieser
Test erneut ohne Mocks durchzuführen und das Verhalten
zu beobachten.
1. Identifikation aller Annahmen an Eingabedaten.
2. Auswahl von Repräsentanten für ungültige Eingabedaten.
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
Fehlschlagbedingungen
Der Service liefert eine Fehlermeldung, die angibt, dass zur
Verfügung gestellte Eingabedaten nicht verarbeitet werden
können.
• Der Service arbeitet ohne Fehlermeldung weiter und
erzeugt einen Effekt.
• Der Service liefert eine unerwartete Fehlermeldung.
• Ein interner Testpunkt wirft eine Fehlermeldung.
89

A. Testszenarien
7b / Testaspekt
Tester
Serviceumgebung
Abdeckung
Risiken
Vorbedingungen
Annahmen an Eingabedaten
Entwickler, Tester
lokal/entfernt
Gegenprobe zu Testszenario 7a unter Verwendung von gültigen
Eingabedaten.
Dokumente und andere Quellen, die zur Analyse von Annahmen
an Eingabedaten in Testszenario 7a genutzt wurden,
können fehlerhaft sein.
• Eine Serviceimplementierung liegt vor.
• Interne Testpunkte sind vorhanden und erlauben auftretende
Fehler gezielt zu verfolgen.
• Testszenario 7a wurde durchgeführt und die Ergebnisse
der anfänglichen Analyse sind noch verfügbar.
Durchführung
Mocks
Aktivitäten
Automatisiert
Die Geschäftslogikschicht.
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
Fehlschlagbedingungen
Der Service erzeugt einen erwarteten Effekt.
• Der Service liefert eine Fehlermeldung.
• Ein interner Testpunkt wirft eine Fehlermeldung.
90

A. Testszenarien
8 / Testaspekt Versteckte Grenzen
Tester
Serviceumgebung
Abdeckung
Risiken
Vorbedingungen
Entwickler, Tester
lokal/entfernt, entfernt/test
Durch den Einsatz einer Schichtenarchitektur oder dem Nutzen
von Subsystemen entstehen Grenzen, an denen unterschiedliche
Datentypen und Annahmen an die Daten zu Fehlern
führen können. Probleme sind versteckt und schwierig
zu identifizieren.
Der Service kann intern mit ungültigen Werten arbeiten.
• Eine Serviceimplementierung liegt vor.
• Falls erforderlich, ist der Service in einer entfernt/test
Serviceumgebung bereitzustellen.
Durchführung
Mocks
Aktivitäten
Manuell
keine
1. Identifikation von Grenzen zwischen allen Schichten
und Ressourcen, d.h. die Grenzen selbst und alle ausgetauschten
Objekte sind bekannt.
2. Für jedes Objekt, das über eine Grenze ausgetauscht
wird, ist der Datentyp bzw. aufgespannte Datenraum
zu bestimmen.
3. Reduktionen im Datenraum identifizieren.
4. Falls erforderlich sind Daten so in den Service einzupflegen,
dass eine potentielle Reduktion im Datenraum
entsteht.
5. Interaktion mit dem Service, so dass potentiell reduzierte
Daten genutzt werden.
Erfolgsbedingungen
• Der Service kompensiert eine Reduktion im Datenraum
und arbeitet in jedem Fall korrekt.
• Der Service wirft eine angemessene Fehlermeldung.
Fehlschlagbedingungen
Der Service verwendet die potentiell reduzierten Daten, so
dass der Effekt des Services fehlerhaft ist.
91

A. Testszenarien
9 / Testaspekt Rückwärtskompatibilität
Tester
Serviceumgebung
Abdeckung
Risiken
Vorbedingungen
Entwickler
lokal/entfernt, entfernt/test
Die Serviceschnittstellte ist ein einzuhaltender Vertrag. Immer
wenn sich Änderungen am Service ergeben, muss die
Serviceschnittstelle rückwärtskompatibel bleiben.
Jede Änderung in der Serviceschnittstelle kann zu Änderungen
bei allen Servicekonsumenten führen. Die Servicekonsumenten
werden unzufrieden, weil sie evtl. zeitintensive
Änderungen in ihrer eigenen Software vornehmen müssen.
Fehler treten evtl. nur bei bestimmten Interaktionen auf und
sind daher zunächst versteckt.
1. Für den Service existieren automatische Tests und diese
Tests setzen einen Proxy zur Interaktion mit dem
Service ein.
2. Keiner der Tests aus Vorbedingung 1 schlägt fehl.
Durchführung
Mocks
Aktivitäten
Automatisiert
Werden vom eingesetzten Test übernommen.
1. Erstellen eines Proxy für den aktuellen produktiven
Service.
2. Ausführen aller verfügbaren Tests mit dem neuen
Proxy.
Erfolgsbedingungen
Fehlschlagbedingungen
Alle Tests sind erfolgreich.
Ein Test schlägt fehl.
92

A. Testszenarien
10 / Testaspekt Interoperabilität
Tester
Serviceumgebung
Abdeckung
Risiken
Vorbedingungen
Tester
entfernt/test
Der Service kann von beliebigen Plattformen eingesetzt werden,
ist aber gebunden an eine Technologie.
Der Service steht nur einem beschränkten Kreis von Nutzern
zur Verfügung.
• Der Service ist in einer entfernt/test Serviceumgebung
verfügbar.
• Eine andere Plattform, die sich von der zur Bereitstellung
genutzten Plattform unterscheidet, ist verfügbar.
Bevorzugt sind für den Test verbreitete Plattformen zu
wählen, die vorrangig von Kunden eingesetzt werden.
Durchführung
Mocks
Aktivitäten
Manuell
keine
1. Benutzen des Services mit einer anderen Plattform.
Erfolgsbedingungen
Fehlschlagbedingungen
Der Service bearbeitet die Anfrage wie erwartet.
Der Service liefert eine Fehlermeldung.
93

A. Testszenarien
11 / Testaspekt Funktionalität
Tester
Serviceumgebung
Abdeckung
Risiken
Vorbedingungen
Tester
entfernt/test
Spezifikationen und die Servicedokumentation beschreiben
das Verhalten eines Services.
Der Service arbeitet nicht wie es von einem Servicekonsument
erwartet wird. Dadurch lässt er sich nicht wie gewünscht
einsetzen.
• Dokumente, die den Effekt eines Services beschreiben,
wurden identifiziert.
• Der Service ist in einer entfernt/test Serviceumgebung
verfügbar.
Durchführung
Mocks
Aktivitäten
Manuell
keine
1. Überprüfen, ob eine Funktion oder ein Effekt, den der
Service liefern soll, eintritt.
Erfolgsbedingungen
Fehlschlagbedingungen
Der Service bearbeitet die Anfrage wie in einem Dokument
festgelegt.
• Der Service zeigt vom Dokument abweichendes Verhalten.
• Der Service wirft eine unerwartete Fehlermeldung.
94

Erklärung der Selbstständigkeit
Hiermit versichere ich, dass ich die vorliegende Masterarbeit selbständig und ohne
fremde Hilfe verfasst und keine anderen als die in der Arbeit angegebenen Quellen
und Hilfsmittel verwendet habe. Die Arbeit hat in gleicher oder ähnlicher Form noch
keinem anderen Prüfungsamt vorgelegen.
Hannover, den 29. Oktober 2007
Dennis Hardt
95