Testen von serviceorientierten Architekturen: Teststrategie und Implementierung

Größe: px
Ab Seite anzeigen:

Download "Testen von serviceorientierten Architekturen: Teststrategie und Implementierung"

Transkript

1 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

2 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

3 Inhaltsverzeichnis 1. Einführung Motivation Problemstellung Struktur dieser Arbeit Grundlagen Testen Grundbegriffe Ausgewählte Testmethoden Teststufe Teststrategie Serviceorientierte Architekturen Grundbegriffe Konsequenzen Plattformen für Unternehmensanwendungen Webservices Grundbegriffe Webservice Standards Zusammenfassung Ableitung einer Teststrategie für serviceorientierte Architekturen Einordnung der Teststrategie Einflüsse auf die Teststrategie Idee, Plattform und Technologie Projektumfeld Teststrategie Serviceumgebung Vorgehensweise Testszenario Komponententests für eine SOA Vorgehen Identifikation der Komponente bei Services Austauschen von Komponenten in Services Zusammenfassung Testaspekte für SOA, Webservices und.net Identifikation von Testaspekten SOA als Idee iii

4 Inhaltsverzeichnis Webservices als Technologie NET als Plattform Analogien zu Java EE Zusammenfassung Werkzeugunterstützung für die Teststrategie Überblick Anforderungen Konsequenzen Prozess Testmöglichkeiten in.net Architektur Grobarchitektur Testablauf Adapter zu einem Unit Test Framework Interaktion mit externen Systemen Implementierung Realisierung von harten Mocks Identifikation von auszutauschenden Teilen Verarbeitung und Austauschen von Code Realisierung von weichen Mocks Zusammenfassung Fallstudie Projektumfeld Betrachtete Webservices Bisheriges Vorgehen beim Testen der Webservices Eine konkrete Teststrategie Annahmen Testmatrix und Testszenarien Anwendung der Teststrategie Umsetzung Gefundene Fehler Lektionen und Bewertung Zusammenfassung Kritische Würdigung Kritischer Rückblick auf den Erarbeitungsprozess Stärken und Schwächen einer Teststrategie Stärken und Schwächen der entwickelten Erweiterungen Kritischer Rückblick auf die Fallstudie Verwandte Arbeiten Andere Ansätze und Werkzeuge Testaspekte Testen von Kompositionen iv

5 Inhaltsverzeichnis 9. Zusammenfassung und Ausblick Rückblick Ausblick Fazit Literaturverzeichnis 76 A. Testszenarien 79 v

6 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

7 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 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 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

8 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

9 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 Testen 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

10 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 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

11 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

12 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 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

13 2. Grundlagen 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 Serviceorientierte Architekturen 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

14 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

15 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 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

16 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

17 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 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 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

18 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

19 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 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 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

20 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 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

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1 Test Dipl. Wirtsch. Ing. Alexander Werth 9-1 Phasen der Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung Methoden der 9-2 Software Test / Erprobung Messen der

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Comparing Software Factories and Software Product Lines

Comparing Software Factories and Software Product Lines Comparing Software Factories and Software Product Lines Martin Kleine kleine.martin@gmx.de Betreuer: Andreas Wuebbeke Agenda Motivation Zentrale Konzepte Software Produktlinien Software Factories Vergleich

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept Testkonzept 1.Einführung Um die Zuverläsigkeit und die Qualität der Software und des gesamten Systems zu verbessern, sind Tests durchzuführen. Die Testreihe läst sich in drei Stufen einteilen, nülich Komponententest,

Mehr

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Jan Düttmann Archimedon Software + Consulting GmbH & Co. KG Marienstraße 66 32427 Minden Stephan Kleuker Hochschule

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

Mehr

Richtig testen in SOA/BPM-Projekten

Richtig testen in SOA/BPM-Projekten Richtig testen in SOA/BPM-Projekten Erfahrungen und Best Practices Dipl.-Inform. Holger Breitling, Mitglied der Geschäftsleitung Dipl.-Inform. Johannes Rost, Software-Architekt 24. September 2010 C1 WPS

Mehr

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128 ... Einleitung... 15 1... Grundlagen der Modellierung von Enterprise Services... 23 1.1... Serviceorientierte Architekturen... 26 1.1.1... Merkmale serviceorientierter Architekturen... 27 1.1.2... SOA

Mehr

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

Mehr

