Evaluierung der Testautomatisierung mit SAP Solution Manager 7.1

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Ausgangssituation der Arbeit
1.2 Zielsetzung der Arbeit
1.3 Vorgehensweise der Arbeit

2 Einführung in Software-Testen
2.1 Notwendigkeit von Tests
2.2 Teststufen in der SAP-Projektmethodik
2.3 Testaktivitäten
2.4 Testautomatisierung
2.4.1 Das kann die Testautomatisierung nicht leisten
2.4.2 Vorteile der Testautomatisierung
2.4.3 Testwerkzeuge

3 SAP Solution Manager
3.1 Allgemeines Konzept
3.1.1 Änderungen in Projekten implementieren
3.1.2 Lösungen effizient betreiben
3.1.3 Prozesse im SAP Solution Manager
3.2 Der Prozess „Testmanagement“
3.3 Optionen für Testwerkzeuge

4 Vorbereitungen der Analyse
4.1 Ziele der Untersuchung
4.2 Betrachtung der zu testenden Technologien
4.2.1 Geschäftsprozess der Angebotserstellung
4.2.2 Darstellung der Systeme und deren Technologien
4.3 Grundsätzliches Konzept für die Testfallerstellung

5 Analyse des Test Automation Frameworks
5.1 Voraussetzungen für den Einsatz
5.1.1 Grundlagen des Test Automation Frameworks
5.1.2 Technische Voraussetzungen
5.2 Integration eines externen Testwerkzeugs
5.3 Erstellen einer Testkonfiguration
5.4 Erstellen und Ausführen von Testskripten mit HP QTP
5.4.1 Grundlagen des HP QuickTest Professional
5.4.2 Testen von Benutzeroberflächen
5.4.3 Parametrisierung in der Testkonfiguration
5.4.4 Implementierung von Prüfungen
5.5 Modularisierung von Testskripten
5.5.1 Modularisierung in HP QTP
5.5.2 Modularisierung in eCATT
5.6 Start und Protokollierung von Skripten im TAF
5.6.1 Ausführen von Skripten
5.6.2 Protokollierung
5.7 Fazit der Analyse

6 Zusammenfassung und Ausblick

Quellverzeichnis

Literaturquellen

Quellen aus dem Internet

Weitere Quellen

Anhang A – Glossar

Anhang B – Transaktionen

Abbildungsverzeichnis

Abbildung 2.1 Allgemeines V-Modell

Abbildung 2.2 Teststufen in der SAP-Projektmethodik

Abbildung 2.3 Ablauf eines Testprozesses

Abbildung 3.1 Application Lifecycle Management

Abbildung 3.2 Testmanagementprozess

Abbildung 3.3 Testoptionen

Abbildung 4.1 EPK zum Prozess der Angebotserstellung

Abbildung 4.2 Modularisierung des Geschäftsprozesses Angebotserstellung

Abbildung 5.1 Testfunktionen und Werkzeuge der Testoption 1

Abbildung 5.2 Testsystem in der SAP-Anwendungslandschaft

Abbildung 5.3 Testbare Schichten einer Systemlandschaft

Abbildung 5.4 Zusammenspiel der Testobjekte

Abbildung 5.5 Anpassung des lokalen Layouts

Abbildung 5.6 Einstellungen der Testfalltypen

Abbildung 5.7 Definition einer Testkonfiguration

Abbildung 5.8 Erstellen einer Testkonfiguration

Abbildung 5.9 Eine Zeile des QTP-Skripts

Abbildung 5.10 HP QTP Testscreen

Abbildung 5.11 HP QTP Add-In Manager

Abbildung 5.12 Record & Run Settings

Abbildung 5.13 Keyword View eines Testskripts

Abbildung 5.14 Parametrisierung im HP QTP

Abbildung 5.15 Object Repository

Abbildung 5.16 Object Spy

Abbildung 5.17 Aufzeichnungsmodi

Abbildung 5.18 Unterschiede im Testskript

Abbildung 5.19 HP Run Result Viewer

Abbildung 5.20 Varianten in der Testkonfiguration

Abbildung 5.21 Ein zentraler Testdatencontainer

Abbildung 5.22 Checkpoint

Abbildung 5.23 Beschreibung des Befehls Reporter

Abbildung 5.24 Das IF-Konditional

Abbildung 5.25 Sequenz von Skripten

Abbildung 5.26 Masterskript

Abbildung 5.27 QTP Testsequenz

Abbildung 5.28 Sequenzen von Skripten in einem Masterskript mit einem Testdatencontainer

Abbildung 5.29 Skriptverhalten bei Fehlereintritt

Tabellenverzeichnis

Tabelle 2.1 Inhalt eines Testkonzepts

Tabelle 2.2 Manuelles und automatisiertes Testen im Vergleich

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Ausgangssituation der Arbeit

Die verstärkte Nutzung von Unternehmensnetzwerken, die zunehmende Globalisierung und die ständige Erweiterung von Geschäftsfunktionen stellen viele Unternehmen vor zahlreiche Herausforderungen. Sie müssen neue Software und Updates ohne Beeinträchtigung der Geschäftsabläufe implementieren und betreiben, sowie trotz steigender Komplexität fehlerfreie und performante Lösungen bereitstellen. Gleichzeitig sollen Betriebskosten gesenkt und Risiken minimiert werden. Unter diesen Prämissen stellt das Thema „Testen“ eine wesentliche Herausforderung für die Implementierung und den Betrieb geschäftskritischer Prozesse dar.

Mit dem SAP Solution Manager wird von der SAP AG (SAP) eine Lösung zur Verfügung gestellt, die alle Methoden, Prozesse und Werkzeuge für das Qualitätsmanagement und Testen beinhaltet. Insbesondere die Funktionalitäten rund um das Testmanagement und die Testautomatisierung sind aktuell wesentlich erweitert und ergänzt worden. Dadurch ergeben sich viele Möglichkeiten in der Erstellung und Verwaltung von manuellen und automatisierten Tests. Die wohl größte Erweiterung stellen dabei die drei unterschiedlichen Testoptionen, welche sowohl SAP- als auch Partner- und Drittanbieter-Werkzeugen beinhalten, dar.

Die drei Testoptionen liefern divergente Ansätze für das manuelle und automatisierte Testen im SAP Solution Manager. Während die Testoptionen 2 und 3 den ganzheitlichen Testlebenszyklus in Drittanbieter-Anwendungen gestalten, wird in Option 1 der komplette Testprozess, von Testplanung bis –auswertung, im SAP Solution Manager umgesetzt. Dabei stellt die Test Workbench, wie bereits in der Vorgängerversion, den zentralen Punkt für die Planung und Vorbereitung von Tests dar, aber auch die Ausführung manueller Tests und die Analyse der Testergebnisse werden hier vollzogen. Für die Erstellung automatisierter Tests wurde das neue Test Automation Framework (TAF), welches die Werkzeuge für die Automatisierung von Tests integriert, in den SAP Solution Manager integriert.

Das TAF integriert über eine zertifizierte Schnittstelle externe Testwerkzeuge für die Erstellung automatisierter Tests. Damit können sowohl SAP- als auch Nicht-SAP-Anwendungen getestet werden, womit ein lückenloses Testen technologieübergreifender Geschäftsprozesse ermöglicht wird. Die Integration eines externen Testwerkzeugs in das Test Automation Framework liefert in Kombination mit dem extended Computer Aided Test Tool (eCATT) viele Vorteile in der Testautomatisierung im SAP-Umfeld.

Diese Arbeit führt eine Machbarkeitsstudie zur Testautomatisierung von SAP- und Nicht-SAP-Anwendungen im SAP Solution Manager 7.1 durch. Darüberhinaus werden die Grundlagen des Testen im SAP-Umfeld aufgezeigt und auf wichtige Fragen der Testautomatisierung eingegangen.

1.2 Zielsetzung der Arbeit

Ausgehend von dem beschriebenen Hintergrund besteht die Zielsetzung dieser Arbeit darin, herauszuarbeiten inwieweit eine Testautomatisierung von technologieübergreifenden Geschäftsprozessen im SAP-Umfeld mit dem neuen Test Automation Framework im SAP Solution Manager 7.1 technisch möglich ist. Hierzu muss das integrierte Testautomatisierungswerkzeug HP QuickTest Professional ausführlich untersucht werden, um dessen Stärken und Schwächenbzw. Potenziale zu erkennen. Für eine solche Untersuchung ist es wichtig, dass sowohl die Grundlagen des Softwaretestens als auch die Thematik der Testautomatisierung bekannt sind. Vor Analyse des TAF werden zunächst diese Kenntnisse vermittelt. Danach findet eine Untersuchung und Beurteilung der Möglichkeiten der Testautomatisierung mit dem neuen Test Automation Framework statt.

