FOM Hochschule für Ökonomie und Management Essen. IT-Management. Seminararbeit im Modul Software-Engineering, IT-Projekt- und Qualitätsmanagement

Transkript

1 FOM Hochschule für Ökonomie und Management Essen IT-Management Seminararbeit im Modul Software-Engineering, IT-Projekt- und Qualitätsmanagement Dynamische Testverfahren: Ein Vergleich zwischen White- und Blackboxtests Betreuer: Autor: Prof. Dr. Gregor Sandhaus Dennis Klümper Matrikelnummer: Bearbeitungszeitraum: Essen, den

2 Inhaltsverzeichnis - i - Inhaltsverzeichnis Inhaltsverzeichnis... i Abbildungsverzeichnis... ii 1 Einleitung Grundlagen des Softwaretestens Dynamische / Flexible Testverfahren Abgrenzung zu statischen Testverfahren Blackbox-Verfahren Äquivalenzklassenbildung Grenzwertanalyse Zustandsbezogene Tests Ursache-Wirkungs-Graph-Analyse Allgemeine Bewertung der Blackbox-Verfahren Whitebox-Verfahren Anweisungsüberdeckung Zweigüberdeckung Bedingungsüberdeckung Pfadüberdeckung Allgemeine Bewertung der kontrollflussorientierten Whitebox-Verfahren Zusammenfassung / Fazit Anhang... I Literaturverzeichnis... II Eidesstattliche Erklärung... III

3 Abbildungsverzeichnis - ii - Abbildungsverzeichnis Abbildung 1: Subsumptionshierarchie der kontrollflussorientierten Testtechniken... 14

4 Einleitung Einleitung In der heutigen Geschäftswelt funktioniert nur noch sehr wenig ohne Software Finanztransaktionen, Personalwesen, Logistik in fast allen Bereichen moderner Unternehmen werden teils sehr komplexe IT-Systeme eingesetzt die auf Software beruhen. Aus diesem Grund ist es enorm wichtig, dass diese Systeme auch zuverlässig arbeiten und die Software qualitativ hochwertig ist. Das oftmals eher vernachlässigte Thema des Softwaretestens gewinnt immer mehr an Bedeutung. Im Rahmen dieser Seminararbeit soll ein wichtiger Eckpfeiler dieser Thematik näher beleuchtet und vorgestellt werden, die dynamischen Testverfahren (in der Literatur auch häufig flexible Testverfahren ). Zunächst sollen dem Leser dieser Arbeit die Grundlagen des Softwaretestens dargelegt werden, um später näher auf Methoden und Techniken eingehen zu können. Im Hauptteil der Arbeit werden zwei verschiedene Formen dynamischer Testverfahren mitsamt ihrer bekanntesten Ausprägungen und Methoden vorgestellt, die Black und Whitebox-Verfahren. Neben der Beschreibung der Verfahren sollen auch ihre jeweiligen Vor- und Nachteile, sowie praxistaugliche Verwendungsstrategien aufgezeigt werden. Eine Zusammenfassung der Erkenntnisse mitsamt einer kritischen Würdigung in Form eines Fazits bildet dann den Schlussteil dieser Seminararbeit.