Testautomatisierung. Märchen, Möglichkeiten und praktischer Nutzen. Richard Seidl 21. Januar 2013 TU Dresden. Medizin- und Informationstechnik AG

Testautomatisierung. Märchen, Möglichkeiten und praktischer Nutzen. Richard Seidl 21. Januar 2013 TU Dresden. Medizin- und Informationstechnik AG Medizin- und Informationstechnik AG Testautomatisierung Märchen, Möglichkeiten und praktischer Nutzen Richard Seidl 21. Januar 2013 TU Dresden Kardiologische Funktionsdiagnostik Vitalfunktions-Monitoring

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Einführung von Testautomatisierung reflektiert Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Matt Young Leiter Test Acquiring Inhaltsverzeichnis Einleitung Testautomatisierung PostFinance

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

E-Business Architekturen

E-Business Architekturen E-Business Architekturen Übung 3b Entwicklung eigener Service-Angebote 01.03.2015 Prof. Dr. Andreas Schmietendorf 1 Ziele der Übung Möglichkeiten zur Serviceimplementierung (ggf. auch Cloud) Umgang mit

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Testkonzept. Tipp-Star

Testkonzept. Tipp-Star Tipp-Star Version: V1.0-27.09.2015 Ablageort: Tipp-Star/01_Projektmanagement/03_Test Status: Fertig gestellt (In Bearbeitung / fertig gestellt / geprüft / freigegeben) Anzahl Seiten: 9 Autoren: tse Sergeyeva

Mehr

WS-Security. Thies Rubarth. Sicherheitskonzepte in global verteilten Anwendungen. 21. Sep 2007 ACM/GI Localgroup #216

WS-Security. Thies Rubarth. Sicherheitskonzepte in global verteilten Anwendungen. 21. Sep 2007 ACM/GI Localgroup #216 WS-Security Sicherheitskonzepte in global verteilten Anwendungen Thies Rubarth 21. Sep 2007 ACM/GI Localgroup #216 Thies Rubarth, M.Sc. (Informatik) IT Berater Jahrgang 1979 Anwendungsentwicklung seit

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Insert picture and click Align Title Graphic. Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Dr. Dieter Lederer, Geschäftsführer Vector Consulting Services GmbH

Mehr

Qualitätssicherungskonzept

Qualitätssicherungskonzept Softwaretechnikpraktikum Gruppe: swp15.aae SS 2015 Betreuer: Prof. Gräbe Datum: 15.06.2015 Tutor: Klemens Schölhorn Qualitätssicherungskonzept Projektteam: Felix Albroscheit Dorian Dahms Paul Eisenhuth

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Unit-Test Theorie und Praxis. Stephan Seefeld, INGTES AG

Unit-Test Theorie und Praxis. Stephan Seefeld, INGTES AG Unit-Test Theorie und Praxis Stephan Seefeld, INGTES AG Inhalt Was sind Unit-Test? NUnit für.net Demo Seite 2 Quellen Für diesen Vortrag verwendete Quellen: dotnet User Group Berlin Brandenburg http://www.dotnet-berlinbrandenburg.de/

Mehr

Last- und Stresstest. Überblick. Einleitung / Motivation Stresstest Lasttest Tools The Grinder Zusammenfassung

Last- und Stresstest. Überblick. Einleitung / Motivation Stresstest Lasttest Tools The Grinder Zusammenfassung Methoden und Werkzeuge zur Softwareproduktion WS 2003/04 Karsten Beyer Dennis Dietrich Überblick Einleitung / Motivation Stresstest Lasttest Tools The Grinder Zusammenfassung 2 Motivation Funktionstest

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Testplanung und Teststeuerung

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Testplanung und Teststeuerung 2007 Dr. Klaudia Dussa-Zieger P r a k t I s c h e Testprozess - Inhalt Testprozess Testen von Software-Systemen Systemen - Testprozess Lehrplan 2003 Testplanung Testausführung ierung Testendebewertung

Mehr

Testen - Konzepte und Techniken

Testen - Konzepte und Techniken Testen - Konzepte und Techniken Magdalena Luniak 21.11.2007 Magdalena Luniak () Testen - Konzepte und Techniken 21.11.2007 1 / 42 Übersicht 1 Motivation 2 Grundbegrie 3 Testen im Softwareentwicklungsprozess

Mehr

Automatisiertes Testen von Prüfplätzen

