Pensumbeskrivelse for ISEB Softwaretest foundation Certificering (Grundlæggende certificering for softwaretestere) Version 1.0

Transkript

1 Dansk oversættelse af engelsk Foundation Syllabus V februar 1999 Pensum emne Beskrivelse Tid Testprincipper Test-terminologi Terminologilisten Dansk Testbegrebsliste anvendes. 5 Der findes ikke et generelt accepteret sæt testdefinitioner, som anvendes globalt af Software testere. BS udgør en kilde til testdefinitioner og er inkluderet i den danske testbegrebsliste, der er suppleret med almindeligt anvendte danske testfaglige begreber. Derfor er test en nødvendighed Definition af fejltagelse, fejl, afvigelse og pålidelighed; fejltagelser og hvordan de opstår; omkostninger ved fejltagelser; udtømmende test er umulig; test og risiko; test og kvalitet; test og kontraktmæssige krav; test og lovmæssige, regelbundne eller ufravigelige krav; hvor meget test er tilstrækkeligt 75 En fejltagelse er en menneskelig handling, der frembringer et ukorrekt resultat. En fejl er en manifestation af en fejltagelse i softwaren (også kaldet en bug). En opstået fejl i softwaren kan medføre en afvigelse, som er en fravigelse fra softwarens forventede leverance eller service. Pålidelighed er sandsynligheden for at softwaren ikke vil forårsage afvigelser i et system i løbet af en specificeret tidsperiode under specificerede omstændigheder. Fejltagelser opstår, fordi vi ikke er perfekte og selv om vi var det arbejder vi under krav og er underlagt begrænsninger, som for eksempel deadlines for levering. En enkelt afvigelse kan koste ingenting eller rigtig meget (f.eks. Venus-sonden). Software i sikkerhedskritiske systemer kan være årsag til dødsfald eller kvæstelser, hvis den svigter, så omkostningen ved afvigelser i et system af denne type kan være tab af menneskeliv. Udtømmende test ville i de fleste tilfælde kræve enorme ressourcer og er derfor generelt uigennemførlig. Omfanget af den gennemførte test afhænger af de risici der skal afværges. Der skal ligge en risikovurdering til grund for allokering af den tid, der afsættes til test og for valget af hvad, der skal testes og hvor vægten for test skal lægges. Test identificerer fejl, og rettelsen af disse hæver softwarens kvalitet ved at hæve softwarens potentielle pålidelighed. Test er en målestok for softwarens kvalitet. Vi måler i hvor høj grad vi har opnået kvalitet ved at teste relevante systemegenskaber som korrekthed, pålidelighed, brugervenlighed, vedligeholdelsesegnethed, genanvendelighed, testbarhed osv. Andre faktorer, der kan være medbestemmende for testen, kan være kontraktmæssige eller lovmæssige krav, normalt defineret i branchespecifikke standarder eller baseret på anerkendt best practice og bredt accepterede kvalitetsstandard. Det er vanskeligt at fastlægge, hvor meget test der er tilstrækkelig. Copyright DANSK IT, 2004.

