Testen von Software: Ziele, Begriffe und Methoden

Testen von Software: Ziele, Begriffe und Methoden 1
Seminar WS 2000/2001
Ausgewählte Gebiete des Software Engineering
durchgeführt am
Institut für Wirtschaftsinformatik
der Johannes Kepler Universität Linz
Arbeitsgruppe Software Engineering
Altenberger Str. 69, A-4040 Linz, Austria
Tel: +43-70-2468-9432
Fax: +43-70-2468-9430
Email: office@swe.uni-linz.ac.at
Leitung: Prof. Dr. Gustav Pomberger
Mitwirkend: Josef Pichler
Testen von Software: Ziele, Begriffe und Methoden
T3
Jürgen Friesenecker
Gerhard Strack
06.12.2000

Testen von Software: Ziele, Begriffe und Methoden 2
Inhaltsverzeichnis
Inhaltsverzeichnis .....................................................................................................2
Kurzfassung..............................................................................................................4
1 Einleitung........................................................................................................5
1.1 Was ist Software-Testen? ..........................................................................5
1.2 Warum soll man testen? ............................................................................5
1.3 Wer soll testen?.........................................................................................6
1.4 Was sollen wir testen?...............................................................................6
1.5 Wann sollen wir testen?.............................................................................6
2 Begriffe und Ziele des Testens.........................................................................7
2.1 Psychologie des Testens [Myers 1989 S 3ff]..............................................7
2.2 Ziele beim Testen......................................................................................7
2.3 Debugging vs. Testing...............................................................................8
2.4 Fehler in Software-Produkten....................................................................9
2.4.1 Einteilung von Fehlern.......................................................................9
2.4.2 Fehlerterminologie.............................................................................9
2.4.3 Fehlerarten ......................................................................................10
2.5 Gesetze für das Testen von Software [Beizer 1990 S. 9]..........................12
2.5.1 1. Gesetz: Das Pestizid-Paradoxon...................................................12
2.5.2 2. Gesetz: Die Komplexitätsschranke...............................................13
2.6 Testprinzipien [Myers 1989 S. 10ff] ........................................................13
3 Testphasen.....................................................................................................15
3.1 Testphasen im Software-Lebenszyklus ....................................................16
3.1.1 Entwicklungstest .............................................................................16
3.1.2 Abnahmetest....................................................................................16
3.1.3 Betriebstest......................................................................................17
3.1.4 Wartungstest....................................................................................18
3.2 Testphasen im Software-Entwicklungsprozeß .........................................18
3.2.1 Bausteintest .....................................................................................18
3.2.2 Verfahrenstest .................................................................................19
3.2.3 Installationstest................................................................................20
3.2.4 Systemtest .......................................................................................20
3.3 Festlegung von Testobjekten innerhalb der Testphasen............................20
4 Vorgehensweise bei der Testausführung ........................................................22
4.1 Testarten .................................................................................................22
4.1.1 Black-Box-Testen und White-Box-Testen .......................................23

Testen von Software: Ziele, Begriffe und Methoden 3
4.1.2 Statisches und Dynamisches Testen.................................................24
4.1.3 Repräsentatives, Schadensausmaßorientiertes und
Schwachstellenorientiertes Testen..................................................................27
4.2 Testaktivitäten der Testdurchführung ......................................................27
4.2.1 Testvorbereitung..............................................................................30
4.2.2 Testausführung ................................................................................34
4.2.3 Testauswertung................................................................................35
Abbildungsverzeichnis............................................................................................37
Literaturverzeichnis ................................................................................................38

Testen von Software: Ziele, Begriffe und Methoden 4
Kurzfassung
Testen von Software beinhaltet eine Menge an Informationen, welche sich zwar im
ersten Moment nur wenig unterscheiden, man aber später in den Detailinformationen
merkt, daß dieses Thema in den Feinheiten seine Wirkung zeigt.
Zu Beginn der Arbeit wird über die herkömmlichen W-Fragen informiert. Beinhaltet
darin ist die Definition des Begriffes Software-Testen und die Lösung zu den Fragen:
Warum, wer, was und wann soll getestet werden.
Danach beginnt ein Einblick in die Begriffe des Testens und dessen folgende Ziele.
Da solche Ziele Verfahren beinhalten, wurde eine zusätzliche Aufspaltung in die
Bereiche: „Testphasen“ und „Vorgehensweise bei der Testausführung“ erzeugt.
Die Testarten selbst werden wiederum unterteilt in den Software-Lebenszyklus und
den Software-Entwicklungsprozeß. Darin angeführt sind genaue Beschreibungen zu
einzelnen Testphasen.
Bei der Vorgehensweise während der Testausführung unterteilt man wiederum
zwischen den Testarten und den Testaktivitäten. Black-Box-Testen und White-Box-
Testen sowie der Unterschied zwischen statischem und dynamischen Testen sind
hier nur einige der relevanten Arten.
Die Testaktivitäten schließen folglich jene Testarten in den verschiedenen Bereichen
wie der Testvorbereitung, der Testausführung, der Testauswertung ein. Hierbei wird
beispielsweise auf dynamische bzw. statische Testweisen innerhalb der
Testvorbereitung zurückgegriffen.
Letztlich soll man in der Lage sein einen Softwaretest dem Ablauf nach
durchzuspielen, wobei auf genaue technische und mathematische Voraussetzungen
nicht näher eingegangen wird.

Testen von Software: Ziele, Begriffe und Methoden 5
1 Einleitung
1.1 Was ist Software-Testen?
Dies ist eine Frage, die nicht leicht zu beantworten ist. Wenn Software Testen im
kommerziellen Bereich eingesetzt wird, verbessert es die Qualität der ausgelieferten
Software-Produkte, steigert die Zufriedenheit der Anwender und senkt die
Wartungskosten. Im Bereich der Wissenschaft resultiert gutes Testen in genaueren
und zuverlässigeren Ergebnissen. Fehlendes oder ineffektives Testen führt
logischerweise zu den entgegengesetzten Ergebnissen – schlechtere Qualität der
Produkte, Unzufriedenheit der Anwender, höhere Wartungskosten, unzuverlässige
und ungenaue Ergebnisse.
Damit uns klar wird, wie Fehler zustande kommen, wie wir unsere eigenen Fehler
entdecken können und wer am besten dazu eingesetzt wird, Software Fehler zu
entdecken, müssen wir Erkenntnisse einsetzen, die aus der Psychologie stammen.
Die Mathematik bietet uns einen Einblick in die Möglichkeiten, die Korrektheit von
Software zu „beweisen“. Mit Hilfe der Wirtschaftswissenschaften müssen wir
entscheiden können, wann die Testergebnisse bedeuten, daß die Testphase beendet
werden sollte. Nur wenn wir alle diese Disziplinen berücksichtigen, werden wir
effektive Tests durchführen können.
Myers hat schon 1979 das Testen von Programmen so definiert:
„Testen ist der Prozeß, ein Programm mit der Absicht auszuführen, Fehler zu
finden.“ [Myers 1989 S. 4]
1.2 Warum soll man testen?
Obwohl das Testen von Software eine teure Angelegenheit ist, können die Kosten,
die das Unterlassen von Tests entstehen, höher sein. Bei Systemen, die mit der
Sicherheit von Menschen zu tun haben, ist dies selbstverständlich.
Bei den meisten Systemen sind wirtschaftliche Erwägungen jedoch sowohl die
treibende Kraft als auch der begrenzende Faktor beim Testen. Je früher im Verlauf
des Lebenszyklus Fehler entdeckt und beseitigt werden, desto niedriger sind die
Kosten ihrer Beseitigung. Die schlimmsten Fehler sind die, die beim Testen nicht

