Software Engineering I

Software Testen

Martin Pinzger
Software Engineering Research Group
University of Klagenfurt
!
!

Follow: @pinzger #SEI_AAU

bersicht
Einfhrung
Teststrategien
Funktionales Testen (Black-Box)

4-2

Einfhrung
Qualitt
Qualitt ist die Gesamtheit von Merkmalen (und Merkmalswerten) eines
Produktes bezglich seiner Eignung, festgelegte und vorausgesetzte
Erfordernisse zu erfllen [ISO 8402]

Qualittsstandards helfen,
die Softwarequalitt zu verbessern bzw. zu sichern
Fehler zu vermeiden oder diese zumindest leichter auffindbar zu machen
Kosten zu sparen (auf Dauer gesehen)

4-3

Qualittseigenschaften (Xxx-ilities)
Korrektheit (correctness)

Wiederverwendbarkeit (re-usability)

Zuverlssigkeit (reliability)

Sicherheit (security)

Testbarkeit (testability)

Robustheit (robustness)

Effizienz (efficiency)

Modularitt (modularity)

Verstndlichkeit (understandability)

Flexibilitt (flexibility)

Portabilitt (portability)

Gebrauchstauglichkeit (usability)

Wartbarkeit (maintainability)

...

4-4

Manahmen zur Qualittssicherung

Organisatorische Manahmen
Standards: Review, Audit, Walkthrough, Checklists, etc.
Einfhrung eines Qualittsmanagementsystems (QMS)
QMS Identifizierung und Lsung von Qualittsproblemen
Verbesserung des QMS

Konstruktive Manahmen
Planung, Vorgehensmodelle, Dokumentation, Schulungen, etc.

Analytische Manahmen
Tests, berprfungen (inspection), Verifikation, Metriken, etc.
-> Zur Erkennung von Fehlern

4-5

Was ist Testen?

Einige Definitionen
Program testing can be used to show the presence of defects, but never their
absence. [Dijkstra, 1972]
Testing is the process of executing a program or system with the intent of
finding errors. [Myers, 1979]
Testing is any activity aimed at evaluating an attribute or capability of a
program or system and determining that it meets its required results. [Hetzel,
1983]
Testing is the process of exercising or evaluating a system or system
component by manual or automated means to verify that it satisfies specified
requirements, or to identify differences between expected and actual
results. [IEEE]

Ziel: Durch das Testen will man Fehler finden (und zwar so viele wie
mglich und so frh wie mglich!)
4-6

Was ist Testen? (forts.)

Testen ist der Prozess, ein Programm mit der Absicht auszufhren,
Fehler zu finden
Sehr wichtig:
Die Korrektheit eines Programms kann durch Testen nicht bewiesen werden
Um sicherzustellen, dass ein Programm fehlerfrei ist, mssen alle Kombinationen
aller mglichen Werte der Eingabedaten getestet werden

4-7

Wieviele Testflle braucht man

um folgende Methoden vollstndig zu testen?
public int computeMin3(int x, int y, int z) { !
int a;!
if (y > x)!
a = min(x, z); // min() berechnet das Minimum zwischen 2 Zahlen!
else!
a = min(y, z);!
return a;!
}
public void computeCount(int x, Integer count) {!
if (count < 20 && x%2 == 0)!
count += 20;!
else!
count -= 20;!
}
public void doSomething() {!
if (cond1) !
if (cond2)!
if (cond3)!
!
}
4-8

Software Testen vs. Verifikation

Durch Testen kann man nur die Anwesenheit von Fehlern feststellen,
nicht aber ihre Abwesenheit
Verifikation ist der formale (mathematische) Beweis, dass das
Programm korrekt ist
Anwendung von mathematischen Beweisen
Basiert auf verschiedenen formalen Techniken

In diesem Sinne ist Testen etwas unzuverlssig!

Aber Testen bleibt wichtig, um die Softwarequalitt und das
Vertrauen in die Korrektheit eines Programms zu erhhen
Durch gezielte Probelufe werden Fehler erkannt

4-9

Error, Fault, Failure

Error (Fehler)
Ein Error ist die Ursache des Problems

Fault
Ein Fault ist ein Zustand des Systems, der ohne Korrekturmanahmen zu einem Ausfall
(Fehlverhalten) fhrt

Failure (Fehlverhalten)
Ein Fehlverhalten tritt auf, wenn das externe Verhalten nicht der Spezifikation entspricht
Error