5 Einleitung Grundlagen des Softwaretestens Der Softwaretest ist eine der am häufigsten eingesetzten Techniken der analytischen Qualitätssicherung 1 und sollte zum Repertoire eines jeden Softwareentwicklers gehören. Eine Software muss vor der Veröffentlichung bzw. Fertigstellung getestet werden, um eine möglichst hohe Qualität aufweisen zu können. Der Qualitätsbegriff ist in der Softwaretechnik nach ISO/IEC 9126 genau spezifiziert und umfasst folgende Qualitätsmerkmale 2 : - Funktionalität - Zuverlässigkeit - Benutzbarkeit - Effizienz - Änderbarkeit - Übertragbarkeit In der Literatur finden sich verschiedene Modelle, die sich mit der praktischen Umsetzung von Softwarequalität in Form von Prozess- und Organisationsmodellen auseinandersetzen. Im Rahmen dieser Arbeit wird allerdings nur auf den eigentlichen Softwaretest in seiner dynamischen Form eingegangen. Prinzipiell ist der Herstellungsprozess von Software vergleichbar mit dem Herstellungsprozess eines Industrieproduktes, obgleich Software immateriell ist. Bei der Herstellung wird geprüft, ob ein Teil- oder Endprodukt eine vorher definierte Anforderung erfüllt oder nicht 3. Bei Software kann man dies durch ihr Verhalten beim Ausführen überprüfen. Sollte sich die Software bei der Ausführung anders verhalten, als es vorher (möglichst schriftlich) definiert wurde, so liegt ein Fehlverhalten bzw. ein Fehler vor (Abweichung von SOLL- und IST-Verhalten). Die Schwierigkeit beim 1 Vgl. Hoffmann, S Vgl. Balzert, S. 1102f 3 Vgl. Spillner, S. 6

6 Einleitung Testen von Software liegt darin, dass von einem Fehlverhalten der Software nicht automatisch auf die Ursache geschlossen werden kann. Es kann durchaus vorkommen, dass durch einen Programmierfehler ein Fehlerzustand zu einem Zeitpunkt bereits eingetreten ist, die eigentliche Fehlerwirkung aber z.b. durch Defekte in anderen Programmteilen maskiert wird und erst zu einem späteren Zeitpunkt wirklich ersichtlich wird 4. Ein Vorteil bei der Softwareentwicklung ist hingegen, dass Fehler nicht durch Verschleiß oder Alterung des Produkts auftreten, wie z.b. bei Industrieprodukten. Ein Fehler ist entweder schon zum Zeitpunkt der Auslieferung vorhanden oder wird ggfs. zu einem späteren Zeitpunkt durch Aktualisierungen der Software nachträglich eingebaut. 4 Vgl. Spillner, S. 8

7 Dynamische / Flexible Testverfahren Dynamische / Flexible Testverfahren Die dynamischen Testverfahren zeichnen sich dadurch aus, dass bei ihnen die Software auf einem Rechner ausgeführt und ihr Verhalten untersucht wird. Aus diesem Grund muss für den dynamischen Test wenigstens ein ausführbarer Teil der Software vorliegen. Da dies in den unteren Teststufen (Komponenten- und Integrationstest) nicht der Fall ist, muss dort das Testobjekt in einen Testrahmen [...] eingebettet werden, um ein ablauffähiges Programm zu erhalten 5. Im Rahmen der dynamischen Testverfahren werden immer speziell ausgewählte Testdaten verwendet. Da diese meist zufällig ausgewählt sind und bei Weitem nicht alle erdenklichen Testfälle abdecken, [...] sind alle praktisch relevanten dynamischen Testtechniken Stichprobenverfahren 6. Dies bedeutet, dass mit Hilfe dynamischer Tests nur unvollständige Aussagen über die Qualität einer Software getroffen werden können. Trotz dieser Nachteile besitzen die dynamischen Verfahren eine hohe Praxistauglichkeit und werden häufig in unterschiedlichen Kombinationen miteinander ausgeführt. 2.1 Abgrenzung zu statischen Testverfahren Die statischen Testverfahren haben folgende Eigenschaften und werden deshalb auch häufig statische Analyseverfahren genannt: - Es erfolgt keine Ausführung der zu prüfenden Software - Alle statischen Analysen können prinzipiell ohne Computerunterstützung durchgeführt werden - Es werden keine Testfälle gewählt - Vollständige Aussagen über die Korrektheit oder Zuverlässigkeit können nicht erzeugt werden 7 5 Spillner, S Liggesmeyer, S.39 7 Liggesmeyer, S.43

