software-qualitÄtssicherung kapitel 6 und...

SoftwareEngineering

Prof.Dr.WolfgangSchramm

SOFTWARE-QUALITÄTSSICHERUNGUND-PRÜFUNG

Kapitel6

1

Übersicht

1. EinführungindasSoftwareEngineering

2. Softwareprozesse3. Anforderungsanalyseund-

Spezifikation4. Softwareentwurf5. Programmierung6. Software-Qualitätssicherungund-

Prüfung7. Konfigurationsverwaltung8. Software-Wartung

2

Kapitelübersicht

1. Einführung/Definition2. Begriffe3. DynamischeVerfahren– Testen4. StatischeVerfahren

3

LernzieledesKapitels

¨ BedeutungSoftware-Qualitätverstehen.

¨ KennenlernenderAufgabenderTestens.

¨ VerschiedeneTeststrategienkennen- undeinschätzenlernen.

¨ DenTest-Prozesskennenlernen.¨ StatischeQS-Verfahren

kennenlernen.

4

Kapitelübersicht

1. Einführung/Definition2. Begriffe3. DynamischeVerfahren- Testen

§ Teststrategien§ VorgehenbeimTesten§ Testautomatisierung

4. StatischeVerfahren

5

Murphy'sLaw

o WennirgendeinTeileinerMaschinefalscheingebautwerdenkann,sowirdsichimmerjemandfinden,derdasauchtut

o NachdemAuseinander- undZusammenbaueneinerVorrichtungbleibenimmereinigeTeileübrig

o BeieinerbeliebigenBerechnungwirddieZahl,derenRichtigkeitfüralleoffensichtlichist,zurFehlerquelle

6

Ariane5

o Europa's ganzerStolz:SuperraketeAriane5

o Entwicklungskosten in10Jahren:6024Mill.€!

o Jungfernflug am04.06.96Gewicht:740t,Nutzlast:7- 18tmit 4Cluster-Satelliten

7

Nach37Sekunden...

o 30Sekunden nach demLiftofferreichte dieAriane5in3700mFlughöhe eineHorizontal-Geschwindigkeitvon32768.0[interneEinheiten]

o Dieser Wertlagetwafünfmal höher als beiAriane 4.

8

DieFehlerquelle

declare vertical_veloc_sensor: float;

vertical_veloc_bias: integer;

horizontal_veloc_sensor: float;

horizontal_veloc_bias: integer; ...

begin

declare pragma suppress(numeric_error, horizontal_veloc_bias);

begin

sensor_get(vertical_veloc_sensor);

sensor_get(horizontal_veloc_sensor);

vertical_veloc_bias := integer(vertical_veloc_sensor);

horizontal_veloc_bias := integer(horizontal_veloc_sensor); ...

exception

when numeric_error => calculate_vertical_veloc();

when others => use_irs1(); end; end irs2;

Fehler-überprüfungabgeschaltet!

9

DieFolgen

o AbsturzdesBordcomputers36,7SekundennachdemStart.Grund:¤ VersuchderUmwandlungeiner64BitGleitpunktzahlinein16-Bit

vorzeichenbehaftetesGanzzahl-Format.¤ DieentsprechendeZahlwargrößerals215 =32768...¤ ...underzeugtesoeinenOverflow.

o ZusammenbruchdesLenksystems,derFlugwurdeinstabilunddieTriebwerkedrohtenabzubrechen.

è Selbstzerstörung...

10

DieHintergründe

o DieSoftwarestammtevonderAriane4...o ...nurflogdieAriane5wesentlichschneller.o DieSoftwarewarfürdenFlugüberflüsssig,nurwichtigfür

einenevtl.RestartbeiCountdownabbruch.o EinBackUp-RechnerverwendetediegleicheSoftwareund

warSekundenvorherabgestürzt!

o DiePrüfungderZahlumwandlungwarbewusstabgeschaltet!Niemandahnte,dassdiehorizontaleGeschwindigkeitsogroßwerdenkönnte.

11

DerSchaden

o 128Mill.€Startkosten434Mill.€Cluster-Satelliten306Mill.€für nachfolgende Verbesserungen

o Verdienstausfall für 2bis 3Jahre.

o Dernächste Testflug konnte erst 17Monate späterdurchgeführt werden – 1.Stufe beendete vorzeitig dasFeuern.

o Dererste kommerzielle Flug fand im Dezember 1999statt.

12 Wie stellen wir fest, ob es in der Software

einen Fehler gibt?

Wir prüfen, dass sie immer genau das

richtige tut.

13

Diskussion:Test-Ziele

¨ DiskutierenSiemiteinemPartner¤ WasistTesten?¤ WaskanndurchTestenerreicht

werden?¤ WaskanndurchTestennicht

erreichtwerden?

¨ Dauer:3Minuten

• MöglichstvieleFehlerfinden.

• AusfehlerfreierAusführungmitTestdatenstatistischauffehlerfreieAusführungmitrealenDatenimEinsatzschließen.

14

ZweiDingemüssendazuerfülltsein

1. DieEigenschaftendesProgrammssinddurchdieSpezifikationeindeutigfestgelegt.

2. DieEigenschaftenlassensichdurchPrüfungeindeutigundvollständigfeststellen.

Anforderungs-spezifikation ü

?

15

BetrachtungderKomplexität

o WirprüfeneineProzedur,dieermittelt,obzweivondreiParameterndesTypsBooleanTRUEsind:Þ achtAusführungsmöglichkeiten.

o EineFunktionmiteinemint-Parameterhat:Þ 232 (» 4*109)Ausführungsmöglichkeiten.

o EinProgrammdasvondreiVariablenmitje32Bitabhängt,hatÞ 296 (» knapp1030)verschiedeneStartzustände.

16

Also…

⇒WirwählenbeimTestenimmereineStichprobe.⇒Wirtestensystematisch.

Programtesting can be used to show the presence of bugs,butnever to show their absence! [Dij70]

Faustregel:Ineinem(leidlichsystematischen)TestfälltdieHälftederFehlerauf.

17

Beides ist wichtig!

SystematischoderintuitivTesten?

o Systematisch¤ DieRandbedingungen sinddefiniertoderpräziseerfasst.

n DassindsämtlicheGegebenheiten,dieaufdieResultateEinflusshaben.

¤ DieEingaben wurdensystematischausgewählt.¤ DieTestergebnisse werdendokumentiertundnachKriterienbeurteilt,

dievordemTestfestgelegtwurden.

o Intuitiv¤ …waskönntenichtfunktionieren?

18

DiepsychologischeSeite

o JedeSuche gehtvoneinerAnnahmenachdemGesuchten aus:¤ WennwireinProgrammuntersuchenin

derAnnahme,dassesfunktioniert,werdenwirvermutlichauchkeinenFehlerfinden.

¤ WennsicheinFehlernicht„enttarnen“lässt,soliegteshäufigdaran,dasswirunsdenFehlernichtvorstellenkonnten.

¤ Wennwiraberzeigenwollen,dasseinProgrammfehlerhaftist,werdenunsereTestdateneinehöhereWahrscheinlichkeithaben,Fehleraufzudecken.

19

IstSoftwarefehlerfrei?

Anwendung Umfang der Software

Zahl der Fehler

Restfehler Schwer-wiegende Restfehler

Autopilot zur Steuerung einer Rakete 30 000 1 500 60 6

Navigations-system des Space Shuttle

500 000 25 000 1 000 100

Flugkontroll Software (USA) 1 000 000 50 000 2 000 200

Software für Steuerung eines Kern-kraftwerks