Testen von Software: Ziele, Begriffe und Methoden 6
entdeckt werden und deshalb noch vorhanden sind, wenn das System „ins Leben
hinaustritt“.
1.3 Wer soll testen?
Effektives Testen erfordert vom Tester, die zu prüfende Software streng objektiv zu
betrachten. Software-Entwickler, die ihre eigene Software testen sollen, befinden
sich deshalb in einer prekären Lage.
In vielen Firmen hat man eingesehen, daß es sehr schwierig ist, gegen das Phänomen
anzugehen, daß fast jeder dazu neigt, eigene Fehler zu verdrängen und so objektives
Testen nicht zu gewährleisten, und deshalb eine Lösung gewählt, die auf der Hand
liegt: die Trennung von Entwicklungs- und Testphasen, indem die Verantwortung
für jede dieser Phasen unter verschiedenen Mitarbeitern aufgeteilt wird. Wenn wir
vor der Aufgabe stehen, Software zu testen, die jemand anderer entwickelt hat, wird
unser beruflicher Ehrgeiz fordern, daß wir erfolgreich sind. Erfolg beim Testen
besteht im Entdecken von Fehlern.
1.4 Was sollen wir testen?
Im Mittelpunkt des traditionellen Software-Testens stand das Testen des
Programmcodes. Fehler werden jedoch nicht nur beim abschließenden Codieren des
Programms gemacht, sondern können im gesamten Lebenszyklus der
Systementwicklung auftreten. Wenn nur getestet wird, nachdem die Codierphase
beendet ist, können Fehler, die bereits in der Phase der Anforderungsanalyse
unterlaufen sind, bereits tief in der Software verwurzelt sein. Wenn Tests lediglich in
diesem späten Stadium durchgeführt werden, wird die Fehlerbeseitigung um so
teurer sein, je früher im Lebenszyklus der ursprüngliche Fehler gemacht wurde. In
den letzten Jahren hat sich deshalb der Schwerpunkt darauf verlagert, Fehler
möglichst nahe an ihrer Quelle zu finden.
1.5 Wann sollen wir testen?
Aus den oben dargelegten Gründen sollte wirtschaftliches Testen danach streben,
Fehler möglichst nahe an ihren Ursprüngen zu beseitigen. Daraus folgt, daß Testen
ein kontinuierlicher Prozeß im gesamten Lebenszyklus sein muß. Methodisches
Testen kann jedesmal dann ausgeführt werden, wenn ein Produkt ein neues Stadium
der Verfeinerung erreicht.

Testen von Software: Ziele, Begriffe und Methoden 7
2 Begriffe und Ziele des Testens
2.1 Psychologie des Testens [Myers 1989 S 3ff]
Die meisten Leute verwenden eine völlig falsche Definition des Begriffes, wie diese:
• „Testen ist der Prozeß, der zeigen soll, daß keine Fehler vorhanden sind.“
• „Der Zweck des Testens ist es, zu zeigen, daß ein Programm die geforderten
Funktionen korrekt ausführt“.
• „Testen ist der Prozeß, der das Vertrauen erzeugt, daß ein Programm das tut,
was es soll“.
Denn diese beschreiben fast das Entgegengesetzte dessen, als was das Testen
angesehen werden soll. Der Tester versucht den Wert des Programms durch das
Testen anzuheben. Werterhebung bedeutet, Anhebung der Qualität oder
Zuverlässigkeit des Programms. Anhebung der Zuverlässigkeit des Programms
bedeutet, Fehler zu finden und zu beheben. Daher sollte man ein Programm nicht
testen, um zu zeigen, daß es funktioniert, sondern man sollte mit der Annahme
beginnen, daß das Programm Fehler enthält und dann testen, um möglichst viele
Fehler zu finden.
Daher ist wie schon oben definiert Testen der Prozeß, ein Programm mit der Absicht
auszuführen, Fehler zu finden.
Diese Definition impliziert, daß Testen ein destruktiver, sadistischer Prozeß ist, es ist
erst erfolgreich, wenn Fehler gefunden werden und nicht, wenn keine Fehler
gefunden werden.
2.2 Ziele beim Testen
Hinsichtlich bestimmter Qualitätsmerkmale, wie z.B. Richtigkeit, Robustheit,
Sicherheit usw. ist Testen primär darauf ausgerichtet, das Vorhandensein von
Fehlern nachzuweisen. Unter Fehler wird dabei jede Abweichung des Verhaltens von
dem in der Anforderungsdefinition festgelegten Verhalten verstanden. Die Ursache
eines Fehlers kann in der Spezifikation, im Entwurf oder in der Implementierung
verborgen sein, sie kann nicht – wenn das Qualitätsmerkmal Robustheit erfüllt sein
soll – in der fehlerhaften Auswahl der Eingabewerte eines Programmsystems liegen.
Nach Beizer [Beizer 1995 S 7ff] testen wir Software um:

Testen von Software: Ziele, Begriffe und Methoden 8
• Programme ohne „Bugs“ zu erhalten, Programmierern Information zu geben,
wie sie „Bugs“ vermeiden können.
• Dem Management Information zu geben, damit es rationell das Risiko einer
Verwendung eines Testobjekts evaluieren kann.
• Ein testbares Programm zu schaffen, ein Programm das leicht validiert,
falsifiziert und gewartet werden kann.
• Explizite und implizite Anforderungen (Requirements) zu schaffen, die
implementierbar, vollständig, konsistent, korrekt sind.
• Explizite Anforderungen zu validieren.
• Implizite Anforderungen zu falsifizieren.
Explizite Anforderungen werden durch sog. „clean tests“(konstruktive/positive
Tätigkeit) validiert. Ein “clean test” ist ein Test dessen primärer Zweck Validation
ist, das heißt Tests werden entworfen um zu zeigen, daß die Software korrekt
arbeitet.
Implizite Anforderungen werden durch sog. „dirty tests“ (subversive/negative
Tätigkeit) falsifiziert. Ein „dirty test“ ist ein Test dessen primärer Zweck
Falsifikation ist, das heißt Tests werden entworfen um die Software zu brechen.
Wenn man etwas nicht testet, heißt das, daß man die Fehlerfreiheit garantiert, oder
daß man sich sicher ist, daß die Funktionalität unnötig ist. Deshalb muß (soll) man
nicht getestete Funktionalität entfernen.
2.3 Debugging vs. Testing
In enger Beziehung zum Testen steht das Debugging (Entwanzen), dessen Zweck
das Erkennen und Beheben von Fehlerursachen und das Beseitigen von Fehlern
einschließlich der Überprüfung der Fehlerkorrektur ist. Diese Überprüfung erfordert
die Wiederholung des Testens, um feststellen zu können, ob der Fehler tatsächlich
korrigiert wurde und ob durch die Korrektur keine neuen Fehler „eingeführt“ wurden
(Retesting). [Heinrich 2000 S. 409]
Die Unterschiede zwischen Testen und Debugging lassen sich nach [Steindl 2000 S.
29 ff] wie folgt aufgliedern:
• Testen beginnt unter bekannten Voraussetzungen, verwendet vordefinierte
Prozeduren und hat vorhersagbare Ergebnisse.
Testen kann geplant werden, Testpläne können entworfen werden und
zeitlich angesetzt werden.
Es ist nur nicht vorhersagbar, ob das Programm den Test besteht oder nicht.

