Sie sind auf Seite 1von 11

Fachhochschule Kln University of Applied Sciences Cologne Fakultt fr Informatik und Ingenieurwissenschaften

Ausarbeitung zu dem Thema

Software-Testverfahren: der Blackbox Test

int int func (int x, int y) int int

Seminar Qualittssicherung WS 02/03 Dozent: Prof. Dr. Mario Winter Dipl.-Inf. Frank Dopatka 1102 1050 1 1

Inhaltsverzeichnis
Seite 1. 2. 3. 4. 5.
5. 5. 5. 5. 5. 1. 2. 3. 4. 5.

Vorwort und Motivation Allgemeine Testregeln Was ist Blackbox ? Problem des vollstndigen Eingabetests Testtechniken
Funktionsabdeckung quivalenzklassenbildung Grenzwertanalyse intuitive Testfallermittlung Smoke-Test

3 3 5 6 7
7 8 8 9 9

6. 7. 8.

Resmee Abbildungsverzeichnis Literaturverzeichnis und Quellen

10 11 11

Software-Testverfahren: der Blackbox Test

Seite 3

1.

Vorwort und Motivation

In dieser Ausarbeitung mchte ich Verfahren und Techniken vorstellen, mit denen man in der Lage ist, erstellten Sourcecode auf seine korrekte Funktionalitt zu prfen. Da ich in der MasterVorlesung Qualittssicherung bereits Einblicke in die strukturellen Whitebox-Testverfahren erhalten habe, ist das Ziel dieser Ausarbeitung die Vorstellung eines weiteren, ergnzenden Verfahrens. Die Wahl dieses Themas ist begrndet durch mein 8-semestriges Studium der Technischen Informatik und seit dem Jahre 2001 zustzlich durch die gewerbliche Programmierung. Daher sind fr mich Verfahren interessant, mit denen mein erzeugter Quellcode, welcher ja dem Kunden als Produkt bergeben wird und fr dessen Funktionalitt ich haftbar bin, mglichst leicht auf seine korrekte Funktionsweise getestet werden kann. Im zweiten Kapitel dieser Ausarbeitung mchte ich zunchst auf allgemein gltige Regeln fr das Testen von Software eingehen, die zwar leicht verstndlich sind, jedoch trotzdem oft miachtet werden. Im Anschlu daran fhre ich den Leser in das eigentlich vorzustellende Verfahren ein, dem Blackbox-Testverfahren. Im vierten Kapitel gehe ich auf die Problematik des vollstndigen Eingabetests ein, welche durch die Anwendung gezielter Testtechniken umgangen werden kann. Abschlieend werden in einem Resmee die Vor- und Nachteile des Blackbox-Verfahrens dargelegt.

2.

Allgemeine Testregeln

Bevor man sich mit Testverfahren und deren Anwendung beschftigen kann, mu zunchst ein grundlegendes Verstndnis fr das Testen von Software gelegt werden. Dieses Verstndnis ist in manchen industriellen Umgebungen, in welchen Software erstellt wird, leider aus meiner eigenen Erfahrung oft nicht gegeben. Dort besteht das Testen darin, da ausschlielich der Entwickler auch fr Tests zustndig ist und whrend der Programmierung seinen Sourcecode selbst testet. Dabei ist zustzlich zu beachten, da sich schon die Erstellung des Sourcecodes unter Zeitdruck aufgrund anstehender Liefertermine vollzieht. Ein Aufschieben des Liefertermins ist undenkbar, die vorherige Planung von Testroutinen wrde lediglich Geld kosten. Zu diesem Thema wurden nach Georg Erwin Thaller1 12 erprobte Regeln fr das Testen von Software erstellt, welche nun nacheinander aufgezhlt und erlutert werden. 1. Ein Programmierer sollte nie versuchen, sein eigenes Programm zu testen. 2. Die mit Entwurf und Programmierung betreute Gruppe sollte nie versuchen, ihr eigenes Programm zu testen. zu 1 und 2: Der Programmierer kennt sein eigenes Programm und er wrde keine oder kaum Fehler finden, die er nicht schon whrend der Programmierung beseitigt htte. Er ist in der Regel nicht in der Lage, sich von seinem Sourcecode in gengendem Mae zu distanzieren, um objektiv testen zu knnen. Das gleiche gilt fr die direkt am Programm beteiligten Personen. Die Tester mssen also generell aus objektiven Personen bestehen, welche idealerweise in keiner Beziehung zur Erstellung des Programms stehen.