1 500 000 75 000 3 000 300

20

Kapitelübersicht


21

DefinitionQualität/Qualitätssicherung

o Quality1. Thedegreetowhichasystem,component,orprocessmeets

specifiedrequirements.2. Thedegreetowhichasystem,component,orprocessmeets

customeroruserneedsorexpectations.

o Qualityassurance (QA)1. Aplannedandsystematicpatternofallactionsnecessarytoprovide

adequateconfidencethatanitemorproductconformstoestablishedtechnicalrequirements.

2. Asetofactivitiesdesignedtoevaluatetheprocessbywhichproductsaredevelopedormanufactured.

IEEE610-1990StandardGlossaryofSoftwareEngineeringTerminology

22

DefinitionTesten

o Testen istdieVorführungeinesProgrammsoderSystemsmitdemZielzuzeigen,dassestut,wasestunsollte

Hetzel:Thecompleteguidetosoftwaretesting,1984

o Testen istderProzesseinProgrammauszuführenmitderAbsicht,Fehlerzufinden

Myers:Theartofsoftwaretesting,1979

o Testing.Theprocessofoperatingasystemorcomponentunderspecifiedconditions,observingorrecordingtheresults,andmakinganevaluationofsomeaspectofthesystemorcomponent.


23

Testen

24

DefinitionTest

o Test1. Anactivityinwhichasystemorcomponentisexecutedunder

specifiedconditions,theresultsareobservedorrecorded,andanevaluationismadeofsomeaspectofthesystemorcomponent.

2. Toconductanactivityasin(1).IEEE610-1990StandardGlossaryofSoftwareEngineeringTerminology

26

Fehler,FehlerundnochmehrFehler

o Esgibt3zentraleFehler-Begriffe,dieleidernichteinheitlichverwendetwerden:¤ Irrtum/Fehlhandlung– error¤ Fehler/Fehlerzustand– defect¤ Fehlverhalten/Fehlerwirkung– failure

27

error,defect &failure

o DieFehlerursache/Irrtum(error)liegtimKopfdesDesignersbzw.desProgrammierers;siebildetdieGrundlagefürdenFehler.¤ Z.B.hatderProgrammierereinbest.Programmkonstruktnichtrichtigverstanden

(==vs.equals inJava).

o DerFehler(defect,fault) liegtindenDatenoderineinerKomponente/einemSystemundkanndortlokalisiertundbehobenwerden.¤ Z.B.inkorrekteAnweisungoderDatendefinition(z.B.Datenverlustbei

Typkonversion).¤ KannUrsachefüreinFehlverhaltensein.

o DasFehlverhalten(failure) wirdbeimProgrammlaufsichtbar.¤ AbweichungeinerKomponente/einesSystemsvondererwartetenLeistung,d.h.

spezifizierterSollwertundbeobachteterIstwertstimmennichtüberein.¤ WirkungeinesFehlers,diebeiderAusführungderKomponente/desSystemsnach

„außen“inErscheinungtritt.Es ist ein Unterschied, ob man ein

Fehlverhalten beseitigt oder sich über die Ursache Gedanken macht und den Fehler

beseitigt.

28

Geht‘sauchandersrum?MitKorrektheit?

FolgerungEinProgrammgiltbeidergeringstenAbweichungvonderSpezifikationalsnichtkorrektà abeinerbestimmtenKomplexität,gibteskaumnocheinkorrektesProgramm.

o KorrektheitisteinebinäreEigenschaft,d.h.eineSoftwareistentwederkorrektodernichtkorrekt.

o Einefehlerfreie Softwareistkorrekt.o EineSoftwareistkorrekt,wennsiekonsistent zuihrer

Spezifikationist.o ExistiertzueinerSoftwarekeineSpezifikation,soisteine

Überprüfung derKorrektheitunmöglich.

29

Testen– aberwie?

o DaeinTest,derkeineFehleraufdeckt,imwesentlicheneineVerschwendungvonZeitundGeldist,folgt:Þ EinguterTest isteiner,dermithoherWahrscheinlichkeiteinenbis

jetztunbekanntenFehleraufdeckt.

o EinTest,dereinenFehleraufdeckt,istkeineüberflüssigeMühe,daerdemProgrammWerthinzugefügthat;dahergilt:Þ EinerfolgreicherTestisteiner,dereinenbisjetztunbekannten

Fehleraufdeckt.

30

Testfall(Definition)

EinTestfall (test case)bezeichneteinenSatzvonkonkretenEingaben(eventuellinklusiveStartzustand)füreinProgrammzurDurchführungeinesbestimmtenTestszusammenmitdervomProgrammerwartetenAusgabe(eventuellinklusiveEndzustand).


o Asetoftestinputs,executionconditions,andexpectedresultsdevelopedforaparticularobjective,suchastoexerciseaparticularprogrampathortoverifycompliancewithaspecificrequirement.


31

Diskussion

¨ GetestetwerdensolldieSteuerungfüreinenFrostwächter,dernachtsineinemGewächshausdafürsorgensoll,dassdieTemperaturnichtunter0Gradsinkt.

¨ MachenSiezujedemnotwendigenTestfallallerelevantenAngaben.

32

Testen– wasistderGewinn?

o BeimTestwirddieQualität (dieVerlässlichkeit,derWert)einesProgrammserhöht.

o DieQualitäterhöhenbedeutetFehler zufindenund zubeseitigen.

o Dahersolltemannichtzeigenwollen,dassdasProgrammfunktioniertsondernmitderAnnahmebeginnen,dassesFehlerenthält.DieseAnnahmegiltohnehinfürdiemeistenProgramme.

33

GroßerNachteilvonTesten

o GetestetwerdenkönnenimmernurausführbareArtefakte(Dokumente),dasheißtProgrammcode.

o DieFehlerursacheliegtabermeistensfrüher.o ZumBeispielszenariobasierte AnalysenundInspektionen

helfen,FehlernfrüheraufdieSpurzukommen.

34

Beides ist wichtig!

SystematischoderintuitivTesten?

o Systematisch¤ DieRandbedingungen sinddefiniertoderpräziseerfasst.

n DassindsämtlicheGegebenheiten,dieaufdieResultateEinflusshaben.

¤ DieEingaben wurdensystematischausgewählt.¤ DieTestergebnisse werdendokumentiertundnachKriterienbeurteilt,

dievordemTestfestgelegtwurden.

o Intuitiv¤ …waskönntenichtfunktionieren?

35

WasistkeinTest?

o Irgendeine InspektioneinesProgramms.o DieVorführung einesProgramms.o DieAnalyse einesProgramms,durchSoftware-Werkzeuge,

z.B.zurErhebungvonMetriken.o DieUntersuchungeinesProgrammsmitHilfeeines

Debuggers.

36

DefinitionTestprozess

Spillner, Linz: Basiswissen Softwaretest, 2010

37

Testen– Wieläuftdasab?

EinProgrammausführen(ggf.auchmehrfach),mitderAbsichtFehlerzufinden.

Testfälle Testdaten

Test-protokolle

Test-ergebnisse

Entwerfen der Testfälle

Erstellen der Testdaten

Vergleich der Ergebnisse mit Testfällen

Ausführen des Programms mit Testdaten

38

DefinitionK/I/S/A-Test

o Componenttesting Testingofindividualhardwareorsoftwarecomponentsorgroupsofrelatedcomponents.

o Integrationtesting Testinginwhichsoftwarecomponents,hardwarecomponents,orbotharecombinedandtestedtoevaluatetheinteractionbetweenthem.