Automatisiertes Testen von Prüfplätzen EXCO. The Quality Company Solutions for Industry and R&D Automatisiertes Testen von Prüfplätzen Am Beispiel einer Prüfplatz-Software stellen wir einen toolgestützten Prozess zur Erstellung der erforderlichen

Mehr

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Lehrplan 2003 Testplanung

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Lehrplan 2003 Testplanung P r a k t I s c h e Testprozess - Inhalt Testprozess Testen von Software-Systemen Systemen - Testprozess Lehrplan 2003 Testplanung Testausführung ierung Testendebewertung Testberichterstattung Lehrplan

Mehr

Whitepaper. Automatisierte Akzeptanztests mit FIT. Einleitung. Die Bedeutung von Akzeptanztests

Whitepaper. Automatisierte Akzeptanztests mit FIT. Einleitung. Die Bedeutung von Akzeptanztests Automatisierte Akzeptanztests mit FIT Einleitung Dieses beschreibt, wie man Tests aus Anwender-/Kundensicht mit dem Open-Source-Werkzeug FIT beschreibt und durchführt. Das ist für Kunden, Anwender und

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

R016 Beilage 5: SOA-Glossar

R016 Beilage 5: SOA-Glossar Eidgenössisches Finanzdepartement EFD Informatiksteuerungsorgan des Bundes ISB R016 Beilage 5: SOA-Glossar Ausgabedatum: 2015-02-25 Version: 2.01 Status: Genehmigt Ersetzt: 2.0 Verbindlichkeit: Weisung

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Testest Du schon? Verfahren und Tools zum Testen von Software

Testest Du schon? Verfahren und Tools zum Testen von Software Testest Du schon? Verfahren und Tools zum Testen von Software Martin Kompf Dezember 2010 JAVA USER GROUP DARMSTADT Testing Software Ziel des Softwaretests ist es, Fehler aufzudecken. Nachzuweisen, dass

Mehr

Software Engineering II (IB) Testen von Software / Modultests

Software Engineering II (IB) Testen von Software / Modultests Testen von Software / Modultests Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Programm-Tests Tests sollen zeigen, dass ein Programm das tut was es tun soll sowie

Mehr

Test-Driven Developement Eine Einführung

Test-Driven Developement Eine Einführung Test-Driven Developement Eine Einführung 2007 by Tobias Hagen Im Rahmen der Veranstaltung Aktuelle Themen der Informatik bei Prof. Dr. Friedbert Kaspar Hochschule Furtwangen University Übersicht Einführung...

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design Softwaretechnik (Medieninformatik) Überblick: 6.1 Einleitung 6.2 Verfeinerung des Klassenmodells 6.3 Sequenzdiagramme 6.4 Umsetzung der Analysekonstrukte in das Design 6.5 Fallstudie 6.6 Software Kontrakte

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung

1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung Übersicht s s Gregoire Kemgne 1 Motivation Problem: Software wird immer größer und komplexer, dadurch ist diese immer schwerer zu überschauen Ein Projekt benötigt mehr Zeit und/oder Entwickler. Lösung:

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

Fabian Schmengler Pragmatisches Unit Testing. Meet Magento DE 2015

Fabian Schmengler Pragmatisches Unit Testing. Meet Magento DE 2015 Fabian Schmengler Pragmatisches Unit Testing Meet Magento DE 2015 1 Agenda Grundlagen: Warum automatisierte Tests? Tests und TDD mit Magento: Überblick und Beispiel Ausblick auf Magento 2 2 Warum Automatisiertes

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Webservices und Grid Computing Globus Toolkit 4 - Grundlagen ICA Joh.. Kepler Universität t Linz Eine Typische Grid-Applikation (Beispiel) VO Management Service Resource Discovery

Mehr

Inhalt. 1 Einführungsveranstaltung. 2 Qualität kompakt

Inhalt. 1 Einführungsveranstaltung. 2 Qualität kompakt Inhalt 1 Einführungsveranstaltung 1.1 Ziel der Veranstaltung Warum Qualität? Inhalt der Veranstaltung 1.2 Formaler Ablauf der Veranstaltung 1.3 Übungs- und Gruppeneinteilung 1.4 Bewertungskriterien mittels

Mehr

Repeatable Benchmarking Mahout

Repeatable Benchmarking Mahout Studienarbeitsexposé Repeatable Benchmarking Mahout Entwicklung eines Lasttest-Rahmenwerkes für Apache Mahout von: Oliver Fischer Institut für Informatik Humbold-Universität zu Berlin Matrikelnummer: 19

