Markus Helfen, Michael Lauer, Hans Martin Trauthwein. SAP-Lösungen testen. Methodik, Funktionstests mit ecatt, Performancetests

Transkript

1 Markus Helfen, Michael Lauer, Hans Martin Trauthwein SAP-Lösungen testen Methodik, Funktionstests mit ecatt, Performancetests

2 Auf einen Blick Geleitwort Vorwort Einleitung TEIL I: METHODIK 2 Theorie des Software-Testens Testmethodik TEIL II: FUNKTIONALES TESTEN 4 Testmanagement mit dem SAP Solution Manager Ökonomische Aspekte der Testautomation Testautomation mit ecatt SAP Test Data Migration Server Coverage Analyzer TEIL III: PERFORMANCETESTS 9 Projektskizze eines Performancetests SAP LoadRunner by Mercury Performancetest mit SAP-GUI-Skripting Monitoring im Performancetest A Die Autoren Index

3 Inhalt Geleitwort Vorwort Einleitung TEIL I: METHODIK 2 Theorie des Software-Testens Testarten Teststufen Blackbox-Test und Whitebox-Test Testfallentwurf für den Blackbox-Test Äquivalenzklassenbildung Grenzwertanalyse Error Guessing Testdaten Testmethodik Roadmaps im SAP Solution Manager Projektphasen Roadmaps Projektvorbereitung Teststrategie und Testkonzept Testwerkzeuge Zuständigkeiten und Verantwortlichkeiten Business Blueprint Abbildung der Geschäftsprozess-Strukturen Teststandards Realisierung Produktionsvorbereitung Go-live & Support

4 Inhalt TEIL II: FUNKTIONALES TESTEN 4 Testmanagement mit dem SAP Solution Manager SAP Solution Manager Implementierung Betrieb Optimierung Integrationskraft des SAP Solution Managers SAP Solution Manager vs. SAP Test Organizer Testfallverwaltung Anbindung der Systemlandschaft Projekt anlegen Teststandards Aufbau der Projektstruktur Einbinden von Testfällen KW-Funktionalitäten im SAP Solution Manager Generierung von Testplänen und -paketen Testdurchführung Statusanalyse Integrationsszenario Kundenbericht der BSH Bosch und Siemens Hausgeräte GmbH Kundenbericht Reno Fashion & Shoes GmbH Ökonomische Aspekte der Testautomation Kostenmodell für Softwaretests Kosten für den Testfallentwurf Kosten für Testwerkzeuge Kosten für die Implementierung der Testautomation Kosten für die Wartung von Testfällen Kosten für die Durchführung eines Testzyklus Individuelles Testkosten-Modell Kostenmodell für Softwarefehler Gesamtbetrachtung Kundenbericht der INVISTA Resins & Fiber GmbH Testautomation mit ecatt Testbestandteile und Architektur der Testlandschaft Technische Voraussetzungen zum Einsatz von ecatt

5 Inhalt 6.3 Aufbau der ecatt-skripte Testen von Transaktionen ohne Controls Testen von Transaktionen mit Controls Aufzeichnen von SAPGUI-Befehlen Auslesen und Prüfen von GUI-Elementen Testen von Web-Dynpro-Anwendungen Testen von Webservices Integration mit externen Tools Prüfen der Ergebnisse Testen von Parametern Direktes Testen von Werten Nachrichtenbehandlung Parametrisierung der Nachrichtenbehandlung Prüfen von Tabellen Verwaltung von Testdaten Modularisierung von Testskripten Ausführen von ecatt-skripten Startoptionen Versionierung Debuggen von ecatt-skripten Überblick über die ecatt-versionen Weiterführende Schritte Zusammenfassung: Vorteile durch die Integration von ecatt in das SAP-System Kundenbericht Zürcher Kantonalbank SAP Test Data Migration Server Funktionalität und Systemlandschaft des SAP TDMS Kundenbericht Behr GmbH & Co. KG Coverage Analyzer TEIL III: PERFORMANCETESTS 9 Projektskizze eines Performancetests Lasttest Stresstest Massentest Rollen im Performancetestprojekt Phasenmodell eines Performancetests