Implementierung

Fehler/Bug/Defekt
Fault

Effekt auf das Programm (inkorrekte Anweisungen)

Failure

Inakzeptables Verhalten
4-10

Fehlerbehandlung
Fault Handling

Fault Avoidance

Design
Methodology

Verification

Fault Tolerance

Fault Detection

Atomic
Transactions

Reviews

Modular
Redundancy

Configuration
Management
Testing

Unit
Testing

Integration
Testing

System
Testing

Debugging

Acceptance
Testing

Correctness
Debugging

Performance
Debugging

[Brugge & Dutoit, 1998]

4-11

Validierung und Verifikation

Validierung ist die berprfung, dass ein Programm oder System die
Anforderungen des Kunden in der Praxis erfllt (meist mit externen
Kunden)
Baue ich das richtige Produkt?
Funktioniert das System richtig?

Verifikation ist die berprfung, dass ein Programm oder System die
spezifizierten Anforderungen erfllt (meist ein interner Prozess)
Baue ich das Produkt richtig?

Nach einer positiven Verifizierung eines Programms, kann dieses bei

der Validierung immer noch durchfallen
Zum Beispiel, wenn die Spezifikation nicht vollstndig den Anforderungen des
Kunden entspricht
4-12

Testebenen

Validierung

Kunde

Hohe
Ebene

Anforderungsanalyse

Anwendungsszenarien

Abnahmetest

sts

Entwickler
Komponentenentwurf

Testflle

Integrationstest

Implementierung

Testflle

Modultest

sts

Te
von

Niedrige
Ebene

n Te

llen

g vo

Systemtest

Aus
fh
run

Testflle

Verifikation

itste

Bere
Systementwurf

4-13

Arten von Tests

Unit-Test
testet die kleinste funktionale Einheit (Funktion, Prozedur)

Modultest (Komponententest)
berprft, ob das Verhalten des Moduls dem Design entspricht

Integrationstest
berprft die Integration von Komponenten (Fokus liegt auf Kommunikations- und
Schnittstellenfehler)

Systemtest
hnlich wie Integrationstest, aber gewhnlich gehren dazu Funktionstest und
Tests nicht-funktionaler Anforderungen (Leistung, Sicherheit, Usability, etc.)

4-14

Arten von Tests (forts.)

Abnahmetest, Akzeptanztest
berprft, ob das System den Anforderungen des Kunden entspricht

Alpha-Test
eine frhe Prfung des Systems von Benutzern innerhalb der
Entwicklungsorganisation

Beta-Test
letzte Prfung des Systems vor der Freigabe durch den Kunden (bzw. potentielle
Kunden)

Funktionstest
berprft das Verhalten der Funktion, ob es dem erwarteten Verhalten entspricht

4-15

Arten von Tests (forts.)

Benchmarktest
vergleicht die Leistung des Systems mit vorhandenen Standards (z.B. andere
Systeme, Metriken)

Konfigurationstest
berprft das Verhalten des Systems mit verschiedenen Konfigurationen
(Hardware und Software)

Installationstest
berprft die Softwareinstallationsroutinen in verschiedenen
Systemumgebungen (z.B. unterschiedliche Betriebssystemversionen,
verschiedene Konfigurationen)

Leistungstest (performance test)

berprft, ob die Leistung (mit unterschiedlichen Konfigurationen), whrend der
betrieblichen Bedingungen stabil bleibt
4-16

Arten von Tests (forts.)

Lasttest (load test)
berprft die Leistung des Systems unter verschiedenen Betriebsbedingungen
(Anzahl der Benutzer, Anzahl der Transaktionen, ber lngeren Zeitraum, etc.)

Belastungstest (stress test)

berprft die Leistung des Systems bei extremer Belastung (z.B. extrem hohe
Anzahl von Benutzern). Ressourcen werden whrend des Tests nicht erhht ->
Ausnahmesituationen

Usability Test
Die potentiellen Benutzer berprfen die Gebrauchstauglichkeit einer Software
(verschiedene Benutzerklassen und unter unterschiedlichen
Betriebsbedingungen)

4-17

Vorgehensweise beim Testen

Testplanung
Was -> Module / Eigenschaften
Wie -> Methodik / Dokumente
Wie lange -> Kosten und Zeit
Wann -> Termine (Vorbereitung, Durchfhrung und Auswertung)
Wer -> Team

