Hochschule Wismar. Fakultät für Wirtschaftsinformatik. Master-Thesis

Transkript

1 Hochschule Wismar Fakultät für Wirtschaftsinformatik Master-Thesis Entwicklung eines Referenzmodells für Software-Testwerkzeuge sowie dessen Anwendung im SAP-Umfeld Thesis zur Erlangung des Grades eines Master of Science (M.Sc.) eingereicht von: geboren am in Stuttgart Fernstudium Master Wirtschftsinformatik Betreuer: weitere Gutachter: Prof. Dr. Jürgen Cleve Prof. Dr. Jan Helmke Stuttgart, den 13. Februar 2013

2 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Abkürzungsverzeichnis IV V VI 1 Einführung Definition und Bedeutung von Software-Qualität Merkmale der Software-Qualität Ziel und Vorgehen Abgrenzung der Themen Einordnung in die Wirtschaftsinformatik Testmethoden Überblick Software-Qualitätssicherung und Software-Test Klassifizierung der Testmethoden Einsatz der Testmethoden im Software-Lebenszyklus Begriffsdefinitionen Funktionsorientierte Methoden Grundlagen Äquivalenzklassenbildung Grenzwertanalyse Zustandsbasierter Test Strukturorientierte Methoden Grundlagen Analyse der Kontrollstruktur Kontrollflussorientierte Methoden Datenflussorientierte Methoden Bewertung Statische Prüfungen Grundlagen Manuelle Prüfung Automatisierte Prüfung Metriken Formale Verifikation I -

3 3 Testwerkzeuge Grundlagen Definition Ziele des Einsatzes Möglichkeiten der Klassifizierung Anwendungsbereiche Testmanagement und -steuerung Generierung von Testdaten und Testfällen Messung und Visualisierung der Testüberdeckung Testausführung Statische Prüfung und Verifikation Nicht funktionaler Test Einführung Voraussetzungen Werkzeug-Auswahl Einführungsprozess Referenzmodell Grundlagen der Referenzmodellierung Begriffsdefinitionen Arten von Referenzmodellen Qualitätsanforderungen an Referenzmodelle Vorgehen bei der Referenzmodellierung Referenzmodell für Software-Testwerkzeuge Problemdefinition und Zielsetzung Ordnungsrahmen Struktur Bausteine Komplettierung und Anwendung Anwendung des Referenzmodells Vorgehen Art und Ziel der Anwendung Auswahl und Analyse der Testwerkzeuge Analyse der Testwerkzeuge SAP Test Workbench SAP ecatt AFI Automatic Test Tool Schlussbetrachtung 83 - II -

4 6.1 Zusammenfassung Ausblick Literaturverzeichnis 88 Ehrenwörtliche Erklärung VII - III -

5 Abbildungsverzeichnis 1 Anforderungsprofil des Wirtschaftsinformatikers Klassifikation der Maßnahmen der Software-Qualitätssicherung Klassifikationsschema für Testmethoden Testphasen der Systementwicklung Abstrakte Darstellung eines Kontrollflussgraphen Ausprägungen des Datenflusses Taxonomie der automatisierten statischen Software-Prüfung Aufgabenbereiche des Testmanagements und der Teststeuerung Unterstützung der Testausführung durch Testwerkzeuge Beschaffung und Einführung eines Testwerkzeugs als Eisbergmodell Vorgehensmodell der Referenzmodellierung Referenzmodell für Testwerkzeuge: Ordnungsrahmen Referenzmodell für Testwerkzeuge: Übersicht Referenzmodell für Testwerkzeuge: Baustein Testmanagement und Teststeuerung Referenzmodell für Testwerkzeuge: Baustein Testausführung Referenzmodell für Testwerkzeuge: Baustein Statische Prüfung und Verifikation Anwendungsfall-Diagramm des Testwerkzeugs SAP Test Workbench Anwendungsfall-Diagramm des Testwerkzeugs SAP ecatt Anwendungsfall-Diagramm des Testwerkzeugs AFI Automatic Test Tool IV -

6 Tabellenverzeichnis 1 Verbreitete funktionsorientierte Testmethoden Kontrollflussorientierte Testmethoden Datenflussorientierte Testmethoden Varianten der manuellen statischen Softwareprüfung Verbreitete Metriken der Software-Qualitätssicherung Grundsätze ordnungsmäßiger Modellierung V -

7 Abkürzungsverzeichnis ABAP AFI AG BWL CAST ecatt EPK ERM ERP GmbH GoM GUI IDEF IS IT LOC MBT MTBF SA UML WI Advanced Business Application Programming P.M. Belz Agentur für Informatik GmbH Aktiengesellschaft Betriebswirtschaftslehre Computer Aided Software Testing extended Computer Aided Test Tool Ereignisgesteuerte Prozesskette Entity-Relationship-Modell Enterprise Resource Planning Gesellschaft mit beschränkter Haftung Grundsätze ordnungsmäßiger Modellierung Graphical User Interface Integrated Definition Informationssystem Informationstechnik Lines of Code Modellbasiertes Testen Mean Time Between Failures Strukturierte Analyse Unified Modeling Language Wirtschaftsinformatik - VI -

8 1 Einführung 1.1 Definition und Bedeutung von Software-Qualität Der Begriff der Software-Qualität wird in der ISO-Norm 9126 definiert als: [...] Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte Erfordernisse zu erfüllen. [ISO/IEC 9126, 2001] 1 Festzustellen ist hierbei, dass die Qualität eines Software-Produkts nicht durch ein Merkmal allein, sondern durch eine Reihe verschiedener Merkmale festgelegt wird. Weiterhin geht aus der Definition hervor, dass Qualität immer im Hinblick auf konkrete Erfordernisse gemessen wird. Im Rahmen der Software-Qualitätssicherung wird somit geprüft, ob das Software-Produkt die an es gestellten Qualitätsanforderungen erfüllt. Die Bedeutung der Qualität von Software-Anwendungen steigt seit einigen Jahren kontinuierlich, was auf zwei Hauptgründe zurückgeführt werden kann. Zum einen findet die Computertechnik immer größere Verbreitung und wird zunehmend auch in sicherheitskritischen Bereichen eingesetzt. Mit Hilfe der Methoden der Software-Qualitätssicherung soll deshalb sichergestellt werden, dass durch Softwarefehler weder Personenschäden entstehen noch erfolgskritische Geschäftsprozesse gestört werden. Zum anderen schreitet die Miniaturisierung der Computertechnik immer weiter voran, wodurch die Integrierung von Computerchips in Alltagsgegenstände ermöglicht wird. Aufgrund dieses Trends sind die Auswirkungen von Fehlern und Sicherheitslücken in der Steuerungssoftware solcher Chips nur schwer absehbar. Die beschriebenen Entwicklungen haben das Potenzial, in ein ubiquitäres Computerzeitalter zu führen. Um die Risiken dieses umfassenden Einsatzes der Computertechnik überschaubar zu halten, sind die systematische Anwendung der Methoden der Software- Qualitätssicherung sowie die Definition und Einhaltung von Qualitätsstandards unabdingbar. [Hoffmann, 2008, S. 2 f.] 2 1 ISO-Norm 9126 wurde in ISO-Norm integriert und von dieser abgelöst. In der vorliegenden Arbeit wird dennoch auf ISO-Norm 9126 zurückgegriffen, da nur der produktbezogene Aspekt der Software-Qualität behandelt werden soll. 2 In dieser Arbeit werden Quellenangaben immer dann am Absatzende positioniert, wenn sich mehrere Sätze des Absatzes sinngemäß auf die angegebene Quelle beziehen

