Prof. Dr. Rainer Koschke - Uni Bremen || Startseite · Software-Test Lernziele Notwendigkeit und...

Software-Projekt

Prof. Dr. Rainer Koschke

Fachbereich Mathematik und InformatikArbeitsgruppe Softwaretechnik

Universitat Bremen

Wintersemester 2008/09

Uberblick I

1 Software-Test

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).


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 ;

}}


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).


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.


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.


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


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)


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


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


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



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


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)

. . .


Software-Test

Typen von Komponententests

Definition

White-/Glass-Box-Tests: Testfall wird mit Kenntnis der Implementierungentworfen.

Techniken:

Pfadtest

(zustandsbasierter Test)

. . .


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


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


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 ;

}}


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


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


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


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 ) ;}

}


Software-Test


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 ” ) ; }

}


Software-Test



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.


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


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


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


Software-Test

Maße der Testabdeckung

C0, Anweisungsuberdeckung (Befehlsabdeckung/Statement-Coverage):Verhaltnis von Anzahl der mit Testdaten durchlaufenenAnweisungen zur Gesamtanzahl der Anweisungen.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität




C0, Anweisungsuberdeckung (Befehlsabdeckung/Statement-Coverage):Verhaltnis von Anzahl der mit Testdaten durchlaufenenAnweisungen zur Gesamtanzahl der Anweisungen.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität


2009-0

1-1

3

Software-Projekt

Software-Test



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


C1, Zweig-/Entscheidungsuberdeckung Verhaltnis von Anzahl der mitTestdaten durchlaufenen Zweige zur Gesamtanzahl derZweige.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität




C1, Zweig-/Entscheidungsuberdeckung Verhaltnis von Anzahl der mitTestdaten durchlaufenen Zweige zur Gesamtanzahl derZweige.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität


2009-0

1-1

3

Software-Projekt

Software-Test



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


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 ;



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



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


C3, Abdeckung aller Bedingungskombinationen Verhaltnis von Anzahl dermit Testdaten durchlaufenen Bedingungskombinationen zurGesamtanzahl der Bedingungskombinationen.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität




C3, Abdeckung aller Bedingungskombinationen Verhaltnis von Anzahl dermit Testdaten durchlaufenen Bedingungskombinationen zurGesamtanzahl der Bedingungskombinationen.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität


2009-0

1-1

3

Software-Projekt

Software-Test



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


C4, Pfadabdeckung Verhaltnis von Anzahl der mit Testdatendurchlaufenen Pfade zur Gesamtanzahl der Pfade.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität




C4, Pfadabdeckung Verhaltnis von Anzahl der mit Testdatendurchlaufenen Pfade zur Gesamtanzahl der Pfade.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität


2009-0

1-1

3

Software-Projekt

Software-Test



(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??. . .

}


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 ( ) ;

}}


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


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 {. . .} ;

}


Software-Test

Zustande eines Stacks


Software-Test


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


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 ( ) ) ;


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 ( ) ) ;

}


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



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



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.


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


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


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


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


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.


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



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


(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


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!


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.


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?


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


Prof. Dr. Rainer Koschke - Uni Bremen || Startseite · Software-Test Lernziele Notwendigkeit und...

Documents

Transcript of Prof. Dr. Rainer Koschke - Uni Bremen || Startseite · Software-Test Lernziele Notwendigkeit und...