Technische Universität Berlin SS

Transkript

1 Seminar Softwaretechnik Automatisiertes spezifikationsbasiertes Testen von Software Technische Universität Berlin SS 2003 Veranstalter: Betreuer: Seminarthema: Stefan Jänichen Mario Friske Codeabdeckung Schriftliche Ausarbeitung: Sadik Akinci 1

2 Inhaltsverzeichnis Abbildungsverzeichnis Einleitung Eigenschaften und Ziele des kontrollflussorientierten Testens Anweisungsüberdeckungstest (statement coverage) Zweigüberdeckungstest (branch coverage) Bedingungsüberdeckungstest (condition coverage) Techniken für den Test von Schleifen Zusammenfassung und Bewertung Literaturverzeichnis Abbildungsverzeichnis Abbildung 1 Typischer Kontrollflussgraph... 5 Abbildung 2 Beispiel: Anweisungsüberdeckung... 7 Abbildung 3 Beispiel: Zweigüberdeckungstest... 9 Abbildung 4 Beispiel: Einfacher Bedingungsüberdeckungstest Abbildung 5 Beispiel: Minimaler Mehrfach-Bedingungsüberdeckungstest Abbildung 6 Beispiel: Pfadklassen boundary interior-test Abbildung 7 Subsumptionshierarchie der kontrollflussorientierten Testmethoden

3 1. Einleitung In dieser Ausarbeitung werden Testtechniken beschrieben, die die Vollständigkeit des Tests anhand der Abdeckung des Software- Quellcodes beurteilen. Diese Techniken fordern die Ausführung aller Anweisungen, Zweige, Bedingungen oder Pfade der zu testenden Software. Um die Testtechniken bewerten zu können, muss für eine ausreichen Codeabdeckung gesorgt werden. Die Codeabdeckung wird durch die Instrumentalisierung des Quellcodes gemessen. Anhand der kontrollflussorientierten oder auch strukturorientierten Testtechniken soll der Begriff der Codeabdeckung näher beschrieben werden. Die kontrollflussorientierte oder auch strukturorientierte Weise des Testens ist eine besondere Technik die Software schon während der Entwicklungsphase zu testen. Darüber hinaus gibt es bei dieser Art des Testens akzeptierte Minimalkriterien, die beim Testen eingehalten werden sollten. Eines dieser minimalen Testverfahren ist der Zweigüberdeckungstest. Bei besonders kritischen Anwendungsbereichen muss die Prüfung mit Hilfe des Bedingungsüberdeckungstest vollzogen werden, da bestimmte kontrollflussorientierte Testtechniken nicht die notwendigen Grundlagen besitzen, um insbesondere einzelne Module ausreichend zu testen. 3

4 2. Eigenschaften und Ziele des kontrollflussorientierten Testens Bei den kontrollflussorientierten Testmethoden wird die Testvollständigkeit anhand der Abdeckung der Kontrollstruktur bewertet. Die kontrollflussorientierten Testtechniken und die datenflussorientierten Testtechniken gehören zu der Gruppe der strukturorientierten Testmethoden, daher besitzen diese deren Stärken und Schwächen. Auf die datenflussorientierten Testtechniken wird in dieser Ausarbeitung nicht weiter eingegangen. Kontrollflussorientierte Testmethoden geben, wie alle strukturorientierten Testmethoden, keine Regel für die Erzeugung von Testfällen an. Aus diesem Grund ist es zwingend notwendig auf eine entsprechende Abdeckung der Struktur zu achten. Kontrollflussorientierte Testmethoden betrachten die Struktur des Quellcodes. Ohne Beachtung der Auslastungsfehler werden die verschiedenen Verarbeitungslogiken betrachtet, die in der Software als Anweisung, Zweige, Bedingungen, Schleifen oder Pfade repräsentiert werden. Dies ist ein Nachteil, welcher getrennt betracht werden muss. Ein weiterer Nachteil ist, dass nicht realisierte jedoch spezifizierte Funktionen nur zufällig erkannt werden. Für diese Funktion ist nämlich kein Überdeckungscode vorhanden. 1 1 Vgl. Peter Liggesmeyer, S. 80 ff. 4