1.3 Vorgehensweise der Arbeit

Um die Zielsetzung zu erreichen, wird in dieser Bachelorthesis wie folgt vorgegangen:

In Kapitel 2 werden die theoretischen Grundlagen zum Testen von Software und Softwaresystemen erarbeitet. Diese Grundlagen beinhalten neben einem Einblick in die Notwendigkeit von Tests auch eine Beschreibung der Teststufen in der SAP-Projektmethodik. Weiterhin wird mit der Beschreibung von Testaktivitäten ein mögliches Vorgehensmodell für einen Testprozess geliefert.Anschließend werden die für das Softwaretesten wichtigen Erkenntnisse der Testautomatisierung zusammengefasst, hierunter fallen die Vor- und Nachteile des automatisierten Testens und deren Auswirkungen auf den Testprozess. Zunächst wird anhand von Nachteilen aufgezeigt, was die Testautomatisierung nicht leisten kann und damit versucht falsche Erwartungen an das automatisierte Testen zu beseitigen. Die Erkenntnisse zeigen jedoch, dass die Vorteile der Testautomatisierung bei richtiger Implementierung der Testwerkzeuge und sorgfältiger Planung des Testprozesses die Nachteile überwiegen. Teilweise werden erhebliche Einsparungen des Arbeits- und Zeitaufwands im Vergleich zum manuellen Testen deutlich. Die Betrachtung einiger Testwerkzeuge, die den Anwender bei den Testaktivitäten unterstützen und das manuelle Testen verbessern können, bildet das Ende des Kapitels.

Kapitel 3geht auf die Anwendungsmanagementlösung SAP Solution Manager ein und beschreibt neben der Funktionalität auch die integrierten Werkzeuge. Ein wichtiges Thema des Kapitels, aber auch des SAP Solution Managers stellt das Application Lifecycle Management dar, nach dessen Prinzip die Prozesse in der Managementlösung abgebildet werden. Nach der Erläuterung des Testablaufs im SAP Solution Manager, schließt die Beschreibung der einleitend vorgestellten Testoptionen das Kapitel ab.

Kapitel 4 beinhaltet die Vorbereitungen zur Untersuchung des Test Automation Frameworks mit dem integrierten Partnerwerkzeug HP QuickTest Professional. Um eine sorgfältige Analyse gewährleisten zu können, werden zunächst die Ziele der Untersuchung festgelegt und die zu testenden Technologien innerhalb eines Geschäftsprozesses aufgezeigt. Anhand eines Konzepts soll das Vorgehen der Untersuchung in die zielführende Richtung gelenkt werden.

Die Umsetzung der Anforderungen bildet den Inhalt von Kapitel 5. Dieses Kapitel beschreibt das neue Test Automation Framework im SAP Solution Manager 7.1 und die Integration des Partnerwerkzeugs HP QuickTest Professional. Die Analyse des Testwerkzeugs zeigt die Möglichkeiten der Testautomatisierung technologieübergreifender Geschäftsprozesse im SAP-Umfeld.

In dem abschließenden Kapitel 6 wird die Zielerreichung der Arbeit validiert und ein kurzer Ausblick auf das weitere Vorgehen zu dem Thema „Testautomatisierung“ bei der EnBW AG gegeben.

2 Einführung in Software-Testen

Das Thema „Testen“ von Software wird in der Softwareentwicklung und -wartung als unverzichtbar gesehen, dennoch gibt es von Unternehmen zu Unternehmen, von Branche zu Branche, riesige Unterschiede in der Qualität des Testens. Während im Umfeld der Chemie- und Pharmaindustrie, wo falsche Entscheidungen und schlecht organisierte Tests Menschenleben gefährden können, ausgereifte Testprozesse anzutreffen sind (vgl. [HeTr09], S. 29), wird laut [INET01] und [INET02] in der IT-Branche immer noch zu selten und nicht sorgfältig getestet. Dabei stellt das Testen die Funktionalität von Softwareanwendungen sicher und erhöht zugleich deren Qualität.

SAP erachtet das Thema „Testen“ als erforderlich und stellt daher seinen Kunden unterschiedliche Werkzeuge und Services zur Verfügung, um Implementierungen und Updates von SAP-Lösungen kontrolliert durchführen zu können. Ein reibungsloser Weiterbetrieb von Geschäftsprozessen wird gewährleistet, indem Änderungen planvoll dokumentiert, getestet und implementiert werden. Der Test stellt auf diese Weise sicher, dass eine geänderte Funktionalität keine negativen Auswirkungen auf den Betrieb hat. Laut [INET03] zeigt sich in der Praxis allerdings immer noch, dass Testprozesse nicht planvoll erfasst werden und somit wenig Effizienz bieten. Aussagen über die Stabilität der Änderungen können dadurch kaum getroffen und die Sicherheit des Produktivbetriebs kann zu keinem Zeitpunkt gewährleistet werden.

In diesem Kontext taucht gelegentlich die Frage auf: „Warum soll eine Standardsoftware getestet werden? Macht das nicht der Hersteller?“. Sicherlich ist es die Aufgabe des Herstellers die Software zu testen und auf Korrektheit zu prüfen, jedoch können kundenseitige individuelle Änderungen nicht durch den Hersteller abgedeckt werden. „Somit ist die unternehmensindividuelle Ausprägung einer betrieblichen Standardsoftware in jedem Fall zu testen.“ [HeTr09].

Bevor in den nachfolgenden Abschnitten auf die Grundlagen des Testens im SAP-Umfeld eingegangen wird, muss zunächst die Notwendigkeit des Testens verdeutlicht werden. Diese ist vielen nicht bewusst, was zur Folge hat, dass Projekte, aufgrund zu spät erkannter Fehler, nicht rechtzeitig fertiggestellt werden oder oftmals das Budget übersteigen. Softwaretests haben einen hohen Nutzen und sind daher absolut notwendig.Die Automatisierung von Tests ermöglicht eine gleichbleibende Testqualität und kann durch die Wiederverwendbarkeit von Testskripten den Arbeits- und Zeitaufwand minimieren. Hier muss aber genau abgewogen werden, ob die Automatisierung sinnvoll erscheint oder nicht. Daher werden im letzten Teil des Kapitels die Vor- und Nachteile der Testautomatisierung beschrieben und Werkzeugtypen aufgezeigt, die bei der Automatisierung behilflich sein können.

2.1 Notwendigkeit von Tests

Einleitend wurde beschrieben, dass das Thema „Testen“ als wichtiger Bestandteil der Softwareentwicklung betrachtet wird, jedoch in unterschiedlicher Form und Qualität ausgeprägt ist. Um Fragestellungen, wie „Warum muss eine Standardsoftware getestet werden?“ zu vermeiden, muss die Notwendigkeit des Testens verdeutlich werden. Nachfolgend wird auf diesen Punkt eingegangen, um ein einheitliches Verständnis für dieses Thema zu schaffen.

SAP stellt mit der breiten Palette der SAP-Lösungen eine hohe Funktionalität zur Verfügung, die einen großen Bereich der betrieblichen Geschäftsprozesse abdeckt. Für die korrekte Funktionsweise der Produkte setzt SAP auf eine umfassende Qualitätssicherung, die in allen Phasen der SAP-Projektmethodik (siehe Kapitel „Teststufen in SAP-Projekten“) zum Einsatz kommt. Kundenseitig gilt es, die individuellen Geschäftsprozesse des eigenen Unternehmens mit SAP-Produkten in Lösungen zu überführen. Reicht die Standardfunktionalität der SAP-Produkte nicht aus, können kundenspezifische Änderungen vorgenommen werden. Dabei stehen dem Kunden mehrere Möglichkeiten zur Verfügung die Standardsoftware an die individuellen Geschäftsprozesse anzupassen.