2 Grundlæggende Testprocessen; vellykkede test afslører fejl; betydningen af testproces 45 testafslutningskriterier eller slutkriterier, dækningskriterier Den grundlæggende testproces omfatter testplanlægning, testspecifikation, testafvikling, testregistrering og testafslutning. Mere detaljeret beskrevet: Testplanlægning: Testplanen bør specificere, hvordan teststrategi og projektets testplan anvendes i forhold til softwaren under test. Planen bør omfatte en identifikation af samtlige undtagelser fra teststrategien og identifikation af al software som softwaren under test skal spille sammen med under testafviklingen, som f.eks. drivere og stubbe. Testspecifikation: Testcases bør designes ved hjælp af de testcase designteknikker, der blev valgt under testplanlægningen. Testafvikling: Hver testcase bør afvikles. Testregistrering: Testregistreringen for hver testcase bør indeholde klare identifikationer og versionsoplysninger om den testede software samt testspecifikationen. Det faktiske resultat skal registreres. Under henvisning til testregistreringen bør det være muligt at godtgøre, at samtlige specificerede testaktiviteter er blevet udført. Det faktiske resultat bør sammenholdes med det forventede resultat. Konstaterede uoverensstemmelser skal registreres som testhændelser og analyseres for at fastlægge årsagen og for at afgøre den tidligste testaktivitet, der skal gentages, f.eks. for at fjerne fejlen i testspecifikationen eller for at kunne afgøre om fejl i softwaren er blevet afhjulpet. Den testdækningsgrad, der er opnået, skal angives for de mål, der er listet som kriterier for testafvikling. Testafslutning: Testregistreringen skal sammenholdes med de allerede specificerede testafslutningskriterier. Hvis kriterierne ikke er blevet overholdt, skal den tidligste testaktivitet, som skal gentages for at opfylde afslutningskriterierne, identificeres, og testen skal genstartes fra dette punkt. Det kan være nødvendigt at gentage testspecifikationsarbejdet for at designe yderligere testcases for at overholde et givet mål for testdækning. Eftersom formålet med testen er at finde fejl, er en test vellykket, når den finder en fejl. Det er kontra-intuitivt, fordi fejl forsinker fremskridt: En vellykket test kan medføre forsinkelser. En vellykket test afslører en fejl, som hvis den var blevet opdaget senere ville have været mange gange dyrere at afhjælpe. Derfor er testen i det lange løb en fordel. Testafslutningskriterier anvendes for at afgøre, hvornår testen (uanset testfase) er fuldført. Kriterierne kan defineres baseret på omkostning, tid, fundne fejl eller testdækningsgrad. Testdækningsgrad Kriterier for testdækningsgrad defineres på basis af elementer, der er aktiveret gennem testsæt, herunder f.eks. forgreninger, brugerkrav, oftest gennemførte transaktioner osv Copyright DANSK IT, 2004.

3 Test for at finde fejl; forholdet mellem tester og udvikler; Psykologien i test uafhængighed Testaktiviteter udføres med det primære formål at finde fejl i softwaren snarere end for at bevise korrekthed. Test kan derfor opfattes som en destruktiv proces. Kravene til testerens tankegang er anderledes end til udviklerens. Der findes rigtige og forkerte måder at fremlægge fejl på over for ophavsmændene eller ledelsen (eksempler anføres). Det er vigtigt at udvikler og tester kommunikerer: F.eks. om ændringer i applikationen eller menustrukturer, der kan påvirke testarbejdet; eller hvor udvikleren mener, koden kan være fejlbehæftet; eller hvor det kan være vanskeligt at reproducere rapporterede fejl. Generelt anses objektiv, uafhængig test for at være mere effektiv. Hvis ophavsmanden tester, bringes bagvedliggende antagelser med ind i testarbejdet, for man ser jo ofte det, man gerne vil se. Der kan være følelser involveret og der kan være en personlig interesse i ikke at finde fejl. Niveauer for uafhængighed i testen kan således være: a) Testcases designes af de(n) person(er), som skriver den software, der skal testes; b) Testcases designes af en eller flere andre person(er); c) Testcases designes af en eller flere person(er) fra en anden afdeling; d) Testcases designes af en eller flere person(er) fra en anden organisation; e) Testcases vælges ikke af en person. Gentest og regressionstest Fejlrettelse og gentest; testens egnethed til gentagelse; regressionstest og automatisering; valg af testcases til regressionstest Når en fejl er opdaget og afhjulpet, bør softwaren testes igen, for at sikre at den oprindelige fejl virkelig er blevet rettet. Desuden bør det overvejes, om der skal testes for lignende eller beslægtede fejl. Test bør være egnet til gentagelse for at give mulighed for gentest / regressionstest. En regressionstest tester om ændringer har forårsaget uforudsete negative følger i den uændrede software (regressionsfejl) og sikrer, at det modificerede system stadig overholder kravene. Regressionstesten udføres altid, når softwaren eller dens miljø er blevet ændret. Testsæt til regressionstest køres mange gange og udvikler sig normalt langsomt. Derfor er regressionstest velegnet til automatisering. Er automatisering ikke mulig, eller er testsæt til regressionstest meget omfattende, kan det blive nødvendigt at trimme testsæt. Man kan udelade repetitiv test, nedbringe omfanget af test på allerede afhjulpne fejl, testcases kan kombineres, nogen test kan lægges ud til periodisk afvikling osv. En delmængde testsæt til regressionstest kan også anvendes til at teste akutte fejlrettelser. Forventede Identifikation af krævet adfærd resultater Forventet adfærd er ensbetydende med forventede resultater, men er ikke det samme som output. Er den forventede adfærd ikke blevet defineret, kan det ske, at et plausibelt, men fejlagtigt resultat tolkes som korrekt. Derfor skal den forventede adfærd defineres før testafviklingen. Orakel-postulatet går ud på at en tester rutinemæssigt kan identificere det korrekte resultat af en test. Oraklet kan f.eks. være det eksisterende system (for en benchmarkafprøvning), eller en specifikation eller en bestemt persons specialviden, men ikke selve koden Copyright DANSK IT, 2004.