Thaller, G. E.: Software-Test. Verifikation und Validation.; 2002; ISBN 3-88229-198-2

Software-Testverfahren: der Blackbox Test


3. Planen Sie keine Tests unter der Annahme, da doch keine Fehler gefunden werden. 4. Testen ist das Ausfhren eines Programms, um Fehler zu finden.

Seite 4

zu 3 und 4: Kein greres Programm ist fehlerfrei. Erst das Auffinden eines Fehlers im Programm macht es mglich, da dieser Fehler auch beseitigt werden kann. Es soll daher kein Test um des Testens Willens - meist, um das eigene Gewissen zu beruhigen - durchgefhrt werden. 5. Das Testen von Software ist eine kreative und intellektuell herausfordernde Ttigkeit. zu 5: Mit dieser Regel wird verdeutlicht, da ein hastiges Testen kurz vor der Auslieferung des Produktes meist unsinnig ist. Statt dessen mssen Tests bereits whrend der Erstellung des Programms geplant werden. Testen darf nicht unter Zeitdruck erfolgen. 6. Die Ergebnisse der Tests mssen grndlich untersucht werden. 7. Vor dem Test mssen die erwarteten Ergebnisse definiert werden. zu 6 und 7: Ein Testen ist nur dann sinnvoll, wenn man sich die Ergebnisse ansieht und mit den Soll-Werten vergleicht. Dies setzt die Existenz von Soll-Werten voraus. Bei einer alleinigen Betrachtung der Ergebnisse versucht man meist, diese Ergebnisse zu interpretieren und kommt zu dem fehlerhaften Schlu, da sich das Programm logisch korrekt verhlt. 8. Die Suche nach nicht verlangten Funktionen ist Teil der Tests. zu 8: In der Spezifikation werden die verlangten Funktionen definiert. Erkennt man nicht verlangte Funktionalitt, so kann diese ggf. aus dem Programm wieder entfernt werden. Dadurch verringert man die Zeilen an Sourcecode, mindert dadurch die Fehleranflligkeit und erhht meist die Geschwindigkeit des Programms. Wird die Zusatz-Funktionalitt gewnscht, kann sie bei Bedarf wieder integriert werden, wobei der Kunde unter Umstnden einen Aufpreis zu zahlen hat. 9. Neben gltigen Eingaben sind auch immer ungltige Eingaben zu testen. zu 9: Hier wird die Frage gestellt, was geschieht, falls Eingaben auerhalb der Spezifikation gettigt werden. Aus diesem Punkt werden die Test-Verfahren auf Robustheit eines Programms abgeleitet. Man spricht hier von dem DAU-Test (Dmmster Anzunehmender User), also einem Bediener, welcher sich nicht mit dem Programm auskennt. Die Frage lautet, ob das Programm auf solche Eingaben mit verstndlichen Fehlermeldungen reagiert oder ob eine Funktionsweise mglich ist, welche in Sach- und/oder Personen-Schden enden kann. 10. Testflle sind eine Investition. zu 10: Generell werden Projekte mit knappem Budget geplant, wobei Tests als zustzliche Ausgaben gesehen werden, die man vermeiden kann. Wird jedoch ein Fehler spt erkannt, ist dessen Behebung teuer. Wird er zu spt erkannt, so kann er unter Umstnden Schden verursachen, die nicht mehr zu beheben sind. Aus diesen Grnden sollten Tests als Investition in ein gutes Produkt, und nicht als Kosten gesehen werden.

Software-Testverfahren: der Blackbox Test


11. Fehler sind meist heterogen verteilt.

Seite 5

zu 11: In diesem Punkt wird darauf aufmerksam gemacht, da sich Fehler grundstzlich berall befinden knnen und das man daher von einer heterogenen Verteilung ausgehen mu. Beim Testen mssen also alle Bereiche behandelt werden, auch solche, die als fehlerfrei gelten. 12. Das Testen von Software ist immer ein Experiment. zu 12: Zuletzt mu man noch darauf aufmerksam machen, da jeder Test einer neuen Software anders verluft. Auch wenn man in der Lage ist, mit Testverfahren standardisierte Ablufe zu ermglichen, bleibt jedes zu testende Produkt individuell. Man mu also stets mit neuen und bislang unbekannten Fehlern rechnen.

3.

Was ist Blackbox ?

Mit den in Kapitel 2 dargestellten Regeln im Hinterkopf mchte ich nun das Testverfahren vorstellen, welches das Thema dieser Ausarbeitung darstellt.