Mehr

Inhalt: Version 1.7.5

Inhalt: Version 1.7.5 Inhalt: Objekte ohne Methoden Objekte mit einfachen Methoden Objekte und Methoden mit Parametern Objekte und Methoden mit Rückgabewert Objekte mit einem Array als Attribut Beziehungen zwischen Objekten

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

HP Service Virtualization. Bernd Schindelasch 19. Juni 2013

HP Service Virtualization. Bernd Schindelasch 19. Juni 2013 HP Service Virtualization Bernd Schindelasch 19. Juni 2013 Agenda EWE TEL GmbH Motivation Proof of Concept Ausblick und Zusammenfassung HP Software Performance Tour 2013: HP Service Virtualization 2 EWE

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

EINE STRATEGIE FÜR OBJEKTORIENTIERTE SOFTWARE TESTEN- OMEN

EINE STRATEGIE FÜR OBJEKTORIENTIERTE SOFTWARE TESTEN- OMEN EINE STRATEGIE FÜR OBJEKTORIENTIERTE SOFTWARE TESTEN- OMEN Wissenschaftliches Arbeiten Recep IBILOGLU 0027849 534 Technische Universitaet Wien 1.Abstract Das Testen ist der kosten und zeitaufwendigste

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

Mehr

Die nächste Revolution in der modelgetriebenen Entwicklung?

Die nächste Revolution in der modelgetriebenen Entwicklung? Die nächste Revolution in der modelgetriebenen Entwicklung? Me Johannes Kleiber Software Engineer bei FMC Johannes.Kleiber@fmc-ag.com Themen Überblick Window Workflow Foundation Workflows modellieren WF

Mehr

Universal Testing. Intelligentes & effizientes Testen mit Universal. Consor AG Ottikerstrasse 14 CH-8006 Zürich +41 44 368 35 35

Universal Testing. Intelligentes & effizientes Testen mit Universal. Consor AG Ottikerstrasse 14 CH-8006 Zürich +41 44 368 35 35 Universal Testing Consor AG Ottikerstrasse 14 CH-8006 Zürich +41 44 368 35 35 Copyright 2001-2009 Consor AG Seite 1 von 5 Komplexe Applikationen, Geschäftsprozesse und Produktentwicklungen, die kontinuierlich

Mehr

Inhalt. 1. Sprachspezifische Fehlerrisiken C++ Java. Smalltalk. 2. Coverage - Modelle. Statement Coverage. Branch Coverage

Inhalt. 1. Sprachspezifische Fehlerrisiken C++ Java. Smalltalk. 2. Coverage - Modelle. Statement Coverage. Branch Coverage Inhalt 1. Sprachspezifische Fehlerrisiken C++ Java Smalltalk 2. Coverage - Modelle Statement Coverage Branch Coverage Inkrementelles Testen von Klassen Testen Polymorpher Bindungen Optimistischer Ausblick

Mehr

Etablierung serviceorientierter Architekturen mit Web Services

Etablierung serviceorientierter Architekturen mit Web Services Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Übersicht zu den Inhalten der Vorlesung) Somemrsemester 2013 1 Ziele und Abgrenzung 2 Allgemeine Lernziele Vermittlung von Basiskenntnissen

Mehr

Automatisiertes UI Testing. Mark Allibone, 18.04.2013, #2

Automatisiertes UI Testing. Mark Allibone, 18.04.2013, #2 Coded UI Testing Automatisiertes UI Testing Mark Allibone, 18.04.2013, #2 Eine klassische Applikations Architektur Grafische Oberfläche Business Logik Datenzugriff (Datenbank, Cloud, etc) Mark Allibone,

Mehr

Stuttgarter Test-Tage 2011 Der Fluch des grünen Balkens in sehr großen Projekten

Stuttgarter Test-Tage 2011 Der Fluch des grünen Balkens in sehr großen Projekten main {GRUPPE} Seite 1 Jürgen Nicolai Geschäftsführender Gesellschafter Liebknechtstrasse 33 70178 Stuttgart Tel : 0711 2270225 Fax : 0711 2270497 Mail : j.nicolai@main-gruppe.de Web: www.health4j.de Stuttgarter