9 1.2 Merkmale der Software-Qualität In der ISO-Norm 9126 [ISO/IEC 9126, 2001] werden folgende Merkmale genannt, welche zur Bewertung der Qualität eines Software-Produkts herangezogen werden können: Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit. Nachdem für jedes dieser Merkmale der erforderliche Merkmalswert festgelegt wurde, kann mit Hilfe eines Tests überprüft werden, ob das Produkt den notwendigen Qualitätsstandard erfüllt. Hierbei ist zu beachten, dass die Merkmale teilweise in konkurrierenden Beziehungen zueinander stehen; die Förderung eines Qualitätsmerkmals kann somit zu Lasten eines anderen gehen. Beispielsweise ist ein Software-System, das sich leicht ändern und übertragen lässt, in der Regel weniger effizient als ein hochgradig spezialisiertes System, welches auf eine bestimmte Umgebung zugeschnitten wurde und nur dort lauffähig ist. [Spillner u. Linz, 2012, S. 14] Nachfolgend werden die oben genannten Qualitätsmerkmale kurz erläutert. Das Merkmal der Funktionalität gibt an, in welchem Maße das Software-Produkt den geforderten Funktionsumfang enthält. Dabei geht es nicht nur darum, ob eine Funktion vorhanden ist oder nicht, sondern auch um die Art ihrer Realisierung. Hierzu zählen beispielsweise Reaktionen auf Bedienungsfehler und die Einhaltung von Normen und gesetzlichen Richtlinien. Bei der Ermittlung der Zuverlässigkeit wird geprüft, ob das System in der Lage ist, sein Leistungsniveau unter bestimmten Bedingungen über einen längeren Zeitraum aufrecht zu erhalten. Hierbei spielt beispielsweise eine Rolle, ob Fehlerzustände zu Systemsausfällen oder Datenverlusten führen. Die Benutzbarkeit bezieht sich auf die Mensch-Maschine-Interaktion und gibt an, wie viel Aufwand mit der Nutzung des Systems verbunden ist. Hierzu zählen unter anderem die Verständlichkeit und der Aufwand für die Einarbeitung in die Bedienung des Systems. Das Merkmal der Effizienz zielt auf die Betriebsmittel ab, die für den Einsatz des Systems notwendig sind. Hierzu gehören insbesondere die vom System benötigten und beanspruchten Hardwarekomponenten. Das Merkmal der Änderbarkeit oder Wartbarkeit des Systems gibt an, welcher Aufwand für die Durchführung von Änderungen und Erweiterungen notwendig ist. Die Übertragbarkeit gibt Aufschluss darüber, wie einfach das System für eine andere Umgebung angepasst und dort installiert werden kann. Systemumgebungen können sich beispielsweise in dem verwendeten Betriebssystem oder der eingesetzten Hardware-Architektur unterscheiden. Hoffmann [Hoffmann, 2008, S. 8 f.] erweitert die oben aufgeführte Liste der Qualitätsmerkmale um Transparenz und Testbarkeit. Die Transparenz gibt an, ob die Funktionen des Software-Systems sorgfältig und strukturiert realisiert wurden. Hierbei sind die durchgängige Anwendung einer Software-Architektur sowie die Einhaltung von Programmierrichtlinien von entscheidender Bedeutung. Das Merkmal der Testbarkeit gibt Aufschluss darüber, welcher Aufwand für den Test des Systems notwendig ist. Im optimalen Fall wurde dieser - 2 -

10 Aspekt beim Entwurf des Systems berücksichtigt, wodurch beispielsweise der Einsatz automatischer Testverfahren vereinfacht wird. Nach Meinung des Autors werden mit Transparenz und Testbarkeit Qualitätsmerkmale explizit herausgestellt, die in der ISO-Norm im Merkmal der Wartbarkeit bereits implizit enthalten sind. 1.3 Ziel und Vorgehen Das Ziel der vorliegenden Arbeit besteht darin, ein funktionsorientiertes Referenzmodell für Software-Testwerkzeuge zu entwickeln und anzuwenden. Um die Grundlagen für die Entwicklung des Referenzmodells zu legen, werden im ersten Teil der Arbeit zunächst verbreitete Methoden der Software-Qualitätssicherung beschrieben. Testwerkzeuge implementieren diese Methoden und ermöglichen so deren effizienten Einsatz in der betrieblichen Praxis. Anschließend werden die verschiedenen Klassen von Testwerkzeugen sowie die mit ihrem Einsatz verbundenen Ziele vorgestellt. Die Vorbereitungen für die Entwicklung des Referenzmodells werden schließlich durch die Grundlagen der Referenzmodellierung abgeschlossen. Das Referenzmodell, welches auf Basis dieser Erörterungen entwickelt wird, beschreibt den idealen Funktionsumfang eines Testwerkzeugs. Es gibt somit Aufschluss darüber, welche der Methoden der Software-Qualitätssicherung in einem Testwerkzeug implementiert werden können und welche Anforderungen hierbei berücksichtigt werden sollten, um eine effiziente Anwendung der Methoden in der Praxis zu ermöglichen. Die Anwendung des Referenzmodells kann verschiedenen Zielen dienen: Zum einen kann mit Hilfe des im Referenzmodell gespeicherten Wissens die Entwicklung eines neuen Testwerkzeugs systematisch und effizient durchgeführt werden. Zum anderen kann das Referenzmodell zur Analyse, zur Bewertung sowie zum Vergleich bestehender Testwerkzeuge herangezogen werden. Weiterhin unterstützt das Modell den Prozess zur Beschaffung eines Testwerkzeugs, da die spezifischen Anforderungen der jeweiligen Organisation aus dem im Referenzmodell beschriebenen idealen Funktionsumfang abgeleitet werden können. Im praxisbezogenen Teil der Arbeit wird das zuvor aufgestellte Referenzmodell auf verschiedene Testwerkzeuge aus dem SAP-Umfeld angewendet. Dabei wird das Ziel verfolgt, diese Werkzeuge zu klassifizieren und zu charakterisieren sowie ihre Stärken, Schwächen und Weiterentwicklungspotenziale systematisch aufzudecken

