Kurt Nørmark ©
Department of Computer Science, Aalborg University, Denmark


September 2001

Abstract Previous lecture Next lecture Index References Contents

I denne lektion er emnet programtest og programdokumentation. Begge emner repræsenterer meget vigtige områder i praktisk softwareudvikling. I delafsnittet om test lægger vi os rimeligt tæt op ad fremstillingen i Pressman's bog om software engineering. I delafsnittet om dokumentation fremstiller vi kortfattet værktøjet javadoc. Derefter diskuterer vi intern program dokumentation med såkaldt 'literate programming' som konkret eksempel. Begge delafsnit indledes på det generelle niveau og de afrundes med nogle praktiske råd rettet mod en objekt-orienteret programmeringssituation

The concept test af program: Test af et program er en aktivitet, som har til formål at afsløre evt. defekter i programmet i forhold til programspecifikationen eller i forhold til intentionen bag programmet

Programtest er en aktivitet i udviklingsprocessen, der har til formål at afsløre evt. defekter i et program. Defekterne er ideelt set i forhold til en præcis programspecifikation, eller i fravær af en sådan, i forhold til intentionen bag programmet

Reference Fejl, defekter og undtagelser

Programtest er placeret mellem programkonstruktion og debugging Programkonstruktion er fasen i forlængelse af programdesign, hvor alle detaljer i programmet udarbejdes Debugging er fasen hvor man finder årsagen til fejl, som er afsløret i forbindelse med programtest I praktiske softwareudviklingsprojekter er programtest en særdeles vigtig og tidkrævende aktivitet

Testaktiviteter kan påpege evt. defekter i et program - aldrig garantere at programmet er fejlfrit

Testabilitet Slide Note Contents Index References

Testabilitet er oversættelsen af den engelske term 'testability', som refererer til 'det at kunne teste et program'

Testabilitet refererer til omkostningerne som er forbundet med afsløringer af fejl og defekter i et program

To nøgleaspekter af testabilitet Kontrollerbarhed Muligheden for at styre program input og programtilstand forud for en testudførelse Uden kontrollerbarhed kan man ikke være sikker på hvad der forårsager bestemte resultater af et program Observerbarhed Muligheden for at tilgå resultatet af en testudførelse Uden observerbarhed kan man ikke vurdere på resultatet af en test

Testabilitet bør være en vigtig designfaktor

Reference Artikel om testabilitet: Robert V. Binder, 'Design for testability', Communication of the ACM, vol 37 no 2, September 1994

Testenheder Slide Note Contents Index References

Det er vigtigt at være sig bevidst, hvilke enheder vi tester. Når vi interesserer os for objekt-orienteret programmering er der flere muligheder.

Hvad er den mindste enhed som testes?

Enkeltkommandoer eller udtryk Procedurer, funktioner, metoder Klasser Pakker

Testutopi Slide Note Contents Index References

Vi vil her se på det umulige i at kunne gennemføre en totaltest af et program, som sikrer at der ikke er fejl

Ideelt set skal alle mulige 'stier gennem et program' testes hver for sig

The concept totaltest: En totaltest er en kombinatorisk komplet test af alle mulige stier gennem et program

En totaltest indebærer, at alle mulige stier gennem et program testes

Totaltest: Indebærer udførelse af alle mulige kombinationer af programmets primitive kommandoer relativt til programmets kontrolstrukturer I selv ganske små programmer er antallet af mulige stier gennem et program så stort, at en totaltest ikke lader sig gennemføre i praksis I mange programmer er der ikke nogen fast øvre grænse på antallet af mulige stier gennem programmet På grund af løkker uden fast øvre grænse

Det bedste man kan håbe på i praksis er test af en udvalgt lille delmængde af stierne gennem et program, som med størst mulig sandsynlighed repræsenterer de defekter, der kan opstå i programmet

Programbevis Slide Note Contents Index References

Et programbevis er et matematisk ræsonnement som overbeviser os om korrektheden af et program. Dette står i modsætning til en test, som er en empirisk sandsynliggørelse af, at der ikke er fejl i programmet. Vi ser, at der er tale om to vidt forskellige aktiviteter

Et programbevis er et alternativ til en totaltest af et program

