Testen Übersicht
description
Transcript of Testen Übersicht
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 1
TestenÜbersicht
Datei: TestenVorlesung.ppt
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
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 2
TestenTestkonzept/-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
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 3
TestenTestarten/-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 Sicherstellung der Funktionsfähigkeit der wichtigsten Schnittstellenanbindungen
Systemtest Installationskontrolltest, operations readyness test
Sicherstellen der IT-technischen Integration, d.h. u.a. dass die Anwendung weiterhin den Betriebsanforderungen entspricht.
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 4
TestenTestmethoden
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
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 5
TestenBlack 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)
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 6
TestenBlack 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
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 7
TestenBlack 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.
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 8
TestenBlack 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
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 9
TestenWhite 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
Datenflussbasierter Test
• C2-Überdeckung, Bedingungsüberdeckung (alle Bedingungen, auch Teile davon)• Mehrfachbedingungsüberdeckung (alle Kombinationen der Teilbedingungen)
• Ü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
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 10
Testen White Box Testing: C0-Überdeckung
Kontrollfußgraph vom ggT (Bsp.:ggT(4,8)=4, ggT(5,8)=1, ggT(15,35)=5)
9-11
12
13
1
2-3
4-6
7
8
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. }
1,2-3,4-6,7, 8,9-11,8,12,13
Ein Testfall für die 100%ige C0-Überdeckung:
Der Pfad
wird nicht getestet, weil in diesem Pfad keine Anweisung enthalten ist
2-3,7
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 11
Testen White Box Testing: 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.
Beispiel für nicht gefundenen Fehler bei der C0-Überdeckung:
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 12
Testen White Box Testing: C1-Überdeckung
9-11
12
13
1
2-3
4-6
7
8
1,2-3,4-6,7, 8,9-11,8,12,13
Zwei Testfälle für die 100%ige C1-Überdeckung:
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.
9-11
12
13
1
2-3
4-6
7
8
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 13
Testen White Box Testing: 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.
Beispiel für gefundenen Fehler bei der C1-Überdeckung:
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 14
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.
9-11
12
13
1
2-3
4-6
7
8
1,2-3,7,8,12,13
3 Testfälle für die CGI-Überdeckung:
1,2-3,4-6,7, 8,9-11,8,12,13
1,2-3,4-6,7, 8,9-11,8,9-11,8,12,13
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 15
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 Anweisungs- bzw. 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.
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 16
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:
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 17
Testen White Box Testing: Bedingungsüberdeckung
Testfall1: A=2, B=0, C=4
A>1
A=2
C:=C/A
C:=C+1
true
true
false
false
B=0true
false
C>1
false
true
Testfall2: A=1, B=1, C=1
Zwei Zweige fehlen:
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.
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 18
TestenWhite Box Testing
Datenflussbasiertes Testen (Def/Uses-Verfahren)
• Getestet werden Interaktion zwischen Anweisungen, die einer Variablen einen Wert zuwei-
sen (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)
r = m % n
r = op1(m,n)
while (r != 0)
if (r == 0)
c-use(m,n)
p-use(r)
def(r)
• 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/ref) auf irgendeinem Weg ausführen• Alle Referenzen: p-uses und c-uses• ….
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 19
TestenVerfahren zum White Box Testing
Kontrollflussgraph mit Datenflussannotation:
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. }
8
2
3
4
6
7
9
10
11
12
5
1 def(m,n)
def(r)
p-use(m,n)
def(r), c-use(m)
def(m), c-use(n)
def(n), c-use(r)
def(r), c-use(m,n)
p-use(r)
def(m), c-use(n)
def(n), c-use(r)
def(r), c-use(m,n)
c-use(n)
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)
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 20
TestenVerfahren zum White Box Testing
Testverfahren Leistungsfähigkeit BewertungC0, (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
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 21
TestenTestszenarien 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)
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 22
TestenUnittest
• 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)
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 23
TestenUnittest (Komplexität, Überdeckung)
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 Ge - number of edges in Gn - number of nodes in Gp - number of connected components (if you have subprograms, p=1 in a single program)
1
43
2
5
...
...
IF a>b
THEN IF b>c
THEN p(a,b)
ELSE p(b,c);
Print(a,b,c);
v(G) = 8 - 7 + 2*1 = 3
Statement coverage:
1-2-3-5 und 1-2-4-5
Branch coverage:
1-5 (additional)
Überdeckung:
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 24
TestenIntegrationstest
• 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.
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 25
TestenTestabschlusskriterien
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
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 26
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ösungs-mö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 er-folgen 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.
TestenFehlermanagement beim Testen
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 27
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
TestenFehlermeldung: Identifikation und Klassifizierung
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 28
TestenAnhang: 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
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 29
TestenAnhang: 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 4.2, 4.2, 4.2
gleichschenkliges Dreieck a = b 4.71, 4.71, 2
b = c 3, 5.6, 5.6
a = c 11, 6, 11
unregelmäßiges Dreieck α 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äsen-tant
Ungültige Eingabe
Negative Zahlen
2.3, -1.5, 3
Text statt Zahl
2.3, 1.5, xrfk.q
Unvollständige Eingabe
2.3, 1.5
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 6 Okt 2011
Seite 30
TestenAnhang: Lösung der Übungsaufgabe von Seite 8
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
Sehr flaches Dreieck c = a + b – ε, ε sehr klein 3, 4, 6.999999999999
b = a + c – ε, ε sehr klein 3, 6.999999999999, 4
Sehr steiles Dreieck c klein, a = b sehr groß 107, 107, 5
Grenzwertanalyse