5 Der Kontrollflussgraph bildet die Grundlage für die kontrollflussorientierten Testmethoden. Speziell bei Programmen, welche mit imperativen Programmiersprachen geschrieben worden sind, kann man immer einen Kontrollflussgraphen erstellen. 2 Wie in unserem Beispiel in Abbildung 1. In dieser Abbildung sehen wir einen Kontrollflussgraphen für ein in Java Code geschriebenen Modul. Das Modul soll in einem Intervall von 1 bis 10 die Anzahl der Primzahlen ermitteln. Als Eingabe erhält sie den Startpunkt c im Intervall und die Variable durchlaufanz, womit die Durchlaufanzahl der While-Schleife kontrolliert werden kann. Start S n 1 Int c = 5 Int durchlaufanz = 0 Int primanz = 0 Zweig, Kante Anweisung, Knoten n 2 n 3 while (c>=0 && c<=10 && durchlaufanz<10) { durchlaufanz = durchlaufanz + 1; if (c == 1 c == 2 c == 3 c == 5 c == 7) { n 4 primanz = primanz + 1; n 5 } c = c+1; Ende E } Abbildung 1 Typischer Kontrollflussgraph 3 2 Vgl. Glenford J. Myers S Vgl. Peter Liggesmeyer, S

6 3. Anweisungsüberdeckungstest (statement coverage) Anweisungsüberdeckungstests, auch C o -Test genannt, sind die am einfachsten anwendbaren kontrollflussorientierten Testmethoden. Mit den Anweisungsüberdeckungstests wird sichergestellt, dass kein toter Code, Anweisungen die niemals durchlaufen werden, im Programm existiert. Dies ist ein notwendiges Kriterium um sicherzugehen, dass jede Anweisung auf Fehler untersucht wird. Der Sinn des Anweisungsüberdeckungstests ist die mindestens einmalige Ausführung aller Anweisungen in einem Programm. Ist dies gewährleistet spricht man von einer völligen Anweisungsüberdeckung. Wie in Abbildung 2 zu erkennen ist, werden alle Anweisungen mindestens einmal ausgeführt, wenn die While-Schleife einmal durchlaufen wird. Unser Testpfad enthält zwar alle Knoten, aber nicht alle Kanten. Die Kante (n3,n5) wird im optionalem Else-Teil nicht ausgeführt. Genau dieser Fall wird im Zweigüberdeckungstest betrachtet. Durch die Einführung der Zähler kann beim automatisierten Testen kontrolliert werden, ob jede Anweisung ausgeführt wurde, indem man sich die Werte nachdem Testdurchlauf ausgeben lässt. Anweisungsüberdeckungstests werden selten als Haupttestwerkzeug in einem Vollständigkeitstest eingesetzt, denn dafür sind sie i. d. R. zu schwach. 4 4 Vgl. Peter Liggesmeyer, S. 81 ff. 6

7 Die Messung des Anweisungsüberdeckungsgrad wird wie folgt definiert: Anzahl der ausgeführten Anweisungen C Anweisung = Anzahl aller Anweisungen S n 1 Int c = 5; Int durchlaufanz = 0; Int primanz = 0; Int max = 1; n 2 n 3 while (c>=0 && c<=10 && durchlaufanz <max) { zähler1 ++; durchlaufanz = durchlaufanz + 1; if (c == 1 c == 2 c == 3 c == 5 c == 7) { zähler2 ++; n 4 primanz = primanz + 1; n 5 } c = c+1; Testdurchlauf: S, n 1, n 2, n 3, n 4, n 5, n 2, E E } Abbildung 2 Beispiel: Anweisungsüberdeckung 5 5 Vgl. Peter Liggesmeyer, S

8 4. Zweigüberdeckungstest (branch coverage) Der Zweigüberdeckungstest (C 1 Test) umfasst den Anweisungsüberdeckungstest vollständig. Für den C 1 Test müssen strengere Kriterien erfüllt werden als beim Anweisungsüberdeckungstest. Im Bereich des kontrollflussorientierten Testens wird der Zweigüberdeckungstest als Minimalkriterium angewendet. Mit Hilfe des Zweigüberdeckungstests lassen sich nicht ausführbare Programmzweige aufspüren. Anhand dessen kann man dann Softwareteile, die oft durchlaufen werden gezielt optimieren. Analog zum Anweisungsüberdeckungstest (Abb. 1) wird, um die Codeabdeckung messbar zu machen, der Code in Abbildung 3. durch eine boolesche Hilfsvariable test instrumentiert. Im Gegensatz zum Anweisungsüberdeckungstest durchläuft der Zweigüberdeckungstest alle Zweige. Der Zweigüberdeckungstest wird auch Entscheidungsüberdeckungstest genannt, da die Hilfsvariable mindestens einmal mit dem Wert true und false durchlaufen werden muss. In diesem Fall muss die While-Schleife mindestens zweimal durchlaufen werden. Mit dem Durchlaufen der Zweige wird auch sichergestellt, dass jeder Knoten (Anweisung) mindestens einmal ausgeführt wird. Somit wird auch das Kriterium für den Anweisungsüberdeckungstest erfüllt. Daher subsumiert der Zweigüberdeckungstest den Anweisungsüberdeckungstest Vgl. Peter Liggesmeyer, S Vgl. Thomas Kühne, S. 27 ff. 8