Programbeviser: Matematisk bevis for at 'programmets postbetingelse' er opfyldt efter programudførelsen såfremt: programmets prebetingelse holder før programudførelsen programmet terminerer Forudsætter at programmet er specificeret, således at programmet kan bevises relativt til specifikationen Specifikation med logiske udtryk (assertions) er det sædvanlige grundlag for programbeviser I praksis bliver man nødt til også at kalkulere med fejl i specifikationen og fejl i programbeviset Den form for bevis, vi diskuterer her, kaldes partiel korrekthed. Årsagen er at vi forudsætter at programmet terminerer (kører til ende). Hvis vi ikke forudsætter terminering taler vi om en endnu stærkere form for korrekthed, nemlig total korrekthed

Et programbevis er så kompliceret at gennemføre, at det nødvendigvis skal automatiseres for at vi kan have tiltro til resultatet af beviset ('korrekt' eller 'ukorrekt') Programbeviser af 'virkelige programmer' er stadigvæk på kanten af det praktisk gennemførbare

I en whitebox test udnytter vi viden om de interne kontrolstrukturer af den enhed, der skal testes I en white box test sikres at alle kommandoer i en enhed udføres mindst én gang

The concept programenhed: En programenhed er i denne lektion en fællesbetegnelse for et programfragment (procedure, metode, klasse, modul, program) som er en test kandidat

Betegnelsen 'programenhed' benyttes i denne lektion som en fællesbetegnelse for f.eks. procedurerer og klasser, som vi skal teste

Mere detaljerede krav til white box test: Alle uafhængige stier i enheden skal udføres mindst én gang Alle konsekvenser af kombinationer af boolske udtryk, der styrer forgreninger, skal udføres Løkker skal udføres systematisk i randtilfældene

Begrebet 'uafhængige stier' beskrives på efterfølgende slides

Reference Software Engineering lærebog: Roger S. Pressman, Software Engineering - a practioneer's approach, McGraw-Hill, 1992

Test af uafhængige stier Slide Note Contents Index References

Som det fremgår af de forrige sider, er begrebet 'uafhængig sti' central for basal white box test. Vi ser nærmere på begrebet her

The concept sti: En sti gennem en programenhed er en sekvens af primitive kommandoer og betingelser, som gennemføres i en programudførelse. Stien starter ved indgang til enheden og slutter ved udgangen af programenheden		Intuitivt er en sti gennem en programenhed en bestemt rækkefølge af primtive kommandoer og primtive betingelser, som udføres fra start til slut af programenheden
The concept uafhængig sti: En uafhængig sti i en programenhed er en sti som tilføjer mindst én ny kommando eller betingelse relativt til de hidtil identificerede uafhængige stier i programenheden		En uafhængig sti gennem en programenhed er en sti (i ovennævnte betydning) som tilføjer mindst én ny primitiv kommando eller betingelse i forhold til de andre uafhængige stier

Ovennævnte definitioner er relativt upræcises, omend intuitionen burde være klar nok. Når vi indfører kontrol flow grafer kan vi formulere en noget mere præcis definition af en uafhængig sti

En programenhed giver anledning til en flow graph Givet en flow graph kan man ved hjælp af simpel grafteori beregne antallet af uafhængige stier, som skal testes

Fra programenhed til flow graph (1) Slide Note Contents Index References

Program: Et simpelt, stilistisk program med en løkke og to forgreninger i løkken. Programmet skal bruges til at illustrerer antallet af uafhængige stier med henblik på whitebox test af programmet

Procedure P; begin while A do begin X; if B then if C then Y else Z else begin V; W end end end

Figure. Et flow chart (rutediagram) som modsvarer ovenstående program

Fra programenhed til flow graph (2) Slide Note Contents Index References

Figure. Fire uafhængige stier i hosstående flow graph: A, r A, X, B, C, Y, p, q, A, r A, X, B, C, Z, p, q, A, r A, X, B, V, W, q, A, r

Et rutediagram (en flow chart) er en grafisk illustration af primitive kommandoer og kontrolstrukturer fra et programmeringssprog. En flow graph er en abstraktion over et rutediagram, som sætter fokus på de forskellige kontrolveje. Én eller flere kommandoer i sekvens slås sammen med det efterfølgende forgreningspunkt. Endvidere introduceres der knuder for de punkter, hvor kontrollen mødes efter en forgrening. Således repræsenterer kanterne i grafen de forskellige veje kontrollen kan forløbe. Knuderne repræsenterer forgrenings og samlingspunkter