11 1.4 Abgrenzung der Themen Als Vorbereitung für die Entwicklung des Referenzmodells werden die in der einschlägigen Literatur verbreiteten Methoden der Software-Qualitätssicherung erläutert. Dabei wird das Ziel verfolgt, einen Überblick über die verschiedenen Verfahren zu geben, die in Testwerkzeugen implementiert werden können. Eine detaillierte Erläuterung der Methoden ist aufgrund des beschränkten Umfangs der vorliegenden Arbeit hingegen nicht möglich. Das Referenzmodell für Software-Testwerkzeuge, welches im Rahmen der vorliegenden Arbeit entwickelt wird, besitzt funktionsorientierten Charakter. Somit beschreibt es den idealen Funktionsumfang eines Testwerkzeugs, schließt jedoch weder den Prozess zur Entwicklung eines Testwerkzeugs noch den technischen Entwurf eines solchen Werkzeugs ein. Die Anwendung des Referenzmodells erfolgt exemplarisch unter Verwendung verschiedener Testwerkzeuge aus dem SAP-Umfeld. Eine erschöpfende Analyse der in diesem Bereich verfügbaren Testwerkzeuge ist im Rahmen der vorliegenden Arbeit hingegen nicht möglich. Auch auf die Neuentwicklung eines solchen Werkzeugs unter Verwendung des Referenzmodells muss aufgrund des beschränkten Umfangs der vorliegenden Arbeit verzichtet werden. 1.5 Einordnung in die Wirtschaftsinformatik Die Wissenschaftsdisziplin der Wirtschaftsinformatik beschäftigt sich mit der Entwicklung und Anwendung betrieblicher Informationssysteme. Das Informationssystem wird hierbei als ein soziotechnisches System verstanden, welches der Lösung betrieblicher Aufgabenstellungen dient und von Menschen gestaltet und genutzt wird. Weiterhin ist das Informationssystem in den organisatorischen Kontext des einsetzenden Unternehmens eingebettet und wird mit den Mitteln der Informationstechnik realisiert. [Bächle u. Kolb, 2012, S. 6 f.] Die Einordnung der vorliegenden Arbeit in das Fachgebiet der Wirtschaftsinformatik erfolgt auf Grundlage der Anforderungen, die an einen Wirtschaftsinformatiker gestellt werden. Das in Abbildung 1 dargestellte Anforderungsprofil besteht nach Bächle und Kolb [Bächle u. Kolb, 2012, S. 11 f.] aus den Teilbereichen Methoden der Wirtschaftsinformatik, Systementwicklung, Informationstechnik, Betriebswirtschaftslehre, Hilfsdisziplinen sowie Soft Skills. Die Methoden der Wirtschaftsinformatik beinhalten die Modellierung sowie die Analyse von Informationssystemen und können als das Kerngebiet dieser Wissenschaftsdisziplin bezeichnet werden. Im Zuge des Entwurfs und der Realisierung von Informationssystemen werden die Prinzipien, Methoden, Techniken und Werkzeuge der Systementwicklung eingesetzt. Die Informationstechnik stellt die Grundlage für die Einführung und den Betrieb von - 4 -

12 Anwendungssystemen dar, indem sie die notwendige Infrastruktur bereitstellt. Da betriebliche Informationssysteme zur Unterstützung von Geschäftsprozessen entworfen werden, sind fundierte Grundkenntnisse der Betriebswirtschaftslehre für einen Wirtschaftsinformatiker unabdingbar, um ein Verständnis für die relevanten betrieblichen Prozesse sowie den organisatorischen Kontext zu schaffen. Weiterhin sind die Mathematik, die Rechtswissenschaften sowie Sprachen für die Bewältigung der Aufgaben eines Wirtschaftsinformatikers notwendig; diese Bestandteile des Anforderungsprofils werden aus Sicht der Wirtschaftsinformatik als Hilfsdisziplinen betrachtet. Zuletzt ist darauf hinzuweisen, dass Soft Skills wie Kommunikations- und Teamfähigkeit sowie Mitarbeiterführung zu den Anforderungen gehören, die an einen Wirtschaftsinformatiker gestellt werden. Methoden der WI IT BWL Systementwicklung Hilfsdisziplinen Soft Skills Prinzipien Methoden Techniken Werkzeuge Mathematik Recht Sprachen Modellierung von IS Systemanalyse Rechnerarchitekturen Infrastruktur Projektmanagement Geschäftsprozesse Organisation Teamfähigkeit Kommunikation Mitarbeiterführung Abbildung 1: Anforderungsprofil des Wirtschaftsinformatikers. Quelle: Eigene Darstellung auf Grundlage von [Bächle u. Kolb, 2012, S. 11 f.] Im Rahmen der vorliegenden Arbeit wird ein Referenzmodell für Software-Testwerkzeuge entwickelt, wobei mit der Modellierung und der Analyse von Systemen zentrale Methoden der Wirtschaftsinformatik angewendet werden. Um die Grundlage für das Referenzmodell zu legen, werden die relevanten Methoden und Werkzeuge der Software-Qualitätssicherung erläutert, wodurch dieser Teil der Arbeit zum Gebiet der Systementwicklung zu zählen ist. Somit wird die vorliegende Arbeit in die Bereiche Methoden der Wirtschaftsinformatik sowie Systementwicklung eingeordnet

13 2 Testmethoden 2.1 Überblick Software-Qualitätssicherung und Software-Test Nach Frühauf u. a. [Frühauf u. a., 1995, S. 19 f.] stellt das Testen von Software eine wichtige Maßnahme der analytischen Software-Qualitätssicherung dar. Die weiteren Felder der Software-Qualitätssicherung decken organisatorische und konstruktive Maßnahmen ab. Die organisatorische Qualitätssicherung zielt auf die Verankerung der Qualitätssicherung in der Unternehmensorganisation sowie auf die systematische Prüfung und Verbesserung der Entwicklungsprozesse ab. Konstruktive Maßnahmen setzen vor und während der Software- Entwicklung an, indem sie Normen und Standards festlegen sowie die im Vorfeld der Programmierung entstandenen Entwicklungsdokumente prüfen [Schneider, 2007, S. 173]. Abbildung 2 stellt die genannten Felder der Software-Qualitätssicherung grafisch dar. Software- Qualitätssicherung Organisatorische Maßnahmen Konstruktive Maßnahmen Analytische Maßnahmen Abbildung 2: Klassifikation der Maßnahmen der Software-Qualitätssicherung. Quelle: Eigene Darstellung in Anlehnung an [Frühauf u. a., 1995, S. 20] Klassifizierung der Testmethoden Eine Methode stellt eine planmäßig angewandte, begründete Vorgehensweise zur Erreichung von festgelegten Zielen dar [Balzert, 2009, S. 596]. Demnach wird unter dem Begriff der Testmethode eine systematische Vorgehensweise zur Prüfung eines Software-Systems verstanden