Abb.1: Testpyramide2 Bereits in der Vorlesung Qualittssicherung wurden die strukturellen Test, auch WhiteboxTests genannt, vorgestellt. Diese orientieren sich an dem erstellten Sourcecode. Es wird versucht, die korrekte Implementierung eines Moduls mit Hilfe der Anweisungs- und Zweigberdeckung nachzuweisen. Die Blackbox-Testverfahren gehen davon aus, da die Implementierung einer Funktionalitt unbedeutend ist. Statt dessen wird berprft, ob die in der Spezifikation verlangte Funktionalitt erfllt ist. Es handelt sich also um ein Testen auf hherer Ebene, von einzelnen Klassen (Komponententest) ber das Zusammenspiel von Klassen (Integrationstest) bis zum Testen des Gesamt-Systems. Die Blackbox-Tests sind also Funktionstests, welche sich auf die sichtbare Funktionalitt des Programms konzentrieren und nicht auf dessen interne Strukturen. Ein Blackbox-Test ist dabei benutzerorientiert, da er feststellt, ob das Programm berhaupt funktioniert, und nicht, wie es programmiert wurde. Der Tester versucht dabei, Umstnde zu entdecken, bei denen sich das Programm nicht gem den Spezifikationen verhlt. Die Testdaten werden demnach nur aus der Programmspezifikation abgeleitet.

De Wille, E.: Software Test, Methoden und Vorgehensweisen

Software-Testverfahren: der Blackbox Test

Seite 6

Dieser Ansatz ist sehr gut vereinbar mit der objektorientierten Programmierung, da auch hier das Bilden von logischen Modulen, Klassen und Objekten, im Vordergrund steht. Die innere Realisierung der Funktionalitt ist dabei fr den Anwender des Systems o der sogar fr den Entwickler, welcher diese Klassen weiter verwendet, unbekannt. Die frage lautet nun, wie ein solcher Blackbox-Test genau durchgefhrt wird.

Abb.2: Die Testumgebung Dazu wird die zu testende Funktion, bzw. das Modul oder die Klasse, in eine fr den Test generierte Testumgebung gebracht. Die Funktion wird als DUT (Device Under Test) bezeichnet. In einer Datenbank werden die Testflle sinnvoll spezifiziert3, welche aus Input-Werten und SollOutput-Werten bestehen. Jede Kombination aus Input-Werten bilden ein aktives Szenario, welches als Eingabe in das DUT gegeben wird. Dieses erzeugt fr diesen Testfall Ausgaben, also Ist-Output-Werte. Diese knnen automatisiert mit den Soll-Werten fr dieses Szenario verglichen werden. Das Ergebnis wird abschlieend in ein Test-Protokoll geschrieben, welches vom Tester ausgewertet werden mu. Der Aufbau einer Testumgebung kann dabei komplizierter sein als das einzelne DUT selbst.

4.

Problem des vollstndigen Eingabetests

Die notwendigen Testflle werden vom Tester spezifiziert. Es stellt sich nun die Frage, welche Testflle sinnvoll sind. Der erste Gedanke kann nun lauten, da man einfach alle mglichen Input-Kombinationen whlt, damit auf jeden Fall sichergestellt wird, da das DUT fehlerfrei ist. Dies ist jedoch hchstens in Ausnahmefllen mglich. Neben des Problems zur Auswertung des Test-Protokolls existiert ein zweites Problem, welches auch bei der heute zur Verfgung stehenden Rechenleistung nicht behoben ist. Es lt sich einfach an einem Beispiel zeigen. Selbst bei Programmen mit einfachen Ein- und Ausgaben wre nmlich eine sehr groe Anzahl von Testfllen erforderlich, die unmglich alle durchgefhrt werden knnen.

Abb.3: Funktion als Blackbox 4

3 4

s. Kapitel 4 und 5 Beispiel aus: Kahlbrandt, B.: Whitebox und Blackbox Tests; FH Hamburg; 2001

Software-Testverfahren: der Blackbox Test

Seite 7

