Black-Box-Tests - Hochschule Wismar
Werbung
Hochschule Wismar Fakultät für Wirtschaftswissenschaften Semesterprojekt Black-Box-Testing Semesterprojekt im Rahmen des Fernstudiengangs Master of Science in Wirtschaftsinformatik der Hochschule Wismar eingereicht von: André Hollstein, Larissa Koch, Stefan Kusay Studiengang Wirtschaftsinformatik, MWI 2010 - WS 2011/2012 Betreuer: Prof. Dr. rer. nat. Jürgen Cleve Wismar, den 15.05.2016 Inhalt I. ABBILDUNGSVERZEICHNIS ...............................................................................................................IV II. TABELLENVERZEICHNIS .................................................................................................................. VII III. ABKÜRZUNGSVERZEICHNIS ......................................................................................................... VIII 1 EINLEITUNG UND PROBLEMSTELLUNG.......................................................................................... 1 2 QUALITÄT VON SOFTWARE ................................................................................................................ 2 3 SOFTWARETESTS .................................................................................................................................... 6 4 3.1 TESTEN..................................................................................................................................................... 6 3.2 TESTPRINZIPIEN UND –STRATEGIE ....................................................................................................... 7 3.3 TESTPHASEN ........................................................................................................................................... 8 3.4 TESTMETHODEN (BLACK-BOX- VS. WHITE-BOX- UND GREY-BOX-TEST)....................................... 9 FUNKTION UND ANWENDUNG VON BLACK-BOX-TESTING..................................................... 13 4.1 DEFINITION BLACK-BOX-TESTING ..................................................................................................... 13 4.2 VOR- UND NACHTEILE VON BLACK-BOX-TESTS .............................................................................. 14 4.3 VORGEHEN BEI ANWENDUNG VON BLACK-BOX-TESTS .................................................................. 15 4.4 TYPEN VON BLACK-BOX-TESTMETHODEN ....................................................................................... 16 4.4.1 4.4.1.1 Äquivalenzklassentest ......................................................................................................................... 16 4.4.1.2 Grenzwertbetrachtung (Boundary-Value-Analyse) ............................................................................. 19 4.4.1.3 Use-Case-Test ..................................................................................................................................... 20 4.4.1.4 Entscheidungstabellenbasierter Test .................................................................................................... 22 4.4.1.5 Paarweises Testen ................................................................................................................................ 25 4.4.2 5 Nicht-Funktionale Tests ................................................................................................................ 28 4.4.2.1 Performance-Tests ............................................................................................................................... 29 4.4.2.2 Sicherheitstests .................................................................................................................................... 29 4.4.3 4.5 Funktionale Tests .......................................................................................................................... 16 Diversifizierungstests .................................................................................................................... 31 4.4.3.1 Back-to-Back-Test ............................................................................................................................... 31 4.4.3.2 Regressionstest .................................................................................................................................... 31 WERKZEUGE FÜR BLACK BOX-TESTS................................................................................................ 32 BLACK-BOX-TESTS IM RAHMEN EINES SAP-PROJEKTS .......................................................... 34 5.1 GRÜNDE FÜR ORGANISIERTES TESTEN IM SAP-UMFELD ................................................................ 34 5.2 TESTMETHODIK IN SAP-PROJEKTEN .................................................................................................. 36 5.2.1 Einführung in die ASAP-Methodik ................................................................................................ 36 5.2.2 Teststufen der ASAP-Methodik...................................................................................................... 40 5.3 SAP QUALITY CENTER BY HP ALS TESTWERKZEUG IM RAHMEN EINES SAP-PROJEKTS ............ 43 5.3.1 Funktionsweise des SAP Quality Centers by HP........................................................................... 43 II 5.4 6 BERICHTE AUS SAP-PROJEKTEN MIT SAP QUALITY CENTER BY HP ............................................. 52 5.4.1 Quality Center by HP im SAP-Projekt der Endress+Hauser Group ............................................ 53 5.4.2 SAP Quality Center by HP im SAP-Projekt des Outdoor-Bekleidungsanbieters Timberland ...... 55 BLACKBOX-TEST IM RAHMEN DER TESTAUTOMATISIERUNG ............................................. 57 6.1 VOR- UND NACHTEILE DER AUTOMATISCHEN TESTDURCHFÜHRUNG .......................................... 57 6.2 TESTDURCHFÜHRUNG MIT HILFE DES SAP SOLUTION MANAGERS ............................................... 58 6.2.1 Vorstellung des SAP Solution Managers....................................................................................... 58 6.2.2 Vorstellung der Test Workbench des SAP Solution Managers ...................................................... 58 6.2.3 Einführung in die Systemlandschaft mit Hilfe des SAP Solution Managers ................................. 59 6.3 NUTZUNG DER SAP ECATT ................................................................................................................. 60 6.3.1 Definitionen und Begrifflichkeiten ................................................................................................ 60 6.3.2 Vorgehensmodell zur Erstellung einer SAP eCATT-Testkonfiguration ........................................ 62 6.3.3 Systemdatencontainer und logischer Namen zur Zieldefinition .................................................... 62 6.3.4 Formulierung des Testskripts mit Hilfe von Attributen, Parametern und Kommandos ................ 65 6.3.5 Nutzung eines Testdatencontainers ............................................................................................... 72 6.3.6 Zusammenfassung aller Elemente im Testskript und Einhängen in die Test Workbench des Solution Managers ...................................................................................................................................... 74 6.4 PRAKTISCHE ERFAHRUNGEN ZUR NUTZUNG DER SAP ECATT ...................................................... 77 7 ZUSAMMENFASSUNG ........................................................................................................................... 78 8 LITERATURVERZEICHNIS .................................................................................................................. 80 III I. Abbildungsverzeichnis Abbildung 1: Übersicht ISO/IEC 9126 Qualitätsmodells (Quelle: Liggesmeyer, 2009, S. 17)...............4 Abbildung 2: Verlauf der Testzeit/Kostenverlauf (Quelle: Frühauf et al., 2007, S. 144). ......................6 Abbildung 3: Der Grundlegende Testprozess (Quelle: Sneed 2008, S. 12). ...........................................9 Abbildung 4: Ebenen des Testens (Quelle: Williams, 2006, S. 42).......................................................10 Abbildung 5: Testarten nach ihrer Konstruktionsmethodik (Quelle: Sneed et al., 2008, S. 169). ........11 Abbildung 6: Schematische Betrachtung Black-Box-Tests (Quelle: Eigene Abbildung nach Limaye, 2009). .................................................................................................................13 Abbildung 7: Beispiel eines Use-Case-Diagramm mit Zeichenerklärung (Quelle: Jeckle, 2005). ........21 Abbildung 8: Beispiel I für Ursache-Wirkungs-Diagramm am Beispiel "Auszahlung Prämie" (Quelle: Eigene Abbildung nach Liggesmeyer, 2009). ....................................................23 Abbildung 9: Beispiel II für Ursache-Wirkungs-Diagramm am Beispiel "Auszahlung Prämie" (Quelle: Eigene Abbildung nach Hoffmann, 2008). ........................................................23 Abbildung 10: Vollständige und paarweise Software-Tests im Vergleich (Quelle: Eigene Abbildung nach Hoffmann, 2008). ..................................................................................26 Abbildung 11: Orthogonales Array der Form Ln(kc) (Quelle: Eigene Abbildung nach Hoffmann 2008). ...............................................................................................................................27 Abbildung 12: Aufgefülltes Array mit Ausprägungen der Freiheitsgrade (Quelle: Eigene Abbildung nach Hoffmann 2008). ...................................................................................27 Abbildung 13: Paarweise vollständige Testmenge (Quelle: Angepasst nach Hoffmann 2008). ...........28 Abbildung 14: Fünf-phasige Vorgehensweise für Penetrationstests (Quelle: Informationstechnik, 2007, S. 47). ...................................................................................30 Abbildung 15: Prinzip eines Regressionstests (Quelle: Frühauf et al., 2007, S. 33). ............................32 Abbildung 16: Das allgemeine V-Modell (Quelle: Maiborn, 2009). .....................................................36 Abbildung 17: ASAP-Einführungsmethodik (Quelle: Steeb Anwendungssysteme GmbH, o.J.). .........38 Abbildung 18: Buttom-Up-Testmodell der ASAP-Methodik (Quelle: Eigene Abbildung nach Helfen et. al. 2010). ..........................................................................................................40 Abbildung 19: Modul Requirements im Quality Center (Quelle: Testing Concepts, 2011). ................44 Abbildung 20: Modul Test Lab im Quality Center (Quelle: QMETHODS - Business & IT Consulting GmbH, o. J. ). ................................................................................................46 IV Abbildung 21: Anhang zu Schritt 1 (Quelle: Eigene Abbildung). .........................................................47 Abbildung 22: Anhang zu Schritt 2 (Quelle: Eigene Abbildung). .........................................................48 Abbildung 23: Anhang zu Schritt 3 (Quelle: Eigene Abbildung). .........................................................48 Abbildung 24: Traditionelle Testbeschreibung (Quelle: Vivit Germany, 2008). ..................................49 Abbildung 25: Testbeschreibung bei Wiederverwendbarkeit von Funktionen (Quelle: Vivit Germany, 2008)................................................................................................................50 Abbildung 26: Teststatus pro Test Set (Quelle: Eigene Abbildung). ....................................................51 Abbildung 27: Übersicht der Fehlermeldungen pro zugeordneten Spezialist (Quelle: Eigene anonymisierte Abbildung). ...............................................................................................51 Abbildung 28: Vor- und Nachteile der automatischen Testdurchführung (Quelle: Eigene Abbildung). ......................................................................................................................57 Abbildung 29: Objekte in der SAP Test Workbench (Quelle: Eigene Abbildung nach SAP AG, 2006). ...............................................................................................................................59 Abbildung 30: Solution Manager als zentrale Verwaltungsinstanz (Quelle: Eigene Abbildung). ........60 Abbildung 31: Vorgehen zur Erstellung einer Testserie (Quelle: Eigene Abbildung). .........................62 Abbildung 32: RFC-Destination – Technische Einstellungen (Quelle: Eigene Abbildung). ................63 Abbildung 33: RFC-Destination - Anmeldung & Sicherheit (Quelle: Eigene Abbildung). ..................64 Abbildung 34: Funktionsweise des Systemdatencontainers (Quelle: Eigene Abbildung nach SAP AG, 2006). ...............................................................................................................65 Abbildung 35: Transaktion SECATT – Systemdaten (Quelle: Eigene Abbildung). .............................65 Abbildung 36: Systemdatencontainer – Systemdaten (Quelle: Eigene Abbildung). .............................65 Abbildung 37: Aufbau eines Testskripts (Quelle: Eigene Abbildung nach SAP AG, 2006). ...............66 Abbildung 39: Testskript - Attribute - Allgemeine Daten (Quelle: Eigene Abbildung). .......................66 Abbildung 40: Auswahl des Musters SAPGUI (Quelle: Eigene Abbildung). .......................................67 Abbildung 41: Auswahl der Aufzeichnungstiefe (Quelle: Eigene Abbildung). ....................................68 Abbildung 42: Editor - eingefügte Kommandoschnittstellen (Quelle: Eigene Abbildung). ..................69 Abbildung 43: Kommandoschnittstelle (Quelle: Eigene Abbildung). ...................................................70 Abbildung 44: Kommandoschnittstelle – Parametrisierung (Quelle: Eigene Abbildung).....................70 Abbildung 45: Parameteransicht (Quelle: Eigene Abbildung). .............................................................70 Abbildung 46: Muster einfügen – Log (Quelle: Eigene Abbildung). ....................................................71 V Abbildung 47: Parameter importieren (Quelle: Eigene Abbildung). .....................................................72 Abbildung 48: Aufruf der Funktion Varianten herunterladen (Quelle: Eigene Abbildung). ................72 Abbildung 49: Excel-Datei zum Varianten-Upload (Quelle: Eigene Abbildung). ................................73 Abbildung 50: Aufruf der Funktion Varianten hochladen (Quelle: Eigene Abbildung). ......................73 Abbildung 51: Variantenübersicht (Quelle: Eigene Abbildung). ..........................................................73 Abbildung 52: Testkonfiguration – Konfiguration (Quelle: Eigene Abbildung). .................................74 Abbildung 53: Startoptionen (Quelle: Eigene Abbildung). ...................................................................75 Abbildung 54: Protokoll (Quelle: Eigene Abbildung). ..........................................................................76 Abbildung 55: Transaktion SOLAR02 – Konfiguration (Quelle: Eigene Abbildung). .........................76 Abbildung 56: Transaktion SOLAR02 - Konfiguration – Testfälle (Quelle: Eigene Abbildung).........77 VI II. Tabellenverzeichnis Tabelle 1: Beispiel-Testfälle zu Äquivalenzklassen (Quelle: Eigene Tabelle). ....................................18 Tabelle 2: Beispiel zur zweidimensionalen Äquivalenzklassenabbildung (Quelle: Eigene Tabelle). ................................................................................................................................19 Tabelle 3: Vorlage für Entscheidungstabelle (Quelle: Eigene Tabelle nach Franz, 2007) ....................24 Tabelle 4: Entscheidungstabelle für das Beispiel "Auszahlung Prämie"(Quelle: Eigene Tabelle nach Franz, 2007) .................................................................................................................24 Tabelle 5: Beispiel einer Testbeschreibung (Quelle:Eigene Tabelle). ..................................................45 Tabelle 6: Voraussetzungen für den Einsatz des eCATT (Quelle: Eigene Tabelle). ............................61 Tabelle 7: Parameterwerte zur Laufzeit (Quelle: Eigene Tabelle nach SAP AG, o.J). .........................71 VII III. Abkürzungsverzeichnis Abkürzung Bedeutung ASAP Accelerated SAP BADI Business Application Add-In BAPI Business Application Programming Interface eCATT Extended-Computer Aided Test Tool IEC International Electrotechnical Commission (Normungsgremium) ERP Enterprise Resource Planning ISO International Organization for Standardization (Normungsgremium) RFC Remote Function Call VIII Black-Box-Testing 1 Einleitung und Problemstellung Die vorliegende Abhandlung wurde im Rahmen des Masterstudiums im Modul '2240 Formale Methoden' an der Hochschule Wismar erstellt und beschäftigt sich mit dem BlackBox-Test als Verfahren zum Test von Software. Hierzu wird im folgenden Kapitel einleitend auf die Qualität von Software, die unterschiedlichen Teststrategien, die Testplanung und die verschiedenen Testmethoden eingegangen, bevor im darauffolgenden Kapitel die theoretischen Grundlagen und Werkzeuge zum Black-Box-Test dargestellt werden. Anschließend wird der praktische Einsatz der BlackBox-Tests in einem SAP-Projekt vorgestellt und die Nutzung des SAP Quality Center by HP zur Testunterstützung sowie die praktischen Erfahrungen beim Einsatz des Werkzeugs beschrieben. Das vorletzte Kapitel beschäftigt sich mit der Testautomation im Rahmen von Black-Box-Tests und stellt hierzu das SAP Extended-Computer Aided Test Tool zur Abbildung selbiger vor und beschreibt ebenfalls praktische Erfahrungen mit dem Werkzeug, bevor abschließend die Abhandlung mit einer Zusammenfassung beendet wird. -1- Black-Box-Testing 2 Qualität von Software Der Qualitätsbegriff hat im Alltags- und Berufsleben einen hohen Stellenwert für viele Menschen. Insbesondere in Ländern mit einem hohen Technologie- und Lebensstandard steht Qualität in unmittelbarem Zusammenhang mit der Sicherheit von Mensch, Technik und Umwelt. Dennoch wird der Begriff sehr unterschiedlich gedeutet, abhängig von der jeweiligen Anwendungssituation, dem Bedarf der Anwender und dem entsprechenden Qualitätsverständnis (Petrasch, 2001). Zahlreiche Definitionen, die sich in der Literatur zum Begriff Qualität finden lassen, spiegeln dieses wider (siehe z. B. Redaktion, 2000; Geiger & Kotte, 2005; Liggesmeyer, 2009). Aus dem lateinischen Wort von Qualitas abgeleitet bedeutet Qualität soviel wie Beschaffenheit und wird häufig mit dem Wert oder der Güte eines Objekts gleichgesetzt (vgl. Geiger & Kotte, 2005, S. 69). Auch im Zusammenhang mit Software hat die Beschaffenheit und damit die Qualität des Produkts eine hohe Bedeutung. Vor diesem Hintergrund haben sich unterschiedliche Standardisierungsorganisationen mit dem Qualitätsbegriff im Allgemeinen, aber auch mit dem Begriff der Softwarequalität im Speziellen auseinandergesetzt und versucht Standardisierungen und Hilfestellungen durch Begriffsdefinitionen und Verfahrensanweisungen zu liefern. Hierzu gehören namhafte Organisationen wie beispielsweise das DEUTSCHE INSTITUT FÜR NORMUNG (DIN), die INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO), das AMERICAN NATIONAL STANDARDS INSTITUTE (ANSI) oder das INSTITUTE OF ELECTRIC AND ELECTRONIC ENGINEERS (IEEE). Darüber hinaus gibt es zahlreiche SoftwareQualitätsstandards die durch Organisationen, Behörden oder andere Gremien geschaffen worden sind und beispielsweise im Rahmen von Projektaufträgen für Dienstleister zur Anwendung kommen (z. B. NORTH ATLANTIC TREATY ORGANIZATION, USVERTEIDIGUNGSMINISTERIUM). Entsprechend der zahlreichen Software-Qualitätsstandards existieren auch viele Definitionen des Begriffs Software-Qualität, nachfolgend anhand der ISO/IEC-Norm 9126 dargestellt (Hoffmann, 2008, S. 6): „Software-Qualität ist die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte Erfordernisse zu erfüllen.“ Im Allgemeinen lässt sich daraus ableiten, dass das Ziel des Software-Qualitätsmanagements darin begründet liegt, die Erfüllung der definierten Softwareprodukteigenschaften sicherzustellen. In der Praxis reduziert sich diese Sichtweise jedoch sehr häufig auf das Kriterium der funktionalen Fehlerfreiheit, da dieses Qualitätsmerkmal für den Anwender einer Software i. d. R. sehr leicht erkennbar ist. Daher wird Softwarequalität oftmals mit dem Kriterium der funktionalen Fehlerfreiheit gleichgesetzt. -2- Black-Box-Testing Dieses eine Kriterium mag für den Anwender einer Software zentral sein, um die Qualität einer Software zu beurteilen, umfasst aber nur ein kleines Spektrum der Kriterien, die zu Grunde gelegt werden können. Wichtige Merkmale, die zur Beurteilung der Qualität von Software herangezogen werden können, fasst Hoffmann wie folgt zusammen (vgl. Hoffmann, 2008, S. 7ff.): Funktionalität (Functionality, Capability): Stellt ein Maß für den Erfüllungsgrad und die Fehlerfreiheit einer Software dar. Laufzeit (Performance): Bildet ein Maß für die Laufzeitanforderungen an eine Software und ist besonders wichtig für das Echtzeitsystem. Zuverlässigkeit (Reliability): Stellt ein Maß für die Ausfallsicherheit und Stabilität einer Software dar. Ähnlich dem Laufzeitkriterium unterliegt es stark der Einwirkung von sekundären Einflussgrößen, z. B. Hardware. Benutzbarkeit (Usability): Bildet ein Maß die sich in direkter Interaktion zwischen Mensch und Maschine abspielen. Wartbarkeit (Maintainability): Bildet ein wichtiges Kriterium zur Bestimmung der Änderungs- und Erweiterungsfähigkeit von Software. Transparenz (Transparency): Stellt ein Maß für die Gradlinigkeit der programmiertechnischen Umsetzung von funktionalen Anforderungen dar. Übertragbarkeit (Portability): Stellt ein Maß für die Übertragbarkeit einer Software in ein anderes Betriebsumfeld dar und beschreibt damit den Grad der Plattformunabhängigkeit. Dieses Qualitätskriterium muss bereits im Rahmen der Softwarekonzeption und Entwicklung berücksichtigt werden und gehört damit in den Bereich der konstruktiven Qualitätssicherung (Hoffmann, 2008). Testbarkeit (Testability): Bildet ein Maß für die frühzeitige und einfache Erkennbarkeit von Fehlern im Rahmen des Testprozesses. Ein Kriterium, welches durch die agilen, testgetriebenen Entwicklungsprozesse an Bedeutung gewonnen hat, um auf diesem Weg qualitativ einen besseren Code, eine höhere Produktivität und leichtere Wartbarkeit zu erreichen. Dieses Qualitätskriterium wirkt damit bereits während des Entwicklungsprozesses der Software. Ähnliche Merkmalslisten finden sich auch bei anderen Autoren (s. a. Alpar et al., 2008). Auch in der ISO/IEC-Norm 9126 sind Qualitätsmerkmale definiert, die zur Beurteilung von Software dienen. Dabei unterscheidet die Norm zwischen interner und externer Qualität sowie der Benutzungsqualität: -3- Black-Box-Testing Abbildung 1: Übersicht ISO/IEC 9126 Qualitätsmodells (Quelle: Liggesmeyer, 2009, S. 17). Der Vorteil solcher Qualitätskriterienlisten oder -modelle liegt darin, dass sie einen Anhaltspunkt für die Wertung und Analyse von Softwareprodukten liefern, jedoch - und dies muss als Nachteil gewertet werden -, sind diese Qualitätskriterienlisten stark standardisiert und müssen spezifisch auf den Entwicklungsprozess angepasst werden. Die Bedeutung oder Beurteilung der Wichtigkeit der vorher genannten Kriterien können aus der Perspektive der jeweiligen Betrachter sehr unterschiedlich ausfallen, z. B. aus der Sicht eines Entwicklers, Administrators oder Anwenders. So sind beispielsweise für reine Anwender Kriterien, wie Funktionalität oder Benutzbarkeit sehr wichtig, während für Entwickler eher die Kriterien wie Wartbarkeit oder Testbarkeit von hoher Relevanz sind. Manchmal schließen sich auch bestimmte Kriterien gegenseitig aus, so muss z. B. eine leicht wartbare Software nicht zwangsläufig leicht portierbar sein. Vor diesem Hintergrund wird deutlich, dass das Verständnis über die Bedeutung und Wertigkeit von Qualitätskriterien sehr stark von der Perspektive des Betrachters bzw. der anzuwendenden Organisation abhängig ist. Daher lassen sich nur schwer ganzheitliche, allgemeingültige Qualitätsmerkmale definieren, da der optimale Erfüllungsgrad bestimmter Kriterien stark von der subjektiven Betrachtungsperspektive abhängig ist. Umso wichtiger ist es, dass die Qualitätskriterien, deren Ausprägung und Sicherung frühzeitig im Rahmen des Projekts definiert und festgelegt werden. Insbesondere der Qualitätssicherung kommt hierbei eine besondere Bedeutung bei. Sommerville (2007, S. 693) definiert die Qualitätssicherung daher auch wie folgt: „Qualitätssicherung ist der Prozess des Definierens, wie sich Softwarequalität erreichen lässt und wie die entwickelnde Organisation feststellt, dass die Software der erforderlichen Qualitätsstufe entspricht. -4- Black-Box-Testing Der Qualitätssicherungsprozess bezieht sich im Wesentlichen auf zwei Bereiche, die Produktund die Prozessqualitätsstandards (Wallmüller, 2001; Sommerville, 2007; Hoffmann, 2008). Diese Differenzierung macht deutlich, dass die Qualität einer Software nicht nur durch die eigentliche Qualitätssicherung des Produktes im Rahmen der Testphase beeinflusst wird, sondern auch durch Methoden und Verfahren vor und während der Umsetzung des Produkts sowie den Prozessen, die die Entwicklung des Produkts steuern und unterstützen. Hoffmann (ebenda, S.20) unterscheidet auf der Ebene der Produktqualität zudem zwischen konstruktiver und analytischer Qualitätssicherung, auf der Ebene der Prozessqualität zwischen Software-Infrastruktur und Managementprozesse. Während die Ebene der konstruktiven Qualitätssicherung Methoden und Techniken umfasst, die darauf ausgerichtet sind die Qualität des Produktes a priori zu beeinflussen, umfasst die analytische Qualitätssicherung Verfahren, die darauf ausgerichtet sind die Qualität der Software a posteriori zu bewerten. In diese Kategorie fallen auch die klassischen SoftwareTestverfahren, die im späteren Verlauf dieser Arbeit weitergehend erläutert werden. Auf der Ebene der Prozessqualität finden sich Verfahren, die während der Entstehung des Produkts Einfluss auf dessen Qualität besitzen. In den Bereich der Software-Infrastruktur gehören Verfahren und Maßnahmen, die Entwicklern bei ihren Tätigkeiten unterstützen, während im Bereich der Managementprozesse vor allem die Methoden und Vorgehensweisen zusammengefasst werden, die die Qualität von Softwareprojekten verbessern sollen. Um die Qualität von Software-Produkten zu erhöhen ergeben sich aus den vorhergenannten Ebenen der Produkt- und Prozessqualität zahlreiche Verfahren, Techniken und Ansätze. Diese sollen und können in der vorliegenden Arbeit nicht alle vertieft behandelt werden. Vielmehr fokussieren die nachfolgenden Kapitel auf die analytische Qualitätssicherung der Software und hier speziell auf Software-Tests mit Hilfe der „Black-Box-Testmethoden“. Dabei soll auch kurz beschrieben werden, wie Test-Strategien, -Prinzipien und -Methoden ineinander greifen. -5- Black-Box-Testing 3 Softwaretests 3.1 Testen Das Testen von Software ist ein wesentlicher Bestandteil der Qualitätssicherungsmaßnahmen in jedem Softwareentwicklungsprojekt. Nach (Alpar et al., 2008, S. 384) lässt sich das Testen wie folgt definieren: „Testen bezeichnet jede einzelne (im Allgemeinen stichprobenartige) Ausführung des Testobjekts, d. h. Komponente, integriertes Teilsystem oder System (in einer Version), um die (beobachteten) Ergebnisse im Hinblick auf gewisse Eigenschaften zu prüfen.“ Das Testen ist aus Qualitätsgesichtspunkten ein wichtiger Aspekt in jedem Software-Projekt, gleichzeitig aber auch sehr aufwandsintensiv. Die dabei entstehenden Kosten machen, abhängig von der geforderten Qualität und dem damit verbundenen Testaufwand, oftmals zwischen 40 und 60 Prozent des Gesamtprojektaufwands aus (Wallmüller, 2001; Sneed & Jungmay, 2006). Dennoch geht es im Wesentlichen nur um die Minimierung von Risiken, da es die 100 Prozent fehlerfreie Software nicht gibt (Bayer, 2005; Bieber, 2011). Zwar kann durch Tests das Vorhandensein von Fehlern festgestellt werden, die Abwesenheit lässt sich auf diesem Weg aber nicht ausschließen. Das Ziel kann daher nur sein, die Wahrscheinlichkeit möglicher Fehler und Fehlerquellen zu minimieren und so für den betrieblichen Einsatz hinreichend vorzubereiten (Sommerville, 2007). Die nachfolgende Abbildung verdeutlicht noch einmal den Zusammenhang zwischen Kosten/Aufwand auf der einen Seite und der Anzahl gefundener Fehler auf der anderen Seite. Abbildung 2: Verlauf der Testzeit/Kostenverlauf (Quelle: Frühauf et al., 2007, S. 144). Daher ist es wichtig die richtige Teststrategie, -planung und –methode zu wählen, so dass Aufwand und Nutzen in einem möglichst optimalen Verhältnis zueinander stehen. Vor diesem -6- Black-Box-Testing Hintergrund wurden auch Methoden entwickelt, die zur Aufdeckung von Redundanzen innerhalb von Testfällen und –daten dienen und auf die im späteren Verlauf dieser Arbeit noch eingegangen werden soll. Vor diesem Hintergrund ist es wichtig die Arbeit des Tests nicht als Tätigkeit zu verstehen die ihren Sinn darin hat zu demonstrieren, dass keine Fehler vorhanden sind. Vielmehr liefert das Testen einen Mehrwert in Bezug auf die Qualität einer Software (Myers et al., 2004, S. 10): „When you test a program, you want to add some value to it. Adding value through testing means raising the quality or reliability of the program. Raising the reliability of the program means finding and removing errors. “ In Anlehnung an Wallmüller (2001, S. 261 ff.) sollten dabei zahlreiche Bereiche beachtet werden, die Prozess des Testens von Software eine Bedeutung haben: Testprinzipien und -strategie Testphasen Zeitpunkt der Beteiligung Etat und Planung Technik zur Testfallermittlung Statische Testtechniken Metriken Testwerkzeuge Testumgebung Testarbeitsplatz Engagement und Motivation Testfunktionen und Ausbildungen Reichweite der Methodik Kommunikation Berichterstattung Feststellungsverwaltung Testwaremanagement Prüfen Testmethoden In der Praxis besitzen nicht immer alle der hier genannten Bereiche eine gleichhohe Relevanz oder treten in Erscheinung. Im Rahmen der vorliegenden Arbeit soll nachfolgend nur auf die Bereiche eingegangen werden, die für das theoretische Verständnis des Testprozesses und der Black-Box-Testmethoden wichtig sind, nämlich die Teststrategie, Testphasen und Testmethoden. In den späteren Kapiteln wird dann noch einmal auf die Testwerkzeuge und Testumgebungen eingegangen. 3.2 Testprinzipien und –Strategie Im vorherigen Abschnitt wurde bereits darauf hingewiesen, dass Software nie 100 Prozent fehlerfrei ist und es im Rahmen des Testens von Software um die Minimierung von Risiken in Bezug auf gravierende Fehler geht. Während die ersten Fehler mit relativ geringem Aufwand zu finden sein werden, wird der Testaufwand für die letzten Prozent unverhältnismäßig hoch sein. Die Teststrategien sollten also darauf ausgerichtet sein, die essentiellsten Fehler so früh wie möglich und mit möglichst geringem Aufwand zu finden. Die Teststrategie bestimmt daher welche (Qualitäts-)Risiken abgedeckt werden müssen (Wallmüller, 2001). Ermöglicht wird diese durch eine effektive Teststrategie, die verschiedene Testverfahren und Testtechniken miteinander kombiniert (Cleff, 2010). -7- Black-Box-Testing Zumeist orientieren sich Teststrategien an einem definierten Vorgehensmodell, dennoch lassen sich verschiedene, prototypische Teststrategieansätze unterscheiden, die allerdings nicht immer überscheidungsfrei sind (vgl. Cleff, 2010, S. 215ff.).: Analytische Teststrategien: Tests werden durch Analyse und Bewertung verfügbarer Software-Artefakte (z. B. ein Software-System oder -Modul, ein Anforderungs- oder Entwicklungsdokument) abgeleitet. Fehler- und Erfahrungsbasierte Teststrategien (auch heuristisches Verfahren genannt): Tests werden auf Basis von bekannten Fehlern oder Erfahrungswerten abgeleitet. Reaktive und vorbeugende Teststrategien: Die Testplanung und -durchführung findet nach Beendigung oder zu einem frühen Zeitpunkt des Entwicklungsprozesses statt. Modellbasierte Teststrategien: In der objektorientierten Entwicklung weitverbreitete Strategie, bei der das ausführbare Software-Modell und seine verschiedenen Arten als Testbasis fungiert. Aus den jeweiligen Teststrategien ergeben sich häufig schon die grundsätzliche methodischen Richtung für das Testen der Software. Unabhängig vom eigentlichen Vorgehen lassen sich darüber hinaus ein paar grundsätzliche Prinzipen für das Testen von Software definieren (vgl. Alpar et al., 2008, S. 385): Die Testaktivitäten sollten sich an Anforderungen des Produkts orientieren. Eine Planung geht immer den Testaktivitäten voraus. Beim Testen gilt das Pareto-Prinzip: 80% der Fehler werden durch 20% der Software verursacht. Die Fehler innerhalb des Produktes können nie alle aufgedeckt werden. Das Testen erfolgt immer vom Kleinen zum Großen, d. h. von den Komponenten zum Gesamtsystem. Das Testen sollte möglichst durch unabhängige Dritte erfolgen. Die Wahrscheinlichkeit unbekannte Fehler zu finden ist abhängig von der Güte des Tests. Ähnliche Zusammenfassungen finden sich auch bei anderen Autoren (s. a. Myers et al., 2004; Limaye, 2009; Desikan & Ramesh, 2008). 3.3 Testphasen Wie bereits erläutert sind Tests wichtige Elemente im Rahmen der Qualitätssicherung von Softwareprojekten und daher von hoher Bedeutung für den Gesamtprojekterfolg. Der eigentliche Ablauf von Tests ist indes immer ähnlich und wird abhängig vom gewählten Vorgehensmodell geplant. Nachfolgend werden die Phasen des Testprozess nach Sneed et. al. (2008) kurz skizziert: Hiernach besteht der Testprozess aus den drei zentralen Schritten Planung, Durchführung und Auswertung, die ergänzt werden durch die Spezifikation der Testfälle sowie der Protokollierung der Ergebnisse (siehe auch Abbildung 3). -8- Black-Box-Testing Die Planung der Tests ist Bestandteil der Projektplanungsphase und inkludiert alle notwendigen Ressourcen, wie Personen, Testwerkzeuge, Daten usw. Wie bereits angedeutet ist ein vollständiger Test einer Software i. d. R. nicht möglich, daher müssen entsprechende Strategien gefunden werden, die Testaufwand, -methode, -priorität bestimmen. Im Rahmen der Testspezifikation werden Testfälle auf Basis der festgelegten Testmethodik definiert. Die Durchführung umfasst den konkreten Ablauf der Tests auf Basis der Testspezifikationen. Die Ergebnisse sollten dabei genauestens und vollständig dokumentiert werden, so dass nach Abschluss der Tests die Auswertung der Ergebnisse Aussagen über den Erfüllungsgrad der Tests liefern. Um den Gesamtprozess flexibel zu halten, ist es möglich in jedem der einzelnen Prozessschritte auf vorgelagerte Prozessschritte oder zum Beginn des Testprozesses zurückzuspringen (siehe Abbildung 3). Abbildung 3: Der Grundlegende Testprozess (Quelle: Sneed 2008, S. 12). Ähnliche Beschreibungen zum Ablauf des generischen Testprozesses finden sich auch bei andere Autoren (Pol et al., 2002; Alpar et al., 2008). 3.4 Testmethoden (Black-Box- vs. White-Box- und Grey-Box-Test) Nachdem im Abschnitt 3.2 bereits auf Teststrategien und Prinzipien eingegangen wurde, soll in diesem Abschnitt kurz die unterschiedlichen Kategorien der Testmethoden diskutiert werden bevor in den nachfolgenden Kapiteln die Black-Box-Tests erst theoretisch und dann im praktischen Einsatz behandelt werden. Nach Hoffmann (2008, S. 158) lassen sich die unterschiedlichen Testarten in drei Kategorien einteilen, die abhängig von der Einteilung nach entsprechenden Ordnungskriterien sind: -9- Black-Box-Testing Prüfebene: Differenziert nach der Entwicklungsphase in der der Test durchgeführt wird, z. B. Abnahmeebene, Systemebene, Integrationsebene. Prüfkriterien: Differenziert nach den inhaltlichen Aspekten nach denen getestet wird, z. B. Funktional, Operational, Temporal. Prüfmethodik: Differenziert nach den Methoden und den Techniken die zur Testfallkonstruktion genutzt werden, z. B. Black-Box-Tests, White-Box-Tests, GreyBox-Tests. Jedoch besteht in der Literatur keine einheitliche Auffassung in Bezug auf die Kategorisierung von Testarten. Sneed et al. (2008) unterscheiden zwischen drei Kategorien und ordnen diesen auch direkt Zuständigkeiten zu: Unittest (White-Box-Test, Entwickler), Integrationstests (Grey-Box-Tests, Entwickler oder Tester) und Systemtest (Black-Box-Test, Tester). Während auf Softwaretestingfundamental.com (softwaretestingfundamentals, 2011) Black-Box Tests als Methode für das „Higher Level Testing“ beschrieben werden, zu dem Akzeptanztests und Systemtests zählen, wird das White-Box-Testing als Methode für das „Lower Level Testing“ beschrieben und daher für Unittests und Integrationstests genutzt. In eine ähnliche Richtung geht der Ansatz von Black (2009) der die „Testgranularität“ als Differenzierungskriterium einführt. Der Begriff Granularität zielt auf die Komplexität und Elemente eines Systems ab und stuft die Testebene ab, vom Programmcode hin zum vollfunktionsfähigen Gesamtsystem. Dabei werden die drei Ebenen Strukturelle Tests (White-Box), Verhaltenstest (Black-Box) und Live-Test (Alpha, Beta oder Akzeptanztest) unterschieden. Eine etwas differenzierte Sicht auf die Granularität finden man bei William (2009), wie die nachfolgende Tabelle aufzeigt: Abbildung 4: Ebenen des Testens (Quelle: Williams, 2006, S. 42). Nachfolgend wird die Kategorisierung nach Prüfmethodik als Mittel zur Differenzierung von Testarten verwendet und weitergehend dargestellt. Hierbei lassen sich im Wesentlichen drei Gruppen von Tests unterscheiden: Black-Box-Tests, White-Box-Tests und Grey-Box-Tests (s. a. Abbildung 5). - 10 - Black-Box-Testing Abbildung 5: Testarten nach ihrer Konstruktionsmethodik (Quelle: Sneed et al., 2008, S. 169). Black-Box-Testen: Das Black-Box-Testen stellt eine Software-Testmethode dar, bei welcher die innere Struktur, das Design und die Art der Implementierung dem Testenden nicht bekannt sind. Daher sind auch keine Kenntnisse über Programmierung oder Implementierung notwendig. Für die Konstruktion von Testfällen wird das Ein- und Ausgabeverhalten der Software herangezogen, daher wird diese Art des Tests auch als „data-driven“ oder als „input/output- driven testing“ bezeichnet (Myers et al., 2004). White-Box-Testen: Das White-Box-Testen stellt im Gegensatz zum Black-Box-Testen eine Software-Testmethode dar, bei der die innere Struktur, das Design und die Art der Implementierung dem Testenden bekannt sind. Zur Testfallkonstruktion werden bestimmte Aspekte des Programm-Codes herangezogen, daher wird diese Art des Tests auch als „logicdriven testing“ bezeichnet (Myers et al., 2004). Hoffmann (2008, S.174) unterscheidet zudem kontrollflussorientierte oder datenflussorientierte White-Box-Tests. Grey-Box-Testen: Als Kombination aus Black-Box- und White-Box-Testen bildet das GreyBox-Testen eine halb-transparente Sichtweise auf das System ab. Ein Beispiel hierfür wäre z. B. wenn der Quellcode von zwei Modulen per Testverfahren analysiert würde, für die Erstellung von Testfällen und das tatsächliche Test werden die vorhandenen Schnittstellen verwendet (softwaretestingfundamentals, 2011; Hoffmann, 2008). Es sei an dieser Stelle darauf hingewiesen, dass Black-Box-Tests keine Alternative für WhiteBox-Tests und umgekehrt ist (Dustin et al., 2001). Häufig berücksichtigt die Einstufung der Testarten auch gleichzeitig eine Zuordnung der idealen Tester, so dass für White-Box-Test in der Regel Entwickler, System- oder Datenbankadministratoren vorgeschlagen, während bei Black-Box-Tests idealerweise, unabhängige Tester, Testingenieure oder Kunden empfohlen werden (Sneed et al., 2008; Black, 2009; softwaretestingfundamentals, 2011). - 11 - Black-Box-Testing Das Testen von Software ist eine wichtige Technik um die angestrebte Qualität von SoftwareProdukten sicherzustellen. Vor diesem Hintergrund wurden in dem zurückliegenden Kapitel einige wichtige Aspekte zu Teststrategien, -prinzipien und -methoden dargestellt, um so in die grundsätzliche Systematik von Testtechniken einzuleiten. Auf dieser Basis wird nun im nachfolgenden Kapitel auf einzelne Black-Box-Testverfahren erläuternd eingegangen. - 12 - Black-Box-Testing 4 Funktion und Anwendung von Black-Box-Testing 4.1 Definition Black-Box-Testing Im vorherigen Kapitel wurde bereits kurz auf das Black-Box-Testing eingegangen. Im Folgenden soll diese Kategorie von Testarten näher erläutert werden. Wie bereits erläutert fasst diese Methodik Testarten zusammen, bei denen das Produkt, also die zu testende Software, als eine Art nicht-einsehbares Objekt betrachtet wird dessen interne Struktur, Aufbau und Ablauf unbekannt sind. Stattdessen konzentriert sich die Arbeit des Testers auf das Auffinden von unspezifischen Verhaltensweisen, in denen sich das Produkt nicht der Anforderungsspezifikation oder den allgemeinen Vorgaben entsprechend verhält. Daher verwenden Black-Box-Tests nur etablierte und zugängliche Schnittstellen, wie z. B. Benutzerschnittstellen oder Schnittstellen für die Anwendungsprogrammierung (API) ( Hoffmann, 2008; Limaye, 2009; Myers et al., 2004; Dustin et al., 2001). Die nachfolgende Definition von Williams fasst diese Sichtweise noch einmal zusammen (Williams, 2006, S. 37): „Black box testing (also called functional testing) is testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions.“ Vor diesem Hintergrund wird für die Erstellung von Testfällen allein das Ein- und Ausgabeverhalten des Produkts verwendet, um die vorgegebenen Anforderungen vollständig abzuprüfen. Die nachfolgende Grafik verdeutlicht noch einmal schematisch diesen Zusammenhang, dabei kann die „Black-Box“ für jede zu testende Software stehen, z. B. ein Betriebssystem, kundenbezogenes SAP-System oder eine Web-Applikation: Abbildung 6: Schematische Betrachtung Black-Box-Tests (Quelle: Eigene Abbildung nach Limaye, 2009). Zumeist wird beim Erstellen der Testfälle auf Benutzerszenarien oder tatsächliche Benutzerinteraktionen zurückgegriffen. Dustin et. al. führen hierzu einige typische Beispiele für Fehler auf (Dustin et al., 2001): - 13 - Black-Box-Testing Inkorrekte oder fehlende Funktionalität Schnittstellenfehler Probleme im Zusammenhang mit Benutzerschnittstellen (Usability) Leistungsabfall Fehler beim Sichern oder Laden Probleme beim Mehrbenutzerzugriff Sicherheitsprobleme Speicherüberlauf Um solche Fehler zu erzeugen haben sich zahlreiche Techniken herausgebildet, die Anwendung bei der Fehlervalidierung finden. Der Begriff Technik umschreibt an dieser Stelle allerdings kein spezielles Werkzeug, sondern lediglich „handwerkliche“ Techniken zur Durchführung bestimmte Black-Box-Tests. Nachfolgend sind einige wichtige Techniken kurz erläutert (Michael & Radosevich, 2009)): Eingabe-Überprüfung und -Validierung Angriff per SQL-Insertion: Sicherheitslücke bei SQL-Datenbanken-Entwicklungen, die durch mangelnde Maskierung oder Überprüfung von Metazeichen in den Benutzereingaben entsteht Validierungstest für Cookie und Session-Management Cross-Site-Scripting-Angriffe: Fehler, die es ermöglichen Informationen aus einem nicht vertrauenswürdigen Zusammenhang, in einen vertrauenswürdigen Kontext einzubringen Buffer-Overload-Angriffe: Fehler, die bei zu große Datenmengen entstehen, für die eine zu kleiner Speicherbereich reserviert wurde Directory-Traversal-Angriff: Suchen nach Sicherheitslücken in Web-Programmen durch Manipulation von Pfadangaben, Protokollen usw. Wie bereits dargelegt, kommt beim Black-Box-Testverfahren der Anforderungsdefinition eine besondere Bedeutung zu. Damit wird die Anforderungsdefinition zu einem zentralen Element der frühzeitigen Lenkung der späteren Softwarequalität und zwar nicht nur aus der Perspektive der erfolgreichen technischen Systementwicklung, sondern auch aus der Perspektive des Systemtestens. Daher bilden hochwertige Anforderungsdefinitionen ein probates Instrument zur Minimierung der Projektrisiken. Vor diesem Hintergrund wurden Ansätze entwickelt die Qualität der Anforderungen sowie deren Dokumentation zu bewerten und auf diesem Wege Steuerungsmechanismen zu besitzen. So lassen sich qualitative Kenngrößen durch Qualitätsmetriken für Anforderungen oder Anforderungsdokumente in Zahlenwerte abbilden und diese für die Beurteilung des Erfüllungsgrads von Qualitätseigenschaften nutzen (Rupp & Die SOPHISTen, 2009). 4.2 Vor- und Nachteile von Black-Box-Tests Mit der beschriebenen Art von Tests sind einige Vor- und Nachteile verbunden, die nachfolgend kurz erläutert werden und denen man sich bewusst sein sollte. - 14 - Black-Box-Testing Zu den Vorteilen von Black-Box-Tests können die folgenden Aspekte gezählt werden (Desikan & Ramesh, 2008; Bender, 2005): Grundsätzlich ist kein besonderes Vorwissen zur Anwendung oder sind spezielle Kenntnisse über die Programmierung notwendig. Daher können Endanwender oder neutrale Prüfer für das Testen verwendet werden. Das Vorhandensein von Anforderungsspezifikationen hilft bzw. unterstützt bei der Erstellung von adäquaten Testfällen. Gleichzeitig hilft es auch bei der Prüfung der Anforderungsspezifikation auf Unvollständigkeit oder auf nicht-valide Anforderungen. Black-Box-Tests helfen dabei das gesamte Funktionsspektrum eines Software-Produkts abzudecken. Da es natürlich ist, dass ein Anwender Fehler im Umgang mit einer Software macht, schließen die Tests richtige und falsche Eingaben ein und testen die Software auf eine natürliche Weise. Automatisierung durch Eingabe/Ausgabe-Logik: Die zu Grunde liegende Eingabe-/ Ausgabe-Logik von Black-Box-Test ermöglicht Testautomatisierungen durchzuführen Zu den Nachteilen von Black-Box-Tests zählen die folgende Punkte (Desikan & Ramesh, 2008); Bender, 2005): Die Hauptschwierigkeiten liegt darin geeignete Testfälle und Testdaten auszuwählen, um so eine möglichst hohe Fehlererkennungsrate zu erreichen. Die Ursachen von erkannten Fehlern können nicht direkt hergeleitet werden, sondern erfordern tiefergehende Analysen. Es werden möglicherweise nicht alle Bereiche der Software getestet, da Anforderungen spezifiziert wurden. Es ist nicht immer ein Vorteil, wenn der Tester die Technologie oder die interne Logik nicht kennt, da dieser Umstand die Erstellung von speziellen Testfällen erschwert und ggf. dazu führt, wichtige Aspekte zu übersehen. Zusammenfassend lässt sich resümieren, dass vor dem Einsatz von Black-Box-Tests die Vorund Nachteile abgewogen werden sollten. Da die Ergebnisse der Tests abhängig von einer gut strukturierten Spezifikation sind, sollte im Vorfeld viel Sorgfalt in diese einfließen. BlackBox-Tests stellen einen sehr analytischen Ansatz dar und daher ist viel Erfahrungen bei der Testfallgenerierung voraussetzt. 4.3 Vorgehen bei Anwendung von Black-Box-Tests Die Vorgehensweise bei der Nutzung von Black-Box-Testverfahren unterscheidet sich nicht grundlegend von dem allgemeinen Verfahren (siehe Abschnitt 3.3). Die nachfolgenden Schritte beschreiben das generische Vorgehen bei einem Black-Box-Test und sind als Ergänzung zum allgemeinen Vorgehensmodell zu sehen: Analyse von Anforderungen und Spezifikationen Auswahl von positiven und negativen Eingabewerte Festlegung der erwarteten Ausgabewerte - 15 - Black-Box-Testing Zusammenführung ausgewählter Eingabewerte in definierte Testfälle Ausführung der Testfälle Analyse und Vergleich der tatsächlichen Ausgabewerten mit den erwarteten Ausgabewerten Abschluss sobald alle Testfälle durchgeführt wurden, ggf. Nachtests, falls Fehler auftreten 4.4 Typen von Black-Box-Testmethoden In der Praxis finden sich zahlreiche Beispiele und Anwendungsfälle von Black-BoxMethoden, von denen im Folgenden einige ausführlicher vorgestellt werden sollen. Zur Klassifizierung der einzelnen Testmethoden werden diese in drei Gruppen unterteilt: Funktionale Tests Nicht-Funktionale Tests Diversifizierungstests Diese Differenzierung wurde vor dem Hintergrund der Bedeutung der Anwendungsspezifikation für die Black-Box-Tests gewählt und orientiert sich damit an der üblicherweise verwendeten Strukturierung von Anforderungskonzepten, bei denen i. d. R. zwischen funktionalen und nicht-funktionalen Anforderungen differenziert wird. Hierhinter verbergen sich Verfahren, bei denen der Schwerpunkt der Tests auf funktionalen (z. B. System- und Funktionsverhalten) oder nicht-funktionalen Aspekten (z. B. Performance, Skalierbarkeit, Usability) in Bezug auf die Spezifikation beruht. Dabei kann üblicherweise die Anzahl der unterschiedlichen nicht-funktionalen Tests denen der funktionalen Test übersteigen. Diversifizierungstests bilden ein Sonderverfahren, bei denen mehrere Versionen eines Programms miteinander verglichen werden, z. B. Back-to-Back-Tests oder Regressionstests (Hoffmann, 2008). Es sei an dieser Stelle noch einmal darauf hingewiesen, dass in der Literatur keine Einheitlichkeit über die Klassifizierung und Strukturierung der Testverfahren besteht. Viele Autoren behandeln beispielsweise nicht-funktionale Tests nicht im Kontext von Black-BoxTestverfahren. Möglichweise liegt dies daran, dass in Anwendungsspezifikationen oftmals die nicht-funktionalen gegen die funktionalen Aspekte in den Hintergrund treten. 4.4.1 Funktionale Tests 4.4.1.1 Äquivalenzklassentest In den vorherigen Abschnitten wurde immer wieder auf die Notwendigkeit des Testens von Software-Produkten hingewiesen. Die Basis für das Testen bildet im Zusammenhang mit Black-Box-Tests die Anforderungsspezifikation, auf deren Basis Testfälle abgeleitet werden, um Aussagen über das erwartete Verhalten der Software liefern zu können. - 16 - Black-Box-Testing Wie viele Testfälle notwendig sind, um die größtmögliche Wirkung, aber den geringsten Aufwand zu erhalten, stellt in der praktischen Anwendung immer wieder eine zentrale und wichtige Frage dar, nicht zuletzt aus Kostengründen (siehe auch Kapitel 3). Vor diesem Hintergrund haben sich Verfahren etabliert, die sich mit der Frage der notwendigen Testfallanzahl (möglichst gering) und -abdeckung (möglichst groß) beschäftigen, wie der Äquivalenzklassentest. Für die Durchführung des Tests sind grundsätzlich zwei Schritte notwendig (vgl. Hoffmann, 2008, S. 177): 1. Die Äquivalenzklassenbildung: Hier wird der Bereich aller Eingangswerte in zwei Gruppen (Äquivalenzklassen) geteilt. Die Aufteilung bzw. die Zuordnung der Werte erfolgt auf Basis eines möglichen, gleichartigen Verhaltens im zu testenden SoftwareSystem. 2. Die Testfallkonstruktion: Aus jeder Äquivalenzklasse werden Werte ausgewählt, in konkrete Testfälle überführt, erwartete Soll-Ausgabewerte ermittelt und mit den erhalten Ist-Ausgabewerte vergleichen. In Anlehnung an Kleuker (2011, 270 ff.) sollen die nachfolgenden Beispiele dieses Verfahren für die ein- und mehrdimensionale Äquivalenzklassebildung näher erläutern: Eindimensionale Äquivalenzklassenbildung Im ersten Fall wird zunächst eine eindimensionale Äquivalenzklassenbildung betrachtet. In einer Verwaltungssoftware soll eine neue Funktion getestet werden. Diese Funktion soll Mitarbeiter-Emailadressen anlegen. Als Einschränkung gilt, dass das Namensfeld nicht leer sein darf. Daraus ergeben sich die beispielsweise folgenden Äquivalenzklassen: Ä.1) E-Mail-Adresse nicht leer (gültig) Ä.2) E-Mail-Adresse leer (ungültig) - 17 - Black-Box-Testing Und die nachfolgenden Tests: Testfallnummer 1 2 Äquivalenzklassennummer Ä.1 Ä.2 E-Mal-Adresse „[email protected]“ „“ Ergebnis Ok Abbruch Tabelle 1: Beispiel-Testfälle zu Äquivalenzklassen (Quelle: Eigene Tabelle). Treten die Ergebnisse beim Testen wie erwartet auf, so verhält sich das Programm wie spezifiziert bzw. erwartet. Mehrdimensionale Äquivalenzklassenbildung Im zweiten Fall wird zunächst eine mehrdimensionale Äquivalenzklassenbildung betrachtet. In der gleichen Verwaltungssoftware soll eine weitere Funktion getestet werden. Diese Funktion soll Abteilungen und Anzahl der Mitarbeiter anlegen. Einschränkungen sind, dass nur die folgenden Abteilungsbezeichnungen gültig sind (FI/CO, IT, HR) und die Anzahl der Mitarbeiter zwischen 0 und 300 sein muss. In diesem Fall ist der Äquivalenzklassenbildungsprozess etwas umfangreicher, da wir zwei Übergabeparameter und damit auch zwei Dimensionen erhalten (siehe Tabelle 2). Im Allgemeinen führt die Partitionierung von n Übergabeparametern zu n-dimensionalen Äquivalenzklassen (Hoffmann, 2008). Daraus ergeben sich die beispielsweise folgenden Äquivalenzklassen, da jeder Parameter des Wertebereichs separat behandelt werden muss: Ä.1) Bereich FI/CO (gültig) Ä.2) Bereich IT (gültig) Ä.3) Bereich HR (gültig) Ä.4) Bereich leer (ungültig) Ä.5) Mitarbeiter <0 (ungültig) Ä.6) Mitarbeiter zw. 0 und 300 (gültig) Ä.7) Mitarbeiter >300 (ungültig) Da bei einem Funktionsaufruf mehrere Werte übergeben werden können, können die Werte miteinander kombinieren, wie die nachfolgende zweidimensionale Matrix darstellt. - 18 - Black-Box-Testing Mitarbeiter kleiner 0 Mitarbeiter zw. 0 und 300 Mitarbeiter größer 300 Bereich = FI /CO Abbruch Ok Abbruch Bereich = IT Abbruch Ok Abbruch Bereich = HR Abbruch Ok Abbruch Bereich = „“ Abbruch Abbruch Abbruch Tabelle 2: Beispiel zur zweidimensionalen Äquivalenzklassenabbildung (Quelle: Eigene Tabelle). Wie zu Beginn dieses Abschnitts bereits erläutert können zusammengehörige Äquivalenzklassen, die zu gleichen Ergebnissen führen, miteinander verschmolzen und auf diesem Weg die Anzahl der Tests stark reduzieren. Bei gültigen Äquivalenzklassen gilt dies auch als probates Mittel, bei ungültigen Äquivalenzklassen muss man achtsamer sein, da der Abbruch für alle ungültigen Äquivalenzklassen in Kombination mit gültigen Äquivalenzklassen gelten muss (Kleuker, 2011). Zusammenfassend lässt sich festhalten, dass die Äquivalenzklassenbildung als werteorientiertes Testverfahren ein probates Mittel zur Optimierung des Testfall- / Testabdeckungs-Verhältnisses darstellt. Man sollte vor allem bei mehrdimensionalen Äquivalenzklassen darauf achten, dass die Verschmelzung von Äquivalenzklassen nicht zu komplex wird und im Zweifelsfall zu der ursprünglichen Betrachtung der Eingabeparameter zurückkehren. Da die Äquivalenzklassenbildung bei ganzzahligen numerischen Werten meistens leichter fällt als bei Nichtzahlenwerten (z. B. Text, Datum), ist eine gewissen Übung erforderlich, um mit dieser Methode gut umgehen zu können. 4.4.1.2 Grenzwertbetrachtung (Boundary-Value-Analyse) Bei genauerer Betrachtung des Beispiels aus dem vorherigen Kapitel könnten man sich die Frage stellen, ob es bei der Einschränkung „Anzahl der Mitarbeiter zwischen 0 und 300“ nicht sinnvoll wäre die oberen und unteren Grenzwerte für die Tests zu verwenden, also z. B. -1, 0 , 300, 301, um zu prüfen wie sich die Anwendung in den Grenzfällen der Wertebereiche verhält. Daher wurde der Äquivalenzklassentest um die Grenzwertbetrachtung erweitert. Der Unterschied liegt lediglich in der Art und Weise begründet, wie Testfälle gebildet werden Diese Testfallerstellungsstrategie resultiert aus der Erkenntnis, dass gerade im Randbereich von Variablen oder Algorithmen die meisten Fehler auftreten (vgl. Roitzsch, 2005, S. 343). Vor diesem Hintergrund ergeben sich die folgenden Grenzwertkonstruktionsregeln für eindimensionale Äquivalenzklassen (vgl. Limaye, 2009, S. 375ff.; Mathur, 2011, S. 119): 1. Wenn die Grenzen ein Kontinuum abschließen, sollte der innere und äußere Wert der unteren und oberen Grenze als Testfall verwendet werden. 2. Wenn die Grenzen Teil eines Diskontinuums sind, d. h. dass es mehrere Wertebereiche (z. B. 0 bis 5 und 10 bis 15) gibt, dann gilt für die einzelnen Wertebereiche die gleiche - 19 - Black-Box-Testing Regel wie unter 1., aber zusätzlich sollte ein Wert gewählt werden, der zwischen den Wertebereichen liegt 3. Wird eine Eingabe erforderlich, bei der nur ein spezifischer Wert richtig ist, dann sollte ein richtiger und zwei falsche Werte getestet werden. 4. Wird eine Aufzählung getestet oder eine Wahrheitswert (Boolean), dann reicht ein richtiger und ein falscher Werte zum Testen. Zwar sind nach Mathur (ebenda) eindimensionale Äquivalenzklassen zu bevorzugen, Hoffmann (2008, S. 181) liefert auch für mehrdimensionale Äquivalenzklasse eine Regel: 5. Testfälle werden gebildet aus dem Grenzwerte-Tupel sowie allen Tupeln, mit Einzelwerten außerhalb der Äquivalenzklasse. Bedauerlicher Weise besitzen Wertebereiche nicht immer Grenzen, sondern sind teilweise nach einer oder zwei Richtungen offen. In Bezug auf das Beispiel des vorherigen Abschnitts hätte die Anforderung auch lauten können, dass die Anzahl der Mitarbeiter größer oder gleich Null sein kann. In diesem Fall gibt es keine obere Grenze mehr. Bei offenen Wertebereichen führt man in diesem Fall eine „künstliche Grenzinduktion“ (Hoffmann, 2008, S. 183) durch, d. h. der Wertebereich wird willkürlich auf der einen Seiten begrenzen, um Äquivalenzklassen zu bilden. Zusammenfassend lässt sich festhalten, dass die Grenzwertbetrachtung, als Erweiterung der Äquivalenzklassenbildung, bei der Auswahl geeigneter Testfälle unterstützt. Richtig eingesetzt erhöht die Grenzwertbetrachtung die Wahrscheinlichkeit Fehler in Randbereichen von Funktionen zu finden und auszuschalten. Allerdings muss beachtet werden, dass nicht immer Grenzbereiche bestehen oder gebildet werden können, z. B. bei Textzuweisungen. Im numerischen Bereich ist es hingegen ein nützliches Hilfsmittel. 4.4.1.3 Use-Case-Test Use-Cases oder Anwendungsfälle werden meistens als Teil der Anforderungsermittlung in Zusammenarbeit mit dem Fachbereich bzw. dem Endnutzer erstellt und sind daher auch Bestandteil des Requirements-Engineering. Im Gegensatz zu den bisher betrachteten Verfahren, die sich im Wesentlichen darauf beschränkt haben einzelne Funktionen zu testen, bewegen sich die Use-Cases eher auf ein Modul oder System. Auf Basis der Anwendungsfälle lassen sich recht einfach sinnvolle Varianten der Anwendungsfälle ableiten und in konkrete Testfälle umwandeln. Zur grafischen Beschreibung von Anwendungsfällen werden sog. Use-Case-Diagramme verwendet, die die Beziehungen zwischen den Anwendungsfällen und Akteuren in den Grenzen des Systems darstellen (siehe Abbildung 7). - 20 - Black-Box-Testing Abbildung 7: Beispiel eines Use-Case-Diagramm mit Zeichenerklärung (Quelle: Jeckle, 2005). Use-Case-Diagramme sind Bestandteil der Unified Modeling Language (UML), die zurzeit in der Version 2.x vorliegt und als ISO-Standard (ISO/IEC 19501) akzeptiert ist (Oestereich, 2009). Der Verwendung von Use-Cases im Zusammenhang mit Black-Box-Tests macht es erforderlich, dass jeder Anwendungsfall in mindestens einen Testfall überführt wird. Voraussetzung dafür ist, dass Use-Cases auch alle wesentlichen Anforderungen an das System abbilden, eine nicht berücksichtigte Anforderung kann dann auch nicht getestet werden. Auch wenn Projekte keine Use-Cases verwenden, sondern die Anforderungen auf andere Weise aufnehmen, so können Use-Cases dabei helfen die aufgenommenen Anforderungen zu Funktionen zu bündeln. Ein anwendungsfallbezogenes Testvorgehen erfordert einen Prozess zu Identifizierung und Entwicklung Testfällen, Hoffmann (2008, S. 189) schlägt dafür die folgenden Schritte vor: Im ersten Schritt werden zunächst Wertebereiche für bestimmte Ablaufprozesse innerhalb des Use-Case-Diagramms definiert und analog der Äquivalentbildung (s. 4.4.1.1) aufgeteilt. Im zweiten Schritt werden dann für die Wertebereiche konkreten Eingabebelegungen ausgewählt. Dass sich auch hier Fehler an den Grenzen der Äquivalenzklassen finden lassen ist nicht unwahrscheinlich, was auch hier denn Einsatz der Grenzwertanalyse sinnvoll macht. Wie bereits dargelegt bildet das Use-Case-Verfahren eine gute Möglichkeit, die im Rahmen der Anforderungsanalyse geforderten Funktionen zu beschreiben. Wird dies allerdings nicht mit der erforderlichen Sorgfalt erfüllt, treten typische Probleme auf, wie z. B. nicht-adäquate Beschreibung von Variablen, unspezifische Beschreibungen von Funktionen oder nicht spezifizierte Geschäftsregeln. - 21 - Black-Box-Testing Zusammenfassend lässt sich über diese Testmethode sagen, dass Use-Cases einen einfachen Zugang zu den geforderten Anforderungen bieten und so die Funktionen eines Systems in einer gut verständlichen Form darlegen können. 4.4.1.4 Entscheidungstabellenbasierter Test Die entscheidungstabellenbasierte Testmethode ist ein funktionsorientiertes Verfahren und beruht darauf, Funktionen von Software-Produkten auf Basis von einfachen UrsacheWirkungs-Zusammenhängen abzubilden. Dabei werden mit einem Ursache-WirkungsDiagramm (engl. „Cause-Effect Graph“) die Beziehung zwischen Ursachen und ihren Wirkungen in Bezug auf die zu testende Software abgebildet. Ursachen und Wirkungen sind nur logische Größen, die „wahr“ und „falsch“ annehmen können, z. B. „ Konto aktiv“, „Ausweis ungültig“, „Konto gesperrt“. Wird das UrsacheWirkungs-Gefüge zu komplex, dann können Ursachen, die eine bestimmte Wirkung auslösen, auch in Haupt- und Nebenursachen zerlegt werden. Die Ursachen und Wirkungen werden in Tabellen überführt, um so ihre logische Beziehung darzustellen. Dabei wird für jede Bedingung eine separate Zeile erzeugt, jede Spalte repräsentiert dann die Bedingungskombination. Die Spalten werden mit Werten („wahr“ oder „falsch“) ausgefüllt, indem für jede Spalte ermittelt wird, welche Wirkung die gegebene Ursache auslöst (Hoffmann, 2008). Die Entscheidungstabelle kann nun zur systematischen Erstellung von Testfällen genutzt werden, die eine Kombination aller Ursachen (z. B. Eingabeoder Automatisierungsbedingungen) und daraus resultierenden Wirkungen darstellt. An einem einfachen Beispiel soll das Verfahren kurz erläutert werden (vgl. Cleff, 2010, S. 124). Dazu betrachten wir den Fall der Prämienauszahlung in einem Unternehmen. Diese erfolgt dann, wenn ein Mitarbeiter länger als 1 Jahr im Unternehmen ist (Bedingung 1) und die vereinbarten Ziele (Bedingung 2) auch erreicht wurden (Bedingung 3). Auf Basis der Aussagen kann nun ein Ursache-Wirkungs-Diagramm erstellt werden. Für die Art der Umsetzung eines Ursache-Wirkungs-Diagramms finden sich in der Literatur unterschiedliche Beispiele (siehe z. B. Liggesmeyer, 2009; Hoffmann, 2008). Zwei mögliche Varianten für das Fallbeispiel sind nachstehend dargestellt. - 22 - Black-Box-Testing Abbildung 8: Beispiel I für Ursache-Wirkungs-Diagramm am Beispiel "Auszahlung Prämie" (Quelle: Eigene Abbildung nach Liggesmeyer, 2009). Abbildung 9: Beispiel II für Ursache-Wirkungs-Diagramm am Beispiel "Auszahlung Prämie" (Quelle: Eigene Abbildung nach Hoffmann, 2008). Unabhängig von der Darstellungsart beschreibt das Ursache-Wirkungs-Diagramm nun grafisch, was vorher textal beschrieben wurde, nämlich dass die Prämienauszahlung nur dann erfolgt, wenn alle drei Bedingungen erfüllt sind. Ist allerdings eine Bedingung nicht erfüllt, dann ist die Wirkung nicht mehr gegeben. Überführt man das Ursache-Wirkungs-Diagramm in eine Tabellenform, dann ergeben sich unter Berücksichtigung, dass alle Bedingungen nur boolesche Werte („wahr“ oder „falsch“) annehmen können, aus n Bedingungen 2n Kombinationen, die in Spalten für Testfälle abgebildet werden. - 23 - Black-Box-Testing Zur Überführung in eine Tabellenstruktur wird die Entscheidungstabelle in vier Blöcke geteilt (vgl. Franz, 2007, S. 38): Ursache = Bedingung Regel = Testfall Wirkung=Aktion Entscheidung Tabelle 3: Vorlage für Entscheidungstabelle (Quelle: Eigene Tabelle nach Franz, 2007) Für das bisher verwendete Beispiel entstehen für 3 Bedingungen 23=8 Spalten. Daraus leitet sich die nachfolgend dargestellte Tabelle ab, die den Kombinationen aus dem Beispiel 2 des Ursache-Wirkungs-Diagramms entspricht: Ursachen T1 T2 T3 T4 T5 T6 T7 T8 B1 Beschäftigung länger als 1 Jahr W W W W F F F F B2 Ziel abgestimmt W W F F F W F W B3 Ziel erreicht W F W F F W W F W F F F F F F F W Auszahlung Prämie Tabelle 4: Entscheidungstabelle für das Beispiel "Auszahlung Prämie"(Quelle: Eigene Tabelle nach Franz, 2007) Auf Basis der vorliegenden Tabelle ergibt sich aus jeder Spalte ein entscheidungstabellenbasierter Test. In der Praxis werden allerdings in den wenigsten Fällen aus den Entscheidungstabelle alle Fälle für das Testen verwendet oder überhaupt in erst in eine Entscheidungstabelle überführt, da es funktionale Abhängigkeiten zwischen Eingangsbedingungen gibt oder Wechselwirkungen bestehen. Eine solche Situation gibt es auch in dem vorliegenden Beispiel, da im Fall T3 und T7 eine Situation beschrieben wird, die eigentlich nicht möglich ist, da hier ein Ziel erreicht wird, ohne dass vorher ein Ziel abgestimmt wurde. Damit reduziert sich die Anzahl der Tests auf 23-2 = 6 Testfälle. Die gleiche Anzahl hätte man auch erhalten, wenn die Tabelle aus dem Beispiel 2 des Ursache-Wirkungs-Diagramms (siehe Abbildung 9) abgeleitet worden wäre, da hier die Fälle T3 und T7 gar nicht aufgetreten wären, weil sie nicht abgebildet sind. Zusammenfassend lässt sich festhalten, dass die entscheidungstabellenbasierte Testmethode ein Möglichkeit bietet funktional abhängige Ursachen und daraus resultierende Wirkungen auf strukturiert und einfache Weise in Testfälle umzuformen. Dabei muss allerdings berücksichtigt werden, dass die Anzahl exponentiell steigt und daher schnell unübersichtlich wird. Es sollte also nach Vereinfachungen geschaut werden, um die Anzahl auf die notwendige Testfallanzahl zu reduzieren. - 24 - Black-Box-Testing Analog der bisher betrachteten Verfahren bietet diese Testmethode die Möglichkeit auf einfache Weise Anforderungen an das System in Testfälle zu überführen und mit dem tatsächlichen Verhalten abzugleichen. Jedoch gilt auch für diese Methode, dass hierfür die Qualität der Anforderungserfassung sehr wichtig ist. Bei der Entscheidungstabelle wurden die Bedingungen untersucht, welche Abhängigkeiten hatten. Bei dem paarweisen Testen wird nach unabhängigen Bedingungen gesucht, also dem genauen Gegenteil. 4.4.1.5 Paarweises Testen Beim paarweisen Testen erfolgt die Testkonstruktion auf Basis aller Kombination von zwei Bedingungen (Ausprägungspaar). „Die Idee des paarweisen Testens basiert auf einer empirischen Beobachtung: Versagt ein System unter einer gewissen Konfiguration seinen Dienst, so lassen sich in den allermeisten Fällen einzelne Faktoren identifizieren, die für das Fehlverhalten verantwortlich sind.“ (Hoffmann, 2008, S. 192ff.). Das paarweise Tests stellt eine Testmethode dar, die sowohl im Bereich der funktionalen wie nicht-funktionalen Tests (siehe Kapitel 4.4.2 Nicht-Funktionale Tests) eingesetzt wird. Das in diesem Abschnitt gewählte Beispiel kommt aus dem Bereich des Konfigurationstestens, eine Testmethode nicht-funktionaler Tests, verdeutlicht aber die Einsatzmöglichkeit dieser Testart auf eindringliche Art. Da es aber bei Programmen häufig eine Vielzahl von Kombinationsmöglichkeiten in Bezug auf die Eingaben oder beim Testen von Funktionen gibt, müssten alle Kombinationen geprüft werden. Dabei entsteht oftmals eine sehr große Anzahl an Testfälle, wie das folgende Beispiel nach Hoffmann (2008, S. 192 ff.) ausführlich darstellt: Eine Web-Anwendung soll mit gängigen Browsern (Explorer, Firefox, Safari), Betriebssystemen (Windows, Linux, OS X) kompatibel sein und mit den Browsersprachen Deutsch und Englisch betrieben werden können. Aus dieser recht einfachen Konfiguration entstehen schon 3*3*2 = 18 unterschiedliche Kombinationen. Bei größeren Systemen entstehen auf diesem Weg schnell sehr große Mengen an Tests, die nicht mehr mit sinnvollem Aufwand abgearbeitet werden können. Vor diesem Hintergrund muss eine Möglichkeit gefunden werden, die Testanzahl und damit den Aufwand auf ein Minimum zu reduzieren. Dies erfolgt durch Reduzierung der Testfälle bis jedes Ausprägungspaar durch einen entsprechenden Testfall abgedeckt ist (siehe Abbildung 10). - 25 - Black-Box-Testing Abbildung 10: Vollständige und paarweise Software-Tests im Vergleich (Quelle: Eigene Abbildung nach Hoffmann, 2008). Damit ist eine Tabelle gefunden, die jedes Ausprägungspaar abdeckt und damit ein vollständige Testmenge bildet. Somit kann diese Tabelle als valide Basis für das Testen der im Beispiel dargelegten Kombination aus Browser, Betriebssystem und Sprache verwendet werden. Da es in der Regel schwierig ist, insbesondere bei größeren Kombinationsvariationen, die richtigen Ausprägungspaare aus der Vielzahl von Kombinationen herauszufinden, soll nachfolgend das Verfahren nach Hoffmann vorgestellt werden (vgl. ebenda, S. 196 ff.). Bei dieser Vorgehensweise wird in drei Schritten eine vollständige Testmenge mit paarweisem Test konstruiert. Die Veranschaulichung der Vorgehensweise erfolgt anhand des vorher dargestellten Beispiels: 1. Es wird die Anzahl der Freiheitsgrade (c) und der maximalen Ausprägungen (k) eines orthogonalen Arrays der Form Ln(kc) gebildet. Für das vorliegende Beispiel besitzt die Applikation 3 Freiheitsgrade mit 3 bzw. 2 Ausprägungen. Daraus ergibt sich die folgende Matrix, der Form L9(33)1: 1 Bei Hoffmann (2008, S. 196) sind weitere Varianten von orthogonalen Arrays zu finden, z. B. der Form L 16(43) und L25(53). - 26 - Black-Box-Testing Abbildung 11: Orthogonales Array der Form Ln(kc) (Quelle: Eigene Abbildung nach Hoffmann 2008). 2. Es wird für jeden Freiheitgrad eine Spalte und für die Ausprägungen eine beliebige Zahl gewählt. Für das vorliegende Beispiel werden die Spalten in der Reihenfolge Betriebssystem, Browser und Browsersprache vergeben und die Ausprägen entsprechend analog (z. B. für das Betriebssystem 1=Windows, 2=Linux, 3=OS X). Daraus ergibt sich die folgende erweiterte Matrix: Abbildung 12: Aufgefülltes Array mit Ausprägungen der Freiheitsgrade (Quelle: Eigene Abbildung nach Hoffmann 2008). 3. Im letzten Schritt muss geprüft werden, ob ggf. unausgefüllte Zellen vorhanden sind. Da im vorliegenden Beispiel der Freiheitsgrad „Browsersprache“ nur mit zwei Ausprägungen belegt ist, wurden nicht alle Zellen ausgefüllt. Diese können nun mit beliebigen Ausprägungen aus des Freiheitsgrads „Browsersprache“ aufgefüllt werden, dürfen aber auf keinen Fall gelöscht werden, da ansonsten die entsprechenden Ausprägungspaare (z. B. OS X und Firefox) verloren gehen würden. - 27 - Black-Box-Testing Abbildung 13: Paarweise vollständige Testmenge (Quelle: Angepasst nach Hoffmann 2008). Zusammenfassend lässt sich festhalten, dass das paarweise Testen eine gute Möglichkeit bietet die Anzahl von Prüfung zu reduzieren, wenn die Kombination von Freiheitsgraden und Ausprägungen zu groß wird. Anders als bei der entscheidungstabellenbasierten Testmethode, bei der Abhängigkeiten von Bedingungen untersucht werden, sollen beim paarweisen Testen unabhängige Bedingungen untersucht werden (Betriebssystem und Browser sind grundsätzlich unabhängig voneinander), da die Praxis gezeigt hat, dass in den allermeisten Fällen zwei Bedingungen für den Ausfall von Software ausreichen. 4.4.2 Nicht-Funktionale Tests In diesen Abschnitt soll noch einmal auf die Gruppe der nicht-funktionalen Tests eingegangen werden. Unter nicht-funktionalen Anforderungen versteht man das allgemeine Verhalten eines Software-Produkts (Franz, 2007). Im Gegensatz zu den bisher dargestellten funktionalen Tests, überprüfen diese die nicht-funktionalen Anforderungen eines Systems, also z. B. die Gebrauchstauglichkeit oder die Zuverlässigkeit eines Systems. Sie beziehen sich oft auf das gesamte System und nicht auf einzelne Teilelemente. Nicht-funktionale Tests werden daher auch als „Higher-Order Testing“ bezeichnet (Myers et al., 2004). Es können zahlreiche verschiedene Arten von nicht-funktionalen Tests unterschieden werden (SoftwareTestingStuff, 2007), z. B. Massentest Performance-Tests Usability-Test Recovery-Test Sicherheitstest Speichertests Konfigurationstests (siehe auch Kapitel 4.4.1.5) Installationstests Kompatibilitätstest - 28 - Black-Box-Testing Zu den wichtigsten nicht-funktionalen Eigenschaften von Software-Produkten gehören die Benutzbarkeit (Usability), die Leistungsfähigkeit (Performance) und die Sicherheit (Security) (Grechenig & Bernhart, 2009). Meistens werden die nicht-funktionalen Eigenschaften eines Systems in der Anforderungsspezifikation nur sehr vage ausgeführt, so dass es schwer fällt Prüfungen aus diesen abzuleiten. Daher wird in konkreten Situationen auf allgemeine Software-Standards zurückgegriffen oder gar keine standardisierten Tests durchgeführt. All die hier erwähnten Beispiele nicht-funktionaler Tests ausführlich zu behandeln, könnte zu einem bücherfüllendem Programm werden, daher wird an dieser Stelle nur auf einer Übersichtsebene und auf den Performance-Test sowie den Sicherheitstests-Test eingegangen. Die Beschreibungen erheben keinen Anspruch auf Vollständigkeit. 4.4.2.1 Performance-Tests Bei Leistungs- oder Performance-Tests wird die Antwortzeit des Systems oder einzelner Komponenten getestet. Performance-Tests werden zur Risikominimierung von Projekten, insbesondere bei zeitkritischen Anwendungen, angesehen. In der Literatur werden die Begriffe (Über-)Last-, Stress- und Performance-Test oftmals synonym verwendet. Mit Hilfe eines Performance-Tests kann die Einhaltung von Anforderungen und Zielen an die Leistungsfähigkeit eines Systems überprüft werden. Die Untersuchung der Performance erfolgt dabei durch Anlegen künstlicher Last und dem Messen der dadurch hervorgerufenen Ressourcennutzung und Reaktionszeiten. Als Last gilt dabei die Nutzung hoher Datenmengen, gleichzeitig zu bearbeitende Nutzeranfragen oder die Simulation sehr lange andauernder Nutzung (Wirtz, 2009). Zur Bestimmung der Performance eines Systems werden Wertebereiche aufgebaut, die bei der Analyse des Systems unterstützen. Einige Beispiele hierfür sind nachfolgend aufgeführt (vgl. Grechenig & Bernhart, 2009, S. 328): Latenz: Beschriebt die Zeitspanne bis zur Beantwortung einer Anfrage. Durchsatz: Beschreibt die Menge der Daten, Informationen oder Arbeitsschritte die in einer definierten Zeit verarbeitet werden. Transaktionsrate: Beschreibt die Form des Durchsatzes, d. h. die Menge an Transaktionen pro Zeiteinheit. 4.4.2.2 Sicherheitstests Sicherheitstests haben in Zeiten zunehmender Cyberkriminalität (Baltaci, 2011) und HackerAngriffen (DerWesten, 2011) eine hohe Bedeutung. Allerdings ist die Beweisführung, ob ein System wirklich sicher ist nicht trivial. Um die Funktionsfähigkeit von Sicherheitsmechanismen in Systemen sicherzustellen gibt es zahlreiche Möglichkeiten, die mit mehr oder weniger Aufwand durchzuführen sind. Vor - 29 - Black-Box-Testing diesem Hintergrund soll im Folgenden beispielhaft auf die Möglichkeiten von Penetrationstests eingegangen werden. Im Jahr 2003 hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) eine umfassende Studie zum Thema Penetrationstests veröffentlicht (BSI, 2007). „Durch einen Penetrationstest kann geprüft werden, inwieweit die Sicherheit der IT-Systeme durch Bedrohungen von Hackern, Crackern, etc. gefährdet ist bzw. ob die IT-Sicherheit durch die eingesetzten Sicherheitsmaßnahmen aktuell gewährleistet ist“ (ebenda, S.5). Dabei werden die gleichen Methoden verwendet, die auch potentielle Angreifer verwenden würden. Bei der Konstruktion von Testfällen und Durchführung Tests ist es immer wichtig Grundannahmen zum Informationsstand des Angreifers zu kennen. Hier unterscheidet man zwischen sog. Black-Box-Testing - ohne jegliches Wissen - und White-Box-Testing mit Wissen über die Software. In meisten Fällen laufen die Test als „Black-Box-Simulation“, bei denen der Hacker keine Informationen über das System besitzt. Bei der Vorgehensweise schlägt das BSI als Methodik für die Durchführung von Penetrationstests ein fünfstufiges Umsetzungsmodell vor (siehe Abbildung 14). Abbildung 14: Fünf-phasige Vorgehensweise für Penetrationstests (Quelle: Informationstechnik, 2007, S. 47). Die für einen potentiellen Angreifer zur Ausnutzung von Schwachstellen zur Verfügung stehenden Möglichkeiten sind äußerst vielfältig und teilweise auch sehr trivial. Hierzu - 30 - Black-Box-Testing gehören die folgenden Möglichkeiten (vgl. TU Wien, S.7 ff.): Ändern vordefinierter Befehlsabfolgen Erzeugen unerwarteter Eingaben Ausführen zusätzlicher Funktionen Direktes oder indirektes Lesen Schreiben/Modifizieren interner Daten, Verwenden kontext-unerwarteter Funktionen Abfolgeunterbrechung von Befehlen Das Hauptproblem bei Penetrationstests liegt darin, dass sich die Techniken, mit denen Angreifer versuchen Schwachstellen auszunutzen, schnell weiterentwickeln, da man über das bestehende Sicherheitsniveau nicht auf die zukünftige Sicherheitsfähigkeit schließen kann. Dies gilt insbesondere für Änderungen, Anpassungen oder Erweiterungen von SoftwareProdukten, durch die Sicherheitslücken entstehen können (siehe Kapitel 4.4.3.2). 4.4.3 Diversifizierungstests Unter der Kategorie Diversifizierungstests lassen sich Testverfahren zusammenfassen, die mehrere Versionen von Software-Anwendungen miteinander vergleichen. Dabei wird allerdings nicht mehr auf Basis einer Spezifikation getestet, sondern lediglich auf Basis eines analogen - funktional wie nicht-funktionalen - Anwendungsverhaltens der Produkte (vgl. Hoffmann, 2008, S. 198). Meistens kommen diese Verfahren bei der parallelen Neuentwicklung von Systemen (Back-to-Back) oder bei der Weiterentwicklung bestehender Systeme (Regressionstest) zum Einsatz. 4.4.3.1 Back-to-Back-Test Bei einem Back-to-Back-Test werden von unterschiedlichen Programmierteams, auf Basis der gleichen Spezifikation, dieselbe Software entwickelt und anschließend gegeneinander getestet (vgl. Hoffmann, 2008). Auf diese Weise entstehen n-Versionen der gleichen Software oder der gleichen Softwarekomponenten. Da die Softwareprodukte auf der gleichen Spezifikation aufsetzen, sollten diese auch identisch sein, also das gleiche Eingabe-/Ausgabe-Verhalten zeigen. Da aber in der Software-Entwicklung eine große Varianz an Möglichkeiten besteht mit unterschiedlichen Mitteln das gleiche Ergebnis zu erreichen (z. B. über unterschiedliche Programmiersprachen, Implementierungsverfahren), besteht auch die Chance, dass Lösungen nicht das gleiche Eingabe-/Ausgabe-Verhalten zeigen. Da die Entwicklung von redundanten Systemen sehr kostspielig ist, wird ein solches Verfahren nur dann angewandt, wenn es wichtige Gründe für solche Parallelimplementierungen gibt, z. B. bei sicherheitsrelevanten Produkten oder bei laufzeitkritischen Systemen. 4.4.3.2 Regressionstest Das vornehmliche Ziel von Regressionstests besteht darin sicherzustellen, dass die Änderungen an einer bestehenden Software (z. B. durch Funktionserweiterungen, Fehlerkorrekturen, Erneuerungen oder Installation in einer neuen Umgebung) keine - 31 - Black-Box-Testing unerwünschten Seiteneffekte auf bestehende funktionale oder nicht-funktionale Aspekte der Software haben (vgl. Hoffmann, 2008, S.198). Die nachfolgende Abbildung beschreibt diesen Zusammenhang noch einmal: Abbildung 15: Prinzip eines Regressionstests (Quelle: Frühauf et al., 2007, S. 33). Sinnvollerweise müssen alle Testfälle, die bisher fehlerfrei abgearbeitet worden sind, nach den Änderungen noch einmal durchgeführt werden. Wie hoch der wirkliche Wiederholungsgrad der Testfälle ist, ergibt sich daraus wie genau die Abhängigkeiten der Systemänderungen und der interdependenten Systemelementen bekannt sind (vgl. Grechenig & Bernhart, 2009, S. 335). In der Praxis reicht es meistens, dass nur ein Teil der Testfälle wiederholt werden, da i. d. R. nicht alle Komponenten/Module der Software von den Änderungen betroffen sind. Dennoch nehmen Regressionstest ein Großteil der Testzeit in Anspruch, da sie ein zentrales Mittel darstellen, um die Software-Korrektheit zu testen (Hoffmann, 2008, S. 199). Vor diesem Hintergrund sollte bei Anpassungen an bestehenden Lösungen immer davon ausgegangen werden, dass es Einflüsse auf die bestehende Funktionalitäten gibt. Wie hoch diese sind muss im Einzelnen geprüft werden, Regressionstests sind in diesem Zusammenhang aber immer sinnvoll oder sogar notwendige Pflicht (vgl. Versteegen et al., 2002, S. 118). 4.5 Werkzeuge für Black Box-Tests Es gibt zahlreiche Werkzeuge, die das Black-Box-Testing unterstützen und erleichtern können, z. B. für bei Performancetests, Usability-Tests, Sicherheitstests, Klassentests usw. (vgl. Franz, 2007). Im Folgenden sind beispielhaft einige Test-Umgebungen aufgeführt (vgl. Aßmann, 2010, S.21): - 32 - Black-Box-Testing TestBench (Imbus: www.imbus.de) Visual 2000 (McCabe & Associates: www.mccabe.com) Cantata++ (IPL, Bath,: www.iplbath.com) ClickTracks (CT Analytics: http://www.clicktracks.com/products/pro/index.php) In den nachfolgenden Kapiteln (5 und 6) wird noch einmal ausführlich auf Werkzeuge und ihre Anwendungsverfahren eingegangen. - 33 - Black-Box-Testing 5 Black-Box-Tests im Rahmen eines SAP-Projekts 5.1 Gründe für organisiertes Testen im SAP-Umfeld Bereits seit 1972 entwickelt SAP ERP-Lösungen. In dieser Zeit wechselte der Name der Anwendung von SAP R/1, R/2, R/3 über mySAP bis hin zu SAP ERP. Zahlreiche Unternehmen weltweit haben bereits jahrelang erfolgreich die ERP-Lösung im Einsatz. Die Qualitätssicherung von SAP stellt nicht nur sicher, dass die ausgelieferte Anwendung möglichst fehlerfrei ist, sondern auch dass Fehler, die erst im Produktivbetrieb entdeckt werden, ebenfalls behoben werden. Hierfür stellt SAP so genannte Hinweise bereit, die eine Fehlerreparatur beinhalten. (vgl. SAP AG, o. J.) Dennoch gibt es trotz der umfangreichen Qualitätssicherung und der jahrelangen Marktreife von SAP-Lösungen Beispiele für gescheiterte SAP-Einführungen. Da SAPEinführungsprojekte meist sehr kostspielig sind und tief in die Unternehmensstruktur eingreifen, können Folgen eines gescheiterten SAP-Projekts für den Auftraggeber sehr dramatisch sein. So ist Shane Co., eine Handelskette für Schmuck, im Jahr 2008 in wirtschaftliche Schwierigkeiten geraten. Neben der Finanzkrise und dem damit verbundenen Rückgang der Nachfrage nach Luxusgütern macht Shane auch die Schwierigkeiten bei der Einführung des Moduls „SAP for Retail“ für die Unternehmenspleite mitverantwortlich. Statt der geplanten maximal zehn Millionen EUR und einer Einführungsphase von zwölf Monaten hat das Projekt 32 Millionen EUR gekostet und drei Jahre in Anspruch genommen. Doch auch nach der Inbetriebnahme im September 2007 war die SAP-Implementierung fehlerhaft. „Nach Angaben von Shane lieferte die ERP-Software keine akkuraten Lagerdaten. Folglich wuchsen die Bestände, während die geforderte Ware nicht in den Regalen lag. Dies habe Kosten verursacht und den Absatz sowohl während der restlichen Monate des Jahres 2007 als auch den ersten neun Monaten des folgenden Jahres beeinträchtigt.“ Neben dem Softwarehersteller SAP könne auch das Beratungsunternehmen Ciber Novasoft für die gescheiterte Einführung verantwortlich gemacht werden. (vgl. Niemann et. al. , 2009) Da die Lösungen von SAP permanent weiterentwickelt und getestet werden, stellt sich die Frage wie es dazu kommen kann, dass ein solches Einführungsprojekt scheitert. Die Ursache kann darin liegen, dass es nicht möglich ist, eine Anwendung „out of the box“ zu entwickeln, die zu jedem Unternehmen wie maßgeschneidert passt. SAP ERP ist keine Maßanfertigung, vielmehr ist die Anwendung mit vielen Standardfunktionen und Erweiterungsmöglichkeiten ausgestattet, die für die Zielgruppe erforderlich sind. Es ist die Aufgabe des Einführungspartners zu erkennen, welche Funktionen in welchem Umfang ein Unternehmen benötigt und diese anschließend entsprechend zu implementieren. Doch genau an dieser Stelle kommt es oft zu Schwierigkeiten. Neben der fehlerhaften Definition der Anforderungen kann auch die Umsetzung dieser fehlerhaft sein. Damit ein Einführungsprojekt erfolgreich endet, müsste also während des gesamten Projekts sichergestellt werden, dass die Anforderungen richtig erkannt, festgehalten und umgesetzt werden.1 - 34 - Black-Box-Testing Das Kapitel 5dieser Arbeit beschreibt die von SAP empfohlene Implementierungs- und Testmethodik. Dabei werden zunächst das Vorgehens- und das Testmodell vorgestellt. Das letztere basiert in SAP-Projekten größtenteils auf Black-Box-Tests. Anschließend wird ein Testmanagementtool vorgestellt, welches in SAP-Projekten eingesetzt werden kann. Abgeschlossen wird das Kapitel mit zwei Kundenberichten. Neben einigen Internetquellen diente v.a. das Buch „SAP-Lösungen testen“ von Markus Helfen und Hans Martin Trauthwein sowie die Berufserfahrung der Verfasserin als SAP-Beraterin für Finanzwesen als Informationsquelle. - 35 - Black-Box-Testing 5.2 Testmethodik in SAP-Projekten 5.2.1 Einführung in die ASAP-Methodik Um eine möglichst optimale SAP-Einführung zu ermöglichen und sicherzustellen, dass das System auch nach der Inbetriebnahme funktionsfähig bleibt, wurde die ASAP-Methodik (Accelerated SAP) entwickelt. Diese wird von SAP für die Einführung des ERP-Systems empfohlen. In diesem Kapitel wird diese Methodik beschrieben. Zunächst soll jedoch das allgemeine V-Modell vorgestellt werden, welches das grundsätzliche Vorgehensmodell für viele Software-Entwicklungsprojekte darstellt. Das V-Modell besteht aus Entwicklungsschritten, welchen die entsprechenden Testaktivitäten gegenüberstehen, die das Ergebnis der jeweiligen Entwicklungsphase überprüfen. Die Anzahl und Ausprägung der jeweiligen Entwicklungsstufen können sich je nach Literatur unterscheiden. Die nachfolgende Abbildung zeigt ein V-Modell mit fünf Entwicklungsschritten (links), welchen vier validierende Testaktivitäten (rechts) gegenüberstehen (vgl. Maiborn, 2009): Abbildung 16: Das allgemeine V-Modell (Quelle: Maiborn, 2009). - 36 - Black-Box-Testing In der Phase der Anforderungsdefinition wird die Gesamtheit aller Anforderungen festgehalten, die ein System erfüllen muss. Anschließend wird das System in der Phase des funktionalen Systementwurfs ausgestaltet und in der Phase des technischen Systementwurfs die konkrete technische Architektur definiert. Danach fließen die funktionalen und technischen Entwürfe in die Spezifikation ein (Phase Komponentenspezifikation) und werden in der Implementierungsphase ausprogrammiert. Sobald die Programmierung abgeschlossen ist, werden Programmmodule im Rahmen des Komponententests getestet. Die Soll-Vorgaben liefert dabei die Komponentenspezifikation. Da der Tester in der Regel über Kenntnis des internen Programmaufbaus verfügt, handelt es sich um einen White-Box- oder Gray-Box-Test (vgl. Unterkapitel 3.4). Nachdem die einzelnen Komponenten erfolgreich getestet wurden, erfolgt der Integrationstest, dessen Aufgabe es ist die Funktionsfähigkeit der Komponentenkombinationen sicherzustellen. Ab dieser Teststufe kommen in der Regel Black-Box-Tests zur Anwendung. Entscheidend für den Erfolg oder den Misserfolg des Integrationstests ist die Übereinstimmung mit den Festlegungen in der Phase des technischen Systementwurfs. Dagegen stellt der Systemtest sicher, dass die funktionalen Anforderungen erfüllt wurden. Hierbei wird nicht mehr die technische Seite des Systems betrachtet, vielmehr wird sichergestellt, dass das System alle erforderlichen Funktionen bietet, die für Geschäftsprozesse des Auftraggebers benötigt werden. Im Abschluss des Projekts ermittelt der Auftraggeber durch einen Abnahmetest die Übereinstimmung des gelieferten Systems mit den Anforderungen. (vgl. Helfen et. al. 2010, S. 46 – 50) Die SAP-Methodik übernimmt die Vorgehensweise des V-Modells mit einigen Modifikationen. „Analog zum V-Modell wird in SAP-Umfeld funktional ausnahmslos nach einer Bottom-up-Strategie getestet – vom Teil zum Ganzen.“ Dabei ist „ (…) die Darstellung der Teststufen (…) von der Beschreibung eines Vorgehensmodells abzugrenzen. Die einzelnen Stufen beschreiben lediglich die Beschaffenheit von Tests und Testfällen korrespondierend zu einer spezifischen Projektphase.“ (vgl. Helfen et. al. 2010, S. 51) Als Vorgehensmodell empfiehlt SAP die ASAP-Methodik. Viele SAP-Beratungsunternehmen haben die ASAP-Methodik angenommen und wenden sie während der Einführung des ERPSystems an. (vgl. Helfen et. al. 2010, S. 51) Die nachfolgende Abbildung stammt aus der Internetseite des Beratungshauses Steeb und zeigt eine Übersicht der ASAP-Projektschritte: - 37 - Black-Box-Testing Abbildung 17: ASAP-Einführungsmethodik (Quelle: Steeb Anwendungssysteme GmbH, o.J.). In der Projektvorbereitungsphase werden die Projektziele definiert, das Projektteam zusammengestellt sowie eine Einführungsstrategie festgelegt. In der Blueprint-Phase werden die Anforderungen an das zukünftige ERP-System zusammengestellt und in Form eines Business-Blueprints festgehalten. Im deutschen Sprachraum wird Business-Blueprint u.a. auch Pflichtenheft bezeichnet. Während der Realisierungsphase werden die vordefinierten Anforderungen an das SAP-System wie folgt umgesetzt: Vorhandene Konfigurationsmöglichkeiten bezeichnet) (Im SAP-Umfeld als Customizing Erweiterungen (Exits): Falls keine Customizing-Möglichkeiten zur Verfügung stehen, kommen in der Regel so genannte Exits zur Anwendung. Hierbei handelt es sich um vordefinierte Absprungstellen in SAP-Programmen, zu welchen eine Erweiterung hinterlegt werden kann. Dabei kann die Art der Erweiterung unterschiedlich sein: Von Substitutionen und Validierungen, die man sich auch ohne Programmierkenntnisse zusammenstellen kann, über ereignisgesteuerte Funktionsbausteine (Business Transaction Events) bis hin zu objektorientierter Implementierung (BADI = Business Application Add-In) Modifikation von SAP-Programmen: Hierbei werden bestehende SAP-Programmen modifiziert. Dabei ist zwischen modifizierten Kopien, die zusätzlich zu den Originalprogrammen verwendet werden und in einem Nicht-SAP-Namensraum existieren, und der Modifikation innerhalb des SAP-Namensraums zu unterscheiden. Die Letzteren sollten aufgrund von Schwierigkeiten während des nächsten Systemupgrades und beim Einspielen von Support-Paketen vermieden werden. Komplette Neuprogrammierung: Falls eine Funktion in SAP nicht zur Verfügung steht, kann diese neu programmiert werden. In der Produktionsvorbereitungsphase werden die Anwender auf die tägliche Arbeit mit dem neuen SAP-System vorbereitet. Anschließend wird das neue ERP-System in der letzten - 38 - Black-Box-Testing Projektphase in Betrieb genommen und das Einführungsprojekt abgeschlossen (Go-Live & Support). Nach Abschluss des Projekts wird das SAP-System jedoch stetig angepasst, um technischem Fortschritt und den sich ändernden Geschäftsprozessen gerecht zu werden. (vgl. Helfen et. al. 2010, S. 80 - 85) Auch in der ASAP-Methodik steht jedem Projektschritt eine Testaktivität gegenüber. Diese werden im nachfolgenden Kapitel näher beschrieben. - 39 - Black-Box-Testing 5.2.2 Teststufen der ASAP-Methodik Ähnlich wie im bereits vorgestellten V-Modell stehen jedem Projektschritt der ASAPMethodik entsprechende Testaktivitäten gegenüber. Dabei kommen im SAP-Umfeld v.a. Black-Box-Tests zur Anwendung. (vgl. Helfen et. al. 2010, S. 55 - 56) Dieses Unterkapitel liefert eine Beschreibung dieser Testaktivitäten, die hauptsächlich dem Buch „SAP-Lösungen testen“ von M. Helfen und H.M. Trauthwein entnommen wurden. Die Beispiele zu den jeweiligen Teststufen sind jedoch aus dem beruflichen Umfeld der Verfasserin entstanden. Die nachfolgende Abbildung zeigt Teststufen sowie die Zuordnung dieser zu den jeweiligen Projektschritten. Abbildung 18: Buttom-Up-Testmodell der ASAP-Methodik (Quelle: Eigene Abbildung nach Helfen et. al. 2010). Der Entwicklertest wird in der Regel während der Entwicklungsphase vom Entwickler selbst durchgeführt und gehört daher nicht zu den funktionalen Tests. Da der Entwickler über Kenntnisse der internen Programmstrukturen verfügt, stellt ein Entwicklertest noch kein Black-Box-Test dar, vielmehr handelt es sich bei diesem Test um einen White-Box-Test. Ein Beispiel für einen Entwicklertest liefern sämtlich Debugging-Aktivitäten beim Entwickeln zusätzlicher Programme. (vgl. Helfen et. al. 2010, S. 51) Der Funktionstest bildet die unterste Stufe der funktionalen Tests. Dieser Test stellt sicher, dass die kleinsten Funktionseinheiten des SAP Systems (Transaktionen oder Funktionsbausteine) die erwarteten Ergebnisse liefern. Aus diesem Grund wird dieser Test - 40 - Black-Box-Testing auch Modul- oder Funktionstest genannt. (vgl. Helfen et. al. 2010, S. 52) Beispielsweise kann nach der Entwicklung eines SAP-Exits dessen korrekte Funktionsweise sichergestellt werden. Im Rahmen eines Szenariotests werden mehrere Transaktionen getestet, welche für bestimmte Geschäftsbereiche oder Teile von Geschäftsprozessen benötigt werden. Der Szenariotest sichert somit die Funktionsfähigkeit des Zusammenspiels mehrerer Transaktionen und ihrer Schnittstellen. (vgl. Helfen et. al. 2010, S. 52) Ein Szenariotest kann beispielsweise die korrekte Verbuchung der Zahlungseingänge beim Laden des elektronischen Kontoauszuges, nach vorheriger Verbuchung von Rechnungen in SAP, sicherstellen. Die Aufgabe eines Integrationstests ist es, die „funktionale Korrektheit“ des ERP-Systems innerhalb ganzer Geschäftsprozesse des Kunden sicherzustellen. Hierbei wird das Zusammenspiel von SAP mit anderen Non-SAP-Systemen sowie die entsprechenden Schnittstellen getestet. Die einzelnen Geschäftsprozesse werden dabei in system- und modulübergreifenden Szenarien abgebildet. (vgl. Helfen et. al. 2010, S. 52) Ein Beispiel für ein solches Szenarion ist der nachfolgende Vertriebsprozess: Der Warenverkauf wird zuerst in einem Non-SAP-System erfasst und anschließend über eine Fakturaschnittstelle in das SAPSystem übergeleitet; hierbei müssen die Kundenstammdaten angelegt und anschließend die Anzahlungsanforderungen, Ausgangsrechnungen- und Gutschriften verbucht werden. Zusätzlich muss sichergestellt werden, dass nach Zahlungseingang in SAP die entsprechende Information an das Vertriebssystem weitergeleitet und die Warenauslieferung freigegeben wird. Im Rahmen des technischen Systemtests wird die SAP-Infrastruktur getestet. Der Schwerpunkt des Tests ligt dabei nicht auf der Software, sondern auf dem Gesamtsystem welches aus einer Datenbank, einem Applikationsserver, Frontends, Netzwerken, etc. besteht. Eine besondere Rolle spielt dabei der Performancetest. In einem Performancetest wird das Laufzeitverhalten des ERP-Systems ermittelt. (vgl. Helfen et. al. 2010, S. 53) Dabei kann bereits während der Altdatenmigration sowie Funktionstestaktivitäten sichergestellt werden, ob genug Systemressource für den späteren operativen Betrieb vorhanden sind. Ist dies nicht der Fall, muss entsprechend nachgerüstet werden. Um Probleme in der Benutzerfreundlichkeit aufzudecken wird ein User Acceptance Test durchgeführt. Mit Hilfe dieses Tests kann die Akzeptanz des neuen ERP-Systems durch die späteren Anwender sichergestellt werden. Sinnvollerweise sollte man in einem solchen Test alle Geschäftsvorfälle verarbeiten, die im operativen Betrieb häufig anfallen und von den Benutzern im Dialogmodus erfasst werden. Häufig werden User Acceptance Tests jedoch nicht separat durchgeführt, sondern in die oben geannten funktionalen Tests integriert. (vgl. Helfen et. al. 2010, S. 53) Auch nach dem Produktivstart kann es erforderlich sein das ERP-System anzupassen. Gründe hierfür können in der Änderung von Geschäftsprozessen aber auch in der technischen Weiterentwicklung liegen. Um nach größeren Änderung die Funktionsfähigkeit des Systems zu garantieren werden Regressionstests durchgeführt. Im SAP-Umfeld werden soche Tests vor allem dann durchgeführt, wenn die Systemanpassung eine technische Ursache hatte (z. B. Einspiele von Support-Packages oder Release-Updates). Neben neuen - 41 - Black-Box-Testing Funktionserweiterungen sind solche Anpassungen oft mit einer Änderung der Datenhaltung verbunden, so dass im Rahmen eines Regressionstests vor allem kundenspezifische Programme getestet werden sollten. (vgl. Helfen et. al. 2010, S. 53 - 54) - 42 - Black-Box-Testing 5.3 SAP Quality Center by HP als Testwerkzeug im Rahmen eines SAPProjekts 5.3.1 Funktionsweise des SAP Quality Centers by HP Bei SAP Quality Center by HP handelt es sich um eine J2EE-basierte Anwendung, die für die Verwaltung von Tests im Rahmen eines SAP-Projekts eingesetzt werden kann. Da die Benutzeroberfläche nur in englischer Sprache zur Verfügung steht, werden nachfolgend u. a. englische Begriffe verwendet. Das SAP Quality Center by HP besteht aus nachfolgend genannten Modulen: Release Management (Definition von Entwicklungszyklen) Requirements Management (Verwalten der Anforderungen) Test Plan (Verwalten der Testfälle) Test Lab (Verwalten und Ausführen von Testfällen) Defect Management (Fehlermanagement) (Helfen et. al. 2010, S. 291) Business Components (Geschäftskomponenten, ein optionales Modul) Zusätzlich zu den oben genannten Modulen bietet SAP Quality Center by HP umfangreiche Auswertungsmöglichkeiten mit Grafiken sowie Drill-Down-Funktionalitäten, die u.a. zum Berichten an das Top-Level-Management zur Anwendung kommen. „Konzeptionell unterstützt das SAP Quality Center by HP anforderungs- und risikobasierte Tests. Die Verknüpfung und der Abgleich von Geschäftsanforderungen mit Testergebnissen kann dabei mit Hilfe der Software abgebildet werden (…)“ (Helfen et. al. 2010, S. 292) Die Anwendung kann in die Anwendungsmanagement-Lösung von SAP, den Solution Manager (siehe Kapitel fünf) integriert werden, so dass die Projekt- und Anforderungsdokumentation sowie Testobjekte aus diesem abgeleitet werden können. Das Projektmanagement erfolgt anschließend immer im Solution Manager, während SAP Quality Center by HP für die Qualitätssicherung eingesetzt wird. Bevor der Test beginnen kann, müssen im ersten Schritt Requirements, d.h. also sämtliche Anforderungen an das Projekt definiert und entsprechend hinterlegt bzw. aus dem SAP Solution Manager übertragen werden. Eine interessante Funktionalität im Bereich der Testanforderungen ist die Möglichkeit Abhängigkeiten zwischen den Anforderungen zu definieren sowie eine Risikobewertung für alle Anforderungen zu hinterlegen. Anschließend kann aufgrund des ermittelten Risikos regelbasiert die Testtiefe vorgeschlagen werden. Hat man zuvor Testaufwände hinterlegt, wird zusätzlich der Gesamttestaufwand errechnet. Eine Anforderung kann beispielsweise wie folgt lauten: „Es muss möglich sein, einen Anlagenzugang gegen ein Verrechnungskonto zu verbuchen.“. - 43 - Black-Box-Testing Abbildung 19: Modul Requirements im Quality Center (Quelle: Testing Concepts, 2011). Nach Fertigstellen der Testanforderungen werden im Modul Test Plan die Testfälle erstellt und in einer frei definierbaren Ordnerstruktur hinterlegt. Ein typischer Testfall besteht dabei aus den einzelnen Testschritten mit der Beschreibung der Testtätigkeit sowie des erwarteten Testergebnisses. Zusätzlich können Dokumente, Grafiken, Screenshots, etc. als Anhang hinterlegt werden. (vgl. Helfen et. al., 2010, S. 302) Beispielsweise kann der Testfall zur oben genannten Anforderung wie nachfolgend beschrieben definiert werden, dabei können die Schritte zwei und drei nur dann ausgeführt werden, wenn der jeweils vorherige Schritt erfolgreich war: - 44 - Black-Box-Testing Schritt Beschreibung Erwartetes Ergebnis Schritt 1 Rufen Sie die Transaktion ABZON auf Die Transaktion kann aufgerufen (Anlagenbewegung erfassen, werden. Die Werte können Gegenbuchung automatisch). Bitte eingegeben werden. geben Sie folgende Werte ein: Buchungskreis 1000, 25.09.2011 für Beleg- und Buchungsdatum, 1000 EUR für Buchungsbetrag, „Test Anlagenzugang“ als Text. In der Eingabemaske sollte die Option „neue Anlage“ ausgewählt und anschließend die Bezeichnung „Testanlage 1 (Fuhrpark)“, Anlagenklasse 3100 sowie die Kostenstelle 40002 eingegeben werden. Schritt 2 Bitte verbuchen Sie den Zugang indem Sie auf den Button „Sichern“ klicken. Es erscheint die nachfolgende Meldung: Anlagenbewegung wurde mit Belegnummer <Belegnummer> gebucht. Anlage <Anlagennummer> im Buchungskreis 1000 angelegt. Schritt 3 Rufen Sie die Transaktion AW01N (Anlagenexplorer) auf. Geben Sie die Anlagennummer aus Schritt eins ein und drücken Sie die Enter-Taste, prüfen Sie den Anschaffungswert und das Bezugsdatum. Die Anlage erscheint im Anlagenexplorer. Der Anschaffungswert ist 1000,00 EUR, das Bezugsdatum entspricht dem 25.09.2011. Tabelle 5: Beispiel einer Testbeschreibung (Quelle:Eigene Tabelle). Die Testfälle sollten nun mit den jeweiligen Testanforderungen verknüpft werden, um anforderungsbasiertes Testen sicherzustellen und ein Reporting zu ermöglichen, welches Echtzeitauswertungen über die Abdeckung der Anforderungen mit den jeweiligen Testergebnissen aufzeigt. Neben der Anforderungsabdeckung kann auch die Priorität der jeweiligen Anforderung oder die Entwicklung der Anforderungserfüllung im zeitlichen Verlauf zur Auswertung herangezogen werden. Sind Testfälle fertiggestellt, können diese im Modul Test Lab zu Testläufen (Test Sets) zusammengefasst und den Testern zugewiesen werden. Zu Testläufen kann zusätzlich die Ausführungsreihenfolge, Bedingungen (z. B. Test B nur dann ausführen, wenn Test A erfolgreich war) sowie das Ausführungsdatum hinterlegt werden. Die Tester können über den Beginn des Tests per E-Mail informiert werden und beginnen anschließend, die ihnen zugewiesenen Testfälle abzuarbeiten. Dabei müssen Testpersonen die Testläufe starten, die - 45 - Black-Box-Testing einzelnen Schritte abarbeiten, die tatsächlichen Testergebnisse erfassen und diese mit Hilfe von Dokumentationen oder Screenshots belegen. (vgl. Helfen et. al., 2010, S. 303 - 304) Die nachfolgende Abbildung zeigt das Modul Test Lab. Abbildung 20: Modul Test Lab im Quality Center (Quelle: QMETHODS - Business & IT Consulting GmbH, o. J. ). Im mittleren Bereich des Monitors sieht die Testperson die einzelnen Testläufe. Diese können markiert und mit Hilfe des Buttons „Run“ (siehe Menüleiste) gestartet werden. Jeder Testlauf besteht aus mehreren Schritten, welche die Testperson abarbeiten und als erfolgreich („Passed“) oder nicht erfolgreich („Failed“) kennzeichnen muss. Zu jedem Schritt muss das tatsächliche Ergebnis dokumentiert werden. Hierfür bietet der Quality Center u.a. eine bequeme Funktion zum Erstellen von Screenshots, die anschließend automatisch an den jeweiligen Testlauf oder –Schritt angefügt werden. Im unteren Bereich des Monitors ist das Ergebnis der einzelnen Schritte des letzten Testlaufs angezeigt. Das Ergebnis eines Testlaufs setzt sich aus den Ergebnissen der einzelnen Schritte zusammen. Erfolgreich ist ein Testlauf nur dann, wenn alle dessen Schritte erfolgreich abgeschlossen wurden. - 46 - Black-Box-Testing Für die oben beschriebene Testanforderung kann die Dokumentation der Testergebnisse wie folgt aussehen: Tatsächliches Ergebnis zu Schritt eins: Die Transaktion kann erfolgreich aufgerufen und die Werte eingegeben werden. Abbildung 21: Anhang zu Schritt 1 (Quelle: Eigene Abbildung). Tatsächliches Ergebnis zu Schritt drei: Die Anlage wurde erfolgreich angelegt und mit der nachfolgenden Meldung bestätigt: „Anlagenbewegung wurde mit Belegnummer 0100000063 gebucht. Anlage 3440 im Buchungskreis 1000 angelegt.“ - 47 - Black-Box-Testing Abbildung 22: Anhang zu Schritt 2 (Quelle: Eigene Abbildung). Tatsächliches Ergebnis zu Schritt drei: Die Anlage 3440 erscheint im Anlagenexplorer, der Anschaffungswert entspricht 1000 EUR, das Anschaffungsdatum ist 25.09.2011. Abbildung 23: Anhang zu Schritt 3 (Quelle: Eigene Abbildung). Im oben beschriebenen Beispiel ist ein erfolgreicher Test dargestellt. Bei einem solchen Ergebnis wäre der Test an dieser Stelle abgeschlossen. Im Fall eines fehlerhaften Ergebnisses müsste jedoch eine Fehlermeldung erfasst werden. Hierfür steht im SAP Quality Center by HP das Modul Defect Management zur Verfügung. Dabei können Fehlermeldungen bereits aus dem Testergebnis heraus erstellt und anschließend von einem berechtigten Personenkreis, z. B. Entwicklern eingesehen werden. Zusätzlich besteht die Möglichkeit, Fehlermeldungen - 48 - Black-Box-Testing einer bestimmten Person zuzuweisen, Statuswerte zu erfassen sowie die Historie des Fehlerbehebungsprozesses einzusehen. (vgl. Helfen et. al., 2010, S. 304 - 305) Das Modul Business Components kann optional verwendet werden. Es bietet die Möglichkeit, atomare Bausteine zu hinterlegen, die zum Erstellen von Testfällen verwendet werden können. Der Grundgedanke hinter diesem Modul ist die Wiederverwendbarkeit von atomaren Funktionen. Im SAP-Bereich können Business Components beispielsweise auf Ebene der Transaktionen erstellt werden, welche zum Ausführen von elementraren Funktionen verwendet werden. So kann der Aufruf der Transaktion zum Suchen und Anzeigen einer Bestellung (ME53N) genau einmal beschrieben und anschließend in allen Tests wiederverwendet werden, in welchen diese Funktion erforderlich ist. Die für den jeweiligen Test benötigten Daten (z. B. Nummern der Bestellungen, etc) werden dabei separat bereitgestellt. Die Reduzierung des Aufwandes beim Testdesign wird nachfolgend in Abbildung 24 und Abbildung 25 aufgezeigt. Abbildung 24: Traditionelle Testbeschreibung (Quelle: Vivit Germany, 2008). - 49 - Black-Box-Testing Abbildung 25: Testbeschreibung bei Wiederverwendbarkeit von Funktionen (Quelle: Vivit Germany, 2008). In jedem Modul der Anwendung ist über den Menüpunkt Analysis ein ausführliches Berichtswesen verfügbar. Dabei sind im Standard folgende Auswertungen verfügbar: „Grafische Auswertungen: Anforderungsabdeckung Teststatus Testfortschritt im Zeitverlauf Status von Fehlermeldungen Alter von Fehlermeldungen Änderungshistorie für einzelne Felder (Trend) Berichte: Anforderungen und zugehörige Testfälle Testfälle mit Einzelschritten Fehlgeschlagene Tests im aktuellen Test Set Fehlermeldungen mit zugeordneten Tests und deren Ausführungsstatus Offene Fehlermeldungen, die durch den aktuellen Benutzer zu bearbeiten sind.“ (Helfen et. al. 2010, S. 307) Zusätzlich zu den Standardberichten können eigene Berichte erstellt werden. Das optional verfügbare HP Quality Center Dashboard kann dazu verwendet werden, den - 50 - Black-Box-Testing projektübergreifenden Status auszuwerten und eine Auswertung auf Basis vordefinierter Kennzahlen für das Top-Management aufzubereiten. (vgl. Helfen et. al., 2010, S. 308) Bei den nachfolgenden Abbildungen handelt es sich um Beispiele für grafische Auswertungen, die im HP Quality Center zur Verfügung stehen. So zeigt die Abbildung 26 den Testfortschritt pro Test Set und die Abbildung 27 die Übersicht der Fehlermeldungen, die einem Spezialisten zugeordnet sind. Test Execution - Sum m ary Graph (Cross Test Set) 180 167 Failed No Run Not Completed Passed 160 Number of Tests 140 120 100 76 80 56 51 60 40 54 21 21 13 27 4 20 21 1 12. Technical Regression 11. Cognos Query & Report (Sal.. 10. Period Close 09. Retail Accounting 08. Supply Chain Accounting / .. 07. F&A Accounting 06. Project Accounting 05. Asset Accounting 04. Bank statement posting and.. 03. General Ledger Accounting 02. Invoice to Cash 01. Procure to Pay 0 Test Set Abbildung 26: Teststatus pro Test Set (Quelle: Eigene Abbildung). Abbildung 27: Übersicht der Fehlermeldungen pro zugeordneten Spezialist (Quelle: Eigene anonymisierte Abbildung). - 51 - Black-Box-Testing 5.4 Berichte aus SAP-Projekten mit SAP Quality Center by HP Bei den nachfolgenden Unterkapiteln handelt es sich um Berichte aus dem praktischen Einsatz des SAP Quality Centers by HP im Rahmen eines SAP-Regressionstests. Der erste Bericht ist dem Buch „SAP-Lösungen testen“ von M. Helfen und H.M. Trauthwein entnommen. Der zweite Bericht stammt aus dem beruflichen Umfeld der Verfasserin. Beide Berichte werden wie folgt strukturiert: Unternehmen: Eine kurze Vorstellung des Unternehmens in welchem das Quality Center zum Einsatz kam Projekt: Beschreibung des SAP-Projekts Besondere Anforderungen: Besonderen Umständen des Projekts, die dazu geführt haben SAP Quality Center by HP für die Testverwaltung einzusetzen Testverlauf: Planung- und Organisation des Tests Fazit: Rückblick auf das Projekt, Beurteilung des Testverwaltungstools - 52 - Black-Box-Testing 5.4.1 Quality Center by HP im SAP-Projekt der Endress+Hauser Group Unternehmen: Das Unternehmen Endress+Hauser ist ein internationaler Anbieter von Sensoren, Messgeräten und Automatisierungslösungen für die Industrie. Der Hauptsitz des Unternehmens ist in der Schweiz. Die Endress+Hauser InfoService GmbH & Co. KG ist der eigene IT-Dienstleister des Unternehmens welcher im Jahr 1997 in die selbstständige Organisation überführt wurde. Bereits seit 1985 hat Endress+Hauser SAP im Einsatz. Projekt: Da die Wartung von SAP-Release R/3 4.6C im Jahr 2009 enden sollte, war im Jahr 2008 ein Upgrade auf den damals aktuellen Release SAP ERP 6.0 geplant. Der Upgrade sollte innerhalb von zwölf Monaten auf zehn produktiven Systemen an verschiedenen Standorten weltweit durchgeführt werden. Im Regressionstest sollte die 100 prozentige Abdeckung der zu testenden Funktionen sichergestellt werden. Besondere Anforderungen: Aufgrund der hohen Anzahl und der Komplexität von Testfällen war ein Testmanagementtool erforderlich, welches sämtliche Testfälle zentral zur Verfügung stellt. Alle Testplanungs- und Durchführungsaktivitäten sowie die Fehleranalyse- und Behebung sollten für sämtliche Standorte und Systeme zentral erfolgen. Zusätzlich sollte es möglich sein die Lösung nicht nur im SAP-Umfeld, sondern in weiteren Bereichen des Unternehmens, z. B. im Webumfeld oder für Eigenentwicklungen einzusetzen. Auch die Option in Zukunft automatisierte Tests durchzuführen sollte mit dem Tool zur Verfügung stehen. Da Quality Center by HP bereits in anderen Bereichen des Unternehmens für die Qualitätssicherung der Software-Entwicklung für Messgeräte eingesetzt wurde, hat sich das Unternehmen für dieses Tool entschieden. Testverlauf: Zum Erstellen der Testfälle wurde das Modul Business Components verwendet. Somit wurden kleine wiederverwendbare Testeinheiten auf Basis von SAPTransaktionen erstellt, die in mehreren Tests verwendet wurden. Die Business Components wurden von den Mitarbeitern der E+H InfoService erstellt und in einer Ordnerstruktur abgelegt welche dem SAP ERP 6.0 –Menü nachempfunden wurde. Insgesamt wurden 8700 Komponenten angelegt welche zu insgesamt 5756 Testfällen zusammengefasst wurden. Anschließend wurden Testfälle zu Test Sets gebündelt und den - 53 - Black-Box-Testing Testern zugewiesen. Während der Testausführung haben die Tester für alle Unstimmigkeiten im Modul Defect Management Fehlermeldungen erzeugt welche anschließend mit Hilfe eines Workflows zu einem Dispatcher und anschließend an zuständige Spezialisten weitergeleitet wurden. Nach Beheben der Fehlerursache erfolgte ein erneuter Test. Alle Beteiligten wurden mit Hilfe des in das SAP Quality Center by HP integrierten Email-Benachrichtigungssystems über den aktuellen Test- und Fehlerstatus informiert. Fazit: Mit Quality Center by HP hat das Unternehmen ein vielseitiges Werkzeug im Einsatz welches nicht nur für den SAP-Upgrade verwendet werden kann, sondern auch in anderen Anwendungsbereichen sowie für Eigenentwicklungen in den Einsatz kommt. Das Tool ermöglicht eine zentrale Planung, Erstellung und die Ablage von Tests. Dank Business Components ist der Testdesign sehr effizient, da gleiche Testschritte nur einmal beschrieben werden müssen. Auch das für die Zukunft geplante automatisierte Testen wird von SAP Quality Center by HP unterstützt. (vgl. Helfen et. al., 2010, S. 310 - 324) - 54 - Black-Box-Testing 5.4.2 SAP Quality Center by HP im SAP-Projekt des Outdoor-Bekleidungsanbieters Timberland Der nachfolgende Bericht stammt aus der beruflichen Tätigkeit der Verfasserin als SAPBeraterin. Der Name des Unternehmens wurde anonymisiert. Unternehmen: Timberland ist ein führender Anbieter von Outdoor- und Freizeitbekleidung. Das Unternehmen hat weltweit ca. 3 500 Mitarbeiter. Die Zentrale des Unternehmens befindet sich in den USA, weitere regionale Zentralen sind in Hong Kong, Singapur und der Schweiz. Die Unternehmenssprache ist Englisch. Ende 2009 wurde die unternehmensweite Einführung von SAP ERP 6.0 erfolgreich abgeschlossen. Der Implementierungspartner war Firma consolut.gmbh aus Mannheim. Projekt: Für die Anbindung eines weiteren SAP-Moduls war im Frühjahr 2011 ein SAP-Upgrade auf den aktuellen Enhancement Package vier erforderlich. Der Upgrade durfte keine negative Auswirkung auf die operative Tätigkeit haben. Um dies zu gewährleisten wurde ein umfangreicher Regressionstest eingeplant. Alle entdeckten Unstimmigkeiten sollten dabei behoben und anschließend erneut getestet werden. Als Anforderung wurde die 100 prozentige Abdeckung für alle Funktionen gefordert, die weltweit im vergangenen Jahr verwendet wurden. Die Mehrzahl von SAP-Erweiterungen und Eigenentwicklungen, die höchst heterogene Systemlandschaft mit vielen Schnittstellen sowie ein Zeitplan von nur ca. zwei Monaten erschwerten die Aufgabe zusätzlich. Besondere Anforderungen: Als besondere Anforderung des Projekts ist die größtenteils virtuelle Kommunikation der Beteiligten aus den USA, Asien und Europa über Videokonferenzen, Internet und Telefon zu nennen. Aus diesem Grund sollte das Testmanagementtool webbasierend sein und in Echtzeit aktuelle Übersichten und Auswertungen des Testfortschritts liefern. Weiterhin sollte die grafische Oberfläche in englischer Sprache zur Verfügung stehen und weitgehend selbsterklärend sein. Für einen technisch versierten Tester sollten ein ca. einstündiges Online-Training sowie eine kurze Dokumentation ausreichend sein, um sich die wichtigsten Test- sowie Fehlermanagement-Funktionen anzueignen. Des Weiteren sollte es möglich sein, wiederverwendbare Test-Bausteine auf Basis von SAPTransaktionen zu erstellen. - 55 - Black-Box-Testing Testverlauf: Das Testdesign erfolgte durch die Mitarbeiter der Firma consolut, welche das Unternehmen Timberland jahrelang betreut. Neben einer Prozessübersicht wurde hierfür eine Auflistung aller Transaktionen erstellt, welche im vergangenen Jahr verwendet wurden. Diese dienten als Basis für die Erstellung der Testfälle. Die Key-User des Unternehmens Timberland wurden als Tester eingeplant. Aufgrund des straffen Zeitplans und der Vielzahl an komplexen länderspezifischen Funktionen wurden jedoch ca. 60% der Tests durch Mitarbeiter der Firma consolut durchgeführt. Dabei wurde darauf geachtet, dass jeder Mitarbeiter Test Sets zugewiesen bekommt, die nicht aus seinem Fachgebiet stammen. Alle Tests konnten pünktlich abgeschlossen werden. Ein Großteil der entdeckten Unstimmigkeiten war auf Änderungen der Datenhaltung in SAP ERP 6.4 zurückzuführen, welche in den Erweiterungen sowie Eigenentwicklungen erst entsprechend implementiert werden mussten. Weiterhin sorgten Implementierungen neuster gesetzlicher Anforderungen für abweichende Testergebnisse. Diese stellten jedoch keine Fehler dar. Jede Fehlermeldung wurde einem SAP-Berater zugewiesen, dessen Spezialisierung im Bereich des Test Sets liegt aus welchem die Fehlermeldung stammte. Fazit: Mit Hilfe von SAP Quality Center by HP war es möglich einen Upgrade Test innerhalb einer vergleichsweise kurzen Zeit durchzuführen. Eine Anreise der Tester in die Unternehmenszentrale war nicht erforderlich. Somit konnten sowohl Reisekosten als auch –Zeit auf ein Minimum reduziert werden. Während der Design- und Testphase konnten sich die Beteiligten schnell in die grafische Oberfläche einarbeiten. Mit Hilfe von Grafiken und Auswertungen des Quality Centers wurden sowohl die Tester als auch das Top-Management in regelmäßigen Abständen über den Testverlauf und die Fehlerbehebung informiert. - 56 - Black-Box-Testing 6 Blackbox-Test im Rahmen der Testautomatisierung Die manuelle Testdurchführung stellt für die einzelnen Tester eine zeitintensive Tätigkeit dar und erfordert ein hohes Maß an Konzentration. Dieser hohe Aufwand kann durch die automatische Testdurchführung reduziert werden. Im Folgenden soll daher die Durchführung von Black-Box-Tests mit dem SAP Extended-Computer Aided Test Tool (eCATT) als Alternative zur manuellen Durchführung der Black-Box-Tests vorgestellt werden. 6.1 Vor- und Nachteile der automatischen Testdurchführung Im Rahmen der automatischen Testdurchführung werden Testfälle einmalig erstellt, parametrisiert und anschließend mehrmals ausgeführt. Dies reduziert einerseits den Aufwand, da weniger Personal benötigt wird und die Testfälle schneller ausgeführt werden. Andererseits können die Testfälle parametrisiert werden, was sowohl die Abbildung verschiedener Geschäftsvorfälle ermöglicht, als auch die Wiederverwendbarkeit erhöht. Darüber hinaus können durch die streng algorithmische Abarbeitung der Testfälle Fehler reproduziert und deren Behebung übergeprüft werden. Der schnelleren Ausführung der automatischen Testfälle stehen jedoch der erhöhte Aufwand zur Schulung der Testfallersteller in der eingesetzten Software und ein höherer Erstellungsaufwand für die Testfälle gegenüber. Darüber hinaus kann nicht auf die menschliche Intelligenz des Testers zurückgegriffen werden. Das heißt, die Testfälle müssen streng algorithmisch beschrieben und ausführbar sein (siehe Error! Reference source not found., vgl. SAP AG, 2006, S. 1-7). Abbildung 28: Vor- und Nachteile der automatischen Testdurchführung (Quelle: Eigene Abbildung). - 57 - Black-Box-Testing 6.2 Testdurchführung mit Hilfe des SAP Solution Managers Der SAP Solution Manager stellt eine Sammlung von Funktionalitäten und Inhalten (so genannte Blueprints) zur Unterstützung bei der Einführung und den Betrieb von SAPProdukten dar, die Kunden mit bereits lizenzierten definierten Nutzern kostenlos nutzen können. Dieser wird im Folgenden detailliert vorgestellt. 6.2.1 Vorstellung des SAP Solution Managers „SAP Solution Manager ist die zentrale Anwendungsmanagementlösung von SAP. Ihre Aufgabe ist es, Ihnen die Implementierung, den Betrieb, die Überwachung und die Unterstützung von SAP-Lösungen im Unternehmen entscheidend zu vereinfachen.“ (SAP AG, 2011) Der Solution Manager unterstützt dabei insbesondere den technischen Betrieb der SAPLösung und stellt hierzu die folgenden Funktionalitäten bereit: Implementierung und Upgrades der SAP Business Suite Change Control Management Testing IT-und Anwendungs-Support Ursachenanalyse Solution Monitoring Service-Level-Management und Reporting Service-Verarbeitung Administration (vgl. SAP AG (2011)) Im nächsten Abschnitt wird nun speziell auf das Testing mit dem SAP Solution Manager eingegangen. 6.2.2 Vorstellung der Test Workbench des SAP Solution Managers Die Test Workbench des SAP Solution Manager stellt den zentralen Einstiegspunkt für die Organisation, die Durchführung und die Verfolgung von Tests dar und wird durch eine Vielzahl von Objekten repräsentiert (vgl. SAP AG, 2006, S. 10-19): - 58 - Black-Box-Testing Abbildung 29: Objekte in der SAP Test Workbench (Quelle: Eigene Abbildung nach SAP AG, 2006). Die Geschäftsprozessbibliothek stellt die prozessbezogene Struktur für alle weiteren Objekte des SAP Solution Manager (unter anderem Testfälle und Transaktionen) dar und kann aus beliebig vielen Prozessen- und Prozessschritten in einer maximal 3-stufigen Hierarchien bestehen. Der Testplan stellt eine zeitraum- und zweckbezogene Auswahl von Geschäftsprozessen dar, die für einen spezifischen Test genutzt werden sollen und wird wiederum in Testpakete unterteilt. Die Testpakete dienen anschließend als fach- und personenbezogener Arbeitsvorrat für die Tester, welche dem jeweiligen Testpaket zugeordnet werden und für dessen Abarbeitung zuständig sind. Die eCATTs können nach der Erstellung ebenfalls in die Geschäftsprozessbibliothek eingehangen sowie in Testpläne und Testpakete mit aufgenommen werden. Damit ist im SAP Solution Manager eine parallele Abarbeitung und Ausführung sowohl manueller, wie auch automatischer Testfälle möglich. 6.2.3 Einführung in die Systemlandschaft mit Hilfe des SAP Solution Managers Der SAP Solution Manager stellt die zentrale Verwaltungsinstanz in einer SAP Systemlandschaft dar und ermöglicht den Zugriff auf alle angebundenen SAP-Systeme. - 59 - Black-Box-Testing Abbildung 30: Solution Manager als zentrale Verwaltungsinstanz (Quelle: Eigene Abbildung). Aus diesem Grund bietet sich der SAP Solution Manager als zentrale Testplattform an: die Tester verfügen über einen zentralen Zugriffspunkt und können die Testfälle vom Solution Manager aus auf allen (per RFC-Verbindung, siehe Abschnitt 6.3.3) angebundenen Systemen ausführen, wobei die Testergebnisse wiederum zentral auf dem SAP Solution Manager verwaltet werden. Im folgenden Unterkapitel soll nun auf die Nutzung der eCATTs eingegangen werden. 6.3 Nutzung der SAP eCATT 6.3.1 Definitionen und Begrifflichkeiten Die SAP Test Workbench ermöglicht neben der Verwaltung von manuellen Testfällen auch die Definition und Wiederverwendung von automatischen Testbausteinen, wobei mehrere Testbausteine zu einem Testablauf zusammengestellt werden können, in denen sich Prüffunktionen einstreuen lassen. Dadurch kann während der Ausführung z. B. überprüft werden, ob Datenbankinhalte fortgeschrieben wurden oder ob Variablen einen bestimmten Wert enthalten. Darüber hinaus können beim eCATT die Ergebnisse eines Tests als Eingabeparameter für den nächsten Test verwendet und so komplette Geschäftsfälle durchgespielt werden. - 60 - Black-Box-Testing Zur schnelleren Erstellung von Testbausteinen können mit Hilfe des eingebauten Recorders Transaktionsabläufe (z. B. das Anlegen einer Kostenstelle) aufgezeichnet werden. Die in der Aufzeichnung enthaltenen Konstanten können später durch Variablen ersetzt werden, um die Abläufe zu flexibilisieren. Bei Bedarf können die eCATTs mit einer Liste von Datensätzen, die in Excel erstellt wird, verknüpft werden. Somit können die Transaktionen rationell getestet werden. Als Ergebnis des Testlaufs wird ein Protokoll des Testablaufs erstellt. Mit eCATTs lassen sich alle Anwendungen aufzeichnen und abspielen, die unter dem SAP GUI for Java oder dem SAP GUI for Windows laufen. Da das Werkzeug im SAPAnwendungsserver eingebettet ist, hat es außerdem Zugriff auf andere Schnittstellen, wie etwa auf Funktionsbausteine, auf BAPIs und sogar auf die SAP-Datenbank selbst. Der SAP Solution Manager dient idealerweise als dezidierter Testserver, auf dem die Testfälle zentral in der Test Workbench verwaltet werden. Die einmal erstellten eCATT Testfälle sind so jederzeit, auf beliebigen SAP-Zielsystemen, wiederholt ausführbar. Während der Ausführung steuern die eCATT-Testskripte die SAP-Anwendung genauso, wie sie von einem Benutzer bedient oder einem externen Programm gesteuert werden würden. Die dabei generierten Testprotokolle werden wiederum auf dem zentralen SAP Solution Manager gespeichert, stehen dort für die Auswertung zur Verfügung und können bei Bedarf revisionssicher archiviert werden. Für die Nutzung des SAP eCATT müssen verschiedene Vorraussetzungen erfüllt sein: Auf dem Quellsystem (Speicherort der eCATTs) muss mindestens das SAP Basis Release v6.20 (Grundlage des SAP R/3 v4.6C und des Solution Manager v2.2) installiert sein. Auf dem Zielsystem (Ausführungsort der eCATTs) muss mindestens das SAP Basis Release v6.20 oder ein älteres Release mit einem bestimmten Support Level Stand (4.6C - Support Package 32, 4.6D - Support Package 21 und 6.10 - Support Package 17) installiert sein sowie der Start von eCATTs und das user_scripting erlaubt sein (vgl. Tabelle sechs). Kriterium SAP Basis Release des Quellsystems Vorraussetzung ≥ 6.20 ≥ 6.20 SAP Basis Release des Zielsystems eCATT und CATT im Zielsystem erlaubt X Parameter sapgui/user_scripting true Tabelle 6: Voraussetzungen für den Einsatz des eCATT (Quelle: Eigene Tabelle). Sind alle Voraussetzungen erfüllt, können anschließend die eCATTs erstellt werden, was Inhalt der folgenden Anschnitte ist. - 61 - Black-Box-Testing 6.3.2 Vorgehensmodell zur Erstellung einer SAP eCATT-Testkonfiguration Zur Erstellung von Testkonfigurationen müssen im ersten Schritt das Quell- und die Zielsysteme über RFC-Verbindungen verbunden und die RFC-Verbindungen in einem Systemdaten-Container hinterlegt werden. Anschließend können die Transaktionen aufgezeichnet und die Testskripte formuliert werden. Sollen die Transaktionen massenweise ausgeführt werden, so sind Testdaten-Container zu erzeugen und mit entsprechenden Werten zu füllen, bevor Systemdaten-Container, Testskript und Testdaten-Container zu einer Testkonfiguration zusammengefügt und in die Test Workbench eingefügt werden können (siehe Abbildung 31) 1 Erstellung der RFC-Verbindungen 2 Anlage des Systemdaten-Containers 3 Formulierung des Testskripts 4 Erzeugung und Organisation des Testdaten-Containers 5 Erstellung der Testkonfiguration 6 Organisation der Testkonfiguration in der Test Workbench Abbildung 31: Vorgehen zur Erstellung einer Testserie (Quelle: Eigene Abbildung). Diese Schritte werden in den folgenden Abschnitten näher erläutert. 6.3.3 Systemdatencontainer und logischer Namen zur Zieldefinition Die eCATTs sollten zentral auf dem Solution Manager erstellt, gespeichert und gestartet, jedoch auf dem Zielsystem ausgeführt werden. Daher müssen beide Systeme durch eine RFCVerbindung miteinander verbunden werden. Die RFC-Verbindung definiert sich dabei über eine eindeutige ID, einen Verbindungstyp (z. B. 3 für ABAP-basierte Systeme, wie SAP ERP), eine Beschreibung und technischen Parametern zum Zielsystem (vom SAP-Administrator bereit zu stellen): - 62 - Black-Box-Testing Abbildung 32: RFC-Destination – Technische Einstellungen (Quelle: Eigene Abbildung). Unter dem Reiter ‚Anmeldung & Sicherheit’ können Anmeldeinformationen für die RFCVerbindung eingetragen werden: - 63 - Black-Box-Testing Abbildung 33: RFC-Destination - Anmeldung & Sicherheit (Quelle: Eigene Abbildung). Aus Sicherheitsgründen sollten jedoch keine Anmeldedaten hinterlegt, sondern nur die Sprache und der Mandant eingetragen werden. Durch das Setzen des Hakens bei ‚Aktueller Benutzer’ wird zuerst der den eCATT aufrufende Benutzer eingetragen. Eine Alternative hierzu stellt noch die Einrichtung eines ‚Trusted System’ dar, wodurch die Benutzerauthentifizierung entfällt. Dies soll jedoch hier nicht weiter beleuchtet werden. Weiterführende Informationen liefern hierzu die SAP-Hinweise 1167901 (Trusted-Trusting anstatt kennwortbehaftete Destination) und 128447 (Trusted/Trusting Systeme). Bei beiden Verfahren werden die Anmeldeinformationen in der RFC-Verbindung hinterlegt, so dass zur Abbildung eines 4-Augen-Prinzips (z. B. letzter Änderer darf nicht freigeben) zwei RFC-Verbindungen eingerichtet werden sollten. Sobald die RFC-Verbindungen eingerichtet sind, müssen diese in einen SystemdatenContainer aufgenommen werden, bevor sie genutzt werden können. Der Systemdaten-Container stellt eine Liste von Systemen dar, die durch das Testskript im Rahmen der Ausführung angesprochen werden können. Zu den Systemen wird im Systemdaten-Container sowohl die RFC-Destination, als auch ein logischer Name hinterlegt, der in den Testskipten verwendet wird. Dies hat den Vorteil, dass die RFC-Destination jederzeit ausgetauscht werden kann, ohne die Testskripte anpassen zu müssen. Um die Umsetzung der logischen Namen zu RFC-Destinationen kümmert sich der Systemdaten-Container (vgl. SAP AG, 2006, S. 1-23). - 64 - Black-Box-Testing Testskript Systemdatencontainer log. Ziel Zielsystem RFC Dest. Abbildung 34: Funktionsweise des Systemdatencontainers (Quelle: Eigene Abbildung nach SAP AG, 2006). Die Anlage eines neuen Systemdatencontainers wird, ebenso wie die Anlage der weiteren Objekte über die entsprechende Funktion in der zentralen Transaktion SECATT durchgeführt. Abbildung 35: Transaktion SECATT – Systemdaten (Quelle: Eigene Abbildung). Im Systemdaten-Container werden dann den einzelnen logischen Destinationen die vorher angelegten RFC-Destinationen zugeordnet: Abbildung 36: Systemdatencontainer – Systemdaten (Quelle: Eigene Abbildung). 6.3.4 Formulierung des Testskripts mit Hilfe von Attributen, Parametern und Kommandos Ein Testskript besteht aus Attributen, Parametern und Kommandos. Die Parameter eines Testskripts unterteilen sich noch einmal in - 65 - Black-Box-Testing Importparameter, die Daten von aus einem Testdatencontainer oder einem anderen Testskript erhalten Lokale Variablen, die nur innerhalb des Testskripts genutzt werden können und Exportparameter, die Daten an andere Testskripte weitergeben. Kommandos sind meist Aufzeichnungen einer oder mehrerer Transaktionen, die durch Prüfungen und Berechnungen ergänzt werden und den eigentlichen Testablauf formulieren. (vgl. SAP AG, 2006, S. 2-5) Testskript Attribute Import Parameter Lokale Variablen Export Kommandos Abbildung 37: Aufbau eines Testskripts (Quelle: Eigene Abbildung nach SAP AG, 2006). Im Testskript werden zuerst die Allgemeinen Daten gepflegt und die Verbindung zum Systemdaten-Container hergestellt: Abbildung 38: Testskript - Attribute - Allgemeine Daten (Quelle: Eigene Abbildung). - 66 - Black-Box-Testing Bevor dann im Reiter ‚Editor’ mit der Formulierung des Testskripts begonnen wird, sollten folgende Kommentarzeilen eingefügt und entsprechend befüllt werden: *&---------------------------------------------------------------------------------------------------*& TECHNISCHER_NAME_DES_TESTSKRIPTS *& Bezeichnung des Testskripts *&---------------------------------------------------------------------------------------------------*& erstellt am: TT.MM.JJJJ, Name des Erstellers (Firma) *& letzte Änderung: TT.MM.JJJJ, Name des Änderers (Firma) *&---------------------------------------------------------------------------------------------------*& Änderungshistorie: *& *& TT.MM.JJJJ Name des Änderers (Firma)........................MARKIERUNG *& Beschreibung der Änderung(en) *&---------------------------------------------------------------------------------------------------*& Anmerkung: *& *&---------------------------------------------------------------------------------------------------- * * * * * * * * * * * * * * * Danach kann mit der Aufzeichnung der Transaktion(en) begonnen werden. Um eine neue Aufzeichnung zu starten, muss ein neues Muster eingefügt und das Kommando SAPGUI ausgewählt werden: Abbildung 39: Auswahl des Musters SAPGUI (Quelle: Eigene Abbildung). Im Muster SAPGUI muss im Feld ‚Zielsystem’ muss die zu nutzende RFC-Verbindung aus dem Systemdatencontainer gewählt werden, bevor die entsprechende Granularität der Kommandoschnittstelle gewählt wird: - 67 - Black-Box-Testing Abbildung 40: Auswahl der Aufzeichnungstiefe (Quelle: Eigene Abbildung). Neben der manuellen Auswahl stehen noch folgende Granularitäten zur Verfügung: Sitzungsebene – alle Aktionen, auch wenn sie mehrere Transaktionen beinhalten, werden in einem SAPGUI-Kommando aufgezeichnet. Transaktionsebene – alle Aktionen einer Transaktion werden in einem SAPGUI-Kommando aufgezeichnet. Dynproebene – alle Aktionen eines Bildschirms (= Fensterinhalt) werden in einem SAPGUI-Kommando aufgezeichnet. Dialogschrittebene – alle Aktionen beim Wechsel zwischen Front- und Backend werden in einem SAPGUI-Kommando aufgezeichnet. Die Entscheidung zur Granularität der Aufzeichnung hängt zum einen von der Größe des Skripts und zum anderen von der Komplexität der Kommandoschnittstelle ab: je feiner die Granularität, desto übersichtlicher wird die Kommandoschnittstelle und desto unübersichtlicher das Testskript. Nach der Eingabe des Transaktionscodes und dem Start der Aufzeichnung wird der Nutzer zur Aufzeichnung ins Zielsystem geleitet und die Ausführung der Transaktion(en) aufgezeichnet. Wichtig: Es werden alle Felder aufgezeichnet, deren Wert manuell verändert worden ist. Das Aufrufen der Auswahlhilfe (F4) reicht jedoch nicht als Wertänderung aus – es sollte daher immer etwas manuell eingegeben (und danach, wo nötig, wieder gelöscht) werden. Nach erfolgter Aufzeichnung werden die erzeugten Kommandoschnittstellen in den Editor eingefügt und können mit einem Doppelklick zur Parametrisierung geöffnet werden: - 68 - Black-Box-Testing Abbildung 41: Editor - eingefügte Kommandoschnittstellen (Quelle: Eigene Abbildung). In der Kommandoschnittstelle werden alle Aktionen, die der Benutzer während der Aufzeichnung ausgeführt hat, detailliert dargestellt: Jeder ‚Processed Screen’ - Knoten entspricht einem ausgeführten Dynpro innerhalb der Kommandoschnittstelle. Unterhalb des ‚Processed Screen’ befinden sich die ‚UserChangeState’ Knoten. Diese listen einzeln alle Aktionen auf, die vom Nutzer während der Aufzeichnung auf GUI-Ebene durchgeführt wurden. Das können sowohl bearbeitete Felder (GuiElement), als auch erhaltene Nachrichten (Message) sein: Die Knoten ‚GuiElement’ erhalten je ein während der Aufzeichnung bearbeitetes Eingabefeld, welches parametrisiert werden kann. Die Knoten ‚Message’ enthalten einzelne Nachrichten, die während der Aufzeichnung durch Benutzeraktionen ausgelöst wurden und welche anschließend behandelt werden sollten. - 69 - Black-Box-Testing Abbildung 42: Kommandoschnittstelle (Quelle: Eigene Abbildung). Innerhalb des Knotens ‚GuiElement’ zeigt ein blauer Pfeil neben dem Wort ‚Text’ an, dass hier eine Eingabe stattgefunden hat, die parametrisiert werden kann. Zur Parametrisierung genügt ein Doppelklick auf das Wort ‚Text’, um die Detaillierung zu öffnen, in der man anschließend im Feld ‚Wert’ den ursprünglich eingegebenen Wert durch den jeweiligen Parameter ersetzen kann: Abbildung 43: Kommandoschnittstelle – Parametrisierung (Quelle: Eigene Abbildung). Um eine Übersicht der angelegten Parameter zu erhalten oder selbst welche anzulegen, kann eine entsprechende Übersicht aufgerufen werden: Abbildung 44: Parameteransicht (Quelle: Eigene Abbildung). In dieser Übersicht können auch neue Parameter angelegt werden, wobei Parameter, die später aus dem Testdaten-Container befüllt werden sollen, als Importparameter zu deklarieren sind. Bei der Anlage eines neuen Parameters genügt die Angabe der Parameter-ID (Feld ‚Parameter’), die Auswahl der Parameterart (Feld ‚I/E/V’) und die Angabe des - 70 - Black-Box-Testing Parameterbezugs (Feld ‚Bezug des Parameters’). Die restlichen Werte (z. B.: ABAP Typ oder Länge) zieht sich das System automatisch aus dem Zielsystem. Natürlich können auch die anderen ABAP Typen (I, C, N, D, T, F, X), sofern bekannt, genutzt werden. Neben der vorherigen Definition von Parametern (z. B. durch Befüllung des Feldes ‚Parameterwert’ in der Parameteransicht oder durch die Nutzung des Testdatencontainers) können die Parameter auch zur Laufzeit mit folgenden Inhalten befüllt werden: Parameterwert Bedeutung &SUBRC Return code &TIME Aktuelle Zeit &DATE Aktuelles Datum &YEAR Aktuelles Jahr &YEARA Nächstes Jahr &YEARB Letztes Jahr &LPC Schleifenzähler &MSX Anzahl der Nachrichten, die von einer Transaktion zurückgeliefert wurden &USER Angemeldeter Benutzer &CLIENT Aktueller Mandant &TFILL Anzahl der Einträge einer internen Tabelle Tabelle 7: Parameterwerte zur Laufzeit (Quelle: Eigene Tabelle nach SAP AG, o.J). Zur Nutzung dieser Parameterwerte reicht im Skript eine einfache Zuweisung, wie z. B. ‚Parameter = &DATE.’ Soll ein Parameter dediziert in das Protokoll geschrieben werden, genügt die Eingabe der folgenden Skriptzeile: ‚LOG ( Parameter ).’ Alternativ kann das entsprechende Muster genutzt werden: Abbildung 45: Muster einfügen – Log (Quelle: Eigene Abbildung). - 71 - Black-Box-Testing 6.3.5 Nutzung eines Testdatencontainers Der Testdaten-Container stellt eine Sammlung von wieder verwendbaren Datensätzen zur Testausführung dar. Innerhalb eines Testdaten-Containers können mehrere Varianten von Datensätzen abgelegt und in verschiedenen Systemkonfigurationen verwendet werden. Auch der Testdatencontainer wird in der zentralen Transaktion SECATT angelegt. Innerhalb der Transaktion hat man die Möglichkeit die Parameter aus dem aufgezeichneten Testskript in den Testdaten-Container zu übernehmen: Abbildung 46: Parameter importieren (Quelle: Eigene Abbildung). Danach ist der Testdaten-Container bereit für die Aufnahme der Datensätze, die unter dem Reiter ‚Varianten’ abgelegt werden. Die Varianten selbst können entweder manuell angelegt oder in Microsoft Excel hoch geladen werden. Abbildung 47: Aufruf der Funktion Varianten herunterladen (Quelle: Eigene Abbildung). - 72 - Black-Box-Testing Zu letzterem muss in der Menüleiste unter ‚Bearbeiten’ die Funktion ‚Varianten’ und dort die Option ‚Herunterladen’ aufgerufen werden. Anschließend öffnet sich ein Dateidialog, in dem der Ablageort der zu herunter zuladenden Textdatei angegeben werden muss. Nach erfolgtem Download kann die Datei in Microsoft Excel geöffnet und entsprechend mit Varianten befüllt werden. Abbildung 48: Excel-Datei zum Varianten-Upload (Quelle: Eigene Abbildung). Hierbei können beliebig viele Varianten eingefügt werden, die sich jedoch wenigstens in der Variantenbezeichnung unterscheiden sollten. Sobald die Befüllung abgeschlossen ist, muss die Datei wiederum im Textformat gespeichert und hochgeladen werden. Abbildung 49: Aufruf der Funktion Varianten hochladen (Quelle: Eigene Abbildung). Anschließend werden die hochgeladenen Varianten im entsprechenden Reiter angezeigt und können in Testkonfigurationen verwendet werden: Abbildung 50: Variantenübersicht (Quelle: Eigene Abbildung). - 73 - Black-Box-Testing 6.3.6 Zusammenfassung aller Elemente im Testskript und Einhängen in die Test Workbench des Solution Managers Die Testkonfiguration stellt eine Kombination aus Systemdaten-Container, Testskript und Testdaten-Container dar, die als Ganzes in die Test Workbench aufgenommen werden kann. Bei der Anlage muss entsprechend auf alle zu verwendenden Objekte referenziert werden: Abbildung 51: Testkonfiguration – Konfiguration (Quelle: Eigene Abbildung). Neben der Nutzung eines oder mehrerer Testdaten-Container besteht hier auch die Möglichkeit im Reiter ‚Varianten’ einen Pfad zu einer MS EXCELl-Datei auf einem beliebigen Laufwerk zu hinterlegen, die die so genannten externen Varianten beinhaltet oder aber auch per Copy & Paste so genannte interne Varianten zu hinterlegen. Bei der Nutzung von externen Varianten werden immer alle Varianten der entsprechenden Datei ausgeführt. Bei der Nutzung von internen Varianten besteht die Möglichkeit vor der Ausführung eine entsprechende Auswahl zu treffen. Beim Start der Testkonfiguration (aus der Transaktion SECATT oder aus der Test Workbench heraus) können verschiedene Start- und Abbruchbedingungen festgelegt werden: - 74 - Black-Box-Testing Abbildung 52: Startoptionen (Quelle: Eigene Abbildung). Beim Testen der Testkonfiguration selbst sollte ‚X Abbruch des Startvorgangs’ und bei späteren Ausführung der Testkonfiguration ‚V Abbruch, Weiter mit nächster Varianten’ gewählt werden. Nach erfolgtem Durchlauf der Testkonfiguration wird ein entsprechendes Protokoll angezeigt und automatisch gespeichert: - 75 - Black-Box-Testing Abbildung 53: Protokoll (Quelle: Eigene Abbildung). Um die Testkonfiguration in die Geschäftsprozessbibliothek zu integrieren, muss der jeweilige Prozessschritt in dieser ausgewählt: Abbildung 54: Transaktion SOLAR02 – Konfiguration (Quelle: Eigene Abbildung). und der eCATT im Reiter ‚Testfälle’ eingefügt werden: - 76 - Black-Box-Testing Abbildung 55: Transaktion SOLAR02 - Konfiguration – Testfälle (Quelle: Eigene Abbildung). Anschließend kann die Testkonfiguration in Testplänen und Testpaketen verwendet und von den Nutzern ausgeführt werden. 6.4 Praktische Erfahrungen zur Nutzung der SAP eCATT In der Theorie sprechen viele Punkte für den Einsatz der SAP eCATT: so reduziert die maschinelle Abwicklung der Testeingaben die Gefahr von manuellen Fehleingaben, die Testfälle können auf anderen Systemen eingesetzt werden und werden darüber hinaus lückenlos dokumentiert. In der Praxis werden die SAP eCATT jedoch nur selten eingesetzt: zu groß ist der initiale Aufwand zur Erstellung der Testfälle und zur Definition der Varianten, zu klein der wahrgenommene Nutzen. Darüber hinaus bedingen Änderungen am Customizing oftmals eine erneute Aufzeichnung der jeweiligen Kommandoschnittstelle, so dass für die eCATTs selbst ein zusätzlicher Pflegeaufwand entsteht. In vielen Unternehmen werden die eCATTs jedoch von der IT-Abteilung zweckentfremdet und, auch wenn es die SAP offiziell nicht unterstützt und auf Gefahren hinweist, zur Migration von Daten oder zur Automatisierung von häufig durchzuführenden Tätigkeiten (z. B. Anlage von Benutzern) genutzt. - 77 - Black-Box-Testing 7 Zusammenfassung Black-Box-Tests stellen eine Software-Testmethode dar, bei welcher die innere Struktur, das Design und die Art der Implementierung dem Testenden nicht bekannt sind. Daher ist kein besonderes Vorwissen zur Anwendung oder über die Programmierung notwendig, so dass beliebige Anwender in den Testprozess integriert werden können. Darüber hinaus helfen Black-Box-Tests, über verschiedene Methoden, das gesamte Funktionsspektrum eines Software-Produkts zu testen. Zu den Nachteilen zählen, geeignete Testfälle und Testdaten auszuwählen, um so eine möglichst hohe Fehlererkennungsrate zu erreichen. Die Grundlogik von Black-Box-Tests bringt es mit sich, dass erkannte Fehler nicht direkt hergeleitet werden können, sondern tiefergehende Analysen erfordern. Letztlich bieten Black-Box-Tests eine hervorragende Möglichkeit das Vorhandensein von Fehler festzustellen, ihre vollständige Abwesenheit lässt sich auf diesem Weg aber nicht ausschließen. Das Ziel kann daher nur sein, Black-Box-Tests mit anderen Methoden zu verknüpfen, z. B. White-Box-Tests, um so die Wahrscheinlichkeit möglicher Fehler und Fehlerquellen zu minimieren und für den betrieblichen Einsatz hinreichend vorzubereiten. Im SAP-Umfeld erfreuen sich Black-Box-Tests einer großen Beliebtheit. Im Rahmen der ASAP-Methodik, welche das Vorgehensmodell zur Einführung von SAP ERP in einem Unternehmen darstellt, basieren die meisten Tests auf der Black-Box-Technik. Aus diesem Grund haben sich auf dem Markt bereits Werkzeuge etabliert, die extra für dieses Umfeld entwickelt wurden. In dieser Arbeit wurden die Werkzeuge SAP Quality Center by HP sowie eCATT vorgestellt. SAP Quality Center by HP kann in das SAP-Anwendungsmanagement-Werkzeug Solution Manager integriert werden, so dass ein permanenter Informationsaustausch zwischen der Anwendungsmanagement- und Qualitätssicherungsumgebung hergestellt werden kann. Das Quality Center basiert auf der J2EE-Technologie, hat eine leicht verständliche Benutzeroberfläche und bietet die Möglichkeit den Aufwand beim Erstellen von Testfällen erheblich zu reduzieren, indem die Testbeschreibung in atomare wiederverwendbare Einheiten zerlegt und von den Testdaten getrennt wird. Mit Hilfe von Berichten und Grafiken, die im SAP Quality Center by HP zur Verfügung stehen, kann der Testfortschritt in Echtzeit nach verschiedenen Kriterien ausgewertet werden. In dieser Arbeit wurden zwei Berichte aus der Praxis vorgestellt, in welchen SAP Quality Centers by HP zur Anwendung kam und den Testaufwand deutlich reduzieren konnte. Die SAP eCATT stellen ein Werkzeug zur Testautomatisierung dar, welche auf allen SAPSystemen kostenlos nutzbar sind. Durch die Testautomatisierung können die Aufwände, insbesondere bei Massen- oder Regressionstests erheblich reduziert werden. Die eCATTs werden dabei bestenfalls auf dem SAP Solution Manager erstellt und verwaltet sowie auf den Zielsystemen nur ausgeführt. Dadurch haben die Tester einen zentralen Anlaufpunkt für alle - 78 - Black-Box-Testing Tests und die Testkoordinatoren eine zentrale Übersicht und Protokollablageinstanz. Die Erstellung der eCATTs wurde im entsprechenden Kapitel beschrieben und zeigt, dass die initiale Erstellung einerseits sehr aufwändig und andererseits auch sehr gut durchdacht sein muss. Gerade Ersteres ist der Grund, dass die eCATTs in der Praxis nur sehr selten in der Testautomation eingesetzt werden. Dennoch haben sie Ihre Daseinsberechtigung, weil sie in einigen Fällen genau die benötigten Funktionalitäten bieten, um beispielsweise Daten zu migrieren oder häufig auszuführende Tätigkeiten zu automatisieren, die andere Werkzeuge hinterlassen. - 79 - Black-Box-Testing 8 Literaturverzeichnis Alpar, P., Grob, H. L., Weimann, P. & Winter, R. (2008). Anwendungsorientierte Wirtschaftsinformatik: Strategische Planung, Entwicklung und Nutzung von Informations-und Kommunikationssystemen. 5. Auflage. Friedr. Vieweg & Sohn Verlag. Aßmann, U. Testwerkzeuge. (13.01.2011) (st.inf.tu-dresden.de). http://st.inf.tudresden.de/Lehre/WS09-10/sew/slides/sew-40-testwerkzeuge-2x2.pdf. Abgerufen am 13.10.2011. Baltaci, K. Cyberkriminalität: Die unsichtbare Gefahr aus dem Netz. (20.09.2011) (diepresse.com). http://diepresse.com/home/techscience/internet/sicherheit/694677/Cyberkriminalitaet_Die -unsichtbare-Gefahr-aus-dem-Netz. Abgerufen am 15.10.2011. Bayer, M. Zu 100 Prozent fehlerfreie Software gibt es nicht. (20.10.2005) (computerwoche.de). http://www.computerwoche.de/nachrichtenarchiv/567618/. Abgerufen am 08.10.2011. Bender, K. (2005). Embedded Systems - Qualitätsorientierte Entwicklung. Springer Verlag: Berlin. Bieber, E. Trends beim Software-Testing: Fehlerfreie Software gibt es nicht. (04.05.2011) (cio.de). http://www.cio.de/strategien/analysen/2273064/. Abgerufen am 08.10.2011. Black, R. (2009). Managing the Testing Process: Practical Tools and Techniques for Managing. 3. Auflage. Wiley Publishing. BSI. Durchführungskonzept für Penetrationstests. (11.2007). (bsi.bund.de). https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/Penetrat ionstest/penetrationstest_pdf.pdf?__blob=publicationFile. Abgerufen am 15.10.2011. Cleff, T. (2010). Basiswissen Testen von Software: Vorbereitung zum Certified Tester (Foundation Level) nach ISTQB-Standard. W3L GmbH Verlag: Herdeke | Witten. DerWesten. Internet-Kriminalität: Sony räumt weiteren Diebstahl von Kundendaten ein Wirtschaft und Finanzen - DerWesten. (03.05.2011) (derwesten.de). http://www.derwesten.de/nachrichten/wirtschaft-und-finanzen/Sony-raeumt-weiterenDiebstahl-von-Kundendaten-ein-id4605751.html. Abgerufen am 15.10.2011. Desikan, S. & Ramesh, G. (2008). Software Testing: Principles and Practice. 6. Auflage. Dorling Kindersley. Dustin, E., Rashka, J. & Paul, J. (2001). Software Automatisch Test: Verfahren, Handhabung, Leistung. Springer-Verlag. . Franz, K. (2007). Handbuch Zum Testen Von Web-Applikationen. Testverfahren, Werkzeuge, Praxistipps. Springer-Verlag: Berlin. - 80 - Black-Box-Testing Frühauf, K., Ludewig, J. & Sandmayr, H. (2007). Software-Prüfung: Eine Anleitung zum Test und zur Inspektion. vdf Lehrbuch. 6. Auflage. Vdf Hochschulverlag: Zürich. Gabler Wirtschaftslexikon Redaktion (2000). Gabler Wirtschaftslexikon: Die ganze Welt der Wirtschaft: Betriebswirtschaft – Volkswirtschaft – Recht – Steuern.15. Auflage. Gabler Verlag: Wiesbaden. Geiger, W. & Kotte, W. (2005). Handbuch Qualität. 4. Auflage. Friedr. Vieweg & Sohn Verlag / GWV Fachverlage GmbH: Wiesbaden. Grechenig, T. & Bernhart, M. Softwaretechnik: Mit Fallbeispielen aus realen Entwicklungsprojekten. (2009). Pearson Studium Pearson Studium: München. Helfen, M., Trauthwein, M. H. (2010). SAP-Lösungen testen. 2. Auflage (1. korrigierter Nachdruck). Galileo Press: Bonn. Hoffmann, D. W. (2008). Software-Qualität. Springer-Verlag: New York Inc. Jeckle, M. Use-Case-Diagramme. (24.01.2005). (jeckle.de). http://www.jeckle.de/umlglasklar/UseCaseDiagramm.pdf. Abgerufen am 15.10.20011. Kleuker, S. (2011). Grundkurs Software-Engineering mit UML: Der Pragmatische Weg zu Erfolgreichen Softwareprojekten. 2. Auflage. Vieweg + Teubner Verlag / Springer Fachmedien: Wiesbaden. Liggesmeyer, P. (2009). Software-Qualität: Testen, Analysieren und Verifizieren von Software: Testen, Analysieren und Verifizieren von Software. 2. Auflage. Spektrum Akademischer Verlag. Limaye, M. G. (2009). Software Testing: Principles, Techniques and Tools. Tata McGrawHill Education. Maiborn, V., Anleitung für professionelles Software-Testmanagement. (17.07.2009) (www.heise.de). http://www.heise.de/developer/artikel/Anleitung-fuer-professionellesSoftware-Testmanagement-227244.html. Abgerufen am 13.09.2011. Mathur, A. P. (2011). Foundations of Software Testing. Dorling Kindersley: India. Michael, C. C. & Radosevich, W. Black Box Security Testing Tools. (27.07.2009) (buildsecurityin.us-cert.gov). https://buildsecurityin.us-cert.gov/bsi/articles/tools/blackbox/261-BSI.html.. Abgerufen am 05.09.2011. Myers, G. J., Badgett, T., Thomas, T. M. & Sandler, C. (2004). The art of software testing. 2. Auflage. John Wiley & Sons. Niemann, F., Pütter, C. SAP angeblich Mitschuld an Juwelier-Pleite. (22.01.2009) (www.cio.de) http://www.cio.de/knowledgecenter/erp/870146/. Abgerufen am 03.10.2011. Oestereich, B. (2009). Die UML-Kurzreferenz 2.3 für die Praxis: kurz, bündig, ballastfrei. Oldenbourg Verlag: München. - 81 - Black-Box-Testing Petrasch, R. (2001). Einführung in das Software-Qualitätsmanagement. Logos Verlag Berlin. Pol, M., Koomen, T. & Spillner, A. (2002). Management und Optimierung des Testprozesses. 2. Auflage. Dpunkt Verlag. QMETHODS - Business & IT Consulting GmbH. HP Quality Center. (o. J. ) (http://www.qmethods.com/). http://www.qmethods.com/service_hp-qualitycenter.html. Abgerufen am 28.09.2011. Roitzsch, E. H. P. (2005). Analytische Softwarequalitätssicherung in Theorie und Praxis. Verlagshaus Monsenstein und Vannerdat: Münster. Rupp, C. & Die SOPHISTen (2009). Requirements-Engineering und –Management: Professionelle, Iterative Anforderungsanalyse für die Praxis. 5. Auflage. Carl Hanser Verlag: München. SAP AG. Geschichte. (o. J. ) (www.sap.com). http://www.sap.com/corporate-de/ourcompany/history.epx. Abgerufen am 03.10.2011. SAP AG (2006). CA611 – Testmanagement mit dem neuen eCATT. Schulungsunterlage 50080664. Anmerkung: Die Seitenangaben stellen immer Kapitel (XX) und Seite (YY) in der Form XX-YY dar. SAP AG. SAP Deutschland - Komponenten und Werkzeuge von SAP NetWeaver: SAP Solution Manager, (o. J.) (www.sap.com). http://www.sap.com/germany/plattform/netweaver/components/solutionmanager/index.ep x. Abgerufen am 15.10.2011 Sneed, H. M. & Jungmay, S. (2006). Produkt- und Prozessmetriken für den Softwaretest. Informatik Spektrum 29, 23–38. Sneed, H. M., Baumgartner, M. & Seidl, R. (2008). Der Systemtest: Von den Anforderungen zum Qualitätsnachweis. 2. Auflage. Hanser Fachbuchverlag. softwaretestingfundamentals. Software Testing Fundamentals. (30.08.2011). (softwaretestingfundamentals.com). http://softwaretestingfundamentals.com/differencesbetween-black-box-testing-and-white-box-testing/. Abgerufen am 12.09.2011. SoftwareTestingStuff. Functional Testing vs Non-Functional Testing. (15.10.2007) (Software Testing Stuff). http://www.softwaretestingstuff.com/2007/10/functional-testing-vs-nonfunctional.html. Abgerufen am 15.10.2011. Sommerville, I. (2007). Software Engineering. 8. Auflage. Pearson Studium. Steeb Anwendungssysteme GmbH: Die Steeb Projektmethodik zur erfolgreichen Einführung Ihrer SAP-Lösung. (o.J.). (www.steeb.de). http://www.steeb.de/leistungen/beratung/einfuehrung-sap-loesungen.html. Abgerufen am 14.09.2011. - 82 - Black-Box-Testing Testing Concepts. Quality Center: All about it. (06.02.2011) (http://qaconcepts.blogspot.com/). http://qse.ifs.tuwien.ac.at/courses/skriptum/download/10P_Nonfunkt_wid_20040204.pdf. Abgerufen am 15.10.2011. TU Wien. Nicht-funktionale Testmethoden. (o. J.).(qse.ifs.tuwien.ac.at). http://qse.ifs.tuwien.ac.at/courses/skriptum/download/10P_Nonfunkt_wid_20040204.pdf. Abgerufen am 15.10.2011. Versteegen, G., Chughtai, A., Dörnemann, H., Heinold, R. & Hubert, H. (2002). SoftwareManagement. Beherrschung des Lifecycles. Springer Verlag: Berlin. Vivit Germany (05.11.2008). Qualitätssicherung und Software Testing mit HP Quality Center. (http://www.vivit-germany.org/). http://www.vivitgermany.org/pdf/Vivit08_D%FCsseldorf_QualityCenter_Blank.pdf. Abgerufen am 15.09.2011. Wallmüller, E. (2001). Software-Qualitätsmanagement in der Praxis. 2. Auflage. Hanser Verlag. weibull.com. weibull.com. (o. J.) (weibull.com). http://www.weibull.com. Abgerufen am 2011-10-08. Williams, L. Testing Overview and Black-Box Testing Techniques. (2006) (RealSearchGroup). http://agile.csc.ncsu.edu/SEMaterials/BlackBox.pdf. Abgerufen am 16.10.2011. Wirtz, G. Nichtfunktionale Tests. (02.09.2009) (enzyklopaedie-der-wirtschaftsinformatik.de). http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/ismanagement/Systementwicklung/Hauptaktivitaten-der-Systementwicklung/SoftwareImplementierung/Testen-von-Software/nichtfunktionale-tests. Abgerufen am 15.10.2011. - 83 -