I term af en flow graf skal en uafhængig sti inkludere en kant som ikke er indeholdt i hidtidigt fundne uafhængige stier

Udledning af testtilfælde til white box test Slide Note Contents Index References

Vi opsummerer her praktisk hvordan man finder 'testtilfælde' til en white box test

The concept testtilfælde: Et testtilfælde repræsenterer bestemte input til en programenhed samt evt. det ønskede resultat. Testtilfældet skal sikre et bestemt gennemløb af enheden, og det skal tillade os at vurdere om resultatet af enhedens udførsel er korrekt

Et testtilfælde (test case) betegner de input og det forventede resultat af en programenhed, som vi tester. Testtilfældet gives til programenheden som udføres, og resultatet af udførelsen sammenlignes med det forventede resultat

Antallet af testtilfælde, kaldet den cyklomatiske kompleksitet , svarer til antallet af regioner i flow grafen Grafteoretisk kan dette vises at være det samme som antallet af kanter minus antallet af knuder plus 2, eller antallet af 'prædikatknuder' (knuder hvor der foretages et valg mellem to muligheder) plus 1

Hvordan man finder testfældene for whitebox test: Tegn flowgrafen ud fra den programenhed, der ønskes testet Bestem den cyklomatiske kompleksitet, svarende til antallet af 'tilstrækkelige' test tilfælde Fastlæg ud fra grafen mængden af lineært uafhængige stier gennem grafen Find - om muligt - for hver af de uafhængige stier testtilfælde, som sikrer at den pågældende sti udføres

Andre white box tests Slide Note Contents Index References

Inden vi forlader white box test vil vi nævne nogle andre og supplerende testtilfælde, som kan være fornuftigt at overveje

Som supplement til ovenstående kan man foreslå yderlige white box tests som på systematisk vis afprøver andre stier end den 'basis mængde af stier' vi studerende ovenfor

Andre white box tests Test af betingelser i logiske udtryk Test af stier som er defineret af 'data flow' Test af forskellige gennemløbsmønstre i løkker

Detaljerne findes i afsnit 18.4 i Software Engineering lærebogen

I en black box test gør vi os ingen antagelser om den indre opbygning af den enhed, der skal testes Programenheden testes udelukkende på 'passende valgte input'

Muligheder i en black box test: Primært at afsløre funktionalitetsfejl i enheden Opnår vi det rigtige resultat på givne input? Finde fejl omkring enhedens grænseflade til andre enheder Overføres data korrekt til og fra enheden? Sekundært at afsløre andre problemer, såsom effektivitet Kan der demonstreres ressource problemer (tid og plads)?

Det er praktisk og kombinatorisk umuligt at teste en enhed på alle mulige input

Exercise 6.1. Test af Kortbunke

Vi har i en opgave for nylig beskæftiget os med klassen Kortbunke. I nærværende opgave bedes I gennemføre en black box test af klassen Kortbunke. Jeg foreslår, at I foretager en test af min udgave af klassen Kortbunke fra sidste gang. Hvis I anstrenger jer kan I måske afsløre en fejl eller to... Nærmere beskrevet bedes I gøre følgende under løsningen af opgaven: Orienter jer i min løsning af opgaven (som er lidt mere omfattende end opgave formuleringen lægger op til). Fastlæg testtilfælde. Tænk på ækvivalensopdelingen af input til metoderne, samt test af randtilfælde. Gennemfør aftestningen ved at programmere en driver i main metoden af klassen Kortbunke. Overvej hvordan I vil observere og vurdere resultatet af aftestningen af de forskellige operationer.

Valg af input til black box test (1) Slide Note Contents Index References

Det kritiske element i en black box test er udvælgelse af gode og repræsentative input. Dette er emnet på denne side

Den egentlige udfordring i black box test er en kritisk udvælgelse af hvilke input en programenhed skal afprøves på

The concept ækvivalensopdelning: En ækvivalensopdelning af en inputtype splitter mængden af værdier i typen op i et lille antal klasser. Opdelningen skal foregå ud fra det kriterium at alle værdier i en klasse skal være 'lige gode' til at afsløre fejl i en programenhed