4 Testomfang og begrænsede ressourcer; de vigtigste tests Prioritering af test først; prioriteringskriterier Der er aldrig tid nok til at udføre al ønsket test. Derfor skal der prioriteres. Test prioriteres på en sådan måde, at uanset hvornår testforløbet afbrydes, så er der blevet testet så godt som overhovedet muligt i den tid, der var til rådighed. Identificer de kriterier der danner grundlag for prioriteringen, f.eks.: alvor sandsynlighed synlighed for afvigelser prioritering af de krav, der skal testes kundens ønsker tilbøjelighed for ændring tilbøjelighed for fejl hvor kritisk området er for forretningen hvor kritisk området er i teknisk henseende kompleksitet Test igennem hele livscyklus Testmodeller Verificering, Validering og Test; V-model Definitioner af verificering, validering og test iflg. Dansk Testbegrebsliste. V-modellen for test viser, at den identificerer de baselines (både test- og udviklingsprodukter), der bør testes på hvert udviklingstrin (det vil sige, test igennem hele livscyklus). Testøkonomi Testdesign på et tidligt tidspunkt; hvordan forberedelse af test kan finde fejl i specifikationerne; omkostninger ved fejl versus omkostninger ved test. Omkostningerne ved fejl eskalerer efterhånden som produktet bevæger sig mod idriftsættelse. Opdages en fejl umiddelbart før produktet er klart til idriftsættelse, stiger prisen på arbejdet med at rette fejlen drastisk, fordi mere end et forudgående trin af design, kodning og test eventuelt skal gentages. Hvis fejlen viser sig når produktet er i drift, kan de potentielle omkostninger blive katastrofale. Hvis fejl i dokumentationen overses, kan udvikling baseret på denne dokumentation medføre mange afledte fejl, der mangedobler effekten af den oprindelige fejl. Testdesign på et tidligt tidspunkt kan forhindre denne mangedoblingseffekt. Analyse af specifikationerne under testforberedelsen bringer ofte fejl i specifikationerne frem i lyset. Omkostningerne ved test er som regel lavere end omkostninger forårsaget af alvorlige fejl (som f.eks. ringe produktkvalitet og/eller fejlrettelse), selv om kun få organisationer kan fremlægge tal der bekræfter dette Copyright DANSK IT, 2004.

5 Overordnet testplanlægning Fastlæggelse af testomfanget; risikoanalyse; testfaser; testopstarts- og testafslutningkriterier; krav til testmiljøet; testdatakilder; dokumentationskrav Nødvendige overvejelser i henhold til IEEE Test Plan Outline. 1. Testplan identifikator; 2. Introduktion; 3. Testgenstande; 4. Områder, der skal testes; 5. Områder, der ikke skal testes; 6. Fremgangsmåde; 7. Kriterier for hvorvidt afviklingen af et testområde kan godkendes eller har fejlet; 8. Kriterier for at afbryde og genoptage testen. 9. Test leverancer; 10. Testopgaver; 11. Krav til Testmiljø; 12. Ansvar; 13. Behov for bemanding og uddannelse; 14. Tidsplan;. Risici og beredskabsplan; 16. Godkendelser. Accepttest Brugeraccepttest, kontraktaccepttest, alfa- og betatest; Accepttest og brugertest. Disse testfaser kan være den eneste test, der udføres af, og er synlig for, kunden, når det drejer sig om en softwarepakke. Brugeraccepttest - Den sidste fase i valideringen. Kunden bør selv udføre testen eller være tæt involveret i den. Kunderne kan vælge at afvikle en hvilken som helst test de ønsker, normalt ud fra deres sædvanlige forretningsprocesser. Oftest sker det ved at indrette en kontormodel, hvor systemerne testes i et miljø, der ligger så tæt på realiteterne som muligt. I Danmark benyttes i praksis en V-model, hvor der skelnes mellem brugertest og accepttest, og brugeraccepttest betegner da den konkrete kombination af disse to testfaser: Accepttest: Den sidste fase i valideringen. Accepttesten er en demonstration af, at acceptkriterierne, som forinden bør være defineret i en kontrakt eller et aftalegrundlag, er indfriet. Typisk ser testen på tværs af system og forretningsgange på kundens/brugerens samlede oplevelse af en løsning. En godkendt accepttest er normalt en endelig godkendelse af en samlet leverance. Brugertest: En detaljeret test af, at et system lever op til brugernes forventninger og krav, som beskrevet i kravspecifikationen, samt test af at systemet fungerer i sammenhæng med brugernes forretningsgange, blanketter og anden brugerdokumentation. Kontraktaccepttest En demonstration af at acceptkriterierne, som vil være defineret i kontrakten, er opfyldt. Alfa- og betatest - Når softwaren virker stabil anvender brugere, der repræsenterer markedet, produktet på samme måde, som de ville gøre i den endelige version og videregiver deres kommentarer. Alfatest udføres på udviklerens lokation, betatest udføres på testerens lokation. Systemintegrationstest Test af integrationen af systemer og softwarepakker; test af grænsefladerne til eksterne organisationer (f.eks. PBS, EDI, Internet) Integration med andre (komplette) systemer. Identifikation af grænsefladerne til andre systemer og vurdering af risici i forbindelse med interaktion med disse. Inkrementel/ikke-inkrementel indfaldsvinkel til integration Copyright DANSK IT, 2004.