Testvorbereitung
Spezifikation der Testflle (reprsentativ, stark, redundanzfrei)
Identifizierung der Testumgebung
Identifizierung der Testwerkzeuge

4-18

Vorgehensweise beim Testen (forts.)

Testdurchfhrung
Testumgebung einrichten
Testflle schrittweise ausfhren
Tests in Protokollen dokumentieren (Fehlermeldungen)
Code whrend des Tests nicht verndern

Abschluss und Auswertung

Resultate zusammenstellen

Fehlerbehebung
Analyse der entdeckten Fehler
Debugging: Bestimmung der Ursachen
Behebung der Fehler (z.B. im Source Code)
4-19

Beispiel eines Testzyklus

Schritt 1: Welche Funktionalitten werden getestet?
Schritt 2: Spezifikation der Entwurfselemente, die getestet werden
Schritt 3: Spezifikation von Teststrategie, Testplan, und Testflle (testbed)
Schritt 4: Spezifikation der Testprozeduren, Szenarien, Flle und Scripts
Schritt 5: Ausfhrung der Tests und Protokollierung
Schritt 6: Generierung von Metriken, um zu entscheiden, ob der Code fr
den Release bereit ist
Schritt 7: Nach Fehlerbehebung, goto Schritt 5 (wiederhole alte Testflle > Regression)
4-20

Testabdeckung (Test Coverage)

Verhltnis an tatschlich getroffenen Aussagen eines Tests
gegenber den theoretisch mglich treffbaren Aussagen
Es gibt verschiedenste Metriken zur Messung der Testabdeckung ->
berdeckungskriterien
berdeckungkriterien werden oft zur Messung der Qualitt der Tests
verwendet
Hhere Abdeckung ~ bessere Qualitt der Tests

Testabdeckung lsst sich durch die Erhhung der Zahl an Testfllen

verbessern
Jedoch steigen damit auch die Kosten fuers Testen
4-21

Strategie: Funktionales Testen (Black-Box)

Tester hat keine Kenntnisse ber das interne Verhalten und die Struktur
des Codes (Code ist eine Black-Box)
Ausgangspunkt ist die Spezifikation - Auswahl erfolgt nach
den Eigenschaften der Eingabe
der Spezifikation
dem Design

Techniken: quivalenzklassenbildung, Grenzwertanalyse, etc.

Verschiedene berdeckungskriterien
Funktionsberdeckung
Attributberdeckung
Ausgabeberdeckung
Ausnahmeberdeckung
4-22

Strategie: Strukturiertes Testen (White-Box)

Der Tester kennt die innere Struktur (den Source Code) des
Programms
Die Struktur des Programms ist die Grundlage fr das White-Box Testen

Technik: Testflle werden mit Hilfe des Kontrollflusses und des

Datenflusses des Programms erzeugt
Programmablufe und Datenflsse werden berprft
Aber die Spezifikation muss auch bekannt sein

Verschiedene berdeckungskriterien
Anweisungsberdeckung
Zweigberdeckung
Bedingungsberdeckung
Pfadberdeckung, etc.
4-23

Strategie: Kombiniertes Testen (Gray-Box)

Die interne Struktur des Programs ist (teilweise) bekannt
Interne Datenstrukturen und Algorithmen sind zugnglich, um
Testflle zu generieren
Die Prfung wird durch das Black-Box-Testen durchgefhrt

4-24

White-Box vs. Black Box Testen

Anforderungsanalyse

Anwendungsszenarien

Abnahmetest

Tes
ts
gv
on

Systemtest

s
Test
von

run

Testflle

Komponentenentwurf

Implementierung

Testflle

Testflle

Integrationstest

Modultest

Au
sf
h

llen

itste

Bere
Systementwurf

Funktional
Black-Box
Strukturell
White-Box

4-25

Funktionales Testen (Black-Box)

!
public int computeMin3 (int x, int y, int z) { !
!
// Implementierung ist nicht bekannt!
}

Testfall = (<x,y,z>, a)
<x,y,z> ist die Eingabe
a ist die erwartete Ausgabe

Ausfhrung der Methode mit <x,y,z> liefert a

Prfe: a=a
4-26

Auswahl der Testflle

Kriterien fuer die Auswahl
Strke (power)
Wenn es einen Fehler im Programm gibt, wird ihn der Test finden