En ækvivalensopdeling deler en input type i et lille antal klasser. Det er filosofien at alle værdier i en klasse skal være lige gode til at afsløre evt. fejl i en programenhed, som input af den pågældende type. Derfor kan vi vælge at teste programenheden med repræsentanter for ækvivalensopdelingen frem for alle mulige værdier fra inputdomænet

Opdelning af input i ækvivalensklasser: Inputtypen er et interval [a .. b]: Vælg en repræsentant under a, én mellem a og b, og én over b Inputtypen er en mængde af værdier V: Vælg en repræsentant i V og én uden for V Inputtypen er en klasse af objekter: Udnyt viden om klassen til at foretage en ækvivalensopdelning af klassen Udvælg en objekt repræsentant for hver ækvivalensklasse

Valg af input til black box test (2) Slide Note Contents Index References

Ud over en form for ækvivalensopdelning kan man overveje andre kriterier for valg af input, hvorpå vi skal test programenheden

Fejl opstår ofte i randområder

Udvælgelse af grænsetilfælde i input: Inputtypen er et interval [a..b]: Udvælg a-1, a, a+1, b-1, b og b+1 Udvælgelse med henblik på test af grænseområder i outputdata Design input data som tilsvarende afprøver enheden på grænseområder i output data Afprøvning af datastrukturer i grænseområder Design input data som afprøver 'tomme' og 'fulde' datastrukturer

Eksempel på black box test Slide Note Contents Index References

Vi ser nu på praktiske eksempler på black box test af to procedurerer, som er programmeret i Pascal

Program: Proceduren Ombyt(var T: ArrayType; i,j: TabelInterval).

procedure Ombyt(var T: ArrayType; i,j: TabelInterval); (* Ombyt element i og j i T *) var temp: TabelElement; begin temp := T[i]; T[i] := T[j]; T[j] := temp end; (* Ombyt *)

Testtilfælde er kombinationerne af T er tom, T er ikke tom i < j, i = j, i > j Statisk typecheck og brug af intervaltyper overflødiggør test af randtilfælde uden for intervallerne

Program: Funktionen FindMaxIndex(var T: ArrayType; fra, til: TabelInterval): TabelInterval.

function FindMaxIndex(var T: ArrayType; fra, til: TabelInterval): TabelInterval; (* Find elementet med den største værdi i T[fra..til], og returner dets indeks *) (* PREBETINGELSE: 1 <= fra <= til <= max *) var i, MaxIndex: TabelInterval; MaxElement: TabelElement; begin MaxIndex := fra; MaxElement := T[fra]; for i := fra+1 to til do if T[i] > MaxElement then begin MaxElement := T[i]; MaxIndex := i end; FindMaxIndex := MaxIndex (* POSTBETINGELSE: For alle j: T[j].Fornavn <= T[MaxIndex].Fornavn *) end; (* FindMaxIndex *)

Testtilfælde er kombinationerne af T er tom, T har største element først, T har største element sidst, T har største element i midten, T indeholder ens værdier fra er T's nedre grænse, fra er T's øvre grænse, til er T's nedre grænse, til er T's øvre grænse, fra er lig med til, fra er én mindre end til, fra er én større end til, fra < til (pænt fordelt) Prebetingelsen overflødiggør nogle testtilfælde Som eksempel på et overflødigt testtilfælde, som følge af prebetingelsen af FindMaxIndex, kan vi nævne de tilfæde som indbefattr 'fra er én større end til'.

Program: Det samlede sorteringsprogram.

Hvordan strukturerer og planlægger vi test af et stort program?

Nærmere problemstillinger: Hvem tester? Programudviklerne eller en uafhængig testgruppe Hvilke testniveauer ønsker vi at identificere? Enhedstest, integrationstest, valideringstest, systemtest, ... Hvordan gennemføres den praktiske test? Hvordan 'skydes kanonen i stilling' til testaktiviteten Manuelt eller værktøjsunderstøttet

Enhedstest Slide Note Contents Index References

Enhedstest betegner den mest finkornede test, som vi foretager os

The concept enhedstest: En enhedstest betegner en relativ isoleret test af den mindste enhed, som vi vælger at afprøve

Enhedstest er betegnelsen for den mest finkornede test, som vi vælger at gennemføre. Enhedstest gennemføres så isoleret og afsondret fra andre enheder som muligt