9 S n 1 Int c = 5; Int durchlaufanz = 0; Int primanz = 0; Int max = 2; Bool test = false; n 2 while (c>=0 && c<=10 && durchlaufanz<max) { durchlaufanz = durchlaufanz + 1; n 3 n 4 if (c == 1 c == 2 c == 3 c == 5 c == 7) { test = true; primanz = primanz + 1; Testdurchlauf: S, n 1, n 2, n 3, n 4, n 5, n 2, n 3, n 5, n 2, E. n 5 E } c = c+1; } Abbildung 3 Beispiel: Zweigüberdeckungstest 8 Schwierig ist es für den Zweigüberdeckungstest Testfälle zu generieren, wo Betriebssystemzustände oder Dateikonstellationen getestet werden müssen. 9 Weiterhin ist diese Technik des Testens zum Testen von Schleifen und zusammengesetzter Entscheidungen nicht geeignet, da weder Kombinationen von Zweigen, noch kompliziert aufgebaute Entscheidungen in Betracht gezogen werden können. Hierfür müssen Erweiterungen herangezogen werden. 8 Vgl. Thomas Kühne, S Vgl. Thomas Kühne, S

10 Weitaus problematischer erweist sich das Zweigüberdeckungsmaß. In dem Fall, dass alle Knoten gleich bewertet sind, verzichtet man auf die Betrachtung der Abhängigkeiten untereinander. Dadurch entsteht kein linearer Zusammenhang zwischen der erreichten Überdeckungsrate und dem Verhältnis zwischen der Anzahl der dazu benötigten Testfälle und der eigentlichen Anzahl der Testfälle, die für die 100 prozentige Zweigüberdeckung notwendig sind. Um den Zweigüberdeckungstest zu verbessern, wird ein Zweig, der abhängig von einem anderen Zweig ist, nicht weiter berücksichtigt. Die Zweige, die nicht abhängig sind, werden als primitiv bezeichnet. 10 Daher ergibt sich für das Überdeckungsmaß: Anzahl der ausgeführten primitiven Zweige C primitiv = Anzahl aller primitiven Zweige 10 Vgl. Peter Liggesmeyer, S. 86 ff. 10

11 5. Bedingungsüberdeckungstest (condition coverage) Der Bedingungsüberdeckungstest (C 2 -Test) betrachtet die logische Struktur von Entscheidungen in einem Programm. Es existieren unterschiedliche Formen des Bedingungsüberdeckungstests. Die schwächste Form ist der einfache Bedingungsüberdeckungstest (simple condition coverage test). Er beinhaltet im Allgemeinen nicht die Methoden der Anweisungs- und Zweigüberdeckungstests. Der Zweigüberdeckungstest ist nur dann im einfachen Bedingungsüberdeckungstest enthalten, wenn die Entscheidungen unvollständig evaluiert wurden. Somit ist der Zweigüberdeckungstest mit den Verknüpfungen UND, ODER und NICHT im einfachen Bedingungsüberdeckungstest integriert Bei dem einfachen Bedingungsüberdeckungstest muss jede atomare Bedingung mindestens einmal mit true und false durchlaufen werden. Für unser Beispiel muss dafür die Überprüfung der Primzahlen von der EINS aus angefangen bis zur SIEBEN ausgeführt werden (s. Abb. 4). Int c = 1; Int durchlaufanz = 0; Int primanz = 0; Int max = 8; while (c>=0 && c<=10 && durchlaufanz< max) { durchlaufanz = durchlaufanz + 1; if (c == 1 c == 2 c == 3 c == 5 c == 7) { primanz = primanz + 1; } c = c+1; } Abbildung 4 Beispiel: Einfacher Bedingungsüberdeckungstest 11 Vgl. Peter Liggesmeyer, S. 89 ff. 12 Vgl. Thomas Kühne, S