o Systemtesting Testingconductedonacomplete,integratedsystemtoevaluatethesystem’scompliancewithitsspecifiedrequirements.

o Acceptancetesting Formaltestingconductedtodeterminewhetherornotasystemsatisfiesitsacceptancecriteriaandtoenablethecustomertodeterminewhetherornottoacceptthesystem.


39

K/I/S/A-TestimEntwicklungsprozess

Komponententest

Integrationstest

Systemtest

Akzeptanztest

40

Waswirdgetestet?

o Komponententest¤ Fokus:Funktionalität,Sonderfälle,Performanzetc.

o Integrationstest¤ Inkrementellvs."allesaufeinmal"¤ Fokus:Schnittstellen,Kommunikation

o Systemtest¤ InderrealenUmgebung,ohneAuftraggeber¤ Fokus:Vollständigkeit,Konfiguration,Interoperabilität,Performanzetc.

o Akzeptanztest (Abnahmetest)¤ BeimAuftraggeber¤ Fokus:Zeigen,dassdiegestelltenAnf.umgesetztsind

41

Kapitelübersicht


§ Teststrategien§ VorgehenbeimTesten§ Testautomatisierung


42

MerkmaledynamischerTesttechniken

o AusführungdesProgrammsmitkonkretenEingabewerten.o TestinderrealenBetriebsumgebung.o EssindStichprobenverfahren.o BeweisennichtdieKorrektheitdergetestetenSoftware.

→ Testfällesollten:n repräsentativ,n fehlersensitiv,n redundanzarmundn ökonomischsein.

43

Testen- Grundlagen

o Jeder Test ist eine Stichprobe.o Korrektheit kann durch Testen nicht bewiesen werden.

¤ Beispiele:n Addition von zwei 32-Bit-Zahlen: 264 mögliche Testfällen Bearbeitung einer Zeichenkette mit 32 Zeichen: 2256 mögliche Testfälle

o Erwartete Ergebnisse müssen im Voraus bekannt sein.¤ Testen gegen die Spezifikation.¤ Testen gegen vorhandene Ergebnisse (Regressionstest).

o Unvorbereitete und undokumentierte Tests sind Zeitverschwendung.

o Testen findet Fehlersymptome (failures und defects), keine Fehlerursachen (errors).

o Nach dem Test: Fehlerursachen finden und beheben (Debugging).

44

Testaufwand

KleineAufwandrechnung:264 » 1,8·1019

o Annahme1:ManuellerTestmit1Testfall/sVollständigerTestdauertca.1,8·1019 s» 58,5MilliardenJahre

o Annahme2:AutomatisierterTestauf1000Rechnernparallel,1Testfall/μs→109 Testfälle/sVollständigerTestdauertca.1,8·1010 s» 58,5Jahre

45

Kapitelübersicht


§ Teststrategien§ Blackbox-Test§ Glassbox-Test§ Graybox-Test

§ VorgehenbeimTesten§ Testautomatisierung


46

3Teststrategien

Blackboxtest Benutzer– siesehendasSystemnurvonaußen:Funktionalität.

Grayboxtest Tester– schauenauchaufdieFunktionalität,aberauchdarunterz.B.obdieDateninderDBkorrektabgelegtsind.

Whiteboxtest Entwickler– kennendenCodeundtestendaraufhin,obderCoderichtigarbeitet.

Alle3Sichtenmüssenberücksichtigtwerden.Z.B.kanneinWhiteboxtest funktionieren,weileinefalscheAnnahmegetroffenwurde,diedannvondenanderenTestsaufgedecktwird.

47

Blackbox-Tests

o DieinnereStrukturdesProgrammsinteressiertnicht.

o Testfälle(engl:test cases)werdenausschließlichausderSpezifikationabgeleitet.

o DerTesteristinteressiertamFindenvonUmständen(Testfälle),indenendasProgrammnichtmitseinerSpezifikationübereinstimmt.

o AndereBezeichnungen:Data-driven Tests,I/O-driven Tests,funktionalesTesten.

x1x2x3

y1

y2

y1 = f( x1, x2)y2 = g(x2, x3)

48

Blackbox-Test

o EinumfassenderBlackbox-Testsollte:¤ AlleFunktionendesProgramms

aktivieren(Funktionsüberdeckung).¤ AllemöglichenEingabenbearbeiten

(Eingabeüberdeckung).¤ AllemöglichenAusgabeformen

erzeugen(Ausgabeüberdeckung).¤ DieLeistungenausloten.¤ DiespezifischenMengengrenzen

ausschöpfen.¤ AlleFehlersituationenherbeiführen.

Jede Anforderung muss getestet werden.

50

Blackboxtesten:Testfallbildung

o EinSortierprogrammverwendetShakerSort fürZahlenfolgenmitbiszu15Elementen,beimehrals15ElementenwirdQuickSort verwendet.Die“interneGrenze”15/16hatsichderImplementierer ausgedacht(vielleichtgemessen),sietrittinderSpezifikationnichtauf,istalsofürdenBlackbox-Testervölligunvorhersehbar.

void sort ( Object [ ] sortArray ) {if ( sortArray.length <=15 )

shakerSort( sortArray );else

quickSort( sortArray );}

o DieChance,diesen(nichtböswilligen!)FehlermittelsBlackbox-Testszuentdecken,istziemlichgering.

o Folge:Vermutlichwirddiesort-Methodeniemitmehrals15ObjektengetestetundderQuickSort-Algorithmusbleibtvölligungetestet.

51


Problem:persistenteDateno IhrVerhaltenistnichtnurvondenaktuellenEingabedaten

abhängig,sondernvonihrerGeschichte(besondersReihenfolge!)o Beispiel

¤ IneinemProgrammmiteinerKunden-DatenbankkönnenausderDatenbankherausautomatischRechnungenerstelltwerden.

¤ BezahlteBeträgewerdeninderDatenbankmarkiert.¤ Rechnungenwerdennurerstellt,wennderBetragnochnichtals

"bezahlt"gekennzeichnetist.¤ DieReihenfolgeRechnungdrucken« Betragals"bezahlt"markieren.

beeinflusstdenZustand,damitdenProgrammablaufunddamitdieTests,diezustandsabhängigerfolgenmüssen.

o EsmüssenalleReihenfolgenallermöglichenEingabengetestetwerden.

52

Übung:Testfällefür3-ecks-Programm[My77]

¨ FindenSiedieTestfälle,diealle3-ecks-Berechnungenabdecken.

53

5.11.20042.2 Funktionstest

Ein“klassisches” Beispiel(Myers)

o Funktionmitdreiint-Eingabewerten(x,y,z),diealsLängenvonDreiecksseiteninterpretiertwerden.

o Berechnet,obdasDreieckgleichseitig,gleich-schenklig oderungleichseitigist.

o SchreibenSiefürdieseFunktionTestfälleauf!(jetzt!)

54


AuswertungnachPunkten1/4

1. HabenSieeinenTestfallfüreinzulässigesgleichseitigesDreieck?

2. HabenSieeinenTestfallfüreinzulässigesgleichschenkligesDreieck?(EinTestfallmit2,2,4zähltnicht.)

3. HabenSieeinenTestfallfüreinzulässigesungleichseitigesDreieck?(BeachtenSie,dassTestfällemit1,2,3und2,5,10keineJa-Antwortgarantieren,dakeinDreieckmitsolchenSeitenexistiert.)

4. HabenSiewenigstensdreiTestfällefürzulässige,gleichschenkligeDreiecke,wobeiSiealledreiPermutationenderbeidengleichenSeitenberücksichtigthaben?(z.B.3,3,4;3,4,3;4,3,3)