Wert (value)
Tests zeigen, was Kunden wissen wollen (testen die Anforderungen der Kunden)

Minimalitt (minimality)
Anzahl der Testflle soll so gering wie mglich sein (redundanzfrei)

Etc.

Generierung der Testflle ist die wesentliche Aufgabe

Techniken: Random, quivalenzklassenbildung, Grenzwertanalyse, etc.

4-27

Grenzwertanalyse (Boundary Value Analysis)

Grenzwertanalyse betrachtet zwei Input-Klassen: gltige Inputs und
ungltige Inputs (auerhalb des gltigen Bereichs)
Grenzwertanalyse benutzt Testdaten, die am Rande des gltigen
Bereichs liegen
Grundlegende Idee
Fehler treten eher in der Nhe der Grenzwerte einer Eingabevariablen auf

Single Fault Assumption:

Fehlverhalten wird durch Fehler in einer einzigen Variablen ausgelst (kein
gleichzeitiges Auftreten von Fehlern)
Bei n Variablen bentigt man 4n + 1 Testflle

4-28

Grenzwertanalyse bei einer Variable

min min+
nominal

max- max

x1

a untere Grenze
b obere Grenze

4n + 1 = 5 Testflle werden erstellt

4-29

Grenzwertanalyse
bei zwei
Variablen
Boundary Value
analysis
Two variables

x2
d

c
a

x1

w many
tests
for erstellt
2, 3, , n variables?
4n +boundary
1 = 9 Testflle
werden

4n + 1

4-30

Beispiel: Blutdruckmessung
Boundary Value analysis
x2= diastolic
Range
200
High
90
Low

Normal

0
0

120

250

x1=systolic

1 Testfall mit nominal (x1=120) und nominal (x2=90)

2 Testfall mit nominal (x1=120) und niedrig (x2=5)
3 Testfall
4-31

Limitierung der Grenzwertanalyse

Grenzwerte sind nicht immer gegeben oder offensichtlich
Bei Aufzhlungen gibt es keine Grenzwerte
Grenzwerte testen keine negativen Flle
-> Erweiterung des Grenzwertanalyse zu Robustheitstesten
(Robustness Testing)

4-32

ension
of the Boundary
Analysis
Robustness
TestingValue
bei zwei
Variablen
mines the cases when the boundaries are slightly
Zustzliche
2 Werte:
max+, mineeded
(negative
testing)
x2
d

min-

max+

c
a

Wieviele Testflle werden bei n Variablen erzeugt?

x1
6n + 1
4-33

Limitierung von Robustness Testing

Der Hauptwert von Robustheitstests liegt im Testen von Exception
Handling
Zu bercksichtigen
In einigen stark typisierten Sprachen fhren Werte auerhalb des vordefinierten
Bereichs zu einem Laufzeitfehler
!

4-34

Worst Case Testing

Grenzwertanalyse (und Robustness Testing) basieren auf der Single
Fault Assumption
Worst Case Testing behandelt den Fall, wenn mehrere Variablen einen
Grenzwert aufweisen
-> Multiple Fault Assumption

Am besten geeignet, wenn Variablen komplexe Zusammenhnge

aufweisen
Bei n Variablen werden 5n Testflle erzeugt

4-35

WorstWorst
Case Testing
zwei Variablen
case bei
testing
x2
d

c
a

b
Min
Min+
nominal
Max
Max-

x1

Min
Min+
nominal
Max
Max-

many boundary tests for 2, 3, , n variables?

52 = 25 Testflle n

4-36

Robust Worst Case Testing (Paranoid Testing)

Robust von
Worst-Case
Kombination
Robustness mittesting
Worst Case Testing
(Paranoid Testing)
x2
d

c
a

x1

w many
boundary
forerzeugt?
2, 3, , n variables?
Wieviele
Testflletests
werden
n

4-37

Testen mit quivalenzklassen

Auch Equivalence/Domain Partitioning Testing (Equivalence Class
Testing ECT) genannt
Eine quivalenzklasse ist eine Menge von Eingabewerten, die auf ein
Programm eine gleichartige Wirkung ausben
Input1: X = X1 u X2
Input2: Y = Y1 u Y2
Input3: Z = Z1 u Z2 u Z3

Testfall = (iX, jY, kZ)