6 Ikke-funktionel systemtest Ikke-funktionelle krav; ikke-funktionelle testtyper: load, performance og stress; sikkerhed; brugervenlighed; lagring; volumen; installerbarhed; dokumentation; genoprettelse. Forklar at, ikke-funktionelle krav er lige så vigtige som funktionelle krav. Omtal kort hver af de anførte teknikker: Load, performance og stress, sikkerhed, brugervenlighed, lagring, volumen, installerbarhed, dokumentation og genoprettelse. Funktionel Funktionelle krav; kravbaseret test; forretningsprocesbaseret systemtest test Funktionelle krav iflg. IEEE-definitionen er krav, der specificerer en funktion, som et system eller en systemkomponent skal udføre. Kravbaseret test hvor brugerkravspecifikationer og systemkravspecifikationer (typisk anvendt i kontrakter) kan anvendes til at udlede testcases. Forretningsprocesbaseret test baseret på forventede brugerprofiler (f.eks. scenarier, use cases osv.) Komponentintegrationstest At samle komponenter til subsystemer; subsystemer til systemer; stubbe og drivere; big-bang, top-down, bottom-up, andre strategier Integrationstest afprøver grænseflader og interaktionen mellem komponenter/subsystemer. Stubbe og driveres rolle. Inkrementelle strategier inklusiv: Top-down, bottom-up og funktionel inkrementering. Ikke-inkrementel fremgangsmåde (big-bang). Komponenttest (Også kendt som enheds-, modul-, programtest); oversigt over BS Software component testing; komponenttest proces Komponenttesten afprøver individuelle softwarekomponenter. For uddybning se BS Vedligeholdelsestest Vedligeholdelsesproblemer; test af ændringer; risici ved ændringer og regressionstest Test af gammel kode med ringe/manglende specifikationer. Testomfanget med hensyn til ændret kode. En effektanalyse mht. følgefejl er vanskelig derfor større risiko ved gennemførelse af ændringer og vanskeligt at beslutte hvor meget regressionstest der skal udføres Copyright DANSK IT, 2004.

7 Dynamiske testteknikker Black- og Whitebox test Funktionel- eller black-box test; struktur-, white- eller glasbox test; trenden går fra white-box til black-box under livscyklus; teknikker og værktøjer Forklar terminologien: Black-box/funktionel og white-box/struktur/glas-box. Beskriv forskellen mellem black- og white-box teknikker. Forklar at, black-box er relevant hele livscyklus igennem, mens yderligere white-box generelt set er relevante for test af subsystemer (komponent, link), men bliver i stadig mindre grad anvendelige i forhold til system- og accepttest. System- og accepttestere fokuserer snarere på specifikationer og krav end på koden. Fremhæv brugen af systematiske testteknikker (og tilhørende målinger) for at skabe tillid. Forklar at, værktøjer øger produktivitet og kvalitet og især er nyttige til white-box test. Black-box testcase Black-box teknikker som specificeret i BCS standarden. 45 design teknikker List alle black-box teknikker i BS Beskriv og giv eksempel på brug af ækvivalensklasse og grænseværdianalyse samt en teknik mere. White-box testcase White-box teknikker som specificeret i BCS standarden. design teknikker Opstil alle white-box teknikker i BS på en liste. Beskriv og giv eksempel på instruktions- og forgrenings-/beslutningpunkttest iflg. BS Fejlgætning Brug af erfaring til at postulere fejl; brug af fejlgætning for at supplere andre testcase design teknikker Fejlgætning kan opdage visse fejl, som systematiske teknikker ikke opdager. Testcases udledes på baggrund af erfaring med, hvor fejltagelser tidligere er opstået, eller testeren kan have forståelse for, hvor fejltagelser sandsynligvis vil kunne opstå i fremtiden. Fejlgætning bør bruges som oprensningsmetode eller som supplement til systematiske teknikker, ikke som første teknikvalg Copyright DANSK IT, 2004.