6 Inhalt 9.4 Testvorbereitung Prozessanalyse Datenanalyse Auswahl des Lasttestwerkzeugs Das Lastprofil Durchführung Lasttest Daten- und Systembereitstellung Single-User-Test Multi-User Tests Ergebnisanalyse Optimierung Durchführung Stresstest Abschlussbericht Executive Summary Aktionsplan Beschreibung des Testaufbaus Beschreibung der Testziele Dokumentation der Testdurchführung SAP LoadRunner by Mercury Performancetest von Portalanwendungen Kundenbericht von Sanofi-Aventis Performancetest mit SAP-GUI-Skripting SAP-GUI-Skripting Lasttestarchitektur Skriptentwicklung Lastgeneratoren PC-Farm Terminal-Server Execution-Log Verfügbarkeit der Beratungslösung Kundenbericht Universitätsklinikum Würzburg Monitoring im Performancetest Vorgehensweise Transaktionen zum technischen Monitoring AL08: Liste der angemeldeten Anwender SM12: Sperrübersicht

7 Inhalt SM66: Globale Workprozess-Übersicht STAD: Transaktionsanalyse ST02: Übersicht der SAP-Puffer ST04N: Datenbankübersicht ST05: SQL-Trace-Analyse OS07/ST06: Systemmonitor SM04: Benutzerliste SM21: Systemlog ST22: ABAP-Laufzeitfehler Zusammenfassung Anhang A Die Autoren Index

8 Geleitwort Die SAP AG ist seit langer Zeit ein strategischer Partner ihrer Kunden. Dies basiert auf ihrer Rolle als Anbieter von Softwareanwendungen, die Prozess- und Geschäftsmodellinnovationen, Flexibilität und schnelle Anpassungsfähigkeit unterstützen. Wir stellen den Anspruch an uns selbst, unsere Kunden ganzheitlich, im Sinne eines»trusted Advisor«über den gesamten Software-Lebenszyklus hinweg zu unterstützen. Insbesondere für meinen Vorstandsbereich, den Bereich Global Service und Support, bedeutet dies, dass wir neben den Anwendungen auch die entsprechenden Methodiken, Services und Werkzeuge zur Verfügung stellen müssen, um den Erwartungen unserer Kunden und Partner mehr als nur gerecht zu werden sei es unmittelbar durch SAP oder durch Angebotsmöglichkeiten unseres stark expandierenden Ecosystems mit Kunden und Partnern. Um auf Anforderungen des Marktes entsprechend reagieren oder technologische Neuerungen nutzen zu können, benötigen unsere Kunden einen effizienten und optimierten Upgrade- und Implementierungsprozess. Eine ganz wesentliche Rolle spielt hierbei das Testen. SAP bietet hier ein zielgerichtetes Portfolio an Services, Prozessen und Tools. Dies beinhaltet unter anderem die Konzeption von Testaufgaben, die Verkürzung von Projektlaufzeit und Senkung von Projektkosten durch gesteigerte methodische Effizienz sowie Ergebnistransparenz durch den Einsatz frei verfügbarer und integriert arbeitender Testwerkzeuge. Wir ermöglichen somit eine dauerhafte Reduzierung manueller Testaufwände durch flexible und vor allem robuste Testwerkzeuge, wodurch gleichzeitig ein wesentlicher Beitrag zur Applikationsqualität geleistet wird. Für die Realisierung all dieser Aufgaben bedarf es zunächst einer Prozessorientierung, das heißt, hierbei steht die Methodik die Vorgehensweise bei der Durchführung von Testprojekten im Vordergrund. Sie wird dann durch die entsprechenden Services und Werkzeuge für die Automation funktionaler Tests und/oder für Performancetests ergänzt. Was genau SAP hierbei seinen Kunden anbietet, werden Sie auf den folgenden Seiten im Detail kennen lernen, praktisch dargelegt anhand konkreter Kundenerfahrungsberichte. 13

