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
1. Einführung/Definition2. Begriffe3. DynamischeVerfahren– Testen4. StatischeVerfahren
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.
IEEE610-1990StandardGlossaryofSoftwareEngineeringTerminology
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).
IEEE610-1990StandardGlossaryofSoftwareEngineeringTerminology
o Asetoftestinputs,executionconditions,andexpectedresultsdevelopedforaparticularobjective,suchastoexerciseaparticularprogrampathortoverifycompliancewithaspecificrequirement.
IEEE610-1990StandardGlossaryofSoftwareEngineeringTerminology
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.
IEEE610-1990StandardGlossaryofSoftwareEngineeringTerminology
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
1. Einführung/Definition2. Begriffe3. DynamischeVerfahren- Testen
§ Teststrategien§ VorgehenbeimTesten§ Testautomatisierung
4. StatischeVerfahren
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
1. Einführung/Definition2. Begriffe3. DynamischeVerfahren- Testen
§ Teststrategien§ Blackbox-Test§ Glassbox-Test§ Graybox-Test
§ VorgehenbeimTesten§ Testautomatisierung
4. StatischeVerfahren
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
Blackboxtesten:Testfallbildung
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
5.11.20042.2 Funktionstest
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.11.20042.2 Funktionstest
AuswertungnachPunkten2/4
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
5.11.20042.2 Funktionstest
AuswertungnachPunkten3/4
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
5.11.20042.2 Funktionstest
AuswertungnachPunkten(Zusatzpunkte)4/4
15. TestmitmaximalenWerten.16. TestaufZahlbereichs-Überlaufbehandlung.17. TestmitunzulässigenEingabezeichenfolgen.
58
5.11.20042.2 Funktionstest
MyersErgebnisse+Folgerungen
o DurchschnittswerteerfahrenerProgrammierer:7-8o „DieseÜbungsolltezeigen,dassdasTestenaucheinessolchtrivialenProgrammskeineleichteAufgabeist.Undwenndaswahrist,betrachtenSiedieSchwierigkeit,einFlugleitsystemmit100.000Befehlen,einenCompileroderauchnureingängigesGehaltsabrechnungsprogrammzutesten.“ (1979)
o Heute:1-10MLoC
60
Blackboxtesten:Testfallbildung
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
1. Einführung/Definition2. Begriffe3. DynamischeVerfahren- Testen
§ Teststrategien§ Blackbox-Test§ Glassbox-Test§ Graybox-Test
§ VorgehenbeimTesten§ Testautomatisierung
4. StatischeVerfahren
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
1. Einführung/Definition2. Begriffe3. DynamischeVerfahren- Testen
§ Teststrategien§ Blackbox-Test§ Glassbox-Test§ Graybox-Test
§ VorgehenbeimTesten§ Nicht-funktionaleTests
4. StatischeVerfahren
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?
KorrekteSoll-Ausgabe?
Eingaben
KorrekteSoll-Ausgabe?
Eingaben
99
IllustrationGraybox-Tests
Eingaben
KorrekteSoll-Ausgabe?
KorrekteSoll-Ausgabe?
Eingaben
KorrekteSoll-Ausgabe?
Eingaben
100
IllustrationGraybox-Tests
Eingaben
KorrekteSoll-Ausgabe?
KorrekteSoll-Ausgabe?
Eingaben
KorrekteSoll-Ausgabe?
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
1. Einführung/Definition2. Begriffe3. DynamischeVerfahren- Testen
§ Teststrategien§ Blackbox-Test§ Glassbox-Test§ Graybox-Test
§ Nicht-funktionaleTests§ VorgehenbeimTesten
4. StatischeVerfahren
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
1. Einführung/Definition2. Begriffe3. DynamischeVerfahren- Testen
§ Teststrategien§ Blackbox-Test§ Glassbox-Test§ Graybox-Test
§ Nicht-funktionaleTests§ VorgehenbeimTesten
4. StatischeVerfahren
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
Wannwirdgetestet?2/3
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
Wannwirdgetestet?3/3
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
1. Einführung/Definition2. Begriffe3. DynamischeVerfahren– Testen4. StatischeVerfahren
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
ÜbersichtüberReview-Techniken
o Ad-hoc Review¤ WennmaneinProblemnichtlösenkannbittetmaneinenMitarbeiter
spontanumHilfe¤ ErgebnishängtvollständigvonderErfahrungdeseinenMitarbeitersab
o PeerDesk-Checking¤ ÄhnlichAd-hocReview¤ DerMitarbeiter“führtdaszuüberprüfendeProduktaufdemPapier
aus”(meistensCode)
148
ÜbersichtüberReview-Techniken
o Pair-Programming¤ ZweiEntwicklerteilensicheinenPC-Arbeitsplatzundarbeiten
gemeinsamaneinemStückCode.¤ EinederPraktikendeseXtreme Programming
o Walkthrough¤ DerAutoreinesDokumentspräsentiertesMitarbeitern,umein
allgemeinesVerständniszuerlangenunddieQualitätdesDokumentszuverbessern.
¤ KeinvorgegebenerProzessundkeineAnleitung,wieFehlerzufindensind.
¤ Risiko:DerAutorvergisstwährendderPräsentationleichtaufdiewesentlichenTeiledesDokumentszufokussieren.
149
ÜbersichtüberReview-Techniken
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.