55



5. HabenSieeinenTestfall,beidemeineSeitegleichNullist?6. HabenSieeinenTestfall,beidemeineSeiteeinennegativen

Werthat?7. HabenSieeinenTestfallmit3ganzzahligenWerten,indem

dieSummezweierZahlengleichderdrittenist?(D.h.,wenndasProgramm1,2,3alsungleichseitigesDreieckakzeptiert,soenthälteseinenFehler.)

8. HabenSiewenigstensdreiTestfällefürPunkt7,wobeiSiealledreiPermutationenfürdieLängejeweilseinerSeitealsSummederbeidenanderenSeitenberücksichtigthaben?(z.B.1,2,3;1,3,2;3,1,2.)

9. HabenSieeinenTestfallmitdreiganzzahligenWertengrößerNull,beidemdieSummeauszweiZahlenkleineralsdiedritteist?(z.B.1,2,4oder12,15,30)

56



10. HabenSiewenigstensdreiTestfällefürPunkt9,wobeiSiealledreiPermutationenberücksichtigthaben?(z.B.1,2,4;1,4,2;4,1,2.)

11. HabenSieeinenTestfall,indemalledreiSeitengleichNullsind(d.h.0,0,0)?

12. HabenSiewenigstenseinenTestfallmitnichtganzzahligenWerten?

13. HabenSiewenigstenseinenTestfall,indemSieeinefalscheAnzahlvonWertenangeben(z.B.zweistattdreiganzzahligeWerte)?

14. HabenSiezusätzlichzujedemEingangswertinallenTestfällendieerwartetenAusgabewerteangegeben?

57


AuswertungnachPunkten(Zusatzpunkte)4/4

15. TestmitmaximalenWerten.16. TestaufZahlbereichs-Überlaufbehandlung.17. TestmitunzulässigenEingabezeichenfolgen.

58


MyersErgebnisse+Folgerungen

o DurchschnittswerteerfahrenerProgrammierer:7-8o „DieseÜbungsolltezeigen,dassdasTestenaucheinessolchtrivialenProgrammskeineleichteAufgabeist.Undwenndaswahrist,betrachtenSiedieSchwierigkeit,einFlugleitsystemmit100.000Befehlen,einenCompileroderauchnureingängigesGehaltsabrechnungsprogrammzutesten.“ (1979)

o Heute:1-10MLoC

60


o ErschöpfendesTestenbedeutet,jedemöglicheEingabewirdalsTestfallvorgesehenunddasProgrammdamitgetestet.

® DasbedeuteteineriesigeMengeanTesteingaben.® ErschöpfendeBlackbox-Testssindnichtpraktisch

durchführbar.DiegenanntenBeispielesindMini-Probleme!

61

ProblemderTestfall-Auswahl

DiegewähltenTestzielemit¤ möglichstwenig¤ möglichstguten

Testfällenumsetzen.

KlassischeTechniken:o Äquivalenzklassenbildungo Grenzwertanalyseo Ursache-Wirkungsgrapheno StatistischesTesten(random testing)

im Folgenden betrachtet

62

Äquivalenzklassen

o ZueinerÄquivalenzklassegehörenalleEingabewerte,beidenenderTesterdavonausgeht,dasssichdasTestobjektbeiEingabeeinesbeliebigenDatumsausderÄquivalenzklassegleichverhält.

o DerTesteines Repräsentanteneiner Äquivalenzklassewirdalsausreichendangesehen,dadavonausgegangenwird,dassdasTestobjektfüralleanderenEingabewertederselbenÄquivalenzklassekeineandereReaktionzeigt.

63

Äquivalenzklassen

o Esgibt2ArtenvonÄquivalenzklassen:¤ Gültige Äquivalenzklassen repräsentierengültigeEingabenfürein

Programm.¤ Ungültige Äquivalenzklassen repräsentierenalleanderenEingaben.

o WiekommtmanzudenÄquivalenzklassen?Þ HeuristischeRegelnzurIdentifizierungvonÄquivalenz-

klassen.

64

Heuristik

o Heuristik (altgr. εὑρίσκω heurísko ‚ich finde‘ zu heuriskein ‚(auf)finden,entdecken‘)¤ Bezeichnet die Kunst, mit begrenztem Wissen und wenig Zeit zu guten Lösungen zu

kommen.¤ Es bezeichnet ein analytisches Vorgehen, bei dem mit begrenztem Wissen über ein

System mit Mutmaßungen Aussagen über das System getroffen werden, die dannmit Hilfe empirischer Methoden verifiziert werden, um die Korrektheit derVorstellung über das System (Systemmodell), auf Grund derer diese Aussagenentwickelt wurden, zu schärfen.

o Heuristik in der Informatik¤ Anwendung von heuristischen Methoden, um mit geringem Rechenaufwand und

kurzer Laufzeit zulässige Lösungen für ein bestimmtes Problem zu erhalten.Klassische Algorithmen versuchen, einerseits die optimale Rechenzeit undandererseits die optimale Lösung zu garantieren. Heuristische Verfahren verwerfeneinen oder beide dieser Ansprüche, um bei komplexen Aufgaben einen Kompromisszwischen dem Rechenaufwand und der Güte der gefundenen Lösung einzugehen.Dazu wird versucht, mithilfe von Schätzungen, „Faustregeln“, intuitiv-intelligentemRaten oder unter zusätzlichen Hilfsannahmen eine gute Lösung zu erzeugen, ohneoptimale Eigenschaften zu garantieren.

¤ Bekannte heuristische Algorithmen: Evolutionäre Algorithmen in der Optimierung.Quelle: Wikipedia

65

IdentifizierungvonÄquivalenzklassen

o DefinitionsbereichderEingabewerte¤ Äquivalenzklasseallezulässigen/erlaubtenWerte:dieseWertemussdasTestobjekt

gemäßderSpezifikationverarbeiten

o WerteaußerhalbdesDefinitionsbereichsderEingabewerte¤ ÄquivalenzklassenalleunzulässigenWerte:fürdieseWertemussauchüberprüft

werden,wiesichdasTestobjektverhält.

o VerfeinerungderÄquivalenzklassen¤ AlleÄquivalenzklassenelemente,dielautSpezifikationunterschiedlichverarbeitet

werdensollenà (Unter-)Äquivalenzklasse.

¤ DieÄquivalenzklassenwerdensolangeweiteraufgeteilt,bissichalleunterschiedlichenAnforderungenmitdenjeweiligenÄquivalenzklassendecken.

¤ AmEndedesVerfeinerungsprozessesistfürjedeÄquivalenzklasseeinRepräsentantfüreinenTestfallzuwählen.

o Nichtvergessen:ZujedemRepräsentantenmussauchdasvorausgesagteErgebnis(undggf.dieVorbedingungen)festgelegtwerden.

66

Schritt1:IdentifizierungvonÄquivalenzklassen

o EingabebedingunggibteinenBereichvonWerten(z.B."gültigeEingabensind101..999")an:¤ EinegültigeÄquivalenzklasse(test1=500).

¤ ZweiungültigeÄquivalenzklassen(test2=-100undtest3=“1000“).

o Eingabebedingungspezifiziert,dasseineAnzahlvonWerten(z.B.3)einzugebenist:¤ EinegültigeÄquivalenzklasse(test1=3Werte).

¤ ZweiungültigeÄquivalenzklassen(test2=2Werteundtest3=4Werte).

o EingabebedingungspezifizierteineMengevonWerten,dieunterschriedlich zubehandelnsind(z.B."Ampelfarbensindrot,gelbundgrün")¤ EinegültigeÄquivalenzklassefürjedesMengenelement(test1=rot,test2=gelb,test3=grün).