Testen von Software: Ziele, Begriffe und Methoden 9
Testen beweist Fehler des Programmierers.
Testen kann ohne großes Wissen über das Design erledigt werden und oft
von Außenstehenden durchgeführt werden.
Vieles läßt sich automatisieren wie der Entwurf von Testfällen und die
Durchführung der Tests.
• Beim Debuggen können die Vorgehensweise und die dafür benötigte Zeit
nicht so von vornherein festgelegt werden (intuitive Sprünge, Vermutungen,
Experimentieren).
Debuggen ist die Rechtfertigung des Programmierers und ist ohne detaillierte
Design-Kenntnisse unmöglich, muß daher von einem „Insider“ durchgeführt
werden.
Automatisiertes Debuggen ist noch immer eine Traumvorstellung.
2.4 Fehler in Software-Produkten
2.4.1 Einteilung von Fehlern
Zur Unterscheidung von Fehlern sind eine Vielzahl unterschiedlicher Möglichkeiten
der Klassifizierung gegeben, so können Fehler klassifiziert werden nach der
Entwicklungsphase, wo der bestimmte Fehler auftritt, nach den Konsequenzen, die
dieser Fehler verursacht, nach der Schwierigkeit, diesen Fehler zu beheben, usw.
Beizer [Beizer 1990 S. 28f] charakterisiert im folgenden diese Möglichkeit der
Klassifizierung näher. Er teilt Fehler nach der Schwere ihrer Konsequenzen ein:
• Kosmetisch
• Anders wäre es angenehmer/schöner
• Mittelschwer
• Performance-Einbußen
• Schadend
• Schwer
• Katastrophal
Fehler können aber auch nach ihrer Terminologie und Art eingeteilt werden.
2.4.2 Fehlerterminologie
Für Fehler gibt es vier verschiedene Begriffe, nämlich „Bug“, „Error“, „Fault“ und
„Failure“, die in dieser Abbildung definiert werden:

Testen von Software: Ziele, Begriffe und Methoden 10
Abbildung 1 - Fehlerterminologie [Steindl 2000 S. 36]
2.4.3 Fehlerarten
Beizer [Beizer 1990 S. 34ff] unterscheidet folgende Fehlerarten:
Abbildung 2 - Fehlerarten [Steindl 2000 S. 37]