8 Statisk test Reviews og Hvorfor, hvornår og hvad skal reviewes? Omkostninger og testprocessen fordele ved reviews Hvorfor reviews er kendt for at være omkostningseffektiv. Ethvert dokument kan reviewes. F.eks. kravspecifikationer, designspecifikationer, kode, testplaner, brugervejledninger osv. Reviews bør starte så tidligt som muligt. Omkostningerne løbende reviews koster ca. % af udviklingsbudgettet. Omkostninger ved reviews omfatter aktiviteter som selve reviewprocessen, analyse af metrikker og procesforbedring. Fordelene omfatter områder som forbedringer af udviklingsproduktivitet, reducerede udviklingstider, testomkostninger og tidsreduktion, reduktion af levetidsomkostninger, lavere fejlniveau osv. Typer af reviews Review typer; mål, udførte aktiviteter, roller og ansvar, produktleverancer, faldgruber Forklar ligheder/forskelle mellem walkthroughs, inspektioner, uformelle reviews og tekniske reviews, som hver især kan identificeres ud fra følgende egenskaber: Walkthroughs brugsmønstre, prøvekørsler, gruppe af kolleger under forfatterens ledelse. Inspektioner ledet af uddannet moderator (ikke forfatter), defineret roller, inkluderer metrikker, formel proces baseret på regler og checklister med start- og slutkriterier. Uformelle reviews udokumenteret, men nyttig, billig, meget udbredt. Tekniske reviews (betegnes også som kollega-reviews) dokumenteret, defineret fejlfindingsproces, omfatter kolleger og tekniske eksperter, ingen deltagelse fra ledelsen. Mål validering og verificering i forhold til specifikationer og standarder (og procesforbedringer). Opnå enighed. Aktiviteter planlægning, oversigtsmøde, forberedelse, reviewmøde og opfølgning (eller lignende). Roller og ansvarsfordeling moderatorer, forfattere, reviewansvarlige/inspektører og ledere (planlægningsaktiviteter) Leverancer produktændringer, ændringer i kildedokumenter og forbedringer (både review og udvikling). Faldgruber manglende uddannelse, manglende dokumentation, mangel på opbakning fra ledelsen (og mangel på succes med forbedring af processer) Copyright DANSK IT, 2004.

