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: Fabian Lorenz Lauer
geboren am 03.05.1983 in Stuttgart Fernstudium Master Wirtschftsinformatik Betreuer: Prof. Dr. Jürgen Cleve
weitere Gutachter: Prof. Dr. Jan Helmke Stuttgart, den 13. Februar 2013
Inhaltsverzeichnis
Abbildungsverzeichnis IV
Tabellenverzeichnis V
Abkürzungsverzeichnis VI
1 Einführung 1
1.1 Definition und Bedeutung von Software-Qualität . . . 1
1.2 Merkmale der Software-Qualität . . . 2
1.3 Ziel und Vorgehen . . . 3
1.4 Abgrenzung der Themen . . . 4
1.5 Einordnung in die Wirtschaftsinformatik . . . 4
2 Testmethoden 6 2.1 Überblick . . . 6
2.1.1 Software-Qualitätssicherung und Software-Test . . . 6
2.1.2 Klassifizierung der Testmethoden . . . 6
2.1.3 Einsatz der Testmethoden im Software-Lebenszyklus . . . 8
2.1.4 Begriffsdefinitionen . . . 9
2.2 Funktionsorientierte Methoden . . . 10
2.2.1 Grundlagen . . . 10
2.2.2 Äquivalenzklassenbildung . . . 11
2.2.3 Grenzwertanalyse . . . 12
2.2.4 Zustandsbasierter Test . . . 13
2.3 Strukturorientierte Methoden . . . 14
2.3.1 Grundlagen . . . 14
2.3.2 Analyse der Kontrollstruktur . . . 14
2.3.3 Kontrollflussorientierte Methoden . . . 16
2.3.4 Datenflussorientierte Methoden . . . 17
2.3.5 Bewertung . . . 18
2.4 Statische Prüfungen . . . 19
2.4.1 Grundlagen . . . 19
2.4.2 Manuelle Prüfung . . . 19
2.4.3 Automatisierte Prüfung . . . 21
2.4.4 Metriken . . . 22
2.4.5 Formale Verifikation . . . 24
3 Testwerkzeuge 25
3.1 Grundlagen . . . 25
3.1.1 Definition . . . 25
3.1.2 Ziele des Einsatzes . . . 26
3.1.3 Möglichkeiten der Klassifizierung . . . 26
3.2 Anwendungsbereiche . . . 27
3.2.1 Testmanagement und -steuerung . . . 27
3.2.2 Generierung von Testdaten und Testfällen . . . 29
3.2.3 Messung und Visualisierung der Testüberdeckung . . . 31
3.2.4 Testausführung . . . 32
3.2.5 Statische Prüfung und Verifikation . . . 34
3.2.6 Nicht funktionaler Test . . . 35
3.3 Einführung . . . 36
3.3.1 Voraussetzungen . . . 36
3.3.2 Werkzeug-Auswahl . . . 37
3.3.3 Einführungsprozess . . . 38
4 Referenzmodell 41 4.1 Grundlagen der Referenzmodellierung . . . 41
4.1.1 Begriffsdefinitionen . . . 41
4.1.2 Arten von Referenzmodellen . . . 41
4.1.3 Qualitätsanforderungen an Referenzmodelle . . . 43
4.1.4 Vorgehen bei der Referenzmodellierung . . . 45
4.2 Referenzmodell für Software-Testwerkzeuge . . . 48
4.2.1 Problemdefinition und Zielsetzung . . . 48
4.2.2 Ordnungsrahmen . . . 49
4.2.3 Struktur . . . 53
4.2.4 Bausteine . . . 57
4.2.5 Komplettierung und Anwendung . . . 65
5 Anwendung des Referenzmodells 67 5.1 Vorgehen . . . 67
5.1.1 Art und Ziel der Anwendung . . . 67
5.1.2 Auswahl und Analyse der Testwerkzeuge . . . 67
5.2 Analyse der Testwerkzeuge . . . 68
5.2.1 SAP Test Workbench . . . 68
5.2.2 SAP eCATT . . . 72
5.2.3 AFI Automatic Test Tool . . . 77
6 Schlussbetrachtung 83
6.1 Zusammenfassung . . . 83 6.2 Ausblick . . . 86
Literaturverzeichnis 88
Ehrenwörtliche Erklärung VII
Abbildungsverzeichnis
1 Anforderungsprofil des Wirtschaftsinformatikers. . . 5
2 Klassifikation der Maßnahmen der Software-Qualitätssicherung. . . 6
3 Klassifikationsschema für Testmethoden. . . 8
4 Testphasen der Systementwicklung. . . 9
5 Abstrakte Darstellung eines Kontrollflussgraphen. . . 15
6 Ausprägungen des Datenflusses. . . 17
7 Taxonomie der automatisierten statischen Software-Prüfung. . . 21
8 Aufgabenbereiche des Testmanagements und der Teststeuerung. . . 29
9 Unterstützung der Testausführung durch Testwerkzeuge. . . 34
10 Beschaffung und Einführung eines Testwerkzeugs als Eisbergmodell. . . 39
11 Vorgehensmodell der Referenzmodellierung. . . 46
12 Referenzmodell für Testwerkzeuge: Ordnungsrahmen. . . 50
13 Referenzmodell für Testwerkzeuge: Übersicht. . . 56
14 Referenzmodell für Testwerkzeuge: BausteinTestmanagement und Teststeue- rung. . . 58
15 Referenzmodell für Testwerkzeuge: BausteinTestausführung. . . 61
16 Referenzmodell für Testwerkzeuge: BausteinStatische Prüfung und Verifikation. 63 17 Anwendungsfall-Diagramm des TestwerkzeugsSAP Test Workbench. . . 69
18 Anwendungsfall-Diagramm des TestwerkzeugsSAP eCATT. . . 73
19 Anwendungsfall-Diagramm des TestwerkzeugsAFI Automatic Test Tool. . . . 78
Tabellenverzeichnis
1 Verbreitete funktionsorientierte Testmethoden. . . 11
2 Kontrollflussorientierte Testmethoden. . . 16
3 Datenflussorientierte Testmethoden. . . 18
4 Varianten der manuellen statischen Softwareprüfung. . . 20
5 Verbreitete Metriken der Software-Qualitätssicherung. . . 23
6 Grundsätze ordnungsmäßiger Modellierung. . . 44
Abkürzungsverzeichnis
ABAP Advanced Business Application Programming AFI P.M. Belz Agentur für Informatik GmbH
AG Aktiengesellschaft
BWL Betriebswirtschaftslehre
CAST Computer Aided Software Testing eCATT extended Computer Aided Test Tool EPK Ereignisgesteuerte Prozesskette ERM Entity-Relationship-Modell
ERP Enterprise Resource Planning
GmbH Gesellschaft mit beschränkter Haftung GoM Grundsätze ordnungsmäßiger Modellierung
GUI Graphical User Interface
IDEF Integrated Definition
IS Informationssystem
IT Informationstechnik
LOC Lines of Code
MBT Modellbasiertes Testen
MTBF Mean Time Between Failures
SA Strukturierte Analyse
UML Unified Modeling Language
WI Wirtschaftsinformatik
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 Merk- mal allein, sondern durch eine Reihe verschiedener Merkmale festgelegt wird. Weiterhin geht aus der Definition hervor, dass Qualität immer im Hinblick auf konkrete Erfordernis- se 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 kontinu- ierlich, was auf zwei Hauptgründe zurückgeführt werden kann. Zum einen findet die Com- putertechnik 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 Miniaturisie- rung 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 abseh- bar. Die beschriebenen Entwicklungen haben das Potenzial, in ein ubiquitäres Computer- zeitalter 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
1ISO-Norm 9126 wurde in ISO-Norm 25000 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.
2In dieser Arbeit werden Quellenangaben immer dann am Absatzende positioniert, wenn sich mehrere Sätze des Absatzes sinngemäß auf die angegebene Quelle beziehen.
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: Funk- tionalitä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 Beziehun- gen 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 übertra- gen 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 derFunktionalität gibt an, in welchem Maße das Software-Produkt den geforderten Funk- tionsumfang 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 derZuverlässigkeit wird geprüft, ob das System in der Lage ist, sein Leistungs- niveau unter bestimmten Bedingungen über einen längeren Zeitraum aufrecht zu erhalten.
Hierbei spielt beispielsweise eine Rolle, ob Fehlerzustände zu Systemsausfällen oder Da- tenverlusten 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 derEffizienz 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 Erweite- rungen notwendig ist. DieÜbertragbarkeit gibt Aufschluss darüber, wie einfach das System für eine andere Umgebung angepasst und dort installiert werden kann. Systemumgebun- gen 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ätsmerk- male um Transparenz und Testbarkeit. Die Transparenz gibt an, ob die Funktionen des Software-Systems sorgfältig und strukturiert realisiert wurden. Hierbei sind die durchgän- gige Anwendung einer Software-Architektur sowie die Einhaltung von Programmierrichtlini- en 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
Aspekt beim Entwurf des Systems berücksichtigt, wodurch beispielsweise der Einsatz auto- matischer 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 beschrie- ben. 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 Vorberei- tungen 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 wer- den können und welche Anforderungen hierbei berücksichtigt werden sollten, um eine effi- ziente 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 Test- werkzeugs systematisch und effizient durchgeführt werden. Zum anderen kann das Re- ferenzmodell 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 verschie- dene 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.
1.4 Abgrenzung der Themen
Als Vorbereitung für die Entwicklung des Referenzmodells werden die in der einschlägi- gen Literatur verbreiteten Methoden der Software-Qualitätssicherung erläutert. Dabei wird das Ziel verfolgt, einen Überblick über die verschiedenen Verfahren zu geben, die in Test- werkzeugen 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 Ar- beit 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 verschiede- ner 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 Referenz- modells muss aufgrund des beschränkten Umfangs der vorliegenden Arbeit verzichtet wer- den.
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 Aufgabenstel- lungen dient und von Menschen gestaltet und genutzt wird. Weiterhin ist das Informations- system 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 TeilbereichenMethoden der Wirtschaftsinformatik,Systementwick- lung,Informationstechnik,Betriebswirtschaftslehre,HilfsdisziplinensowieSoft Skills.
DieMethoden der Wirtschaftsinformatik beinhalten die Modellierung sowie die Analyse von Informationssystemen und können als das Kerngebiet dieser Wissenschaftsdisziplin be- zeichnet werden. Im Zuge des Entwurfs und der Realisierung von Informationssystemen werden die Prinzipien, Methoden, Techniken und Werkzeuge derSystementwicklungeinge- setzt. DieInformationstechnik stellt die Grundlage für die Einführung und den Betrieb von
Anwendungssystemen dar, indem sie die notwendige Infrastruktur bereitstellt. Da betrieb- liche Informationssysteme zur Unterstützung von Geschäftsprozessen entworfen werden, sind fundierte Grundkenntnisse derBetriebswirtschaftslehrefür einen Wirtschaftsinformati- ker unabdingbar, um ein Verständnis für die relevanten betrieblichen Prozesse sowie den organisatorischen Kontext zu schaffen. Weiterhin sind die Mathematik, die Rechtswissen- schaften sowie Sprachen für die Bewältigung der Aufgaben eines Wirtschaftsinformatikers notwendig; diese Bestandteile des Anforderungsprofils werden aus Sicht der Wirtschaftsin- formatik alsHilfsdisziplinen betrachtet. Zuletzt ist darauf hinzuweisen, dassSoft Skills wie Kommunikations- und Teamfähigkeit sowie Mitarbeiterführung zu den Anforderungen gehö- ren, die an einen Wirtschaftsinformatiker gestellt werden.
System- entwicklung Methoden
der WI IT BWL Hilfs-
disziplinen Soft Skills
Modellierung von IS System- analyse
Prinzipien Methoden Techniken Werkzeuge
Rechner- architekturen Infrastruktur
Projekt- management Geschäfts- prozesse Organisation
Mathematik Recht Sprachen
Team- fähigkeit Kommunika- tion
Mitarbeiter- fü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 zentraleMethoden 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 derSystementwicklung zu zählen ist.
Somit wird die vorliegende Arbeit in die BereicheMethoden der Wirtschaftsinformatik sowie Systementwicklungeingeordnet.
2 Testmethoden
2.1 Überblick
2.1.1 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 wich- tige 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 Ent- wicklungsprozesse ab. Konstruktive Maßnahmen setzen vor und während der Software- Entwicklung an, indem sie Normen und Standards festlegen sowie die im Vorfeld der Pro- grammierung entstandenen Entwicklungsdokumente prüfen [Schneider, 2007, S. 173].
Abbildung 2 stellt die genannten Felder der Software-Qualitätssicherung grafisch dar.
Software- Qualitätssicherung
Konstruktive Maßnahmen Organisatorische
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]
2.1.2 Klassifizierung der Testmethoden
Eine Methode stellt eine „planmäßig angewandte, begründete Vorgehensweise zur Errei- chung 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.
Die Testmethoden der Software-Qualitätssicherung lassen sich grundlegend in statische und dynamische Methoden einteilen [Liggesmeyer, 2009, S. 37 f.]. Bei der Anwendung sta- tischer 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 Metho- den 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 tes- tenden Programms mit im Vorfeld definierten Soll-Ergebnissen vergleichen. Wird hierbei ei- ne 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 Me- thoden weiter aufgeteilt werden.
Im Zuge der Anwendung strukturorientierter Methoden wird der Aufbau des Quellcodes ana- lysiert; 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 Quell- codes werden die strukturorientierten Methoden in kontrollfluss- und datenflussorientierte Verfahren weiter unterteilt; die Abschnitte 2.3.3 und 2.3.4 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 Anforde- rungen oder der Spezifikation, definiert. Im Rahmen der Testdurchführung wird das Laufzeit- verhalten 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.
Test- Methoden
Dynamisch Statisch
Analysierend Funktions-
orientiert
Struktur- orientiert Verifizierend
Abbildung 3: Klassifikationsschema für Testmethoden.
Quelle: Eigene Darstellung in Anlehnung an [Liggesmeyer, 2009, S. 38]
2.1.3 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 Reihenfol- ge ihres Einsatzes im Software-Entwicklungsprozess aufgelistet werden: Modultest, Inte- grationstest, 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 so- wie 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 desIntegrationstestswird das Zusammenspiel der einzelnen Module des Systems geprüft. Je nachdem, welche Integrationsstrategie hierbei zum Einsatz kommt, sind Test- treiber 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 nachfolgendenFunktionstest 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 beziehungswei- se der Spezifikation aufzudecken. Anzumerken ist, dass der Funktionstest in der Literatur
verwendet System-
Test Anwender-
Test
Funktions- Test
Modul- Test Integrations-
Test
Modul- Entwurf Anforderungen
(kundenseitig)
Anforderungen
Spezifikation
System- Entwurf verwendet
verwendet verwendet verwendet
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 Testpha- se darstellt [Spillner u. Linz, 2012, S. 43].
DerSystemtest ähnelt dem Funktionstest, erweitert diesen jedoch um nicht-funktionale As- pekte der Software-Qualität wie Benutzbarkeit, Effizienz und Übertragbarkeit.
Zuletzt wird nach der Übergabe des Systems an den Kunden derAnwendertest (Synonym:
Abnahmetest) durchgeführt. Dieser ähnelt dem Systemtest, wird jedoch nicht vom Herstel- ler, sondern vom Kunden durchgeführt. Hierbei werden zum einen Fehler aufgedeckt, die auf Besonderheiten der kundenseitigen Systemumgebung zurückzuführen sind. Zum an- deren fördert der Test Anforderungen zutage, die nicht eindeutig zwischen Anwender- und Herstellerseite kommuniziert wurden.
2.1.4 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.
Im Rahmen der Testdurchführung wird einTestobjekt ü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 Literatur- quellen 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ändeoffensichtlich geworden sind.
Die Testdurchführung wird bei Anwendung dynamischer Verfahren in Testfälle unterteilt. Die Definition von Testfällen erfolgt auf Grundlage derTestbasis; diese umfasst alle hierfür ge- eigneten Dokumente über das Testobjekt, wozu beispielsweise Anforderungsdefinition, Spe- zifikation und technischer Entwurf zählen.
EinTestfall 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 alsTestdatenbezeichnet.
2.2 Funktionsorientierte Methoden
2.2.1 Grundlagen
Im Zuge der Anwendung funktionsorientierter Testmethoden werden Testfälle aus der Test- basis abgeleitet. Als Grundlage für die Testfall-Definitionen dienen somit Anforderungsde- finitionen, Spezifikationen, Benutzerhandbücher und sonstige Dokumente, die Informatio- nen ü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 Funktio- nen 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 2.1.3 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.
Verbreitete Verfahren, welche zur sinnvollen Auswahl von Eingabewerten verwendet wer- den können, sind Äquivalenzklassenbildung, Grenzwertanalyse sowie der zustandsbasierte Test.
Im Rahmen des System- und Abnahmetests werden funktionsorientierte Testmethoden ein- gesetzt, um die zu testenden Arbeitsabläufe beziehungsweise Anwendungsszenarien sinn- voll auszuwählen. Hierfür stellen der anwendungsbasierte, der entscheidungstabellenba- sierte 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 Testphasen
Äquivalenzklassenbildung Modul- und Integrationstest Grenzwertanalyse Modul- und Integrationstest Zustandsbasierter Test Modul- und Integrationstest Anwendungsbasierter Test System- und Abnahmetest Entscheidungstabellenbasierter Test System- und Abnahmetest
Paarweiser Test System- und Abnahmetest
Tabelle 1: Verbreitete funktionsorientierte Testmethoden.
Quelle: [Hoffmann, 2008, S. 175 ff.]
In den nachfolgenden Abschnitten werden verbreitete Verfahren zur Auswahl von Eingabe- werten 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 einge- gangen, da ihre Implementierung in Testwerkzeugen als zu aufwändig erscheint.
2.2.2 Äquivalenzklassenbildung
Durch die Bildung und Anwendung von Äquivalenzklassen wird die Gesamtmenge der mög- lichen 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 ei- ner 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.]
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 Pro- gramms 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 Äquiva- lenzklasse bei der Testdurchführung verwendet wird; eine vollständige Testabdeckung wäre demnach bei Verwendung der Werte -10, 50 und 200 gegeben.
2.2.3 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. Die- se 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 2.2.2 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 besit- zen, können – theoretisch gesehen – keine Minimal- und Maximalwerte abgeleitet werden.
In der Praxis besteht jedoch die Möglichkeit, in Abhängigkeit der eingesetzten Program- miersprache 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.
2.2.4 Zustandsbasierter Test
Der zustandsbasierte Test wird eingesetzt, wenn das Testobjekt verschiedene Zustände an- nehmen kann und somit zustands- oder gedächtnisbehaftet ist. Der Zustand des Testob- jekts 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äu- men. Hierbei findet beispielsweise das Zustandsdiagramm der UML (Unified Modeling Lan- guage) Verwendung. Auf Basis dieser Beschreibung werden Testfälle erzeugt, welche je- weils einen definierten Anfangszustand, die zur Stimulation des Testobjekts durchzuführen- den 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 sub- sumieren 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über- gä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ßgeb- lich vom aktuellen Zustand beeinflusst. [Spillner u. Linz, 2012, S. 140].
2.3 Strukturorientierte Methoden
2.3.1 Grundlagen
Strukturorientierte Testmethoden stellen neben den in Abschnitt 2.2 beschriebenen funkti- onsorientierten 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 instru- mentiert werden kann. Aus diesem Grund erfordern strukturorientierte Testmethoden tech- nisches 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 Verfah- ren besteht darin, dass die Testüberdeckung anhand des Quellcodes objektiv gemessen und somit gewährleistet werden kann.3Im Zuge der Anwendung von White-Box-Verfahren kann sichergestellt werden, dass alle Zeilen des Programmcodes im Rahmen der Testdurchfüh- rung durchlaufen werden. Die Ausführung der Programmzeilen resultiert in einem beobacht- baren 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.]
2.3.2 Analyse der Kontrollstruktur
Die Analyse der inneren Struktur des Testobjekts dient zum einen als Grundlage für die De- finition von Testfällen. Zum anderen ermöglicht sie die Messung der durch die Testfälle er- reichten Testüberdeckung. In den Zielen des Software-Tests kann der Testabdeckungsgrad festgelegt werden, der mindestens erreicht werden soll. Zur Spezifizierung des Abdeckungs- grads 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 An- weisungen und Verzweigungen durch gerichtete Kanten miteinander verbindet. Weiterhin besitzt der Kontrollflussgraph genau einen Start- und einen Endknoten. Bei Ausführung des
3Nach Schneider [Schneider, 2007, S. 104] werden Anforderungen durch Testfälle abgedeckt, Codezeilen jedochüberdeckt; dieser sprachlichen Differenzierung wird in der vorliegenden Arbeit gefolgt.
Programms wird der Graph auf einem Pfad ausgehend von seinem Startknoten durchschrit- ten, 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 geometri- sche Formen visualisiert.
Anweisung 1 Start
Ende Verzwei-
gung 1
Anweisung 3 Anweisung 2
Anweisung 4
Abbildung 5: Abstrakte Darstellung eines Kontrollflussgraphen.
Quelle: Eigene Darstellung in Anlehnung an [Wirsing, 2003, S. 21]
2.3.3 Kontrollflussorientierte Methoden
Kontrollflussorientierte Testmethoden verfolgen den Ansatz, dass möglichst viele der Code- pfade 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 Quell- code verborgenen Fehlerzustände werden während der Testdurchführung zur Wirkung ge- bracht. [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 stren- ge Anforderungen stellen als die Pfadüberdeckung. Als Minimalkriterium sollte die Anwei- sungsüberdeckung eingehalten werden. Diese fordert die Ausführung aller im Programm- code vorhandenen Anweisungen im Rahmen der Testdurchführung. Lässt sich dieses Krite- rium 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 Über- deckungskriterien, 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
C0 Anweisungsüberdeckung Test aller Anweisungen.
C1 Zweigüberdeckung Test aller Anweisungen und aller Bedingungen.
C2 Pfadüberdeckung Test aller Pfade.
C3 Bedingungsüberdeckung Test der Teilbedingungen (verschiedene Varianten).
- McCabe-Überdeckung Test aller Elementarpfade.
Tabelle 2: Kontrollflussorientierte Testmethoden.
Quelle: [Hoffmann, 2008, S. 206 ff.]
4Fü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.
2.3.4 Datenflussorientierte Methoden
Datenflussorientierte Testmethoden messen die Testüberdeckung anhand des Datenflus- ses, 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 datenflussattributier- ter Kontrollflussgraphen visualisiert werden. Bei dieser Variation des in Abschnitt 2.3.2 be- schriebenen Kontrollflussgraphen werden die schreibenden und lesenden Variablenzugrif- fe neben den entsprechenden Anweisungsknoten angegeben. [Liggesmeyer, 2009, S. 142 f.]
Im Zuge der Analyse des Datenflusses wird grundsätzlich zwischen schreibender (defini- torischer) 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 verschiede- nen 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 Überde- ckungskriterien geprüft werden. Die Kriterien zielen darauf ab, dass nach einem definitori- schen 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 Va- riablenzugriff alle nachfolgenden referenzierenden Verwendungen der Variable durchlaufen
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 Überdeckungskri- terien.
Kriterium Beschreibung
all-defs Minimaltest: Jeder definitorische Zugriff wird von einem beliebigen referenzierenden Zugriff gefolgt.
all-c-uses Test aller kalkulatorischen Variablenzugriffe.
all-p-uses Test aller prädikativen Variablenzugriffe.
all-c-/some-p-uses Test der referenzierenden Zugriffe mit Priorisierung der kalkulatori- schen Verwendung.
all-p-/some-c-uses Test der referenzierenden Zugriffe mit Priorisierung der prädikativen Verwendung.
all-uses Maximaltest: Test aller referenzierenden Variablenzugriffe.
Required k-Tupel Test aller Sequenzen von definitorischen-referenzierenden-Zugriffen mit Länge≤k.
Tabelle 3: Datenflussorientierte Testmethoden.
Quelle: [Liggesmeyer, 2009, S. 144 ff.]
2.3.5 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 funktionsorien- tierter Verfahren erfolgt. [Spillner u. Linz, 2012, S. 164]
Bei Anwendung strukturorientierter Verfahren ist zu beachten, dass sich die dabei gemes- sene Code-Überdeckung durch Testfälle stets auf den aktuellen Programmcode des Testob- jekts 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 objektorientier- ter Software-Systeme den kontrollflussorientierten Vorfahren vorzuziehen sind, da sie unter dieser Voraussetzung einen höheren Prozentsatz der im Testobjekt enthaltenen Fehlerzu- stände aufdecken. [Liggesmeyer, 2009, S. 141]
Zuletzt soll darauf hingewiesen werden, dass die Messung der Testüberdeckung die Instru- mentierung des Testobjekts erfordert. Hierbei wird der Quellcode des zu testenden Pro- gramms im Vorfeld eines Testlaufs durch Kontrollanweisungen ergänzt, sodass die Ausfüh- rung der für die Testüberdeckung relevanten Codezeilen protokolliert werden kann. [Spillner u. Linz, 2012, S. 164 f.]
2.4 Statische Prüfungen
2.4.1 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 Entwick- lungsprozess eingesetzt werden, da ein lauffähiges System keine zwingende Voraussetzung für die Testdurchführung darstellt. Folglich kann auch auf Testtreiber und Platzhalter verzich- tet 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 Testdurch- führung gering gehalten werden kann. [Simon u. a., 2006, S. 107]
In der vorliegenden Arbeit wird zwischen manueller und automatisierter Prüfung des Quell- codes des Testobjekts unterschieden. Das Review stellt eine verbreitete manuelle Methode des statischen Testens dar und wird in Abschnitt 2.4.2 genauer erläutert. Im Gegensatz da- zu beschreibt Abschnitt 2.4.3 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 2.4.4 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.].
2.4.2 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
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 wer- den anstelle von „Quellcode“ und „Entwickler“ die allgemeineren Begriffe „Dokument“ bezie- hungsweise „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 protokol- liert. Im Gegensatz dazu handelt es sich bei einer Inspektion um ein formales Review, das mit einer Vorbereitungsphase, einer Reviewsitzung sowie einer Nachbereitungsphase ver- bunden 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 Entwicklungspro- zesse des Unternehmens. [Henry, 2008, S. 67 f.]
Tabelle 4 enthält eine Übersicht über die verschiedenen Varianten des Reviews.
Review-Art Beschreibung
Informelles Review Gegenlesen des Dokuments durch einen Kollegen.
Walkthrough Besprechung des Dokuments in einer informellen Sitzung.
Technisches Review Experten beraten in einer protokollierten Sitzung über das Doku- ment.
Inspektion Das Dokument wird in einer formalen, moderierten Sitzung ge- prü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 aufge- wogen. 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än- de. 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 er- stellten Dokumenten und kann darüber hinaus zur Verbesserung der Entwicklungsprozesse beitragen.
2.4.3 Automatisierte Prüfung
Neben der manuellen Prüfung des Quellcodes des Testobjekts können statische Analysen auch werkzeuggestützt durchgeführt werden.5 Hierbei analysieren Werkzeuge die innere Struktur des Systems und konstruieren auf dieser Grundlage ein Systemmodell. Nach Si- mon u.a. [Simon u. a., 2006, S. 108] handelt es sich bei einem Systemmodell um eine abstrakte Beschreibung des Quellcodes, welche Informationen über die im System vor- handenen Einheiten sowie deren wechselseitigen Beziehungen enthält. Das Systemmodell kann einerseits als Dokumentation genutzt werden, um die Einarbeitung in die Architek- tur der Anwendung zu erleichtern. Andererseits können auf Grundlage des Systemmodells im Quellcode vorhandene Unstimmigkeiten aufgedeckt und Kennzahlen ermittelt werden.
[Cleff, 2010, S. 198]
Abbildung 7 stellt die verschiedenen Arten der automatisierten statischen Analyse grafisch dar. Im Folgenden werden die verschiedenen Ansätze umrissen – eine erschöpfende Er- läuterung ist im Rahmen der vorliegenden Arbeit hingegen nicht möglich. Die Erläuterung von Metriken erfolgt im separaten Abschnitt 2.4.4, da dieser Form der statischen Analyse in Theorie und Praxis besonders große Bedeutung beigemessen wird.
Automatisierte statische
Prüfung
Anomalien- analyse Konformitäts-
analyse
Exploit- Analyse
Messung (Metriken)
Formale Verifikation
Abbildung 7: Taxonomie der automatisierten statischen Software-Prüfung.
Quelle: Eigene Darstellung auf Grundlage von [Hoffmann, 2008, S. 247 ff.].
Im Rahmen der Konformitätsanalysewird der Quellcode auf die Einhaltung vorgegebener Regeln und Richtlinien überprüft [Hoffmann, 2008, S. 271 f.]. In syntaktischer Hinsicht wird das Programm gegen die Grammatik der verwendeten Programmiersprache geprüft; dies ist Aufgabe des Compilers. Die Analyse der Semantik deckt Strukturelemente des Quellcodes auf, die zwar syntaktisch zulässig sind, jedoch Konventionen der eleganten und effizienten Programmierung widersprechen. Bei dieser Prüfung können durchaus auch unternehmen- spezifische Programmierrichtlinien berücksichtigt werden [Spillner u. Linz, 2012, S. 102].
Dies macht die Konformitätsanalyse zu einer flexiblen und effizienten Methode, um bereits
5In der Literatur wird die automatisierte Quellcode-Prüfung teilweise mit der statischen Analyse gleichgesetzt [Cleff, 2010, S. 198]. In der vorliegenden Arbeit wird die manuelle Prüfung jedoch auch der statischen Analy- se zugeordnet. Somit werden die statische Analyse als Oberbegriff und die manuelle sowie die automatisierte Prüfung als Varianten betrachtet.
während der Entwicklung einen Mindeststandard hinsichtlich der Software-Qualität zu ge- währleisten.
DieAnomalienanalysedeckt Unstimmigkeiten im Kontroll- und Datenfluss des Testobjekts auf und zielt damit in dieselbe Richtung wie die Konformitätsanalyse. Im ersten Schritt der Analyse wird ein – gegebenenfalls datenflussattributierter – Kontrollflussgraph erstellt, wie er in Abschnitt 2.3.2 der vorliegenden Arbeit bereits beschrieben wurde. Auf dieser Grund- lage wird der Kontroll- und Datenfluss des Programms auf Auffälligkeiten hin untersucht.
Hinsichtlich des Kontrollflusses kann es sich dabei beispielsweise um unerreichbare Anwei- sungen oder nicht zugewiesene Rückgabewerte handeln. Anomalien im Datenfluss liegen bei Verwendung von nicht-initialisierten Variablen oder bei fehlender Verwendung von Varia- blen nach ihrer Wertezuweisung vor.
Prinzipiell handelt es sich bei Anomalien zwar um Auffälligkeiten, jedoch nicht zwingend um Fehler. Nach der Anwendung eines Werkzeugs zur statischen Analyse muss der zuständi- ge Entwickler für jede der dabei aufgespürten Anomalien entscheiden, ob diese auf einen Fehler hindeutet und somit behoben werden muss. [Spillner u. Linz, 2012, S. 102 ff.]
Eine weitere Aufgabe der statischen Analyse besteht darin, das Testobjekt auf sicherheits- kritische Schwachstellen hin zu untersuchen. Angreifer können derartige Sicherheitslücken ausnutzen, um das Programm zum Absturz zu bringen, Daten zu manipulieren oder frem- den Programmcode zur Ausführung zu bringen. Die Aufdeckung derartiger Sicherheitslü- cken wird nach Hoffmann [Hoffmann, 2008, S. 301] alsExploit-Analysebezeichnet. Mit Hilfe der syntaktischen und semantischen Ansätze der Exploit-Analyse können sicherheitskriti- sche Schwachstellen aufgedeckt werden, die Angriffstechniken wie Puffer-Überläufe oder SQL-Injektionen ermöglichen [Pezzè u. Young, 2009, S. 401].
2.4.4 Metriken
Softwaremetriken sind Maße, welche die Quantifizierung bestimmter Aspekte eines Software- Entwicklungsprozesses oder eines Software-Produkts ermöglichen. Im Rahmen der Software- Qualitätssicherung werden Metriken eingesetzt, um bestimmte Aspekte der Qualität des be- trachteten Software-Systems anhand objektiver Zahlen bewerten zu können. Da die Ermitt- lung der verbreiteten Metriken standardisiert ist, können die Ergebnisse mit Referenzwerten oder den Werten anderer Unternehmen verglichen werden. Auf diese Weise können Poten- ziale zur Verbesserung der Software-Qualität systematisch aufgedeckt werden. [Simon u. a., 2006, S. 113]
Für die vorliegende Arbeit sind Metriken relevant, aus denen sich Aspekte der Qualität des betrachteten Software-Systems ableiten lassen. Ein Beispiel hierfür stellt die McCabe-Metrik
dar. Diese quantifiziert die Komplexität eines Programms auf Grundlage seiner zyklomati- schen Zahl, welche mit jeder im Kontrollfluss enthaltenen Verzweigung steigt [Hoffmann, 2008, S. 259]. Dahinter steht der Gedanke, dass ein Programm umso schwerer verständlich ist, je mehr Bedingungen es enthält. Folglich wird die Qualität des betroffenen Software- Systems hinsichtlich der Wartbarkeit und Erweiterbarkeit verschlechtert, wenn dessen Mo- dule eine im Durchschnitt hohe Komplexität aufweisen.
Auf Grundlage der McCabe-Metrik kann eine Höchstgrenze für die zyklomatische Komple- xität von Seiten der Qualitätssicherung festgelegt werden. Die Einhaltung dieser Richtlinie kann bereits während der Entwicklung mit geringem Aufwand überprüft werden, indem ent- sprechende Analysewerkzeuge eingesetzt werden. Auf diese Weise leistet die Anwendung der McCabe-Metrik einen Beitrag, um den Qualitätsstandard eines Software-Produkts von Anfang an hoch zu halten.
Tabelle 5 enthält eine Übersicht verbreiteter Maße der Software-Qualität. Am Beispiel der McCabe-Metrik wurde oben gezeigt, wie Softwaremaße zur Verbesserung der Software- Qualität eingesetzt werden können. Zur Ermittlung der Metrik LOC (Lines of Code) werden die Code-Zeilen des Programms gezählt; auf diese Weise gibt diese grundlegende Metrik Aufschluss über den Umfang der Software. Mit Hilfe der Metrik MTBF (Mean Time Between Failures) kann die Zuverlässigkeit eines Systems gemessen werden. Zur Bestimmung der MTBF wird der Mittelwert der Zeitspannen zwischen zwei Systemausfällen gebildet. Im Ge- gensatz zur MTBF ist die Ausführung des zu vermessenden Systems für die Anwendung der Halstead-Maße nicht notwendig. Bei den Halstead-Metriken handelt es sich um eine Gruppe von Kennzahlen, die auf Grundlage der Analyse des Quellcodes in Operatoren und Operanden berechnet werden [Liggesmeyer, 2009, S. 260]. Die Halstead-Maße geben unter anderem Hinweise auf die Komplexität, den Umfang und den Aufwand zur Implementierung des Programms.
Metrik Kategorie Beschreibung
LOC Umfangsmaß Lines of Code; Anzahl der Code-Zeilen des Pro- gramms.
MTBF Zuverl.keitsmaß Mean Time Between Failures; durchschnittliche Zeit zwischen zwei aufeinander folgenden Ausfällen.
McCabe Komplexitätsmaß Die zyklomatischen Komplexität steigt mit der Anzahl der im Programm enthaltenen Verzweigungen.
Halstead (verschiedene) Gruppe von Kennzahlen, welche auf Grundlage der im Quellcode vorkommenden Operatoren und Operanden errechnet werden.
Tabelle 5: Verbreitete Metriken der Software-Qualitätssicherung.
Quelle: [Liggesmeyer, 2009, S. 255 ff.]
2.4.5 Formale Verifikation
Im Rahmen der Verifizierung prüft der Software-Hersteller, ob das Ergebnis einer Entwick- lungsphase den gestellten Anforderungen und Zielen entspricht [Spillner u. Linz, 2012, S. 43]. So wird beispielsweise die Spezifikation anhand der Anforderungen und das reali- sierte System anhand seines technischen Entwurfs verifiziert. Im Gegensatz zur Validierung erfolgt die Verifizierung durch die Entwicklungsabteilung des Software-Produzenten.
Die formale Verifikation stellt eine Variante der Verifizierung dar, bei welcher die Prüfung der Entwicklungsergebnisse mit Hilfe mathematischer Methoden erfolgt. Da das Programm dabei nicht zur Ausführung kommt, handelt es sich um eine statische Testmethode. Mit Hilfe der formalen Verifikation kann mathematisch bewiesen werden, dass sich das Programm gemäß seiner Spezifikation verhält. Aufgrund dieses Umstands ist die formale Verifikation sehr viel exakter als andere Ansätze wie beispielsweise funktionsorientierte Testmethoden, welche lediglich einen Teil der möglichen Varianten des Programmablaufs testen. [Thaller, 2002, S. 194 f.]
Trotz ihres großen Potenzials konnte sich die formale Verifikation in der Praxis bisher nicht durchsetzen. Ein wesentlicher Grund ist darin zu suchen, dass das Eingangsdokument, ge- gen welches verifiziert wird, in einer formalen Notation vorliegen muss; auf diese Weise kann die Mehrdeutigkeit natürlicher Sprachen vermieden werden. Die Verwendung einer formalen Notation erfordert jedoch Spezialwissen und schränkt die Verwendbarkeit des entstandenen Dokuments ein. Weiterhin ist der zu untersuchende Zustandsraum bei komplexen Software- Systemen häufig so groß, dass selbst moderne Computersysteme bei der Durchführung der formalen Verifikation an die Grenzen ihrer Rechenleistung stoßen.
Aus diesen Gründen erscheint die Anwendung der formalen Verifikation nur dann sinnvoll, wenn das Testobjekt in einem sicherheitskritischen Bereich eingesetzt werden soll oder mit sonstigen Testmethoden nicht zufriedenstellend geprüft werden kann. Aufgrund der Schwie- rigkeiten beim Einsatz formaler Verifikationsverfahren favorisieren Pezzè und Young [Pezzè u. Young, 2009, S. 129 f.] die modellbasierte Verifikation. Dabei können verschiedene ma- thematische Verfahren zum Einsatz kommen; diese besitzen zwar nicht zwingend die Präzi- sion der formalen Verifikation, lassen sich jedoch mit weniger Aufwand einsetzen und besser skalieren.
3 Testwerkzeuge
3.1 Grundlagen
3.1.1 Definition
Unter einemTestwerkzeugist eine Software-Anwendung zu verstehen, welche die Software- Qualitätssicherung beim Testen von Software-Systemen unterstützt. In der Literatur wird hierfür der Begriff CAST (Computer Aided Software Testing) synonym verwendet [Spillner u.
Linz, 2012, S. 210].
Testwerkzeuge werden für verschiedene Anwendungsbereiche des Testens eingesetzt; Ab- schnitt 3.2 erläutert die verschiedenen Einsatzmöglichkeiten im Detail. Mit der Testautoma- tisierung soll an dieser Stelle ein bedeutender Anwendungsbereich für Software-Testwerk- zeuge vorweggenommen werden. Unter der Testautomatisierung ist nach Seidl u.a. „[...]
die Durchführung von ansonsten manuellen Testtätigkeiten durch Automaten“ [Seidl u. a., 2012, S. 7] zu verstehen. Ein Testwerkzeug kann somit als Automat fungieren, der Testfäl- le durchführt, welche im Vorfeld durch Tester spezifiziert wurden. Dadurch wird zum einen die Effizienz der Testdurchführung erhöht und die Möglichkeit geschaffen, Tests mit vie- len verschiedenen Versionen des Software-Systems und in unterschiedlichen Umgebungen auszuführen. Zum anderen wird durch eine Automatisierung die Zuverlässigkeit und Nach- vollziehbarkeit der Testdurchführung erhöht.
Im Zusammenhang mit Testwerkzeugen wird vereinzelt der Begriff desTestframeworksver- wendet. Nach Spillner und Linz [Spillner u. Linz, 2012, S. 209] wird damit entweder ein System zur Erstellung von Testwerkzeugen, ein Konzept zur Testautomatisierung oder der Gesamtprozess der Testdurchführung verstanden.
EinTestportal integriert verschiedene Testwerkzeuge und ermöglicht einen rollenbasierten und personalisierten Zugriff auf Testfunktionen und Testberichte. Die Notwendigkeit für Por- tale entsteht einerseits dadurch, dass in größeren Unternehmen zumeist mehrere Werk- zeuge eingesetzt werden müssen, um die gestellten Anforderungen abzudecken; beispiels- weise dient ein Werkzeug zur statischen Analyse, ein anderes zur automatisierten Test- durchführung und ein drittes zum Vergleich von Ist- und Soll-Werten. Andererseits folgt aus unterschiedlichen Rollen wie Manager, Tester oder Entwickler ein unterschiedlicher Informa- tionsbedarf; dieser Tatsache wird bei Einsatz von Testportalen Rechnung getragen, indem unterschiedliche Sichten auf die Testergebnisse angeboten werden. Dies kann beispiels- weise realisiert werden, indem für Manager Statistiken und Kennzahlen generiert werden,
Testern Informationen über Testläufe und Testüberdeckung angezeigt werden und einem Entwickler die Ergebnisse der statischen Code-Analyse und der Testdurchführungen für die von ihm erstellten Module zugänglich gemacht werden. [Simon u. a., 2006, S. 134 ff.]
3.1.2 Ziele des Einsatzes
Die wesentlichen Ziele, die beim Einsatz von Testwerkzeugen verfolgt werden, bestehen in der Steigerung der Effizienz des Testens, in der Anwendung mathematischer Verfah- ren sowie in einer verbesserten Protokollierung der Testdurchführung [Liggesmeyer, 2009, S. 392].
Durch die Automatisierung einfacher Tätigkeiten der Qualitätssicherung können einerseits die Kosten der Testdurchführung gesenkt werden. Andererseits ermöglicht dies die Steige- rung des Testumfangs. Darauf weist insbesondere Thaller [Thaller, 2002, S. 228 f.] hin und führt an, dass das Software-Produkt mit Hilfe automatischer Tests auf Grundlage einer höhe- ren Anzahl verschiedener Systemumgebungen geprüft werden kann als dies bei manueller Testdurchführung der Fall wäre. Zusätzlich können automatische Tests unter Verwendung von Zwischenversionen ausgeführt werden, wodurch der aktuelle Stand der Qualität des Software-Produkts bereits während der Entwicklung transparent gemacht wird. Zuletzt weist Thaller darauf hin, dass die Beschleunigung der Testdurchführung durch Automatisierung zu geringeren Testlaufzeiten führt, wodurch eine neue Version des Software-Produkts frü- her auf den Markt kommen kann.
Weiterhin ermöglichen Testwerkzeuge die Anwendung mathematischer Verfahren, welche ansonsten aufgrund des hohen Aufwandes nicht einsetzbar wären. Hierzu zählt zum einen die Anwendung strukturorientierter Verfahren zur Ermittlung der Testüberdeckung. Zum an- deren wäre die Ermittlung von Metriken oder die Anwendung von statischen Prüfmethoden wie der formalen Verifikation ohne Werkzeugunterstützung undenkbar.
Schließlich erstellen Testwerkzeuge Protokolle und Berichte über Testläufe und dienen so- mit als Nachweisinstrument. Die automatisierte Protokollierung und Auswertung senkt dabei nicht nur Kosten, sondern steigert darüber hinaus die Zuverlässigkeit und Objektivität dieser Dokumente. Für einen Nachweis der Testergebnisse gegenüber Dritten gelten durch Werk- zeuge automatisch erstellte Protokolle als deutlich aussagekräftiger als manuell erstellte Dokumente.
3.1.3 Möglichkeiten der Klassifizierung
Testwerkzeuge können anhand des Anwendungsbereichs, für den sie geeignet sind, klas- sifiziert werden. Zu den verschiedenen Anwendungsbereichen zählen die Unterstützung
des Testmanagements, die Generierung von Testdaten, die Spezifikation von Testfällen, die Messung der Testabdeckung, die Ausführung von Testfällen, die Durchführung von stati- schen Prüfungen sowie nicht-funktionale Tests, in welchen unter anderem der Ressourcen- bedarf und die Datensicherheit des Software-Produkts geprüft werden. Die aufgezählten Anwendungsbereiche werden im nachfolgenden Abschnitt 3.2 näher erläutert.
Neben dem Anwendungsbereich eines Testwerkzeugs können weitere grundlegende Eigen- schaften für eine grobe Klassifizierung verwendet werden.
Hierzu zählt insbesondere die Abhängigkeit des Werkzeugs von bestimmten Programmier- sprachen, Hardware-Plattformen oder Betriebssystemen. Werkzeuge, die funktionsorientier- te Testmethoden implementieren, sind in dieser Hinsicht zumeist flexibel einsetzbar. Im Un- terschied dazu müssen strukturorientierte Testmethoden sowie die Verfahren der statischen Code-Analyse für jede Programmiersprache separat implementiert werden [Liggesmeyer, 2009, S. 394 f.]. Bei diesen Ansätzen wird – wie in den Abschnitten 2.3.2 und 2.4.3 an- gesprochen – die innere Struktur des Testobjekts mittels eines Kontrollflussgraphen oder eines Systemmodells abgebildet. Auf Grundlage dieser abstrakten Darstellung können Al- gorithmen in Unabhängigkeit von der Programmiersprache, in der das Testobjekt vorliegt, zum Zwecke der Prüfung angewendet werden. Für die Abstrahierung des Quellcodes des Testobjekts ist die Kenntnis der vorliegenden Programmiersprache jedoch unabdingbar.
Weiterhin ist zu beachten, dass strukturorientierte Werkzeuge zur Testdurchführung in der Regel eine Instrumentierung des Testobjekts erfordern. Dabei werden Protokollanweisun- gen in den Quellcode des Testobjekts eingefügt, um die Testüberdeckung im Zuge der Test- durchführung ermitteln zu können [Spillner u. Linz, 2012, S. 252]. Somit stellt die Unterschei- dung in instrumentierende und nicht-instrumentierende Werkzeuge eine weitere Möglichkeit der Klassifizierung dar.
3.2 Anwendungsbereiche
3.2.1 Testmanagement und -steuerung
Ein Anwendungsbereich von Testwerkzeugen besteht darin, die Qualitätssicherung hin- sichtlich des Managements und der Steuerung von Software-Tests zu unterstützen. Somit sind derartige Werkzeuge nicht an der Testdurchführung beteiligt, sondern ermöglichen ei- ne effiziente Durchführung des mit der Software-Qualitätssicherung verbundenen Projekt-, Anforderungs-, Konfigurations- und Abweichungsmanagements. Weiterhin dienen sie zur Pflege und Priorisierung von Testfällen und unterstützen das Berichtswesen, indem sie Test- durchführungsprotokolle auswerten und aufbereiten. [Spillner u. Linz, 2012, S. 210]