9 Geleitwort Worauf bei der Umsetzung dieser Vorgehensweise besonders geachtet wurde, ist die Skalierbarkeit unseres Angebotes, um allen Ansprüchen und Bedürfnissen unserer Kunden gerecht zu werden. Nur durch die Produktisierung unserer Angebote und Beratungsdienstleistungen in Standardservices haben wir die Möglichkeit, Kunden in allen Unternehmensgrößen, von kleinen Unternehmen, über den Mittelstand bis hin zu Großunternehmen, helfen zu können. Darüber hinaus lassen sich unsere Angebote über alle Phasen des Software-Lebenszyklus und für alle Softwareanwendungen nutzen. Diese Produktisierung garantiert zusätzlich die Verfügbarkeit unserer Services, in höchster Qualität durch das konsequente Verwerten von Erfahrungen sowie eine klare Kostenkontrolle, da sich die Testkosten schon vorab definitiv kalkulieren und prognostizieren lassen. Zudem ermöglicht die Produktisierung einen effizienten Wissenstransfer an unsere Kunden. Geliefert werden diese Services durch das Beratungsteam des SAP Test Management Consulting. Hierbei agieren unsere Experten vornehmlich unter Zuhilfenahme der SAP-Testwerkzeuge und Basistechnologien wie z. B. SAP Solution Manager oder ecatt. Aber auch die neuen Tools von SAP, wie etwa der Test Data Migration Server (TDMS), und gängige Produkte von Drittherstellern wie z. B. Mercury und Compuware werden unterstützt. SAP ist somit bestens aufgestellt, um dem eigenen Anspruch, als»trusted Advisor«für unsere Kunden zu agieren, gerecht zu werden. In diesem Sinne danke ich den Autoren herzlich für ihr Engagement, die gesammelten Erfahrungen in diesem Werk unseren Kunden und Partnern zur Verfügung zu stellen, und wünsche Ihnen, meine sehr verehrten Leser, dass Sie bei der Lektüre dieses Buchs viele wertvolle Informationen bezüglich unserer Werkzeuge und zahlreiche Hinweise aus der Praxis für Ihre eigenen Aktivitäten finden und diese dann gewinnbringend verwerten können. Mit freundlichem Gruß Gerhard Oswald Mitglied des Vorstandes der SAP AG 14

10 Vorwort Welcome to the Jungle! Welcome to the Jungle? Was hat dieser Ohrwurm von Guns N Roses mit einem seriösen Fachbuch von SAP PRESS zu tun? Nun, auf der Rückfahrt von einem Kundentermin unterhielten wir uns über die Optimierung unseres Präsentationsmaterials. Dabei diskutierten wir lange über die Herausforderungen unserer Kunden, denen sie sich im Aufgabenbereich des Testens stellen müssen. Wir wollten sie auf einer Präsentationsfolie visualisieren, um unsere Lösungsvorschläge anforderungsgerechter darstellen zu können. Das spontane Brainstorming erbrachte eine Vielzahl von Herausforderungen, die auch recht schnell kategorisiert werden konnten: Kundenprozesse wurden seit geraumer Zeit systemübergreifend abgebildet, SAP hatte zu diesem Zeitpunkt bereits das Stadium der New-Dimension-Produkte erfolgreich hinter sich gelassen. Die SAP-Kunden betrieben SAP-Lösungslandschaften mit unterschiedlich hohem Heterogenitätsgrad. Auch die Technologie stellt Anforderungen an die Durchführung von Tests, aber auch an die marktgängigen Testtools, die eingesetzt werden sollen. Können insbesondere die Automatisierungstools Oberflächen, Lösungen und Technologien von SAP dauerhaft, robust und kostengünstig abdecken? Testprojekte sollten einem Mindestumfang methodischer Grundsätze, Regeln und Rahmenbedingungen folgen, diese gilt es bei den unterschiedlichen Testarten und -stufen zu berücksichtigen. Auf dem Markt können Sie eine Vielzahl von Werkzeugen bei unterschiedlichen Anbietern kaufen. Zum geschilderten Zeitpunkt waren Unternehmen im Begriff, Kaufentscheidungen zu treffen, deren finanzielle Konsequenzen weit über die Lizenzierungskosten des Third-Party-Tools hinausgingen. Herausforderungen Diese vier unterschiedlichen Dimensionen (Lösungen, Technologien, Methodik und Tools) sollten nun in einer Folie abgebildet werden. Nach einigen Kilometern war zwar das Darstellungsproblem gelöst, aber der Folientitel wurde erst gefunden, als der oben erwähnte Musiktitel den gedanklichen Durchbruch ermöglichte. Die animierte Folie trägt den Titel»Das Thema Testen erscheint wie ein 15