8 Dynamische / Flexible Testverfahren Im Prinzip wird der Quellcode einer Software bei der statischen Analyse im Vorfeld auf seine Korrektheit hin überprüft. Dazu gibt es verschiedene Werkzeuge, die ein Softwareentwickler in der Praxis einsetzen kann, um z.b. Inkonsistenzen oder fehlende Wertzuweisungen im Vorfeld aufdecken und beheben zu können. 2.2 Blackbox-Verfahren Blackbox-Verfahren oder auch funktionsorientierte Testmethoden gehören mit zu den dynamischen Testverfahren und zeichnen sich dadurch aus, dass der Tester nicht an dem internen Verhalten und an der Struktur der Programms interessiert ist, sondern daran, welche Ausgaben das Programm bei speziellen Testfällen erzeugt und ob diese mit den zuvor definierten Ausgaben konform sind 8. Theoretisch müsste ein Tester alle erdenklichen Kombinationen von Eingabedaten zu Testfällen formen und diese mit den gewünschten Ausgaben abgleichen. Ein solcher Test würde vollständiger Test genannt werden. Die Komplexität von Softwareprodukten und wirtschaftliche Gesichtspunkte führen dazu, dass ein solcher vollständiger Test praktisch nicht umzusetzen ist. Demzufolge muss der Tester im Vorfeld nützliche und notwendige Testfälle definieren, die im Idealfall alle gewünschten SOLL-Funktionen der Software abdecken. Hierfür können verschiedene Methoden als Hilfestellung herangezogen werden Äquivalenzklassenbildung Die funktionale Äquivalenzklassenbildung hilft dem Tester dabei, eine möglichst sinnvolle Auswahl an Testfällen zu definieren, die einerseits möglichst alle potentiellen Fehler einer Software aufspüren können soll, andererseits die Quantität und Komplexität der Testfälle auf ein vernünftiges Maß herunter brechen muss. Daten bzw. Werte werden in so genannte Äquivalenzklassen eingeordnet, die alle durch die 8 Vgl. Myers, S.7

9 Dynamische / Flexible Testverfahren Software gleichartig bearbeitet werden sollen 9. Für jede definierte Äquivalenzklasse sollte der Tester mindestens einen Wert auswählen, der anschließend repräsentativ für alle anderen Werte der Klasse im Test geprüft wird. (z.b. 61 für alle Werte zwischen 1 und 100). Zu einer Äquivalenzklasse gehören alle Eingabedaten, bei denen der Tester davon ausgeht, dass sich das Testobjekt bei Eingabe eines beliebigen Datums aus der Äquivalenzklasse gleich verhält. 10 Unterschieden wird grundsätzlich zwischen gültigen und ungültigen Äquivalenzklassen: Erfordert eine Funktion einer Software beispielsweise ausschließlich positive Eingabewerte (z.b. Anzahl Mitarbeiter), so kann eine gültige Äquivalenzklasse (positive Zahlen) und eine ungültige Äquivalenzklasse (negative Zahlen) gebildet werden. Negativen Zahlen würden in diesem Fall zu einem Fehler führen und müssen mit Hilfe einer Fehlerbehandlungsroutine verarbeitet werden. Bevor der Test durchgeführt werden kann müssen die zu erwartenden Resultate der Testfälle bestimmt werden, um das IST-Ergebnis mit dem SOLL-Ergebnis abgleichen zu können (Bei Berechnungen kann man dies z.b. mit einer Tabellenkalkulation oder einem Taschenrechner durchführen). Sobald alle Äquivalenzklassen aufgestellt und die entsprechenden Repräsentanten festgelegt wurden, kann die Anzahl der notwendigen Testfälle ermittelt werden (Positivtests für die gültigen und Negativtests für die ungültigen Äquivalenzklassen). Aus Zeitgründen ist es auch hier oftmals nicht möglich, alle aufgestellten Testfälle wirklich durchzuführen. Als Testendekriterium wird dann der prozentuale Anteil der getesteten zu den gesamten Äquivalenzklassen gebildet, z.b. ergibt sich bei 15 von 18 getesteten Klassen eine so genannte Äquivalenzklassen- Überdeckung von 83,33% Vgl. Liggesmeyer, S Spillner, S Vgl. Spillner, S.120

