Kein Folientitel

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Übersicht
Inhalt:
 Testkonzept/-plan
 Testarten, -stufen und -phasen
 Testmethoden für black box testing
 Testmethoden für white box testing
 Kontrollflussbasiert
 Datenflussbasiert
 Testszenarien und Testfälle
 Unittest
 Integrationstest
 Testabschlusskriterien
 Fehlermanagement
Datei: TestenVorlesung.ppt
Seite 1
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Testkonzept/-plan
• Im Testkonzept (häufig auch bezeichnet als Testplan) werden zuerst die geplanten
Testarten (auch bezeichnet als Teststufen bzw. Testphasen) festgelegt (s. nächste
Seite).
• Dabei wird für jede Testart folgendes festgelegt:
• Ziel
• Zuständigkeit (für Koordination, Durchführung und Abnahme)
• Zeitraum der Durchführung
• Testmethode
• Aufwandsabschätzung
• Testumgebung (incl. Tool):
• Treiber für benötigte Testdaten
• Treiber für erforderliche Aufrufmodule
• Simulation der aufgerufenen Module
Seite 2
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Testarten/-phasen/-stufen
Testart
häufig bezeichnet als
Ziel
Unittest
Komponententest, Modultest,
Produkttest
Sicherstellung der Funktionsfähigkeit von Schnittstellen
und Systemfunktionen
Technischer
Integrationstest
delivery acceptance test
Sicherstellen, daß die entwickelte Komponente technisch
ablauffähig ist
Anwendungstest
application integration test
Sicherstellung der Funktionsfähigkeit des Gesamtsystems
Integrationstest
business integration test
Sicherstellung der Durchgängigkeit von Prozessen unter
Einbindung der angrenzenden Systeme, d.h.
Sicherstellung der fachlichen Integration
Rollentest
Sicherstellung der Funktionsfähigkeit der mit den Rollen
verbundenen Berechtigungsprüfungen
Performancetest
(Systemtest), Volumentest
Frühzeitiges Feststellen von Performance-Problemen auf
Basis von Echtdaten
Regressionstest
Upgradetest
Sicherstellung des Produktivbetriebs bei Einspielen von
neuen Releases
Recoverytest
Backuptest
Sicherstellung des korrekten Neuaufsetzens nach einem
Systemstillstand
Inbetriebnahmetest
Systemtest
Sicherstellung der Funktionsfähigkeit der wichtigsten
Schnittstellenanbindungen
Installationskontrolltest, operations
readyness test
Sicherstellen der IT-technischen Integration, d.h. u.a.
dass die Anwendung weiterhin den
Betriebsanforderungen entspricht.
Seite 3
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Testmethoden
Black Box Testing (funktionsorientiertes Testen)
• Spezifikation des Testobjekts als Ausgangspunkt der Testdatenermittlung
• Testdaten werden in Klassen eingeteilt, bei jedem Repräsentant einer Klasse verhält
sich das Testobjekt gleich
• Qualität der Testdaten hängt ab von der Aussagekraft der Spezifikation
• Es kann nicht ermittelt werden, ob das Programm mehr tut als es soll
(Computerkriminalität)
White Box Testing (strukturorientiertes Testen)
• Programmtext als Ausgangspunkt der Testdatenermittlung
• möglichst viele Programmabläufe werden ausgeführt
• unterschiedliche Überdeckungen werden angestrebt (C0, C1, …)
• Programme können getestet werden, für die keine Spezifikation vorliegt
• vergessene Teile der Spezifikation können nicht gefunden werden
• es ist nicht erkennbar, ob die getesteten Anweisungen im Betrieb überhaupt
ausgeführt werden
Seite 4
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Black Box Testing: Testziele
Mögliche Testziele (einzeln oder in Kombination):
•
Funktionsüberdeckung: jede spezifizierte Funktion mindestens einmal
aktiviert
•
Ausgabeüberdeckung: jede spezifizierte Ausgabe mindestens einmal erzeugt
•
Ausnahmeüberdeckung: jede spezifizierte Ausnahme- bzw. Fehlersituation
mindestens einmal erzeugt
•
Attributüberdeckung: alle geforderten Attribute (soweit technisch möglich)
getestet
•
insbesondere Erreichung der spezifizierten Leistungsanforderungen
–
unter normalen Bedingungen
–
unter möglichst ungünstigen Bedingungen (Belastungstest)
Seite 5
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Black Box Testing: Verfahren
Problem der Testfall-Auswahl: die gewählten Testziele mit möglichst wenig und
möglichst guten Testfällen umsetzen
Klassische Techniken:
•
•
•
•
•
Äquivalenzklassenbildung: Gleichartige Eingabedaten werden zu Klassen zusammengefasst
und aus jeder Klasse wird ein Repräsentant getestet
Grenzwertanalyse: An den Grenzen zulässiger Datenbereiche treten erfahrungsgemäß häufig
Fehler auf; Testfälle für solche Grenzfälle auswählen
Ursache-Wirkungsgraphen: systematischen Bestimmung von Eingabedaten, die ein
gewünschtes Ergebnis bewirken
Statistisches Testen (random testing): Eingabedaten werden zufällig ausgewählt; die gezielte
Testfall-Auswahl wird durch eine große Zahl von Testfällen ersetzt; Problem: Auswahl der
Eingabedaten muss der tatsächlichen Verteilung der Eingabedaten im produktiven Betrieb der
Software entsprechen
Fehler raten (error guessing): Intuitive Testfallauswahl aufgrund von Erfahrung; ergänzt andere
Methoden zur Testfallbestimmung; Qualität stark von Erfahrung und Intuition der Tester abhängig
Seite 6
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Black Box Testing: Übung
Gegeben sei ein Programm, das folgende Spezifikation erfüllen soll:
Das Programm fordert zur Eingabe von drei nicht negativen reellen Zahlen auf und liest die
eingegebenen Werte; es interpretiert die eingegebenen Zahlen als Strecken a, b und
c und untersucht, ob die drei Strecken ein Dreieck bilden, und klassifiziert gültige
Dreiecke.
Das Programm liefert folgende Ausgaben:
•
kein Dreieck wenn a+b <= c oder a+c <= b oder b+c <= a
•
gleichseitiges Dreieck, wenn a=b=c
•
gleichschenkliges Dreieck, wenn a=b oder b=c oder a=c
•
unregelmäßiges Dreieck sonst
Das Programm zeichnet ferner alle gültigen Dreiecke winkeltreu und skaliert in einem
Fenster der Größe 10x14 cm auf maximal darstellbare Größe. Die Seite c liegt unten
parallel zur Horizontalen. Alle Eckpunkte haben einen Minimalabstand von 0,5 cm
vom Fensterrand.
Das Programm liefert eine Fehlermeldung, wenn andere Daten als drei nicht negative reelle
Zahlen eingegeben werden. Anschließend wird mit einer neuen Eingabeaufforderung
versucht, gültige Werte einzulesen.
Seite 7
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Black Box Testing: Übung
Welche 4 Funktionen sind bei einer vollständigen Funktionsüberdeckung zu prüfen?
Für eine vollständige Ausgaben- und Ausnahmeüberdeckung sind die notw. Äquivalenzklassen
definiert worden; legen Sie für jede (Sub-)klasse einen Repräsentanten fest:
•
Ausgabenüberdeckung:
–
kein Dreieck mit 3 Subklassen
–
gleichseitiges Dreieck
–
gleichschenkliges Dreieck mit 3 Subklassen
–
unregelmäßiges Dreieck mit 9 Subklassen
•
Ausnahmeüberdeckung
–
ungültige Eingabe mit 3 Subklassen
Legen Sie für jeden Grenzfall einer Grenzwertanalyse einen Testwert fest (insg. 7 Grenzfälle):
•
kein Dreieck mit 4 Werten
•
Sehr flaches Dreieck mit 2 Werten
•
Sehr steiles Dreieck
Seite 8
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
White Box Testing: Verfahren
Kontrollflussbasierter Test
•
•
•
•
C0-Überdeckung, Anweisungsüberdeckung, statement coverage (alle Knoten)
C1-Überdeckung, Zweigüberdeckung, branch coverage (alle Zweige)
CGI, Grenze-Inneres Test
C∞-Überdeckung, Pfadüberdeckung, path coverage (alle Pfade)
Test der Bedingungen
• C2-Überdeckung, Bedingungsüberdeckung (alle Bedingungen, auch Teile davon)
• Mehrfachbedingungsüberdeckung (alle Kombinationen der Teilbedingungen)
Datenflussbasierter Test
• Überdeckungsgrad bzgl. der Datenverwendung (Def/Uses-Verfahren):
• (zustandsverändernde) Wertzuweisung: z.B. r=0
• (zustandserhaltende) Benutzung in Ausdrücken: z.B. f(r)
• (zustandserhaltende) Benutzung in Entscheidungen: z.B. r>0
Seite 9
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
White Box Testing: C0-Überdeckung
Kontrollfußgraph vom ggT (Bsp.:ggT(4,8)=4, ggT(5,8)=1, ggT(15,35)=5)
1
2-3
4-6
7
8
9-11
12
13
1. public int ggt(int m, int n) {
2.
int r;
3.
if (n > m) {
4.
r = m;
5.
m = n;
6.
n = r
}
7.
r = m % n;
8.
while (r != 0) {
9.
m = n;
10.
n = r;
11.
r = m % n;
}
12.
return n;
13. }
Ein Testfall für die 100%ige
C0-Überdeckung:
1,2-3,4-6,7, 8,9-11,8,12,13
Der Pfad
2-3,7
wird nicht getestet,
weil in diesem Pfad
keine Anweisung
enthalten ist
Seite 10
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
White Box Testing: C0-Überdeckung
Beispiel für nicht gefundenen Fehler bei der C0-Überdeckung:
Mit den
Testdaten x=5
und y=0 wird
zwar die C0Überdeckung
erfüllt, jedoch
wird der Fehler
im falschen
Programm nicht
gefunden, denn
die Sollwerte
x=25 und y=30
werden in beiden
Fällen erreicht.
Seite 11
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
White Box Testing: C1-Überdeckung
1
1
2-3
2-3
4-6
4-6
7
7
8
8
9-11
9-11
12
12
13
13
Zwei Testfälle für die
100%ige C1-Überdeckung:
1,2-3,4-6,7, 8,9-11,8,12,13
1,2-3,7,8,12,13
neu
Jedoch:
• Schleifen werden nicht ausreichend
getestet.
• Komplexe Bedingungen werden nicht
getestet.
• Kombinationen von Zweigen werden nicht
getestet.
Seite 12
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
White Box Testing: C1-Überdeckung
Beispiel für gefundenen Fehler bei der C1-Überdeckung:
Mit den Testdaten
x=5 und y=0
(Ergebnis: x=25,
y=30) wird der
eine Test
durchgeführt, mit
x=-1 und y=0
(Ergebnis: x=-1,
y4) der zweite
Test.
Der Fehler wird im
Gegensatz zur
C0-Überdeckung
gefunden.
Seite 13
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
White Box Testing: CGI-Überdeckung
Die CGI-Überdeckung (Grenze-Inneres) bezieht sich
nur auf Schleifenanweisungen und fordert, dass jede
Schleife in mindestens einem Testfall
• gar nicht (gilt nur bei abweisenden
Schleifen, while, for nur wenn Abbruchbedingung bei
erstmaliger Auswertung wahr)
• genau einmal und
• mehr als einmal ausgeführt wird.
3 Testfälle für die CGI-Überdeckung:
1,2-3,7,8,12,13
1,2-3,4-6,7, 8,9-11,8,12,13
1
2-3
4-6
7
8
9-11
12
1,2-3,4-6,7, 8,9-11,8,9-11,8,12,13
13
Seite 14
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
White Box Testing: Bedingungsüberdeckung
Die C2-Überdeckung (Bedingungsüberdeckung)
berücksichtigt komplexe/zusammengesetzte
Bedingungen, indem sie fordert, alle
Teilbedingungen zu variieren. Jedoch ist nicht
gefordert, dass unterschiedliche Wahrheitswerte
bei der Auswertung der gesamten Bedingung
berücksichtigt werden. Somit ist die Anweisungsbzw. Zweigüberdeckung stärker, da manche
Zweige bei der C2-Überdeckung nicht getestet
werden.
Testfall1: A=2, B=1, C=4
Testfall2: A=1, B=0, C=1
Die Testfälle überdecken zwar alle Variationen der
Teilbedingungen, jedoch wird der Pfad c nicht
getestet.
Seite 15
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
White Box Testing: Bedingungsüberdeckung
Bei der Testfallermittlung sollte man
sowohl die C2-Überdeckung
(Bedingungsüberdeckung) als auch die
Zweigüberdeckung berücksichtigen (s.
auch Beispiel vorige Folie):
Testfall1: A=2, B=0, C=4  Pfad a-c-e
Testfall2: A=1, B=1, C=1  Pfad a-b-d
Mit diesen Testfällen werden zwar alle
Zweige überdeckt, jedoch nicht alle
Zweigkombinationen.
Um das zu zeigen, benötigt man eine
äquivalente Umformung des
Kontrollflussgraphen:
Seite 16
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
White Box Testing: Bedingungsüberdeckung
Testfall1: A=2, B=0, C=4
A>1
true
B=0
true
Testfall2: A=1, B=1, C=1
false
false
C:=C/A
Zwei Zweige fehlen:
false
Lösung:
Mehrfachbedingungsüberdeckung (C3-Ü.)
Die C3-Überdeckung ist dann erfüllt,
wenn jede Kombination der
Wahrheitswerte aller Teilbedingungen in
Testfällen ausgeführt wird.
C>1
false
A=2
true
true
C:=C+1
Seite 17
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
White Box Testing
Datenflussbasiertes Testen (Def/Uses-Verfahren)
• Getestet werden Interaktion zwischen Anweisungen, die einer Variablen einen Wert zuweisen (definieren), und Anweisungen, die diesen Variablenwert benutzen (referenzieren):
• Wertzuweisung (Definition, definitional use, def)
• Berechnungsreferenz (Benutzung in Ausdrücken, computational use, c-use)
• Entscheidungsreferenz (Benutzung in Bedingungen, predicative use, p-use)
• verschiedene Test-/Überdeckungskriterien (Metriken):
• Alle Definitionen: Das Resultat einer Zuweisung
(Definition) wird wenigstens einmal
benutzt (c-use oder p-use)
• Alle DR-Interaktionen: jedes Paar
def(r)
(def/ref) auf irgendeinem Weg ausführen
• Alle Referenzen: p-uses und c-uses
• ….
c-use(m,n)
r = m % n
r = op1(m,n)
while (r != 0)
if (r == 0)
p-use(r)
Seite 18
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Verfahren zum White Box Testing
Kontrollflussgraph mit Datenflussannotation:
Bsp. für DR-Interaktionen:
(1, m, 4, r, 6):
m wird in 1 definiert, in 4
referenziert, r wird in 4
definiert und in 6
referenziert; damit hängt 6
von 1 ab.
(1, m, 7, r, 10):
…..
 Teste die Wegstücke:
(1, 2, 3, 4, 5, 6) und
(1, 2, 3, 7, 8, 9, 10)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
public int ggt
(int m, int n) {
int r;
if (n > m) {
r = m;
m = n;
n = r
}
r = m % n;
while (r != 0) {
m = n;
n = r;
r = m % n;
}
return n;
}
1
def(m,n)
2
def(r)
3
p-use(m,n)
4
def(r), c-use(m)
5
def(m), c-use(n)
6
def(n), c-use(r)
7
def(r), c-use(m,n)
8
p-use(r)
9
def(m), c-use(n)
10
def(n), c-use(r)
11
def(r), c-use(m,n)
12
c-use(n)
Seite 19
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Verfahren zum White Box Testing
Testverfahren
Leistungsfähigkeit
Bewertung
C0, (statement coverage)
Anweisungsüberdeckung
Niedrig
Entdeckt knapp 1/5 der Fehler
Entdeckt dead code
Mit and. Verfahren kombinieren
C1, (branch coverage)
Zweigüberdeckung
Entdeckt ca. 1/3 aller Fehler und
80% der Kontrollflussfehler
DAS minimale Testkriterium
C2,
Bedingungsüberdeckung
Niedrig
Umfasst i.Allg. nicht die C0- und C1Überdeckung, da Bedingungen evtl. in
Anweisungen neu berechnet werden
Mehrfach-Bedingungsüberdeckung
Hoch
Umfasst Zweigüberdeckung
Aufwand wächst stark
CGI,
Grenze-Inneres Test
Mittel
Zielt auf komplexe Schleifen
Nur als Ergänzung
C∞, (path coverage)
Pfadüberdeckung
Sehr hoch
Entdeckt ca. 2/3 aller Fehler
In den meisten Fällen nicht
praktikabel
Datenflusstest
Mittel bis hoch
All c-uses deckt 1/2 aller Fehler auf
All p-uses deckt 1/3 aller Fehler auf
All defs deckt 1/4 aller Fehler auf
Zielt auf Variablen-Verwendung
C-uses findet viele Berechnungsfehler
Seite 20
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Testszenarien und Testfälle
Für jede der geplanten Testarten werden die Testszenarien (o. a. Testumfänge) in Form
einer Liste von Testfällen festgelegt.
Für jeden Testfall gibt es dann eine Testanweisung und ein Testprotokoll, die häufig in
einem(!) Formular zusammengefasst sind. Die Beschreibung eines Testfalls beinhaltet
somit folgendes:
• Beschreibung des Testfalls und der dazugehörigen Testschritte incl.
Testbedingungen und Testdaten
• Name des Erstellers der Testanweisung
• Name des Freigebenden der Testanweisung
• Name des Testers
• Name des Abnehmenden
• Die zu testende Eigenschaft (Korrektheit, Bedienoberfläche, Performance, …)
• Erwartetes Ergebnis
• Tatsächliches Ergebnis (diese Information liegt natürlich erst nach der
Testdurchführung vor)
Seite 21
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Unittest
• typgerechte Verwendung aller Datenobjekte (ungewollte Konvertierungen)
• Objektverwendungsnachweise (Cross reference list, Aufrufhierarchie/-graph)
• Datenflussanalyse von Programmobjekten (Variablen, Konstanten):
• Objekte werden vor ihrer Definition verwendet
• Objekte werden mehrfach überschrieben, ohne vorher verwendet worden zu sein
• Objekte werden definiert, ohne danach verwendet zu werden
• “nur-lesbare” Objekte werden überschrieben: z.B. Prüfung durch den ANSI-C-Compiler bei
Verwendung des Schlüsselworts CONST: char *strcpy (char *ziel, const char *quelle);
(der Speicherbereich quelle darf von der Funktion nicht verändert werden).
• Statisch unerreichbare Programmsequenzen (z.B. fehlendes GOTO bei vorh.
Sprungmarken)
• Hinweise auf krasse Programmierfehler (z.B. nicht terminierende Schleife)
• Prüfung von Programmierkonventionen und Qualitätsstandards (z.B.
Namensgebung, Schachtelungstiefe, Komplexität)
Seite 22
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Unittest (Komplexität, Überdeckung)
...
1
IF a>b
2
THEN IF b>c
3
4
THEN p(a,b)
ELSE p(b,c);
Print(a,b,c);
5
Komplexität: metric of McCabe: Cyclomatic
Number is the maximum number of
independent paths in a flowgraph
v(G) = e - n + 2p
v(G) - Cyclomatic Number of the flowgraph G
e - number of edges in G
n - number of nodes in G
p - number of connected components (if you
have subprograms, p=1 in a single program)
v(G) = 8 - 7 + 2*1 = 3
Überdeckung:
Statement coverage:
1-2-3-5 und 1-2-4-5
Branch coverage:
1-5 (additional)
...
Seite 23
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Integrationstest
• Syntaxprüfung der Schnittstellen (z.B. falsche Anzahl von Parametern oder nicht
übereinstimmender Parametertyp), z.B. Prüfung der Argumente/aktuellen Parameter bei
einem Funktionsaufruf unter Verwendung des Funktions-Prototypen zur Deklaration der
Funktionen durch den ANSI-C-Compiler: float hoch (float zahl, int potenz)
• Kopplungskategorisierung nach Myers, sechs Abstufungen für die interne Festigkeit
eines Moduls (Cohesion), fünf Abstufungen für die Bindung zu anderen Moduln (Coupling)
• Anzeige verdeckter Abhängigkeiten, Beispiel: Zwei Module verwenden (importieren)
eine externe Variable, die von einem dritten Modul bereitgestellt wird, d.h. die Kopplung
zwischen den beiden benutzenden Moduln ist nicht unmittelbar ersichtlich
• Intermodulare Datenflussanalyse, Beispiel: Ein Parameter erhält vor dem Aufruf der
Schnittstelle einen Wert und wird in der aufgerufenen Funktion sofort überschrieben, ohne
vorher gelesen zu werden
• Ausschöpfen der Parameterbereiche: Prüfung der Ausnahmebehandlungen und
Grenzfälle (sind häufig in den Simulationen vernachlässigt worden), des Modulverhaltens
bei Systemfehlern, der über Modulgrenzen hinweg realisierten Fehlerbehandlungen und der
globalen Variablen
• Überprüfen der Aufrufreihenfolge: systemweite Überprüfung auf Einhaltung
vorgeschriebener Abläufe und Protokollierung der Abläufe einzelner Operationen
• Funktionalitätsprüfung (Zusammenwirken von Teilfunktionen)
stat.
dyn.
Seite 24
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Testabschlusskriterien
Wenn mit den in der Testvorschrift festgelegten Testdatensätzen keine Fehler mehr gefunden
werden
• Sinnvolles Kriterium, wenn der Umfang des Prüflings eine systematische Auswahl von Testfällen mit
ausreichender Überdeckung ermöglicht
• Übliches Kriterium bei der Abnahme
Wenn die Prüfkosten pro entdecktem Fehler eine im voraus festgelegte Grenze überschreiten
• Sinnvolles Kriterium für das Beenden des Systemtests
• Setzt die Erfassung der Prüfkosten und der Anzahl gefundener Fehler voraus
Wenn während der Ausführung einer im voraus festgelegten Menge von Testfällen keine Fehler
auftreten
• Beispielsweise im Systemtest mit zufällig bestimmten Testdaten. Die Anzahl der hintereinander
fehlerfrei auszuführenden Testfälle bestimmt sich aus der geforderten Zuverlässigkeit
Wenn die vorher festgelegte Obergrenze für die Fehlerdichte unterschritten wird
• Muss mit statistischen Methoden bestimmt werden
Seite 25
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Fehlermanagement beim Testen
Fehlerstatus
Gesetzt durch
Bedeutung
Neu
Tester
Neue Fehlermeldung (s. nä. Folie) wurde erfasst. Der Tester hat eine aus
seiner Sicht sinnvolle Beschreibung und Klassifizierung eingetragen.
Offen
Testmanager (TM)
TM sichtet die Meldungen, bereitet sie für eine einheitliche Bewertung auf,
löscht ggfs. Dubletten und weist die Meldung einem Entwickler zu.
Abgewiesen
Testmanager
Meldung wird als unberechtigt abgewiesen (kein Defekt im Testobjekt,
Änderungswunsch, der nicht berücksichtigt wird).
Analyse
Entwickler
E. dokumentiert das Ergebnis der Problemanalyse (Ursache, Lösungsmöglichkeiten, geschätzter Korrekturaufwand) in Form von Kommentaren.
Beobachtung Entwickler
Das Problem kann nicht nachvollzogen/ausgeschlossen werden. Meldung
bleibt unerledigt, bis weitere Informationen/Erkenntnisse vorliegen.
Korrektur
Projektmanager
Projektmanager entscheidet aufgrund der Analyse, dass die Korrektur erfolgen soll. Der zuständige Entwickler dokumentiert die Art der Korrektur.
Test
Entwickler
Der zuständige Entwickler behebt das Problem. Die Softwareversion, in
der die Korrektur verfügbar ist, wird angegeben.
Erledigt
Tester
Tester wiederholt im nächstmöglichen Testzyklus den fehleraufdeckenden
Test und setzt bei erfolgreicher Fehlerbeseitigung den Endzustand.
Flop
Tester
Ergibt der Fehlernachtest, dass die Fehlerbeseitigung erfolglos oder
ungenügend war, ist eine erneute Analyse notwendig.
Seite 26
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Fehlermeldung: Identifikation und Klassifizierung
Attribut
Bedeutung
Nummer
laufende, eindeutige Meldungsnummer
Testobjekt
Identifikation der genauen Version des Testobjekts
Plattform
Identifikation der HW-/SW-Plattform bzw. der Testumgebung, in der das Problem
auftritt
Entdecker
Identifikation des Testers (ggf. mit Teststufe), der das Problem meldet
Entwickler
Name des für das Testobjekt verantwortlichen Entwicklers oder Teams
Erfassung
Datum, ggf. Uhrzeit, an dem das Problem beobachtet wurde
Status (s. vo. Folie)
Bearbeitungsfortschritt der Meldung; möglichst mit Kommentar und Datum
Klasse
Klassifizierung der Schwere des Problems
Priorität
Klassifizierung der Dringlichkeit einer Korrektur
Anforderung
Verweis auf die (Kunden-)Anforderung, die wegen der Fehlerwirkung nicht erfüllt
oder verletzt ist
Fehlerquelle
Soweit feststellbar, die Projektphase, in der die Fehlhandlung begangen wurde
(Analyse, Design, Programmierung); nützlich zur Planung prozessverbessernder
Maßnahmen
Seite 27
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Anhang: Lösung der Übungsaufgabe von Seite 8
Vollständige Funktionsüberdeckung beinhaltet:
Aktivierung der Funktionen Prüfen, Klassifizieren, Skalieren und Zeichnen
Vollständige Ausgaben- und Ausnahmenüberdeckung benötigen
Äquivalenzklassen für
Erzeugen der Ausgaben
•
kein Dreieck
•
gleichseitiges Dreieck
•
gleichschenkliges Dreieck
•
unregelmäßiges Dreieck
Erzeugung der Ausnahmesituationen
•
ungültige Eingabe
Seite 28
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Anhang: Lösung der Übungsaufgabe von Seite 8
Klasse
Subklasse
Repräsentant
kein Dreieck
b größte Seite
4.25, 2, 1.3
b größte Seite
1.3, 4.25, 2
c größte Seite
2, 1.3, 4.25
gleichseitiges Dreieck
gleichschenkliges Dreieck
unregelmäßiges Dreieck
4.2, 4.2, 4.2
a=b
4.71, 4.71, 2
b=c
3, 5.6, 5.6
a=c
11, 6, 11
α spitz, β spitz
3, 5, 6
α spitz, β rechtwinklig
3, 5, 4
α spitz, β stumpf
3, 6, 4
β spitz, γ spitz
6, 3, 5
β spitz, γ rechtwinklig
4, 3, 5
β spitz, γ stumpf
4, 3, 6
γ spitz, α spitz
5, 6, 3
γ spitz, α rechtwinklig
5, 4, 3
γ spitz, α stumpf
6, 4, 3
Klasse
Subklasse
Repräsentant
Ungültige
Eingabe
Negative
Zahlen
2.3, -1.5, 3
Text statt
Zahl
2.3, 1.5, xrfk.q
Unvollständ
ige Eingabe
2.3, 1.5
Seite 29
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6
Okt 2011
Testen
Anhang: Lösung der Übungsaufgabe von Seite 8
Grenzwertanalyse
Grenzfall
Subklasse
Testwert
kein Dreieck
a=b=c=0
0, 0, 0
a=b+c
6, 2, 4
b=a+c
2, 6, 4
c=a+b
2, 4, 6
c = a + b – ε, ε sehr klein
3, 4, 6.999999999999
b = a + c – ε, ε sehr klein
3, 6.999999999999, 4
c klein, a = b sehr groß
107, 107, 5
Sehr flaches Dreieck
Sehr steiles Dreieck
Seite 30