12 Der Mehrfach-Bedingungsüberdeckungstest (multiple condition coverage test) subsumiert zwar den Zweigüberdeckungstest, dieser ist aber abhängig von der Art und Weise der Evaluierung der Entscheidung. Daher ist der Mehrfach-Bedingungsüberdeckungstest als alleinige Anforderung nicht ausreichend. Ziel dieser Form des Testens ist es alle Variationen der atomaren Bedingungen zu bilden. 13 Dies gelingt jedoch nicht immer, z.b. kann in Abb. 4 nicht gleichzeitig c=1 und c=2 gelten. Einen realistischen Kompromiss zu diesen genannten Formen stellt der minimale Mehrfach-Bedingungsüberdeckungstest (minimal multiple condition coverage test) und der modifizierte Bedingungs-/ Entscheidungsüberdeckungstest (modified condition/decision coverage) dar. Der minimale Mehrfach-Bedingungsüberdeckungstest hat im Grunde dieselben Eigenschaften wie die einfache Bedingungsüberdeckung, jedoch muss hier auch die Gesamt-Bedingung wenigstens einmal true und wenigstens einmal false werden. Der Mehrfach- Bedingungsüberdeckungstest bietet unter den Bedingungsüberdeckungstests den umfassendsten Überdeckungstest. Daher haben diese Arten des Testens einen entsprechenden Testaufwand. Der minimale Mehrfach-Bedingungsüberdeckungstest subsumiert den Zweigüberdeckungstest. Damit auch in unserem Beispiel die Gesamt- Bedingungen die verschiedenen Werte annehmen können, müssen die Eingaben c und max gut ausgewählt werden (s. Abb. 5). Der modifizierte Bedingung-/Entscheidungsüberdeckungstest zielt auf das Testen der Logik von zusammengesetzten Entscheidungen ab. Es entsteht ein linearer Testaufwand, bezogen auf die Anzahl der atomaren Teilentscheidungen. Für den Test einer Entscheidung mit n Teilentscheidungen sind mindestens n+1 Testfälle erforderlich. 13 Vgl. Andreas Zeller, S

13 Bei unvollständigen Evaluationen von Eigenschaften ist es hier notwendig, die Anforderungen abzuschwächen. Um ein einigermaßen anständiges Testmaß zu erreichen, wird der Quotient aus der Anzahl der getesteten Objekte (Anweisung, Zweige, atomare Teilentscheidung) und der Anzahl der als testbar vorausgesetzten vorhandenen Objekte gebildet. 14 Der Bedingungsüberdeckungstest ist für den Test von komplizierten Verarbeitungslogiken besonders gut geeignet, da er einen guten Kompromiss aus Leistung und Testaufwand bietet. Eine gewisse Problematik stellen die zusammengesetzten Entscheidungen bei dem Bedingungsüberdeckungstest dar. Aus Effizienzgründen können sie von verschiedenen Compilern unterschiedlich umgesetzt werden. 15 Int c Int max c>=0 c<=10 durchlaufanz<max Bedingung A Testfälle F T T T T T T T T T T T F T T T T T T T T T F T T T T F T T F F T T T T Merke: Jede atomare Bedingung und jede Gesamt-Bedingung muss wenigstens einmal den Wert true und wenigstens einmal den Wert false annehmen. c == 1 c == 2 c == 3 c == 5 c == 7 Bedingung B - F T - - F F F F - F F - - F F F T - F F - - T F F F - F F - - F T F F - F F - - F F T F - F T - - T T T T Abbildung 5 Beispiel: Minimaler Mehrfach-Bedingungsüberdeckungstest 14 Vgl. Peter Liggesmeyer, S. 101 ff. 15 Vgl. Peter Liggesmeyer, S. 109 ff. 13