10 Dynamische / Flexible Testverfahren Grenzwertanalyse Die Grenzwertanalyse wird in der Praxis häufig in Kombination mit der Äquivalenzklassenbildung angewendet, da Fehlerzustände in Programmen häufig an den Grenzbereichen der Äquivalenzklassen auftreten. 12 Nach G.J. Myers unterscheidet sich die Grenzwertanalyse dahingehend von der Äquivalenzklassenbildung, als dass bei ihr jeder Rand einer Äquivalenzklasse in einem Testfall auftreten muss, anstatt zufällig ausgewählter Repräsentanten der Klasse. Ferner gilt die Aufmerksamkeit nicht nur den Eingabebedingungen, sondern es müssen auch Testfälle entworfen werden, die den Ergebnisraum berücksichtigen (Ausgabeäquivalenzklassen) 13. Myers empfiehlt dem Tester, stets die Grenzen selbst, als auch die Werte unmittelbar vor und nach der Grenze zu prüfen (z.b. sollten bei einem Wertebereich von -1 bis +1 auch und getestet werden). Zudem sollen immer Minimal und Maximalwerte sowie deren Nachbarwerte geprüft werden. Bei Fließkommazahlen liegt die Wahl der Toleranz der Rechengenauigkeit (Nachkommastellen) beim Tester selbst 14. Um eine sinnvolle Grenzwertanalyse durchführen zu können, sollten die Softwareanforderungen im Vorfeld mit dem Kunden gründlich ausgearbeitet worden sein. Eventuell genügt es dem Kunden, wenn das Programm lediglich x-stellige Werte verarbeiten kann, so dass man das Testen astronomisch großer Grenzwerte vernachlässigen kann. Ähnlich wie bei der Äquivalenzklassenbildung hängt der Erfolg oder Misserfolg dieses Tests von der Wahl der Klassen und Testfälle ab Zustandsbezogene Tests Bislang wurden Testverfahren vorgestellt, bei denen eine Ausgabe in Abhängigkeit von einer bestimmten Eingabe überprüft wurde. Vernachlässigt wurde dabei, in welchem Zustand sich das verarbeitende System befindet bzw. welche Operationen das System 12 Spillner, S Vgl. Myers, S Vgl. Spillner, S.121

11 Dynamische / Flexible Testverfahren im Vorfeld bereits durchgeführt hat. Dies ändert sich nun beim zustandsbezogenen Test. Um diesen durchführen zu können, muss bereits beim Softwareentwurf ein entsprechendes zustandsbezogenes Modell spezifiziert werden, aus dem sich dann alle Zustände und Zustandsübergänge als Testbedingungen für die Testfälle extrahieren und testen lassen 15. Systeme, die abhängig von ihrem Zustand arbeiten, sind häufig endliche Automaten bzw. Zustandsautomaten. Hierzu gehören beispielsweise Geldautomaten oder Fahrkartenautomaten. Grundsätzlich sind zustandsbezogene Tests dann sinnvoll, wenn es sich um ein gedächtnisbehaftetes System handelt, d.h. wenn das System seine Historie in irgendeiner Form speichert. Im Grunde genommen ist also jede Software gedächtnisbehaftet, da sie auf einem Speicher aufbaut. Diese Gedächtnishaftung steht aber nicht stets so im Vordergrund, dass sie für den Test beobachtet werden muss 16, d.h. der zustandsbezogene Test kann bei einigen Programmen durchaus vernachlässigt und durch andere Testformen ersetzt werden. Bei Zustandsautomaten unterscheidet man zwischen Zuständen, Ereignissen und Zustandsübergängen. Solche Automaten werden häufig in Form von Zustandsdiagrammen, -tabellen oder matrizen dargestellt. Ziel des zustandsbezogenen Tests ist es, möglichst sämtliche Testfälle für alle denkbaren Zustände, Ereignisse und Zustandsübergänge zu definieren und zu testen, um zu verhindern, dass der Automat an einer Stelle hängt und nicht weiter laufen kann 17. Als Testendekriterien lassen sich folgende Punkte festhalten 18 : - Jeder Zustand wurde mindestens einmal erreicht - Jeder Zustandsübergang wurde mindestens einmal ausgeführt - Alle spezifikationsverletzenden Zustandsübergänge wurden geprüft 15 Vgl. Cleff, S Liggesmeyer, S Vgl. Cleff, S Vgl. Spillner, S.134