11 Vorwort Dschungel «und wird übrigens auch heute noch natürlich in aktualisierter Form verwendet, vielleicht ist sie Ihnen ja auch schon bereits begegnet. Das Thema Testen erscheint wie ein Dschungel Anwendermodifikationen Issue Management Rel. 4.6C IS... SiteScope Java End - To - End QA Run Regressionstests Systemtests QA Load TestPartner CRM SAP Test Workbench Rel. 4.0 ecatt SAP NetWeaver Test Management Web AS 6.nn Mobile Sales APO Topaz Test Organizer SAP xapps QuickTest Pro CATT HTML SAPGUI 6.nn EBP Rel. 4.7 Last -/Stresstests TestDirector WinGui Unicode Integrationstests SCM LoadRunner WinRunner Vantage Track Record QA Director SAP Solution Manager WebDynpro Funktionstests BIW 2.x R/3 Enterprise BIW 3.x SAP AG 2004, Test Management Consulting 1 Abbildung Die Dschungel-Folie Erkenntnisse aus ca. 380 Kundenengagements Beim Lesen dieses Buchs werden Sie nicht nur erkennen, dass wir uns seit der oben erwähnten Reise weiterhin Gedanken um unsere Kunden gemacht haben, sondern dass wir aufgrund der vielen gewonnen Erfahrungen in unserer konkreten Beratungspraxis in der Lage waren, ein solches Projekt anzugehen. Viele der verarbeiteten Erfahrungen sind im Rahmen von Kundenprojekten gesammelt worden, wobei wir die komfortable Situation nutzen konnten, die Erkenntnisse aus ca. 380 Kundenengagements sowie zusätzlich aus zahlreichen Veranstaltungen und Vorträgen zu unterschiedlichen Themen des Testens und der Qualitätssicherung in und mit der SAP- Kundenbasis zu verwerten. Viele Beobachtungen und Argumentationen sind gerade in der Diskussion und in der Zusammenarbeit mit unseren Kunden entstanden oder bestätigt worden. Darüber hinaus haben wir erkannt, dass in diesem Umfeld immer noch ein signifikanter Bedarf an Information und solider Beratung besteht. Immer wieder haben wir feststellen müssen, dass Kunden aufgrund der mangelnden Erfahrung eines Beratungspartners falsch 16

12 Vorwort beraten wurden. Insbesondere im ecatt-umfeld erleben wir diese Situation mehrmals im Jahr, wenn beispielsweise die falschen Treiber zur Anwendung im Rahmen einer Automatisierungsaktivität empfohlen worden sind. Die Konsequenzen trägt in letzter Konsequenz der Kunde, wenn das Thema und die Motivation daran zu arbeiten verbrannt wurden. Die genauen Nutzungszahlen der SAP-Testwerkzeuge in der SAP- Kundenbasis sind uns heute nicht bekannt, die Dunkelziffer in der Nutzung der SAP-Testtools ist aufgrund von Indizien höher als vermutet. Die nachvollziehbare Nutzung steigt nach unserer Beobachtung mit dem Verbreitungsgrad des SAP Solution Managers stetig an. Gerade Unternehmen, die ein geeignetes Einstiegsthema auf der Implementierungsseite des SAP Solution Managers suchen, werden hier sehr schnell fündig und realisieren unmittelbar Nutzenpotenziale, indem sie Spreadsheet-basierte Lösungen endlich ablösen können. Mit dem SAP Solution Manager haben wir jetzt die Möglichkeit, Projekte und Tests durchgängig nachvollziehbar innerhalb eines zentralen Systems zu dokumentieren, was im Vergleich zu den frühen Versionen der klassischen Test Workbench aus den SAP-R/3-System- Releases einen echten Fortschritt bedeutet obwohl deren Grundfunktionalität immer noch erkennbar und stabil ist. Selbst die Anforderungen vieler nachweispflichtiger Kunden können mittlerweile mühelos erfüllt werden. Aber auch zum SAP Solution Manager selbst besteht noch reichlich Informationsbedarf bei unseren Kunden, weshalb wir bei der Konzeption dieses Buchs sehr viel Wert auf die Darstellung der Integration der SAP-Testwerkzeuge in den SAP Solution Manager gelegt haben. Zentrale Testdokumentation Der Einsatz SAP-eigener Testwerkzeuge ist eine logische Konsequenz aus dem Einsatz des SAP NetWeavers als strategische Geschäftsprozess-Plattform für Unternehmen und dem damit verbundenen Gewinn an Homogenität der Lösungslandschaft. Es wäre sehr nachlässig oder sogar fahrlässig, diesen Vorteil durch eine Nutzung von anderen Werkzeugen ohne Kenntnis und Prüfung der Alternativen von SAP-Testwerkzeugen leichtfertig zu verspielen. Vertrauen Sie außerdem auf die in einer Vielzahl von Kundenkontakten, -engagements und -projekten erworbene Reputation des SAP Test Management Consultings als Trusted Advisor im Testumfeld; 17