Betrachtet wird die Funktion func mit zwei 32Bit-Integer-Parametern als Eingabe und einem 32Bit-Integer als Ausgabe. Diese Funktion wird sehr schnell abgearbeitet und bentigt fr eine Ausfhrung lediglich 10 9 s = 1ns . Rechnet man die mglichen Testflle aus, so kommt man bei zwei 32Bit-Integern auf 2 32 2 32 = 2 64 , also auf ca. 1019 Testflle. Fr diesen einfachen Test wrden 10 9 s 1019 = 1010 s , also ca. 317 Stunden bentigt. Dies kann also nicht Sinn und Zweck eines Blackbox-Tests sein. Es gilt also, nicht so zu testen, da die absolute Fehlerfreiheit des Programms garantiert wird, sondern da konomisch getestet wird. Man mu eine Menge von Testfllen in der Art konstruieren, da mglichst viele Fehler gefunden werden. Eine sinnvolle Konstruktion von Testfllen ist die Aufgabe der Qualittssicherung. Dabei existieren jedoch eine Reihe von Vorgehensweisen, die bei der Auswahl der Testflle helfen. Diese Vorgehensweisen werden in Kapitel 5 vorgestellt.

5.

Testtechniken

Die Vorstellung der Testtechniken wird stets in drei Teile unterteilt. Zunchst wird eine Fehlerhypothese aufgestellt. In dieser Behauptung wird auf eine typische Fehlerquelle hingewiesen, welche mit der Testtechnik zumindest teilweise eliminiert werden kann. Im Anschlu daran wird das Ziel definiert, das mit der Testtechnik erreicht werden soll und abschlieend wird die Methode skizziert, mit der das Ziel erreicht wird. In einigen Fllen wird die Vorgehensweise anhand eines Beispiels nher erlutert. 5. 1. Funktionsabdeckung

Hypothese: In der Spezifikation werden Funktionalitten definiert, die von dem Produkt nicht realisiert werden. Dies kann beispielsweise geschehen, indem eine geforderte Teil-Funktionalitt einfach vergessen wird. Ziel: Das Zeil der Funktionsabdeckung besteht darin, Testflle zu identifizieren, mit denen nachgewiesen werden kann, da die jeweilige Funktion vorhanden und ausfhrbar ist. Methode: Anhand der definierten Anforderungen aus der Spezifikation sind die zu testenden Funktionen zu identifizieren. Fr die identifizierten Funktionen werden dann Testflle definiert. Beispiel: Als Beispiel kann der aus der Vorlesung bereits bekannte Stapelspeicher verwendet werden.

Abb.4: Modell des Stapelspeichers5


5

vgl.: Spillner, A.; Linz T.: Basiswissen Softwaretest; dpunkt.Verlag; ISBN 3-89864-178-3, S. 120ff.

Software-Testverfahren: der Blackbox Test

Seite 8

Beispiele fr Funktionsabdeckung ist unter anderem das testweise Initialiseren des Stapels mit anschlieender Prfung auf empty. Dadurch wird die Korrekte Ausfhrung des Konstruktors Stapel geprft. Als zweiter Test kann man push(Hallo) ausfhren und danach den Stapel auf filled prfen und das letzte Element untersuchen. Es mu sich um Hallo handeln. Als drittes kann man pop ausfhren und den Stapel wieder auf empty prfen. Hallo mu dabei zurckgegeben werden. Fhrt man anschlieend delete aus, kann man im RAM des TestRechners nachsehen, ob der Destuktor ~Stapel wirklich alle Programmteile entfernt hat. Auf diese Weise mssen alle Funktionen abgearbeitet werden. 5. 2. quivalenzklassenbildung

Hypothese: In der Spezifikation werden Datenklassen definiert, die von dem Produkt nicht realisiert werden. Dies ist hnlich mit der Funktionsabdeckung, bezieht sich hier jedoch auf eine unterschiedliche Verhaltensweise innerhalb einer Funktion in Abhngigkeit von den gewhlten Input-Werden. Ziel: Die Bildung von quivalenzklassen, welche mit hoher Wahrscheinlichkeit und einer minimalen Anzahl von Testfllen Fehler entdecken. Methode: Die gesamten Eingabedaten eines Programms werden in eine endliche Anzahl von quivalenzklassen so unterteilt, so da mit jedem beliebigen Reprsentanten einer Klasse die gleichen Fehler wie mit jedem anderen Reprsentanten dieser Klasse gefunden werden. Dies hrt sich zunchst einfach an, kann aber bei einer komplexen Funktionalitt durchaus Probleme bereiten, falls die Anzahl der Datenklassen nicht mehr berschaubar ist. Beispiel: Hier wird als Beispiel die Punktevergabe und die Ausgabe von Bugeldbescheiden bei Geschwindigkeitsbertretungen herangezogen. Dabei seien exemplarisch folgende Klassen zu unterscheiden: 10km/h zu schnell bewirkt Bugeld von 10 20km/h zu schnell bewirkt Bugeld von 25 und 1 Punkt 30km/h zu schnell bewirkt Bugeld von 50 und 2 Punkte Es knnen vier quivalenzklassen mit den Input-Testdaten 5km/h, 15km/h, 28km/h und 31km/h gebildet werden. Diese werden in das DUT eingegeben und anschlieend die Ausgabe mit den oben genannten Soll-Werten verglichen. 5. 3. Grenzwertanalyse