12 Dynamische / Flexible Testverfahren Ursache-Wirkungs-Graph-Analyse Bei den bislang vorgestellten Methoden und Techniken wurden die verschiedenen Eingabeparameter eines Testobjekts unabhängig voneinander betrachtet. Bei der Ursache-Wirkungs-Graph-Analyse werden solche Abhängigkeiten bei der Ermittlung der Testfälle berücksichtigt 19. Ein Ursache-Wirkungs-Graph ist eine formale Sprache, in die eine Spezifikation aus der natürlichen Sprache übersetzt wird, [...] wobei er einer Schaltung der Digitallogik entspricht (kombinatorisches logisches Netz). 20 Die Vorgehensweise zur Erzeugung von Testfällen nach diesem Verfahren unterteilt sich in sechs Schritte 21 : - Zerlegung der Spezifikation in handhabbare bzw. bearbeitbare Teile - Identifizierung der Ursachen und Wirkungen jeder Teilspezifikation, wobei eine Ursache eine bestimmte Eingangsbedingung bzw. eine Äquivalenzklasse von Eingabebedingungen ist und eine Wirkung eine Ausgangsbedingung oder eine Systemtransformation (Nachwirkung der Eingabe auf den Systemzustand) ist. - Transformation der Spezifikation in einen Booleschen Graphen (Ursache- Wirkungs-Graph) - Eintragung von Abhängigkeiten zwischen Ursachen und/oder Wirkungen in Form von Kommentaren - Umsetzung des Graphen in eine Entscheidungstabelle mit beschränkten Eingängen, wobei jede Spalte oder Tabelle einen Testfall darstellt - Konvertierung der Spalten der Entscheidungstabelle zu Testfällen Das Erstellen einer solchen Entscheidungstabelle hat den günstigen Nebeneffekt, dass Unvollständigkeiten und Widersprüche aufgedeckt werden 22. Der Test kann dann als beendet angesehen werden, wenn jede Spalte der Entscheidungstabelle durch 19 Vgl. Spillner, S Myers, S Vgl. Liggesmeyer, S.66f 22 Vgl. Liggesmeyer, S.66

13 Dynamische / Flexible Testverfahren mindestens einen Testfall abgedeckt wird, da dann alle sinnvollen Kombinationen von Ursachen und Wirkungen überprüft werden können Allgemeine Bewertung der Blackbox-Verfahren Eine systematische funktionsorientierte Testplanung und Durchführung ist notwendiger Bestandteil jeder akzeptablen Testvorgehensweise. [...] Die erfolgreiche Durchführung systematisch funktionsorientiert geplanter Testfälle vermittelt ein begründetes Vertrauen in die Software-Qualität. 24 Grundsätzlich ist der Erfolg eines Tests auf Blackbox-Basis maßgeblich abhängig von der Qualität der definierten Spezifikation. Fehler können nicht erkannt werden, wenn in den Anforderungen fehlerhafte Festlegungen getroffen wurden 25. Oftmals weisen Programme zum Teil ungewollte Zusatzfunktionen auf, die nicht spezifiziert wurden und ggfs. Sicherheitsprobleme auslösen können. Solche können mit Hilfe von Blackbox-Verfahren nicht oder nur zufällig gefunden werden. 2.3 Whitebox-Verfahren Anders als bei den Blackbox-Verfahren, ist bei den Whitebox- oder auch strukturorientierten Testverfahren der Quellcode des Programms bzw. Testobjekts von entscheidender Bedeutung. Ziel der Whitebox-Verfahren ist es, möglichst alle Bestandteile des Quellcodes mindestens einmal zur Ausführung zu bringen 26. Ebenso wie der vollständige Test bei den Blackboxverfahren ist allerdings auch eine vollständige Prüfung aller Anweisungen, Pfade oder Kanten in der Praxis nur schwer umzusetzen, da z.b. durch Schleifen oder Wiederholungen sehr viele mögliche Ausführungen berücksichtigt werden müssten 27. Wichtig bei der Ausführung eines 23 Vgl. Spillner, S Liggesmeyer, S Vgl. Spillner, S Vgl. Spillner, S Vgl. Myers, S.9