Enhedstest er en god kandidat til whitebox test hvis man har ressourcer og værktøj til en fornuftig understøttelse

Testsstillads (test scaffolding): Etablering af hjælpeprogrammer og moduler, som tillader os at teste en given enhed E Stubbe som gør det ud for enheder, der anvendes af E En driver som udfører testtilfælde på E

Figure. Arrangement af en enhedstest. Testtilfældene indlæses i et driverprogram, som kalder eller anvender den enhed E, som vi tester. For at kunne afprøve enheden så isoleret som muligt anvender vi stubbe for andre enheder, som E er afhængig af. Alternativt kan vi overveje at benytte andre enheder, som vi allerede har testet

Integrationstest Slide Note Contents Index References

Integrationstest betegner den test, hvor vi sætter enhederne sammen til større og større dele. Der er mange måder at gøre dette på i testhenseende

The concept integrationstest: En integrationstest betegner en samlet afprøvning af en mængde af enheder, og i sidste instans af det komplette program

Vi anvender betegnelsen 'integrationstest' om afprøvningen af en mængde af enheder, som anvender hinanden. Integrationstesten vil ultimativt rette sig mod afprøvningen af det komplette program

Integrationstest udføres oftest som black box test

Kendetegn ved integrationstest: Graden af inkrementalitet Lav: Sæt alle moduler sammen og prøvekør det samlede program ('Big bang') Høj: Gradvis større enheder sættes sammen og afprøves Bevægelsesretning Top-down: Testen starter med hovedprogrammet og nærmer sig de primitive moduler (dybde eller bredde først) Bottom-up: Testen starter med primitive moduler og nærmer sig det samlede hovedprogram

Vi sammenligner top-down og bottom-up teststrategierne på næste slide

Sammenligning af top-down og bottom-up integrationstest Slide Note Contents Index References

Her ser vi på de to yderpunkter i det vi på forrige slide kaldte 'bevægelsesretningen'

Top-down integrationstest: Tidlig test af overordnet funktionalitet Eliminerer (måske) behovet for test drivere Matcher top-down udviklingsteknikker, såsom struktureret programmering Bottom-up integrationstest: Sen test af overordnet funktionalitet Eliminerer (måske) behovet for anvendelse af stubbe Matcher bottom-up udviklingsteknikker, såsom objekt-orienteret programmering

Som set i andre sammenhænge, vil man i praksis ofte overveje kombinerede top-down og bottom-up løsninger

Det er bedre at forebygge fejl end at lave fejl Code review er et middel til at fjerne fejl fra programmet inden testfasen

The concept Code review: Et 'Code review' er et formelt møde hvor en gruppe af kvalificerede personer (udviklere) - om mulig med forskellig baggrund - identificerer fejl i et program

Code review Formålet er at finde fejl - ikke at rette fejlene Giv udvikleren lejlighed til at 'læse programmet op' Derved finder udvikleren ofte selv fejl Formidling af den enkelte programmør's bidrag til hele gruppen Ikke en anklage mod den programmør, der har lavet en fejl Mindre en to timers møde - review af op til 200 liniers program Kan involvere checklister (beskrivelser af fejl som man skal være på udkig efter) som gradvist kan udvikle sig i et projekt En deltager, som spiller sekretær-rollen, noterer alle fejl i et 'Code review skema'

Reference Testing Object-oriented Software - Life Cycle Solutions, kapitel 9.: Imran Bashir og Amrit L. Goel, Springer Verlag, 2000

Information hiding formindsker objekt-orienterede programmers testabilitet Vanskeligere at observere skjulte egenskaber Klasser er naturlige testenheder Klasser udgør den fundamentale byggesten i et objekt-orienteret program Det er ikke tilstrækkeligt at gennemføre isoleret funktionalitets test (black box) Metode-interaktions test er også væsentlig En kombinatorisk komplet metode-interaktions test er urealistisk En bottom-up teststrategi er naturlig Objekt-orienteret program konstruktion foregår som regel 'bottom-up' Muliggør realistiske tests tidligt i udviklingsprocessen Polymorfi og dynamisk binding kan bidrage med et væld af 'implicitte stier' gennem et program Vanskeligt på et statisk grundlag at definere stier til white box test