9 Statisk analyse Simpel statisk analyse; compiler-genererede informationer; dataflow-analyse; kontrolflow-grafer, kompleksitetsanalyse; Forklar at, statisk analyse ikke indebærer nogen dynamisk eksekvering og kan afsløre mulige fejl som f.eks. utilgængelig kode, ikke-definerede variable, mis-match i parameter typer, funktioner og procedurer der ikke bliver kaldt, mulige array overskridelser. Forklar at, enhver fejl, der er fundet af compilere, er fundet igennem statisk analyse. Compilere finder fejl i syntaksen. Mange compilere giver også information om variabel anvendelse, som er nyttig under vedligeholdelse. Forklar at, dataflow-analysen ser på anvendelse af data på stier igennem koden, idet der kigges efter mulige uregelmæssigheder, som f.eks. definitioner uden mellemliggende anvendelse og anvendelse af en variabel, efter at den er blevet slettet. Forklar anvendelsen med eksempler på produktionen af kontrolflow-grafer for et program. Introducer kompleksitetsmetrikker, inklusive cyklomatisk kompleksitet. Styring af test (Test management) Organisation Organisatoriske strukturer for test; sammensætning af team Forklar at, der kan være forskellige struktureringer for test i forskellige organisationer: Testafvikling kan være udviklerens ansvar eller kan være teamets ansvar (par-test). Det kan også være en person i teamet, som er tester, der kan være et dedikeret testteam (som ikke har med udvikling at gøre) eller der findes interne testkonsulenter, der rådgiver i forbindelse med projekter. Endelig kan der også findes en separat organisation, som udfører testarbejdet. Normalt er der brug for et multidisciplinært team med specialkundskaber. Der er brug for følgende rollefordeling: Testanalytiker til at forberede strategier og planer, eksperter i testautomatisering, database administrator eller designer, brugergrænseflade-eksperter, testmiljøstyring osv. Typiske symptomer på dårlig konfigurationsstyring; Konfigurationsstyring konfigurationsidentificering: konfigurationskontrol; statusrapportering; konfigurationsrevision Typiske symptomer på dårlig konfigurationsstyring beskrives, som f.eks. når det ikke er muligt at matche kilde- og objektkode, identificere hvilken version i en compiler der genererede objektkoden, identificere ændringerne i kildekoden, der er udført i en bestemt softwareversion, samt når samtidige ændringer er udført af forskellige udviklere i samme kildekode (og ændringer derved er gået tabt). Konfigurationsidentificering kræver at alle konfigurationsobjekter og deres versioner i testsystemet er kendte. Konfigurationskontrol betyder vedligeholdelse af delene i en konfiguration i et bibliotek og vedligeholdelse af en log over hvordan delene i konfigurationen er blevet ændret i løbet af tiden. Statusrapportering er den funktion, der opsamler og gør det muligt at følge op på problem-/fejlrapporter, ændringsønsker osv. Konfigurationsrevision er den funktion, der kontrollerer indholdet i biblioteker osv. med hensyn til f.eks. deres overensstemmelse med standarder Copyright DANSK IT, 2004.

10 Konfigurationsstyring kan være meget kompliceret i miljøer med blandede hardware- og softwareplatforme, men der findes stadig flere sofistikerede platformuafhængige værktøjer til konfigurationsstyring. Testestimering, Testestimering; Testopfølgning; Teststyring -opfølgning og -styring Testestimering forklar at, den indsats, der kræves for at udføre aktiviteterne i en overordnet testplan, skal være udarbejdet i forvejen og at der skal tages højde for at noget testarbejde skal gentages. Testopfølgning beskriv nyttige mål til registrering af fremdrift (f.eks. antal testgennemløb, test godkendt/fejlet, opståede og afhjulpne fejl, gentest osv.). Forklar, at den testansvarlige kan være tvunget til at indrapportere afvigelser fra projekt-/testplanerne som f.eks. mangel på tid, før testafslutningskriterierne er opfyldt. Teststyring forklar at, omfordeling af testressourcer kan være nødvendig, f.eks. ændringer i testtidsplanen, testmiljøet, antallet af testere osv. Hvad er en testhændelse ; testhændelser og testprocessen; Testhændelser rapportering af testhændelser; sporing og analyse En testhændelse er enhver signifikant, ikke planlagt begivenhed, der sker under testforløbet og som kræver efterfølgende undersøgelse og/eller rettelse. Hændelser skal registreres, når forventede og faktiske testresultater er forskellige fra hinanden. Testhændelser kan forekomme både i relation til dokumentation, i kode eller i et system under test. Testhændelser kan analyseres for at overvåge testprocessen og for at understøtte forbedringer af testprocessen. Testhændelser bør rapporteres, når en anden en ophavsmanden til et produkt under test udfører testen. Typisk vil informationen, der rapporteres om en hændelse, omfatte: forventede og faktiske resultater testmiljøet den testede softwares ID testerens/testernes navn(e) alvor omfang prioritet enhver anden information, der måtte være relevant for at genskabe og afhjælpe den potentielle fejl. Testhændelser bør kunne spores fra deres opståen igennem de forskellige trin helt ud til de er rettet og lukket. Teststandarder Standarder for kvalitetssikring; industrispecifikke standarder; teststandarder 5 Forklar at, standarder for kvalitetssikring blot specificerer at test skal afvikles, mens industrispecifikke normer specificerer niveauet for test, og test standarder specificerer måden, hvorpå test skal afvikles. Ideelt set bør teststandarder baseres på de to sidste (niveauet og måden). Eksempler på de forskellige standarder er ISO 9000, Railway Signalling standard, BS , BS Værktøjer til støtte for test (CAST) Typer af testværktøjer Kravtest; statisk analyse; testdesign; testdataforberedelse; karakterbaseret testafvikling; GUI testafvikling; test harness, drivere og simulatorer; performancetest; dynamisk analyse; debugging; sammenligning; teststyring; testdækningsmåling Copyright DANSK IT, 2004.