14 Dynamische / Flexible Testverfahren Whitebox-Tests ist es, die Spezifikation zu beachten. Oftmals wird die grammatikalische Korrektheit eines Quellcodes geprüft, ob das Programm anschließend aber auch das tut, was es dem Kunden nach tun soll, ist eine andere Frage. Im Folgenden sollen die kontrollflussorientierten Varianten der Whitebox-Verfahren näher vorgestellt werden, die in der Praxis von Belang sind. Die datenflussorientierten Verfahren werden im Rahmen dieser Seminararbeit nicht weiter berücksichtigt Anweisungsüberdeckung Bei der Anweisungsüberdeckung (auch C0-Test genannt) stehen die Anweisungen bzw. Statements des Quellcodes im Vordergrund. Hier müssen Testfälle konstruiert werden, die möglichst viele der vorhandenen Anweisungen zur Ausführung bringen 28. Je mehr Anweisungen berücksichtigt werden, desto höher der so genannte Anweisungsüberdeckungsgrad (Im Idealfall 100%). Zur Ausführung dieses Tests wird der Quellcode in einen Kontrollflussgraphen transformiert, in dem die Anweisungen als Knoten und der Kontrollfluss zwischen den Anweisungen als Kanten dargestellt werden. Ein Problem dieser Methode ist, dass eine hundertprozentige Anweisungsüberdeckung häufig schwer zu erreichen ist (z.b. bei seltenen Ausnahmebedingungen) und sie als Qualitätsmaß nicht sonderlich aussagekräftig ist 29. Deshalb besitzt der Anweisungsüberdeckungstest in der Praxis nur eine untergeordnete Bedeutung Zweigüberdeckung Einen Schritt weiter als der Anweisungsüberdeckungstest geht der Zweigüberdeckungstest. Experten sehen den Zweigüberdeckungstest als Minimalkriterium im Bereich des 28 Vgl. Spillner, S Vgl. Spillner, S Vgl. Liggesmeyer, S.86

15 Dynamische / Flexible Testverfahren kontrollflussorientierten Testens 31. In der Literatur findet man ihn auch unter dem Namen C1-Test oder branch coverage test. Wie der Name schon vermuten lässt, ist das Ziel bei diesem Test die Abdeckung möglichst aller Zweige des Programms, d.h. es wird geprüft, ob alle codierten Bedingungen des Programms korrekt ausgeführt werden 32 (logische Prüfung). Bei Durchführung dieses Tests kann es durchaus vorkommen, dass einzelne Zweige einer Schleife mehrfach durchlaufen werden. Dies spielt bei der Bewertung mit Hilfe des C1-Maßes (Zweigüberdeckung in Prozent) allerdings keine Rolle, wichtig ist hier nur, dass ein Zweig überhaupt ausgeführt wird 33. Im Vergleich zur Anweisungsüberdeckungsmethode sind bei diesem Verfahren wesentlich mehr Testfälle erforderlich, abhängig von der Struktur des Programms. Ein Vorteil ist z.b., dass leere Zweige erkannt werden können. Schwächen zeigt diese Methode bei objektorientierter Software, da hier die eigentliche Komplexität in den Beziehungen zwischen den Klassen liegt und deshalb zusätzliche Überdeckungskriterien erforderlich sind. In der Praxis hat sich gezeigt, dass eine Zweigüberdeckung von 100% angestrebt werden sollte und dass neben allen Anweisungen auch alle möglichen Verzweigungen innerhalb des Kontrollflusses eines Programms getestet werden sollten, damit der Test als aussagekräftig angesehen werden kann Bedingungsüberdeckung Im Gegensatz zum Zweigüberdeckungstest ist der Bedingungsüberdeckungstest in der Lage, auch komplexe Bedingungen, die aus mehreren Teilbedingungen bestehen können, interpretieren und testen zu können 35. Je nach Komplexität der Anforderungen können verschiedene Formen des Bedingungsüberdeckungstests zur Anwendung kommen, z.b. der einfache Bedingungsüberdeckungstest (C2-Test) oder der 31 Vgl. Liggesmeyer, S Vgl. Spillner, S Vgl. Spillner, S Vgl. Spillner, S Vgl. Spillner, S.149