14 6. Techniken für den Test von Schleifen Schleifen stellen beim Testen einer Software erhebliche Probleme dar, da sie oft eine extrem hohe Anzahl von Programmpfaden verursachen. Diese kann man nicht mit einfachen Pfadüberdeckungstests (path coverage) überprüfen. Der Pfadüberdeckungstest ist eine sehr erschöpfende Testtechnik in der Familie der kontrollflussorientierten Testmethoden. Er verlangt die Prüfung aller möglichen Eingaben in allen Betriebssituationen und ist somit ein sehr erschöpfender Test, welcher i. d. R. nicht praktikabel ist. Dieser verlangt die Prüfung aller möglichen Eingaben in allen Betriebssituationen. Hier finden die Verfahren des strukturierten Pfadtests (boundary) und Grenze-Inneres-Überdeckung (boundary interior coverage) ihren Platz. Die Pfade werden in Äquivalenzklassen unterteilt und es werden nur Stellvertreter aus diesen Klassen von Pfaden ausgeführt. Da der boundary interior-test ein Spezialfall des strukturierten Pfadtests ist, wird nur dieser in betracht gezogen. Der vollständige Zweigüberdeckungstest gilt für beide als Nebenbedingung (s. Abb. 6). 16 Der boundary interior coverage unterscheidet die Schleifenausführung in: keine, eine und mindestens zwei Schleifenausführungen. So entstehen beim Testen drei Pfadklassen: 1. Pfade, die die Schleifen nicht ausführen, diese sind dann leer. ohne Schleifen 2. Pfade, die die Schleife zwar betreten, die jedoch nicht wiederholen. boundary 3. Pfade, die die Schleifen mindestens zweimal ausführen. interior Vgl. Peter Liggesmeyer, S. 112 ff. 17 Vgl. Peter Liggesmeyer, S. 116 ff. 14

15 Im Vergleich zum Zweigüberdeckungstest hat der strukturierte Pfadtest eine viel höhere Erfolgsquote Fehler auf zu spüren. Während Fehler beim Zweigüberdeckungstest unerkannt bleiben, werden diese i. d. R. vom strukturierten Pfadtest sicher aufgespürt. Für den boundary interior-test ist dieselbe Leistung zu erwarten, da er ein Spezialfall des strukturierten Pfadtests ist. Der strukturierte Pfadtests ist zwar ein sehr mächtiges Testverfahren, aber auch ein sehr aufwendiges, da die Durchführung sehr eingeschränkt abläuft. Sie hat eine sehr hohe Bedeutung im Zusammenhang mit fehlerorientierten Testansätzen. S n 1 Kategorie Bezeichnung Pfad 1. ohne Schleifen n 2 A 0 B 0 n 1 n 2 n 3 n 4 n 8 n 1 n 3 n 4 n 8 n 3 n 4 2. boundary test A 1a A 1b B 1a B 1b n 1 n 2n 3n 4n 5n 6n 7 n 4 n 8 n 1 n 2 n 3 n 4 n 5 n 7 n 4 n 8 n 1 n 3 n 4 n 5 n 6 n 7 n 4 n 8 n 1 n 3 n 4 n 5 n 7 n 4 n 8 n 5 n 6 n 7 3. interior test A 2c A 2d A 2e A 2f B 2c B 2d B 2e B 2f n 1 n 2 n 3 n 4 n 5 n 6 n 7 n 4 n 5 n 6 n 7 n 4 (n 5 [n 6] n 7 n 4) i n 8 n 1 n 2 n 3 n 4 n 5 n 6 n 7 n 4 n 5 n 7 n 4 (n 5 [n 6] n 7 n 4) i n 8 n 1 n 2 n 3 n 4 n 5 n 7 n 4 n 5 n 6 n 7 n 4 (n 5 [n 6] n 7 n 4) i n 8 n 1 n 2 n 3 n 4 n 5 n 7 n 4 n 5 n 7 n 4 (n 5 [n 6 ] n 7 n 4 ) i n 8 n 1 n 3 n 4 n 5 n 6 n 7 n 4 n 5 n 6 n 7 n 4 (n 5 [n 6 ] n 7 n 4 ) i n 8 n 1 n 3 n 4 n 5 n 6 n 7 n 4 n 5 n 7 n 4 (n 5 [n 6 ] n 7 n 4 ) i n 8 n 1 n 3 n 4 n 5 n 7 n 4 n 5 n 6 n 7 n 4 (n 5 [n 6 ] n 7 n 4 ) i n 8 n 1 n 3 n 4 n 5 n 7 n 4 n 5 n 7 n 4 (n 5 [n 6 ] n 7 n 4 ) i n 8 I mit i? 0 n 8 Abbildung 6 Beispiel: Pfadklassen boundary interior-test Vgl. Peter Liggesmeyer, S