¤ EineungültigeÄquivalenzklassefüreinNicht-Element(test4=blau).

o EingabebedingungkennzeichneteineMuss-Situation(z.B."einBezeichnerinJavamussmiteinemBuchstabenbeginnen"):¤ EinegültigeÄquivalenzklasse(test1="einDatum":BezeichnerbeginntmiteinemBuchstaben).

¤ EineungültigeÄquivalenzklasse(test2="2Daten":BezeichnerbeginntmiteinerZahl).

67

Schritt2:AbleitungderTestfälle

o DieÄquivalenzklassen sindeindeutigzunummerieren.

o FürdieErzeugungvonTestfällenausdenÄquivalenzklassensindzweiRegelnzubeachten:1. DieTestfällefürgültige Äquivalenzklassen werdendurchAuswahl

vonTestdatenausmöglichstvielengültigenÄquivalenzklassengebildet.

2. DieTestfällefürungültige Äquivalenzklassen werdendurchAuswahleinesTestdatumsauseinerungültigenÄquivalenzklassegebildet.EswirdmitWertenkombiniert,dieausschließlichausgültigenÄquivalenzklassenentnommensind.

70

Grenzwertanalyse

o AndenGrenzenzulässigerDatenbereichetretenerfahrungsgemäßhäufigFehlerauf.

o TestfällefürsolcheGrenzfälleauswählen.

o Beispiel:MultiplikationzweierganzerZahlenxundy

o MöglicheGrenzfällefürxundy¤ -1¤ 0¤ 1¤ Produktläuftpositivüber¤ Produktläuftnegativüber

Heuristik

71

Grenzwertanalyse+Äquivalenzklassenbildung

o AnstattauseinerÄquivalenzklasseeinenbeliebigenWertalsRepräsentantenfüreinenTestfallzuwählen,verlangtdieRandwertanalyse,dasseinodermehrereWertesogewähltwerden,dassdieEndenderWertebereichejederÄquivalenzklasseüberprüftwerden.

o AnstattsichnuraufdenEingaberaumzukonzentrieren,wirdauchderErgebnisraum beiderBildungderTestfällebeachtet.

72

Testfallgenerierung

1. FürjedeEingabeÄquivalenzklassen bilden.2. RepräsentantenmitGrenzwertanalysebestimmen

¤ Bereiche:Grenzwert,Grenzwert„+1“,Grenzwert„- 1“.¤ Aufzählungen:alleElemente,einungültigesElement.

3. Testfälle bilden.¤ „gültige“Testfälle:

n fürjedeEingabeeinengültigenRepräsentantenwählen,n jedergültigeRepräsentantmindestenseinmal.

¤ „ungültige“Testfälle:n fürgenaueineEingabeungültigenRepräsentantenwählen,

alleanderenEingabengültig,n jederungültigeRepräsentantmindestenseinmal.

73

Grenzwertanalyse- Testfälle

HeuristischguteRegelnzurErstellungvonTestfällen:o WenneineEingabebedingungeinenBereich odereineAnzahl von

Werten(z.B.1bis999)angibt,entwirfTestfällefürdieEndendesgültigenWertebereiches(1und999)undfürWerte,diedirektaußerhalbliegen(0und1000).

o WendedieseRegelaufdieAusgabebedingungenan,d.h.entwirfTestfälleso,dassdieEndendergültigenAusgabebereicheerreichtwerdenundversucheTestfällesozuwählen,dassdieErgebniswertegeradeaußerhalbdesgültigenWertebereichsliegenwürden.Beispiel:DasErgebniseinerSinusfunktionsollte+1.0und-1.0erreichen(fürdieEingabewerte1/2 p und3/2 p).

o WenneineEingabebedingungeinegeordnete Liste vonWertenspezifiziert,entwirfTestfälle,diesichaufdasersteunddasletzteElementderMengekonzentrieren.

75

Kapitelübersicht



§ VorgehenbeimTesten§ Testautomatisierung


76

Glass-Box-Test

o Synonyme:Whitebox-Test/StrukturellesTesten.

o DerTesterentwickeltTestfälleauseinerBetrachtungderAblauflogikdesProgrammsunterBerücksichtigungderSpezifikation.

o Ziel:MöglichstvielePfadetesten(=Pfad)

77

BestimmungvonVerzweigungen/Pfaden

o BestimmungderProgrammverzweigungen¤ BedingteAnweisungenundSchleifen:zweiZweige

n „if ohneelse“:ebensozweiZweige

¤ EineFallunterscheidung:Zweige=AnzahlderFälleà Kontrollflussgraph

o EinPfad isteineFolgevonZweigenvomStartzumEndeo BestimmungallerPfade:

¤ AlleKombinationenn allerProgrammzweigen beiSchleifen:allermöglichenAnzahlenvonDurchläufen

if, while

switch

Zweig

if

else-Fallthen-Fall

78

Glassbox-Tests

a == 3

b >= 0 || c > 0

b++;

println( 4/( b + 2*c ) );

Yes

Yes

No

No

Für den Glasbox-Test betrachtet man Pfade.

80

Überdeckungskriterien1/2

o Anweisungsüberdeckung/StatementCoverage /C0-Überdeckung¤ AlleAnweisungenwerdenausgeführt.

o Zweigüberdeckung/Branch Coverage /C1-Überdeckung¤ BeiVerzweigungenwerdenallemöglichen

Wege(Zweige)durchlaufen.

o Pfadüberdeckung(PathCoverage)¤ AllemöglichenWegewerdendurchlaufen.

81

Überdeckungskriterien2/2

o Termüberdeckung (Condition Coverage):GründlicheÜberprüfungkomplizierter,zusammengesetzterEntscheidungen.¤ SimpleCondition Coverage /Einfache

Bedingungsüberdeckung/C2-Überdeckungn JederlogischeTerm,dereineVerzweigungsteuert,

wirdmitdenmöglichenWerten(true oderfalse)belegt.

¤ MinimalMultipleCondition Coverage /MinimaleMehrfachüberdeckung/C3-Überdeckungn DergesamtelogischeTerm,dereineVerzweigung

steuert,wirdmitdenmöglichenWerten(true oderfalse)belegt - verkürzteAuswertungderTeilausdrücke.

¤ MultipleCondition Coveragen JederlogischeTerm,dereineVerzweigungsteuert,

wirdmitfastallenmöglichenWerten(true oderfalse)belegt– völlständige Auswertung.

82

Überdeckungen- Zusammenfassung

o Überdeckungen, besonders C1 und C2, spielen bei der Qualitäts-sicherung eine wesentliche Rolle.

o Vollständige Überdeckungen sind selten zu erreichen, was in derVielfalt der Ablaufmöglichkeiten z. B. mit schwer zu testenden try-catch-Blöcken liegen kann.

o Da man sich bei Überdeckungen immer fragt, welche Auswirkungein Befehl, eine Bedingung oder eine Variable haben kann, findetman durch solche Ansätze viele kleine Fehler.

o Um effizient mit Überdeckungstests arbeiten zu können, ist eineAutomatisierung der wiederholten Testausführung mit derBerechnung und Analyse der Überdeckungen unerlässlich.

o Generell ist beim Überdeckungsansatz zu beachten, dass man zwargenau die inneren Details der Abläufe prüft, es aber nichtfestgestellt werden kann, ob das Programm überhaupt seineursprüngliche Aufgabenstellung erfüllt.

83

BestimmungvonZweigenundPfaden