Testen von Software: Ziele, Begriffe und Methoden 11
2.4.3.1 Strukturelle Fehler
Kontrollflußfehler und Sequenzfehler enthalten fehlende Pfade, nicht-erreichbarer
Programmcode, falsche Schleifenbedingungen, fehlende, duplizierte, unnötige
Verarbeitungsschritte und falsch verstandene Abfragen.
Kontrollflußfehler und Sequenzfehler werden normalerweise beim Unit Testen
gefunden. Diese Fehler können durch die Wahl der Programmiersprache (z.B. ohne
GOTOs) und des Programmierstils bzw. Programmierrichtlinien vermieden werden.
Logische Fehler entstehen durch falsches Verständnis von logischen Operatoren,
fehlende oder falsch angelegte Zweige, doch mögliche unmögliche Zweige,
fehlerhafte Negation boolescher Ausdrücke (z.B. Negation von >= wird

Testen von Software: Ziele, Begriffe und Methoden 12
sind nicht deklarierte Daten, Aufruf nicht existenter Prozeduren, oder
Dokumentationsfehler führen oft zu fehlerhaftem Code oder falschen
Wartungsarbeiten, wie Tippfehler, irreführende, fehlerhafte oder veraltete
Kommentare.
2.4.3.4 Testfehler und Fehler im Testdesign
Fehler können auch in den Testfällen auftreten, denn es gibt keine engelhaften
Tester. Abhilfen gegen Testfehler sind Debuggen der Testfälle, Qualitätskontrolle
beim Testen, automatisierte Testausführung und automatisierter Testentwurf.
2.5 Gesetze für das Testen von Software [Beizer 1990 S. 9]
2.5.1 1. Gesetz: Das Pestizid-Paradoxon
Jede Methode, die man anwendet, um Fehler zu vermeiden oder zu finden, hinterläßt
einen gewissen Rest von raffinierteren Fehlern, gegen welche die eingesetzte
Methode nichts ausrichten kann.
Das Pestizid-Paradoxon wird durch folgende Abbildung einfach erläutert:

Testen von Software: Ziele, Begriffe und Methoden 13
Abbildung 3 - Das Pestizid Paradoxon [Steindl 2000 S. 9]
2.5.2 2. Gesetz: Die Komplexitätsschranke
Die Komplexität der Software (und damit auch die Komplexität der Fehler) wächst
über unsere Fähigkeiten hinaus, die Komplexität zu meistern.
2.6 Testprinzipien [Myers 1989 S. 10ff]
• Ein notwendiger Bestandteil eines Testfalls ist die Definition der erwarteten
Werte oder des Resultats.
Würde das erwartete Resultat eines Testfalls nicht vorher definiert, so besteht die
Möglichkeit, ein plausibles, aber fehlerhaftes Ergebnis wegen des Phänomens „das
Auge sieht das, was es sehen will“ als korrekt zu betrachten. Daher muß eine genaue
Untersuchung des ganzen Outputs und ein exakter Vergleich mit dem erwarteten
Output des Programms vorgenommen werden.
• Überprüfen Sie die Ergebnisse eines jeden Tests gründlich.
Dies ist wahrscheinlich das wichtigste Prinzip, weil Fehler übersehen werden, die
aber in Testfällen erkennbar sind, weil eine sorgfältige Überprüfung der Ergebnisse
unterbleibt.

Testen von Software: Ziele, Begriffe und Methoden 14
• Testfälle müssen für ungültige und unerwartete ebenso wie für gültige und
erwartete Eingabedaten definiert werden.
Beim Testen neigt man dazu, sich auf zulässige und erwartete Eingabedaten zu
konzentrieren und ungültige und unerwartete Daten zu vernachlässigen. Fehler
werden sonst erst entdeckt, wen das Programm auf neue, unerwartete Weise
eingesetzt wird.
• Schauen Sie, ob das Programm etwas tut, was es nicht tun soll.
Das ist eine einfache Ergänzung der vorigen Regel. Programme müssen auf
unerwünschte Nebeneffekte hin untersucht werden.
• Vermeiden Sie Wegwerftestfälle, es sei denn das Programm ist wirklich ein
Wegwerfprogramm.
Testfälle sind wiederholbar und können in der Zukunft goldeswert sein, daher sollen
Testfälle nicht weggeworfen werden.
• Planen Sie kein Testverfahren unter der stillschweigenden Annahme, daß
keine Fehler gefunden werden.
Die Wahrscheinlichkeit für die Existenz weiterer Fehler in einem Abschnitt eines
Programms ist proportional zu der Zahl der bereits entdeckten Fehler in diesem
Abschnitt. Auf den ersten Blick ergibt das keinen Sinn, aber diese Erscheinung
wurde in vielen Programmen beobachtet.
• Testen ist eine extrem kreative und intellektuell herausfordernde Aufgabe.
• Testen ist der Prozeß, ein Programm mit der Absicht auszuführen, Fehler zu
finden.
• Ein guter Testfall ist dadurch gekennzeichnet, daß er mit hoher
Wahrscheinlichkeit einen bisher unbekannten Fehler zu entdecken imstande
ist.
• Ein erfolgreicher Testfall ist dadurch gekennzeichnet, daß er einen bisher
unbekannten Fehler entdeckt.

Testen von Software: Ziele, Begriffe und Methoden 15
3 Testphasen
„Testphasen sind sachlich und zeitlich in sich geschlossene Abschnitte des Testens,
in denen für bestimmte Software-Produkte definierte Testaufgaben durchgeführt
werden.“ [Schmitz 1982 S. 70]
Unterschieden werden jene nach folgenden Größen:
• analysierende Testobjekte und deren Zuordnung zu Projektphasen
• Überschaubarkeit und Beherrschbarkeit der Testobjekte
• Durchzuführende Testaufgaben
• Verantwortlichkeiten für die Durchführung des Testens bzw. die Freigabe
von Objekten
• Vorgegebene Umgebung, in der das Testobjekt getestet wird
(Entwicklungsumgebung, Anwendungsumgebung)
Für jeden dieser einzelnen Unterschiede ist eine Testphase zu realisieren, sofern alle
Objekte der unterschiedlichen Typen getestet werden sollen. Auch wenn ein Objekt
für die Testdurchführung zu komplex bzw. nicht vollständig durchschaubar ist, sind
Elemente des Testobjekts in eigenen Testphasen zu testen.
Weiters sind Testphasen für Objekte zu unterscheiden, wenn sie verschiedene
Verantwortlichkeiten besitzen.

Testen von Software: Ziele, Begriffe und Methoden 16
3.1 Testphasen im Software-Lebenszyklus
Abbildung 4 – Software Lebenszyklus [Steindl 2000 S. 6]
Anhand der angeführten Kriterien unterscheidet man:
• Entwicklungstest
• Abnahmetest
• Betriebstest
• Wartungstest
3.1.1 Entwicklungstest
Dieser Test beinhaltet alle Maßnahmen des Testens innerhalb des Software-
Produktionsprozesses und testet hinsichtlich der Anforderungen an die
Projektergebnisse in Bezug auf die relevanten Qualitätsmerkmale.
Betreuer dieses Tests sind die jeweilig verantwortlichen Entwickler und endet somit
mit der Freigabe des Produktes für den Betrieb. (siehe auch 4.2 Testphasen im
Software Entwicklungszyklus)
3.1.2 Abnahmetest
Das Produkt wird hier hinsichtlich der Anwendung des Benutzers getestet. Dieser
Zustand ist jedoch erst bei der Freigabe des Systems aus der Hand der

Testen von Software: Ziele, Begriffe und Methoden 17
Entwicklungsgruppe möglich (z.B. beim Ankauf des Systems). Getestet wird
letztlich nach der Installation und Einführung des Systems.
Es werden beim Abnahmetest normalerweise drei Formen von Tests unterschieden:
• Benchmarktest: entsprechend der Problemanalyse Testfälle/Testdaten
konstruiert oder aus Beständen an Originaldaten selektiert. Der dynamische
Test erfolgt mit den so ermittelten Testdaten in einer weggehend sicheren
Testumgebung oder in der Produktionsumgebung.
• Pilottest: es wird ein potentieller zukünftiger Arbeiter ausgesucht, welcher
die Software für eine gewisse Zeit das System testet.
• Paralleltest: Die Software wird mit einem oder mehreren zukünftigen
Anwendern für eine begrenzte Zeit parallel zum alten Verfahren eingesetzt.
3.1.3 Betriebstest
Der Betriebstest dient zur Erkennung von Fehlern während des Einsatzes im Betrieb.
Hierzu wird das Software-Produkt durch sporadische oder permanente Ausführung
von Testaktivitäten mit Testfällen aus realen Verarbeitungsdaten, geprüft.
Vorgehensweisen:
• Überprüfung der Ergebnisse der Produktionsläufe [Schmitz 1982 S. 81]
o Teilweise Überprüfung: die Tests bzw. Ergebnisse werden nur in
gewissen Zeitabständen durchgeführt
o Permanente Überprüfung
• Während des Ablaufes werden Zwischenschritte der
Programmverarbeitung auf Plausibilität geprüft
• Nach dem Ablauf werden verdichtete Daten automatisiert oder
nicht-automatisiert geprüft
• Nach dem Ablauf werden Ergebnisse mit alten verglichen und
die Unterschiede „interpretiert“
• Wiederholung von Produktionsläufen in einer isolierten Umgebung
Vorerst müssen Verarbeitungsfälle, welche im normalen Betrieb nicht
anfallen, ausgewählt werden. Diese werden schlußendlich in einer
Betriebstestdatei gespeichert.
Danach wird hier eine sogenannte Testfirma mit diesen Daten simuliert. Dies
heißt jedoch keinesfalls, daß von der Betriebsdatei nicht abgewichen wird, im
Gegenteil, die Testfirma ist so angelegt um eine ständiges updaten
durchführen zu können.
Durch das Testen unmittelbar vor dem Einsatz kann sichergestellt werden,

Testen von Software: Ziele, Begriffe und Methoden 18
daß zwischenzeitlich keine Änderungen in die Programme eingebracht
worden sind und darüber hinaus auch durch Änderungen in der
Hardware/Software-Umgebung kein fehlerhaftes Verhalten hervorgerufen
wird.
Wird ein Fehler erkannt wird sofort die Wartung des Software-Systems
begonnen.
3.1.4 Wartungstest
Dient der Analyse hinsichtlich der Auswirkungen von Änderungen oder
Erweiterungen des Programmsystems.
Aufgabe des Wartungstests ist es, die geänderten sowie neuen Programmfunktionen
zu testen. Vorerst getrennt und schließlich in Zusammenhang mit dem restlichen
Software-System.
Wesentlich hierbei ist, daß auf vorhandene Testfälle und Testdaten wiederverwendet
werden und somit für neue Funktionen aktualisiert bzw. erweitert werden müssen um
bei anderen Tests optimale Testaktivitäten zu garantieren.
3.2 Testphasen im Software-Entwicklungsprozeß
Alle Phasen einer Softwareentwicklung werden mindestens durch einen Test
überprüft. Dies gilt besonders für Module die Zwischenergebnisse liefern.
Es werden folgende Tests unterschieden:
• Bausteintest
• Verfahrenstest
• Installationstest
• Systemtest
3.2.1 Bausteintest
Programmbausteine sind Module, welche durch Eingaben über die Schnittstelle
unabhängig vom Gesamtsystem getestet werden.
Der Bausteintest wird in einer kontrollierbaren, sicheren Umgebung durchgeführt.
Externe Schnittstellen zu anderen Programmen, Daten, Datenbanken oder auch
Benutzern werden in dieser Testumgebung simuliert.
„Es ist wichtig, die Testfälle für ein Testobjekt so auszuwählen, daß

Testen von Software: Ziele, Begriffe und Methoden 19
• für alle Funktionseinheiten und deren Schnittstellenverhalten geprüft wird, ob
sie ihre Spezifikation erfüllen,
• alle Zweige der Funktionseinheiten durchlaufen werden
• der kleinste und größte Wert jedes Eingabedatums berücksichtigt wird
(Grenzwerttest)
• jede Schleife mit minimaler und maximaler Durchlaufzahl geprüft wird
• alle Fehlerausgänge des Testobjekts geprüft werden
• die Reaktion des Testobjekts auf willkürliche Eingabedaten überprüft wird
(Streß-Test, Zufallstest)
3.2.2 Verfahrenstest
Enthält die Analyse einzelner Programme oder mehrerer Programme in ihrem
Zusammenwirken. Ferner werden die Module hinsichtlich der externen
Schnittstellen insbesondere auch mit dem Benutzer schrittweise analysiert.
Um eine Übersicht über das Zusammenwirken zu erlangen ist es empfehlenswert den
Zusammenhang zwischen den Testfällen und den damit verbunden Funktionen in
einer Tabelle darzustellen.
Abbildung 5 - Testfallmatrix [Heinrich 2000 S. 414]
Der Verfahrenstest wird noch in einer Entwicklungsumgebung durchgeführt, dabei
ist es aber nicht mehr nötig Entwickler zu belasten sondern spezialisierte Gruppen
oder Personen des Aufgabenbereichs.

Testen von Software: Ziele, Begriffe und Methoden 20
3.2.3 Installationstest
Beinhaltet die Analyse des Installationsprozesses hinsichtlich möglicher Fehler bei
der Installation.
Untersucht wird die Verfügbarkeit von Umgebung (Dateien, Datenbank,...) und
Programmbausteinen. Weiters wird die formale Zusammenarbeit dieser getestet.
Notwendig ist solch ein Test, wenn man von einem System auf ein anderes wechselt
(z.B. von der Entwicklungsumbebung hin zur Benutzerumgebung).
3.2.4 Systemtest
Analysiert das Gesamtsystem in der Zielumgebung. Im Normalfall wird hier das
Pflichtenheft überprüft.
Aus diesem Grund wird der Systemtest in der realen Benutzerumgebung unter
Einbeziehung realer Schnittstellen durchgeführt (unter Umständen wird der
zukünftige Benutzer eingesetzt).
Zu untersuchende Ziele:
• Testen des Gesamtsystems in Hinblick auf Effizienzanforderungen
• Testen des Zusammenwirkens des Gesamtsystems mit vorhandenen
Softwareprodukten
• Testen des funktionalen Zusammenwirkens der Programme des realisierten
Produktes in der Zielumgebung
Analysiert wird (wie oben angegeben) dieses System von eigenständigen
Testgruppen um vorhergehende fehlende Fälle aufzudecken. Weiter soll eine
Struktur zur Analyse beibehalten werden, welche folgendermaßen aussieht:
• formale Gesichtspunkte
• sachlich inhaltlicher Gesichtspunkt
• Zusammenwirken mit Elementen in der Umgebung
• qualitativer Gesichtspunkt
3.3 Festlegung von Testobjekten innerhalb der Testphasen
Die Komplexität von Testphasen, Testaufgaben und Testobjekten sollte so gewählt
werden, daß das Testen beschränkt ist. Hierzu gibt es zwei Möglichkeiten:
• gezielte Steuerung der Umgebung, in welcher der Test eines Objekts abläuft
• schrittweise Analyse von Teilen eines Software-Produkts

Testen von Software: Ziele, Begriffe und Methoden 21
Strategien zum Testen von Programmen:
• Testobjekte werden geteilt, um den Umfang zu verkleinern (z.B. einzelne
Programmbausteine -> einzelne Programme -> gesamtes Programmsystem)
Hierzu sollte die Wahl der Testobjekte nach technischen, funktionalen oder
aufgabenbezogenen Gesichtspunkten gewählt werden.
• Testen der Programme in einer konstruierten Umgebung, welche später
immer realer wird, wobei die Umgebungen auf Fehlerfreiheit geprüft
wurden/werden sollten.
Strategien zum Testen von Dokumenten:
• Begrenzung der Testobjekte auf einen Maximalwert.
• Im Normalfall sind Dokumente nicht automatisiert testbar was dazu führt,
daß bei der Aufteilung der Dokumente auf eine strickte Trennung von
Teildokumenten geachtet werden soll.
• Einsetzen von gleichen Testern innerhalb eines Dokuments oder
ausreichende Beschreibung des Kontexts zwischen den Teildokumenten,
wobei die erste Lösung, trotz größerer Fehlergefahr, vorgezogen werden
sollte.

Testen von Software: Ziele, Begriffe und Methoden 22
4 Vorgehensweise bei der Testausführung
4.1 Testarten
Nach [Heinrich 2000 S. 415ff] kann eine Systematik der Testmethoden nach
folgenden Testarten gebildet werden: nach der Art der Testfallermittlung,
Testausführung und dem Umfang der Testausführung.
Die Testfallermittlung kann aufgabenorientiert (funktionsorientiert) oder
produktorientiert (strukturorientiert) erfolgen. Danach wird zwischen Black-Box-Test
und White-Box-Test unterschieden.
Bezüglich der Art der Testausführung wird zwischen statischem Testen und
dynamischem Testen unterschieden.
Der Umfang der Testausführung wird durch die Art und die Anzahl der verwendeten
Testfälle festgelegt. Danach wird zwischen repräsentativem Test, schwachstellenorientiertem
Test und schadensausmaß-orientiertem Test unterschieden.
Folgende Abbildung zeigt den Zusammenhang zwischen den Testarten. Weitgehend
identisch mit der Testart statisches Testen ist die Testart logisches Testen, und
weitgehend identisch mit der Testart dynamisches Testen ist die Testart empirisches
Testen. Beim logischen Testen (auch als Schreitischtest bezeichnet) wird das
Testobjekt durch gedankliches Nachvollziehen seiner Funktionsweise getestet; beim
empirischen Testen wird das Testobjekt auf einem Testsystem implementiert.
Abbildung 6 - Zusammenhang zwischen den Testarten [Heinrich 2000 S. 416]

Testen von Software: Ziele, Begriffe und Methoden 23
4.1.1 Black-Box-Testen und White-Box-Testen
Das Black-Box-Testen wird auch als „funktionaler Test“ oder „exterior test“
bezeichnet. Wesentliches Merkmal des Black-Box-Testens ist, daß hier das
Ein/Ausgabeverhalten ohne Berücksichtigung der inneren Struktur des Testobjektes
(Schnittstellentest) geprüft wird. Das heißt der Tester ist nicht an dem internen
Verhalten und an der Struktur des Programms interessiert, sondern daran, Umstände
zu entdecken, bei denen sich das Programm nicht gemäß der Spezifikation verhält, er
betrachtet das Programm eben als Blackbox. Die Testdaten werden nur aus der
Spezifikation abgeleitet (d.h. ohne Kenntnisse von der internen Struktur des
Programms zu verwenden). Wichtig ist, das Verhalten des Testobjekts bei
fehlerhaften Eingabedaten zu überprüfen.
Black-Box-Testen ist im wesentlichen für das dynamische Testen, d.h. die
Ausführung mit Testdaten, von Bedeutung. Insofern ist Black-Box-Testen im
wesentlichen auf das Testen von Programmen ausgerichtet; darüber hinaus ist diese
Testart bei Verfügbarkeit entsprechender Hilfsmittel z.B. zum Prototyping auch für
Dokumente von Bedeutung.
Durch Black-Box-Testen kann das Fehlen von Aufgaben/Funktionen bzw.
Eigenschaften des Testobjekts erkannt werden. Dagegen kann durch Black-Box-
Testen keine Informationen darüber geliefert werden, ob alle Funktionen des
Testobjekts auch tatsächlich benötigt werden oder ob Datenobjekte manipuliert
werden, die keinen Einfluß auf das Ein/Ausgabeverhalten des Testobjekts haben.
Solche Hinweise auf Design- und Implementierungsfehler liefert nur der White-Box-
Test.
Das White-Box-Testen wird auch als „Strukturtest“ oder „interior test“ bezeichnet.
Wesentliches Merkmal des White-Box-Testen ist, daß hier das
Ein/Ausgabeverhalten unter Betrachtung der inneren Strukturen (Schnittstellen- und
Strukturtest) geprüft wird. Das heißt der Tester definiert die Testdaten mit Kenntnis
der Programmlogik. Das Ziel dabei ist, für jeden möglichen Pfad durch das
Testobjekt das Verhalten des Testobjekts in Abhängigkeit von den Eingabedaten
festzustellen. Bei der Wahl der Eingabedaten ist laut [Pomberger 1996 S. 152] zu
berücksichtigen, daß
• jedes Modul und jede Funktion des Testobjektes mindestens einmal
aufgerufen wird,
• jeder Zweig mindestens einmal durchlaufen wird,
• möglichst viele Pfade durchlaufen werden.

Testen von Software: Ziele, Begriffe und Methoden 24
Für gut strukturierte Programme ist es praktisch unmöglich alle Pfade (alle
möglichen Anweisungsfolgen) auszutesten. Auch bei einer automatischen
Testdatengenerierung ist es unmöglich, alle Pfade zu testen, weil die Anzahl der
dazu benötigten Testläufe viel zu hoch ist.
Trotzdem ist der White-Box-Test eine der wichtigsten Testmethoden, weil man
damit für eine begrenzte Anzahl von Programmpfaden die richtige Manipulation der
Datenstrukturen und das Ein/Ausgabeverhalten von Testobjekten überprüfen kann.
White-Box-Testen ist sowohl für das statische als auch dynamische Testen von
Bedeutung.
Vorteil des White-Box-Testens ist, daß das Vorhandensein nicht geforderter/
gewünschter Aufgaben/Funktionen bzw. Eigenschaften des Testobjekts erkannt
werden kann. Demgegenüber wird als Nachteil angeführt, daß das Fehlen
erforderlicher Aufgaben/Funktionen nicht festgestellt wird; diese Aussage ist nicht
generell gültig, da durch Bereitstellung der Soll-Ergebnisse und entsprechende
Ergebnisprüfung auch derartige Fehler gefunden werden können.
Insgesamt ist festzustellen, daß weder allein durch Black-Box-Testen noch durch
ausschließliches White-Box-Testen eine vollständige Abdeckung der Testaufgaben
gegeben ist; vielmehr sind beide Testarten in Kombination miteinander anzuwenden.
4.1.2 Statisches und Dynamisches Testen
Statisches Testen dient zur Analyse von Software-Produkten, wobei ausschließlich
das Testobjekt selbst als Datenbestand analysiert und ausgewertet wird. Es erfolgt
keine Ausführung des Testobjekts mit Testdaten.
Statisches Testen bezieht sich sowohl auf Dokumente als auch auf Programme. So
ist z.B. das Testen von Dokumenten zum großen Teil durch statisches Testen zu
realisieren; teilweise wird auch beim Testen von Dokumenten dynamisch getestet.
Bei Programmen ist das statische Testen der erste Schritt nach der Codierung und
kann unterschiedlichen Umfang hinsichtlich der durchzuführenden Analysen haben.
Die Aktivitäten beim statischen Test beziehen sich auf syntaktische, strukturelle oder
semantische Analysen des Testobjekts. Das Ziel dabei besteht darin, zu einem
möglichst frühen Zeitpunkt fehlerverdächtige Stellen des Testobjekts zu lokalisieren.
Die wichtigsten Tätigkeiten der statischen Analyse sind [Pomberger 1996 S.150f]:
• Code-Inspektion

Testen von Software: Ziele, Begriffe und Methoden 25
• Komplexitätsanalyse
• Strukturanalyse
• Datenflußanalyse
Bei der Code-Inspektion versucht ein Team von Softwaretechnikern beim
gemeinsamen Lesen des Codes Entwurfs- und Implementierungsfehler zu finden,
diese aber nicht selbst auszubessern. Ein Inspektionsteam besteht gewöhnlich aus
vier Leuten. Einer von ihnen ist der Moderator, der ein kompetenter, aber nicht am
Projekt beteiligter Softwaretechniker sein sollte. Die Pflichten des Moderators
beinhalten die Protokollierung aller gefundenen Fehler und die Zeitplanung für die
Inspektionssitzungen. Die weiteren Mitarbeiter sind der Designer des Testobjekts,
der für die Implementierung zuständige Programmierer und der für den Test
zuständige Mitarbeiter. Erst wenn die Inspektion vollständig abgeschlossen ist,
werden der Designer und der Implementierer vom Moderator mit der Korrektur
beauftragt.
Abbildung 7 – Codeinspektion [Steindl 2000 S. 61]
Das Ziel der Komplexitätsanalyse ist die Ermittlung von Meßzahlen für die
Komplexität eines Programms. Darunter werden Komplexitätsmaße von Modulen,
Schachtelungstiefen von Schleifen, Längen von Prozeduren und Methoden
verstanden. Die Ergebnisse der Komplexitätsanalyse gestatten es, in gewissen

Testen von Software: Ziele, Begriffe und Methoden 26
Grenzen Aussagen über die Qualität eines Softwareproduktes zu machen und
fehlerträchtige Stellen im Programmsystem zu lokalisieren.
Das Ziel der Strukturanalyse ist es, Strukturanomalien eines Testobjektes
aufzudecken. Sie soll z.B. Auskunft darüber geben, ob alle Anweisungen eines
Programms vom Programmanfang aus erreicht werden können, ob das
Programmende von allen Anweisungen aus erreichbar ist, ob in einem Programm
Schleifen mit Einsprüngen enthalten sind oder ob der Kontrollfluß unerlaubte
Strukturen enthält.
Bei der Datenflußanalyse sollen Datenflußanomalien aufgedeckt werden. Sie liefert
Informationen darüber, ob ein Datenobjekt vor seiner Benutzung einen Wert erhalten
hat und ob ein Datenobjekt nach einer Wertzuweisung auch benutzt wird. Die
Datenflußanalyse soll sowohl für den Rumpf eines Testobjekts als auch für die
Schnittstellen zwischen Testobjekten durchgeführt werden.
Dynamisches Testen dient der Analyse von Software-Produkten durch Ausführung
mit Testdaten. Ziel des dynamischen Testens ist es, Ablauffehler zu erkennen, indem
durch gezieltes Erzeugen und Auswertung einer Datenbasis diese mit Soll-
Ergebnissen verglichen wird.
Dynamisches Testen bezieht sich nicht nur auf Programmen sondern auch auf
Dokumente, weil das gedankliche Durchrechnen eines Programms oder Verfolgen
eines Ablaufplans mit Testdaten ebenso dazu dient Ergebnisse zu erzielen und diese
einem Soll-/Ist-Vergleich zu unterziehen.
Die Aktivitäten beim Dynamischen Test umfassen: [Pomberger 1996 S. 151]
• Die Vorbereitung des Testobjekts zur Fehlerlokalisierung,
• Die Bereitstellung einer Testumgebung,
• Die Auswahl geeigneter Testfälle und -daten,
• Die Testausführung und -auswertung.
Im Software-Lebenszyklus darf und kann dynamisches Testen nicht fehlen. Jede
Prozedur, jedes Modul und jede Klasse, jedes Subsystem und das Gesamtsystem
müssen dynamisch getestet werden, auch wenn statische Tests oder
Programmverifikationen durchgeführt wurden.
Generell ist festzustellen, daß weder allein das statische noch das dynamische Testen
ausreichend ist, um alle möglichen Fehler zu erkennen. Vielmehr sind beide
Testarten in unterschiedlichen Maße geeignet, bestimmte Fehler bzw. Fehlerklassen
zu erkennen.

Testen von Software: Ziele, Begriffe und Methoden 27
4.1.3 Repräsentatives, Schadensausmaßorientiertes und
Schwachstellenorientiertes Testen
Welche Vorgehensweise beim Testen nach dem Umfang der Testausführung
verwendet wird, hängt sowohl von der Auswahl der einzubeziehenden Daten ab als
auch von den zu analysierenden Komponenten des Testobjekts. So wird der Umfang
der Testausführung dieser Testarten entweder direkt durch Selektion entsprechender
physischer Komponenten oder indirekt durch Auswahl entsprechender Testdaten
festgelegt.
Ein Test wird als repräsentativer Test bezeichnet, wenn Art und Umfang der
Testfälle so ausgewählt werden, daß die Komponenten des Testobjekts entsprechend
der Häufigkeit ihrer Verwendung getestet werden. Das heißt, daß für die
Testausführung genau festgelegte Teile des Testobjekts (im wesentlichen beim
Testen von Dokumenten) einbezogen werden und so bestimmte
Aufgaben/Funktionen repräsentiert werden. Wichtig ist beim repräsentativen Testen,
daß detaillierte Erwartungen hinsichtlich der Ergebnisse der Testausführung
bestehen.
Ein Test wird als schadensausmaßorientierter Test bezeichnet, wenn die
Komponenten des Testobjekts, bei denen durch das Auftreten von Fehlern ein
besonders hoher Schaden verursacht werden kann, intensiver getestet werden als die
anderen Komponenten. Zur Einstufung der Testobjekt-Komponenten in
Schadensklassen muß eine Risikoanalyse durchgeführt werden.
Schwachstellenorientiertes Testen beschreibt die Vorgehensweise, bei der Art und
Umfang der Testfälle so ausgewählt werden, daß die Komponenten des Testobjekts
entsprechend der auf Grund von Erfahrung und Intuition vermuteten
Fehlerhäufigkeit in den Komponenten dynamisch getestet werden, um die
Annahmen zu verifizieren oder falsifizieren. Diese Vorgehensweise wird auch als
„error guessing“ bezeichnet.
Repräsentatives, statistisches und schwachstellenorientiertes Testen sind sowohl
beim Black-Box- bzw. White-Box-Testen als auch beim statischen und dynamischen
Testen anwendbar. Darüber hinaus sind sie für alle Testaufgaben anwendbar.
4.2 Testaktivitäten der Testdurchführung
Jede Testaktivität muß ein genau definiertes Ergebnis erfüllen, was beispielsweise
Testfälle oder Testdaten für ein bestimmtes Testobjekt sind.

Testen von Software: Ziele, Begriffe und Methoden 28
Unterschieden werden hierzu verschiedenste Klassen:
Abbildung 8 – Zusammenwirken der Klassen von Testaktivitäten [Schmitz 1982 S. 90]
Testplanung:
Legt die Aufgaben, Ziele und Vorgehensweisen fest, wobei eine strategische und
operative Testplanung erfolgt.
Testdurchführung:
Enthält alle Testdaten und realisiert den zuvor in der Testplanung erstellten Testplan.
Testkontrolle:
Überwacht und steuert den Testprozeß.
Testdokumentationserstellung:
Erfaßt jegliche Beschreibung der Vorgehensweisen beim Testen, der hierbei
verwendeten Daten und die Ergebnisse selbst. Diese Aktivität läuft ständig, somit
parallel zur Testplanung, Testdurchführung und Testkontrolle.
Die Testdurchführung selbst wird schlußendlich wieder untergliedert in die
Bereiche:
• Testvorbereitung
• Testausführung
• Testauswertung
Testvorbereitung:

Testen von Software: Ziele, Begriffe und Methoden 29
Die Testvorbereitung enthält alle nötigen Informationen zur Vorbereitung der
Testausführung.
Testausführung:
Beinhaltet jegliche Testaktivitäten bzw. Daten, die zur Ausführung notwendig sind.
Testauswertung:
Die Ergebnisse hierzu werden auf verschiedenste weise bearbeitet.
Grundlegend ist jedoch zu erwähnen, daß hier sämtliche Ergebnisse protokolliert
werden, um eine Teststatistik zu erstellen.
Die beiden unten angeführten Graphiken sollen hierzu einen Einblick über den
Ablauf des Testes ermöglichen.
Abbildung 9 – Zusammenwirken der Testaktivitäten für das Testen ohne Ablauf mit
Testdaten [Schmitz 1982 S. 93]

Testen von Software: Ziele, Begriffe und Methoden 30
Abbildung 10 – Zusammenwirken der Testaktivitäten zur Ausführung eines Testobjekts mit
Testdaten beim dynamischen Testen [Schmitz 1982 S. 94]
4.2.1 Testvorbereitung
4.2.1.1 Checklisten
Checklisten dienen zur Erstellung von Analysepunkten beim nicht-automatisierten
Testen. Somit können die Grundlagen für Testaktivitäten aufgezeichnet werden und
erhalten zusätzlich Bedeutung für gewisse Testziele.
Zur Erstellung von Checklisten können folgende Methoden verwendet werden:
• Übernahme vorgegebener Standard-Checklisten
• Modifikation vorgegebener Standard-Checklisten
• Erstellung individueller Checklisten.

Testen von Software: Ziele, Begriffe und Methoden 31
Abbildung 11 – Checkliste mit Umgebungsstruktur [Steindl 2000 S. 60]
4.2.1.2 Verwendungsnachweise von Elementen
Verwendungsnachweise sind Sammlungen von Informationen, welche
Informationen über die Elemente eines Testobjekts und dessen Verwendung
beinhalten.
Jene Nachweise können für jedes beliebige Testobjekt formuliert werden was sowohl
Dokumente als auch Programme beinhaltet.
4.2.1.3 Testfallermittlung
Ein Testfall besteht aus allen Eingabedaten, die für die Testausführung eines
Testobjektes zur Verfügung stehen. Die Testfallermittlung ist somit das bestimmen
jener Menge von Daten um einen komplexen Softwaretest durchzuführen.
Vollständiges Testen ist mit Testdaten in der Regel (auch bei kleinen Testobjekten)
grundsätzlich nicht möglich, was dazu führt, daß im wesentlichen nicht alle Fehler
korrigiert bzw. vermieden werden können.
Ein wichtiger Punkt hierzu ist die gegebenen Ressourcen (Zeit, Kosten) optimal
auszunützen um möglichst gute Fehlerergebnisse zu erzielen.

Testen von Software: Ziele, Begriffe und Methoden 32
4.2.1.4 Testdatenerstellung
Signifikant hierzu ist die Bereitstellung von Testdaten. Testdaten selbst werden in
die Kategorien Normal-, Falsch- und Grenzwerte eingeordnet.
Abbildung 12 – Normal-, Falsch- und Grenzwerte [Steindl 2000 S. 72]
Methoden zur Erstellung passender Daten sehen wie folgt aus:
• Konstruktion von Testdaten: hierbei ergeben sich Daten aus der
vorausgegangenen Testfallermittlung
• Selektion von Originaldaten: ist dann zutreffend, wenn reale Testfälle
(qualitativ oder auch quantitative Daten) aus der Arbeitsumgebung in die
Erstellung der Testdaten einfließen.
Abbildung 13 – Verwendung der Methoden zur Testdatenerstellung in den Testphasen des
Programmtestens [Schmitz 1982 S. 120]

Testen von Software: Ziele, Begriffe und Methoden 33
4.2.1.5 Soll-Ergebnis-Ermittlung
Ziel der Soll-Ergebnis-Ermittlung ist es erwartete Ergebnisse im vorhinein zu
errechnen um später Vergleiche zu den Ist-Ergebnissen zu erstellen.
Soll-Ergebnisse können auf zwei verschiedene Arten ermittelt werden.
• datenorientiert: Bestimmung der Werte von Datenelementen
• produktorientiert: Bestimmung von Strukturelementen eines Testobjekts
4.2.1.6 Testumgebung
Die Testumbebung beinhaltet das bereitstellen von externen Schnittstellen des
jeweiligen Testobjekts und muß das Verhalten desselben im Testlauf auch
nachbilden bzw. aufzeichnen können. Diese Aufzeichnungen bestehen aus der
Übernahme der Steuerung und dessen Daten plus der Rückgabe dieser.
Grundsätzlich gibt es drei Arten von Schnittstellen:
• Treiber (wird dem Testobjekt vorgeschaltet und versorgen somit das
Testobjekt mit Testdaten)
• Platzhalter (ist ein Modul, welches einen nicht vorhandenen Baustein
ersetzen soll.
• Inversion (beinhaltet die Änderung des Testobjekts, falls es sich um ein
Unterprogramm handelt)
Abbildung 14 – Testumgebung für das Testen des Programmbausteins ‚B2’Schematische
Darstellung [Schmitz 1982 S. 126]

Testen von Software: Ziele, Begriffe und Methoden 34
4.2.1.7 Testprozedur
Beinhaltet jegliche Aktivitäten zur Erstellung der Prozeduren für die Testausführung.
Wesentlicher Bestandteil ist das Erstellen aller Steueranweisungen in der Job-
Control-Language um die statische Testausführung des Testobjekts automatisiert
durchführen zu können bzw. die Testausführung durch Ablauf des Testobjekts auf
einer Anlage zu ermöglichen.
4.2.2 Testausführung
4.2.2.1 Statische Testausführung
Die statische Testausführung umfaßt die Testaktivitäten, die beim Testen ohne
Ablauf mit Testdaten zur Fehlererkennung erforderlich sind, deshalb wird jene
Ausführung meist zum Testen von Programmen verwendet. Dokumente werden
hiermit zwar auch getestet, jedoch in einem wesentlich geringeren Ausmaß.
Die Bedeutung der statischen Testausführung ergibt sich neben wirtschaftlichen
Aspekten daraus, daß teilweise Testaufgaben nur statisch realisiert werden können.
Beim Verwenden der statischen Testausführung sollen nachfolgende Testaktivitäten
unterschieden werden:
• Analyse der Einhaltung von Darstellungskonventionen
• Analyse der Dokumentationseigenschaften
• Analyse der Komplexität
• Analyse der Kontrollstruktur
• Analyse des Datenflusses
• Analyse des Detaillierungsgrades
4.2.2.2 Dynamische Testausführung
Es werden jegliche Testfälle erprobt, welche Daten zur Ausführung erfordern.
Testaktivitäten hierzu sind: [Schmitz 1982 S. 128]
• Ausführung des Testobjekts: ist der reale Ablauf auf einer ADV-Anlage
• Simulation einer Testumgebung: Es werden reale Umgebungen simuliert,
wobei die Testumgebung Elemente eines ADV-Systems repräsentiert, die für
die dynamische Testausführung eines Testobjekts notwendig, aber nicht
vorhanden sind.

Testen von Software: Ziele, Begriffe und Methoden 35
• Ablaufprotokollierung: Es wird der chronologische Ablauf aufgezeichnet um
später einzelne Schritte nachvollziehen zu können.
Objekte hierzu sind:
o Kontrollfluß (Durchlauf durch Programmpunkte in Form eines
Protokolls)
o Datenfluß (protokolliert werden Zustandsänderungen von Variablen)
• Erstellen einer Ablaufstatistik: ermittelt Daten des Ablaufprotokolls
(beispielsweise: Durchlaufhäufigkeiten an definierten stellen im Testobjekt,
Nutzugshäufigkeiten von Datenelementen oder angenommene Wertebereiche
von Datenelementen)
4.2.3 Testauswertung
In der Testauswertung werden alle Testaktivitäten beinhaltet. Im einzelnen sind dies
• die Ergebnisprüfung
• die Testergebnisprotokollierung und
• das Erstellen der Teststatistik
4.2.3.1 Ergebnisprüfung
Die Ergebnisprüfung vergleicht die Soll-Daten mit den Ist-Daten, womit eine
Charakterisierung der Fehler möglich ist.
Man unterscheidet hier zwei Arten von Ergebnissen:
• datenorientierte Ergebnisse (beziehen sich auf den Inhalt von
Datenelementen während der Testausführung oder am Ende der
Testausführung, d.h. auf Zwischen- und Endergebnisse)
• produktorientierte Ergebnisse (beziehen sich auf Strukturelemente des
Testobjekts und deren Ausführung im Testablauf – beinhaltet eine
wesentliche Bedeutung beim Testen von Programmen)
Die Formen selbst lassen sich in zwei Gruppen einteilen
• Ergebnisprüfung nach dem Ablauf (Ist-Soll-Ergebnisse werden bei
Endergebnissen verglichen)
• Ergebnisprüfung während des Ablaufs (Ist-Soll-Ergebnisse werden mittels
Zwischen- und Ergebnissen verglichen

Testen von Software: Ziele, Begriffe und Methoden 36
4.2.3.2 Testergebnisprotokollierung
Die Ergebnisse werden hier in Protokollform gespeichert um eine spätere
unabhängige Weiterverarbeitung zu garantieren.
Protokolliert werden (meist) folgende Daten:
• Durchgeführte Testaktivitäten
• beteiligte Personen bei der Testausführung
• bearbeitete Analysepunkte einer Checkliste
• Erfassung der Ist-Ergebnisse der Testausführung
• Erfassung und Charakterisierung eines erkannten Fehlers
4.2.3.3 Erstellen der Teststatistik
Hierzu werden meist die Ergebnisse kumuliert (über mehrere Testläufe) um
Ablaufstatistiken zu erstellen.
Häufige Größen der Teststatistiken:
• Testmaßzahlen
• Nicht-durchlaufene bzw. nicht fehlerfrei durchlaufene Strukturelemente
• Gesamtzahl der Erkannten Fehler
• (Testaufwand)
Zweck von Teststatistiken:
• Bereitstellung von Informationen für Testdatenerstellungen
• Bereitstellung von verdichteten Daten für weitere Vorgehensweise beim
Testen
• Breitstellung von Statistiken über Fehlerfindung und Fehlerbehebung
• Bereitstellung von Daten zur Entscheidung über die Freigabe oder Abnahme
von Produkten im Rahmen der Testkontrolle und Qualitätskontrolle

Testen von Software: Ziele, Begriffe und Methoden 37
Abbildungsverzeichnis
Abbildung 1 - Fehlerterminologie [Steindl 2000 S. 36]...........................................10
Abbildung 2 - Fehlerarten [Steindl 2000 S. 37].......................................................10
Abbildung 3 - Das Pestizid Paradoxon [Steindl 2000 S. 9]......................................13
Abbildung 4 – Software Lebenszyklus [Steindl 2000 S. 6]......................................16
Abbildung 5 - Testfallmatrix [Heinrich 2000 S. 414] ..............................................19
Abbildung 6 - Zusammenhang zwischen den Testarten [Heinrich 2000 S. 416] ......22
Abbildung 7 – Codeinspektion [Steindl 2000 S. 61]................................................25
Abbildung 8 – Zusammenwirken der Klassen von Testaktivitäten [Schmitz 1982 S.
90] ..................................................................................................................28
Abbildung 9 – Zusammenwirken der Testaktivitäten für das Testen ohne Ablauf mit
Testdaten [Schmitz 1982 S. 93].......................................................................29
Abbildung 10 – Zusammenwirken der Testaktivitäten zur Ausführung eines
Testobjekts mit Testdaten beim dynamischen Testen [Schmitz 1982 S. 94].....30
Abbildung 11 – Checkliste mit Umgebungsstruktur [Steindl 2000 S. 60] ................31
Abbildung 12 – Normal-, Falsch- und Grenzwerte [Steindl 2000 S. 72]..................32
Abbildung 13 – Verwendung der Methoden zur Testdatenerstellung in den
Testphasen des Programmtestens [Schmitz 1982 S. 120].................................32
Abbildung 14 – Testumgebung für das Testen des Programmbausteins
‚B2’Schematische Darstellung [Schmitz 1982 S. 126].....................................33

Testen von Software: Ziele, Begriffe und Methoden 38
Literaturverzeichnis
[Beizer 1990]
[Beizer 1995]
[Heinrich 2000]
[Jorgensen 1995]
[Kowalk 1993]
[Müllerburg 1996]
[Myers 1989]
[Parrington 1990]
[Pomberger 1996]
[Schmitz 1982]
[Steindl 2000]
Boris Beizer: Software Testing Techniques, Second Edition,
Van Nostrand Reinhold, 1990
Boris Beizer: Black-Box Testing: Techniques for Functional
Testing of Software and Systems, Wiley, 1995
Lutz J. Heinrich: Management von Informatik-Projekten,
Teil B, 6., korrigierte Aufl., Skriptum, 2000, S. 408-418
Paul C. Jorgensen: Software Testing: A Craftsman’s
Approach, CRC Press, 1995
Wolfgang P. Kowalk: Korrekte Software: Semantik,
Spezifikation, Verifikation und Testen von Programmen, BI-
Wiss.-Verl., 1993
Monika Müllerburg: Gesellschaft für Informatik/Fachgruppe
Test, Analyse und Verifikation von Software: Test, Analyse
und Verifikation von Software, aus der Arbeit der
Fachgruppe 2.1.7 Test, Analyse und Verifikation von
Software (TAV) der Gesellschaft für Informatik (GI),
Oldenburg, 1996
Glenford J Myers: The Art of Software Testing
Methodisches Testen von Programmen, 3. Aufl.,
Oldenbourg, 1989
Norman Parrington, Marc Roper: Understanding Software
Testing Software-Test: Ziele, Anwendungen,
Methoden, McGraw-Hill, 1990
Gustav Pomberger, Günther Blaschek: Software Engineering,
Prototyping und objektorientierte Software-Entwicklung, 2.
Aufl., Carl Hanser, 1996, S. 146-160
Paul Schmitz, Heinz Bons, Rudolf van Megen: Testen im
Software-Lebenszyklus, Braunschweig, 1982
Christoph Steindl: Testen von Softwaresystemen, Unterlagen
zur kombinierten Lehrveranstaltung, Skriptum, 2000