13 Vorwort die fachlichen Grundlagen, unsere Best Practices, Vorgehensweisen und Argumentationen haben wir nun den Lesern im Rahmen dieses Buchs zugänglich gemacht. Bei seiner Konzeption schöpften wir aus einem Erfahrungsschatz von mehr als 30 Berufsjahren und gelebten Best Practices mit den Tätigkeitsschwerpunkten: Qualitätsmanagement inklusive der Erstellung, Zertifizierung, dem Betreiben und Auditing von Qualitätsmanagementsystemen verschiedener Unternehmen Qualitätssicherung der Entwicklung, Implementierung und des Betriebs von Softwareprodukten Konzeption, Planung, Umsetzung, Durchführung von zahlreichen Testprojekten unterschiedlicher Zielsetzungen und Größen Entscheider und Führungskräfte von IT-Abteilungen, Programmoder Projektmanager von SAP-Kunden können in diesem Buch praxisbewährte Vorgehensweisen für die Planung und Umsetzung eigener Testprojekte finden. Auf Initiative des Verlags Galileo Press, der Anfang 2005 gezielt einen Autor für ein Buch im SAP-Testumfeld suchte, haben wir uns an dieses Buchprojekt gewagt, um einen Pfad bzw. ein Licht ins Dunkel des oben beschriebenen Dschungels zu bringen. Da uns ein Buch der geeignete Kanal erschien, um unsere Erfahrungen an die Kunden weiterzugeben, hat sich dann das Autorenteam in bewährter Besetzung an dieses Vorhaben gewagt. Danksagung Die Realisierung eines Werks von diesem Umfang ist nicht nur alleine den Autoren zu verdanken. An dieser Stelle möchten wir allen Beteiligten Dank sagen, die uns bei der Erstellung dieses Buches ermutigt und unterstützt haben. Ohne Zweifel müssen wir uns zuerst bei unseren Partnerinnen und Kindern bedanken, da sie während der Erstellung nicht nur gelegentlich auf uns verzichten mussten, sondern auch in Situationen der Anwesenheit mit unserer gedanklichen Abwesenheit wohlwollend umgegangen sind. 18

14 Vorwort Ein derartiges Projekt muss trotz allen Engagements auch unter ökonomischen Rahmenbedingungen realisiert werden können. Diese hat der Vorstand der SAP AG in Person von Gerhard Oswald recht spontan und angemessen geschaffen, wofür wir uns recht herzlich bedanken möchten. Wir möchten unseren Kunden danken, und zwar ganz besonders herzlich denen, die ihre Erfahrungen mit uns gemeinsam in diesem Buch mit den Lesern teilen. Aber wir möchten uns auch bei unseren Kunden bedanken, bei denen wir in den letzten Jahren unsere Erfahrungen in diesem Umfeld sammeln durften, deren Feedback unser Wirken bestätigte und ohne die folglich eine Realisierung dieses Buchs nicht möglich gewesen wäre. Eine wesentliche Rolle im Rahmen der Erstellung dieses Buchs hat unser Redakteur Tim Dahmen übernommen, der unser Wissen und die Erfahrungen in vielen Gesprächen verwertet hat und zusammen mit seinen Rechercheergebnissen in beachtliche Resultate überführt hat. Ein herzliches Dankeschön an Tim und viel Erfolg in der Beraterrolle! Lektor und Schnittstelle zum Verlag war Florian Zimniak, der versuchte, aus unseren Manuskripten immer den maximalen Mehrwert für die Leser herauszuholen. Die Zusammenarbeit mit Ihnen war angenehm und erfolgreich, vielen Dank dafür. In unseren Arbeitsumfeldern bedanken wir uns zunächst bei unseren Managern für ihre Unterstützung, namentlich bei Dorothée, Manfred, Peter, Thomas und Ron. Stellvertretend für die Unterstützung in Form von Anregungen, Beiträgen oder Korrekturen durch die Kollegen des SAP Test Management Consultings möchten wir uns insbesondere bei Andreas Wentz bedanken. Auch innerhalb der SAP AG müssen wir einem großen Personenkreis Dank für Ihre Unterstützung und Ratschläge aussprechen, namentlich bei Jonathan Maidstone (Product Manager SAP NetWeaver Testtools) und Marc Oliver Schäfer (Product Manager SAP Solution Manager), im Umfeld Test Data Migration Server bei Anja Marschollek, Peter Keller, Ralf Debus und Dennis Landscheidt, bei Dr. Jörg Bischof stellvertretend für das ecatt-entwicklungsteam und bei 19