Hypothese: Eine besondere Hufigkeit beim Auftreten von Fehlern tritt an den Grenzen von Datenklassen auf, zumeist durch eine unsaubere Definition der Klassen im Sprachgebrauch. Ziel: Testflle zu definieren, mit denen Fehler im Zusammenhang mit der Behandlung der Grenzen von Wertebereichen aufgedeckt werden knnen. Methode: Ausgangspunkt sind die mittels quivalenzklassenbildung ermittelten quivalenzklassen. Im Unterschied dazu wird kein beliebiger Reprsentant der Klasse ausgewhlt, sondern Reprsentanten an den Grenzen der Klassen. Die Grenzwertanalyse ist dabei ein einfacher Zusatztest zu der quivalenzklassenbildung.

Software-Testverfahren: der Blackbox Test

Seite 9

Beispiel: Als Beispiel werden wieder die Punktevergaben und die Bugeldbescheide verwendet: 10km/h zu schnell bewirkt Bugeld von 10 20km/h zu schnell bewirkt Bugeld von 25 und 1 Punkt 30km/h zu schnell bewirkt Bugeld von 50 und 2 Punkte Es werden diesmal drei quivalenzklassen mit den Input-Testdaten 10km/h, 20km/h, 30km/h gebildet. Am Beispiel 10km/h erkennt man schon die Problematik im Sprachgebrauch. Wird hier schon ein Bugeld verhngt oder erst bei 10,1km/h? Wird also auf grer oder auf grergleich geprft? In solchen Fllen mu ggf. die Spezifikation nochmals hinterfragt werden. 5. 4. intuitive Testfallermittlung

Hypothese: Der Tester kann zustzliche Fehlerquellen erahnen aufgrund seiner Erfahrung. Durch die stetige Verwendung einer Programmiersprache oder durch die gleichen Programmierer existieren Fehlerquellen, die sich aus der Kombination zwischen Mensch und dessen eingesetzter Programmiersprache zusammensetzen. Ziel: Zielsetzung ist es, systematisch ermittelte Testflle qualitativ zu verbessern und ergnzende Testflle aus Erfahrungswerten zu ermitteln. Man spricht von gesteuerten Zufallstests. Methode: Dieses Verfahren b eruht auf der intuitiven Fhigkeit und Erfahrung von Menschen, Testflle nach erwarteten Fehlern auszuwhlen. Hierbei werden Erfahrungen ber immer wieder auftretende Standardfehler eingebracht. 5. 5. Smoke-Test

Hypothese: Bislang wird nur von Eingaben gem der Spezifikation ausgegangen. Eine weitere Fehlerquelle besteht darin, da ein DAU (Dmmster Anzunehmender User) die Software bedient. Ziel: Ziel ist das Testen des Objektes unter unzulssigen Bedingungen mit der Beobachtung des Objektes auerhalb der Spezifikation. Die Software wird somit auf Robustheit geprft. Die Fragestellung lautet, ob sich das Programm bei Fehleingaben stets korrekt verhlt, es also weder zu Sach-, noch zu Personenschden kommen kann. Methode: Die Prfung auf Robustheit erfolgt durch zufllige und unsinnige Eingaben. Es werden gezielt Flle getestet, die sich auerhalb der Spezifikation befinden. Beispiel: Als Beispiel wird wieder einmal der Stapelspeicher verwendet. Eingaben auerhalb der Spezifikation sind unter anderem das Ausfhren der pop-Operation auf einem leeren Stapel, die push-Operation auf einem vollen Stapel oder das Ausfhren von delete auf einen gefllten Stapel. Ein Anwender, der den Sinn eines Stapelspeichers versteht, kommt nicht auf die Idee, diese unsinnigen Operationen durchzufhren. Gerade die Robustheit einer Anwendung gegen solche Operationen zeichnet jedoch ihre Gte aus.

Software-Testverfahren: der Blackbox Test

Seite 10

6.

Resmee