14 Die Testmethoden der Software-Qualitätssicherung lassen sich grundlegend in statische und dynamische Methoden einteilen [Liggesmeyer, 2009, S. 37 f.]. Bei der Anwendung statischer Methoden wird das zu testende Programm nicht ausgeführt stattdessen wird sein Quellcode überprüft. Zu den statischen Methoden zählen die Software-Verifikation sowie die Verfahren der statischen Code-Analyse. Im Gegensatz dazu erfordern dynamische Methoden die Ausführung des zu testenden Programms somit wird hierbei das Laufzeitverhalten geprüft. Allen dynamischen Verfahren ist gemein, dass sie das Laufzeitverhalten des zu testenden Programms mit im Vorfeld definierten Soll-Ergebnissen vergleichen. Wird hierbei eine Abweichung festgestellt, so ist zu prüfen, ob es sich um einen Programmierfehler handelt, oder ob die Abweichung in fehlerhaften Soll-Werten beziehungsweise in einer fehlerhaften Ausführung des Programms begründet ist. Die dynamischen Testmethoden können in strukturorientierte und funktionsorientierte Methoden weiter aufgeteilt werden. Im Zuge der Anwendung strukturorientierter Methoden wird der Aufbau des Quellcodes analysiert; da hierbei der Quellcode einsehbar sein muss, wird bei diesem Vorgehen auch von White-Box- oder Glass-Box-Tests gesprochen [Schneider, 2007, S. 91]. Auf Grundlage der Analyse des Quellcodes können Testfälle systematisch aufgebaut werden, sodass sie alle relevanten Ablaufpfade durch den Quellcode abdecken. Je nach Art ihrer Analyse des Quellcodes werden die strukturorientierten Methoden in kontrollfluss- und datenflussorientierte Verfahren weiter unterteilt; die Abschnitte und enthalten nähere Informationen zu diesen Testmethoden. Im Gegensatz zu strukturorientierten Verfahren betrachten funktionsorientierte Methoden nicht den Quellcode des zu testenden Programms, sondern prüfen seine Funktionalität aus Sicht des Benutzers. Da die interne Struktur des Programms hierbei keine Rolle spielt, wird die Anwendung dieser Verfahren auch als Black-Box-Test bezeichnet. Die Testfälle werden dabei auf Grundlage der Dokumentation des Programms, also beispielsweise den Anforderungen oder der Spezifikation, definiert. Im Rahmen der Testdurchführung wird das Laufzeitverhalten des Programms gegen das in der Dokumentation definierte Soll-Verhalten geprüft. [Spillner u. Linz, 2012, S. 72 f.] Abbildung 3 stellt das Ergebnis der oben vorgenommenen Klassifizierung der verschiedenen Testmethoden grafisch dar

15 Test- Methoden Statisch Dynamisch Analysierend Verifizierend Funktionsorientiert Strukturorientiert Abbildung 3: Klassifikationsschema für Testmethoden. Quelle: Eigene Darstellung in Anlehnung an [Liggesmeyer, 2009, S. 38] Einsatz der Testmethoden im Software-Lebenszyklus Software-Tests werden in verschiedenen Phasen der Entwicklung eines Software-Systems durchgeführt. Die Testphasen unterscheiden sich hinsichtlich des Testgegenstands sowie der durchführenden Partei. In Abhängigkeit der Anforderungen der jeweiligen Testphase variieren die Testmethoden, welche dabei schwerpunktmäßig zum Einsatz kommen. Alper [Alper, 1994, S. 101 ff.] definiert folgende Testphasen, welche in aufsteigender Reihenfolge ihres Einsatzes im Software-Entwicklungsprozess aufgelistet werden: Modultest, Integrationstest, Funktionstest und Anwendertest. Abbildung 4 auf Seite 9 stellt die genannten Testphasen grafisch dar. Der Modultest (Synonyme sind Unit- und Komponententest) prüft einzelne Bestandteile des Gesamtsystems. Hierbei kommen schwerpunktmäßig strukturorientierte Verfahren sowie die Techniken der statischen Code-Analyse zum Einsatz. Da hierfür Entwicklerwissen notwendig ist, wird dieser Test entweder mit Unterstützung der Entwicklung oder von der Entwicklung selbst durchgeführt. Im Zuge des Integrationstests wird das Zusammenspiel der einzelnen Module des Systems geprüft. Je nachdem, welche Integrationsstrategie hierbei zum Einsatz kommt, sind Testtreiber und Platzhalter notwendig, um das noch unvollständige System mit dynamischen Methoden testen zu können. Da noch kein lauffähiges Gesamtsystem vorliegt, fällt auch in dieser Phase der Schwerpunkt auf strukturorientierte Testmethoden. Im nachfolgenden Funktionstest wird das nun zusammengefügte Gesamtsystem erstmals aus Perspektive des Benutzers geprüft. Dieser Test wird funktionsorientiert durchgeführt und dient dazu, Abweichungen der Funktionalität gegenüber den Anforderungen beziehungsweise der Spezifikation aufzudecken. Anzumerken ist, dass der Funktionstest in der Literatur - 8 -

16 Anwender- Test verwendet Anforderungen (kundenseitig) System- Test verwendet Anforderungen Funktions- Test verwendet Spezifikation Integrations- Test verwendet System- Entwurf Modul- Test verwendet Modul- Entwurf Abbildung 4: Testphasen der Systementwicklung. Quelle: Eigene Darstellung in Anlehnung an [Alper, 1994, S. 101]. teilweise im nachfolgenden Systemtest enthalten ist und somit keine eigenständige Testphase darstellt [Spillner u. Linz, 2012, S. 43]. Der Systemtest ähnelt dem Funktionstest, erweitert diesen jedoch um nicht-funktionale Aspekte der Software-Qualität wie Benutzbarkeit, Effizienz und Übertragbarkeit. Zuletzt wird nach der Übergabe des Systems an den Kunden der Anwendertest (Synonym: Abnahmetest) durchgeführt. Dieser ähnelt dem Systemtest, wird jedoch nicht vom Hersteller, sondern vom Kunden durchgeführt. Hierbei werden zum einen Fehler aufgedeckt, die auf Besonderheiten der kundenseitigen Systemumgebung zurückzuführen sind. Zum anderen fördert der Test Anforderungen zutage, die nicht eindeutig zwischen Anwender- und Herstellerseite kommuniziert wurden Begriffsdefinitionen In diesem Abschnitt werden elementare Begriffe des Software-Testens definiert. Dies legt die Grundlage für die Erläuterung von Testmethoden in den nachfolgenden Abschnitten. Als Referenz wird hierbei Spillner und Linz [Spillner u. Linz, 2012, S. 8 ff.] herangezogen