15 Vorwort Dr. Christian Hansen für seine Unterstützung bei der Erarbeitung des Coverage Analyzer-Kapitels. Es war toll, ein solches Projekt in einem Unternehmen wie SAP anzugehen und durchzuführen, dessen Kultur solche Projekte immer noch fördert und möglich macht: Wir sind nach wie vor stolz, in solch einem Unternehmen zu arbeiten! St. Ingbert, im Juli 2006 Markus Helfen Hans Martin Trauthwein Michael Lauer 20

16 ecatt bietet umfassende Möglichkeiten, SAP-Lösungen automatisiert zu testen. Durch die Automation des Benutzerverhaltens erlaubt ecatt sowohl komponentenweise Funktionstests als auch Integrationstests entlang von Prozessketten. Aufgrund der Integration in das SAP-System wird ecatt zum wichtigsten Werkzeug für die Automation von Regressionstests. 6 Testautomation mit ecatt Dieses Kapitel richtet sich schwerpunktmäßig an den operativen IT- Mitarbeiter, der sich detaillierte technische Informationen erschließen möchte, um in die ecatt-nutzung einzusteigen. Mit ecatt befindet sich ein ebenso mächtiges wie komplexes Testwerkzeug im Lieferumfang der Basis von SAP-Anwendungen. ecatt ist mit dem Basisrelease des Web AS 6.20 fest in den SAP Web Application Server integriert und bietet durch die enge Verzahnung mit dem SAP-System flexible Möglichkeiten, auf ein zu testendes System zuzugreifen. Das folgende Kapitel beschreibt ecatt in dem aktuellen Basisrelease des Web AS 7.0 und verweist wenn erforderlich auf Unterschiede zu den älteren Releaseständen 6.40 und ecatt eignet sich sowohl für komponentenweise Funktionstests als auch für prozessorientierte Integrationstests. Der einfachere Fall, nämlich Komponententests, hat vor allem als Entwicklertest zur schnellen Fehlerlokalisierung während der Implementierung eine große Bedeutung. Den interessanteren Fall stellen jedoch Integrationstests dar. Hierbei wird ein Test über Anwendungskomponenten und Systemgrenzen hinweg entlang eines Geschäftsprozesses automatisiert durchgeführt. Typisches Einsatzszenario dieser Tests ist der automatisierte Regressionstest, z. B. nach Systemerweiterungen oder dem Einspielen von Support Packages. Bestandteil der SAP-Basis Einsatzgebiet 181

17 6 Testautomation mit ecatt 6.1 Testbestandteile und Architektur der Testlandschaft Testkonfiguration und Modularität Testtreiber Das grundlegende Objekt für die Arbeit mit ecatt ist die Testkonfiguration. Eine Testkonfiguration besteht aus den zu verwendenden Testdaten, einer Testlogik, die den Testablauf steuert, sowie den Systemdaten, die die zu testenden Systeme spezifizieren. Ein wichtiger Punkt hierbei ist die Modularität, die durch eine Trennung von Testlogik, Testdaten und Systemdaten erreicht wird. So können sowohl Test- als auch Systemdaten in mehr als einer Testkonfiguration verwendet werden. Die Testlogik folgt ebenfalls einem modularen Aufbau, sodass sich einzelne Bausteine der Testlogik gegenseitig aufrufen und in mehreren Testkonfigurationen eingesetzt werden können. Um mit dem zu testenden System flexibel interagieren zu können, greift ecatt auf Testtreiber zurück. Diese Adapter verzahnen auf unterschiedlichen Ebenen mit dem zu testenden System und erlauben so das direkte Prüfen der verschiedenen Anwendungskomponenten. Durch den Einsatz des jeweils passenden Treibers können je nach Einsatzzweck und Release des Web AS sowohl funktionsartige Objekte wie BAPIs, Funktionsbausteine und Webservices als auch Transaktionen und Web-Dynpro-Anwendungen getestet werden. Mittels eines Testtreibers kann das zu testende SAP-System auf verschiedenen Ebenen angesteuert werden. Zur Auswahl stehen die folgenden Treiber. TCD-Treiber Der TCD-Treiber ist geeignet für konventionelle Transaktionen (ohne Controls). Ein Vorteil liegt darin, dass der TCD-Modus auf der Batch-Input-Technologie basiert. Daher ist es möglich, die aufgezeichneten Transaktionen dunkel (ohne GUI) abzuspielen, was sehr effiziente Tests erlaubt. Zudem ermöglicht es der TCD-Treiber, nachträglich kleinere Anpassungen an bereits fertig gestellten Skripten vorzunehmen. Dieser Treiber ist somit besonders wartungsfreundlich. Näheres zum TCD-Treiber finden Sie in Abschnitt

