Systematisk testning af program til udregning af mellemskat

Transkript

1 Systematisk testning af program til udregning af mellemskat Indledning I denne opgave vil vi definere passende cases til systematisk black-box test af et program til beregning af mellemskat. Vi har valgt at følge metoden i Myers&Wiley, kapitel 4, hvilket vil sige, at vi baseret på programmets input conditions definerer ugyldige og gyldige ækvivalensklasser. Disse danner grundlag for valget af en mængde test cases. De restende cases vælges på baggrund af boundary analysis. Inspireret af extreme programming implementerede vi de resulterende test cases i JUnit før selve implementeringen af selve mellemskat-programmet fandt sted. Dernæst benyttede vi de valgte tests til fejlfinding i programmet. Vi vil senere i denne rapport redegøre for vore erfaringer med denne fremgangsmåde. Desuden foretager vi en analyse af den code coverage, der opnås med de valgte tests, og foretager således en vurdering af værdien af vores test cases fra et white-box synspunkt. Ækvivalensklassepartitionering (ÆKP) (1) Identificering af ækvivalensklasser Input conditions med tilhørende ækvivalensklasser i nedenstående tabel (figur 1) er udledt af mellemskat-algoritmens specifikation. Bemærk at de ugyldige klasser er klasser, hvor input resulterer i en fejltilstand, hvor algoritmen/programmet ikke kan beregne noget meningsfuldt (jf. Myers&Wiley), samt at ækvivalensklasserne er disjunkte og udtømmende i hver række. Tallene i parantes angiver nummerering af ækvivalensklasserne til senere brug ved valg af kandidatelementer.

2 input condition ugyldige gyldige ækvivalensklasser ækvivalensklasser a personlig indkomst PI < (1) PI ³ (2) b ægtefælles personlige SPI < (3) SPI ³ (4) indkomst c eget bundfradrag NCI og PI+NCI >198 (5) NCI og PI+NCI 198 (6) NCI > og PI+NCI >198 (7) NCI > og PI+NCI 198 (8) d ægtefælles bundfradrag SNCI og SPI+SNCI >198 (9) SNCI og SPI+SNCI 198 (1) SNCI > og SPI+SNCI >198 (11) SNCI > og SPI+SNCI 198 (12) e egen nettokapitalindkomst NCI> (13) NCI (14) f ægtefælles nettokapitalindkomst SNCI> (15) SNCI (16) g ægtefælle har ægtefælle (17) har ikke ægtefælle (18) Figur 1: Input conditions med tilhørende ækvivalensklasser. (2) Identificering af test cases udfra ækvivalensklasserne Følgende test cases i figur 2 er udledt som beskrevet i Myers&Wiley, kap. 4, side 47, dvs. at hvert kandidatelement er valgt således, at det dækker så mange ækvivalensklasser som muligt. En - som variabelværdi i et kandidatelement betyder, at denne variabel slet ikke findes, da ægtefælleobjektet er null". Test case navne begyndende med V angiver valid og med I angiver invalid. Ækvivalensklassenumre er angivet i parantes, når klasserne allerede er blevet dækket af et tidligere kandidatelement. test case navn kandidatelement dækker ækvivalensklasser forventet værdi (oracle) V1 (2, -1, T, 2, -1) 2, 4, 5, 9, 14, 16, V2 (15, -1, F, -, -) (2), 6, (14), 18 V3 (4, 1, T, 1, -1) (2), (4), 7, 1, 13, (16), (17) 624 V4 (15, 1, T, 2, 2) (2), (4), 8, 11, (13), (15), (17) V5 (2, 2, T, 15, 1) (2), (4), (7), 12, (13), (15), 984 (17) I1 (-1, 1, F, -, -) 1 I2 (1, 1, T, -2, 1) 3 Figur 2: Kandidatelementer til dækning af ækvivalensklasser.

3 Boundary Analysis Denne teknik går ud på at vælge flere test case kandidater i hver input ækvivalensklasse, således at klassens grænser berøres. Tilsvarende vælges input kandidater således at grænser i output-rummet berøres. Figur 3: Visualisering af ækvivalensklasserne for input condition (c) De fleste af vores input conditions opdeler inputrummet i to klasser udfra kun ét parameter, så i disse tilfælde testes på begge sider af grænsen mellem disse klasser. Input condition (c) og (d) opdeler derimod inputrummet i 4 klasser (se figur 3), og test af grænserne kræver derfor flere test cases. Følgende er en liste over de grænsetilfælde, vi vurderer som interessante mht. inputrummet: (1) PI+NCI = 198 (2) SPI+SNCI = 198 (3) NCI = (4) SNCI = (5) PI = (6) SPI =