17 Im Rahmen der Testdurchführung wird ein Testobjekt überprüft. Das Testobjekt ist mit dem zu testenden Programm gleichzusetzen und kann in der Praxis eine Methode, eine Funktion, eine Komponente oder das Software-System als Ganzes darstellen. In anderen Literaturquellen wird der Begriff des Prüflings synonym verwendet. Aus einer Testdurchführung kann eine Reihe von Fehlerwirkungen resultieren, die aufgrund der im Testobjekt vorhandenen Fehlerzustände offensichtlich geworden sind. Die Testdurchführung wird bei Anwendung dynamischer Verfahren in Testfälle unterteilt. Die Definition von Testfällen erfolgt auf Grundlage der Testbasis; diese umfasst alle hierfür geeigneten Dokumente über das Testobjekt, wozu beispielsweise Anforderungsdefinition, Spezifikation und technischer Entwurf zählen. Ein Testfall umfasst Eingabewerte, mit denen das Testobjekt aufgerufen wird, sowie Soll- Werte, mit denen die Rückgabewerte des Testobjekts verglichen werden. Weiterhin kann ein Testfall Vor- und Nachbedingungen beinhalten. Die für die Durchführung eines Testfalls verwendeten Daten werden als Testdaten bezeichnet. 2.2 Funktionsorientierte Methoden Grundlagen Im Zuge der Anwendung funktionsorientierter Testmethoden werden Testfälle aus der Testbasis abgeleitet. Als Grundlage für die Testfall-Definitionen dienen somit Anforderungsdefinitionen, Spezifikationen, Benutzerhandbücher und sonstige Dokumente, die Informationen über die Funktionalität und das Soll-Verhalten des Testobjekts beinhalten. Aus diesem Grund werden diese Testmethoden auch als spezifikations- oder anforderungsorientierte Verfahren bezeichnet. Da die innere Beschaffenheit des Testobjekts bei der Anwendung der Verfahren keine Rolle spielt, handelt es sich um Black-Box-Tests. Die Testüberdeckung wird nach dieser Herangehensweise als vollständig betrachtet, wenn alle spezifizierten Funktionen des zu testenden Software-Systems durch Testfälle überprüft werden. [Bath u. McKay, 2011, S. 31 f.] Die verschiedenen funktionsorientierten Testmethoden können hinsichtlich der Testphase, in der sie verwendet werden, unterschieden werden; die verschiedenen Testphasen wurden in Abschnitt erläutert. Auf Ebene des Modul- und Integrationstests geht es darum, aus der Gesamtmenge der möglichen Eingabewerte des Testobjekts eine sinnvolle Stichprobe auszuwählen, welche anschließend für die Testfall-Definition verwendet wird. Diese Auswahl ist notwendig, da es bei nicht-trivialen Programmen mit akzeptablem Aufwand unmöglich ist, für jede mögliche Kombination von Eingabewerten einen separaten Testfall zu erstellen und durchzuführen

18 Verbreitete Verfahren, welche zur sinnvollen Auswahl von Eingabewerten verwendet werden können, sind Äquivalenzklassenbildung, Grenzwertanalyse sowie der zustandsbasierte Test. Im Rahmen des System- und Abnahmetests werden funktionsorientierte Testmethoden eingesetzt, um die zu testenden Arbeitsabläufe beziehungsweise Anwendungsszenarien sinnvoll auszuwählen. Hierfür stellen der anwendungsbasierte, der entscheidungstabellenbasierte sowie der paarweise Test verbreitete Verfahren dar. [Hoffmann, 2008, S. 186 f.] Tabelle 1 enthält eine zusammenfassende Übersicht über verbreitete funktionsorientierte Testmethoden unter Angabe der Testphasen, für die das jeweilige Verfahren geeignet ist. Testmethode Äquivalenzklassenbildung Grenzwertanalyse Zustandsbasierter Test Anwendungsbasierter Test Entscheidungstabellenbasierter Test Paarweiser Test Testphasen Modul- und Integrationstest Modul- und Integrationstest Modul- und Integrationstest System- und Abnahmetest System- und Abnahmetest System- und Abnahmetest Tabelle 1: Verbreitete funktionsorientierte Testmethoden. Quelle: [Hoffmann, 2008, S. 175 ff.] In den nachfolgenden Abschnitten werden verbreitete Verfahren zur Auswahl von Eingabewerten als Vorbereitung für die Durchführung von Modul- und Integrationstests erläutert. Auf Testmethoden, die auf abstrakteren Testebenen eingesetzt werden, wird nicht näher eingegangen, da ihre Implementierung in Testwerkzeugen als zu aufwändig erscheint Äquivalenzklassenbildung Durch die Bildung und Anwendung von Äquivalenzklassen wird die Gesamtmenge der möglichen Werte eines Eingabeparameters in Klassen aufgeteilt. Dies erfolgt dergestalt, dass das Laufzeitverhalten des Testobjekts für jeden Einzelwert einer Klasse äquivalent, also gleich, ist. Da es sich bei der Äquivalenzklassenbildung um eine Black-Box-Technik handelt, kann allerdings nicht nachgeprüft, sondern lediglich vermutet werden, dass alle Werte einer Klasse zum selben Ablaufpfad im Kontrollfluss des Programms führen. Bei begründeter Annahme der Äquivalenz der Werte einer Klasse wird die Anzahl der Testfälle, die für eine vollständige Testabdeckung notwendig ist, drastisch reduziert. Anstatt jeden möglichen Wert jedes Eingabeparameters des Testobjekts bei der Testdurchführung zu verwenden, reicht es aus, das Programm mit einem beliebigen Wert aus jeder Äquivalenzklasse exemplarisch auszuführen und seine Reaktion zu überprüfen. [Schneider, 2007, S. 94 f.]

19 Als Beispiel soll ein Eingabeparameter mit einem zulässigen Wertebereich von Ganzzahlen zwischen 1 und 99 dienen. In diesem einfachen Fall können alle gültigen Werte zu einer Äquivalenzklasse zusammengefasst werden: {1 x 99}. Um die Reaktion des Programms auf ungültige Eingabewerte zu überprüfen, werden darüber hinaus zwei Klassen mit Mengen ungültiger Werte definiert: {x 0} und {x 100}. Auf dieser Grundlage werden drei Testfälle definiert, sodass ein Wert aus jeder Äquivalenzklasse bei der Testdurchführung verwendet wird; eine vollständige Testabdeckung wäre demnach bei Verwendung der Werte -10, 50 und 200 gegeben Grenzwertanalyse Die Grenzwertanalyse basiert auf der Annahme, dass die Verarbeitung von Werten, die an den Übergängen von Äquivalenzklassen angesiedelt sind, besonders fehlerträchtig ist. Diese Heuristik beeinflusst die Auswahl der Werte aus den Äquivalenzklassen, mit welchen der relevante Eingabeparamter des Testobjekts bei der Testdurchführung versorgt wird. [Henry, 2008, S. 60 f.] Um die Wahrscheinlichkeit, beim Test Fehlerzustände aufzudecken, zu maximieren, werden zum einen alle Werte ausgewählt, die auf dem Übergang zwischen zwei Äquivalenzklassen liegen. Zum anderen werden für jeden Übergang die Werte der beiden Klassen mit den geringsten Abständen zu dem Übergang für die Testfall-Definition herangezogen. Darüber hinaus gibt es stets zwei Äquivalenzklassen, die auf einer Seite nicht an eine andere Klasse grenzen. Aus diesen Klassen wird der Minimal- beziehungsweise Maximalwert verwendet. [Spillner u. Linz, 2012, S. 125] Die Grenzwertanalyse soll auf das im vorangegangenen Abschnitt eingeführte Beispiel angewendet werden. Zunächst werden die Äquivalenzklassen in aufsteigender Reihenfolge aufgelistet: {x 0}, {1 x 99}, {x 100}. Aus den beiden Übergängen zwischen den Äquivalenzklassen werden folgende Grenzwerte abgeleitet: 0, 1, 99 und 100. Da die beiden Randklassen einen offenen Wertebereich besitzen, können theoretisch gesehen keine Minimal- und Maximalwerte abgeleitet werden. In der Praxis besteht jedoch die Möglichkeit, in Abhängigkeit der eingesetzten Programmiersprache den Minimal- beziehungsweise Maximalwert des für den jeweiligen Parameter benutzten Datentyps zu verwenden. Anzumerken ist, dass bei der Auswahl der Werte aus den Äquivalenzklassen Variationen zulässig sind. So ist es denkbar, neben dem Wert mit dem geringsten Abstand zu einem Übergang auch den zweitnächsten Wert zu verwenden. Weiterhin ist eine Ergänzung der Grenzwerte mit aus den Äquivalenzklassen zufällig ausgewählten Werten vorstellbar