Zusammenfassend kann man sagen, da die Blackbox-Testverfahren einen wichtigen Beitrag fr die Prfung von Software anhand ihrer Spezifikation darstellen. Die korrekte Funktionalitt eines Systems hat die hchste Prioritt, ist also wichtiger als die konkrete Implementierung. Genau hier setzen die Blackbox-Tests an. Im Gegensatz zu den Whitebox-Verfahren knnen die Testflle bereits whrend der Programmierung erstellt werden, da zu diesem Zeitpunkt die Spezifikation bereits existiert. Die Durchfhrung des Testes kann automatisiert werden. Nicht automatisiert werden kann jedoch in der Regel die Erstellung der Testflle sowie die letzte Begutachtung der Test-Protokolle. Testverfahren knnen also nicht den Tester oder gar die Qualittssicherung von ihren Aufgaben ablsen, sondern lediglich untersttzend wirken. Des weiteren knnen fehlerhafte oder unzulngliche Spezifikationen meist nicht entdeckt werden, da die realisierte Software gegen die Spezifikation getestet wird. Die Spezifikation selbst kann lediglich durch regelmige Reviews zusammen mit dem Kunden getestet werden. Abschlieend bleibt als kleiner Nachteil der Blackbox-Testverfahren die Tatsache, da zustzliche, nicht geforderte oder nicht spezifizierte Funktionalitt nicht entdeckt werden kann, da sich diese innerhalb des Quellcodes befindet. Dies kann jedoch von den Whitebox-Verfahren gewhrleistet werden. Blackbox-Tests sind also wichtige Bestandteile zur Sicherstellung der korrekten Funktionalitt von Programmen, stellen aber keine alleinige und ultimative Lsung dar. Sie untersttzen lediglich die Effizienz des Testens in Kombination mit anderen Testverfahren. Alle TestVerfahren sind wiederum eingebettet in den fortlaufenden Proze der Qualittssicherung, der ein Produkt von der ersten Marktanalyse bis nach der Abnahme des Produktes durch den Endkunden begleitet.

Software-Testverfahren: der Blackbox Test

Seite 11

7.
Abb. 1 2 3 4

Abbildungsverzeichnis
Seite Testpyramide Die Testumgebung Funktion als Blackbox Modell des Stapelspeichers 5 6 6 7

8.
[1] [2] [3]

Literaturverzeichnis und Quellen


De Wille, E.: Software Test, Methoden und Vorgehensweisen <http://www.elektroniklager.de/sw/test.htm> (07.11.2002) Kahlbrandt, B.: Whitebox und Blackbox Tests; FH Hamburg; 2001; <http://www.informatik.fh-hamburg.de/~khb/st4se2/node64.html> (07.11.2002) Moeller, A.: Endbereicht Projektgruppe WWW-basierte Vermittlung, Kapitel 4: Systemtest; 2001; <http://www-ui.informatik.uni-oldenburg.de/user/amoeller/public/doc/endbericht/endbericht/node5.html> (22.12.2002) Ragutt, Dr. B.: Elementarmethode Black-box-Testfallentwurf (BBTE); Entwicklungsstandard fr IT-Systeme des Bundes ; 1997; <http://www.v-modell.iabg.de/au251htm/4beschrm/bbte.htm > (07.11.2002) Reason, J.: Human Error; MA: Cambridge University Press; 1990; <http://www.zwisler.de/scripts/reason.html> (22.12.2002) Thaller, G. E.: Software-Test. Verifikation und Validation.; 2002; ISBN 3-88229-198-2 Spillner, A.: Systematisches Testen in der Software-Entwicklung; FH Bremen; 1999; <http://homepages.hs-bremen.de/~anna/html/homepage/spillner/html/systtest/sld023.htm > (07.11.2002) Spillner, A.; Linz T.: Basiswissen Softwaretest; dpunkt.Verlag; ISBN 3-89864-178-3 Wenner, R.: Verifikation von Hard- und Software; FH Bonn-Rhein-Sieg; WS 2000/2001; <http://www.inf.fh-rhein-sieg.de/projekt/demerzers/verifikation/verifikation.html> (07.11.2002) Winter, M.: Testbarkeit objekt-orientierter Programme; GI-Fachgruppe 2.1.7; Test, Analyse und Verifikation von Software; 1997; <http://www.informatik.fernuni-hagen.de/import/pi3/GI/OOTestbarkeit.doc2.html> (22.12.2002)

[4]

[5] [6] [7] [8] [9] [10]