Unternehmen versuchen durch die Entwicklung und Anpassung der eigenen Geschäftsprozesse ihre Einzigartigkeit und die daraus resultierenden Wettbewerbsvorteile zu sichern. Die Individualität der Geschäftsprozesse führt aber die Funktionalität der Standardsoftware oftmals an ihre Grenzen. Somit werden kundenseitige Änderungen an der Software unvermeidlich. Bevor aber unnötige Eingriffe vorgenommen werden, sollte zunächst geprüft werden, ob standardisierte Prozesse mit Hilfe des Customizings an die Anforderungen des Unternehmens angepasst werden können. Überall dort, wo diese Form der Anpassungen nicht ausreicht, muss die Funktionalität durch Erweiterungen oder Modifikationen implementiert werden. Sollten Modifikationen ebenfalls nicht ausreichen, gibt es die Möglichkeit vollständige Eigenentwicklungen im SAP-System zu implementieren (vgl. [INET04]).

All diese Änderungsmöglichkeiten einer SAP-Lösung können geschäftskritische Fehler ver-ursachen, daher gilt es das Customizing und zusätzliche Entwicklungen durch angemessene Testaktivitäten zu prüfen. Auf diese Weise kann auf fachlicher Ebene sichergestellt werden, dass alle Anforderungen korrekt in die Lösung implementiert wurden, damit die Lösung alle Geschäftsprozesse optimal unterstützen kann (vgl. [HeTr09], S. 31). Zudem muss auf technischer Ebene die fehlerfreie Nutzung der Prozesse und eine angemessene Performance gewährleistet werden (vgl. [HeTr09], S. 31). Die kundenindividuelle Ausprägung einer Standardsoftware muss somit, ob geringe oder erhebliche Änderungen vorgenommen wurden, immer getestet werden.

Doch nicht nur kundenindividuelle Entwicklungen stellen Tester vor neue Herausforderungen. Die komplett neue Installation einer SAP-Lösung oder das Update eines bestehenden Systems, in Form von Patches und Enhancement Packages, bringen enorme Änderungen mit sich, die es ebenso gilt zu prüfen (vgl. [INET05]). Besonders wichtig ist die Gewährleistung eines reibungslosen Ablaufs geschäftskritischer Prozesse im Produktivbetrieb (vgl. [HeTr09], S. 43). Hier dürfen nach dem Einspielen von Support Packages und SAP-Hinweisen keine Fehler auftreten. Die Notwendigkeit zur Prüfung sämtlicher Änderungen und Geschäftsprozesse ist damit gegeben.

Für das Testen der Änderungen in SAP-Lösungen existieren viele Möglichkeiten. Hier muss eine ausgewogene Kombination von Testfällen ausgewählt werden, um zu hohen Testaufwand und redundante Tests zu vermeiden. Zudem sollten die Testfälle nicht nur einzelne Geschäftsprozesse abdecken, sondern die vollständige Durchführung von Integrationstests ermöglichen. Mit dem richtigen Management von Tests und dem Einsatz von Testautomatisierungswerkzeugen kann nicht nur eine hohe Qualität der SAP-Lösungen realisiert werden, zudem kann durch die Wiederholung von Regressionstests der Zeit- und Kostenaufwand signifikant reduziert werden (vgl. [INET03] und [INET05]). Der SAP Solution Manager (siehe Kapitel 3) als Plattform für das Management von SAP-Lösungen unterstützt dabei den Anwender bei sämtlichen Testaktivitäten im Umfeld von SAP-Produkten.

Wie dieser Abschnitt gezeigt hat, ist das Testen aller Änderungsereignisse unvermeidbar, um die fehlerfreie Funktionalität von SAP-Lösungen zu gewährleisten. Je nach Änderungsereignis entstehen aber unterschiedlich hohe Testaufwände und –umfänge, die bei der Planung von Testfällen einkalkuliert werden müssen. Außerdem erfordern Änderungen unterschiedliche Testaktivitäten und Methoden, die zusammen mit den typischen Teststufen im SAP-Umfeld nachfolgend aufgezeigt werden.

2.2 Teststufen in der SAP-Projektmethodik

In den vergangenen Jahrzehnten wurden in der Softwareentwicklung viele Vorgehensmodelle erarbeitet, um Softwareprojekten eine Struktur zu geben und somit ein organisiertes Vorgehen im Entwicklungsprozess zu ermöglichen. Das von Boehm bereits 1979 vorgestellte V-Modell erkannte die Qualitätssicherung als eigenen Prozess und stellte diese dem Entwicklungsprozess gleich. Die Gegenüberstellung der Testphasen überprüft die Ergebnisse der korrespondierenden Entwicklungsphasen und führt auf diese Weise zu einer möglichst hohen Testabdeckung (vgl. [INET06]). Aufgrund der Konzeptions- bzw. Entwicklungsphasen auf der linken Seite und der gleichberechtigten Testphasen auf der rechten Seite entsteht ein V-förmiger Aufbau des Modells (siehe Abbildung 2.1) (vgl. [FeGr99], S. 6).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1Allgemeines V-Modell (vgl. [HeTr09], S. 48)

Auch wenn das V-Modell in seiner ursprünglichen Form für einen modernen Entwicklungs- bzw. Implementierungsprozess nicht mehr geeignet ist, zeigt es trotzdem auf, dass innerhalb eines Entwicklungsprojekts verschiedene Testphasen erforderlich sind. „Die Aufteilung in unterschiedliche Teststufen ist sinnvoll, da die einzelnen Stufen jeweils andere Vorgehensweisen bei der Testfallerstellung, Testplanung und Testdurchführung erfordern, die es im Projekt-kontext zu berücksichtigen gilt“ [HeTr09].

Das V-Modell eignet sich nicht nur als Vorgehensmodell für die Neuentwicklung einer Software, sondern kann für unterschiedliche Entwicklungsprozesse eingesetzt werden. Diese Eigenschaft stellt eine Verbindung zum SAP-Umfeld dar, jedoch mit dem Unterschied des zugrunde liegenden Vorgehensmodells. Die ASAP (Accelerated SAP) Implementation Roadmaps^[1] beschreiben das Vorgehen für die Implementierung und das Update von SAP-Systemen. Sie decken gesamte Projekte ab und gehen über die Realisierung und den Test von System-änderungen hinaus (vgl. [HeTr09], S, 50). Dokumentvorlagen und Best Practices können z.B. im Kontext einzelner Projektphasen bzw. Tätigkeiten abgerufen werden (vgl. [HeTr09], S. 78). Neben den standardisierten ASAP Roadmaps für verschiedene Projekttypen (u.a. Upgrade, Roll-out) können kundenspezifische Roadmaps erstellt werden. Diese ermöglichen ein angepasstes Vorgehensmodell bei großen Projekten mit Eigenentwicklungen.

Entsprechend dem allgemeinen V-Modell wird im SAP-Umfeld ebenfalls in jeder Projektphase getestet. Die ASAP Roadmaps gehen jedoch über Akzeptanztests hinaus und bilden mit den Regressionstests ein gesondertes Vorgehen im operativen Betrieb zur Absicherung der Funktionalität der SAP-Systeme. Die Abbildung 2.2 zeigt die Verbindung aus den Teststufen des V-Modells und der SAP-Projektmethodik.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2Teststufen in der SAP-Projektmethodik (vgl. [HeTr09], S. 51)

Teststufen in SAP-Projekten

Im SAP-Umfeld wird funktional nach einer Bottom-up-Strategie getestet, d.h. vom Teil zum Ganzen. Diese erlaubt im zeitlichen Verlauf eines Projektes nach Integrationsstufen vor-zugehen und in jeder ASAP-Phase die notwendigen Tests durchzuführen. Dabei werden nach [HeTr09], [ObGe00] und [SpLi10] folgende Tests unterschieden:

- Entwicklertest: Wie der Name bereits sagt, wird diese Testart in der Entwicklungsphase vom Entwickler selbst durchgeführt. Die Tests finden auf technisch niedriger Ebene statt und können neben der formalen Ablauffähigkeit auch einzelne Codezeilen und Funktionsbausteine testen.
- Funktionstest: Ein Funktionstest, auch Modultest oder Unit-Test genannt, überprüft eine einzelne Transaktion oder einen Funktionsbaustein. Dabei liegt der Fokus des Tests auf den inneren Funktionen und nicht auf der Schnittstelle oder Integration.
- Szenariotest: Mit einem Szenariotest werden mehrere zusammenwirkende Transaktionen z.B. in einem Geschäftsprozess getestet. Bei dieser Testart soll das Zusammenspiel ein-zelner Transaktionen und ihrer Schnittstellen geprüft werden.
- Integrationstest: Die fehlerfreie Integration von SAP-Lösungen mit Non-SAP-Anwendungen und Systemschnittstellen ist in einer heterogenen Systemlandschaft von hoher Bedeutung und muss daher durch einen Integrationstest geprüft werden. Die Geschäftsprozesse werden hierfür in Szenarien abgebildet und die Software wird entlang dieser modul- und systemübergreifenden Szenarien getestet.
- Technischer Systemtest: Bei den Systemtests wird das Gesamtsystem mit allen Komponenten, wie Datenbank, Applikationsserver, Netzwerk usw., gegen die gesamten Anforderungen in einer simulierten Produktivumgebung getestet.
- Performancetest: Als wesentlicher Bestandteil der technischen Systemtests sorgen Performancetests für die Messung der Durchsatz- und Antwortzeiten des Systems. Für die Durchführung solcher Tests wird die funktionale Korrektheit der zu testenden Anwendung vorausgesetzt.
- User Acceptance Test: Ein weiterer bedeutender Test vor dem Go-Live ist der User Acceptance Test. Hauptsächlich wird bei diesem Test auf Probleme in der Bedienbarkeit geprüft. Dieser Test wird durch den Anwender manuell durchgeführt, weshalb ein erheblicher Aufwand verursacht wird und mitunter keine automatisierten Tests verwendet werden können.
- Regressionstest: Das Ziel eines Regressionstests ist es sicherzustellen, dass nach einer prozessualen oder technischen Veränderung keine Fehler in der Funktionalität oder am Geschäftsprozess entstehen. Im SAP-Umfeld werden solche Tests hauptsächlich nach Korrekturen, Enhancement-/Support-Package-Implementierungen oder nach Änderungen des Customizings eingesetzt.

Aufgrund der Wichtigkeit der Regressionstests für die Untersuchungen dieser Arbeit, wird auf diese Testart und die Ereignisse, die einen Regressionstest erforderlich machen, nachfolgend eingegangen.

Regressionstest

Wie bereits erwähnt, soll ein Regressionstest sicherstellen, dass nach einer Modifikation an einer bereits getesteten Komponente keine Fehler auftreten. Dafür werden im Grunde keine neuen Testfälle entwickelt, sondern vorhandene Tests wiederholt. Hierdurch kann gewähr-leistet werden, dass nach einer Änderung der Softwarekomponente der identische Test durchgeführt wird. Somit kann ein Vergleich zum Testlauf der Vorgängerversion gezogen werden (vgl. [Fran07], S. 208).

Änderungen der Software können Regressionstests in jeder Projektphase notwendig machen. [Fran07] und [HeTr09] unterscheiden dabei zwischen diesen Ereignissen:

- Fehlerbehebung einer Komponente: Die Korrektur eines Fehlers in einer Komponente kann unter Umständen zu einem anderen Fehler führen und sich negativ auf die Funktionalität der Anwendung auswirken. Ein Regressionstest soll die Komponente auf den korrigierten Fehler prüfen und auf eventuelle Folgefehler stoßen. Die Testwiederholung soll sich jedoch nicht nur auf die modifizierte Komponente beschränken, sondern direkt kommunizierende Systemkomponenten mit überprüfen.
- Implementierung neuer Funktionen: Die Erweiterungen einer SAP-Lösung durch neue Funktionen oder Änderungen vorhandener Funktionen müssen zunächst in allen Projektphasen getestet werden. Der anschließende Regressionstest soll sicherstellen, dass keine der bestehenden, un-veränderten Funktionen durch die Neuerungen ungewollt beeinflusst werden.

2.3 Testaktivitäten

Das Kapitel 2.2 hat bereits gezeigt, das Tests in allen Projektphasen entlang der Integrationsstufen notwendig sind, um die fehlerfreie Funktionalität einer Software nach vorgenommenen Änderungen gewährleisten zu können. Mit den ASAP Roadmaps steht eine umfangreiche Methodik zur Implementierung und zum Betrieb von SAP-Lösungen zur Verfügung, welche auch Aktivitäten zur Qualitätssicherung enthalten. In diesem Kontext hat ein Testprozess die Auf-gabe die wesentlichen Schritte zur Umsetzung des Tests zu beschreiben und somit ein strukturiertes Vorgehen zu ermöglichen (vgl. [SpLi10], S. 20). In der allgemeinen Literatur sind ausführliche Beschreibungen mit allen Testaktivitäten zu finden, zumindest sollte ein Testprozess die nachfolgend beschriebenen Schritte enthalten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3Ablauf eines Testprozesses

Testvorbereitung

Die Vorbereitungen einer so umfangreichen Aufgabe wie das Testen sollten so früh wie möglich in einem Projekt stattfinden. In den ersten Schritten werden sämtliche Aspekte der durchzuführenden Tests analysiert und gegliedert dokumentiert. Alle Festlegungen werden in Form eines Testkonzepts, welches für das gesamte Projekt als Regelwerk und Leitfaden für alle Testaktivitäten gelten soll, festgehalten (vgl. [SpLi10], S. 21). Unter anderem enthält ein solches Konzept folgende Informationen (vgl. [SpLi10], S. 179):

- Einordnung der Tests in den Projektkontext
- Art und Umfang der Testumgebung
- Umfang der Testdokumente
- Inhalte der Tests, zu testende sowie nicht zu testende Merkmale
- Testende-, Testabbruch- und Abnahmekriterien
- Verwendung von Testwerkzeugen

Tabelle 2.1Inhalt eines Testkonzepts

Kernaufgabe der Testvorbereitung ist die Bestimmung der Teststrategie, die wiederrum die Zielsetzung der Tests und der Testaktivitäten festlegt. Um eine optimale Testabdeckung erreichen zu können, werden anhand einer Risikoanalyse der Testumfang, die Priorität und der Detailierungsgrad einzelner Testarten und –stufen bestimmt. Die Gewichtung der durchzuführenden Testfälle kann mit der Identifikation von Risikopotentialen bestimmt werden. Dabei muss der Testumfang kritischer Systemkomponenten größer ausfallen und intensiver getestet werden, als der einer weniger kritischen Komponente. Die Bestimmung der benötigten Ressourcen stellt in diesem Zusammenhang eine Herausforderung dar, denn sie impliziert die Abschätzung des Testaufwands (vgl. [HeTr09], S. 63).

Testfallerstellung

Die in den Vorbereitungen festgelegte Teststrategie gibt vor in welchem Umfang Objekte getestet werden sollen. Auf dieser Grundlage können einzelne Testfälle spezifiziert werden, wobei zu beachten ist, dass unterschiedliche Testphasen unterschiedliche Testfälle benötigen. Eine Beschreibung der Testfälle muss in jedem Fall angelegt werden, unabhängig davon, ob manuell oder automatisiert getestet wird. Die manuellen Tests sollten idealerweise eine detaillierte Beschreibung aufweisen, um als Grundlage für eine Automatisierung dienen zu können (vgl. [HeTr09], S. 63).

Testplanung und -durchführung

Die unterschiedliche Betrachtung der Teststufen innerhalb der Testarten macht es unmöglich einen universellen Testplan für alle Testarten zu erstellen. Daher werden im ersten Schritt der Testplanung die für die Teststufe relevanten Testfälle aus der Gesamtmenge identifiziert und zugewiesen. Für einen nicht vollumfänglichen Test kann anhand der Risikobewertung eine Teilmenge der Testfälle selektiert werden. Die Risikoanalyse hilft die Priorisierung von Testfällen festzulegen, um einen konkreten Ablauf der Tests zu ermöglichen und gleichzeitig sicherzustellen, dass kritische Testfälle zuerst auszuführen sind (vgl. [SpLi10], S. 27). Nach der Planung der Tests erfolgt ihre Durchführung. Die einzelnen Testfälle werden Testern zugewiesen, welche die Durchführung und das Ergebnis der Tests exakt und vollständig dokumentieren und einen definierten Status der Tests (z.B. erfolgreich, fehlerhaft) zurückmelden. Für eine erfolgreiche Planung und Durchführung von Tests und die anschließende Auswertung und Dokumentation empfiehlt [Spil08] den Einsatz von Testmanagementwerkzeugen.

Testauswertung