4 Hvad angår outputrummet, betragter vi grænsetilfældet, hvor mellemskatsbeløbet er, som interessant. Dette forekommer, når skattegrundlaget er mindre end eller lig med bundfradragsgrænsen på 198., og da vi leder efter grænsetilfælde, er et skattegrundlag før bundfradrag på præcist 198. naturligvis det mest interessante, dvs. det syvende grænsetilfælde er: (7) Skattegrundlag før bundfradrag = bundfradrag Vi har valgt at implementere 24 boundary tests på baggrund af disse grænser. De resulterende boundary tests kan ses i figur 4. Når SNCI og SPI ikke er angivet, betyder dette, at der ikke er en ægtefælle. Når PI og NCI ikke er angivet eksplicit, betyder det, at de er sat til. Vi mener, at disse tests berører de ovennævnte grænser. test case navn B1.1 B1.2 B1.3 B1.4 B2.1 B2.2 B2.3 B2.4 B3.1 B3.2 B3.3 B3.4 B4.1 B4.2 B4.3 B4.4 B5.1 B5.2 B5.3 B5.4 B6.1 B6.2 B6.3 B6.4 kandidatelement pi= 198, nci = -1 pi= 1981, nci = -1 pi= 198, nci = pi= 1981, nci = pi= -1, nci = -1 pi=, nci = -1 pi= -1, nci = pi=, nci = pi= -1, nci = 198 pi=, nci = 198 pi= -1, nci = 1981 pi=, nci = 1981 spi= 198, snci = -1 spi= 1981, snci = -1 spi= 198, snci = spi= 1981, snci = spi= -1, snci = -1 spi=, snci = -1 spi= -1, snci = spi=, snci = spi= -1, snci = 198 spi=, snci = 198 spi= -1, snci = 1981 spi=, snci = 1981 forventet værdi (oracle) Figur 4: Kandidatelementer til boundary test.

5 Analyse af code coverage Formålet med denne analyse er at undersøge hvor høj en grad af code coverage, der opnås, ved brug af blackbox-metoderne ÆKP og BA. Denne white-box teknik har til formål at henlede opmærksomheden på eventuelle kodeblokke, som ikke berøres af testene. Således kan man undgå at overse utestet kode og opnår samtidigt et mål for pålideligheden af de udførte tests. Figur 5 repræsenterer vores mellemskat-algoritme som et flow chart. De hvide kasser repræsenterer decisions. Kanten mærket S følges, hvis udtrykket evaluerer til sand, og kanten mærket F følges, hvis udtrykket evaluerer til falsk. En lille kasse midt på en kant angiver, at statements bliver udført. Figur 5: Flow-chart diagram over mellemskatprogrammet. For at få overblik over, hvilke execution paths, vores algoritme gennemgår under de enkelte tests, har vi modificeret koden, således at information udskrives i hver programblok i form af nummeret svarende til placeringen af koden i flow chart diagrammet. Vi har desuden tilføjet else-blokke med tilsvarende udskrift de steder, hvor else-blokkene ikke i forvejen var implementeret. På denne måde kan vi præcis følge med i, hvilken execution path, der følges, når en bestemt test køres. Resultatet er angivet i følgende tabel (figur 6).

6 Test Case Execution Path testcasevalid1() testcasevalid2() testcasevalid3() testcasevalid4() testcasevalid4() testcasevalid5() testcaseinvalid1() 1- testcaseinvalid2() testcaseb1() testcaseb2() testcaseb3() 1-1- testcaseb4() testcaseb5() testcaseb6() Figur 6: Execution paths for hver enkelt test case. (1) Statement Coverage For at opnå statement coverage skal følgende to punkter opfyldes: (1) Alle pile med små kasser på skal traverseres, dvs. alle statements i vores program, der ikke er if-statements, skal udføres som følge af en af vores testkandidater. (2) Alle store kasser skal besøges, dvs. alle if-statements skal udføres. Da samtlige store kasser har mindst én udgående pil med en lille kasse, følger dette af punkt (1). En gennemgang af ovenstående liste af execution paths viser, at begge punkter er opfyldt, og vi kan dermed konkludere, at vores tests medfører statement coverage.

