UNIT-Testing im Bereich der SAP Anwendungsentwicklung
Werbung
UNIT-Testing im Bereich der SAP Anwendungsentwicklung Bachelorarbeit zur Erlangung des akademischen Grades „Bachelor of Science in Informatik“ im Rahmen des Bachelorstudiums Informatik vorgelegt von: Patrick Deutsch betreut von: Priv.-Doz. Dipl.-Ing. Mag. Dr. Michael Felderer am Institut für Informatik an der Leopold-Franzens-Universität Innsbruck Innsbruck, im November 2016 Abstract Kundenspezifische Anpassungen von ERP Systemen sind anfällig für kostspielige Systemfehler, was das Testen dieser Modifikationen unerlässlich macht. Das Konzept der Unit-Tests stellt hierbei eine Möglichkeit dar, bestimmte Fehler bereits sehr früh zu identifizieren und somit zu verhindern. In Kooperation mit der Firma Swarovski, welche das marktführende ERP System SAP im Einsatz hat, soll das Potenzial sowie die Verbreitung von Unit-Tests in ERP Systemen ermittelt werden. Darüber hinaus sollen die Gründe für den derzeitigen Nicht-Einsatz von Unit-Tests bei Swarovski eruiert werden. Zur Klärung dieser Fragen wurde eine Umfrage zum Thema ERP Testing ausgewertet, sowie eine weitere Umfrage bei der Firma Swarovski durchgeführt. Außerdem wurden Beispielimplementierungen in verschiedenen Bereichen des Systems erstellt, um die Funktionsweise von ABAP Unit zu untersuchen. Weiters wurden die Programmabbrüche am System von Swarovski auf die Vermeidbarkeit durch Unit-Testing untersucht. Die ERP Testing Umfrage ergab, dass Unit-Tests bei der Anpassung von ERP Systemen nicht sehr weit verbreitet sind. Bei der Mitarbeiterbefragung wurden als Hauptgründe für diesen Umstand Zeitmangel, Budgetknappheit sowie fehlendes Wissen über das Prinzip genannt. Insgesamt konnten 90 % aller untersuchten Quellcodeobjekte durch Unit-Tests getestet werden, der Aufwand dafür war jedoch bei objektorientierten Objekten wesentlich geringer als bei prozeduralen. Knapp die Hälfte aller Programmabbrüche hätte durch entsprechende UnitTests vermieden werden können. Das Erstellen von Unit-Tests stellt einen beträchtlichen Aufwand dar und es muss sichergestellt werden, dass die Testkosten die Fehlerkosten nicht übersteigen. Daher empfiehlt es sich, nur jene Geschäftsprozesse mit einer hohen Risikobewertung für Unit-Tests in Betracht zu ziehen. Eine Risikoanalyse kann zur Identifikation dieser Geschäftsprozesse verwendet werden. I Inhaltsverzeichnis 1 EINLEITUNG ......................................................................................................................... 1 1.1 Thema und Motivation ........................................................................................................................ 1 1.2 Problemstellung .................................................................................................................................. 1 1.3 Zielsetzung........................................................................................................................................... 2 1.4 Struktur der Arbeit .............................................................................................................................. 2 2 GRUNDLAGEN DES SOFTWARE TESTENS .............................................................................. 3 2.1 Was ist Software Testen? .................................................................................................................... 3 2.2 Testklassifikation ................................................................................................................................. 4 2.3 Was ist Unit-Testing? ........................................................................................................................... 6 2.3.1 Aufbau von Unit-Tests ........................................................................................................................... 8 2.4 Testgetriebene Entwicklung................................................................................................................. 8 2.4.1 Testgetriebener Entwicklungszyklus.................................................................................................... 10 2.5 ABAP Unit .......................................................................................................................................... 10 2.6 Testen in ERP Systemen ..................................................................................................................... 12 2.7 ERP bei der Firma Swarovski .............................................................................................................. 13 2.7.1 Systemlandschaft................................................................................................................................. 13 2.7.2 Entwicklungs- und Testorganisation .................................................................................................... 14 3 METHODEN........................................................................................................................ 15 3.1 Datenerhebung und -analyse ............................................................................................................. 15 3.1.1 ERP-Testing Umfrage ........................................................................................................................... 15 3.1.2 Umfrage bei Swarovski ........................................................................................................................ 16 3.1.3 Analyse der Programmabbrüche ......................................................................................................... 16 3.1.4 Objektklassifikation ............................................................................................................................. 16 3.2 Realisierung ....................................................................................................................................... 17 3.2.1 Implementierung von Unit-Tests ......................................................................................................... 17 3.2.2 Risikoanalyse ....................................................................................................................................... 18 4 ERGEBNISSE ....................................................................................................................... 19 4.1 Datenerhebung und -analyse ............................................................................................................. 19 4.1.1 ERP-Testing Umfrage ........................................................................................................................... 19 4.1.2 Umfrage bei Swarovski ........................................................................................................................ 22 4.1.3 Analyse der Programmabbrüche ......................................................................................................... 24 4.1.4 Objektklassifikation ............................................................................................................................. 26 II 4.2 Realisierung ....................................................................................................................................... 26 4.2.1 Implementierung von Unit-Tests ......................................................................................................... 26 4.2.2 Risikoanalyse ....................................................................................................................................... 29 4.3 5 Zusammenfassung ............................................................................................................................. 31 DISKUSSION ....................................................................................................................... 32 5.1 Datenerhebung und -analyse ............................................................................................................. 32 5.1.1 ERP-Testing Umfrage ........................................................................................................................... 32 5.1.2 Umfrage bei Swarovski ........................................................................................................................ 32 5.1.3 Analyse der Programmabbrüche ......................................................................................................... 33 5.1.4 Objektklassifikation ............................................................................................................................. 34 5.1.5 Zusammenfassung ............................................................................................................................... 35 5.2 Realisierung ....................................................................................................................................... 36 5.2.1 Implementierung von Unit-Tests ......................................................................................................... 36 5.2.2 Risikoanalyse ....................................................................................................................................... 37 5.2.3 Teststrategie bei Swarovski ................................................................................................................. 38 5.2.4 Zusammenfassung ............................................................................................................................... 38 6 DANKSAGUNG.................................................................................................................... 40 7 LITERATURVERZEICHNIS ..................................................................................................... 41 8 ANHANG ............................................................................................................................ 43 8.1 Umfrage: SAP UNIT – Testing bei Swarovski ...................................................................................... 43 8.2 Detailliste der Programmabbrüche .................................................................................................... 50 8.3 Abbildungsverzeichnis ....................................................................................................................... 52 8.4 Tabellenverzeichnis ........................................................................................................................... 53 III Einleitung Patrick Deutsch 1 Einleitung 1.1 Thema und Motivation Enterprise Resource Planning (ERP) Systeme bilden sämtliche Geschäftsprozesse einer Organisation in einem einzigen IT-System ab [1]. Da diese Systeme bei ihrer Einführung in einem Unternehmen die bereits bestehenden Prozesse meist nicht vollständig widerspiegeln, werden sie oft durch den Kunden angepasst. Da Fehler in diesen Systemen zu erheblichen Kosten für die jeweiligen Unternehmen führen können, ist das Testen dieser Anpassungen vor ihrer Freigabe essenziell. Für diese Tests stehen meist eigens dafür konzipierte Testsysteme zur Verfügung. Die Durchführung der Tests kann entweder manuell erfolgen oder automatisiert durch spezielle Frameworks durchgeführt werden. Der Hauptvorteil von Testautomatisierung liegt darin, dass die Tests nach ihrer Erstellung wiederholt ohne großen Aufwand ausgeführt werden können. Die Kosten für Softwarefehler erhöhen sich mit jeder Entwicklungsstufe in der sie unentdeckt bleiben. Unit-Testing Frameworks bieten eine Möglichkeit, Softwarequalitätssicherung in einer sehr frühen Entwicklungsphase durchzuführen. Diese Bachelorarbeit wird in Kooperation mit der Firma Swarovski erstellt. Diese verwendet das ERP System der Firma SAP, welches mit einem Marktanteil von 24 % Marktführer im ERP Bereich ist [2]. Bei der Firma Swarovski werden derzeit keine Unit-Tests im SAP Bereich erstellt. Ziel der Arbeit ist es, die Gründe für diesen Umstand herauszufinden, sowie das Potenzial für den Einsatz von Unit-Tests zu ermitteln. Darüber hinaus soll die Verbreitung von Unit-Tests in den ERP Systemen anderer Unternehmen untersucht werden. Hier wird der Fokus speziell auf Unternehmen gelegt, welche wie die Firma Swarovski SAP als ERP System verwendet. 1.2 Problemstellung Die Probleme und Schwierigkeiten dieser Arbeit liegen hauptsächlich darin, jene Bereiche im SAP ERP System der Firma Swarovski zu ermitteln, welche sich für den Einsatz von UnitTests eignen. Dafür muss der bestehende kundenspezifische Quellcode im System analysiert werden. Da das Designen und Erstellen von Unit-Tests einen beträchtlichen Aufwand darstellt, sollten vor deren Einsatz jene Geschäftsprozesse ermittelt werden, welche überhaupt dafür in Frage kommen. Ein weiteres Problem besteht darin, zu analysieren warum bei der Firma Swarovski derzeit bei der Implementierung von kundenspezifischem Code im ERP System keine Unit-Tests erstellt werden. Die technischen Mittel dazu stehen bereits seit Längerem zur Verfügung, werden aber derzeit nicht genutzt. 1 Einleitung Patrick Deutsch 1.3 Zielsetzung Das primäre Ziel dieser Arbeit liegt in der Identifikation von Geschäftsprozessen und Technologien bei denen der Einsatz von automatisierten Unit-Tests zur Verbesserung der Qualität von kundenspezifischem Software-Code in der SAP Anwendungsentwicklung beitragen kann. Dafür werden Beispielimplementierungen von Unit-Tests im SAP ERP System der Firma Swarovski erstellt, um die Funktionsweise und Möglichkeiten des integrierten UnitTesting-Frameworks ABAP Unit herauszuarbeiten. Darauf aufbauend erfolgt eine Empfehlung für die Integration von spezifischen Unit-Tests in die Teststrategie der Firma Swarovski. Weiters soll durch eine interne Mitarbeiterbefragung herausgefunden werden, warum derzeit keine Unit-Tests im SAP Umfeld eingesetzt werden. Außerdem soll ermittelt werden, wie weit verbreitet Unit-Testing generell bei der Anpassung von ERP Systemen ist. 1.4 Struktur der Arbeit Die vorliegende Arbeit gliedert sich in 5 große Kapitel. Nachdem in der Einleitung die Probleme und Ziele definiert wurden, befasst sich das 2. Kapitel mit den Grundlagen des Software Testens sowie mit dem ERP System der Firma Swarovski. Im 3. Kapitel werden die Vorgehensweise sowie die Methoden zur Erreichung der definierten Ziele beschrieben. In Anschluss werden die erzielten Ergebnisse dargestellt bevor diese im 5. Kapitel hinsichtlich verschiedener Aspekte diskutiert werden. Die Methoden, Ergebnisse und die Diskussion gliedern sich dabei jeweils in einen Analyse- sowie einen Implementierungsteil. 2 Grundlagen des Software Testens Patrick Deutsch 2 Grundlagen des Software Testens 2.1 Was ist Software Testen? „Software Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden“[3]. Software Testen zählt zu den Maßnahmen der Analytischen Qualitätssicherung. Im Gegensatz zur Statischen Qualitätssicherung liegt hier der Fokus darauf, Fehler welche bereits im Programmcode enthalten sind, zu entdecken. Bei der Statischen Qualitätssicherung geht es darum, Maßnahmen zu definieren um Fehler bereits vor der Entstehung zu vermeiden. [4] Abbildung 2.1: Gliederung der Software Qualitätssicherung [4] Warum Software Testen wichtig ist, zeigt eine Untersuchung der LOT Consulting GmbH aus Karlsruhe zum Thema Kosten durch Softwarefehler aus dem Jahr 2001. In dieser Untersuchung wird der geschätzte Verlust in deutschen Mittelstands- und Großunternehmen mit 84,4 Mrd. EUR pro Jahr angegeben. Die Kosten für die Beseitigung von Programmfehlern belaufen sich auf ein Drittel des gesamten IT-Budgets von Unternehmen in Deutschland. [5] Die Testkosten für IT-Projekte nehmen ständig zu. Noch Ende der 1980er Jahre veranschlagten Projektleiter maximal 25 % des Gesamtbudgets für Testkosten. Die Komplexität von Software nimmt immer weiter zu, und somit machen heute die Testkosten oft mehr als 50 % der Gesamtprojektkosten aus. [6] 3 Grundlagen des Software Testens Patrick Deutsch 2.2 Testklassifikation Softwaretests lassen sich anhand ihrer Merkmale in verschiedene Klassen einteilen [4, 7]: Prüfmethodik: Nach welchen Methoden und Techniken werden Testfälle konstruiert? - Black-Box Tests: die innere Struktur der Software bleibt beim Test unberücksichtigt. Die Testfälle werden ausschließlich aus der Spezifikation abgeleitet. Für die Testfallkonstruktion wird nur das Ein- und Ausgabeverhalten berücksichtigt. Bekannte Konstruktionsverfahren sind beispielsweise Äquivalenzklassenbildung, Grenzwertanalyse und Paarweises Testen. - White-Box-Tests: orientieren sich am Quellcode des Testobjektes. Daher werden diese Testverfahren auch als codebasierte Testverfahren bezeichnet. Das Ziel bei WhiteBox-Tests ist es, möglichst viele Anweisungen in einem Testobjekt zur Ausführung zu bringen. Als Grundlage für diese Testverfahren wird vor der Testfallerstellung der sogenannte Kontrollflussgraph eines Testobjektes abgeleitet. Jeder Knoten in diesem gerichteten Graph entsprich einer Anweisung im Programm, jede Kante einem möglichen Kontrollfluss [8]. Anhand vom erstellten Graphen lassen sich verschiedene Testfallentwurfsmethoden konstruieren: Abbildung 2.2: Kontrollflussgraph für das Zählen von Zeichen Anweisungsüberdeckung: hier werden die einzelnen Anweisungen (Knoten im Kontrollflussgraphen) herangezogen. Um eine vollständige Anweisungsüberdeckung zu erzielen, muss jede Anweisung mindestens 4 Grundlagen des Software Testens Patrick Deutsch einmal in einem Testfall ausgeführt werden. Dieses Testverfahren ist das schwächste aller Überdeckungstestverfahren und ist somit als Teilmenge in allen anderen Verfahren enthalten. - Zweigüberdeckung: da bei diesem Testverfahren die Kanten im Kontrollflussgraphen betrachtet werden, muss für eine vollständige Zweigüberdeckung jede Kante im Kontrollflussgraphen einmal durchlaufen werden. Pfadüberdeckung: diese Testtechnik ist wesentlich mächtiger als die vorher genannten, hat aber in der Praxis aufgrund der hohen Komplexität nur wenig Bedeutung. Um eine vollständige Pfadüberdeckung zu erreichen, müsste jeder mögliche Pfad im Kontrollflussgraphen durchlaufen werden. Vor allem wenn Schleifen in einem Programm vorhanden sind, ist dies nur theoretisch realisierbar, da eine extrem hohe Anzahl an möglichen Pfaden entsteht. Bedingungsüberdeckung: kann als eine Erweiterung der Zweigüberdeckung angesehen werden. Der Unterschied besteht darin, dass die Zweigüberdeckung nur den Ergebniswert einer gesamten Bedingung berücksichtigt, da diese für die Verzweigung im Kontrollflussgraphen relevant sind. Die Bedingungsüberdeckung zieht jedoch zusätzlich noch die einzelnen Teilbedingungen zur Testfallkonstruktion heran. Gray-Box-Tests: dies stellt eine Kombination aus Black-Box-Tests und White-BoxTests dar. Grundsätzlich werden die Testfälle ähnlich wie Black-Box-Tests erstellt. Dem Tester ist allerdings die interne Programmstruktur des Testobjektes bekannt und er lässt dieses Wissen in die Konstruktion der Testfälle einfließen. Prüfkriterium: Gliederung nach den inhaltlichen Aspekten der Testfälle. - Funktionale Tests: es wird überprüft, ob ein Software System bei einer vorgegebenen Belegung von Eingabewerten, die korrekten Ausgabewerte berechnet. Funktionale Anforderungen spezifizieren „was“ das System erbringen soll. Funktionale Merkmale sind Richtigkeit, Interoperabilität, Sicherheit, Ordnungsmäßigkeit und Angemessenheit. Zu dieser Gruppe von Tests zählen unter anderem Funktionstests, Kompatibilitätstests, Zufallstests, Crashtests und Trivialtests. - Nicht-Funktionale Tests: bei dieser Testart werden Attribute des funktionalen Verhaltens überprüft, also in welcher Qualität – „wie gut“ – ein System funktioniert. Die Umsetzung nicht funktionaler Anforderungen beeinflusst oft die Zufriedenheit des Kunden mit einem Softwareprodukt. Nicht funktionale Merkmale sind Zuverlässigkeit, Effizienz und Benutzbarkeit. Lasttests, Stresstests, Performanztests und Massentests sind Vertreter dieser Testart. Prüfebene: Gliederung der Tests in die verschiedenen Entwicklungsphasen. Die Tests werden in vier Klassen unterteilt: - Unit-Tests: die erste Teststufe, in der kleine Programmteile unabhängig von anderen Programmteilen getestet werden. 5 Grundlagen des Software Testens Patrick Deutsch - Integrationstests: jene Teststufe in welcher das Zusammenspiel einzelner Komponenten getestet wird. Ziel des Integrationstests ist es, Fehlerzustände in Schnittstellen verschiedener Komponenten zu finden. Jede Komponente für sich wurde isoliert bereits getestet. - Systemtests: in dieser Teststufe wird das System zum ersten Mal als Ganzes getestet. Es wird überprüft, ob die vom Kunden spezifizierten Anforderungen an das Produkt erfüllt sind. - Abnahmetests: im Gegensatz zu den vorherigen Teststufen, liegt der Abnahmetest nicht mehr im Verantwortungsbereich des Herstellers, sondern des Kunden. Dieser Test wird bereits in der Einsatzumgebung des Kunden und mit authentischen Daten ausgeführt. Abbildung 2.3: Einteilung der Teststufen nach Prüfebene [4] Je später Softwarefehler entdeckt werden, umso höher sind die entsprechenden Fehlerkorrekturkosten. Abbildung 2.4: Fehlerkorrekturkosten nach Entdeckungszeitpunkt [9] 2.3 Was ist Unit-Testing? Bei Unit-Tests, oft auch Modul- oder Komponententests genannt, werden atomare Programmeinheiten getestet, welche groß genug sind um eigenständig getestet zu werden. Bei den einzelnen Units kann es sich um Klassen, Funktionen, Module, Pakete oder sogar um 6 Grundlagen des Software Testens Patrick Deutsch ganze Bibliotheken handeln. Unit-Tests werden zu den White-Box-Tests gezählt. Dies bedeutet, dass sie sich am zu testenden Quellcode orientieren [4], weshalb sie meist von Mitgliedern des Entwicklungsteams erstellt werden [10]. Das Konzept des Unit-Testings wurde in den 1970er Jahren entwickelt und stellt eine der besten Möglichkeiten zur Verbesserung der Code Qualität dar. Zum ersten Mal eingesetzt wurde das Konzept von Kent Beck in der Programmiersprache Smalltalk. Ab diesem Zeitpunkt wurde es zu einer gängigen Praxis in der Softwareentwicklung [11]. Die Implementierung dieses Frameworks nannte Beck SUnit. Sie diente als Grundlage für das xUnit Framework, welches eine Sammlung von Unit-Testing Architekturen verschiedener Programmiersprachen darstellt [12]. Tabelle 2.1 beinhaltet eine Auflistung verschiedener Programmiersprachen mit den dazugehörigen Unit-Testing Frameworks welche auf der xUnit-Architektur basieren. Tabelle 2.1: xUnit-Implementierungen verschiedener Programmiersprachen [5] xUnit-Derivate ABAP Objects Unit ABAP Unit CppUnit CsUnit JUnit Nunit PHPUnit Runit SUnit Test::Unit TestNG VbUnit VB Lite Unit Programmiersprache ABAP ab Release 6.10 ABAP ab Release 6.40 C++ C# Java .NET-Plattform PHP Ruby Smalltalk Ruby Java Visual Basic 6.0 Visual Basic (VB) und Visual Basic for Application (VBA) Eigenschaften eines „guten“ UNIT-Tests [11]: 1. 2. 3. 4. 5. 6. automatisiert und wiederholt ausführbar einfach zu implementieren einmal geschrieben, ist der Test auch morgen noch relevant jeder sollte in der Lage sein, den Test schnell und einfach laufen zu lassen kurze Ausführungszeit die Resultate sind konsistent (wenn zwischen den Testläufen am Programmcode nichts geändert wird, geben die Tests immer denselben Wert zurück) 7. der Test besitzt die volle Kontrolle über die getestete Unit 8. komplett isoliert von anderen Tests 9. sollte der Test fehlschlagen, ist einfach zu erkennen was erwartet wurde und wie das Problem lokalisiert werden kann 7 Grundlagen des Software Testens Patrick Deutsch 2.3.1 Aufbau von Unit-Tests In der Regel werden alle Unit-Tests in drei Phasen gegliedert [13]: - Ausgangszustand herstellen zu testende Operation ausführen Vergleich von Ist- und Sollwert (mittels Assertions) Das Ergebnis eines Unit-Tests wird in eine der folgenden drei Kategorien eingeteilt [4]: Success: Ist-Wert und Soll-Wert stimmen überein, somit wurde der Test erfolgreich durchlaufen. Error: Der Testfall konnte ohne Probleme durchlaufen werden, der Ist-Wert weicht allerdings vom Soll-Wert ab. Failure: Bei der Testausführung ist ein Systemfehler aufgetreten. Dies kann zB durch einen Programmabsturz im zu testenden System verursacht worden sein. In diesem Fall ist die Berechnung eines Ist-Wertes für den Vergleich nicht möglich. 2.4 Testgetriebene Entwicklung Testgetriebene Entwicklung (engl. Testdriven Development – TDD) ist eine qualitätsbewusste Programmiertechnik, mit der Programme in kleinen Schritten entwickelt werden können. Vom Entwickler werden automatisierbare Unit-Tests geschrieben, welche ein Programm in kleinen unabhängigen Einheiten überprüfen. Die Idee des testgetriebenen Ansatzes in der Softwareentwicklung besteht darin, zuerst den Testcode und erst im Anschluss den eigentlichen Programmcode zu schreiben. Für jede Änderung am Programmcode wird zuerst ein Test geschrieben, welcher vorerst fehlschlägt. da die entsprechende Funktionalität im Programm noch nicht vorhanden ist. Da zuerst der Test entwickelt und geschrieben wird, wird sichergestellt, dass auch wirklich das programmiert wird, was programmiert werden soll. Ein weiterer Vorteil der Testgetriebenen Entwicklung besteht darin, dass auf jeden Fall testbarer Code erstellt wird, da der Test ja bereits geschrieben wurde. [14] Abbildung 2.5 sowie Abbildung 2.6 verdeutlichen den Unterschied der traditionellen Softwareentwicklung zur Testgetriebenen Softwareentwicklung. 8 Grundlagen des Software Testens Abbildung 2.5: Traditioneller Entwicklungszyklus [11] Abbildung 2.6: Testgetriebener Entwicklungszyklus [11] 9 Patrick Deutsch Grundlagen des Software Testens Patrick Deutsch 2.4.1 Testgetriebener Entwicklungszyklus Der Testgetriebene Entwicklungszyklus besteht im Wesentlichen aus drei Phasen: grün rot: der Programmierzyklus beginnt damit, dass neue Anforderungen an den Code gestellt werden. Für diese Anforderung wird ein Test entwickelt, welcher fehlschlägt, da die Funktionalität noch nicht implementiert ist. rot grün: der Programmcode wird so implementiert, dass der Test auf möglichst einfache Weise erfüllt wird. grün grün: nachdem wieder alle Tests erfolgreich durchlaufen, muss der neu implementierte bzw. geänderte Programmcode überarbeitet und gut strukturiert werden. Diesen Vorgang nennt man Refactoring. Durch das neuerliche Ausführen der Tests, wird sichergestellt, dass durch diesen Schritt keine zusätzlichen Fehler in den Programmcode gekommen sind. [11, 14] Abbildung 2.7: Phasen der Testgetriebenen Entwicklung https://en.wikipedia.org/w/index.php?title=Test-driven_development&oldid=721858149 [06.11.2016] Wenn von einem Test erwartet wird, dass er fehlschlägt, dieser aber erfolgreich durchläuft, wurde entweder nicht getestet, was getestet werden sollte, oder der Test ist fehlerhaft. [11] 2.5 ABAP Unit ABAP Unit ist die durch SAP entwickelte Umsetzung des xUnit Frameworks. ABAP Unit ist seit dem Release 6.40 sowohl in die interne SAP Entwicklungsumgebung, als auch in die ABAP Erweiterung für Eclipse integriert. Die Tests können entweder direkt in das zu testende Objekt integriert werden, oder es können eigene Testprogramme angelegt werden, was zu einer Trennung von Testcode und Produktivcode führt. Für eine Implementierung der Tests in eigenen Testprogrammen spricht, 10 Grundlagen des Software Testens Patrick Deutsch dass die Testfälle in eigenen Testpaketen zusammengehalten werden können. Somit sind alle Tests im System an einer zentralen Stelle implementiert und können gut strukturiert werden, was die Übersichtlichkeit erhöht. Gegen die Trennung von Test- und Produktivcode spricht, dass diese oft eng miteinander verwoben sind. Daher könnte eine Trennung wesentlichen Mehraufwand bedeuten. Da sich die Tests an einer anderen Stelle im System befinden, kann es bei einer Änderung am Produktivcode leichter passieren, dass die Testfälle nicht angepasst werden. Außerdem bedeutet es beim Transport der Änderungen in das Test- bzw. Produktivsystem einen Mehraufwand, da nicht nur das geänderte Objekt, sondern auch das Testobjekt transportiert werden muss. Obwohl beide Methoden Vor- und Nachteile mit sich bringen, empfiehlt die SAP das Testcoding direkt in das Testobjekt zu integrieren. [12] Abbildung 2.8: Beispiel einer Testklasse in ABAP Unit ABAP Unit unterscheidet strikt zwischen Test- und Produktivcode. Testklassen haben Zugriff auf den Produktivcode, umgekehrt jedoch nicht. Im Framework integriert ist die Möglichkeit zur Messung der Code Coverage sowie die Möglichkeit zur automatisierten Testausführung. [15] Unit-Tests können für folgende Objekttypen im SAP System erstellt und ausgeführt werden: 1. 2. 3. 4. Ausführbare Programme Modulpools Funktionsgruppen Klassenpools Technisch gesehen können Unit-Tests also sowohl in prozeduralen Objekten (Programme, Modulpools und Funktionsgruppen) als auch in objektorientierter Programmierung (Klassenpools) implementiert werden. SAP empfiehlt allerdings objektorientiert zu 11 Grundlagen des Software Testens Patrick Deutsch programmieren, da dies dabei hilft die Programme gut zu strukturieren. Damit sich ein Programm für Unit-Tests eignet, sollte eine Methode genau eine Funktionalität abbilden. [12] 2.6 Testen in ERP Systemen Enterprise Resource Planning Systeme (ERPs) kapseln die gesamten Daten und Prozesse einer Organisation in einem einheitlichen System [1]. In der heutigen Zeit gehören ERP Systeme zu den wichtigsten und kritischsten Teilen des operativen Geschäfts in allen Arten von Organisationen [16]. Meist decken diese Systeme bei der Einführung jedoch nicht zu 100 Prozent die Prozesse der Unternehmen ab. Dieser Umstand führt dazu, dass die Systeme oft durch den Kunden angepasst werden müssen. Fehler bei Kundenanpassungen bzw. erweiterungen können zu sehr hohen Kosten für das Unternehmen führen [17]. Deshalb ist effektives und effizientes Testen ein wichtiger Punkt bei ERP Projekten, um zu verhindern, dass Fehler bei der Implementierung in das Produktivsystem gelangen [10]. Bei umfangreichen und kritischen ERP Projekten belaufen sich die Testkosten auf ca. 50 % der Gesamtkosten [1]. Erfolgreiches Testen beeinflusst maßgeblich den Erfolg des gesamten Projektes [10]. Eine ERP Systemlandschaft besteht in der Regel aus mindestens drei Systemen: einem Entwicklungssystem, einem Testystem und dem Produktivsystem. [18] Abbildung 2.9: ERP Systemlandschaft [18] Bezogen auf die einzelnen Teststufen kann gesagt werden, dass Unit-Tests im Entwicklungssystem geschrieben und ausgeführt werden. Alle weiteren Teststufen werden im Testsystem realisiert, da hier meist bessere Testdaten zur Verfügung stehen und das System weniger Änderungen unterzogen ist, als das Entwicklungssystem. 12 Grundlagen des Software Testens Patrick Deutsch 2.7 ERP bei der Firma Swarovski 2.7.1 Systemlandschaft Die Firma Swarovski verwendet das ERP System von SAP. Derzeit sind folgende Module dieses Systems im Einsatz: Tabelle 2.2: eingesetzte ERP Module bei Swarovski Abkürzung MM PP FI CO LO Bezeichnung Material Management Production Planning Financial Accounting Controlling Logistics Die ERP Systemlandschaft besteht insgesamt aus sechs Systemen: 1. 2. 3. 4. 5. 6. Entwicklungssystem Testsystem Schulungssystem Upgrade System Konsolidierungssystem Produktivsystem Jedes System besitzt eine eindeutige dreistellige ID welche sich folgendermaßen zusammensetzt: das einstellige Präfix bezeichnet den Typ des Systems, die darauffolgende zweistellige Zahl steht für die Systemlandschaft – „10“ für das ERP System. Weitere bei der Firma Swarovski eingesetzte Systeme von SAP sind unter anderem das Business-Warehouse System (BW) sowie das Customer-Relationship-Management System (CRM). Abbildung 2.10: ERP Systemlandschaft bei Swarovski Das einzige System, in dem Änderungen am Programmcode möglich sind, ist das Entwicklungssystem. Anschließend können die Änderungen in das Testsystem und das Schulungssystem transportiert werden. Diese beiden Systeme werden in periodischen Abständen auf den Stand des Produktivsystems gesetzt. Dies führt dazu, dass in diesen Systemen wesentlich bessere Testdaten zur Verfügung stehen als im Entwicklungssystem. Im Konsolidierungssystem wird noch einmal überprüft, ob die Integration der geänderten Objekte 13 Grundlagen des Software Testens Patrick Deutsch in den bestehenden Code wie geplant funktioniert. Ist dies der Fall können die Objekte für das Produktivsystem freigegeben werden. Im Jahr 2014 wurden ca. 12.000 Anpassungen am System vorgenommen, wovon ca. 1.100 Änderungen am Programmcode zur Folge hatten. Systemupgrades durch die SAP werden als erstes in das Upgrade System integriert. Dies hat den Vorteil, dass die Auswirkungen des Upgrades ersichtlich sind und getestet werden können, ohne den laufenden Entwicklungsprozess zu stören. 2.7.2 Entwicklungs- und Testorganisation Zurzeit sind bei der Firma Swarovski ca. 20 Softwareentwickler und ca. 120 Business Consultants im Bereich SAP beschäftigt. Die Organisation der Business Consultants orientiert sich an den jeweiligen Modulen im SAP System. Programmänderungen zur Anpassung des Systems werden von der Entwicklungsabteilung durchgeführt. Vor der Freigabe dieser Änderungen für das Produktivsystem müssen diese noch durch mindestens einen Business Consultant getestet werden. Getestet wird sowohl ob die Anpassungen der Anforderung entsprechen und ob diese korrekt implementiert wurden. Großteils werden diese Tests in Black-Box-Testverfahren durch manuelles Ausführen der Programme durchgeführt. Zusätzlich dazu gibt es noch eine Quality Management Abteilung, welche derzeit aus einer Person besteht. Aktuell wird in dieser Abteilung eine Teststrategie für Systemupgrades inkl. automatisierter Black-Box-Tests ausgearbeitet. Außerdem gibt es in jedem Team der Business Consultants die Rolle eines SAP Test Managers. Diese sind für die Wartung des Testkataloges sowie für das Testmanagement bei Systemupgrades in ihren jeweiligen Bereichen zuständig. 14 Methoden Patrick Deutsch 3 Methoden 3.1 Datenerhebung und -analyse Mithilfe einer Umfrage zum Thema ERP Testing wurde die Verbreitung von Unit-Tests im ERP Bereich ermittelt. Um den derzeitigen Wissensstand der Mitarbeiter der Firma Swarovski im SAP Bereich über Unit-Testing zu bestimmen wurde eine weitere Umfrage erstellt und ausgewertet. Diese Umfrage sollte mögliche Gründe für den derzeitigen Nicht-Einsatz dieser Teststufe aufzeigen. Um herauszufinden inwieweit Unit-Tests zur Qualitätsverbesserung beitragen können, wurden die Programmabbrüche im Produktivsystem der Firma Swarovski dahingehend analysiert. Dadurch soll ermittelt werden, wie viele dieser Fehler durch Unit-Testing vermieden werden hätten können. Weiters wurde eine Klassifizierung der derzeit im System vorhandenen Objekte in die einzelnen Objektkategorien durchgeführt, da diese für die Verwendung von ABAP Unit hinsichtlich Usability und Aufwand der Testerstellung relevant sind. Alle vorliegenden Daten und Ergebnisse beziehen sich auf das SAP ERP System in der Version 7.40 der Firma Swarovski. Alle Auswertungen beziehen sich rein auf den Kundenerweiterungsraum (Z-Coding). Es kann davon ausgegangen werden, dass der nicht erweiterte Standardcode im System bereits vom Hersteller SAP getestet wurde. 3.1.1 ERP-Testing Umfrage Die Universität Innsbruck hat im Jahr 2013 eine Online-Umfrage zum Thema Testen in ERP Projekten durchgeführt. Teilgenommen an dieser Umfrage haben insgesamt 299 Personen von denen 97 die Umfrage vollständig und 202 teilweise ausgefüllt haben. Ziel der Umfrage war es den „State of the Art“ beim Testen in ERP Projekten zu erheben. Die Umfrage beinhaltete insgesamt 114 Fragen, welche in folgende 13 Gruppen eingeteilt waren: 1. Allgemeines zum Unternehmen 2. ERP Basisinformationen 3. Herausforderungen beim Testen in ERP Projekten 4. Vorgehensmodell 5. Testorganisation 6. Risikomanagement 7. Maßnahmen zur Qualitätssicherung 8. Testmanagement 9. Testverfahren 10. Testarchitektur 11. Testwerkzeuge 12. Auswertung und Bericht 15 Methoden Patrick Deutsch 3.1.2 Umfrage bei Swarovski Um herauszufinden warum derzeit bei der Firma Swarovski keine Unit-Tests implementiert werden, wurde eine interne Umfrage durchgeführt. Diese richtete sich gleichermaßen an Entwickler und Consultants. Die Umfrage umfasste sowohl Fragen zum Wissensstand über Unit-Testing im Allgemeinen sowie zur Qualitätseinschätzung bezüglich der selbst implementierten/betreuten Programme. Die Umfrage wurde mittels der Online Plattform www.umfrageonline.com erstellt, versendet und ausgewertet. Insgesamt wurden 34 Personen befragt, 25 nahmen daran teil und füllten die Umfrage vollständig aus. Die Teilnahme war vom 11.08.2016 bis 26.09.2016 möglich. 3.1.3 Analyse der Programmabbrüche Es wurde eine Auswertung aller Programmabbrüche im Zeitraum von April 2015 bis Juni 2015 durchgeführt. Hierdurch konnten folgende Parameter abgeleitet werden: Programmabbrüche pro Fehler, Fehler pro Modul, die 30 fehleranfälligsten Programme, die 30 häufigsten Programmierfehler sowie die betroffenen Z-Programme. Diese Daten wurden dahingehend analysiert, welche dieser Programmabbrüche durch UnitTests vermieden werden hätten können. Damit dies auf einen Programmabbruch zutrifft, ist es notwendig einen geeigneten Unit-Testfall zu erstellen, welcher das Fehlverhalten des Programmes erkennt. Ist die Erstellung eines derartigen Testfalles nicht möglich, wäre der Programmabbruch durch Unit-Tests nicht vermeidbar gewesen. 3.1.4 Objektklassifikation In einem Zeitintervall von einer Woche wurde aus dem SAP Produktivsystem die Aufrufstatistik der einzelnen Verarbeitungsblöcke extrahiert. Anschließend wurden die Verarbeitungsblöcke in die folgenden Kategorien eingeteilt: 1. 2. 3. 4. Methoden Funktionsbausteine Form-Routinen Sonstige Objekte Für jede Kategorie wurde die Anzahl der Objekte sowie die Häufigkeit der Aufrufe ermittelt. Die verschiedenen Objektkategorien sind unterschiedlich in das Unit-Test Framework ABAP Unit integriert. Dies bedeutet, dass sich die Vorgehensweise für die Erstellung von Unit-Tests zwischen den Kategorien teilweise erheblich voneinander unterscheidet. 16 Methoden Patrick Deutsch 3.2 Realisierung Zur Erstellung der Testfälle wurde das im SAP integrierte ABAP Unit Framework verwendet. Als IDE (Integrated Development Environment) wurde Eclipse in der Version 4.6 (Neon) verwendet. 3.2.1 Implementierung von Unit-Tests Um beurteilen zu können in welchen Bereichen des Systems Unit-Tests sinnvoll zur Anwendung kommen könnten, wurden Tests in verschiedenen Technologien (Objektorientierte Programmierung, Prozedurale Programmierung, User-Exits, Badis, usw.) erstellt. Wo es möglich war, wurden die Testfälle direkt in die zu testenden Objekte integriert, wie es von SAP empfohlen wird. Teilweise waren aufwändige Vorarbeiten nötig um die Objekte entsprechend testbar zu machen. Um nicht in den laufenden Systembetrieb einzugreifen, wurden die Testfälle nicht in den Originalobjekten, sondern in zuvor erstellten Kopien implementiert. In jedem Testobjekt waren mehrere Datenbankzugriffe implementiert, daher wurde für jedes Objekt ein Data Access Object erstellt, in welches die Datenbankzugriffe ausgelagert wurden. Testklassen Testklassen sind lokale Klassen, welche bei der Definition den Zusatz „FOR TESTING“ erhalten. Die einzelnen Testmethoden erhalten ebenfalls den Zusatz „FOR TESTING“. Sie sind parameterlose Instanzmethoden. Eine Testmethode entspricht einem Testfall. Um die Handhabung von Testklassen für die verschiedenen Objekttypen zu untersuchen, wurden sowohl für ausführbare Programme, Modulpools, Funktionsgruppen als auch Klassenpools exemplarisch Testklassen mit den dazugehörigen Testmethoden angelegt und ausgeführt. Weiters wurde die Testüberdeckung der getesteten Objekte gemessen (Anweisungsüberdeckung, Bedingungsüberdeckung und Prozedurüberdeckung). Testautomatisierung Zur Automatisierung von Unit-Tests wird der im System integrierte Code Inspector [19] verwendet. Es werden sogenannte Prüfvarianten angelegt, welche die zu testende Objektmenge definieren. 17 Methoden Patrick Deutsch 3.2.2 Risikoanalyse Bei Swarovski wird für jeden Geschäftsprozess eine Risikobewertung durchgeführt. Das Risiko jedes Prozesses errechnet sich daraus, wie häufig dieser Prozess durchlaufen wird und wie hoch die Kosten bei einem Fehler im Prozess sind. Die Fehlerkosten setzen sich folgendermaßen zusammen [7]: - - Fehlerkorrekturkosten: jene Kosten, die für die Behebung des Fehlers anfallen, zB Analyse und Korrektur, erneuter Testaufwand sowie die Kosten für die erneute Auslieferung des Produkts. direkte Fehlerkosten: Kosten welche beim Kunden durch den Fehler entstehen, für die aber der Hersteller haften muss. indirekte Fehlerkosten: hier handelt es sich um jene Kosten bzw. Umsatzverlust, welche dadurch entstehen, weil der Kunde mit dem Produkt unzufrieden ist. Der verursachte Imageschaden zählt ebenfalls zu den indirekten Fehlerkosten. Gemeinsam mit einem Vertreter der SAP QM Abteilung von Swarovski wurde die aktuelle Risikobewertung analysiert und ein Pareto Diagramm erstellt. 18 Ergebnisse Patrick Deutsch 4 Ergebnisse 4.1 Datenerhebung und -analyse 4.1.1 ERP-Testing Umfrage Die Teilnehmer der durchgeführten Umfrage wurden wie folgt klassifiziert: Tabelle 4.1: Personenklassifizierung der ERP-Testing Umfrage Gruppe ERP-Anwender ERP-Hersteller ERP-Vertriebs- und/oder Implementierungspartner keine Antwort Summe Anzahl 175 34 42 48 299 Prozent 58,53% 11,37% 14,05% 16,05% 100,00% Als größte Gruppe wurden die ERP-Anwender mit 58,53 % identifiziert. Mit 25,42 % bilden die ERP-Hersteller zusammen mit den ERP-Vertriebs- oder Implementierungspartnern den kleineren Teil. Auffallend war jedoch, dass der zweitgrößte Teil der befragten Personen sich zu keiner der vorhandenen Gruppen zählte bzw. sich nicht dazu äußern wollte. Die Umfrage zeigte außerdem, dass derzeit folgende Teststufen bei den befragten Unternehmen in ERP Projekten realisiert sind: Tabelle 4.2: Teststufen in der ERP Umfrage Teststufe Unit-/Modul-/Klassen-/Komponententest Integrationstest Systemtest Abnahmetest keine Angabe Sonstiges Summe Anzahl 29 60 46 62 8 4 209 Prozent 9,70% 20,07% 15,38% 20,74% 2,68% 1,34% 69,91% Abnahme- und Integrationstests sind jene Teststufen, welche bei ERP Projekten am häufigsten eingesetzt werden. Jeweils mehr als 20 % gaben an, diese Tests in ihren Projekten durchzuführen. Weniger als 10 % haben hingegen die Ebene der Unit-/Modul-/Klassen/Komponententests in ERP Projekten im Einsatz. Die eingesetzten ERP Systeme der befragten Unternehmen sind in Tabelle 4.3 dargestellt: 19 Ergebnisse Patrick Deutsch Tabelle 4.3: ERP System Verteilung ERP-System SAP Eigen-/Individualentwicklung Sonstiges Microsoft NAV BMD Comarch ERP Enterprise Microsoft AX Mesonic Orlando proalpha Lawson M3 abas ERP Aplus Comarch Suite Infor LN PSIpenta eNVenta ERP IFS Applications Infor AS Jet Orbit RS2 keine Antwort Summe Anzahl 59 31 27 21 12 10 9 7 5 5 4 3 3 3 3 3 1 1 1 1 1 89 299 Prozent 19,73% 10,37% 9,03% 7,02% 4,01% 3,34% 3,01% 2,34% 1,67% 1,67% 1,34% 1,00% 1,00% 1,00% 1,00% 1,00% 0,33% 0,33% 0,33% 0,33% 0,33% 29,77% 100,00% Mit 19,73 % ist SAP das führende ERP System unter den Umfrageteilnehmern. Am zweithäufigsten kommen Eigen-/Individualentwicklungen zum Einsatz. Interessanterweise gab der Hauptteil der Befragten keine Antwort ab. In Tabelle 4.4 ist die Verteilung der Teststufe Unit-/Modul-/Klassen-/Komponententest auf die einzelnen ERP Systeme ersichtlich. Einige der Unternehmen, welche diese Teststufe bei ihren Projekten einsetzen, gaben an, mehr als ein ERP System im Einsatz zu haben. Dieser Umstand erklärt die Differenz der 29 Unternehmen in Tabelle 4.2 und der in Summe 34 ERP Systemen in Tabelle 4.4. 20 Ergebnisse Patrick Deutsch Tabelle 4.4: Aufteilung von Unit-/Modul-/Klassen-/Komponententest in die jeweiligen ERP Systeme ERP-System RS2 Orlando abas ERP Comarch Suite Mesonic SAP Comarch ERP Enterprise proalpha Eigen-/Individualentwicklung Microsoft NAV BMD Summe Anzahl 1 2 1 1 2 14 2 1 6 3 1 34 Prozent 2,94% 5,88% 2,94% 2,94% 5,88% 41,18% 5,88% 2,94% 17,65% 8,82% 2,94% 100,00% Anteil im jeweiligen System 100,00% 40,00% 33,33% 33,33% 28,57% 23,73% 20,00% 20,00% 19,35% 14,29% 8,33% Absolut wird die Teststufe Unit-/Modul-/Klassen-/Komponententest bei Unternehmen mit SAP am häufigsten eingesetzt. Dies entspricht jedoch nur einem Anteil von 23,73 % der SAP einsetzenden Unternehmen. Folgende Tabelle zeigt, wie auf die Frage nach der Qualitätssicherung im jeweiligen Vorgehensmodell geantwortet wurde: Tabelle 4.5: Qualitätssicherung im jeweiligen Vorgehensmodell Antwort Reviews sind Teil jeder Iteration Unittests sind Teil jeder Iteration Integrationstests sind Teil jeder Iteration Abnahmetests sind Teil jeder Iteration Regressionstests sind Teil jeder Iteration Separate Iterationen dienen der Qualitätssicherung keine Antwort Nicht beendet oder nicht gezeigt Summe Anzahl 8 5 11 15 2 5 38 215 299 Prozent 2,68% 1,67% 3,68% 5,02% 0,67% 1,67% 12,71% 71,91% 100,00% Auffällig ist, dass in 29 Datensätzen die Frage ob in der Teststufe Unit-/Modul-/Klassen/Komponententest im ERP Umfeld getestet wird, mit ja beantwortet wurde, bei der Frage zur Qualitätssicherung im jeweiligen Vorgehensmodell jedoch nur 5mal „Unittests sind Teil jeder Iteration“ mit ja beantwortet wurde. Bei einem dieser 5 Datensätze wurde sogar die Frage nach der Teststufe Unit-/Modul/Klassen-/Komponententest mit nein beantwortet. 21 Ergebnisse Patrick Deutsch 4.1.2 Umfrage bei Swarovski Von den 34 befragten Personen bei Swarovski haben 25 an der Umfrage teilgenommen und diese vollständig ausgefüllt. Folgende Tabelle zeigt, wie sich diese Personen auf die einzelnen Teams verteilen: Tabelle 4.6: Teilnahme an der Mitarbeiterbefragung Berufsgruppe (inkl. Führungskräfte) Entwickler Consultant Quality Management Summe befragt 17 16 1 34 teilgenommen 13 11 1 25 teilgenommen in Prozent 52,00% 44,00% 4,00% 100,00% Insgesamt gaben 80 % der teilnehmenden Personen an, mit dem Begriff Unit-, Modul- bzw. Komponententest vertraut zu sein, wobei sich die restlichen 20 % in zwei Consultants und drei Entwickler aufschlüsseln. Abbildung 4.1: Einteilung der Personen nach Unit-Test Kenntnissen Nur 10 % dieser Teilnehmer (2 Personen) mit Unit-Test Kenntnissen, haben auch bereits selbst einen Unit-Test erstellt. Beide Personen kommen aus der Berufsgruppe der Entwickler. 22 Ergebnisse Patrick Deutsch Abbildung 4.2: Einteilung der Personen mit Unit-Test Kenntnissen gruppiert nach bereits erstellten Unit-Tests Obwohl mehr als die Hälfte der Teilnehmer mit Unit-Test Kenntnissen auch mit einem UnitTest Framework vertraut sind, hat nur eine Person auch Kenntnisse im SAP integrierten Framework ABAP Unit. Diese Person gab auch an Kenntnisse in anderen Frameworks zu haben, konnte aber weder Vor- noch Nachteile von ABAP Unit zu diesen nennen. Tabelle 4.7: Einteilung nach Unit-Test Framework Kenntnissen Unit-Test Framework Kenntnisse ABAP Unit andere Unit-Test Frameworks (zB Java) keine Unit-Test Framework Kenntnisse Summe Anzahl 1 11 9 21 Prozent 4,76% 52,38% 42,86% 100,00% Auf die Frage, mit welcher Teststrategie die geschriebenen/betreuten Programme getestet werden, wurde wie folgt geantwortet: Tabelle 4.8: Gliederung der Personen nach Testabwicklung Testabwicklung manuell automatisiert Summe Anzahl 25 4 29 Prozent 86,21% 13,79% 100,00% Von den vier Personen, welche automatisierte Testverfahren verwenden, gaben drei an, zusätzlich manuell zu testen. 23 Ergebnisse Patrick Deutsch Insgesamt gaben 56 % an, dass sie der Meinung sind, dass automatisierte Unit-Tests ihren Testaufwand reduzieren könnten. Die folgende Tabelle zeigt eine Gruppierung der Begründungen für diese Annahme: Tabelle 4.9: Gründe für reduzierten Testaufwand Begründung für reduzierten Testaufwand Zeitersparnis durch wiederholtes/automatisiertes Ausführen frühzeitige Fehlererkennung Erkennen von Side-Effects weniger Risiko Summe Anzahl 7 5 1 1 14 Prozent 50,00% 35,71% 7,14% 7,14% 100,00% Im Gegensatz dazu können die Antworten jener Personen, welche nicht der Meinung sind, dass Unit-Tests ihren Testaufwand reduzieren könnten, folgendermaßen zusammengefasst werden: Tabelle 4.10: Gründe für keinen reduzierten Testaufwand Begründung für keinen reduzierten Testaufwand mehr Aufwand für die Softwareentwickler kein Ersatz für manuelle Tests keine Antwort Summe Anzahl 5 3 1 9 Prozent 55,56% 33,33% 11,11% 100,00% Als mögliche Gründe, für den derzeitigen Nicht-Einsatz von Unit-Tests bei Swarovski, nannten die teilnehmenden Personen Zeitmangel, zu wenig Wissen über das Prinzip und Budgetknappheit. Abbildung 4.3: mögliche Gründe für den derzeitigen Nicht-Einsatz von Unit-Tests bei Swarovski 4.1.3 Analyse der Programmabbrüche Die Programmabbrüche, welche im Zeitraum von April 2015 bis Juni 2015 aufgetreten sind, können bezogen auf Unit-Testing wie folgt eingeteilt werden: 24 Ergebnisse Patrick Deutsch Tabelle 4.11: Programmabbrüche gruppiert nach Kategorie Fehlerkategorie vermeidbar durch UNIT-Tests nicht vermeidbar durch UNIT-Tests technische Fehler SQL Fehler Summe Anzahl 2471 1954 438 421 5284 Prozent 46,76% 36,98% 8,29% 7,97% 100,00% PROGRAMMABBRÜCHE SQL Fehler; technische 421; 8% Fehler; 438; 8% vermeidbar durch UNITTests; 2.471; 47% nicht vermeidbar durch UNITTests; 1.954; 37% Abbildung 4.4: Einteilung der Programmabbrüche in vermeidbar und nicht-vermeidbar durch UNIT-Testing Es ist ersichtlich, dass knapp die Hälfte der Programmabbrüche im laufenden Betrieb, durch entsprechende Unit-Tests vermieden werden hätte können. Die Programmabbrüche teilen sich folgendermaßen auf die einzelnen Module im SAP System auf: Tabelle 4.12: Gliederung der Programmabbrüche nach Modulen Modul MM (Material Management) SD (Sales and Distribution) PP (Production Planning) FI (Financial Accounting) EAI (Enterprise Application Integration) BA (Business Analytics) CO (Controlling) FORMS (Forms) BW (Business Warehouse) Summe 25 Programmabbrüche 1696 1586 1465 329 133 25 22 15 13 5284 Prozent 32,10% 30,02% 27,73% 6,23% 2,52% 0,47% 0,42% 0,28% 0,25% 100,00% Ergebnisse Patrick Deutsch Es zeigt sich, dass knapp 90 % der Programmabbrüche auf die drei Module „Material Management“, „Sales and Distribution“ und „Production Planning“ entfallen. 4.1.4 Objektklassifikation Tabelle 4.13: Auswertung der Verarbeitungsblöcke im SAP ERP Produktivsystem Methoden Funktionsbausteine 22.848 3.801 Anzahl Objekte 36,65% 6,10% 42.447.806.287 13.668.500.833 Anzahl Aufrufe 65,41% 21,06% Form-Routinen Sonstige Summe 27.851 7.845 62.345 44,67% 12,58% 100,00% 8.741.617.131 33.818.798 64.891.743.049 13,47% 0,05% 100,00% Die größte Anzahl an Objekten bildet die Gruppe der Form-Routinen mit 44,67 %. Die meisten Aufrufe betreffen jedoch die Methoden mit 65,41 %. Während die Methoden als objektorientiert klassifiziert werden, zählen die Funktionsbausteine, Form-Routinen und sonstige Objekte zu den prozeduralen Verarbeitungsblöcken. 4.2 Realisierung 4.2.1 Implementierung von Unit-Tests Es wurden Testfälle für zehn Objekte im Bereich „Sales and Distribution“ erstellt. Diese Objekte teilen sich folgendermaßen auf die verschiedenen Objektkategorien auf: Tabelle 4.14: Anzahl getestete Objekte je Klassifizierung Objektklassifikation Ausführbare Programme Klassenpools Funktionsgruppen Modulpools Summe Anzahl 3 3 2 2 10 Lediglich für ein Objekt aus der Klasse der Modulpools konnten keine Unit-Tests ausgeführt werden. Hier handelte es sich um einen User-Exit im SAP Standardprogramm SAPMV45A. Für SAP Standardprogramme können zwar Unit-Tests erstellt werden, die Ausführung wird aber durch einen entsprechenden Eintrag in der Tabelle TAUNIT_PROG_INFO verhindert. Da ein User-Exit technisch gesehen zum ihn umgebenden SAP Standardprogramm gehört, war eine Ausführung in diesem Fall nicht möglich. Umgangen werden kann dieses Problem durch objektorientierte Programmierung. Bei Klassen handelt es sich um eigenständige Objekte, welche nicht mehr zum aufrufenden Programm gehören. Für die übrigen Objekte wurde jeweils eine Anweisungsüberdeckung von mindestens 70 % erzielt. 26 Ergebnisse Patrick Deutsch Abbildung 4.5 zeigt ein Beispiel für Bedingungsüberdeckung in ABAP Unit. Rote Markierung: Bedingung wurde durch den Test nicht erreicht Gelbe Markierung: die Bedingung wurde in den Tests entweder immer oder nie erfüllt. Grüne Markierung: die Bedingung wurde in den Tests sowohl erfüllt als auch nicht erfüllt. Abbildung 4.5: Beispiel für Code-Highlighting bei Bedingungsüberdeckung in ABAP Unit Abbildung 4.6 und Abbildung 4.7 zeigen das Code-Highlighting sowie die Zusammenfassung eines Testlaufes mit der Messung der Anweisungsüberdeckung. Rote Markierung: die Anweisung wurde bei keinem Testfall ausgeführt. Grüne Markierung: die Anweisung wurde durch mindestens einen Testfall ausgeführt. 27 Ergebnisse Patrick Deutsch Abbildung 4.6: Beispiel für Code-Highlighting bei Anweisungsüberdeckung in ABAP Unit Abbildung 4.7: Zusammenfassung von Anweisungsüberdeckung in ABAP Unit Datenbankzugriffe in Unit-Tests Da Unit-Tests wiederholt ausführbar sein müssen, in einem Entwicklungssystem die Datenbasis aber nicht garantiert werden kann, sollten in einem Unit-Test keine Datenbankzugriffe stattfinden. Eine Änderung der Testdaten könnte zu fehlerhaften Tests führen, obwohl das getestete Objekt korrekt ist. 28 Ergebnisse Patrick Deutsch In Programmiersprachen wie Java, C oder C++ werden Mocking-Frameworks zur Elimination der Datenbank aus den Testfällen verwendet. ABAP Unit unterstützt jedoch kein MockingFramework. Um das Problem der Datenkonsistenz zu umgehen gibt es zwei Möglichkeiten: 1. Fixture Methoden Bei dieser Variante werden in der SETUP Methode der Testklasse, welche vor jedem Testfall ausgeführt wird, jene Datensätze in den Datenbanktabellen erzeugt, welche für den Testfall benötigt werden. In der TEARDOWN Methode (wird nach jedem Testfall aufgerufen) werden die angelegten Datensätze wieder gelöscht, damit wieder der ursprüngliche Datenbestand vorhanden ist. 2. Data Access Objects Bei dieser Methode werden alle Datenbankzugriffe des zu testenden Objektes in ein sogenanntes Data Access Object (DAO) ausgelagert. Das Testobjekt enthält ein Attribut mit der Referenz auf das DAO. In der Testklasse wird nicht das eigentliche DAO verwendet, sondern ein lokales DAO erzeugt, welches vom ursprünglichen DAO erbt, und die Methoden mit Datenbankzugriffen redefiniert und Dummy-Daten zurückliefert. [20] 4.2.2 Risikoanalyse Jedem Prozess werden die beiden Werte Frequency Class (Häufigkeit der Ausführung) und Damage Class (Schaden bei Fehler) zugewiesen. Daraus wird das Prozessrisiko errechnet. In der Spalte Relative Weight (%) wird das Risiko prozentuell vom darüber liegenden Prozess dargestellt. Die Spalte Contribution (%) zeigt den Risikoanteil jedes Prozesses gemessen am Gesamtrisiko. 29 Ergebnisse Patrick Deutsch Abbildung 4.8: Bewertung des Risikos der einzelnen Geschäftsprozesse Auffallend ist, dass die beiden risikoreichsten Prozesse „SD_Sales and Distribution“ und „MM_Material Management“ mit jeweils 30,98 % in Summe bereits 61,96 % am Gesamtrisiko ausmachen. In Abbildung 4.9 wird ersichtlich, dass mit den ca. 12,5 % riskantesten Prozessen (ca. 200) bereits eine Risikoabdeckung von 80 % erreicht wird. Somit würden sich Codefragmente, welche in einem oder im Idealfall sogar mehreren dieser Geschäftsprozesse durchlaufen werden, besonders gut für Unit-Testing eignen. 30 Ergebnisse Patrick Deutsch Abbildung 4.9: Pareto Darstellung der Risikobewertung aller Geschäftsprozesse bei Swarovski 4.3 Zusammenfassung Die ERP Testing Umfrage zeigte, dass nur eine geringe Anzahl an Unternehmen Unit-Tests im ERP Bereich im Einsatz hat. Die firmeninterne Umfrage bei Swarovski ergab, dass die Mehrheit der befragten Personen mit dem Konzept des Unit-Testens vertraut ist und eine Reduktion des Testaufwandes dadurch als realistisch sieht. Als Hauptgründe für den derzeitigen Nicht-Einsatz wurden Budgetknappheit, Zeitmangel sowie fehlendes Wissen über das Prinzip genannt. Die Analyse der Programmabbrüche ergab, dass fast die Hälfte der Fehler mittels Unit-Tests vermieden werden hätte können. Bei der Objektklassifikation zeigte sich, dass rund ein Drittel des kundenspezifischen Quellcodes objektorientiert programmiert ist, was für den Einsatz von Unit-Tests von Vorteil ist. Bei der Implementierung von Unit-Tests in ausgewählten Bereichen im System stellte sich heraus, dass neun von zehn Objekten unit-testbar waren. Um Datenbankzugriffe zu umgehen, können die zur Verfügung stehenden Fixture Methoden oder Data Access Objects verwendet werden. Die Auswertung der Risikoanalyse zeigt, dass die beiden Module „SD_Sales and Distribution“ und „MM_Material Management“ einen Anteil von über 60 % am Gesamtrisiko haben und sich dadurch für den Einsatz von Unit-Tests anbieten. 31 Diskussion Patrick Deutsch 5 Diskussion 5.1 Datenerhebung und -analyse 5.1.1 ERP-Testing Umfrage Es fällt auf, dass Unit-/Modul-/Komponententest jene Teststufe ist, welche bei ERP Projekten am wenigsten realisiert wird. Lediglich 26 befragte Unternehmen gaben an, diese Teststufe bei ERP Projekten im Einsatz zu haben. Allerdings gaben nur 5 Unternehmen an, dass UnitTests Teil jeder Iteration ihres jeweiligen Vorgehensmodells sind. Dies lässt den Schluss zu, dass selbst bei den wenigen Unternehmen, welche diese Teststufe implementiert haben, diese nicht regelmäßig eingesetzt wird. Bei der Gruppe der ERP-Anwender kann argumentiert werden, dass deren Kunden meist unternehmensintern sind. Somit fällt der Kostenpunkt des Imageschadens bei einem Softwarefehler weg. Dies drückt die Fehlerkosten erheblich. Da die Testkosten die Fehlerkosten nicht übersteigen sollen, kann hier ein reduziertes Testmanagement eigesetzt werden. Auffallend ist aber, dass auch bei der Gruppe der ERP-Hersteller diese Teststufe meist nicht zum Einsatz kommt, nämlich lediglich bei vier Unternehmen. Da bei dieser Gruppe das ERP System ein Produkt ist, welches an andere Unternehmen vertrieben wird, sollte hier doch ein sehr ausgeprägtes Testmanagement implementier sein. Eine mögliche Ursache für diesen Umstand könnten aber zum Beispiel ausgedehnte Serviceverträge sowie ein schneller Support bei Fehlern sein. Betrachtet man nur das ERP System SAP, welches auch Swarovski einsetzt, gaben 14 Unternehmen an, diese Teststufe bei ERP Projekten einzusetzen. Dies entspricht lediglich 23,73 % aller Unternehmen, welche SAP verwenden. Die Umfrage zeigt also, dass Unit-Testing sowohl bei ERP-Anwendern als auch bei ERPHerstellern nicht weit verbreitet ist. 5.1.2 Umfrage bei Swarovski Wie die Mitarbeiterbefragung bei Swarovski gezeigt hat, sind 80 % der teilnehmenden Personen mit dem Begriff Unit-/Modul- bzw. Komponententest vertraut. Selbst einen Unit-Test erstellt haben allerdings lediglich 10 % der mit dem Begriff vertrauten Personen. Betrachtet man nur den Personenkreis der Entwickler, welche für das Erstellen von Unit-Tests verantwortlich sind, sind 85 % mit dem Begriff vertraut, wovon 18 % bereits einen Unit-Test erstellt haben. Nur eine Person gab an, mit dem im SAP integrierten Framework ABAP Unit vertraut zu sein. Diese Person konnte weder Vor- noch Nachteile gegenüber anderen xUnitFrameworks nennen. Obwohl 84 % der teilnehmenden Personen die Qualität der von ihnen betreuten Programme mit „hoch“ oder „sehr hoch“ bewerteten, sind 80 % von ihnen der Meinung, dass Unit-Tests die Qualität weiter erhöhen könnten. 32 Diskussion Patrick Deutsch Die Mehrheit der Personen ist also mit dem Prinzip des Unit-Testens vertraut und sieht einen Mehrwert durch den Einsatz dieser Art von Tests. Auf die Frage nach den Gründen, warum derzeit bei Swarovski trotzdem keine Unit-Tests erstellt werden, nannten 92 % einen der folgenden Gründe: - Prinzip ist nicht bekannt Budgetknappheit Zeitmangel Dies deckt sich mit den in [12] genannten Hauptgründen dafür, dass qualitätssichernde Maßnahmen oft vernachlässigt und somit dem Kunden überlassen werden. Diesen Argumenten kann entgegengehalten werden, dass Softwarefehler mehr Kosten verursachen, je später sie entdeckt werden. Vom Kunden entdeckte Fehler sind somit wesentlich teurer, als Fehler welche bereits in der Realisierungsphase der Software gefunden werden. Grob kann gesagt werden, dass sich die Korrekturkosten für einen Softwarefehler mit jeder Teststufe gegenüber der vorherigen Stufe verdoppeln. [21] Insgesamt sind 56 % der Meinung, dass automatisierte Unit-Tests ihren Testaufwand reduzieren könnten. Als Begründung für diese Annahme wurden größtenteils Zeitersparnis, durch das wiederholte automatisierte Ausführen der Tests, sowie frühzeitige Fehlererkennung angegeben. Diese Antworten stehen somit im Widerspruch zu den Vermutungen für den derzeitigen Nicht-Einsatz von Unit-Tests. Eine mögliche Ursache für diesen Widerspruch könnte sein, dass die Softwareentwickler und -tester über Unit-Testing und dessen Vorteile Bescheid wissen, der Führungsebene diese aber nicht bekannt oder nicht bewusst sind. Eine weitere Möglichkeit könnte sein, dass die teilnehmenden Entwickler lediglich mit dem Begriff des Unit-Testings vertraut sind, aber wenig über den Einsatz sowie dessen Vorteile wissen. Dies würde erklären, warum die Mehrheit einen Mehrwert durch Unit-Tests sieht, derzeit aber nur eine der teilnehmenden Personen jemals einen Unit-Test im SAP erstellt hat. Dieser Mangel könnte leicht durch interne oder externe Schulungen behoben werden. Zusammenfassend kann gesagt werden, dass die Mehrheit der an der Umfrage teilnehmenden Personen dem Einsatz von Unit-Testing positiv gestimmt und offen ist. Vermutlich müsste aber ein genereller Wandel in der IT Organisation stattfinden. Es müsste ein Bewusstsein dafür geschaffen werden, dass zwar zusätzliche Entwicklungskosten für das Erstellen der Tests anfallen, dafür aber viele Fehler bereits in einer sehr frühen Testphase entdeckt werden. Dadurch können aufwändige und kostenintensive Korrekturen vermieden werden. 5.1.3 Analyse der Programmabbrüche Bei der Analyse der Programmabbrüche im Produktivsystem hat sich herausgestellt, dass 47 % durch entsprechendes Unit-Testing vermeidbar gewesen wären. Bei einem Großteil dieser Abbrüche, trat der Fehler an den Grenzwerten des jeweiligen Datenbereiches auf. Oft traten sogenannte Overflow-Exceptions auf, bei denen die Eingabe zu groß für den jeweiligen Datenbereich war und das Programm dies nicht entsprechend behandelt hat. 33 Diskussion Patrick Deutsch Solche Fehler können leicht vermieden werden, wenn vor oder während der Implementierung eine Grenzwertanalyse durchgeführt wird. Bei dieser Methode werden die Grenzwerte von Äquivalenzklassen für die Konstruktion von Testfällen herangenommen. Ein Testfall ist dabei immer ein ungültiger Wert, welcher außerhalb des erlaubten Wertebereiches liegt. [7] Wenn also Unit-Tests auf Basis einer Grenzwertanalyse implementiert werden, wird bereits beim Testen ersichtlich wie ein Programm auf ungültige Eingaben reagiert. Wird dies im Programm nicht entsprechend berücksichtigt, schlägt ein Testfall fehl und der Programmierer muss die entsprechenden Korrekturen vornehmen. Die restlichen 53 % aller Programmabbrüche hätten auch durch entsprechende Unit-Tests nicht vermieden werden können, da hier kein Testfall erstellt werden hätte können. Der häufigste Fehler war ein TIME_OUT, bei dem die Verarbeitungszeit eines Programms zu lang ist. Dieser Fehler tritt auf, wenn ein Benutzer dem Programm eine zu große Menge von Eingabedaten zur Verfügung stellt. Da es sich hier um eine nicht behandelbare Ausnahme handelt, hat der Programmierer keine Möglichkeit darauf entsprechend zu reagieren. Ein ebenfalls beträchtlicher Teil der Programmabbrüche trat in der Verarbeitung von GUIKomponenten auf. Da die Oberfläche für Unit-Testing nicht relevant ist, können dafür auch keine Testfälle erstellt werden. Jeweils ca. 8 % der Programmabbrüche wurden durch technische Fehler bzw. Fehler bei Datenbankzugriffen verursacht. Die technischen Fehler wurden nicht durch einen Fehlerzustand im ausgeführten Programm verursacht, sondern durch einen Systemfehler. Die Fehler bei Datenbankzugriffen können ebenfalls nicht durch Unit-Tests behoben werden, da in den Tests keine Datenbankzugriffe stattfinden sollten. Diese sollten mittels Mocking durch fixe Testdaten ersetzt werden. Es kann gesagt werden, dass knapp die Hälfte aller Programmabbrüche im laufenden Betrieb durch den Einsatz von Unit-Tests vermieden werden hätte können, was doch einen beträchtlichen Teil darstellt und klar aufzeigt, dass Potenzial dafür besteht. Der Fokus sollte dabei auf die Module „Material Management“, „Sales and Distribution“ und „Production Planning“ gelegt werden, da fast 90 % aller Programmabbrüche auf diese drei Module entfallen. 5.1.4 Objektklassifikation Bei der Klassifikation der Verarbeitungsblöcke im System hat sich gezeigt, dass nach der Anzahl der Aufrufe im System mehr objektorientierter als prozeduraler Code durchlaufen wird. Betrachtet man allerdings nur die Anzahl der Objekte, unabhängig davon wie oft diese im System aufgerufen werden, entfallen nur 36,65 % auf objektorientierte Programmierung. Diese Unterscheidung ist deshalb wichtig, da für den Einsatz von Unit-Tests objektorientierte Programmierung empfohlen wird. [12] Nach der Implementierung von Unit-Tests in verschiedenen Bereichen des Systems bei Swarovski kann dies nur bestätigt werden. Meist konnten die Testfälle auch für prozedurale Programme erstellt werden, der Aufwand dafür war aber um einiges höher, da teilweise gewisse Vorarbeiten erledigt werden mussten. Bei Funktionsgruppen und Programmen müssen zB eigene Includes angelegt werden, in denen die Tests zusammengefasst werden. Um den Einsatz von Unit-Tests in Zukunft zu erleichtern, sollte bei neu erstelltem Quellcode darauf geachtet werden, diesen in objektorientiertem Programmierstil zu entwickeln. Den 34 Diskussion Patrick Deutsch gesamten bestehenden prozeduralen Code auf Objektorientierung umzubauen wäre zu viel Aufwand. Es könnte jedoch darüber nachgedacht werden, ob vereinzelt zentrale prozedurale Verarbeitungsblöcke, welche in sensiblen Bereichen des Systems implementiert sind transformiert werden. 5.1.5 Zusammenfassung Generell kann gesagt werden, dass Unit-Testing bei der Implementierung und Erweiterung von ERP Systemen nicht sehr weit verbreitet ist. Nur wenige Unternehmen gaben an, diese Teststufe bei ihren ERP Projekten einzusetzen. Auch bei der Firma Swarovski gibt es derzeit keine Richtlinien für den Einsatz von Unit-Tests in ihrem ERP System. Die intern bei Swarovski durchgeführte Umfrage ergab, dass die Mehrheit der befragten Softwareentwickler zwar mit dem Prinzip des Unit-Testens vertraut ist, jedoch gab lediglich eine Person an, bereits Unit-Tests im SAP System implementiert zu haben. Vor- bzw. Nachteile gegenüber Unit-Testing-Frameworks anderer Programmiersprachen konnten nicht genannt werden. Weiters wurde durch die Umfrage deutlich, dass sich sowohl Entwickler als auch Consultants eine Qualitätsverbesserung durch Unit-Tests erwarten würden. Als Hauptgründe für den Umstand, dass diese Teststufe dennoch nicht realisiert ist, wurden Zeitmangel, Budgetknappheit sowie fehlendes Wissen darüber angegeben. Um diesen Argumenten entgegenzutreten, müsste ein Bewusstsein dafür geschaffen werden, dass die Fehlerkosten rasant ansteigen, je später ein Fehler entdeckt wird. Eine Auswertung der Programmabbrüche im laufenden System von Swarovski hat ergeben, dass knapp die Hälfte der Abbrüche durch den Einsatz entsprechender Unit-Tests vermieden werden hätte können. Die übrigen Fehler gliedern sich in SQL Fehler, Fehler in der GUI Verarbeitung, Systemfehler und Fehler durch eine zu große Menge von Eingabedaten. Für diese Fehler hätten keine Unit-Testfälle erstellt werden können. Die meisten der Programmabbrüche entfallen auf die Module „Material Management“, „Sales and Distribution“ und „Production Planning“. Diese würden sich daher besonders für Unit-Tests eignen. Für die Verwendung von ABAP Unit wird objektorientierte Programmierung empfohlen. Im ERP System der Firma Swarovski sind derzeit gut ein Drittel aller Verarbeitungsblöcke im objektorientierten Programmierstil implementiert. Eine Transformierung der restlichen Verarbeitungsblöcke in Objektorientierung wäre sicherlich zu viel Aufwand. Um den Einsatz von Unit-Tests in Zukunft aber zu erleichtern, sollte bei Neuentwicklungen darauf geachtet werden, diese objektorientiert zu programmieren. 35 Diskussion Patrick Deutsch 5.2 Realisierung 5.2.1 Implementierung von Unit-Tests Bei der Implementierung von Unit-Tests ist aufgefallen, dass jedes getestete Objekt über eine Vielzahl von Datenbankzugriffen verfügt. Dies führt dazu, dass keine konstante Datenbasis, welche bei Unit-Tests essenziell ist, gewährleistet werden kann. In Kapitel 4.2.1 werden zwei Methoden beschrieben, wie dieses Problem umgangen werden kann. Die Verwendung der Fixture Methoden zum Erstellen bzw. Bereinigen der Testdaten ist nicht zu empfehlen, da es bei Problemen in der Testausführung zu inkonsistenten Zuständen auf der Datenbank kommen kann. Bei einem Systemabsturz während der Testausführung würden die vorher erzeugten Testdaten auf der Datenbank nicht mehr gelöscht werden und somit auf der Datenbank stehen bleiben. Die bessere Alternative ist hier, alle Datenbankzugriffe über Data Access Objects zu realisieren, da bei der Testausführung keine Änderungen auf der Datenbank vorgenommen werden. Die bestehenden Programme auf dieses Prinzip auszurichten, würde jedoch sehr viel Aufwand bedeuten. Eine Alternative wäre, Unit-Tests nur für neue Objekte einzuführen. Wenn das Prinzip der Data Access Objects bei der Erstellung von Objekten sofort berücksichtigt wird, bedeutet es relativ wenig Mehraufwand, führt jedoch dazu, dass das Objekt unit-testbar wird. Weiters ist auffallend, dass die getesteten Objekte ein zu hohes Maß an Komplexität aufweisen, was die Erstellung von guten Unit-Tests erschwert. Es wäre ein Refactoring sinnvoll, um die Objekte dahingehend anzupassen, dass eine Routine nur einen Zweck erfüllt. Außerdem sollte auf die Verwendung von globalen Daten verzichtet werden. Jene Daten welche in einer Routine benötigt werden, sollten als Schnittstellenparameter an diese übergeben werden. Dies erleichtert das Erstellen von Unit-Tests erheblich, da in der Schnittstelle der Routine sofort ersichtlich ist, welche Daten benötigt werden. Ein weiteres Problem ist das Vorhandensein von Nachrichten (Fehlermeldungen bzw. Erfolgsmeldungen) in der Geschäftslogik. Beim Auslösen einer Nachricht wird die Programmkontrolle sofort an die GUI übergeben, welche die Nachricht darstellt. In einem UnitTest führt dies zur sofortigen Beendigung des Tests. Beim Ausführen der Tests ist sowohl das Darstellen der Nachricht sowie das Abbrechen des Testfalls nicht erwünscht. Nachrichten sollten daher in der Geschäftslogik vermieden und nur direkt in GUI-Elementen ausgegeben werden. Dies kann entweder durch das Setzen und Weiterreichen von Parametern oder durch das Auslösen von Exceptions geschehen. Da im Test sowohl auf eine Exception, als auch auf einen Rückgabeparameter reagiert werden kann, wird das Erstellen von Unit-Tests ermöglicht. [22] Testdaten Bei der Implementierung von Unit-Tests spielen die Testdaten eine wichtige Rolle. Da in UnitTests keine Datenbankzugriffe erlaubt sind, werden die Testdaten meist direkt im Test hinterlegt. Dies hat den Nachteil, dass bei einer Änderung der Testdaten, alle Unit-Tests welche darauf zugreifen angepasst werden müssen. 36 Diskussion Patrick Deutsch Eine Möglichkeit diesen Umstand zu umgehen bietet das von SAP entwickelte eCATTFramework (extended Computer Aided Test Tool) zur Testautomatisierung, welches direkt in das System integriert ist. [12] Die Verwendung dieses Tools ermöglicht es dem Entwickler, die Testdaten aus einem sogenannten Testdatencontainer zu ermitteln. Die Befüllung dieses Containers kann zB über Excel- oder XML-Files erfolgen. Dies ermöglicht eine saubere Trennung von Test- und Produktivdaten, bietet aber trotzdem die Möglichkeit die Testdaten ohne Programmieraufwand zu verändern. Testautomatisierung Beim Einsatz von Unit-Tests spielt Testautomatisierung eine wichtige Rolle. Da im Laufe der Zeit sehr viele Testfälle erstellt werden, ist es wichtig diese automatisiert ausführen zu können. Durch das regelmäßige wiederholte Ausführen von neuen sowie bestehenden Testfällen, ist sichergestellt, dass keine Side-Effects durch eine Änderung an bestehendem Code ins System gelangt sind. Der Programmierer kann zwar das von ihm angepasste Objekt testen und so sicherstellen, dass es wie gewünscht funktioniert, Probleme bei abhängigen Objekten werden dabei aber leicht übersehen. Im SAP steht für das automatisierte Ausführen von Unit-Tests der sogenannte Code Inspector zur Verfügung. Über diesen kann gesteuert werden, wie oft welche Testfälle ausgeführt werden. Der Code Inspector kann auch so konfiguriert werden, dass bei einem Transport von einem Objekt vom Entwicklungssystem auf das Testsystem oder – noch wichtiger – ins Produktivsystem eine Prüfung ausgeführt wird. Beim Fehlschlagen eines Unit-Tests wird der Transport untersagt. Dies ist eine wichtige Methode zur Qualitätssicherung, da somit sichergestellt ist, dass nach dem Release einer Programmänderung weiterhin alle Unit-Tests erfolgreich durchlaufen werden. 5.2.2 Risikoanalyse Es ist wichtig, dass die Testkosten die Kosten für einen möglichen Fehler nicht übersteigen [7]. Die Kosten für einen Softwarefehler orientieren sich am Risiko des zugrundeliegenden Geschäftsprozesses. Das Risiko für einen Prozess errechnet sich folgendermaßen: 𝑅𝑖𝑠𝑖𝑘𝑜 = 𝑚ö𝑔𝑙𝑖𝑐ℎ𝑒𝑟 𝑆𝑐ℎ𝑎𝑑𝑒𝑛 ∗ 𝐻ä𝑢𝑓𝑖𝑔𝑘𝑒𝑖𝑡 𝑑𝑒𝑟 𝐴𝑢𝑠𝑓üℎ𝑟𝑢𝑛𝑔 [12] Daher sollte mehr Testaufwand in jene Prozesse fließen, welche eine höhere Risikobewertung haben. Bezogen auf Unit-Testing bedeutet dies, dass jene Objekte, welche in riskanten Geschäftsprozessen durchlaufen werden, besser getestet werden sollten, als Objekte, welche ausschließlich in weniger riskanten Prozessen verwendet werden. Bei Swarovski haben die beiden Prozesse „SD_Sales and Distribution“ und „MM_Material Management“ die höchste Risikobewertung. Somit sollte diesen beiden Prozessen bei der Einführung von Unit-Tests besondere Beachtung geschenkt werden. 37 Diskussion Patrick Deutsch 5.2.3 Teststrategie bei Swarovski Swarovski hat derzeit im Bereich SAP keine Teststrategie implementiert. Dies führt dazu, dass es keine Richtlinien dafür gibt, auf welcher Testebene und in welchem Umfang Prozesse getestet werden müssen. Die Tests werden zum größten Teil auf Basis der eigenen Erfahrung (explorativ) erstellt und ausgeführt. Lediglich bei Systemupgrades werden teilweise bereits automatisierte Abnahmetests eingesetzt. Abbildung 5.1: Bewertung des Testprozesses bei Swarovski durch die Firma Software Quality Lab aus dem Jahr 2013 Bei einer Bewertung des Testprozesses bei Swarovski durch die Firma Software Quality Lab im Jahr 2013, wurde das Fehlen einer Teststrategie mit dem größten Handlungsbedarf bewertet. Die Teststrategie sollte den roten Faden von den Systemanforderungen hin zu den jeweiligen Testaktivitäten deutlich machen. In ihr werden die Verteilung des Testaufwandes und der Testabdeckung über die zu testenden Objekte geregelt. Außerdem werden die Teststufen und Testmethoden definiert. Das Ziel der Teststrategie ist es, Fehler so früh und kostengünstig wie möglich zu finden. [23] 5.2.4 Zusammenfassung Beim Erstellen von Beispielimplementierungen von Unit-Tests in verschiedenen Bereichen des SAP Systems von Swarovski hat sich herausgestellt, dass es mit ABAP Unit zwar ein gut integriertes Framework dafür gibt, jedoch einige Punkte für eine effiziente Nutzung beachtet 38 Diskussion Patrick Deutsch werden müssen: neue Funktionalitäten sollten lediglich objektorientiert programmiert werden, Datenbankzugriffe nur mehr über Data Access Objects implementiert werden und die erstellten Programme müssen sehr modular aufgebaut sein. Weiters muss darauf geachtet werden, dass eine saubere Trennung von Business Logik und Oberfläche vorhanden ist (Exceptions statt Messages in der Business Logik). Bei den untersuchten Programmen am System von Swarovski waren meist gleich mehrere dieser Voraussetzungen verletzt. Zwar konnten mit einer Ausnahme in allen ausgewählten Objekten Unit-Tests erstellt werden, allerdings waren oft sehr zeitaufwändige Vorarbeiten dafür notwendig. Außerdem sollte in einem Programm ein gewisses Maß an Business Logik vorhanden sein. Programme welche lediglich Daten aus der Datenbank lesen und entsprechend auf der Oberfläche darstellen eignen sich daher meist nicht für die Implementierung von Unit-Tests. Weiters sollte ein Fehler in einem Objekt ein gewisses Risiko darstellen, da sonst die Testkosten leicht die Fehlerkosten übersteigen können. Bezogen auf Swarovski sollte vor der Einführung von Unit-Tests eine Teststrategie erstellt werden, welche ebenfalls den Einsatz von Unit-Tests regelt. Darin sollten Metriken festgelegt werden, welche den Entwicklern den Umfang der zu erstellenden Tests vorgeben. Als Metrik für die Implementierung von Unit-Tests wird üblicherweise die Testabdeckung verwendet. Diese regelt im Wesentlichen das Verhältnis von getestetem Code zum gesamten Programmcode. Für den Einsatz von Unit-Tests eignen sich jene Objekte am meisten, welche in Geschäftsprozessen mit hoher Risikobewertung vorkommen, entsprechend oft aufgerufen werden und derzeit oft Fehler verursachen. Bei dieser Schnittmenge kann durch die Implementierung relativ weniger Tests eine hohe Qualitätsverbesserung erreicht werden. Konkret sind das vor allem Objekte aus den Modulen „Materials Management“ und „Sales and Distribution“, da diese sowohl bei der Risikoanalyse als auch bei der Liste der derzeitigen Programmabbrüche ganz vorne zu finden sind. 39 Danksagung Patrick Deutsch 6 Danksagung An dieser Stelle möchte ich mich bei Priv.-Doz. Dipl.-Ing. Mag. Dr. Michael Felderer bedanken, der mir während der gesamten Zeit als Betreuer zur Verfügung stand und mir stets weiterhelfen konnte. Ein großes Dankeschön geht an die Firma Swarovski, welche diese Bachelorarbeit erst ermöglicht hat. Ein besonderer Dank gilt hier meinem Vorgesetzten Mag. Stefan Totschnig, der mich sowohl bei der Themenwahl als auch bei der Umsetzung unterstützt hat. Außerdem bedanke ich mich bei meinen Kolleginnen und Kollegen bei der Firma Swarovski, die mir sowohl durch ihre Teilnahme an meiner Mitarbeiterumfrage als auch durch hilfreiche Tipps weitergeholfen haben. Abschließend möchte ich mich noch bei meiner Freundin Nicole bedanken, welche mich während der gesamten Studienzeit immer wieder motiviert hat und stets ein offenes Ohr für meine Sorgen hat. 40 Literaturverzeichnis Patrick Deutsch 7 Literaturverzeichnis [1] P. Gerrard, “Test methods and tools for ERP implementations,” Proc. - Test. Acad. Ind. Conf. Pract. Res. Tech. TAIC PART-Mutation 2007, pp. 40–43, 2007. [2] “ERP-Software - Marktanteile der Anbieter weltweit 2013 | Statistik,” 2013. [Online]. Available: https://de.statista.com/statistik/daten/studie/262342/umfrage/marktanteileder-anbieter-von-erp-software-weltweit/. [Accessed: 16-Nov-2016]. [3] G. J. Myers, C. Sandler, and T. Badgett, The Art of Software Testing. Wiley, 2011. [4] D. W. Hoffmann, Software-Qualität. Springer, 2013. [5] “Softwarefehler kommen die deutsche Wirtschaft teuer zu stehen computerwoche.de,” 2001. [Online]. Available: http://www.computerwoche.de/nachrichten/519152. [Accessed: 23-Oct-2016]. [6] H. M. Sneed and S. Jungmayr, “Mehr Testwirtschaftlichkeit durch Value-DrivenTesting,” Informatik-Spektrum, vol. 34, no. 2, pp. 192–209, Apr. 2011. [7] T. Linz and A. Spillner, Basiswissen Softwaretest: Aus- und Weiterbildung zum Certified Tester - Foundation Level nach ISTQB-Standard. dpunkt.verlag, 2012. [8] M. Pol, T. Koomen, and Andreas Spillner, Management und Optimierung des Testprozesses: Praktischer Leitfaden für erfolgreiches Software-Testen mit TPI und TMap, 2. Heidelberg: dpunkt.verlag, 2002. [9] P. Liggesmeyer, Software-Qualität: Testen, Analysieren und Verifizieren von Software. Spektrum Akademischer Verlag, 2009. [10] A. Al-Hossan and A. S. Al-Mudimigh, “Practical Guidelines for ERP Testing,” J. Theor. Appl. Inf. Technol., vol. 27, pp. 11–18, 2011. [11] R. Osherove, The Art of Unit Testing. mitp Verlag, 2015. [12] D. Majer, Unit-Tests mit ABAP-Unit. dpunkt.verlag, 2009. [13] Wikipedia, “Modultest - Wikipedia, Die freie Enzyklopädie,” 2016. [Online]. Available: https://de.wikipedia.org/w/index.php?title=Modultest&oldid=158478083. [Accessed: 19-Oct-2016]. [14] F. Westphal, Testgetriebene Entwicklung mit JUnit und FIT. dpunkt.verlag, 2005. [15] Wikipedia, “ABAP Unit - Wikipedia, Die freie Enzyklopädie,” 2016. [Online]. Available: https://de.wikipedia.org/w/index.php?title=ABAP_Unit&oldid=155777715. [Accessed: 19-Oct-2016]. [16] M. Felderer and F. Piazolo, “Multidimensional Views on Enterprise Information Systems: Proceedings of ERP Future 2014,” ERP Futur. 2014, p. 183, 2016. [17] C. C. Chen, C. Law, and S. C. Yang, “Managing ERP Implementation Failure: A Project Management Perspective,” IEEE Trans. Eng. Manag., vol. 56, no. 1, pp. 157– 170, Feb. 2009. [18] M. Bradford, Modern ERP: Select, Implement, and Use Today’s Advanced Business Systems. Lulu.com, 2016. [19] SAP, “Help Portal - Code Inspector.” [Online]. Available: https://help.sap.com/saphelp_nw73/helpdata/de/49/205531d0fc14cfe10000000a42189 b/content.htm. [Accessed: 22-Oct-2016]. 41 Literaturverzeichnis Patrick Deutsch [20] A. Krawczyk, “ABAP Unit Tests without database dependency - DAO concept - SAP Blogs,” 2013. [Online]. Available: https://blogs.sap.com/2013/03/21/abap-unit-testswithout-database-dependency-dao-concept/. [Accessed: 03-Nov-2016]. [21] F. Witte, Testmanagement und Softwaretest: Theoretische Grundlagen und praktische Umsetzung. Wiesbaden: Springer Fachmedien Wiesbaden, 2016. [22] R. Plantiko, “Keine Message-Befehle in Geschäftslogik!,” 2010. [Online]. Available: http://ruediger-plantiko.blogspot.co.at/2010/11/keine-message-befehle-ingeschaftslogik.html. [Accessed: 03-Nov-2016]. [23] A. Spillner, T. Roßner, M. Winter, and T. Linz, Praxiswissen Softwaretest Testmanagement – Aus- und Weiterbildung zum Certified Tester – Advanced Level nach ISTQB-Standard. dpunkt.verlag, 2014. 42 Anhang Patrick Deutsch 8 Anhang 8.1 Umfrage: SAP UNIT – Testing bei Swarovski Seite 1 Diese Umfrage zum Thema Softwarequalität mit Schwerpunkt UNIT-Testing bei Swarovski umfasst 9 bis 15 Fragen. Planen Sie ca. 5 bis 10 Minuten zur Beantwortung der Fragen ein. Vielen Dank für Ihre Teilnahme! Seite 2 1. Welche Position innerhalb der Swarovski IT nehmen Sie ein? * Entwickler Consultant Sonstiges (bitte angeben) Seite 3 2. Sind Sie mit dem Begriff UNIT-Test (auch Modul- oder Komponententest) vertraut? * Ja Nein keine Angabe 43 Anhang Patrick Deutsch Seite 4 3. Haben Sie selbst bereits einmal einen UNIT-Test geschrieben? * Ja Nein keine Angabe Seite 5 4. Sind Sie mit dem ABAP UNIT Framework zum Erstellen von UNIT-Tests vertraut? * Ja Nein keine Angabe Seite 6 5. Kennen Sie das Prinzip des UNIT-Testings aus anderen Programmiersprachen (zB Java)? * Ja Nein keine Angabe 44 Anhang Patrick Deutsch Seite 7 6. Können Sie Vor-/Nachteile von ABAP UNIT gegenüber UNIT-Test Frameworks anderer Programmiersprachen (JUnit, NUnit, usw.) nennen? * Ja Nein keine Angabe Seite 8 7. Geben Sie bitte die Vor-/Nachteile von ABAP UNIT gegenüber UNIT-Test Frameworks anderer Programmiersprachen (JUnit, NUnit, usw.) an: * Seite 9 8. Wie testen Sie Ihre Programme? * manuell automatisiert Sonstiges (bitte angeben) 45 Anhang Patrick Deutsch Seite 10 9. Welche Teststrategie verfolgen Sie bei Ihren Tests? * systematisch (Testfallableitung aus der Spezifikation bzw. bestimmte Testdesign- Techniken) explorativ (auf Basis der eigenen Erfahrung) Sonstiges (bitte angeben) Seite 11 10. Sind Sie der Meinung, dass die Entwickler ihre Progamme selbst ausreichend testen? * Ja Nein keine Angabe Sonstiges (bitte angeben) 46 Anhang Patrick Deutsch Seite 12 11. Glauben Sie, dass automatisierte UNIT-Tests die Qualität der von Ihnen betreuten Programme erhöhen könnten? * Ja Nein keine Angabe Sonstiges (bitte angeben) UNIT-Test (Modultest): Vom Entwickler definierte und implementierte Testfälle möglichst kleiner Programmeinheiten (Units) - zB Methoden, Funktionsbausteine, Performs, usw.) Seite 13 12. Glauben Sie, dass automatisierte UNIT-Tests Ihren Testaufwand reduzieren könnten? * Ja Nein keine Angabe Seite 14 13. Nennen Sie Gründe dafür, warum Sie glauben, dass automatisierte UNIT-Tests Ihren Testaufwand reduzieren könnten? * 47 Anhang 14. Patrick Deutsch Nennen Sie Gründe dafür, warum Sie glauben, dass automatisierte UNIT-Tests Ihren Testaufwand nicht reduzieren könnten? * Seite 15 15. Wie schätzen Sie selbst die Qualität der von Ihnen geschriebenen/betreuten Programme ein (gemessen an der Anzahl der Programmabbrüche bzw. von den Usern gemeldeten Fehlern)? * sehr hoch hoch mittel niedrig sehr niedrig 48 Anhang Patrick Deutsch Seite 16 16. Warum glauben Sie, sind derzeit bei Swarovski keine UNIT-Tests im Einsatz? * Prinzip ist nicht bekannt Budgetknappheit Zeitmangel durch UNIT-Tests können vermutlich keine zusätzlichen Fehler gefunden werden technische Gründe (zB Objekte sind nicht UNIT testbar) Sonstiges (bitte angeben) 49 Anhang Patrick Deutsch 8.2 Detailliste der Programmabbrüche Tabelle 8.1: Programmabbrüche vermeidbar durch UNIT-Tests Fehler RAISE_EXCEPTION CONVT_NO_NUMBER CALL_FUNCTION_OPEN_ERROR CALL_FUNCTION_REMOTE_ERROR COMPUTE_BCD_OVERFLOW BCD_ZERODIVIDE DATA_LENGTH_0 TABLE_INVALID_INDEX BCD_FIELD_OVERFLOW GETWA_NOT_ASSIGNED ITAB_LINE_NOT_FOUND CALL_FUNCTION_PARM_MISSING CONVT_OVERFLOW CALL_FUNCTION_CONFLICT_TYPE UNCAUGHT_EXCEPTION BCD_OVERFLOW OBJECTS_OBJREF_NOT_ASSIGNED CONVT_CODEPAGE CALL_FUNCTION_SEND_ERROR STRING_OFFSET_TOO_LARGE CHECK_SELOPT_ILLEGAL_SIGN STRING_OFFSET_LENGTH_TOO_LARGE STRING_OFFSET_NEGATIVE SUM_OVERFLOW COMPUTE_INT_TIMES_OVERFLOW MOVE_TO_LIT_NOTALLOWED_NODATA OBJECTS_OBJREF_NOT_ASSIGNED_NO OPEN_DATASET_NO_AUTHORITY DDIC_TYPE_INCONSISTENCY ASSIGN_TYPE_CONFLICT STRING_LENGTH_TOO_LARGE COLLECT_OVERFLOW_TYPE_P DATA_OFFSET_TOO_LARGE CALL_FUNCTION_RECEIVE_ERROR SET_HANDLER_FOR_NULL TABLE_ILLEGAL_STATEMENT CALL_FUNCTION_NOT_FOUND DYN_CALL_METH_PARAM_TYPE CALL_FUNCTION_CONFLICT_LENG CALL_TRANSACTION_NOT_FOUND IMPORT_ALIGNMENT_MISMATCH EXPORT_TOO_MUCH_DATA DATASET_NOT_OPEN CALL_FUNCTION_NOT_ACTIVE GETWA_WRONG_LENGTH Summe 50 Anzahl 389 296 275 203 147 119 115 104 92 92 71 68 65 57 57 47 47 44 31 25 22 13 13 8 8 8 7 7 6 5 4 3 3 3 3 2 2 2 2 1 1 1 1 1 1 2471 Anhang Patrick Deutsch Tabelle 8.2: Programmabbrüche nicht vermeidbar durch UNIT-Tests Fehler TIME_OUT ITAB_DUPLICATE_KEY CONNE_IMPORT_WRONG_COMP_LENG DYNPRO_FIELD_CONVERSION DYNPRO_SYNTAX_ERROR MESSAGE_TYPE_UNKNOWN DYNP_TOO_MANY_RADIOBUTTONS_ON SYNTAX_ERROR STOP_NO_REPORT DYNPRO_MSG_IN_HELP SPOOL_NO_CONVERSION MESSAGE_TYPE_X_TEXT SYSTEM_NO_ROLL DYNPRO_NOT_FOUND LOAD_NO_ROLL Summe Anzahl 1233 462 104 76 42 6 6 6 6 4 3 3 1 1 1 1954 Tabelle 8.3: Programmabbrüche durch technische Fehler Fehler LOAD_PROGRAM_TABLE_MISMATCH LOAD_PROGRAM_CLASS_MISMATCH TSV_TNEW_PAGE_ALLOC_FAILED ITS_TEMPLATE_NOT_FOUND TSV_TNEW_BLOCKS_NO_ROLL_MEMORY TYPELOAD_NEW_VERSION LIST_TOO_MANY_LPROS STOP_WITHIN_CALLED_DYNPRO LOAD_TYPE_VERSION_MISMATCH SYSTEM_CORE_DUMPED TSV_TNEW_OCCURS_NO_ROLL_MEMORY LOAD_PROGRAM_NOT_FOUND Summe 51 Anzahl 113 78 68 67 45 16 16 15 12 5 2 1 438 Anhang Patrick Deutsch Tabelle 8.4: Programmabbrüche durch SQL Fehler Fehler DBSQL_SQL_ERROR DBSQL_DUPLICATE_KEY_ERROR DBSQL_TABLE_UNKNOWN SQL_CAUGHT_RABAX SAPSQL_PARSE_ERROR SAPSQL_STMNT_TOO_LARGE DBSQL_STMNT_TOO_LARGE SAPSQL_IN_ITAB_ILLEGAL_SIGN SAPSQL_PARSER_TODO_WARNING DBSQL_FAE_STATEMENT_TO_BIG DBSQL_TOO_MANY_OPEN_CURSOR DBIF_REPO_SQL_ERROR DBIF_NTAB_SQL_ERROR Summe Anzahl 142 107 54 35 25 19 17 7 6 5 2 1 1 421 8.3 Abbildungsverzeichnis Abbildung 2.1: Gliederung der Software Qualitätssicherung [4] ................................................... 3 Abbildung 2.2: Kontrollflussgraph für das Zählen von Zeichen ..................................................... 4 Abbildung 2.3: Einteilung der Teststufen nach Prüfebene [4] ....................................................... 6 Abbildung 2.4: Fehlerkorrekturkosten nach Entdeckungszeitpunkt [9] ........................................ 6 Abbildung 2.5: Traditioneller Entwicklungszyklus [11] .................................................................... 9 Abbildung 2.6: Testgetriebener Entwicklungszyklus [11] ............................................................... 9 Abbildung 2.7: Phasen der Testgetriebenen Entwicklung............................................................ 10 Abbildung 2.8: Beispiel einer Testklasse in ABAP Unit ................................................................ 11 Abbildung 2.9: ERP Systemlandschaft [18] .................................................................................... 12 Abbildung 2.10: ERP Systemlandschaft bei Swarovski................................................................ 13 Abbildung 4.1: Einteilung der Personen nach Unit-Test Kenntnissen........................................ 22 Abbildung 4.2: Einteilung der Personen mit Unit-Test Kenntnissen gruppiert nach bereits erstellten Unit-Tests ........................................................................................................................... 23 Abbildung 4.3: mögliche Gründe für den derzeitigen Nicht-Einsatz von Unit-Tests bei Swarovski............................................................................................................................................. 24 Abbildung 4.4: Einteilung der Programmabbrüche in vermeidbar und nicht-vermeidbar durch UNIT-Testing ....................................................................................................................................... 25 Abbildung 4.5: Beispiel für Code-Highlighting bei Bedingungsüberdeckung in ABAP Unit .... 27 Abbildung 4.6: Beispiel für Code-Highlighting bei Anweisungsüberdeckung in ABAP Unit.... 28 Abbildung 4.7: Zusammenfassung von Anweisungsüberdeckung in ABAP Unit ..................... 28 Abbildung 4.8: Bewertung des Risikos der einzelnen Geschäftsprozesse ............................... 30 Abbildung 4.9: Pareto Darstellung der Risikobewertung aller Geschäftsprozesse bei Swarovski............................................................................................................................................. 31 Abbildung 5.1: Bewertung des Testprozesses bei Swarovski durch die Firma Software Quality Lab aus dem Jahr 2013 ....................................................................................................... 38 52 Anhang Patrick Deutsch 8.4 Tabellenverzeichnis Tabelle 2.1: xUnit-Implementierungen verschiedener Programmiersprachen [5] ...................... 7 Tabelle 2.2: eingesetzte ERP Module bei Swarovski ................................................................... 13 Tabelle 4.1: Personenklassifizierung der ERP-Testing Umfrage ................................................ 19 Tabelle 4.2: Teststufen in der ERP Umfrage.................................................................................. 19 Tabelle 4.3: ERP System Verteilung ............................................................................................... 20 Tabelle 4.4: Aufteilung von Unit-/Modul-/Klassen-/Komponententest in die jeweiligen ERP Systeme ............................................................................................................................................... 21 Tabelle 4.5: Qualitätssicherung im jeweiligen Vorgehensmodell ................................................ 21 Tabelle 4.6: Teilnahme an der Mitarbeiterbefragung .................................................................... 22 Tabelle 4.7: Einteilung nach Unit-Test Framework Kenntnissen ................................................ 23 Tabelle 4.8: Gliederung der Personen nach Testabwicklung ...................................................... 23 Tabelle 4.9: Gründe für reduzierten Testaufwand ......................................................................... 24 Tabelle 4.10: Gründe für keinen reduzierten Testaufwand .......................................................... 24 Tabelle 4.11: Programmabbrüche gruppiert nach Kategorie ....................................................... 25 Tabelle 4.12: Gliederung der Programmabbrüche nach Modulen .............................................. 25 Tabelle 4.13: Auswertung der Verarbeitungsblöcke im SAP ERP Produktivsystem ............... 26 Tabelle 4.14: Anzahl getestete Objekte je Klassifizierung ........................................................... 26 Tabelle 8.1: Programmabbrüche vermeidbar durch UNIT-Tests ................................................ 50 Tabelle 8.2: Programmabbrüche nicht vermeidbar durch UNIT-Tests....................................... 51 Tabelle 8.3: Programmabbrüche durch technische Fehler .......................................................... 51 Tabelle 8.4: Programmabbrüche durch SQL Fehler ..................................................................... 52 53