16 Dynamische / Flexible Testverfahren Mehrfachbedingungsüberdeckungstest (C3-Test). Die Erläuterung dieser Methoden würde leider den Rahmen dieser Seminararbeit sprengen, weshalb sie an dieser Stelle nur erwähnt sein sollen Pfadüberdeckung Der Pfadüberdeckungstest (path coverage test oder C4-Test) ist eine der umfassendsten kontrollflussorientierten Testtechniken 36. Er erfordert [...] die Ausführung aller unterschiedlichen Pfade des zu testenden Software-Moduls. 37 Als Pfad wird eine einmalige Sequenz von Knoten des Kontrollflussgraphen angesehen. Da der Test sehr komplex ist, umfasst er alle bislang vorgestellten kontrollflussorientierten Testtechniken, mit Ausnahme des Bedingungsüberdeckungstests. Bei Programmen mit vielen Schleifenkonstrukten zeigt sich die praktische Untauglichkeit dieser Methode, da relativ schnell eine astronomisch hohe Anzahl an möglichen Pfaden zu Tage treten würde 38. Zur Vereinfachung wurden deshalb andere Varianten eines solchen vollständigen Pfadüberdeckungstests geschaffen, z.b. der Boundary-Interior-Pfadüberdeckungstest oder der strukturierte Pfadüberdeckungstest. Diese Varianten lösen das Problem der Pfadexplosion, indem sie versuchen die Anzahl der Schleifendurchläufe einzugrenzen. Der Boundary-Interior-Pfadüberdeckungstest unterteilt die Pfade eines Programms beispielsweise in drei verschiedene Klassen, Äußere Pfade, Grenzpfade und Innere Pfade. Es können dann entsprechende Testfälle generiert werden, die die Anzahl der zu durchlaufenden Pfade deutlich reduzieren. Beim strukturierten Pfadüberdeckungstest kann der Tester auswählen, wie detailliert er Schleifen durchlaufen möchte. Dazu wählt er einen Wert für die Konstante k, die dann die Anzahl der zu durchlaufenden Schleifeniterationen angibt. Für k=2 entspricht der Test dem Boundary-Interior-Pfadtest. 36 Vgl. Liggesmeyer, S Liggesmeyer, S Vgl. Hoffmann, S.210f

17 Dynamische / Flexible Testverfahren Allgemeine Bewertung der kontrollflussorientierten Whitebox-Verfahren In der Praxis ist das kontrollflussorientierte Testen von enormer Bedeutung 39. Wie unter bereits beschrieben wird der Zweigüberdeckungstest oftmals als notwendige Minimalbedingung angesehen. Je nach Branche der einzusetzenden Software weichen die Anforderungen teilweise voneinander ab. Abbildung 1 zeigt die verschiedenen Formen der kontrollflussorientierten Testverfahren in ihrer hierarchischen Subsumption, wobei der Anweisungsüberdeckungstest die geringste und der vollständige Pfadüberdeckungstest die höchste Komplexität aufweist. Bei der Verwendung von Whitebox-Tests sollte man sich im Klaren sein, dass nur die Funktionalität der bereits programmierten Module getestet werden kann. Der Test gibt keinen Aufschluss darüber, ob die vom Kunden gewünschten Anforderungen auch komplett implementiert wurden. Abbildung 1: Subsumptionshierarchie der kontrollflussorientierten Testtechniken Vgl. Liggesmeyer, S Grafik entnommen aus Liggesmeyer, S.139