Das Reporting ist ein wichtiges Element des Testprozesses, denn es gibt nach der Testdurchführung wichtige Informationen über den Status der Testfälle und ermöglicht somit zu bewerten, ob die in der Planung festgelegten Testendekriterien erfüllt sind. Die Auswertung gibt Auskunft über den aktuellen Bearbeitungsstatus und die Fehlermeldungen und kann somit zur Beendigung der Testaktivität führen. Aufgrund von Auswertungen können zusätzliche Testfälle eingeführt oder die Kriterien reduziert werden. Der Einsatz von Testmanagementwerkzeugen erweist sich hier als sehr sinnvoll, da ein Überblick mit Diagrammen und Detailberichten ermöglicht wird. In jedem Fall muss bei der Erfüllung der Testendekriterien ein abschließender Testbericht erstellt werden. Dieser sollte neben den relevanten Nachweispflichten auch mögliche Verbesserungsvorschläge zum Testprozess enthalten (vgl. [Spil08], S. 24).

2.4 Testautomatisierung

Die vorhergehenden Abschnitte haben bereits beschrieben, dass das Thema „Testen“ ein wichtiger Bestandteil der Softwareentwicklung ist und seine Notwendigkeit hat. Änderungen von Standardsoftware durch Weiterentwicklung, Customizing oder Implementierung von Updates führen zu neuen Funktionen, welche die Software grundlegend verändern können. Um die Funktionalität gewährleisten zu können, müssen nicht nur die geänderten Komponenten der Software getestet werden, sondern die komplette Systemsoftware. Mit den ASAP Roadmaps steht im SAP-Umfeld ein Vorgehensmodell zur Verfügung, das in unterschiedlichen Projektphasen unterschiedliche Teststufen vorsieht und somit den Entwicklungsprozess der Software durch den entsprechenden Testprozess absichert. Mit den Testaktivitäten wird ein Testprozess von der Vorbereitung bis zur Durchführung durchlaufen und anschließend ausgewertet. Auf Grundlage der ausgewerteten Ergebnisse werden weitere Entscheidungen getroffen.

Mit der Testautomatisierung ergeben sich einige Möglichkeiten, die den Anwender (Testmanager, Testingenieur, Tester) bei der Erstellung und Auswertung der Tests unterstützen und eine Hilfestellung leisten. Jedoch erweckt der Begriff „Testautomatisierung“ bei vielen Personen falsche Vorstellungen, weshalb des Öfteren euphorisch über das Thema gesprochen wird, jedoch die Vorstellungen mit mehr Aufwand verbunden sind, als zunächst geplant. Diese falschen Erwartungen an das Thema „Testautomatisierung“ sollen nachfolgend ausgeräumt werden, bevor die Vorteile der Thematik dargestellt werden. Der Abschnitt mit der Beschreibung der möglichen Testwerkzeuge zur Unterstützung der Testaktivitäten und Methoden schließt das Kapitel ab.

2.4.1 Das kann die Testautomatisierung nicht leisten

Im Zusammenhang mit Testautomatisierung entstehen oft falsche Erwartungen, weil ungeschulte Personen eine falsche Vorstellung von automatisiertem Testen haben (vgl. [FeGr99], S. 10). Die Erwartungen liegen in vielen Fällen weit von der Realität entfernt, denn der Einsatz eines Testautomatisierungswerkzeugs bedeutet nicht, dass der Testaufwand automatisch verringert wird oder der Zeitplan sich verkürzt. Im Gegenteil nimmt der Aufwand zu Beginn eines Testprozesses zu und kann sich erst bei mehrmaliger Wiederholung auszahlen.

Laut [DuRP00] lassen hohe Ansprüche an Technologie und Automatisierung manche Menschen glauben, ein automatisiertes Testwerkzeug kann alle Aktivitäten von der Planung bis zur Ausführung der Tests ohne manuellen Einsatz erledigen. Andere glauben, ein einziges Testwerkzeug könne ohne Rücksicht auf Umgebungsparameter sämtliche Testanforderungen unterstützen.

Falsche Erwartungen im Hinblick auf Testautomatisierung müssen ausgeräumt werden, um ein besseres Verständnis für das automatisierte Testen und dessen Auswirkungen zu schaffen. In diesem Abschnitt wird ein Teil der falschen Vorstellungen aufgezeigt.

Die Alleskönner

Auch wenn die Vorstellung großartig ist, dass ein Testwerkzeug automatisch den Testplan entwickelt, die Testverfahren entwirft und erstellt und die Abläufe ausführt, entspricht dies nicht ganz der Realität. Testwerkzeuge können zwar einige Testaktivitäten automatisieren, trotzdem sollten sie als eine „Verbesserung des manuellen Testens“ [DuRP00] betrachtet werden, und nicht als Alleskönner, die den menschlichen Faktor komplett ersetzen können.

Verringerung des Testaufwands

Der Einsatz automatisierter Werkzeuge wird zwar oft in der Verringerung des Testaufwands begründet, jedoch tritt eine Einsparung nicht unmittelbar auf. Es ist sogar möglich, dass bei der Einführung automatisierter Tests ein höherer Aufwand für den Testprozess entsteht. Die Gründe für den höheren Aufwand können im Einsatz eines neuen Testwerkzeugs oder in der ausführlichen Analyse der Zielanwendung liegen. Sowohl die Einarbeitung in ein neues Werkzeug als auch die Untersuchung des Zielsystems, um zu ermitteln, welche Teile davon der Automatisierung zugänglich sind, stellen einen zusätzlichen Testaufwand dar (vgl. [DuRP00], S. 39). Eine Verringerung des Testaufwands wird gewöhnlich (bzw. wenn überhaupt) erst nach mehreren Testdurchläufen, in Form von Regressionstests, erreicht (vgl. [INET01]).

Verkürzung des Zeitplans

Eine weitere falsche Erwartung ist, dass Testautomatisierung den Testprozess beschleunigt und somit den Zeitplan verkürzt. Wie oben beschrieben, kann die Einführung eines automatisierten Testwerkzeugs den Testaufwand erhöhen. Dies hat zur Folge, dass die erwartete Verkürzung nicht unmittelbar zutrifft. Es besteht sogar die Möglichkeit, dass eine Verlängerung des Zeitplans erforderlich ist, da mit der Einführung der Testautomatisierung aktuelle Testprozesse erweitert oder sogar neue Prozesse entwickelt werden müssen (vgl. [DuRP00], S. 39).

Universelle Anwendbarkeit der Testautomatisierung

Wie bereits erwähnt, sollte der Begriff „Testautomatisierung“ als Verbesserung des manuellen Testens und nicht als die Lösung für das Testen gesehen werden. Schließlich ist es weder möglich noch ist es wirtschaftlich verträglich alle Tests in einem Projekt zu automatisieren. Allein die Betrachtung der unendlichen Anzahl von Abwandlungen und Kombinationen von System- und Benutzeraktivitäten, die in n-schichtigen Architekturen und Anwendungen mit grafischen Benutzeroberflächen möglich sind, zeigt, dass sehr viel Zeit benötigt wird, um jede Möglichkeit zu testen. Der Tester hat gar nicht die Zeit und die nötigen Ressourcen, um eine hundert-prozentige Testabdeckung einer Anwendung zu gewährleisten (vgl. [DuRP00], S. 41). Aufgrund der hohen Komplexität und der umfangreichen Funktionalität moderner Systeme würde das Testen zu einer endlosen Aufgabe wachsen (vgl. [INET05]). Infolgedessen sollte niemals eine hundertprozentige Testautomatisierung einer zu testenden Anwendung als das Ziel festgelegt werden. Denn „es ist unmöglich, einen 100%-Test mit allen möglichen einfachen Eingaben für ein System durchzuführen“ [DuRP00].

Hinzukommt der einschränkende Faktor „Kosten“, der die Automatisierung von einmal ausgeführter oder sehr spezifischer und komplexer Tests teurer als manuelles Testen macht (vgl. [INET05]). Aufgrund des hohen Zeitaufwands, der für die Erstellung von automatisierten Tests investiert werden muss, kann durch die einmalige Ausführung kein Mehrwert entstehen (vgl. [FeGr99], S. 5). Ähnliche Auswirkungen auf die Kosten haben spezielle und komplexe Testfälle. Die Testautomatisierung solcher Tests bringt meistens keine wirtschaftlichen Vorteile, da der automatisierte Test nur für diesen einen Fall angewandt wird und somit kein mehrfacher Einsatz möglich ist. Der Aufwand, der dafür betrieben werden muss, ist wiederum zu groß und erhöht die Kosten der Testerstellung. Daher sollte während der Testvorbereitung genau untersucht werden, für welche Testfälle sich die Investition in die Entwicklung eines automatisierten Testskripts lohnt (vgl. [FeGr99], S. 5). Dafür ist eine sorgfältige Analyse der zu testenden Systemanwendung notwendig.