Wenn ein Eingabe (i,j,k) in einer quivalenzklasse (X2 x Y1 x Z3 ) zu einem Fehler
fhrt, werden alle anderen Eingaben in dieser Klasse mit der grten
Wahrscheinlichkeit zu dem gleichen Fehler fhren
-> wenn ein Testfall in einer quivalenzklasse keinen Fehler aufdeckt, so erwartet
man, dass alle anderen Testflle ebenfalls keine Fehler aufdecken wrden
4-38

Ziele von Testen mit quivalenzklassen

Vollstndiges Testen ist nicht mehr notwendig (Minimalitt)
Ermglicht dem Tester die Selektion von Testfllen (Eingaben), die mit
grosser Wahrscheinlichkeit Fehler aufdecken (Strke)
Ermglicht dem Tester die Abdeckung eines grossen Eingabe/
Ausgabe Bereiches mit einer Untermenge von Werten aus den
quivalenzklassen (Minimalitt)

4-39

Bilden von quivalenzklassen

Erfolgt auf Basis der Beschreibung von Eingabebedingungen in der
Spezifikation
Erstellen testbarer Anforderungen
Erstellen von korrekten und (mglichst) vollstndigen Input/Output Werten
Implementieren eines ersten Sets von Black-Box Testfllen, die iterativ erweitert
werden

Strategien zur Ableitung der Klassen [Myers, 1979]

Wertebereiche -> 1 Klasse mit Werten fuer den erlaubten Wertebereich, 2 Klassen
fuer die Abdeckung der ungltigen Werte kleiner bzw. grsser dem Wertebereich
Aufzhlung -> 1 Klasse mit allen erlaubten Eingabewerten, 1 Klasse mit allen
anderen Eingabewerten
Falls es Rckschlsse gibt, dass der Eingabewert einer Klasse nicht zum
gewnschten Verhalten fhrt, dann wird diese Klasse weiter zerlegt

4-40

Beispiel: Bilden von quivalenzklassen

Funktion mit Eingabewerten Base, New und Type
Wertebereiche fuer Eingaben
Base = 10,000 - 50,000
New = Y oder N
Type = A, B, C, X

Was sind mgliche quivalenzklassen?

Base: Base < 10,000; Base 10,000 - 50,000; Base > 50,000
New: New = Y oder N; New = X, A, B,
Type: Type = A, B, C, X; Type = D, E, F,

4-41

Path und Code Coverage mit quivalenzklassen

Beispiel: Funktion mit Eingabewerten Base, New und Type
Base: Base < 10,000; Base = 10,000 - 50,000; Base > 50,000
New: New = Y oder N; New = X, A, B,
Type: Type = A, B, C, X; Type = D, E, F,

Path Coverage -> Testen aller mglichen Kombinationen (Pfade)

3 x 2 x 2= 12 Testflle
-> Strong ECT

Code Coverage -> Minimale Anzahl von Testfllen, um mglichst alle

Statements auszufhren
max(3, 2, 2) = 3 Testflle
-> Weak ECT
4-42

Weak ECT
Aus jeder quivalenzklasse muss ein Wert getestet werden
Klasse b < x1 < c

Nicht alle Kombinationen werden getestet, so dass mgliche Fehler nicht

gefunden werden knnen

x2
g

Klasse f < x2 < g

f
e

x1
a

d
43
4-

Strong ECT
Jede quivalenzklasse muss mit (mind.) einem Wertetupel getestet
werden
Jede mgliche Kombination von quivalenzklassen wird getestet mglicherweise sind nicht alle sinnvoll

x2
g
f
e

x1
a

4-44

Weak Robust ECT

Anwendung des Weak ECT unter Bercksichtigung von ungltigen
Eingabewerten
Fr gltige Eingaben verwendet man einen Wert aus den jeweils gltigen Klassen
(-> Weak ECT)
Fr ungltige Eingaben besteht ein Testfall aus einem ungltigen Wert, die
restlichen Werte des Testfalls sind alle gltig (-> Robust ECT)
Gltiger Input:!
a <= x1 <= d!
e <= x2 <= g!
!
Ungltiger Input:!
x1 < a!
x1 > d!
x2 < e!
x2 > g

x2
g
f

x1
a

d
4-45

Strong Robust ECT

Anwendung des Strong ECT unter Bercksichtigung von ungltigen
Eingabewerten
Jede gltige und ungltige quivalenzklasse muss mit mind. einem Wertetupel
getestet werden