Mehr

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE DOKUMENTATION MAAS - MONITORING AS A SERVICE DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE Dokumentation MaaS - Monitoring as a Service Inhalt 1. MaaS - Monitoring as Service... 3 1.1 Einleitung...

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

Thomas Freitag achelos GmbH SmartCard-Workshop. 1 2012 achelos GmbH

Thomas Freitag achelos GmbH SmartCard-Workshop. 1 2012 achelos GmbH Thomas Freitag achelos GmbH SmartCard-Workshop 2012 1 2012 achelos GmbH Übersicht 1. 2. 3. 4. 5. 6. 7. Einführung / Motivation Historie des Testens Schnittstellen im Testbereich Eclipse Plugins Automatisierung,

Mehr

Testen II. (Management, Tools) Daniela Rose. Software Engineering Projekt WS07/08 Fachgebiet Softwaretechnik und Systemgestaltung

Testen II. (Management, Tools) Daniela Rose. Software Engineering Projekt WS07/08 Fachgebiet Softwaretechnik und Systemgestaltung Testen II (Management, Tools) Daniela Rose Fachgebiet Softwaretechnik und Systemgestaltung 12.12.2007 Gliederung 1. Motivation 2. Der grundlegende Testprozess 3. Testen im Softwareentwicklungsprozess 4.

Mehr

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Konzeption und prototypische Implementierung eines Knowledge-Servers mit Adaptern zur Integration

Mehr

Unit Testing mit JUnit. Dr. Andreas Schroeder

Unit Testing mit JUnit. Dr. Andreas Schroeder Unit Testing mit JUnit Dr. Andreas Schroeder Überblick Was dieses Video behandelt Warum Testen? Was sind Unit Tests? Der Teufelskreis des Nicht-Testens JUnit Unit Test Vorteile Test-Inspiration Wann aufhören?

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen. Alexander Schunk Marcel Teuber Henry Trobisch

Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen. Alexander Schunk Marcel Teuber Henry Trobisch Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen Alexander Schunk Henry Trobisch Inhalt 1. Vergleich der Unit-Tests... 2 2. Vergleich der Codeabdeckungs-Tests... 2 3. Vergleich

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Systematische Testfallableitung und Tests durchführen

Systematische Testfallableitung und Tests durchführen Systematische Testfallableitung und Tests durchführen Testen Bereich Kontrolle Aktivität Interne Qualitätssicherung durchführen (Verifikation) Ziele Tests werden systematisch und zielgerichtet erstellt

Mehr

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1 30.01.2011 Seite 1 This flyer is exclusively for the use of client personnel. No part of it may be distributed, quoted or reproduced outside the client organisation without the prior written approval of

Mehr

SEQIS 10 things API Testing

SEQIS 10 things API Testing SEQIS 10 things API Testing SEQIS 10 things API Testing Herzlich Willkommen! Reinhard Salomon SEQIS Geschäftsleitung SEQIS 10 things Programm 2014 20.03.14 Business Analyse Einführung in den BABOK Guide

Mehr

Testmanagement im agilen Entwicklungsprozess

Testmanagement im agilen Entwicklungsprozess Testmanagement im agilen Entwicklungsprozess Unser Beratungsangebot für die effiziente Abwicklung von Projekten: n Anforderungen erkennen n Software-Qualität steigern n Teams zum Erfolg führen Unser Erfolgskonzept:

Mehr

ISTQB Certified Tester Foundation Level Exam Übungsprüfung