Reference Testabilitet

Test af klasse 'skiver' Slide Note Contents Index References

Ideerne på denne side stammer fra bogen 'Testing Object-oriented Software - Life Cycle Solutions', som er referert andet steds på denne side.

Ved at identificere dele af en klasse - slices - kan man lave omfattende metodekombinations test på relativt afgrænsede dele af klassen

The concept Slice: En slice (skive) af en klasse udgøres af én instansvariabel og alle de metoder som tilgår variablen

En slice (eller på dansk skive) af en klasse tager udgangspunkt i en variabel. Med variablen følger alle de metoder, som direkte eller indirekte læser fra eller assigner til variablen.

Slice baseret klasse enhedstest: Identificer alle skiver af en klasse (én pr. instansvariabel). Test observatører, konstruktorer og mutatorer pr. skive

Ovenstående ide repræsenterer en kombination af white box og black box testing for metode interaktionstest. Der er ingen bidrag til black box test af de enkelte metoder White box aspektet udgøres af dannelsen af skiver (slices). Dette kræver at vi studerer klassen internt. Resten af testen er helt igennem efter black box ideen.

Reference Testing Object-oriented Software - Life Cycle Solutions: Imran Bashir og Amrit L. Goel, Springer Verlag, 2000

Detaljer om slice-baseret klasse enhedstest Slide Note Contents Index References

Vi ser her på nogle mere detaljerede anvisninger på en slice baseret klasse enhedstest

Test af en skive i klassen: Test hver observationsmetode: Test hver observationsmetode i skiven på alle mulige permutationer af skivens metoder Alternativt et tilfældigt udvalg Test hver konstruktor Efter konstruktoren kaldes alle skivens observationsmetoder Test hver mutationsmetode Kald alle permutationer af mutationsmetoder i skiven efterfulgt af alle skives observationsmetoder En observationsmetode er en funktion, der aflæser egenskaber et objekt. En report må ikke på nogen måde påvirke objektets tilstand. En mutationsmetode en en metode, som ændrer et objekts tilstand. I de fleste klasser er det de metoder der er til rest, når vi har set bort fra observationsmetoderne.

Klassen som testenhed: Praktiske problemer Slide Note Contents Index References

Vi vil her diskutere nogle praktiske aspekter af enhedstest af klasser

Hvordan kan man i praksis gennemføre en enhedstest på en klasse?

Nogle praktiske observationer: Man kan ofte bruge main metoden til at organisere test af en klasse Hvis testen bliver omfattende, er det bedre at lave en separate test driver klasse pr. klasse Dette kan give synligheds og observationsproblemer, idet vi ikke kan se private egenskaber fra en anden klasse

Test i forhold til kontraktideen (1) Slide Note Contents Index References

Vi har tidligere i kurset studeret kontraktbegrebet, pre- og postbetingelser og klasseinvarianter. Vi indså at kontrakter er værdifulde under design til fastlæggelse af ansvar mellem klasser i et objekt-orienteret program. Vi konstaterede imidlertid også, at ideerne omkring kontrakter påvirker mange andre faser i programudviklingsprocessen. Her sætter vi fokus på værdien af (og naturligvis også begrænsningerne ved) kontrakter i en testaktivitet

Design kontrakter og assertions hjælper også i forbindelse med programtest

Positive bidrag under test: Black box bidrag Specifikationen, som programmet testes op imod Specifikationen er en integreret del af programmet Automatisk vurdering af hvorvidt en testudførelse giver et korrekt resultat Observerbarhed Postbetingelsen og klasseinvarianten fortæller, om resultatet af en procedure er korrekt Afgrænsning af de input, der skal testes Bidrag fra ansvarsfordelingen Ingen gode grunde til at teste en procedure med input, som ikke opfylder prebetingelsen Afgrænsning af de metoder, som interagerer med hinanden Formindsker metode interaktionstests Ingen gode grunde til at at afprøve sekvenser af beskeder, som involverer falske prebetingelser Selv om ideen om kontrakter reducerer antallet af testtilfælde er der stadig store udfordringer i at vælge hensigtsmæssig test input til en black box test af et program med kontrakter

References Observerbarhed under testabilitet Om udbyttet af kontrakter i programudviklingsprocessen Kontraktbegrebet