20 2.2.4 Zustandsbasierter Test Der zustandsbasierte Test wird eingesetzt, wenn das Testobjekt verschiedene Zustände annehmen kann und somit zustands- oder gedächtnisbehaftet ist. Der Zustand des Testobjekts wechselt, nachdem bestimmte Ereignisse ausgelöst wurden; dieser Wechsel wird als Zustandsübergang bezeichnet und kann mit Aktionen verbunden sein, die im Anschluss an den Zustandsübergang durch das Testobjekt ausgeführt werden. [Liggesmeyer, 2009, S. 58 f.] Der zustandsbasierte Test prüft, ob das Testobjekt die Zustandsübergänge und die damit verbundenen Aktionen gemäß seiner Spezifikation durchführt. Weiterhin wird die Robustheit des Testobjekts geprüft, indem ungültige Zustände beziehungsweise ungültige Zustandsübergänge simuliert und irrelevante Ereignisse ausgelöst werden. Die Beschreibung der gültigen Zustände, Übergänge, Ereignisse und Aktionen erfolgt mit Hilfe von Zustandsdiagrammen, Zustandsübergangstabellen und Zustandsübergangsbäumen. Hierbei findet beispielsweise das Zustandsdiagramm der UML (Unified Modeling Language) Verwendung. Auf Basis dieser Beschreibung werden Testfälle erzeugt, welche jeweils einen definierten Anfangszustand, die zur Stimulation des Testobjekts durchzuführenden Aktionen, dessen erwartete Reaktionen sowie den erwarteten Endzustand beinhalten. [Spillner u. Linz, 2012, S. 139] Bezüglich der Testabdeckung existieren verschieden strenge Kriterien, die sich jeweils subsumieren und nachfolgend in aufsteigender Reihenfolge aufgezählt werden [Liggesmeyer, 2009, S. 60 f.]: Im Zuge der Testdurchführung werden alle spezifizierten Zustände erreicht. Alle gültigen Zustandsübergänge werden vollzogen. Alle Ereignisse, die zu Zustandsübergängen führen können, werden ausgelöst. Darüber hinaus kann die Anforderung bestehen, zusätzlich alle ungültigen Zustandsübergänge zu testen. Der zustandsbasierte Test ist vor allem bei objektorientierten Systemen einzusetzen; dort sind die Testobjekte häufig zustandsbehaftet und das Verhalten des Systems wird maßgeblich vom aktuellen Zustand beeinflusst. [Spillner u. Linz, 2012, S. 140]

21 2.3 Strukturorientierte Methoden Grundlagen Strukturorientierte Testmethoden stellen neben den in Abschnitt 2.2 beschriebenen funktionsorientierten Methoden weitere Verfahren zur systematischen Konstruktion von Testfällen bereit. Das charakteristische Merkmal dieser Methoden ist, dass im Zuge ihrer Anwendung die innere Struktur des Testobjekts analysiert wird. Dies setzt voraus, dass der Quellcode des zu prüfenden Programms einsehbar ist und bei Bedarf für die Testdurchführung instrumentiert werden kann. Aus diesem Grund erfordern strukturorientierte Testmethoden technisches Wissen und werden in der Regel mit Unterstützung der zuständigen Entwickler im Rahmen von Modul- und Integrationstests eingesetzt. [Henry, 2008, S. 59] Der wesentliche Vorteil der strukturorientierten gegenüber den funktionsorientierten Verfahren besteht darin, dass die Testüberdeckung anhand des Quellcodes objektiv gemessen und somit gewährleistet werden kann. 3 Im Zuge der Anwendung von White-Box-Verfahren kann sichergestellt werden, dass alle Zeilen des Programmcodes im Rahmen der Testdurchführung durchlaufen werden. Die Ausführung der Programmzeilen resultiert in einem beobachtbaren Verhalten des Testobjekts, welches gegen das im Vorfeld festgelegte Soll-Verhalten geprüft wird. Hinsichtlich der Testdurchführung gibt es somit keinen Unterschied zwischen White- und Black-Box-Techniken. Durch die Analyse der inneren Struktur des Testobjekts kann weiterhin vermieden werden, für einen Codepfad mehrere, redundante Testfälle zu definieren dadurch wird die Effizienz des Testens erhöht. [Cleff, 2010, S. 149 f.] Analyse der Kontrollstruktur Die Analyse der inneren Struktur des Testobjekts dient zum einen als Grundlage für die Definition von Testfällen. Zum anderen ermöglicht sie die Messung der durch die Testfälle erreichten Testüberdeckung. In den Zielen des Software-Tests kann der Testabdeckungsgrad festgelegt werden, der mindestens erreicht werden soll. Zur Spezifizierung des Abdeckungsgrads stehen verschiedene Kriterien zur Verfügung, die in den nachfolgenden Abschnitten vorgestellt werden. Die Kontrollstruktur eines Programms besteht aus Anweisungen und Verzweigungen. Ein Kontrollflussgraph ermöglicht die grafische Darstellung der Konstrollstruktur, indem er Anweisungen und Verzweigungen durch gerichtete Kanten miteinander verbindet. Weiterhin besitzt der Kontrollflussgraph genau einen Start- und einen Endknoten. Bei Ausführung des 3 Nach Schneider [Schneider, 2007, S. 104] werden Anforderungen durch Testfälle abgedeckt, Codezeilen jedoch überdeckt; dieser sprachlichen Differenzierung wird in der vorliegenden Arbeit gefolgt