7 (2) Andre typer code coverage For at opnå decision-coverage skal alle kanter i flow-diagrammet traverseres. En gennemgang af execution paths i listen ovenfor bekræfter, at dette er tilfældet, og vores test cases medfører derfor decision coverage. Det bemærkes, at da der hverken er exception-handlers, entry points eller andre former for implicitte branches i vores metode, følger statement-coverage af decision-coverage. I vores tilfælde følger condition-coverage, decision-condition-coverage og multiplecondition-coverage ligeledes af decision-coverage, eftersom alle branches kun består af én condition. Konklusion på analyse På baggrund af vores graf, ovenstående argumentation og nedenstående udskrift konkluderer vi, at vores tests opfylder kravene til alle de nævnte typer af coverage, og at testene således er så udtømmende, som de kan blive, fra et white-box synspunkt. Reflektion på arbejdsproces Vores tests var succesfulde, idet to fejl i koden blev opdaget på baggrund af de på forhånd planlagte tests. Det skal dog bemærkes, at den ene af disse fejl viste sig at befinde sig i test koden. Der er formentlig altid en risiko for fejl i testkode, men der kan næppe herske nogen tvivl om, at vores manglende erfaring med JUnit forøgede risikoen betydeligt, foruden at gøre implementationen af vores test cases langsommelig. Ved fremtidigt arbejde med JUnit må det forventes, at hastigheden så vel som korrektheden af testkoden er større, end tilfældet var under løsningen af denne opgave. I fremtidige projekter, som involverer programmering i Java, vil vi alvorligt overveje at benytte JUnit. Den XP-inspirerede arbejdsproces var desuden succesfuld i det henseende, at gruppemedlemmmet, som udviklede programmet, følte sig hjulpet af det foregående arbejde med at skrive test cases. Han oplevede, at dette gav større indsigt i problemområdet og afslørede nogle af faldgruberne i programmeringen. En overraskelse under arbejdet viste sig at være nytten af tegningen af et flow-chart. Formålet med chartet var udelukkende at tjene som værktøj ved bestemmelsen af graden af code coverage, men faktisk afslørede det første udkast, at der eksisterede en fejl i vores kode, som ikke blev fanget af de oprindelige tests. Forglemmelsen skyldtes en ubevist antagelse om, at udregningen af skat for henholdsvis skattebetaleren og ægtefællen blev beregnet af den samme kode. Dette viste sig ikke at være tilfældet, og derfor blev fejlen ikke fanget af testene. Denne hændelse illustrerer hvor vigtigt, det er, at være bevidst om de antagelser, man gør sig om koden, under valget af black-box tests. Det kan naturligvis ikke undgåes at gøre visse antagelser, idet koden er ukendt eller slet ikke skrevet. En total

8 mangel på antagelser dermed vil således nødvendiggøre fuldstændig udtømmende test, hvilket som bekendt er uoverkommeligt i langt de fleste sammenhænge. Der er ingen tvivl om, at de systematiske test har været nyttige - både til at finde fejl og til at målrette udviklingen af selve programmet. Alligevel var gruppemedlemmernes tillid til kodens korrekthed efter den langvarige indsats overraskende lav. De brugte metoder er overvejende heuristiske og langt fra ufejlbarlige, og betydningen af erfaring med testskrivning samt "næse for at finde fejl" er blevet mere tydelig for os. Vi har oplevet testprocessen som ekstremt tidskrævende - især den overskuelige størrelse af programmeringsopgaven taget i betragtning. Dette gør fordelene ved kodeinspektion endnu mere åbenlyse, og det er vores opfattelse, at vi formentlig kunne have fanget de samme fejl ved inspektion af koden som med test suiten, men med et langt mindre tidsforbrug. Ikke dermed sagt at test er overflødige, men det er med opgaven ganske godt blevet illustreret for os hvor høje omkostningerne ved test er, og at der i praksis må ske et tradeoff, evt. ved at erstatte meget grundige tests med mere overfladiske tests kombineret med brug af kodeinspektion.