11 Værktøjer til kravtest yder automatiseret støtte til verificering og validering af kravmodeller, som f.eks. konsistenskontrol og animering. Værktøjer til statisk analyse giver information om softwarens kvalitet ved at undersøge koden i stedet for at køre testcases igennem koden. Værktøjer til statisk analyse måler normalt softwarens forskellige karakteristika på objektiv måde, fx cyklomatiske kompleksitetsmålinger og andre kvalitetsparametre. Værktøjer til testdesign genererer testcases ud fra en specifikation, der normalt opbevares i en database i et CASE værktøj eller genereres fra formelt specificerede krav, gemt i selve værktøjet. Nogle værktøjer genererer testcases på baggrund af en kodeanalyse. Værktøjer til testdataforberedelse gør det muligt for testdata at blive valgt fra bestående databaser eller blive oprettet, genereret, manipuleret og redigeret til brug for test. De mest sofistikerede værktøjer kan behandle mange forskellige fil- og databaseformater. Værktøjer til karakterbaserede testafvikling giver optage-/afspilningsfaciliteter for applikationer til karakterbaserede terminaler. Værktøjerne simulerer brugerindtastninger på terminalerne og optagelse af skærmbilleder til senere sammenligning. Testforløbene optages normalt i et programmerbart scriptsprog, testdata, testcases og forventede resultater kan fastholdes i separate test-databaser. Værktøjerne bruges ofte til at automatisere regressionstest. Værktøjer til GUI-testforløb giver optage-/afspilningsfaciliteter for applikationer til grafiske brugergrænseflader (GUI). På engelsk anvendes også betegnelsen WIMP (Windows, Icons, Mouse, Pointer)- interface applikationer. Værktøjerne simulerer musebevægelser, knap-klik og tastaturinput og kan genkende GUI-objekter som vinduer, felter, knapper og andre kontroller. Objekttilstande og bitmapbilleder kan optages til senere sammenligning. Testforløbene optages normalt i et programmerbart scriptsprog, testdata, testcases og forventede resultater kan gemmes i separate test-databaser. Værktøjerne bruges ofte til at automatisere regressionstest. Testharness og testdrivere anvendes ofte til eksekvering af software under test, hvis softwaren ikke har nogen brugergrænseflade eller for at køre grupper af bestående, automatiserede testscripts, som kan styres af testeren. Der findes nogle værktøjer på det kommercielle marked, men også specialskrevne programmer hører til i denne kategori. Simulatorer anvendes til at understøtte test, når kode eller andre systemer enten ikke er til rådighed eller upraktisk at anvende (f.eks. test af software til at tackle atomkernenedsmeltning). Værktøjer til performancetest har to hovedegenskaber: Belastningsgenererings- og testtransaktionsmåling. Belastningsgenerering (generering af load) finder sted ved enten at køre applikationen igennem brugergrænsefladen eller ved hjælp af testdrivere, der simulerer den belastning som applikationen generer på arkitekturen. Antallet af eksekverede transaktioner registreres. Køres applikationen via brugergrænsefladen, foretages og registreres der tidsmålinger for udvalgte transaktioner. Værktøjer til performancetest frembringer normalt rapporter på basis af de registrerede testtransaktioner og grafik over belastningen i forhold til svartider. Værktøjer til dynamisk analyse giver run-time informationer om status for eksekvering af software. Værktøjerne anvendes almindeligvis til overvågning af allokeringen, anvendelsen og deallokering af hukommelse, markering af hukommelseslæk, åbne pointere, pointeraritmetik og andre fejltagelser, som er vanskelige at finde på statisk vis. Værktøjer til debugging bruges hovedsageligt af programmører til at genskabe fejl og undersøge programmernes tilstand. Debuggers gør det muligt for programmøren at eksekvere programmet linje for linje, standse programmet på en vilkårlig programinstruktion og sætte og undersøge programvariable. Værktøjer til sammenligning anvendes til at opdage forskelle mellem faktiske resultater og forventede resultater. Selvstændige sammenligningsværktøjer kan normalt håndtere en række forskellige fil- og databaseformater. Værktøjer til testafvikling har normalt indbyggede sammenligningsfunktioner, der behandler karakterskærmbilleder, GUI-objekter eller bitmapbilleder. Disse værktøjer kan ofte filtrere, således at rækker eller kolonner af data eller områder på skærmbilleder kan ignoreres. Værktøjer til teststyring kan have flere egenskaber. Styring af testmaterialer omfatter oprettelse, styring og kontrol af testdokumentationen, f.eks. testplaner, -specifikationer og resultater. Nogle værktøjer understøtter testforløbets projektstyringsaspekter, f.eks. testtidsplanlægning, registrering af testresultater samt styringen af Copyright DANSK IT, 2004.