BestimmungderProgrammzweige:o BetrachtungvonVerzweigungenundSchleifen.o BeiProgrammiersprachenmitgeschlossenen

Ablaufkonstrukten:¤ if-Anweisungen(auchdieohneelse)undSchleifen

habenjezweiZweige.¤ Einecase/switch-Anweisung:sovieleZweigewieFälle.

BestimmungderPfade:o AlleKombinationeno allerProgrammzweigeo beimaximalemDurchlaufallerSchleifen.

84

Beispiel(nach[Mye79])

VAR

a,b,x: INTEGER;

...

BEGIN

IF (a>1) AND (b=0)

THEN x := x DIV a;

IF (a=2) OR (x>1)

THEN x := x+1;

...

85

Übung

¨ ÜberlegensiesichdieTestfällefürdiedreiÜberdeckungskriterien:¤ Anweisungsüberdeckung¤ Zweigüberdeckung¤ Pfadüberdeckung

86

NotwendigeTestfälle

AnweisungsüberdeckungmitdemTestfall:o a=2b=0x=1

ZweigüberdeckungmitdenTestfällen:o a=3b=0x=3(obenthen-Zweig,untenelse-Zweig)o a=2b=1x=1(obenelse-Zweig,untenthen-Zweig)

¤ AuchandereZweigkombinationensindzulässig.JederZweigmuss1xdurchlaufenwerden.

PfadüberdeckungmitdenTestfällen:o a=1b=1x=2o a=3b=0x=3o a=2b=0x=4o a=1b=1x=1

87

Glasbox-Tests

o DieAnzahlderPfadedurcheinProgrammistmeistenssehrhoch.

o BeispieleinesProgramm-Ablaufplans

88

Übung

o BestimmensiedieAnzahlderPfadedurchdasdargestellteProgramm.

88

89

Lösung

o DieeindeutigenPfadedurchdiesesProgrammentsprichtderAnzahlderMöglichkeitenvonAnachBzukommen.

o DieseZahlist51 (1Durchlauf)+52 +...+520(20Durchläufe)¤ wobei5dieZahlderPfadedurchden

Schleifenrumpfist¤ Dasergibtca.1014.

90

BinäreSuche

GebenSiedenKontrollflussgraphenan.

91

Kontrollflussgraph

92

Anweisungsüberdeckung

o ÜberdeckungallerAnweisungen:C0-Test:JedeAnweisung(numerierte Zeile)desProgrammswirdmindestenseinmalausgeführt.

o ImBeispiel:a={11,22,33,44,55},k =33überdecktAnweisungen:1,2,3,4,5,9a={11,22,33,44,55},k =15überdecktAnweisungen:1,2,3,4,6,7,8,9

o BeideTestfällezusammenerreichenvolleAnweisungsüberdeckung.

o MessenderAnweisungsüberdeckung:¤ "Instrumentieren"desCodes(durchWerkzeuge)¤ EinfügenvonZählanweisungenbeijederAnweisung

Man kann auch mit einem einzigen Testfall die C0-Abdeckung erreichen.

93

Zweigüberdeckung

o ÜberdeckungallerZweige:C1-Test: BeijederFallunterscheidung(einschließlichSchleifen)werdenbeideZweigeausgeführt(Bedingung=true undBedingung=false).

o ZweigtestzwingtauchzurUntersuchung"leerer"Alternativen:if (x >= 1)

y = true; // kein else-Fall

o ImBeispiel:DiebeidenTestfällederletztenFolieüberdeckenalleZweige.

o Messung/InstrumentierungvonAnweisungi:¤ Fallunterscheidung:if (...) { bT[i]++; ... } else { bF[i]++; ... }

¤ While-Schleife:while (...) { bT[i]++; ... } bF[i]++;

94

Testgüte undÜberdeckungsgrad

o DieTestgüte hängtvongewählterÜberdeckungunderreichtemÜberdeckungsgradab.

o Überdeckungsgrad – ProzentualesVerhältnisderAnzahlüberdeckterElementezurAnzahlvorhandenerElemente.

o Beispiel:DerTestfalla=3b=0x=3erreicht50%Zweigüberdeckung.

95

Testgüte undÜberdeckungsgrad

o AnweisungsüberdeckungisteinschwachesKriterium.FehlendeAnweisungenwerdenbeispielsweisenichtentdeckt.

o ZweigüberdeckungwirdinderPraxisangestrebt.Dennoch:falschformulierteBedingungsterme(z.B.x>1stattx<1)werdennichtentdeckt.

o PfadüberdeckungistinfastallenProgrammen,dieSchleifenmitVerzweigungenenthalten,nichttestbar.

96

Kapitelübersicht



§ VorgehenbeimTesten§ Nicht-funktionaleTests


97

Graybox-Test- Anwendungsszenario

o TypischerAnwendungsbereich:Webanwendungen¤ ÜbereineWebschnittstellewerdenDatenineinerDatenbank

verschoben.¤ ManmusssichsowohlmitdemDatenbankcodealsauchmitder

Webschnittstellebefassen.n AuditingundLogging prüfen:BestimmteDatensindnichtüberdasgewöhnlicheUIverfügberà Log-Analyse,Audit-Reporting,direkteAbfragevonbest.Datenbanktabellen.

n FürandereSystemgedachteDaten:Ausgabenbzw.Ausgabeformateprüfen.n VomSystemgenerierteInformation:WennAnwendungenz.B.PrüfsummernoderHashwerteerzeugenàmanuellprüfen.OderbeivomSystemerzeugtenZeitstempelnaufdierichtigeZeitzoneachten.

n MemoryLeaks:Untersuchen,obDaten,diegelöschtwerdensollenauchtatsächlichgelöschtwurden,obRegistrierungseinträgekorrektdurchgeführtwurden.

98

IllustrationGraybox-Tests

Eingaben

KorrekteSoll-Ausgabe?


Eingaben


Eingaben

99


Eingaben



Eingaben


Eingaben

100


Eingaben



Eingaben


Eingaben

101

Graybox-Test

o Graybox-Testsversuchen,dieVorteilevonBlackbox- undGlasbox-Testverfahrenzukombinieren.

Vorgeheno Soll-Überdeckungsgradfestlegen,z.B.Zweigüberdeckung.o ZunächstBlackbox-Testsdurchführen

¤ ZurÜberprüfungderFunktionalität,¤ Überdeckungwird(imHintergrund)mitprotokolliert.

o DannGlasbox-Testdurchführen¤ AnalysedernichtüberdecktenProgrammteile.

n KorrekturdesProgramms(EntfernenunnötigerTeile)odern ErstellenzusätzlicherTestfälle.

¤ Testen,bisdervordefinierteÜberdeckungsgraderreichtist.

102

Kapitelübersicht



§ Nicht-funktionaleTests§ VorgehenbeimTesten


103

Nicht-funktionaleTests

o Lasttest Last=AnzahlNutzer,AnzahlTransaktionen,etc.

¤ Performance-Test MessungderAntwortzeit(i.d.R.lastabhängig)¤ Volumen-Test VerhaltenbeigroßenDatenmengen¤ Stress-Test VerhaltenbeiÜberlast

o TestderSicherheito TestderStabilität(imDauerbetrieb)o TestderBenutzerfreundlichkeito TestaufKompatibilität

¤ andereSysteme,(alte)Datenbestände

112

Kapitelübersicht



§ Nicht-funktionaleTests§ VorgehenbeimTesten


113

VorgehenbeimTesten

o Wiewirdgetestet?o Waswirdgetestet?o Wannwirdgetestet?o Wiewirddokumentiert?o Wannistmanfertigmittesten?