Außerdem sollte beachtet werden, dass manche Tests physikalisch einfach nicht automatisiert werden können, wie zum Beispiel eine gedruckte Ausgabe. Sicherlich könnte der Prozessschritt, der einen Druckaufrag ausführt, geskriptet werden, jedoch kann die nachfolgende Prüfung, ob die Ausgabe auch wirklich erfolgt ist, nicht automatisiert werden. Die manuelle Prüfung durch den Anwender ist trotzdem notwendig.

Weiterhin sollte jedem bewusst sein, dass die Automatisierung von GUI-Tests einen großen Aufwand verursacht, wenn die Benutzeroberfläche der zu testenden Anwendung ständigen Änderungen unterworfen ist. Allein die Verschiebung eines Objekts in der Präsentationsschicht der Software kann einen automatisierten Test fehlschlagen lassen, wenn das Testwerkzeug nur die Position des Testobjekts speichert und dadurch das Objekt nicht mehr findet. Um die Funktionalität weiterhin testen zu können, ist somit eine Anpassung, evtl. sogar Neuerstellung, des Testskripts notwendig. Daher sollte die GUI-Testautomatisierung am Ende eines Projekts erfolgen, weil sich bis dahin oft noch Änderungen ergeben (vgl. [INET05]).

2.4.2 Vorteile der Testautomatisierung

Auch wenn die Testautomatisierung nicht alle Erwartungen erfüllen kann, so bringt sie bei korrekter Implementierung und einem festgelegten Testprozess (siehe Kapitel 2.3) einige Vorteile mit sich. Die bedeutendsten Vorteile automatisierter Tests werden nachfolgend aufgezeigt.

2.4.2.1 Verbesserung der Softwarequalität

Damit eine Software erwartungsgemäß und mit geringer Ausfallzeit laufen kann, werden mit der Testarbeit die Ziele der Auffindung und Reduzierung von Mängeln verfolgt. Ein weiteres Ziel sollte darin bestehen die Erwartungen der Benutzer zu erfüllen oder zu übertreffen. Um diese Ziele erreichen zu können, sollte der Testprozess innerhalb des Schrittes „Anforderungsdefinition“ in der Entwicklungsphase beginnen.

Testautomatisierung kann das Testen in alle Aktivitäten verbessern, z.B. bei der Entwicklung von Testverfahren während der Vorbereitung, der Testausführung, der Analyse der Test-ergebnisse und der Berichterstellung. Außerdem werden alle Teststufen, beginnend bei den Entwicklertests bis einschließlich Regressionstests, unterstützt. Testautomatisierung kann mit korrekt implementierten Testwerkzeugen und Methoden und einem wohldefinierten Testprozess zur Verbesserung der Qualität der Systemsoftware führen.

Detaillierte Definition der Anforderungen

Die Definition von Testfällen ist zwingend notwendig, um zuverlässige und kostengünstige Softwaretests erstellen zu können. Dabei sollten Anforderungen detailliert und eindeutig beschrieben werden, um den Testaufwand und Kosten zu verringern. Mit Werkzeugen wird das Erstellen testfähiger Anforderungen erleichtert. Testfertige Anforderungen unterstützen nicht nur die Vorbereitung eines effizienten Tests, sondern erhöhen zusätzlich die Nachvollzieh-barkeit des Testverfahrens. Dadurch wird eine größere Sicherheit in Bezug auf die Vollständigkeit des Tests geschaffen.

Verbesserte Performancetests

Die Zeiten als Leistungsdaten manuell mit der Stoppuhr gesammelt wurden, gehören seit der Einführung von Testwerkzeugen der Vergangenheit an. Die manuelle Ausführung war nicht nur arbeitsintensiv, sondern stark fehleranfällig und ermöglichte keine automatische Wieder-holung (vgl. [DuRP00], S. 45). Mit Werkzeugen für Performancetests werden Systemfunktionen automatisiert getestet und anschließend Zahlen und Kurven über Zeitwerte ausgegeben und die Engpässe dargestellt. Ein weiterer Vorteil des Einsatzes von Testwerkzeugen zur Performancemessung ist die Minimierung der eingesetzten Rechner und Personen zur Durchführung einer Vielzahl von Tests. Mit einem automatisierten Performancetest können nicht nur viele manuelle Tester ersetzt, sondern eine gleichbleibende Wiederholung der Tests ermöglicht werden. Zudem können anhand von Testdaten unterschiedliche Tests simuliert werden, um die Auswirkungen auf unterschiedliche Gegebenheiten zu testen. Das Ziel von Performancetests sollte im Nachweis der akzeptablen Reaktionszeiten unter realistischen Belastungen bestehen.

Mögliche Qualitätsmessung

Der Einsatz von Werkzeugen zur Testautomatisierung ermöglicht die Ausgabe von Metriken für die Qualität der Tests. Die Ergebnisse der automatisierten Tests lassen sich messen und analysieren und durch die Wiederholbarkeit von Tests mit bereits ausgeführten Tests vergleichen. Diese Möglichkeiten bilden einen Vorteil zum manuellen Testen, bei dem es vorkommen kann, dass die beim ersten Durchgang unternommenen Schritte nicht identisch mit denen sind, wie beim zweiten Durchgang. Infolgedessen wird eine Qualitätsmessung ungenau und der Vergleich somit schwierig.

2.4.2.2 Verbesserung der Testqualität

Ein weiterer Grund für die Verwendung von Testautomatisierung ist die Steigerung der Tiefe und Breite der Tests. Die Vorteile, welche sich dadurch ergeben, werden nachfolgend dargestellt.

Verbesserte Regressionstests

Laut Definition (siehe Kapitel 2.2) ist ein Regressionstest die Wiederholung eines Tests an einer modifizierten Software. Dabei wird das Ziel verfolgt, sicherzustellen, dass die bereitgestellte Funktionalität die Spezifikationen erfüllen und keine Fehler durch Änderungen in der Software entstehen. Ein Testautomatisierungswerkzeug ermöglicht einfachere Regressionstests durch die gleichbleibende Wiederholung eines Tests. Auf diese Weise kann gewährleistet werden, dass sich keine Fehler durch die Änderung der Software eingeschlichen haben. Ein ausführ-licher Regressionstest ist normalerweise langwierig und zäh und deshalb anfällig für mensch-liche Fehler (vgl. [DuRP00], S. 53). Aus diesem Grund sollte bei dieser Art von Tests die manuelle Prüfung durch den automatisierten Test ergänzt bzw. ersetzt werden. Der Test durchläuft automatisch jeden Schritt, der sonst manuell durchgeführt worden wäre, und verringert so den Testaufwand (vgl. [FeGr99], S. 9).

Testen der Softwarekonfigurationen

Ein weiteres Beispiel für die Vorteile, die sich durch die Wiederverwendung von automatisierten Tests ergeben, findet sich im verbesserten Testen der Softwarekonfigurationen (vgl. [DuRP00], S. 54). Durch Aktualisierungen und Implementierungen neuer Versionen können unerwartete Kompatibilitätsprobleme in der aktuellen Software entstehen. Die Ausführung automatisierter Testskripts nach Updates einer Software kann sicherstellen, dass aktuelle Anwendungen fehlerfrei funktionieren.

Ausführung einfacher Tests

Die Wiederholung von Tests mit immer gleichbleibenden Schritten führt zwangsweise zur Monotonie in der Ausführung der Arbeit. Diese wiederum hat negative Auswirkungen auf Tester, die aufgrund der monotonen Testschritte, die Testarbeit vernachlässigen könnten. Nach vielen erfolgreichen Tests besteht das Risiko, dass sie einige auslassen in der Hoffnung, dass die Software trotzdem richtig funktioniert. Auf diese Weise bleibt der ein oder andere Fehler unentdeckt (vgl. [DuRP00], S. 54). Die Verwendung der Automatisierung lohnt sich bei einfachen Tests, da ein Testskript die monotonen Schritte immer ausführt und anschließend die Ergebnisse prüft (vgl. [DuRP00], S. 55).