18 Testbestandteile und Architektur der Testlandschaft 6.1 Testkonfiguration Systemdaten Testlogik Testdaten SAP System Treiber Transaktionen ohne Controls TCD Transaktionen mit Controls SAPGUI Web-Dynpro Anwendungen WEBDYNPRO BAPIs FUN Funktionsbausteine FUN Web Services WEBSERVICE non-sap-system externe Komponenten REFEXT Abbildung 6.1 Aufbau einer Testkonfiguration SAPGUI-Treiber Der SAPGUI-Treiber erlaubt das Testen von Transaktionen, die Controls verwenden. Die Handhabung unterscheidet sich von der des TCD-Treibers, da die Aufzeichnung sich direkt auf die Benutzerinteraktion mit den Controls bezieht. Der Treiber arbeitet ausschließlich mit und über das SAP GUI für Windows. Näheres zum SAPGUI-Treiber finden Sie in Abschnitt 6.5. Verwaltungstransaktionen Funktionsbausteine und BAPIs können aus ecatt heraus direkt und ohne den Umweg über eine Verwaltungstransaktion, wie z. B. SE37, aufgerufen werden. Dadurch kann die Transaktionssequenz im Testprozess gegenüber einer manuellen Testdurchführung unverändert bleiben. Web-Dynpro-Treiber Web-Dynpro-Anwendungen auf dem ABAP-Stack werden mit dem SAP-Basisrelease Web AS 6.40 durch einen eigenen Treiber 183

19 6 Testautomation mit ecatt unterstützt. Mit dem Basisrelease 7.0 des Web AS werden diese Anwendungen zusätzlich auf dem Java-Stack unterstützt. Näheres hierzu erfahren Sie in Abschnitt 6.6. Webservice-Treiber Webservices können ab Web AS 7.0 ähnlich wie Funktionsbausteine getestet werden. Lediglich der Verbindungsaufbau erfordert eine gesonderte Behandlung. Eine interessante Möglichkeit ist das Testen von Anwendungen, die ihre Dienste sowohl in Form einer Web-Dynpro-Anwendung als auch als Webservice zur Verfügung stellen. Näheres hierzu erfahren Sie in Abschnitt 6.7. Zentrales Testadministrationssystem ecatt wurde konzipiert, um über ein zentrales Testsystem betrieben zu werden. SAP empfiehlt, dafür den SAP Solution Manager sowohl für manuelle als auch für automatische Tests einzusetzen. Dies bedeutet, dass ecatt selbst auf dem zentralen Testadministrationssystem verwaltet und gestartet wird und mittels RFC-Verbindung auf die zu testende Applikation zugreift. Die zu testende Applikation kann sich auf jedem Einzelsystem der Systemlandschaft befinden. Sie kann aus beliebigen Komponenten bestehen, die jeweils über einen geeigneten Treiber angesprochen werden. Auch Integrationstests, die mehrere Komponenten auf verschiedenen Systemen integriert testen, werden durch ecatt unterstützt. Die Voraussetzungen zum Betrieb von ecatt als zentrales Testadministrationssystem werden in Abschnitt 6.2 beschrieben. zentrales Testsystem SAP Web AS 6.20 oder h ö her SAP Solution Manager 3.1 oder h ö her Test Workbench ecatt Test Organizer mysap BI SAP R/3 4.6C oder h ö her mysap CRM Non - SAP Abbildung 6.2 Zentrales Testsystem in der SAP-Anwendungslandschaft 184