18 Zusammenfassung / Fazit Zusammenfassung / Fazit Wie wir sehen können, wurden im Bereich der dynamischen Softwareprüfung diverse Methoden und Techniken entwickelt, um dem Softwareentwickler zu helfen, ein qualitativ hochwertiges Produkt erstellen zu können. Um zuverlässige Aussagen über die Qualität einer Software machen zu können ist es ratsam, sowohl funktionsorientierte (Blackbox) als auch strukturorientierte (Whitebox) Testmethoden anzuwenden. Je nach Komplexität der erstellten Software eignen sich die verschiedenen Subformen der Bereiche mehr oder weniger. Wie bereits beschrieben wird im Bereich der strukturorientierten Methoden der Zweigüberdeckungstest von Experten als Minimalkriterium angesehen. Ein strukturierter Pfadtest oder ein Mehrfach- Bedingungsüberdeckungstest sind in der Praxis gerade für kleinere Projekte oftmals zu komplex, als dass sich ihre Anwendung unter betriebswirtschaftlichen Gesichtspunkten lohnen würde. Wie viel Geld, Zeit und Ausdauer in das Testen einer Software gesteckt wird, hängt letztendlich natürlich vom Auftraggeber bzw. vom Einsatzgebiet der Software ab. Die Zuverlässigkeit eines Programms zur Flugzeugsteuerung beispielsweise kann unter Sicherheitsgesichtspunkten nicht gründlich genug getestet werden, da von ihrer Funktionalität ggfs. Menschenleben abhängen. Auch im Bereich der Blackbox-Verfahren gibt es unterschiedliche Methoden, deren Wirksamkeit von der Struktur des zu testenden Programms abhängt. Bei einer Finanztransaktionssoftware, mit der große Geldbeträge gehandelt werden, wäre z.b. eine umfangreiche Grenzwertanalyse mit sinnvoll gewählten Äquivalenzklassen sehr zu empfehlen. Software, die auf lange Laufzeiten und Stabilität ausgelegt ist, sollte dringend mit Hilfe zustandsbasierter Methoden getestet werden, um einen Ausfall bzw. einen Stillstand vermeiden zu können. Zusammenfassend lässt sich sagen, dass es keine generellen Empfehlungen geben kann, welche Tests zwingend durchgeführt werden müssen. Dies ist von Fall zu Fall verschieden und hängt maßgeblich von der Struktur der Software ab.

19 Anhang - I - Anhang

20 Literaturverzeichnis - II - Literaturverzeichnis Andreas Spillner, Tilo Linz Basiswissen Softwaretest, 3. Auflage, dpunkt-verlag, Heidelberg 2005, ISBN: Dirk W. Hoffmann Software-Qualität, Springer-Verlag, Berlin 2008, ISBN: G..J. Myers Helmut Balzert Peter Liggesmeyer Methodisches Testen von Programmen, 7. Auflage, Oldenbourg Verlag, München Wien 2001, ISBN: Lehrbuch der Software-Technik, 2. Auflage, Spektrum Akademischer Verlag, Heidelberg, Berlin 2000, ISBN: Software-Qualität Testen, Analysieren und Verifizieren von Software, 2. Auflage, Spektrum Akademischer Verlag, Heidelberg 2009, ISBN: Torsten Cleff Basiswissen Testen von Software, W3L GmbH, Herdecke 2010, ISBN:

21 Eidesstattliche Erklärung Eidesstattliche Erklärung Hiermit versichere ich, dass die vorliegende Arbeit von mir selbständig und ohne unerlaubte Hilfe angefertigt worden ist, insbesondere dass ich alle Stellen, die wörtlich oder annähernd wörtlich aus Veröffentlichungen entnommen sind, durch Zitate als solche gekennzeichnet habe. Ich versichere auch, dass die von mir eingereichte Version mit der digitalen Version übereinstimmt. Weiterhin erkläre ich, dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat. Ich erkläre mich damit einverstanden, dass die Arbeit der Öffentlichkeit zugänglich gemacht wird. Ort, Unterschrift: Name