Test i forhold til kontraktideen (2) Slide Note Contents Index References

Der er også en række aspekter af test, hvor der ikke er hjælp at hente fra kontraktideen. På denne side kaster vi lys på disse.

Kontrakter løser langt fra alle problmer omkring test

Områder hvor kontraktideen ikke bidrager positivt White box test Kontrollerbarhed Selve den systematiske afprøvning Den faktiske testudførelse af programmet på hensigtsmæssigt input

Reference Kontrollerbared under testabilitet

Selv om vi konsekvent anvender designkonstrakter er der alligevel rigelige udfordringer i forbindelse med gennemførelse af program test

Opsummering Slide Note Contents Index References

Vi afrunder med en synopsis over nogle praktiske råd om test af objekt-orienterede programmer

Gennemfør systematisk endhedstest af alle ikke-trivielle klasser Benyt black box klasse enhedstest med en til lejligheden fremstillet driver Overvej white box metode enhedstest af metoder med kritisk og kompliceret kontrol Overvej en systematisk metode interaktions test Benyt en bottom-up teststrategi Gennemfør intern code review i projektgruppen

Dokumentation af et program tjener flere væsensforskellige formål

Brugsdokumentation Beskrivelse af programmets virkemåde Retter sig mod slutbrugeren Ekstern moduldokumentation Beskrivelse af eksterne egenskaber af et programmodul Retter sig mod programmører af andre moduler Intern programdokumentation Beskrivelse af interne egenskaber af et programmodul Retter sig mod programmører af det aktuelle modul

I denne lektion samler interessen sig om ekstern moduldokumentation, sekundært om intern programdokumentation, og slet ikke om brugsdokumentation

Moduldokumentation Slide Note Contents Index References

Moduldokumentation er på helt naturlig måde dokumentation af klasser når vi taler objekt-orienteret programmering

I objekt-orienteret programmering udgøres moduldokumentation af en beskrivelse af klassernes klientgrænseflader

Hvilke aspekter af en klasse skal dokumenteres? En forklaring af klassens sammenhæng med andre klasses, og evt. overordnede forhold omkring klassen Klassenavn, superklasse og klasseinvariant Intuitiv og eksternt rettet forklaring af klassen Signaturen af metoder: navn, parametertyper, rækkefølgen af parametrene, typen af returværdien, exceptions, pre- og postbetingelser Intuitiv og eksternt rettet forklaring pr. metode

Dokumentation: Strukturering i tid og rum Slide Note Contents Index References

Vi ser her på hvornår i udviklingsprocessen vi skriver dokumentation, og hvordan denne struktureres og organiseres i forhold til programmet

Tid: Hvornår laves dokumentationen i programudviklingsprocessen? Dokumentationen skrives før programmet Dokumentationen skrives som en integreret del af programudviklingsprocessen Dokumentationen skrives efter programmet er færdigt Rum: Hvordan organiseres dokumentation i forhold til programstrukturen? Dokumentationen organiseres i separate dokumenter, løsrevet fra program og programstruktur Dokumentation og program er organiseret i samme struktur Dokumentationen bor i programmet Programmet bor i dokumentationen

Dokumentation i forhold til test Slide Note Contents Index References

Vi vil her kort diskutere forholdet mellem denne lektions to dele: test og dokumentation

Et veldokumenteret program indeholder færre fejl end et udokumenteret program Man kan overveje at konsolidere program testen ved at argumentere for dets kvalitet i særlig programdokumentation

Observationer En skriftligt formuleret programforståelse presser programmøren til en bedre forståelse, som given reduktion af alvorlige logiske fejl. God dokumentation hindrer misforståelser i gruppen af programmører

Javadoc er baseret på ideen om at udtrække moduldokumentation fra et eksisterende program

Karakteristik af javadoc: Dokumentationen bor i klassen Dokumentation udtrækkes fra særlige doc comments i klassen, som 'parses' til en hvis grad Doc comments er særligt mærkede kommentarer: /** ... */ Det er muligt at bruge HTML tags i dokumentationen med henblik på formatering Undlade at bruge tags (header tags) som interfererer med formateringen af de overordnede dele af et javadoc dokument Billeder kan inkluderes via HTML tag'et img Ikoner, som bruges af javadoc, skal findes i dokumentationskatalogets 'images directory' Understøtter særlige, javadoc specifikke tags Til beskrivelse af forfatter, version, parametre til metoder, returværdi af metoder, forældelse, oprindelsesversion, undtagelser, serialisering, og krydsreferencer

