Testen von serviceorientierten Architekturen: Teststrategie und Implementierung

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