22 Programms wird der Graph auf einem Pfad ausgehend von seinem Startknoten durchschritten, bis sein Endknoten erreicht ist. [Liggesmeyer, 2009, S. 84] Ein Kontrollflussgraph wird in Abbildung 5 beispielhaft dargestellt. Um die Orientierung zu erleichtern, werden die verschiedenen Strukturelemente durch unterschiedliche geometrische Formen visualisiert. Start Anweisung 1 Verzweigung 1 Anweisung 2 Anweisung 3 Anweisung 4 Ende Abbildung 5: Abstrakte Darstellung eines Kontrollflussgraphen. Quelle: Eigene Darstellung in Anlehnung an [Wirsing, 2003, S. 21]

23 2.3.3 Kontrollflussorientierte Methoden Kontrollflussorientierte Testmethoden verfolgen den Ansatz, dass möglichst viele der Codepfade des Testobjekts im Rahmen der Testdurchführung zur Ausführung gebracht werden sollen. Je mehr dieser Pfade durch die Testfälle überdeckt werden, desto mehr der im Quellcode verborgenen Fehlerzustände werden während der Testdurchführung zur Wirkung gebracht. [Hoffmann, 2008, S. 201] Werden sämtliche Pfade durchlaufen, so werden garantiert alle Fehlerzustände ausgelöst und können durch Soll-Ist-Vergleiche im Rahmen der Testdurchführung aufgedeckt werden. In diesem Idealfall liegt das Kriterium der Pfadüberdeckung vor. Allerdings ist die Ausführung aller Code-Pfade bei nicht-trivialen Programmen unter akzeptablem Aufwand nicht möglich: Im Quellcode enthaltene Schleifen führen zu einer exorbitanten Anzahl möglicher Pfade. [Hoffmann, 2008, S. 210 f.] Aus diesem Grund existieren verschiedene andere Überdeckungskriterien, die weniger strenge Anforderungen stellen als die Pfadüberdeckung. Als Minimalkriterium sollte die Anweisungsüberdeckung eingehalten werden. Diese fordert die Ausführung aller im Programmcode vorhandenen Anweisungen im Rahmen der Testdurchführung. Lässt sich dieses Kriterium nicht erfüllen, so enthält das Testobjekt toten Code, der in keinem Pfad erreicht wird. Die Aufdeckung unerreichbarer Codezeilen ist eines der Ziele, die bei der Anwendung von kontrollflussorientierten Verfahren verfolgt werden. [Spillner u. Linz, 2012, S. 151] Innerhalb der Spanne zwischen Anweisungs- und Pfadüberdeckung existieren weitere Überdeckungskriterien, die als Anforderung bei der Definition von Testzielen verwendet werden können. Auf eine Erläuterung aller kontrollflussorientierten Testmethoden muss mit Hinweis auf den begrenzten Umfang der vorliegenden Arbeit verzichtet werden. Jedoch gibt Tabelle 2 eine Übersicht über die verbreiteten Überdeckungskriterien. 4 Kürzel Überdeckungskriterium Beschreibung C 0 Anweisungsüberdeckung Test aller Anweisungen. C 1 Zweigüberdeckung Test aller Anweisungen und aller Bedingungen. C 2 Pfadüberdeckung Test aller Pfade. C 3 Bedingungsüberdeckung Test der Teilbedingungen (verschiedene Varianten). - McCabe-Überdeckung Test aller Elementarpfade. Tabelle 2: Kontrollflussorientierte Testmethoden. Quelle: [Hoffmann, 2008, S. 206 ff.] 4 Für die grundlegenden Überdeckungskriterien ist die Verwendung eines Kürzels der Form Cx gebräuchlich; das C steht hierbei für Coverage, zu deutsch Überdeckung

24 2.3.4 Datenflussorientierte Methoden Datenflussorientierte Testmethoden messen die Testüberdeckung anhand des Datenflusses, welcher im Rahmen der Testdurchführung innerhalb des Testobjekts vollzogen wird. Bei der Ausführung des zu testenden Programms entsteht ein Datenfluss, wenn schreibend oder lesend auf Variablen zugegriffen wird. Der Datenfluss kann mit Hilfe datenflussattributierter Kontrollflussgraphen visualisiert werden. Bei dieser Variation des in Abschnitt beschriebenen Kontrollflussgraphen werden die schreibenden und lesenden Variablenzugriffe neben den entsprechenden Anweisungsknoten angegeben. [Liggesmeyer, 2009, S. 142 f.] Im Zuge der Analyse des Datenflusses wird grundsätzlich zwischen schreibender (definitorischer) und lesender (referenzierender) Nutzung der jeweiligen Variablen unterschieden. Hinsichtlich der referenzierenden Verwendung wird weiter differenziert, ob die Variable für eine Berechnung herangezogen wird (kalkulatorische Nutzung) oder in die Prüfung einer Bedingung involviert ist (prädikative Nutzung) [Hoffmann, 2008, S. 220 f.]. Die verschiedenen Ausprägungen des Datenflusses werden in Abbildung 6 grafisch dargestellt. Abbildung 6: Ausprägungen des Datenflusses. Quelle: Eigene Darstellung. Auf Grundlage der Analyse des Datenflusses kann die Einhaltung verschiedener Überdeckungskriterien geprüft werden. Die Kriterien zielen darauf ab, dass nach einem definitorischen Variablenzugriff ein referenzierender Zugriff erfolgen muss. Ist dies nicht der Fall, so liegt eine Anomalie im Datenfluss des Programms vor. Eine vollständige Überdeckung des Datenflusses liegt vor, wenn im Rahmen der Testdurchführung für jeden definitorischen Variablenzugriff alle nachfolgenden referenzierenden Verwendungen der Variable durchlaufen

25 und somit getestet werden [Hoffmann, 2008, S. 226]. Falls die Realisierung der vollständigen Überdeckung zu aufwändig ist, kann alternativ ein schwächeres Kriterium gewählt werden. Tabelle 3 gibt einen Überblick über die verbreiteten datenflussorientierten Überdeckungskriterien. Kriterium all-defs all-c-uses all-p-uses all-c-/some-p-uses all-p-/some-c-uses all-uses Required k-tupel Beschreibung Minimaltest: Jeder definitorische Zugriff wird von einem beliebigen referenzierenden Zugriff gefolgt. Test aller kalkulatorischen Variablenzugriffe. Test aller prädikativen Variablenzugriffe. Test der referenzierenden Zugriffe mit Priorisierung der kalkulatorischen Verwendung. Test der referenzierenden Zugriffe mit Priorisierung der prädikativen Verwendung. Maximaltest: Test aller referenzierenden Variablenzugriffe. Test aller Sequenzen von definitorischen-referenzierenden-zugriffen mit Länge k. Tabelle 3: Datenflussorientierte Testmethoden. Quelle: [Liggesmeyer, 2009, S. 144 ff.] Bewertung Strukturorientierte Testmethoden ermöglichen einerseits die systematische Konstruktion von Testfällen auf Grundlage der Programmstruktur des Testobjekts, wodurch eine hohe Testüberdeckung bei geringer Redundanz erreicht wird. Andererseits können die Verfahren zur objektiven Ermittlung der Testüberdeckung eingesetzt werden. Dies rechtfertigt den Einsatz strukturorientierter Methoden auch dann, wenn die Testfall-Definition mittels funktionsorientierter Verfahren erfolgt. [Spillner u. Linz, 2012, S. 164] Bei Anwendung strukturorientierter Verfahren ist zu beachten, dass sich die dabei gemessene Code-Überdeckung durch Testfälle stets auf den aktuellen Programmcode des Testobjekts bezieht. Demnach reduzieren nicht realisierte Funktionen die Test-Überdeckung nicht und können durch White-Box-Verfahren folglich auch nicht aufgedeckt werden. Hierfür sind ergänzende Black-Box-Tests notwendig, welche die Funktionalität des Testobjekts gegen seine Anforderungsdefinition abgleichen. [Schneider, 2007, S. 107] Weiterhin ist anzumerken, dass datenflussorientierte Methoden beim Test objektorientierter Software-Systeme den kontrollflussorientierten Vorfahren vorzuziehen sind, da sie unter dieser Voraussetzung einen höheren Prozentsatz der im Testobjekt enthaltenen Fehlerzustände aufdecken. [Liggesmeyer, 2009, S. 141]