Gltiger Input:!
a <= x1 <= d!
e <= x2 <= g!
!
Ungltiger Input:!
x1 < a!
x1 > d!
x2 < e!
x2 > g

x2
g

e
x1
a

d
4-46

Beispiel: Autoversicherung
A car insurance company Simplicity provides insurance cover for
motor vehicles.
When a customer applies for a quote on insurance, the agent
requests the following information:
Vehicle type
Age of the driver

The system outputs a quote for insurance

Exercise: define test cases for Code Coverage and Path Coverage

4-47

Interview zur Erstellung der Spezifikation

Q: "Do you treat all types of vehicles alike?"
A: "No. We insure cars, trucks, vans, and motorcycles. We have a
different way of getting a quote for each type."
Q: "Do you treat all ages the same way (even though they give a
different number for the quote?)"
A: "Well, not exactly. There are three classes of age: the under 21 kids,
the great middle aged group from 21 to 65, and the Golden Oldies who
are over 65. We do it differently for each group."

4-48

Car insurance example

Was sind die quivalenzklassen?

Vehicle type
Cars
Trucks
Vans

Age
<21
21 - 65
> 65

Motorcycles

4-49

Car insurance example

Code Coverage - Weak ECT

Code coverage

Vehicle type

!
!

Cars
Trucks
Vans

Age
<21
21 - 65
> 65

> 65
21 - 65
<21

!
Motorcycles

!
How many tests?

4 = max (4, 3)

Wieviele Testflle sollten gemss Weak ECT erstellt werden?

max(4,3) = 4

4-50

Car insurance example

Code Coverage - Weak ECT

Code coverage

> 65
21 - 65
<21
Cars
How many tests?

Trucks

Vans

Motorcycles

4 = max (4, 3)

4-51

Car insurance example

Path Coverage - Strong ECT

Path coverage

Cars
Trucks
Vans

<21
21 - 65
> 65

>6

21 - 6

<2

Motorcycles

How many tests?

12 = 4 x 3

Wieviele Testflle sollten gemss Strong ECT erstellt werden?

4 x 3 = 12

4-52

Car insurance example

Path Coverage - Strong ECT

Path coverage

> 65
21 - 65
<21
Cars

Trucks

Vans

Motorcycles

Sind alle How

Testflle
manynotwendig?
tests?

12 = 4 x 3
Fahren von Trucks mit unter 21 Jahren?

Fahren von Motorrdern mit ber 65 Jahren?

4-53

Random Testing
Auswahl der Testflle basiert auf einer Wahrscheinlichkeitsverteilung
(siehe auch [Musa, 93])
Uniform: Testflle werden mit gleicher Wahrscheinlichkeit aus der gesamten
Eingabe-Domne ausgewhlt
Operationell: Testflle werden aus einer Verteilung, die durch gesammelte
historischen Daten definiert wird, gezogen
Auswahl der Eingabedaten entspricht annhernd der tatschlichen Verteilung der Eingabedaten bei
Nutzung der Software

Fehlerhufigkeit = #Fehler / #Eingaben -> Vertrauen (Confidence)

Random Testing kann auch fr quivalenzklassen angewendet
werden
Fehlerhufigkeit = #Fehler (Klasse) / #Eingaben (Klasse)

4-54

Weitere Black-Box Testing Methoden

Cause-and-Effect Graphing
State Transition Testing
Error Guessing
!

4-55

Literatur
Balzert H., Lehrbuch der Software Technik: Software Management, Software Qualittssicherung,
Unternehmensmodellierung, Spektrum Akademischer Verlag, 1998.
Beizer B.: "Software Testing Techniques"; van Nostrand Reinhold, 1983.
Beizer B.: Black- Box Testing: Techniques for Functional Testing of Software Systems, J. Wiley,
1995.
Bruegge, B. and Dutoit, A.: Object-Oriented Software Engineering: Using UML, Patterns, and
Java, 2nd ed., Prentice Hall, 2004.
Burnstein, I., Practical Software Testing, Springer-Verlag, 2003
Jorgensen Paul C.:Software Testing: A Craftsmans Approach, 2nd ed., CRC Press, 2002
Kaner C., Falk J., Nguyen Hung Q.: Testing Computer Software , Wiley &Sons, 1999.
Musa, J. Operational profiles in software-reliability engineering, IEEE Software, March 1993, pp.
1432.
Myers, G. "The Art of Software Testing", Wiley, 1979
4-56