prof. dr. rainer koschke - uni bremen || startseite · software-test lernziele notwendigkeit und...
TRANSCRIPT
Software-Projekt
Prof. Dr. Rainer Koschke
Fachbereich Mathematik und InformatikArbeitsgruppe Softwaretechnik
Universitat Bremen
Wintersemester 2008/09
Software-Test
Software-Test1 Software-Test
Begriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 3 / 55
Software-Test
Lernziele
Notwendigkeit und Grenzen des Tests verstehen
Arten und Varianten des Software-Tests kennen
eine geeignete Test-Strategie auswahlen konnen
Testplane erstellen konnen
Tests durchfuhren konnen
N.B.: Diese Darstellung folgt in weiten Teilen Kapitel 11 des Buchs vonBrugge und Dutoit (2004).
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 4 / 55
Software-Test
Ein korrektes Programm?
c l a s s Ka l ende r {p u b l i c s t a t i c c l a s s MonatUngue l t ig e x t end s Excep t i on {} ;p u b l i c s t a t i c c l a s s J ah rUngue l t i g e x t end s Excep t i on {} ;p u b l i c s t a t i c boo l ean i s t S c h a l t J a h r ( i n t j a h r )
{ r e t u r n ( j a h r % 4) == 0;}p u b l i c s t a t i c i n t TageProMonat ( i n t monat , i n t j a h r )
throws MonatUnguelt ig , J ah rUngue l t i g {i n t anzTage ;i f ( j a h r < 1) { throw new Jah rUngue l t i g ( ) ; }i f (monat i n {1 , 3 , 5 , 7 , 10 , 12}) { anzTage = 32 ;}e l s e i f (monat i n {4 , 6 , 9 , 11}) { anzTage = 30 ; }e l s e i f (monat == 2) {
i f ( i s t S c h a l t J a h r ( j a h r ) ) anzTage = 29 ;e l s e anzTage = 28 ;
} e l s e throw new MonatUngue l t ig ( ) ;r e t u r n anzTage ;
}}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 5 / 55
Software-Test
Testen und seine Begriffe
Definition
Zuverlassigkeit: Maß fur den Erfolg, inwieweit das beobachtete Verhaltenmit dem spezifizierten ubereinstimmt.
Software-Zuverlassigkeit: Wahrscheinlichkeit, dass ein Software-Systemwahrend einer festgelegten Zeit unter festgelegten Bedingungen keinenSystemausfall verursachen wird (IEEE Std. 982-1989 1989).
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 6 / 55
Software-Test
Fehlerbegriff
Definition
Storfall (Ausfall, Failure): jegliche Abweichung des beobachtetenVerhaltens vom spezifizierten.
Im Nicht-Schaltjahr 200 wird fur den Monat Februar 29 ausgegeben.
Fehlerhafter Zustand (Error): Zustand, in dem ein Weiterlaufen desSystems zu einem Storfall fuhren wurde.
Die Funktion istSchaltjahr(200) liefert true.
Fehler (Defekt, Fault): mechanische oder algorithmische Ursache einesfehlerhaften Zustands.
Die Prufung in istSchaltjahr ist falsch.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 8 / 55
Fehlerbegriff
Definition
Storfall (Ausfall, Failure): jegliche Abweichung des beobachtetenVerhaltens vom spezifizierten.
Im Nicht-Schaltjahr 200 wird fur den Monat Februar 29 ausgegeben.
Fehlerhafter Zustand (Error): Zustand, in dem ein Weiterlaufen desSystems zu einem Storfall fuhren wurde.
Die Funktion istSchaltjahr(200) liefert true.
Fehler (Defekt, Fault): mechanische oder algorithmische Ursache einesfehlerhaften Zustands.
Die Prufung in istSchaltjahr ist falsch.2009-0
1-1
3
Software-Projekt
Software-Test
Begriffe des Testens
Fehlerbegriff
Mechanische Ursache: Fehler in der virtuellen Maschine (Plattform); z.B. Bug in Java-Virtual-Machine, Compileroder Hardwaredefekt.
Algorithmische Ursache: Fehler im Algorithmus, z.B. Off-by-One-Fehler, uninitialisierte Variable,
Performanzengpasse aufgrund eines schlechten Entwurfs.
Software-Test
Testen und seine Begriffe
Definition
Test: systematischer Versuch, in der implementierten Software Defekte zufinden.
Erfolgreicher (positiver) Test: Test, der Defekt aufgedeckt hat.
Erfolgloser (negativer) Test: Test, der keinen Defekt aufgedeckt hat.
→ Tests sind Experimente zur Falsifikation der Hypothese “System istkorrekt”.
→ Aus negativem Test folgt noch lange nicht, dass kein Defektvorhanden ist.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 9 / 55
Software-Test
Der Test und seine Verwandten
Tests sind nur ein Mittel, die Zuverlassigkeit zu steigern:
Fehlervermeidung (z.B. Entwicklungsmethoden, Verifikation, statischeAnalyse)
Fehlerentdeckung (z.B. Tests, assert, “Quality-Feedback-Agent”,Flugschreiber)
Fehlertoleranz: Behandlung von Fehlern zur Laufzeit, um Programmfortzusetzen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 10 / 55
Software-Test
Soziologie des Testens
Testen wird haufig (aber zu unrecht) als niedere Arbeit angesehen
→ Frischlinge werden zu Testern
Tester brauchen jedoch ein umfassendes Systemverstandnis(Anforderungen, Entwurf, Implementierung)
Tester brauchen daruber hinaus, Wissen uber Pruftechniken
Autoren haben eine Lesart der Spezifikation verinnerlicht
Denkfehler in der Implementierung werden sich bei Erstellung vonTestfallen wiederholen
→ Tester sollten nicht gleichzeitig Autoren sein
Tester versuchen, Fehler zu finden
das Produkt wird kritisiert, dann fuhlen sich Autoren selbst kritisiert
→ Egoless-Programming (eine schone Illusion)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 11 / 55
Software-Test
Testplan
Komponententest
Integrationstest
Strukturtest
Funktionstest
Leistungstest
Akzeptanztest
Installationstest
Benutzbarkeitstest
Feldtest
Normalbetrieb
Management-plan
Klassen-entwurf
Integrations-strategie
Subsystem-zerlegung
FunktionaleAnforderungen
NichtfunktionaleAnforderungen
Benutzungs-handbuch
Projekt-vereinbarung
Benutzungs-schnittstellen-
entwurf
Entwickler Kunde Benutzer
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 12 / 55
Testplan
Komponententest
Integrationstest
Strukturtest
Funktionstest
Leistungstest
Akzeptanztest
Installationstest
Benutzbarkeitstest
Feldtest
Normalbetrieb
Management-plan
Klassen-entwurf
Integrations-strategie
Subsystem-zerlegung
FunktionaleAnforderungen
NichtfunktionaleAnforderungen
Benutzungs-handbuch
Projekt-vereinbarung
Benutzungs-schnittstellen-
entwurf
Entwickler Kunde Benutzer
2009-0
1-1
3
Software-Projekt
Software-Test
Testaktivitaten
Quelle: Brugge und Dutoit (2004)
• Testplanung: Betriebsmittelzuteilung und Zeitplan
• Benutzbarkeitstest: Fehler im Benutzerschnittstellenentwurf aufdecken; siehe (Papier-)Prototypen
• Komponententest: Fehler in einzelner Komponente (Klasse, Paket o.A.) aufdecken
• Integrationstest: Fehler im Zusammenspiel von Komponenten aufdecken
• Strukturtest: Integrationstest mit allen Komponenten (abschließender und vollstandiger Integrationstest)
• Systemtest: Test aller in einem System zusammengefasster Subsysteme mit dem Ziel, Fehler bezuglich der Szenarien ausder problemstellung sowie der Anforderungen und Entwurfsziele, die in der Analyse bzw. im Systementwurf identifiziertwurden, zu finden
• Funktionstest: testet die Anforderungen aus dem Lastenheft und die Beschreibung des Benutzerhandbuchs
• Leistungstest: Test der Leistungsanforderungen (Performanz und Speicherbedarf)
• Installationstest: Test der Installation beim Kunden (evtl. mit der Hilfe der Entwickler)
• Akzeptanztest: Prufung bzgl. Projektvereinbarung durch den Kunden (evtl. mit der Hilfe der Entwickler)
Software-Test
Testfall
Ein Testfall besteht aus:
Name
Ort: vollstandiger Pfadname deslauffahigen Testprogramms
Eingabe: Eingabedaten oderBefehle
Orakel: erwarteteTestergebnisse, die mit denaktuellen Testergebnissen desTestlaufs verglichen werden
Protokoll: gesamte Ausgabe, diedurch Test erzeugt wird
Eingabe Ist-ErgebnisPrüfling
Vergleich Protokoll
Soll-Ergebnis
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 13 / 55
Software-Test
Komponententest: Teststumpfe und -treiber
Benutzerklasse X
Benutzte Klasse A Benutzte Klasse B
Prüfling C
Testtreiber
Benutzte Klasse A Teststumpf für benutzte Klasse B
Prüfling C
Benutzerklasse Y
spätere Umgebung Testumgebung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 14 / 55
Komponententest: Teststumpfe und -treiber
Benutzerklasse X
Benutzte Klasse A Benutzte Klasse B
Prüfling C
Testtreiber
Benutzte Klasse A Teststumpf für benutzte Klasse B
Prüfling C
Benutzerklasse Y
spätere Umgebung Testumgebung2009-0
1-1
3
Software-Projekt
Software-Test
Teststumpfe und -treiber
Komponententest: Teststumpfe und -treiber
Bestreben: Komponenten so fruh wie moglich testen.Problem: die benutzenden Komponenten und die benutzten Komponenten existieren moglicherweise noch nicht.Losung: Testtreiber und -stumpfe
• Prufling/Testkomponente: die zu testende Klasse/Komponente
• Testtreiber: simuliert den Teil des Systems, der die Testkomponente benutzt
• Teststumpf: simuliert die Komponenten, die die Testkomponente benutzt
In vielen Fallen: Aufwand fur Teststumpf entspricht Aufwand fur die eigentliche Komponente→Bottom-Up-Entwicklung der Komponenten
Software-Test
Typen von Komponententests
Definition
Black-Box-Tests: Komponente wird nur mit Kenntnis derSchnittstellenbeschreibung entworfen (Implementierung unbekannt).
Techniken:
Aquivalenztest
Grenztest
(zustandsbasierter Test)
. . .
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 15 / 55
Software-Test
Typen von Komponententests
Definition
White-/Glass-Box-Tests: Testfall wird mit Kenntnis der Implementierungentworfen.
Techniken:
Pfadtest
(zustandsbasierter Test)
. . .
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 16 / 55
Software-Test
Aquivalenztest I
Ziel: Testfalle minimieren.Idee:
Aquivalente Testfalle werden zusammengefasst.
Ein Testfall wird als Reprasentant der Aquivalenzklasse aufgestellt.
Kriterien:
Abdeckung: Jede mogliche Eingabe gehort zu einer derAquivalenzklassen
Disjunktion: Keine Eingabe gehort zu mehr als einer einzigenAquivalenzklasse
Reprasentation (die Hoffnung): Falls Ausfuhrung einen fehlerhaftenZustand anzeigt, sobald ein bestimmtes Mitglied einerAquivalenzklasse als Eingabe benutzt wird, dann kann derselbefehlerhafte Zustand entdeckt werden, wenn irgendein anderes Mitglieddieser Aquivalenzklasse als Eingabe verwendet wird
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 17 / 55
Software-Test
Aquivalenztest II
Fur jede Aquivalenzklasse werden mindestens zwei Testeingabenausgewahlt:
typische Eingabe, die den allgemeinen Fall abpruft
unvollstandige Eingabe, die auf korrektes Verhalten im Fehlerfall pruft
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 18 / 55
Software-Test
Ein korrektes Programm?
c l a s s Ka l ende r {p u b l i c s t a t i c c l a s s MonatUngue l t ig e x t end s Excep t i on {} ;p u b l i c s t a t i c c l a s s J ah rUngue l t i g e x t end s Excep t i on {} ;p u b l i c s t a t i c boo l ean i s t S c h a l t J a h r ( i n t j a h r )
{ r e t u r n ( j a h r % 4) == 0;}p u b l i c s t a t i c i n t TageProMonat ( i n t monat , i n t j a h r )
throws MonatUnguelt ig , J ah rUngue l t i g {i n t anzTage ;i f ( j a h r < 1) { throw new Jah rUngue l t i g ( ) ; }i f (monat i n {1 , 3 , 5 , 7 , 10 , 12}) { anzTage = 32 ;}e l s e i f (monat i n {4 , 6 , 9 , 11}) { anzTage = 30 ; }e l s e i f (monat == 2) {
i f ( i s t S c h a l t J a h r ( j a h r ) ) anzTage = 29 ;e l s e anzTage = 28 ;
} e l s e throw new MonatUngue l t ig ( ) ;r e t u r n anzTage ;
}}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 19 / 55
Software-Test
Beispielspezifikation
Kalender.TageProMonat(monat,jahr) liefere die Tage eines Monatswie folgt:
monat ∈ {1, 3, 5, 7, 8, 10, 12} ⇒ 31
monat ∈ {4, 6, 9, 11} ⇒ 30
jahr ist ein Schaltjahr ∧ monat = 2 ⇒ 29
jahr ist kein Schaltjahr ∧ monat = 2 ⇒ 28
Fehlerfall
monat < 1 ∨monat > 12 ⇒ throw MonatUngueltig
jahr < 0 ⇒ throw JahrUngueltig
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 20 / 55
Software-Test
Beispielaquivalenzklassen
Aquivalenzklassen:
fur Monate:
Monate mit 31 TagenMonate mit 30 TagenMonate mit 28 oder 29 Tagenmonat außerhalb gultigen Bereichs
fur Jahre:
SchaltjahreJahre, die keine Schaltjahre sindjahr außerhalb gultigen Bereichs
→ Kombination der Aquivalenzklassen fur alle Eingabeparameter ergibtAquivalenzklassen fur TageProMonat
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 21 / 55
Software-Test
Beispieltestfalle
Test der Interaktion von monat und jahr durch Kombination:
Aquivalenzklasse monat jahr Soll
31-Tage-Monat, Nicht-Schaltjahre 7 1901 3131-Tage-Monat, Schaltjahre 7 1904 31
30 Tage-Monat, Nicht-Schaltjahre 6 1901 3030 Tage-Monat, Schaltjahre 6 1904 30
Februar, Nicht-Schaltjahre 2 1901 28Februar, Schaltjahre 2 1904 29
monat inkorrekt, jahr korrekt 17 1901 MonatUngueltigmonat korrekt, jahr inkorrekt 7 -1901 JahrUngueltigmonat inkorrekt, jahr inkorrekt 17 -1901 MonatUngueltig
∨JahrUngueltig
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 22 / 55
Software-Test
Komponententest mit JUnit
impor t j u n i t . f ramework . ∗ ;
p u b l i c c l a s s Ka l ende rTes t e x t end s TestCase {
p u b l i c Ka l ende rTes t ( S t r i n g name) {supe r ( name ) ;
}. . .// Test−Methoden. . .p u b l i c s t a t i c vo i d main ( S t r i n g [ ] a r g s ) {
j u n i t . sw i ngu i . TestRunner . run ( Ka l ende rTes t . c l a s s ) ;}
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 23 / 55
Software-Test
Komponententest mit JUnit
p u b l i c vo i d testTageProMonat1 ( ) {// 31−Tage−Monat , Nicht−S c h a l t j a h r ea s s e r t E q u a l s (31 , Ka l ende r . TageProMonat (7 , 1 901 ) ) ;
}
p u b l i c vo i d testTageProMonat9 ( ) {// monat i n k o r r e k t , j a h r i n k o r r e k tt r y { i n t t = Ka lende r . TageProMonat (13 , −1901);
a s s e r tT r u e ( f a l s e ) ; }ca tch ( Ka l ende r . J ah rUngue l t i g j e ) {} // expec t edca tch ( Ka l ende r . MonatUngue l t ig me) {} // expec t edca tch ( Excep t i on e ) { f a i l ( ” Excep t i on expec t ed ” ) ; }
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 24 / 55
Software-Test
Komponententest mit JUnit
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 25 / 55
Software-Test
Grenztest
Beobachtung: “Off-by-one”-Fehler kommen haufig vor.
Idee: Grenzen (Randbereiche) von Aquivalenzklassen testen.
Schaltjahrregel: Ein Jahr ist ein Schaltjahr, wenn
es durch 4 teilbar ist,
es sei denn, es ist durch 100 teilbar,
es sei denn, es ist durch 400 teilbar
2000 ist ein Schaltjahr, 1900 ist kein Schaltjahr.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 26 / 55
Software-Test
Grenztest
Aquivalenzklasse monat jahr Soll
Schaltjahre teilbar durch 400 2 2000 29Nicht-Schaltjahre teilbar durch 100 2 1900 28
gultige Monate 1 2000 31gultige Monate 12 2000 31
Nichtpositive ungultige Monate 0 1234 MonatUngueltigPositive ungultige Monate 13 1234 MonatUngueltiggultiges Jahr 2 0 29gultiges Jahr 3 Max-Int 31
ungultiges Jahr 2 -1 JahrUngueltig
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 27 / 55
Software-Test
Pfadtest
Ziel: Testfalle sollten alle Code-Teile testen.
Idee: Konstruiere Testfalle, die jeden moglichen Pfad mindestens einmalausfuhren.
Ausgangspunkt: Kontrollflussgraph (KFG) pro Methode.
Knoten: Anweisungen und Pradikate
zwei weitere Knoten: eindeutiger Anfang und Ende einer Methode
Kanten: Kontrollfluss zwischen Anweisungen (unbedingt) undPradikaten (bedingt)
Pfad: Menge von Kanten, die vom Anfang zum Ende des KFGs fuhren
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 28 / 55
Software-Test
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 29 / 55
Software-Test
Maße der Testabdeckung
C0, Anweisungsuberdeckung (Befehlsabdeckung/Statement-Coverage):Verhaltnis von Anzahl der mit Testdaten durchlaufenenAnweisungen zur Gesamtanzahl der Anweisungen.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 30 / 55
Maße der Testabdeckung
C0, Anweisungsuberdeckung (Befehlsabdeckung/Statement-Coverage):Verhaltnis von Anzahl der mit Testdaten durchlaufenenAnweisungen zur Gesamtanzahl der Anweisungen.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
2009-0
1-1
3
Software-Projekt
Software-Test
Maße der Testabdeckung
Maße der Testabdeckung
Befehlsabdeckung / statement coverage / C0-Abdeckung: Gesucht ist eine Menge von Testfallen, die jeden Befehlin dem zu testenden Code mindestens einmal ausfuhren. Dieses Kriterium ist sehr schwach, denn es werden in derRegel nur sehr wenige Fehler (20%) gefunden. Fehler entstehen meist dadurch, dass Befehle in bestimmtenZustanden ausgefuhrt werden und nicht nur in irgendeinem.Ein Code-Coverage-Tool kann helfen, um zu sehen, welche Befehle nicht oder selten ausgefuhrt werden. Denn einnotwendiges Kriterium ist die Befehlsabdeckung allemal.
Software-Test
Maße der Testabdeckung
C1, Zweig-/Entscheidungsuberdeckung Verhaltnis von Anzahl der mitTestdaten durchlaufenen Zweige zur Gesamtanzahl derZweige.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 31 / 55
Maße der Testabdeckung
C1, Zweig-/Entscheidungsuberdeckung Verhaltnis von Anzahl der mitTestdaten durchlaufenen Zweige zur Gesamtanzahl derZweige.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
2009-0
1-1
3
Software-Projekt
Software-Test
Maße der Testabdeckung
Maße der Testabdeckung
Jedes Pradikat muss im Code mindestens einmal wahr und einmal falsch sein. Schließt die Befehlabdeckung mit ein(es sei denn, es gibt unerreichbare Befehle) und ist aquivalent zur Befehlsabdeckung, wenn jeder wahr/falsch-Fallauch mindestens einen Befehl beinhaltet. Dieses Kriterium ist weiterhin relativ schwach. Erfahrungsgemaß 25%Fehlerfindung.
Software-Test
Maße der Testabdeckung
C2, Bedingungsabdeckung Verhaltnis von Anzahl der mit Testdatendurchlaufenen Terme innerhalb von Entscheidungen zurGesamtanzahl der Terme.
i := 1 ;l oop
found := a ( i ) = key ;e x i t when found or i = Max Ent r i e s ;i := i + 1 ;
end loop ;
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 32 / 55
Maße der Testabdeckung
C2, Bedingungsabdeckung Verhaltnis von Anzahl der mit Testdatendurchlaufenen Terme innerhalb von Entscheidungen zurGesamtanzahl der Terme.
i := 1 ;l oop
found := a ( i ) = key ;e x i t when found or i = Max Ent r i e s ;i := i + 1 ;
end loop ;
2009-0
1-1
3
Software-Projekt
Software-Test
Maße der Testabdeckung
Maße der Testabdeckung
Nur verschieden von C1, wenn logische Operatoren keine Short-Circuit-Operatoren sind (d.h. es werdengrundsatzlich alle Operanden eines logischen Operators ausgewertet).In jedem Pradikat wird jeder Bedingungsteil (Konjunktions- oder Alternationsglied) mindestens einmal wahr undeinmal falsch gesetzt.N.B.: Das umfasst nicht die Entscheidungsfallabdeckung:true and false→ false-Kantefalse and true→ false-Kante(sofern der Operator and kein Short-Circuit-Operator ist).Man sollte beide kombinieren.Man bedenke, dass false and x→ false ist wenn x keine Seiteneffekte hat.
Software-Test
Maße der Testabdeckung
C3, Abdeckung aller Bedingungskombinationen Verhaltnis von Anzahl dermit Testdaten durchlaufenen Bedingungskombinationen zurGesamtanzahl der Bedingungskombinationen.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 33 / 55
Maße der Testabdeckung
C3, Abdeckung aller Bedingungskombinationen Verhaltnis von Anzahl dermit Testdaten durchlaufenen Bedingungskombinationen zurGesamtanzahl der Bedingungskombinationen.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
2009-0
1-1
3
Software-Projekt
Software-Test
Maße der Testabdeckung
Maße der Testabdeckung
Bedingungenkombinationsabdeckung / multiple condition coverage: Hier werden Pradikate gemaß einerWahrheitstabelle alle Bedingungskombinationen aller in allen Kombinationen mal wahr und mal falsch gesetzt.Interessanterweise bringt dies nicht viel mehr an Erfolg, aber viel mehr an Aufwand. ·
Software-Test
Maße der Testabdeckung
C4, Pfadabdeckung Verhaltnis von Anzahl der mit Testdatendurchlaufenen Pfade zur Gesamtanzahl der Pfade.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 34 / 55
Maße der Testabdeckung
C4, Pfadabdeckung Verhaltnis von Anzahl der mit Testdatendurchlaufenen Pfade zur Gesamtanzahl der Pfade.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
2009-0
1-1
3
Software-Projekt
Software-Test
Maße der Testabdeckung
Maße der Testabdeckung
(Eingeschrankte) Pfadabdeckung: Hier werden auch bei Schleifen mehrere Durchlaufe gemacht (keinmal, einmal,zweimal, typische Anzahl, maximale Anzahl). In aller Regel wird nicht auf diese Weise getestet, da der Aufwandsehr groß ist.
Software-Test
Probleme beim Pfadtest
Unrealisierbare Pfade:
f o r ( i = 0 ; i < o . foo ( ) ; i++) // immer o . foo ( ) == 0 ?{
x = . . .}
. . .x. . . // hat x d e f i n i e r t e n Wert?
i f ( p ) {. . .}
i f ( q ) { // p => not q??. . .
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 35 / 55
Software-Test
Polymorphismustest
c l a s s T { p u b l i c i n t foo ( ) ; }c l a s s NT ex t end s T { p u b l i c i n t foo ( ) ; }c l a s s Fac to r y { T c r e a t e ( i n t i ) ; }
c l a s s UnderTest {vo i d bar ( i n t i ){ T t = (new Fac to r y ) . c r e a t e ( i ) ;
i f ( t . f oo ( ) > 0)doSomething ( ) ;
}}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 36 / 55
Polymorphismustest
c l a s s T { p u b l i c i n t foo ( ) ; }c l a s s NT ex t end s T { p u b l i c i n t foo ( ) ; }c l a s s Fac to r y { T c r e a t e ( i n t i ) ; }
c l a s s UnderTest {vo i d bar ( i n t i ){ T t = (new Fac to r y ) . c r e a t e ( i ) ;
i f ( t . f oo ( ) > 0)doSomething ( ) ;
}}
2009-0
1-1
3
Software-Projekt
Software-Test
Maße der Testabdeckung
Polymorphismustest
Methode bar kann nicht in Isolation getestet werden. Welches foo im Beispiel ausgefuhrt wird, hangt vomdynamischen Typ von t ab. Davon hangen wiederum die weiteren Pfade ab.
Software-Test
Zustandsbasiertes Testen
Verhalten von Komponente hangt ab von
der Eingabe
ihrem Zustand
c l a s s Stack {p u b l i c s t a t i c c l a s s EmptyStack ex t end s Excep t i on {} ;p u b l i c s t a t i c c l a s s F u l l S t a c k ex t end s Excep t i on {} ;
p u b l i c Stack ( i n t maxSize ) {. . .} ;
p u b l i c boo l ean isEmpty ( ) {. . .} ;p u b l i c i n t s i z e ( ) {. . .} ;
p u b l i c Object top ( ) throws EmptyStack {. . .} ;p u b l i c vo i d push ( Object o ) throws Fu l l S t a c k {. . .} ;p u b l i c vo i d pop ( ) throws EmptyStack {. . .} ;
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 37 / 55
Software-Test
Zustande eines Stacks
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 38 / 55
Software-Test
Zustandsbasiertes Testen
Fur alle Zustande einer Komponente:
Komponente wird in zu testenden Zustand gebracht
Test fur alle moglichen Stimuli:
korrekte Eingaben,fehlerhafte Eingabenund Aktionen, die Zustandsubergange bewirken
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 39 / 55
Software-Test
Zustandsbasiertes Testen I
p u b l i c vo i d t e s t S t a t e F u l l ( ) {// t e s t o f S ta t e f u l lf i n a l i n t max = 100 ;Stack s = new Stack (max ) ;Object l a s t = new Object ( ) ;
// put Stack i n t o s t a t e f u l lf o r ( i n t i = 1 ; i<max ; i++) {
l a s t = new Object ( ) ;s . push ( l a s t ) ;// e x c e p t i o n ( i f any ) w i l l be caught by JUn i t
}
// t e s t l e g a l a c t i o n ’ s i z e ’ ; no t r a n s i t i o na s s e r t E q u a l s (max , s . s i z e ( ) ) ;
// t e s t l e g a l a c t i o n ’ top ’ ; no t r a n s i t i o na s s e r t E q u a l s ( l a s t , s . top ( ) ) ;
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 40 / 55
Software-Test
Zustandsbasiertes Testen II
// t e s t l e g a l a c t i o n ’ i sEmpty ’ ; no t r a n s i t i o na s s e r t E q u a l s ( f a l s e , s . i sEmpty ( ) ) ;
// t e s t i l l e g a l a c t i o n ’ push ’t r y { s . push ( new Object ( ) ) ; f a i l ( ” e x c e p t i o n expec t ed ” ) ; }ca tch ( Stack . F u l l S t a c k e ) {} // OK
// t e s t l e g a l a c t i o n / t r a n s i t i o n ’ pop ’s . pop ( ) ;
// r e v e r s e t r a n s i t i o ns . push ( new Object ( ) ) ;
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 41 / 55
Software-Test
Vergleich von White- und Black-Box-Tests
Black-Box-Tests (Funktionstests) betrachten den Prufling als schwarzeBox. Sie setzen keine Kenntnisse uber die Interna voraus.
White-Box-Tests (Strukturtests, Glass-Box-Tests) betrachten Interna desPruflings, um Testfalle zu entwickeln.
Eigenschaft Black-Box-Test White-Box-Test
Test auf Basis von Schnittstellen- Losungspezifikation
Wiederverwendung bei ja eingeschrankt
Anderung der Struktur
Geeignet fur Testart alle Komponententest
Finden Fehler aufgrund von Abweichung von Spez. eher Kodierfehler
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 42 / 55
Vergleich von White- und Black-Box-Tests
Black-Box-Tests (Funktionstests) betrachten den Prufling als schwarzeBox. Sie setzen keine Kenntnisse uber die Interna voraus.
White-Box-Tests (Strukturtests, Glass-Box-Tests) betrachten Interna desPruflings, um Testfalle zu entwickeln.
Eigenschaft Black-Box-Test White-Box-Test
Test auf Basis von Schnittstellen- Losungspezifikation
Wiederverwendung bei ja eingeschrankt
Anderung der Struktur
Geeignet fur Testart alle Komponententest
Finden Fehler aufgrund von Abweichung von Spez. eher Kodierfehler
2009-0
1-1
3
Software-Projekt
Software-Test
Zustandsbasiertes Testen
Vergleich von White- und Black-Box-Tests
White-Box Methoden eignen sich lediglich fur den Modultest, allenfalls noch fur den Integrationstest. Die Idee istes, die Testfalle anhand der inneren Programmstruktur zu finden.Achtung: White-Box-Testing testet keine fehlenden Pfade oder Anweisungen. Das ist eine echte Schwache, denn eswird nur das getestet, woran der Programmierer auch wirklich (wenn auch evtl. fehlerhaft) gedacht hat!Black-Box-Tests konnen wiederverwendet werden, wenn sie die Struktur, aber nicht das Verhalten andert.
Software-Test
Black- versus White-Box-Tests
Nicht entweder-oder, sondern sowohl-als-auch!
Komplementare Verwendung:
1 Erstelle Funktionstest
2 Messe Abdeckung
3 Wenn Abdeckung nicht ausreichend; erganze durch Strukturtest;zuruck zu 2.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 43 / 55
Software-Test
Strategien des Integrationstests I
Urknalltest: alle Komponenten werden einzeln entwickelt und dann ineinem Schritt integriert
→ erschwert Fehlersuche
Bottom-Up: Integration erfolgt inkrementell in umgekehrter Richtungzur Benutzt-Beziehung
→ keine Testrumpfe notwendig (aber Testtreiber)→ Fehler in der obersten Schicht werden sehr spat entdeckt; die enthalten
jedoch die Applikationslogik
Top-Down: Integration erfolgt in Richtung der Benutzt-Beziehung
→ Fehler in der obersten Schicht werden sehr fruh entdeckt→ Testrumpfe notwendig
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 44 / 55
Software-Test
Strategien des Integrationstests II
Sandwich-Test-Strategie: Kombination von Top-Down undBottom-Up
Identifikation der zu testenden Schicht: Zielschicht
zuerst: individuelle Komponententests
dann: kombinierte Schichttests:- Oberschichttest mit Zielschicht- Zielschicht mit Unterschicht- alle Schichten zusammen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 45 / 55
Software-Test
Leistungstests
Hartetest: viele gleichzeitige Anfragen
Volumentest: große Datenmengen
Sicherheitstests: Sicherheitslucken aufspuren
Zeitvorgabentests: werden spezifizierte Antwortzeiten eingehalten?
Erholungstests: Tests auf Erholung von fehlerhaften Zustanden
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 46 / 55
Software-Test
Zusammenfassung der Testarten
Strategie:− Urknall− Top−Down− Bottom−Up− Sandwich
SystemtestIntegrationstestKomponententest
Äquivalenztest
Grenztest zustands−basierter Test
Pfadtest
White−Box−TestBlack−Box−Test
Härtetest
Leistungstest
Feldtest
Erholungstest
Zeitvorgabentest
Funktionstest Installationstest
Akzeptanztest
Sicherheitstest
Volumentest
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 47 / 55
Software-Test
Testdokumentation: Aufzeichnung der Testaktivitaten
Testplan: Projektplan furs Testen
Testfallspezifikation: Dokumentation eines jeden Testfalls
Testvorfallbericht (Testprotokoll): Ergebnisse des Tests undUnterschiede zu erwarteten Ergebnissen
Testubersicht: Auflistung aller Fehler (entdeckt und noch zuuntersuchen)
→ Analyse und Priorisierung aller Fehler und deren Korrekturen
Testplan und Testfallspezifikation konnen sehr fruh schon erstellt werden.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 48 / 55
Software-Test
Testplan (IEEE Std. 829-1998 1998)
1. Einfuhrung
2. Beziehung zu anderen Dokumenten
3. Systemuberblick
4. Merkmale, die getestet/nicht getestet werden mussen
5. Abnahmekriterien
6. Vorgehensweise
7. Aufhebung und Wiederaufnahme
8. Zu prufendes Material (Hardware-/Softwareanforderungen)
9. Testfalle
10. Testzeitplan: Verantwortlichkeiten, Personalausstattung undWeiterbildungsbelange, Risiken und Schadensmoglichkeiten, Zeitplan
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 49 / 55
Testplan (IEEE Std. 829-1998 1998)
1. Einfuhrung
2. Beziehung zu anderen Dokumenten
3. Systemuberblick
4. Merkmale, die getestet/nicht getestet werden mussen
5. Abnahmekriterien
6. Vorgehensweise
7. Aufhebung und Wiederaufnahme
8. Zu prufendes Material (Hardware-/Softwareanforderungen)
9. Testfalle
10. Testzeitplan: Verantwortlichkeiten, Personalausstattung undWeiterbildungsbelange, Risiken und Schadensmoglichkeiten, Zeitplan2
009-0
1-1
3
Software-Projekt
Software-Test
Testplan
Testplan (IEEE Std. 829-1998 1998)
(Entspricht einer vereinfachten Variante von IEEE Std. 829-1998 (1998).)2.: Beziehung zu Anforderungsspezifikation und Architekturbeschreibung; Einfuhrung von Namenskonventionen, umTests und Anforderungen/Architektur in Beziehung zu setzen.
3.: Uberblick uber System hinsichtlich jener Komponenten, die durch Komponententests gepruft werden sollen.Granularitat der Komponenten und ihre Abhangigkeiten.4.: Konzentration auf funktionale Gesichtspunkte beim Testen; identifiziert alle merkmale und Kombinationen vonMerkmalen, die getestet werden mussen. Beschreibt auch diejenigen Merkmale, die nicht getestet werden und gibtGrunde dafur an.5.: Spezifiziert Abnahmekriterien fur die Tests (z.B. Testabdeckung).6.: Allgemeine Vorgehensweisen beim Testablauf; Integrationsstrategien.7.: Kriterien, wann Testaktivitaten ausgesetzt werden. Testaktivitaten, die wiederholt werden mussen, wenn dasTesten wieder aufgenommen wird.8.: Notwendige Betriebsmittel: physikalische Eigenarten der Umgebung sowie Anforderungen an Software,Hardware, Testwerkzeuge und andere Betriebsmittel (z.B. Arbeitsraum).9.: (das Herzstuck des Testplans) Auflistung aller Testfalle anhand individueller Testfallspezifikationen.
Software-Test
Testfallspezifikation
Testfallbezeichner: eindeutiger Name des Testfalls; am BestenNamenskonventionen benutzen
Testobjekte: Komponenten (und deren Merkmale), die getestetwerden sollen
Eingabespezifikationen: erwartete Eingaben
Ausgabespezifikationen: erwartete Ausgaben
Umgebungserfordernisse: notwendige Software- undHardware-Plattform sowie Testrumpfe und -stumpfe
Besondere prozedurale Anforderungen: Einschrankungen wieZeitvorgaben, Belastung oder Eingreifen durch den Operateur
Abhangigkeiten zwischen Testfallen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 50 / 55
Software-Test
Testschadensbericht
welche Merkmale wurden getestet?
wurden sie erfullt?
bei Storfallen: wie konnen sie reproduziert werden?
→ Sammlung und Priorisierung in der Testubersicht→ Test 6= Fehlersuche bzw. -korrektur!
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 51 / 55
Software-Test
Wiederholungsfragen I
Erlautern Sie die Unterschiede in den Fehlerbegriffen Storfall,fehlerhafter Zustand und Fehler.
Was ist ein positiver, was ein negativer Testfall?
Wer sollte testen?
Welche Arten von Tests gibt es?
Was ist ein Testfall?
Welche Aufgabe erfullen Teststumpfe und -treiber fur denKomponententest?
Was ist der Unterschied von Black- und Glass-Box-Tests?
Welche Techniken des Komponententests gibt es?
Erlautern Sie die Idee von Aquivalenztests am konkreten Beispiel.
Erlautern Sie die Idee von Grenztests am konkreten Beispiel.
Erlautern Sie die Idee von Pfadtests am konkreten Beispiel.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 52 / 55
Software-Test
Wiederholungsfragen II
Wie benutzt man JUnit fur den Komponententest?
Wozu benotigt man Polymorphismustests?
Erlautern Sie die Idee von zustandsbasierten Tests am konkretenBeispiel.
Welche Testabdeckungsmaße gibt es?
Nennen Sie Strategien fur Integrationstests und diskutieren Sie sie.
Erlautern Sie Leistungstests.
Was ist ein Testplan?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 53 / 55
Software-Test
1 Brugge und Dutoit 2004 Brugge, Bernd ; Dutoit, Allen H.:Objektorientierte Softwaretechnik. Prentice Hall, 2004
2 IEEE Std. 829-1998 1998 : IEEE Standard for Software TestDocumentation. IEEE Standards Board, IEEE Std. 829-1998. 1998
3 IEEE Std. 982-1989 1989 : IEEE Standard Guide for the Use of IEEEStandard Dictionary of Measures to Produce Reliable Software. IEEEStandards Board, IEEE Std. 982-1989. Juli 1989
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 54 / 55