Durchführung von Tests, die mit manuellen Verfahren nicht möglich sind

Die immer größer werdende Komplexität von modernen Softwaresystemen stellt viele Tester vor große Herausforderungen. Die Prozesse und Testanforderungen sind teilweise so komplex, dass manuelles Testen nicht alle gewünschten Tests unterstützen kann. So lassen sich viele Arten der Testanalyse manuell nicht durchführen (vgl. [FeGr99], S. 9), weil zum Beispiel gegen die Logik der Anwendung geprüft werden soll. Dabei sollen die GUI- und API-Tests dasselbe Ergebnis liefern. Jedoch sind API-Tests manuell nicht durchführbar, weshalb eine Automatisierung unausweichlich wird.

Reproduktion von Fehlern

Wie bereits beschrieben sollen Softwaretests Fehler in der Anwendung aufdecken, damit Entwickler sie beseitigen können. Jedoch kommt es beim manuellen Testen des Öfteren vor, dass der Tester auf einen Fehler stößt, diesen aber nicht reproduzieren kann. Aus welchem Grund die Lokalisierung des Fehlers und die Ursachenfindung schwierig sind. Mit einem Testautomatisierungswerkzeug werden einzelne Schritte in einem Testskript aufgezeichnet und können anschließend mehrmals ausgeführt werden. Sollten bei der Ausführung eines Testskripts Fehler auftreten, so werden sie bei weiteren Ausführungen in Kombination mit gleichen Daten reproduzierbar auftreten.

Tests außerhalb der Arbeitszeit

Ein weiterer Vorteil der Testautomatisierung ist der variable Startzeitpunkt zur Ausführung von Testskripten. Der Tester kann um 8 Uhr morgens die auszuführenden Testskripte auswählen und den Ausführungszeitpunkt auf 10 Uhr abends legen. Am nächsten Morgen kann er die Ergebnisse im Testprotokoll durchsehen, analysieren und weitere Schritte einleiten.

[FeGr99] und [DuRP00] empfehlen die Startzeitpunkte zur Durchführung von Testskripten auf Tageszeiten zu legen, an denen wenig Auslastung am Gesamtsystem stattfindet. Diese Zeitpunkte können unter anderem der Beginn der Mittagspause oder kurz vor Feierabend sein. Dadurch können das System und die Arbeitszeit optimal genutzt werden.

2.4.2.3 Verringerung des Testaufwands und Minimierung des Zeitplans

Wie in Kapitel 2.4 erläutert wurde, führt die Testautomatisierung nicht unmittelbar zur Reduzierung des Testaufwands. Mit der Einführung eines Testautomatisierungswerkzeugs kann er aufgrund der Einrichtung und Einarbeitung sogar zunehmen. Auch die Entwicklung eines Testplans wird wegen der detaillierten Beschreibung des Testprozesses den Aufwand zunehmen lassen, durch die Wiederverwendbarkeit der Tests wird aber bereits nach wenigen Testdurchläufen ein Mehrwert sichtbar (vgl. [INET05]). „Die Verwendung eines automatisierten Testwerkzeugs kann sowohl den Testaufwand als auch den Testzeitplan reduzieren“ [DuRP00].

Die Aufwandsunterschiede zwischen dem manuellen und dem automatisierten Testen können in der Gesamtbetrachtung eines Testprozesses enorm sein. Laut [DuRP00] können mit Hilfe von Testwerkzeugen über 70% der Personenstunden, die das manuelle Testen benötigt, eingespart werden. Dabei sind die Einsparungen nicht in allen Testaktivitäten zu beobachten. Die stärkste Verringerung des Testaufwands wird in der Phase der Testausführung deutlich. Die Tätigkeiten, wie z.B. die Durchführung der Tests, die Analyse der Ergebnisse und das Erstellen von Testberichten, benötigen in der automatisierten Ausführung bis zu siebenmal weniger Arbeit. Die Unterschiede des manuellen und automatisierten Testens nach 1750 Testläufen und 700 Fehlern werden in der Tabelle 3.1 deutlich.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2Manuelles und automatisiertes Testen im Vergleich^[2] (vgl. [DuRP00], S. 58)

Erstellung eines Testplans

Die Erstellung eines Testplans ist für den gesamten Testprozess von hoher Bedeutung. Alle wichtigen Aspekte des Testprozesses müssen durchdacht werden, bevor die eigentliche Erstellung der Testskripte beginnt. Die zu testende Anwendung muss vollständig auf die Kompatibilität mit dem Testwerkzeug untersucht werden, um zu ermitteln, welche Komponenten und Prozessschritte automatisiert werden können. Weiterhin sollte ein Plan mit allen möglichen Varianten der Testfälle und der dazu benötigten Testdaten skizziert werden. Außerdem müssen Standards definiert werden, damit Skripte direkt bei der Erstellung modular und wieder-verwendbar gestaltet werden. Diese und weitere Schritte^[3] sind notwendig, damit die Test-automatisierung erfolgreich und gewinnbringend eingesetzt werden kann. Die sorgfältige und detaillierte Planung hat zur Folge, dass der Testaufwand für das automatisierte Testen wesentlich höher ist als beim manuellen Testen.

Erstellung von Testverfahren

Die manuelle Erstellung und Wartung von Testverfahren ist ein mühsamer, teurer und zeitaufwändiger Vorgang (vgl. [DuRP00], S. 59). Änderungen einer Software können zur Anpassung vorhandener Testverfahren bzw. zur Erstellung neuer Testverfahren führen. Dazu müssen zunächst die zu ändernden Testverfahren identifiziert werden, bevor im nächsten Schritt die Anpassungen der Tests geschehen können. Moderne Werkzeuge können den Tester bei diesen Tätigkeiten unterstützen. Testverfahren können mit speziellen Programmen in wenigen Schritten generiert werden (vgl. [DuRP00], S. 98). Andere Programme, wie z.B. der Business Process Change Analyzer^[4] (BPCA), erkennen Änderungen an der Software und können Informationen über den benötigten Testaufwand zur Beseitigung der Konflikte geben. Der Testaufwand bei der Erstellung von Testverfahren kann durch die Verwendung von Werkzeugen deutlich verringert werden (siehe Tabelle 3.1).

Testausführung

Wie bereits erwähnt ist die manuelle Durchführung von Tests arbeitsintensiv und fehleranfällig. Mit der Verwendung von Testautomatisierungswerkzeugen werden bei dieser Tätigkeit die größten Einsparungen an Arbeits- und Zeitaufwand sichtbar (siehe Tabelle 3.1). Im Idealfall muss der Tester die Testskripte lediglich starten und das Testwerkzeug kann unbeaufsichtigt arbeiten. Es ist sogar möglich die Tests zu einer bestimmten Zeit beginnen zu lassen (siehe Kapitel „Verbesserung der Testqualität“), um Ressourcen schonend und sinnvoll auszunutzen. Außerdem ermöglicht die Wiederwendung der Tests die Ausführung der Skripte mit gleich-bleibender Testqualität.

Analyse der Testergebnisse

Testautomatisierungswerkzeuge besitzen im Allgemeinen die Funktionalität Protokolle für durchgeführte Tests zu erstellen. Dabei werden die Ergebnisse in Form von Ampelsignalen ausgegeben, bei denen grüne Ausgaben bestanden und rote das Gegenteil bedeuten. Manche Werkzeuge geben bei fehlgeschlagener Funktionalität eine Fehlerbeschreibung aus und erzeugen Screenshots von der Fehlerstelle. Anhand dieser Informationen werden die Fehleranalyse und der Vergleich mit Originaldaten erleichtert.

Berichterstellung

Testwerkzeuge können mit den Testergebnissen und zusätzlichen Eingaben der Tester Berichte für einen maßgeschneiderten Bedarf in kurzer Zeit erstellen und den Arbeits- und Zeitaufwand stark reduzieren.

2.4.3 Testwerkzeuge