26 Zuletzt soll darauf hingewiesen werden, dass die Messung der Testüberdeckung die Instrumentierung des Testobjekts erfordert. Hierbei wird der Quellcode des zu testenden Programms im Vorfeld eines Testlaufs durch Kontrollanweisungen ergänzt, sodass die Ausführung der für die Testüberdeckung relevanten Codezeilen protokolliert werden kann. [Spillner u. Linz, 2012, S. 164 f.] 2.4 Statische Prüfungen Grundlagen In den nachfolgenden Abschnitten werden verschiedene Testmethoden vorgestellt, welche den Quellcode des Testobjekts auf Fehler und Unstimmigkeiten prüfen. Die Prüfverfahren werden als statisch bezeichnet, da das zu testende Programm dabei nicht ausgeführt wird. Die statischen Ansätze des Software-Testens besitzen verschiedene Vorteile gegenüber den dynamischen Testmethoden. Zum einen können statische Prüfungen sehr früh im Entwicklungsprozess eingesetzt werden, da ein lauffähiges System keine zwingende Voraussetzung für die Testdurchführung darstellt. Folglich kann auch auf Testtreiber und Platzhalter verzichtet werden, die für die Durchführung von dynamischen Modul- und Integrationstests in der Regel notwendig sind. Zum anderen werden für die Durchführung statischer Tests weder Testfälle noch Testdaten benötigt, wodurch der Aufwand für die Vorbereitung der Testdurchführung gering gehalten werden kann. [Simon u. a., 2006, S. 107] In der vorliegenden Arbeit wird zwischen manueller und automatisierter Prüfung des Quellcodes des Testobjekts unterschieden. Das Review stellt eine verbreitete manuelle Methode des statischen Testens dar und wird in Abschnitt genauer erläutert. Im Gegensatz dazu beschreibt Abschnitt Verfahren der statischen Code-Analyse, die sinnvollerweise nur mit Werkzeugunterstützung ausgeführt werden können. Zu dieser Kategorie zählt auch die Vermessung der Software mit Hilfe von Metriken, welche in Abschnitt behandelt wird. Manuelle und automatisierte Verfahren ergänzen sich, da bei der Durchführung von Reviews Zeit gespart werden kann, indem im Vorfeld Analysewerkzeuge zur Aufdeckung grober Unstimmigkeiten eingesetzt werden [Spillner u. Linz, 2012, S. 99 f.] Manuelle Prüfung Bei der manuell durchgeführten statischen Prüfung handelt es sich in der Regel um eine strukturierte Gruppenprüfung, für die der Begriff des Reviews gebräuchlich ist. Im Rahmen eines Reviews gehen zwei oder mehr Personen den Programmcode durch und suchen nach Fehlern, Umstimmigkeiten und Auffälligkeiten. Diese werden im Protokoll der Reviewsitzung

27 als Befunde festgehalten und im Nachgang durch den zuständigen Entwickler im Quellcode korrigiert. Dieses Verfahren kann nicht nur auf Quellcode angewendet werden, sondern auf beliebige Dokumente, die im Rahmen des Entwicklungsprozesses entstehen. Folglich werden anstelle von Quellcode und Entwickler die allgemeineren Begriffe Dokument beziehungsweise Prüfling sowie Autor verwendet. [Schneider, 2007, S. 141] Es existieren verschiedene Varianten des Reviews, die sich hauptsächlich in der Anzahl der beteiligten Personen sowie hinsichtlich des Formalitätsgrades ihres Ablaufs unterscheiden. Bei einem informellen Review sprechen zwei Entwickler den Quellcode eines Programms durch. Hierfür ist keine Vorbereitung notwendig und die Ergebnisse werden nicht protokolliert. Im Gegensatz dazu handelt es sich bei einer Inspektion um ein formales Review, das mit einer Vorbereitungsphase, einer Reviewsitzung sowie einer Nachbereitungsphase verbunden ist. Die Ergebnisse der Inspektion werden protokolliert und können somit auch dem Management oder anderen Parteien vorgelegt werden. Bei einer Inspektion geht es neben der Prüfung des betrachteten Dokuments auch um die Verbesserung der Entwicklungsprozesse des Unternehmens. [Henry, 2008, S. 67 f.] Tabelle 4 enthält eine Übersicht über die verschiedenen Varianten des Reviews. Review-Art Informelles Review Walkthrough Technisches Review Inspektion Beschreibung Gegenlesen des Dokuments durch einen Kollegen. Besprechung des Dokuments in einer informellen Sitzung. Experten beraten in einer protokollierten Sitzung über das Dokument. Das Dokument wird in einer formalen, moderierten Sitzung geprüft, wobei die beteiligten Personen verschiedene Rollen wie Moderator, Gutachter und Protokollant einnehmen. Tabelle 4: Varianten der manuellen statischen Softwareprüfung. Quelle: [Spillner u. Linz, 2012, S. 92 ff.] Die Planung und Durchführung von Reviews verursacht erhebliche Aufwände und kann nur in geringem Maße durch Werkzeuge unterstützt werden. Die dabei entstehenden Kosten werden durch die Vorteile der strukturierten Gruppenprüfung jedoch mit Leichtigkeit aufgewogen. Nach Henry [Henry, 2008, S. 67] ermöglichen Reviews eine frühe Erkennung und Beseitigung von Fehlern und reduzieren somit die mittel- und langfristigen Wartungsaufwände. Weiterhin wird Wissen über die innere Struktur des zu prüfenden Programms sowie über die Erkennung und Behebung von Fehlern und Unschönheiten im Quellcode auf informellem Wege verbreitet. Dies führt automatisch zu einer Steigerung der Qualität von zukünftig erstellten Dokumenten und kann darüber hinaus zur Verbesserung der Entwicklungsprozesse beitragen