20 Testbestandteile und Architektur der Testlandschaft 6.1 Alle erstellten Testobjekte, also Testfallbeschreibungen, Testskripte sowie Test- und Systemdatencontainer werden dabei auf dem zentralen Testsystem abgelegt. Auch die Testdokumentation, also der Nachweis für durchgeführte Tests, wird auf dem zentralen Testsystem verwaltet. Um ecatt-skripte auf unterschiedlichen Systemen ausführen zu können, beispielsweise bei einer Änderung in der Systemlandschaft, ist es erforderlich, die systemspezifischen Aspekte des Skripts zu kapseln. Durch diese Kapselung wird erreicht, dass die Informationen, welche Systeme getestet werden sollen, sehr einfach austauschbar sind. ecatt stellt einen einfachen und effektiven Mechanismus für diese Kapselung zur Verfügung. Dazu wird in einem Systemdatencontainer eine Reihe logischer Ziele innerhalb der Testlandschaft definiert. Ein logisches Ziel beschreibt die Rolle einer Anwendungsinstanz in der Lösungslandschaft. Jedem logischen Ziel wird im Systemdatencontainer genau eine RFC-Verbindung zugeordnet, die auf das zu testende physikalische System verweist. In ecatt-skripten finden aber ausschließlich die logischen Zielangaben Verwendung. Systemdatencontainer und logische Ziele Kapselung Skript 1 Aktion 1 auf CRM Aktion 2 auf APO Aktion 3 auf APO CRM = RFC27 APO = RFC02 RFC02 RFC27 Skript 2 Aktion 4 auf APO APO- System Systemdatencontainer CRM- System Abbildung 6.3 Funktion des Systemdatencontainers Somit ist beim Wechsel auf ein anderes Zielsystem innerhalb der Testlandschaft lediglich der Systemdatencontainer innerhalb der Testkonfiguration auszutauschen. Alternativ kann für die Ausführung der Tests ein anderer Systemdatencontainer angegeben werden. 185

21 6 Testautomation mit ecatt 6.2 Technische Voraussetzungen zum Einsatz von ecatt Neben Anforderungen an die Testorganisation, die in den vorangegangenen Kapiteln ausführlich beschrieben wurden, existieren einige technische Voraussetzungen für den Einsatz von ecatt. Einrichten der Trusted-RFC- Verbindungen Typischerweise besteht eine Testlandschaft aus mehreren Systemen und der Geschäftsprozess wird durch eine Kette von Transaktionen abgebildet. Diese gehören zu verschiedenen Anwendungen, die ihrerseits verteilt auf mehreren Systemen laufen. Ein zentrales Testverwaltungssystem steuert mittels Testskript den Test der Komponenten auf allen Systemen. Die Kommunikation zwischen Testsystem und zentralem Testverwaltungssystem erfolgt hierbei über die Remote-Function-Call-Schnittstelle (RFC). Eine Verbindung mittels RFC erfordert auch bei einem automatisierten Testlauf immer wieder eine Interaktion mit dem Benutzer, da Mandant, Benutzername und Kennwort für jedes System, das über RFC gerufen wird, neu eingegeben werden müssen. Ein festes Hinterlegen der Anmeldedaten in der RFC-Verbindung würde dieses Problem zwar lösen, verbietet sich in der Praxis aber aus Sicherheitsgründen. Die von SAP empfohlene Vorgehensweise besteht in der Einrichtung einer Trusted-RFC-Verbindung. Hier ist weder die manuelle Anmeldung an den Zielsystemen erforderlich, noch müssen die Anmeldedaten an irgendeiner Stelle fest hinterlegt werden. Eine genaue Anleitung zum Einrichten einer Trusted-RFC-Verbindung befindet sich in SAP-Hinweis Support Package Level Zunächst einmal müssen alle zu testenden Systeme bestimmte Mindestanforderungen an die installierten Support Package Level der Basis erfüllen, sofern Sie über ein Basisrelease älter als 6.20 verfügen. Basisrelease Web AS 6.20 oder höher Support Package Level der Basis keine Anforderungen Web AS 6.10 Mindestens 17 Tabelle 6.1 Mindestanforderungen an den Support Package Level nach installiertem Release 186