Javadoc materiale Slide Note Contents Index References

Vi giver her en række henvisninger til detaljeret materiale og dokumentation om javadoc

Javadoc understøttes af god online dokumentation: How to Write Doc Comments for Javadoc Stilistisk vejledning Javadoc tag konventioner og -oversigt Eksempel på klasse dokumenteret med javadoc Javadoc værktøjsdokumentation Javadoc home page

Et program tjener to formål: at instruere maskinen samt at fastholde forståelse og forklaring for mennesker

Aspekter af et literate program Et program struktureres på læserens præmisser, ikke compilerens Programmet opdeles i mindre fragmenter som forklares separat Der vælges en rækkefølge blandt fragmenterne som er optimal for formidlingen af problemløsningen bag programmet Et program opfattes som et stykke faglitteratur, som kan virke instruktivt og inspirerende for andre programmører

To program is to understand

Citatet stammer fra Kristen Nygaard, oprindelig ophavsmand til objekt-orienteret programmering i Simula

Det klassiske literate programming værktøj Slide Note Contents Index References

Literate programming er en forholdsvis generel ide, som kan understøttes på mange forskellige måder. Her ser vi på et klassisk værktøj, som har været benyttet til en sådan understøttelse. Værktøjet, eller rettere værktøjsfamilien, kaldes WEB efter det første sådanne, lavet af Donald Knuth

Der findes en gruppe programmeringsværktøj kaldet WEB, som understøtter literate programming

Figure. Organiseringen af værktøj i WEB systemer, der understøtter literate programming.

Aspekter af WEB-agtigt programmeringsværktøj Programmet bor i dokumentationen Programmet udtrækkes af 'tangle' værktøjet Dokumentationen, som formateres af 'weave', indeholder velforklarede programfragmenter, indholdsfortegnelse, krydsreferencer, og stikordsregistre Dokumentationen er primært beregnet på at blive læst fra papir, i formateret form

Reference Eksempel på literate WEB produceret program (postscript)

Intern struktur af et literate WEB dokument Slide Note Contents Index References

Internt udgør et WEB dokumentet et hierarkisk struktureret program samt en lineært struktureret dokumentation

Figure. Den interne struktur af et WEB dokument. De grå pile repræsenterer den lineære dokumentationsstruktur. Den lilla pile repræsenterer hierarkisk programstruktur. Herunder ses programtræet trukket ud af nettet, og sat sammen til en helhed

Figure. Programstrukturen som defineret ovenfor af de røde bokse og de lilla pile

Opsummering Slide Note Contents Index References

Alle bør lave eksternt rettet dokumentation af offentlige klasser's klientgrænseflader Ekstern klassedokumentation kan i Java skrives i samme fil som klassen, og og derefter udtrækkes af JavaDoc Ekstern klassedokumentation er en forudsætning for sikker og samtidig programudvikling i en projektgruppe Intern programdokumentation højner programkvaliteten, giver bedre fælles programforståelse i gruppen, og mindsker antallet af fejl

Collected references Contents Index

Fejl, defekter og undtagelser Artikel om testabilitet: Robert V. Binder, 'Design for testability', Communication of the ACM, vol 37 no 2, September 1994 Software Engineering lærebog: Roger S. Pressman, Software Engineering - a practioneer's approach, McGraw-Hill, 1992 Testing Object-oriented Software - Life Cycle Solutions, kapitel 9.: Imran Bashir og Amrit L. Goel, Springer Verlag, 2000 Testabilitet Testing Object-oriented Software - Life Cycle Solutions: Imran Bashir og Amrit L. Goel, Springer Verlag, 2000 Kontraktbegrebet Om udbyttet af kontrakter i programudviklingsprocessen Observerbarhed under testabilitet Kontrollerbared under testabilitet Eksempel på literate WEB produceret program (postscript)

Chapter 6: Test og Dokumentation
Course home     Author home     About producing this web     Previous lecture (top)     Next lecture (top)     Previous lecture (bund)     Next lecture (bund)     
Generated: March 31, 2008, 12:08:36