114

DerTestprozess

Testfälle Testdaten

Test-protokolle

Test-ergebnisse

Entwerfen der Testfälle

Erstellen der Testdaten

Vergleich der Ergebnisse mit Testfällen

Ausführen des Programms mit Testdaten

115

Waswirdgetestet?

o TestgegenstandsindKomponenten,Teilsysteme oderSysteme

o Komponententest,Modultest(UnitTest)

o Integrationstest(IntegrationTest)

o Systemtest(SystemTest)

vgl. K/I/S/A

116

Wannwirdgetestet?1/3

Komponententest

Integrationstest

Systemtest

Akzeptanztest

117


o Unit-Test,Modultest,Komponententest(auch:Klassentest)¤ Fokus:Funktionalität,Sonderfälle,Performanzetc.

o Integrationstest¤ Inkrementellvs."allesaufeinmal"¤ Fokus:Schnittstellen,Kommunikation

o Systemtest¤ InderrealenUmgebung,ohneAuftraggeber¤ Fokus:Vollständigkeit,Konfiguration,Interoperabilität,Performanzetc.

o Akzeptanztest (Abnahmetest)¤ BeimAuftraggeber¤ Fokus:Zeigen,dassdiegestelltenAnf.umgesetztsind.

118


o Regressionstests¤ …dienenderÜberprüfungbereitserreichterTestergebnissenacheiner

Änderung.¤ Testfälleund–ergebnisse werdenprotokolliert

z.B.ineinerTestdatenbank.¤ nacheinerÄnderungwerdendieTestfällewiederdurchgespielt.¤ sinnvoll&hilfreich:automatischesTesten.¤ (Nur)Abweichungenwerdengemeldet.

119

Testgegenstand

o Abnahmetest(acceptance test)¤ einebesondereFormdesTests:¤ nicht:Fehlerfinden¤ sondern:zeigen,dassdasSystemdiegestelltenAnforderungenerfüllt,

d.h.inallengetestetenFällenfehlerfreiarbeitet.¤ InderrealenUmgebungdurchdenAuftraggeberoder¤ InFormvonAlpha- undBeta-TestsfüreinenanonymenMarkt

121

Wannhatmangenuggetestet?

o WennmitdeninderTestvorschriftfestgelegtenTestdatensätzenkeineFehlermehrgefundenwerden.¤ SinnvollesKriterium,wennderUmfangdesPrüflingseine

systematischeAuswahlvonTestfällenmitausreichenderÜberdeckungermöglicht.

¤ ÜblichesKriteriumbeiderAbnahme.

o WenndiePrüfkostenproentdecktemFehlereineimvorausfestgelegteGrenzeüberschreiten.¤ SinnvollesKriteriumfürdasBeendendesSystemtests.¤ SetztdieErfassungderPrüfkostenundderAnzahlgefundenerFehler

voraus.

Achtung: bei „schlechten“ Testfälle:kein Fehler wird gefunden das System ist ausreichend fehlerfrei

122

Wannhatmangenuggetestet?

o AbschätzungdesRestrisikos¤ DasRestfehlerrisikokann

n ausdenbekanntenDateninformellgeschätztwerden.n mitHilfestatistischerVerfahrenanalytischabgeschätztwerden.

124

VorgehenbeimTesten

o Wiewirdgetestet?o Waswirdgetestet?o Wannwirdgetestet?o Wannistmanfertigmittesten?o Wiewirddokumentiert?

125

Wiewirddokumentiert?1/2

Reihenfolge der Testfälle u.U. wichtig!

Testfälle werden zusammengefasstzu Testabschnitten für z.B. gleiche Art des Tests,gleiche Vorbedingungen, etc.

Testspezifikation§ IEEE829-1998Standardfor SoftwareTestDocumentation

Testfallspezifikation1. Id./Nr.2. Beschreibung3. Autor4. Vorbedingungen5. Eingaben6. ErwarteteResultate7. Ergebnis(pass/fail)

auch: gültige/ungültige EingabenArt des Tests (Funktion, Last, Zeit, …)

Exakt, z.B. „50“nicht „einen Geldbetrag“

126

Wiewirddokumentiert?2/2

o Manuelle Testfälle¤ sogenaubeschreiben,dasssieeindeutigreproduzierbarsind,¤ „abkürzen“erlaubt(z.B.„wieoben,jedochEingabe30,Ergebnis60“),

„Intuition“nicht(z.B.„weiteresinnvolleWerteauchtesten“),¤ Dokumentationz.B.inTabellen-Programm(OOo Calc,Excel).

o Automatische Testfälle¤ JUnit fürKomponenten/Integrationstest.¤ DokumentationmitJavaDoc.

o Zweck derDokumentation¤ Review(sinddieTestfälle„gut“).¤ VorgabenfürTester(manuell).

127

TestfallalsText– Teil1

128

TestfallalsText– Teil2

Aus: H. Sneed e.a.: Der Systemtest. 3. Aufl., Hanser, 2012.

129

TestfallalsTabelle

Aus: H. Sneed e.a.: Der Systemtest. 3. Aufl., Hanser, 2012.

130

IEEE829– TestSpecification – Teil1

131

IEEE829– TestSpecification – Teil2

141

Zusammenfassung

o TestenkannnurdieAnwesenheitvonFehlernaufzeigen,niemalsderenAbwesenheit.

o Esist(normalerweise)nichtmöglich,einProgrammerschöpfendzutesten:dasgiltfürBlackbox- wiefürWhitebox-Tests.

o Manunterscheidet¤ Blackbox,Whitebox- undGraybox-Tests.¤ ImzeitlichenVerlauf:

Unit-/Modul-/Komponenten-Tests,Integrationstests,Systemtest,Abnahmetest,

¤ BeiwiederholtemTestennachÄnderungen:Regressionstests.

o DieKombinationverschiedenerVerfahrenlieferteineguteÜberdeckung.

143

Kapitelübersicht


144

Software-Reviews

o TestenbenötigtausführbarenCode,d.h.keinTestvonAnforderungs-spezifikation,Entwurfsspezifikation,…möglich.

o EsbestehtBedarfanergänzendenMethodenzurEntdeckungundBeseitigungvonFehlern:=>Reviews

o ReviewskönnendasTestennichtersetzen,undumgekehrt!

145

Software-Reviews

Design Code TestAnford. WartungFehler-Entdeckung

Fehler-UrsprungDesign Code TestAnford. Wartung

Chaos

Ohne Reviews

Design Code TestAnford. WartungFehler-Entdeckung

Fehler-UrsprungDesign Code TestAnford. Wartung

Mit Reviews (ideal)

146

ÜbersichtüberReview-Techniken

o EmpirischeStudienbelegenInspektionenalsdiezuverlässigsteReview-Technik.¤ Inspektionenfinden50%mehrFehleralsWalkthroughs.¤ Inspektionenfindenbiszu6xmehrFehleralsAd-hocReviews.

Inspektion TeamReview

Walkthrough PairProgramming

PeerDesk-Checking

Ad-hoc

Sehrformal

Wenigerformal

147


o Ad-hoc Review¤ WennmaneinProblemnichtlösenkannbittetmaneinenMitarbeiter

spontanumHilfe¤ ErgebnishängtvollständigvonderErfahrungdeseinenMitarbeitersab

o PeerDesk-Checking¤ ÄhnlichAd-hocReview¤ DerMitarbeiter“führtdaszuüberprüfendeProduktaufdemPapier

aus”(meistensCode)

148