ISTQB Certified Tester Foundation Level Exam Übungsprüfung BEMERKUG: Bitte nur eine Antwort auf jede Frage 1. Die statische Analyse kann höchstwahrscheinlich ICHT finden: (A) Die Verwendung einer Variablen bevor diese definiert wurde. (B) Unerreichbaren ( toten

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

Testen. Werkzeuggestützte Softwareprüfungen. Olaf Göllner, mail@ogoellner.de

Testen. Werkzeuggestützte Softwareprüfungen. Olaf Göllner, mail@ogoellner.de Testen Werkzeuggestützte Softwareprüfungen Olaf Göllner, mail@ogoellner.de Gliederung Themengebiete: Anforderungen Testarten Werkzeugübersicht Automatisierung von Tests GUI Capture&Replay Vor-/Nachteile

Mehr

Einleitung. Was ist SOA? Die SOA Idee. Beispiel Monolithische Applikation. Services. CD Player. playtrack(cd, nr) setshuffle(onoff) ejectcd()

Einleitung. Was ist SOA? Die SOA Idee. Beispiel Monolithische Applikation. Services. CD Player. playtrack(cd, nr) setshuffle(onoff) ejectcd() Einleitung Was ist Service Oriented Architecture? Welche Konzepte verfolgt SOA? Was genau ist ein Service? Wie modelliere ich meine Servicelandschaft? Was ist ideales Servicedesign? Aufgaben für den Technologiemanager

Mehr

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design Design im Softwareentwicklungsprozess traditionell Geschäftsprozessmodellierung Requirements Engineering Analyse Design Implementierung Tests Design 1 test-getrieben: nur 1. Design top-down hier testgetrieben

Mehr

Assembly Technology. des Entwicklungsprozesses

Assembly Technology. des Entwicklungsprozesses FRAUNHOFER-institut für produktionstechnologie IPT projektgruppe entwurfstechnik mechatronik Requirements Engineering Assembly Technology Ovidemporion porum quiae nemporro cone venderferia coris dio officia

Mehr

Extremes Programmieren

Extremes Programmieren Extremes Programmieren Übersicht, Demonstration, Erfahrungen ACM/GI Regionalgruppe Hamburg, 16.3.2001 Frank Westphal unabhängiger Berater westphal@acm.org http://www.frankwestphal.de Tammo Freese OFFIS,

Mehr

-Kommentare ein-und ausschalten. -Kommentare ein-und ausschalten. Seite 1 DI Christian Eggbauer mobilkom austria

-Kommentare ein-und ausschalten. -Kommentare ein-und ausschalten. Seite 1 DI Christian Eggbauer mobilkom austria Diese Diese Kommentarfelder Kommentarfelder können können Sie Sie über über das das Menü Menü Ansicht Ansicht -Kommentare ein-und ausschalten. -Kommentare ein-und ausschalten. Dies Dies ist ist die die

Mehr

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung Use-Cases Bruno Blumenthal und Roger Meyer 17. Juli 2003 Zusammenfassung Dieses Dokument beschreibt Netzwerk-Szenarios für den Einsatz von NetWACS. Es soll als Grundlage bei der Definition des NetWACS

Mehr

GEDS Dienstleistungen. Software Engineering

GEDS Dienstleistungen. Software Engineering GEDS Dienstleistungen Software Engineering GEDS Software Engineering Übersicht Leistungen Methoden Vorgehen Projektablauf Technologien Software Engineering Leistungen Auftragsprogrammierung Wir übernehmen

Mehr

Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit.

Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit. Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit. BEKA: Frankfurt, 25. Oktober 2012 T-Systems Angebot Umsetzung des globalen Telematikprojekts für den ÖPNV im Großherzogtum Luxemburg.

Mehr

SERVICE SUCHE ZUR UNTERSTÜTZUNG

SERVICE SUCHE ZUR UNTERSTÜTZUNG SERVICE SUCHE ZUR UNTERSTÜTZUNG VON ANFORDERUNGSERMITTLUNG IM ERP BEREICH MARKUS NÖBAUER NORBERT SEYFF ERP SYSTEME Begriffsbestimmung: Enterprise Resource Planning / Business Management Solution Integrierte

Mehr

Software Engineering in

Software Engineering in Software Engineering in der Werkzeuge für optimierte LabVIEW-Entwicklung Folie 1 Best Practices Requirements Engineering Softwaretest Versionsmanagement Build- Automatisierung Folie 2 Arbeiten Sie im Team?

Mehr

BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE

BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE CO-MAT-TECH 2004 14-15 October 2004 BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE Roman NAGY External doctorand

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

Mehr

PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN

PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN Mathias Slawik, WI (M), 3. FS Aktuelle Themen der Wirtschaftsinformatik, HTW Berlin, WS 10/11 Gliederung 2 Methode

Mehr

Grüezi Mein Name ist Susanne Bandi und ich begrüsse Sie herzlich zum Kurzreferat: So richten Sie ihr Configuration Management auf die Zukunft aus!

Grüezi Mein Name ist Susanne Bandi und ich begrüsse Sie herzlich zum Kurzreferat: So richten Sie ihr Configuration Management auf die Zukunft aus! Grüezi Mein Name ist Susanne Bandi und ich begrüsse Sie herzlich zum Kurzreferat: So richten Sie ihr Configuration Management auf die Zukunft aus! SIE sind hier, weil sie Potential sehen für ihr Configuration

Mehr