12 testhændelser, der er opstået under testen. Testhændelsesværktøjer kan også indeholde workflow-orienterede faciliteter til at følge og styre allokering, fejlretning og gentest af fejl. De fleste teststyringsværktøjer indeholder udstrakte rapporterings- og analysemuligheder. Værktøjer til testdækningsmåling (eller -analyse) indeholder muligheder for objektiv måling af den strukturelle testdækning under testafvikling. De programmer, der skal underkastes test, instrumenteres før compileringen. Instrumenteringskoden registrerer dækningsdata dynamisk i en logfil, uden at funktionaliteten af det program, der testes, bliver påvirket. Efter eksekvering analyseres logfilen og der fremlægges en dækningsstatistik. De fleste værktøjer udarbejder statistikker over de mest almindelige dækningsmål som instruktions- eller forgreningsdækning. Valg og implementering af værktøj Hvilke testaktiviteter kan automatiseres? Krav til CAST værktøjer; hvilke værktøjstyper skal bruges? Testprocessens modenhed og CAST parathed ; udvælgelsesprocessen; værktøjer, platforme og CAST integration; pilotprojekter og udrulning Mange testaktiviteter kan automatiseres og testafviklingsværktøjer er ikke nødvendigvis første og eneste valg. Undersøg testaktiviteterne med henblik på, hvor værktøjer kunne være en fordel og prioriter de områder, der anses for at være de vigtigste. Det kan være vigtigere, hvordan værktøjet passer ind i testprocessen end at vælge det værktøj, der har mest funktionalitet - når det skal besluttes, om der er brug for et værktøj og hvilket det så i givet fald skal være. Testværktøjernes nyttevirkning afhænger normalt af et systematiseret og disciplineret afviklet testproces. Forløber testen kaotisk, kan værktøjerne vise sig ikke at have nogen nytte, og tværtimod være en hindring for testen. Der skal allerede eksistere en god testproces eller der skal være en erkendelse af, at testprocessen skal forbedres samtidigt med implementeringen af testværktøjer. Den grad af lethed, hvormed testværktøjer kan implementeres, kan betegnes som CAST parathed. Testværktøjer kan indeholde interessant funktionalitet, der dog ikke nødvendigvis er til rådighed på den aktuelle platform. F.eks. kører på forskellige versioner af UNIX-systemer, men ikke dit. Nogle testværktøjer, f.eks. performancetestværktøjer kræver egen hardware. Derfor bør anskaffelsesprisen for denne hardware tages med i rentabilitetsberegningerne. Hvis der allerede er værktøjer til rådighed, skal det overvejes på hvilket niveau disse skal integreres med andre værktøjer og om det i det hele taget giver mening. Typisk vil spørgsmålet være om et testafviklingsværktøj skal integreres i det bestående teststyringsværktøj eller omvendt. Nogle udbydere tilbyder integrerede testværktøjssæt, f.eks. testafvikling, teststyring og performancetest som samlet pakke. Integrationen af nogle testværktøjer kan medføre store fordele, men der findes også tilfælde hvor integrationen alene er kosmetisk. Når der først er enighed om kravene til automatisering, er der fire trin tilbage i udvælgelsesprocessen: 1. Oprettelse af en liste af udvalgte potentielle testværktøjer 2. Afholdelse af demoer 3. Evaluering af valgt(e) værktøj(er) 4. Review og valg af værktøj. Før man forpligter sig til at implementere testværktøjet på tværs af alle projekter, gennemføres der normalt et pilotprojekt for at sikre, at fordelene ved anvendelsen af testværktøjet virkelig kan opnås. Pilotprojektets mål er at få en vis erfaring med anvendelsen af testværktøjerne, identificere nødvendige ændringer i testprocessen og anslå de faktiske omkostninger og fordele ved implementeringen. Udrulning af testværktøjet bør basere sig på en succesrig evaluering af pilotprojektet. Udrulning kræver normalt et stort engagement blandt testværktøjets brugere og de nye projekter, da der altid er startomkostninger forbundet med anvendelse af ethvert værktøj i nye projekter Copyright DANSK IT, 2004.