16 7. Zusammenfassung und Bewertung Trotz hoch entwickelten Testtechniken sollte man die Codeabdeckung nicht außer Betracht lassen. Mit Hilfe der Messung der Codeabdeckung kann man nicht nur sicher sein, dass der gesamte Quelltext abgedeckt wird, sondern dies auch beweisen, z.b. durch die Ausgabe von Variablen, welche die Ausführung der Schleifen zählen. Die Instrumentierung unterscheidet sich bei den Testtechniken nicht gravierend, sie wird i. d. R. durch die Implementierung von Extracode realisiert. Die kontrollflussorientierten Testtechniken sind unverzichtbar, wenn es darum geht, eine Software genügend zu testen. Der Zweigüberdeckungstest, der den Anweisungsüberdeckungstest subsumiert, ist ein allgemein akzeptiertes Minimalkriterium des strukturorientierten Softwaretests. Bei einer unvollständigen Zweigüberdeckung gilt der Test als nicht hinreichend und ist im Sinne des Testens nicht zu gebrauchen. 19 Der Testwerkzeugmarkt hat hierauf reagiert und stellt heute eine große Auswahl von kontrollflussorientierten Testwerkzeugen zur Verfügung. Es gibt Test-Tools wie PureCoverage von Rational. Mit ihr lässt sich abmessen, wie gut die Qualität der Testdurchführung war. Die Instrumentierung geschieht durch das hinzufügen von Extracode (z.b. Schleifenzähler). Rational verwendet hierfür die Object Code Insertion (OCI) Technologie Vgl. Peter Liggesmeyer, S Handbuch von Rational S

17 Mit Hilfe dieses Test-Tools können einige Eigenschaften ermittelt bzw. gemessen werden, wie z.b.: Die Höhe des Prozentsatzes von dem getesteten Quellcode. Welche Funktion, Methoden, Verfahren oder Teile des Codes zugänglich oder unzugänglich waren. Ob ungetestete Zeilen im Quellcode existieren. Die Prüfung kann bei Rational auf drei verschiedenen Ebenen vollzogen werden. Bei der Zeilen-Ebene (Line-level) wird während des Testdurchlaufs gemessen, wie welche Zeile durchlaufen wird (sehr detailliert und erschöpfend). Als Alternative bietet sich die Funktions-Ebene (Function-level) des Prüfens an. Hier wird gemessen wie oft die Funktion in einem Testdurchlauf ausgeführt wurde. Die Funktions-Ebene ähnelt der Zeilen- Ebene. Sie ist aber nur dann empfehlenswert, wenn nach keinem exakten Ergebnis, sondern nach einem praktikablen Lösungsweg gefragt ist. Die Time-Ebene befasst sich mit dem Sammeln der Daten für zeitgesteuerte Funktionen. Hier wird die Anfangs- und Endzeit der Funktion gestoppt. Somit wird festgestellt, wie lange es dauert eine Funktion zu durchlaufen. Diese Ergebnisse können jedoch durch andere Prozessorauslastungen, die zur selben Zeit ausgeführt werden, verfälscht werden Handbuch von Rational S. 91 ff. 17

18 Die strukturorientierten Testtechniken sind aus pragmatischen Gründen i. d. R. kontrollflussorientierte Techniken. Bei der Auswahl der Testmethoden gilt es die Subsumptionshierarchie der kontrollflussorientierten Testmethoden zu beachten (s. Abb. 7). Pfadüberdeckungstest Mehrfach- Bedingungsüberdeckungstest Modifizierter Bedingung-/ Entscheidungsüberdeckungstest Minimaler Mehrfach- Bedingungsüberdeckungstest Modifizierter boundary interior- Test Bedingung-/ Entscheidungsüberdeckungstest Zweigüberdeckungstest Anweisungsüberdeckungstest Einfacher Bedingungsüberdeckungstest Abbildung 7 Subsumptionshierarchie der kontrollflussorientierten Testmethoden Vgl. Peter Liggesmeyer, S

19 8. Literaturverzeichnis Buch: [1] Peter Liggesmeyer: Software-Qualität Testen, Analysieren und Verifizieren von Software Spektrum Akademischer Verlag 2002 [2] Glenford J. Myers: Methodisches Testen von Programmen 4. Auflage Oldenbourg Verlag, München/Wien 1991 WWW: [3] Thomas Kühne: Programmiermethodik Qualitätssicherung

20 [6] Andreas Zeller: Software-Test: Strukturtest Lehrstuhl Softwaretechnik Universität des Saarlandes, Saarbrücken 2003 Handbuch: [7] Rational Software Corporation: Rational PurifyPlus Rational Purify Rational PureCoverage Rational Quantify Getting Started (VERSION: PART NUMBER: )