o Pair-Programming¤ ZweiEntwicklerteilensicheinenPC-Arbeitsplatzundarbeiten

gemeinsamaneinemStückCode.¤ EinederPraktikendeseXtreme Programming

o Walkthrough¤ DerAutoreinesDokumentspräsentiertesMitarbeitern,umein

allgemeinesVerständniszuerlangenunddieQualitätdesDokumentszuverbessern.

¤ KeinvorgegebenerProzessundkeineAnleitung,wieFehlerzufindensind.

¤ Risiko:DerAutorvergisstwährendderPräsentationleichtaufdiewesentlichenTeiledesDokumentszufokussieren.

149


o Team-Review¤ ÄhnlichderInspektion-Technikaberwenigerformal.¤ MehrereMitarbeiterüberprüfenindividuelleinProdukt.¤ DieErgebnissewerdenineinenTreffenmitdemAutorbesprochen.

150

Inspektion– Eigenschaften

Prozess

Lesetechniken

Rollen Dokumente

Welche Aktivitäten werden innerhalb des Inspektionsprozesses ausgeführt?

Welche Rollen sind in den

Inspektions-prozess

involviert?

Welche Dokumente werden in

einer Inspektion verwendet?

Welche Techniken können eingesetzt werden, um Fehler in einem Softwaredokument zu finden?

Inspektion

151

DerProzessunddieRollen

¨ Teilnehmereinladen,TerminvereinbarungvonallenInspektionsaktivitäten,Räumefestlegenà Organisator

¨ SuchenachundDokumentationvonProblemen(d.h.potentielleFehlern/Fragen/Verbesserungsvorschläge)à Inspektoren

¨ SammelnderFehler.Entscheiden,obeinBefundeintatsächlicherFehlerist.SuchenachweiterenFehlern.EntscheidenüberRe-Inspektion.àModerator//Autor/Inspektoren

¨ KorrekturderFehlerà Autor

Planung

Vorbereitung

Meeting

Korrektur

Kick-off

Follow-up

152

Inspektion- Dokumente

¨ Organisationsliste¤ ListeallergeplantenInspektionsaktivitäten(innerhalbeines

Projektsoderprojektübergreifend).¨ Problemliste

¤ DokumentationderBefunde(potentielleFehler/Fragen/Verbesserungsvorschläge)sowiedesAufwandsfürdieFehlersuche.

¨ Fehlerliste¤ DokumentationdertatsächlichenFehler,

sowiedesAufwandesfürdasMeeting.

¨ Korrekturliste¤ DokumentationderFehlerkorrektur(oftinFehlerliste

integriert).

Zu inspizierendesDokument

153

BedeutungderDokumente

¨ ErgebnisseeinerInspektion¤ VerbessertesSoftwaredokument¤ DokumentierteInformationzurCharakterisierung

n desinspiziertenDokumentesn desInspektionsprozessesn desSoftware-Entwicklungsprozesses

¨ VerwendungderErgebnisse¤ HilfefürdenAutorbeiderÜberarbeitungseines

Dokumentes¤ Charakterisierung/Beurteilung/Vorhersage/

VerbesserungdesInspektions- undSoftwareentwicklungsprozessesundnichtderdaranbeteiligtenPersonen!

154

AktivitätenderVorbereitungsphase

o DokumentwirdvondenInspektorennachBefundendurchsucht(Individulaktivität).

o Fehlerwerdendokumentiert.o Ziel:möglichstvieleschwereFehlerfinden.

155

Inspektion– Lesetechniken1/2

¨ AnwendunginderVorbereitungsphase(Individualaktivität)¨ HäufigesProblem

¤ EsgibtoftkeinekonkreteAnleitungfürInspektoren…n wasineinemSoftwaredokumentzuüberprüfenist.n wieeinSoftwaredokumentnachFehlernzudurchsuchenist.

¤ Motto:JederInspektorüberprüftalles.

à IneffizienteInspektion(#gefundeneFehler/Zeit)

156

Lesetechniken2/2

o Ad-hoc¤ KeineweitereUnterstützungfürInspektor.

o Checklisten:¤ DerInspektorbekommteineChecklistemitFragen,dieerbeimLesen

beantwortensoll.

o PerspektivenbasiertesLesen/SzenariobasiertesLesen:¤ DerInspektorfolgteinemLeseszenario.Diesesgibtbestimmte

Aktivitätenvor,diewährendderFehlersuchedurchzuführensindundfokussiertdenInspektoraufbestimmteAspekte.

157

Auszug aus einer Checkliste für Anforderungsdokumente

No. Frage

Fragen das gesamte Dokument betreffend

1 Existiert zu jedem Use Case im Use Case Diagramm genau ein formell beschriebener

Use Case und umgekehrt?

2 Ist das gewünschte System durch die Gesamtheit der Use Cases vollständig

beschrieben?

Checklisten

162

PerspektivenbasiertesLesen(PBR)

o LeseszenariengebenkonkreteAnleitungbeiderFehlersuche.o InspektorennehmenverschiedeneBlickwinkel(Perspektiven)

ein,diedieAufmerksamkeitaufverschiedeneAspektefokussierenà wenigerÜberlappung.

o DerEinflussderErfahrungvonInspektorenaufdieEffektivitätderInspektionwirdgeringer.

o WährendderInspektionwirdaktivmitdemDokumentgearbeitetà Verständniserhöht,Ergebnissekontrollierbar.

163

Leseszenarien

o JederDokumentnutzerhatQualitätsanforderungenandasDokument.DiesehängenvonderRolledesDokumentennutzersimEntwicklungsprozessab.

System-Tester

Kunde

Dokument

Entwickler

164

Beispiel-SzenariofürPerspektivenbasiertesLesen

o Youshouldreadthedocumentfromtheperspectiveofamoduletester.Indoingso,takethecodedocumentandextractacontrolflowgraph:Aggregatesuitablesequencesofcode,e.g.,asequenceofstatements.Makesurethatallbranchescanbeidentifiedinyourcontrolflowgraph.Forbuildingthecontrolflowgraphusethesymbolsontheform“symbolsfortestscenarios”.Documentyourcontrolflowgraphontheform“ResultsModuleTestScenario”.

o Usethecontrolflowgraphtoderivetestcases:Foreachbranchofthecontrolflowgraphandeachcalculation,developatestorasetofteststhatallowyoutoensuretheinternalcorrectnessofthecodemodule.Documentyourtestcasesontheform“ResultsModuleTestScenario”.

o Whileperformingtheactivities,askyourselfthe followingquestions:¤ 1.Doyouhavealltheinformationthatisnecessarytoidentifyatestcase

(e.g.,areallconstantvalues and interfaces defined)?¤ 2.Arealldatavaluesusedinacorrectway?(Quelle :WalterTichy,KIT)

166

AbdeckungundÜberlappung

Dokumentmit Fehlern

hohe Überlappunggeringe Abdeckung

geringe Überlappunghohe Abdeckung

z.B. alle Inspektoren

gleiche Checkliste

z.B. gut gewählte Szenarien

170

Zusammenfassung:TestenversusInspektionen

o TestbenötigtablauffähigenCode/InspektionenkönnenauchaufDokumentendurchgeführtwerden.

o Testenisterstspätmöglich/InspektionenkönnenbereitsinderAnforderungsphasedurchgeführtwerden.

o TestenentdecktFehlverhalten/InspektionenentdeckendieFehlerselbst.

o Testen:IsolationdesFehlerskostetzusätzlichenAufwand.o InspektionenförderndenWissenstransferzwischen

Mitarbeitern.

software-qualitÄtssicherung kapitel 6 und...

Documents