Mit der Verwendung von Testwerkzeugen kann die Qualität der Software und des Testens verbessert und zudem eine erhebliche Verringerung des Arbeits- und Zeitaufwands im Testprozess bewirkt werden. Bevor jedoch willkürlich Werkzeuge, die den Arbeitsalltag vereinfachen sollen, in das Unternehmen eingeführt werden, aber keine Verwendung finden, sollte eine ausführliche Analyse des Bedarfs durchgeführt werden, anhand deren Ergebnissen die Auswahl von geeigneten Testwerkzeugen getroffen wird. Die Entscheidung, welche Arten von Werkzeugen nutzbringend eingesetzt werden können, gehört zu den grundlegenden Überlegungen von Projekten (vgl. [HeTr09], S. 65) und sollte während der Erstellung des Testplans getroffen werden.

Laut [SpLi08], [HeTr09] und [DuRP00] werden nahezu alle Verfahrensweisen und Methoden von entsprechenden Werkzeugen unterstützt oder automatisiert. Unterschiedliche Aktivitäten oder Phasen des Testprozesses erfordern jedoch verschiedene Werkzeugarten, um die gewünschten Tätigkeiten durchführen zu können. Nur in den seltensten Fällen wird das gesamte Sortiment an Testwerkzeugen in einem Projekt benötigt. Nachfolgend werden Werkzeuge, die unter anderem bei der Durchführung der Analyse (siehe Kapitel 5) verwendet wurden, für diese Anwendungsfälle gezeigt.

Testmanagement

Testmanagementwerkzeuge, wie die Test Workbench im SAP Solution Manager (siehe Kapitel 3), ermöglichen die Planung, Durchführung und Auswertung von Tests und bilden mit ihrem breitgefächerten Leistungsumfang ein Fundament für den Testprozess. Üblicherweise werden mit einem Testmanagementwerkzeug folgende Anwendungsbereiche unterstützt.

- Verwaltung von Testfällen: Werkzeuge für das Testmanagement sollten die geordnete Ablage von manuellen und automatisierten Testfällen erlauben und unabhängig von der Testdurchführung die zentrale Speicherung der Testfälle ermöglichen (vgl. [SONS01]). Außerdem sollten eine Sortierfunktion, nach Thema oder Ausführungsreihenfolge, und Dokumentvorlagen bereitgestellt werden.
- Testplanung und -durchführung: Die Testplanung kann durch die Verwendung von Werkzeugen insofern unterstützt werden, indem erstellte Testfälle für eine bestimmte Teststufe ausgewählt und einzelnen Testern zugewiesen werden. Die Tester können die ihnen zugewiesenen Testfälle abarbeiten und dabei deren Status erfassen und den Testverlauf entsprechend dokumentieren.
- Fehlermanagement: Die während der Testdurchführung entstandenen Fehlermeldungen sollten sofort und ohne Medienbrüche erfasst werden können. Testmanagementwerkzeuge stellen hierzu die Funktionalität eines Service Desks bereit, in dem das Abbilden eines individuellen Fehlerbehebungsprozesses ermöglicht werden sollte.
- Reporting: Die durch Tester erzeugten und im Fehlermanagement erfassten Daten können für ein effektives Reporting verwendet werden, um die Datenbasis für eine Analyse zu schaffen und eine kontinuierliche Verbesserung des Testprozesses zu ermöglichen.

Änderungsanalyse

Wie das Kapitel „Notwendigkeit von Tests“ dargestellt hat, können Änderungen eines Systems, seien es z.B. Änderungen im Customizing oder das Einspielen von Support Packages, die Funktionalität von Geschäftsprozessen beeinträchtigen. Mit einem Regressionstest kann sicher-gestellt werden, dass die Änderung keine negativen Auswirkungen auf die Kernprozesse hat. Die Auswahl der dazu notwendigen Testfälle kann durch Werkzeuge der Änderungsanalyse, wie z.B. dem bereits erwähnten Business Process Change Analyzer, unterstützt werden.

Testautomatisierung

Testautomatisierungswerkzeuge, auch Testroboter genannt, wie z.B. HP QuickTest Professional (siehe Kapitel 5), ermöglichen das automatische Abspielen von Testfällen und ersetzen auf diese Weise das manuelle Testen. Die Erstellung von solchen Tests erfolgt typischerweise nach dem Capture-and-replay-Verfahren, d.h. der Testroboter erfasst bei der Testdurchführung die Eingaben, Mausklicks und Angaben des Benutzers und speichert diese als ein Testskript (vgl. [Fran07], S. 213). Ein solches Skript kann bearbeitet werden, um z.B. durch Parametrisierung unterschiedliche Testdaten abspielen zu können. Die Funktionalität moderner Werkzeuge geht noch weiter und ermöglicht mit der Programmierung von Befehlen, meist in Form von Skriptsprachen, tiefergehende Prüfanweisungen oder eine tiefergehende Ablauflogik. Hersteller-spezifische Werkzeuge, wie z.B. eCATT von SAP, bieten hier weiteren Mehrwert, indem durch Befehle der direkte Zugriff auf die Datenbank erlaubt oder die Ausführung von Skripten auf dem Applikationsserver ermöglicht wird.

3 SAP Solution Manager

Werkzeuge können den Arbeitsalltag des Anwenders wesentlich erleichtern und mehr Qualität in die Bearbeitung von Aufgaben bringen. Die in Kapitel 2.4 beschriebenen Werkzeugarten bilden nur einen Bruchteil dessen, was moderne Werkzeuge leisten können. Mit dem SAP Solution Manager bringt SAP eine Lösung auf den Markt, welche den kompletten Lebenszyklus einer Anwendung, von der Planung über den Betrieb bis zur kontinuierlichen Verbesserung, abdeckt.

In diesem Kapitel wird das Konzept des SAP Solution Managers und das Modell „Application Lifecycle Management“ (ALM) vorgestellt.Nach dessen Prinzip werden die Prozesse im SAP Solution Manager abgebildet. Weiterhin werden die Abläufe des Testmanagementprozesses im SAP Solution Manager beschrieben und abschließenddie drei Testoptionen kurz dargestellt.

3.1 Allgemeines Konzept

Der SAP Solution Manager ist die zentrale Lösung für das Application Lifecycle Management und den Betrieb von Softwarelösungen (vgl. [INET03]). Er unterstützt heterogene Systemumgebungen von der Implementierung über die Produktivsetzung und den Betrieb bis hin zur kontinuierlichen Verbesserung von Anwendungen. Mit der Kombination von Werk-zeugen und Inhalten kann die Zuverlässigkeit und Stabilität von Anwendungen erhöht und die Gesamtbetriebskosten verringert werden (vgl. [ScMe11], S. 29). Um dies zu ermöglichen, unterstützt der SAP Solution Manager den gesamten Lebenszyklus einer Anwendung, der nach dem Modell der IT Infrastructure Library (ITIL) dargestellt wird. Application Management ist ein umfassender Unterstützungsansatz in der Anwendungsumgebung, der in den folgenden Phasen den gesamten Lebenszyklus von IT-Lösungen abdeckt (siehe Abbildung 3.1):

- Anforderungen (Requirements): Sammlung der Anforderungen für neue Anwendungen
- Entwurf (Design): Umwandlung der Anforderungen in detaillierte Spezifikation
- Implementierung und Test (Build & Test): Anwendungskonfiguration und Erstellung eines Organisationsmodells gemäß den Spezifikationen
- Auslieferung (Deploy): Überführung des Betriebsmodells und der Änderungen in die bestehende produktive IT-Landschaft
- Betrieb (Operate): Bereitstellung der IT-Services, die für den fortlaufenden Betrieb erforderlich sind
- Optimierung (Optimize): Analyse der Erfüllung von Service-Levels und gegebenenfalls Start von Aktivitäten, um die Ergebnisse zu verbessern

[...]

---

^[1] Das Buch „SAP-Lösungen testen“ gibt im Kapitel Testmethodik eine genaue Beschreibung zum Vorgehensmodell im SAP-Umfeld.

^[2] Die hier dargestellten Werte sind einer geleisteten Forschungsarbeit der Firma imbus GmbH entnommen. Dabei führte das Unternehmen in Zusammenarbeit mit dem European Systems and Software Initiative (ESSI) der Europäischen Kommission ein Experiment zur Prozessverbesserung durch automatisiertes Testen grafischer Benutzerschnittstellen durch.

^[3] Eine detaillierte Beschreibung zur Erstellung eines Testplans ist im Kapitel 6 des Buches „Software automatisch testen“ gegeben.

^[4] In Kapitel 7 des Buches „SAP Solution Manager“ wird der Business Process Change Analyzer ausführlich beschrieben.