Certified Tester Foundation Level Syllabus

Transkript

1 Version 2007 Dansk udgave

2 Copyright 2007, ophavsmændene (Thomas Müller (formand), Dorothy Graham, Debra Friedenberg og Erik van Veendendal). Copyright 2005, ophavsmændene (Thomas Müller (formand), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson og Erik van Veendendal), alle rettigheder forbeholdes. Ophavsmændene overfører copyright til (herefter kaldet ISTQB). Ophavsmændene (de aktuelle copyrightindehavere) og ISTQB (som den fremtidige copyrightindehaver) har aftalt følgende brugsbetingelser: 1) Enhver enkeltperson eller uddannelsesvirksomhed må bruge denne syllabus som grundlag for et uddannelsesforløb, hvis ophavsmændene og ISTQB er angivet som kilde og copyrightindehavere og forudsat, at al sådan uddannelse kun oplyser syllabus efter forelæggelse til officiel akkreditering af undervisningsmaterialet til et godkendt nationalt ISTQB-nævn. 2) Enhver enkeltperson eller gruppe af enkeltpersoner må bruge denne syllabus som grundlag for artikler, bøger eller anden afledt skrift, hvis ophavsmændene og ISTQB er oplyst som kilde og copyright-indehavere af syllabus. 3) Ethvert godkendt nationalt ISTQB-nævn må oversætte denne syllabus og autorisere den (eller oversættelsen heraf) til andre parter.

3 Revisionshistorie Version Dato Bemærkninger ISTQB Maj-2007 Certified Tester Vedligeholdelsesudgivelse - se Tillæg E - Releasenotat til Syllabus ISTQB Juli-2005 Certified Tester ASQF V2.2 Juli-2003 ASQF Syllabus Foundation Level Version 2.2 Lehrplan Grundlagen des Softwaretestens ISEB V Feb-1999 ISEB Foundation Syllabus V februar 1999 Version 2007 Side 3 af maj 2007

4 Indholdsfortegnelse Certified Tester Revisionshistorie... 3 Indholdsfortegnelse... 4 Taksigelser... 9 Introduktion til denne syllabus Formålet med dette dokument Certified Tester Foundationniveau i software-test Undervisningsformål/vidensniveau Eksamen Akkreditering Detaljeringsgrad Sådan er denne syllabus organiseret Testprincipper (K2) Undervisningsformål for grundlæggende test Hvorfor er test nødvendig? (K2) Hvad er test? (K2) Generelle testprincipper (K2) Grundlæggende testproces (K1) Psykologien i test (K2) Hvorfor er test nødvendig (K2) Termer Kontekst i softwaresystemer (K1) Årsager til softwarefejl (K2) Testrollen ved softwareudvikling, vedligeholdelse og drift (K2) Test og kvalitet (K2) Hvor megen test er nok? (K2) Hvad er test? (K2) Termer Baggrund Generelle testprincipper (K2) Termer Principper...16 Princip 1 Testviser tilstedeværelse af defekter Princip 2 Udtømmende test er umulig Princip 3 Tidlig test Princip 4 Defekt-klyngedannelse Princip 5 Pesticide-paradoks Princip 6 Test er afhængig af sammenhængen Princip 7 Fravær-af-fejl-fejltagelsen Grundlæggende testproces (K1) Termer Baggrund Testplanlægning og kontrol (K1) Testanalyse og design (K1) Version 2007 Side 4 af maj 2007

5 1.4.3 Testimplementering og afvikling (K1) Evaluering af udgangskriterier og rapportering (K1) Testlukningsaktiviteter (K1) Psykologien i test (K2) Termer Baggrund Referencer Test igennem hele softwarens livscyklus (K2) Softwareudviklingsmodeller (K2) Testniveauer (K2) Testtyper (K2) Vedligeholdelsestest (K2) Softwareudviklingsmodeller (K2) Termer Baggrund V-model (sekventiel udviklingsmodel) (K2) Iterativ-inkrementelle udviklingsmodeller (K2) Test i en livscyklusmodel (K2) Testniveauer (K2) Termer Baggrund Komponenttest (K2) Integrationstest (K2) Systemtest (K2) Accepttest (K2) Brugeraccepttest Drifts(accept)test Kontrakt- og regelaccepttest Alfa- og beta- (eller felt-)test Testtyper (K2) Termer Baggrund Test af funktion (funktionstest) (K2) Test af ikke-funktionelle softwareegenskaber (ikke-funktionel test) (K2) Test af softwarestruktur/-arkitektur (strukturel test) (K2) Test i forbindelse med ændringer (bekræftelsestest (gentest) og regressionstest) (K2) Vedligeholdelsestest (K2) Termer Baggrund Referencer Statiske teknikker (K2) Statiske teknikker og testproces (K2) Reviewproces (K2) Statisk analyse med værktøjer (K2) Statiske teknikker og testproces (K2) Termer Baggrund Reviewproces (K2) Termer Baggrund Faser ved et formelt review (K1) Roller og ansvar (K1) Version 2007 Side 5 af maj 2007

6 3.2.3 Reviewtyper (K2) Uformelt review Walkthrough Teknisk review Inspektion Succesfaktorer for reviews (K2) Statisk analyse vha. værktøjer (K2) Termer Baggrund Værdien ved statisk analyse er: Typiske defekter fundet ved statiske analyseværktøjer indbefatter: Referencer Testdesignteknik (K3) Testudviklingsprocessen (K2) Kategorier af testdesignteknik (K2) Specifikationsbaserede eller black-box-teknikker (K3) Strukturbaseret eller white-box-teknikker (K3) Erfaringsbaserede teknikker (K2) Valg af testteknik (K2) Testudviklingsprocessen (K2) Termer Baggrund Kategorier af testdesignteknikker (K2) Termer Baggrund Specifikationsbaserede eller black-box-teknikker (K3) Termer Ækvivalenspartitionering (K3) Grænseværdianalyse (K3) Test af beslutningstabel (K3) Tilstandsovergangstest (K3) Usecase test (K2) Strukturbaseret eller white-box-teknikker (K3) Termer Baggrund Instruktionstest og dækning (K3) Beslutningstest og dækning (K3) Andre strukturbaserede teknikker (K1) Erfaringsbaserede teknikker (K2) Termer Baggrund Valg af testteknikker (K2) Termer Baggrund Referencer Teststyring (K3) Testorganisation (K2) Testplanlægning og estimering (K2) Overvågning og kontrol af testfremdrift (K2) Konfigurationsstyring (K2) Risiko og test (K2) Hændelseshåndtering (K3) Version 2007 Side 6 af maj 2007

7 5.1 Testorganisation (K2) Termer Testorganisation og uafhængighed (K2) Testlederes og testeres opgaver (K1) Testplanlægning og estimering (K2) Termer Testplanlægning (K2) Testplanlægningsaktiviteter (K2) Udgangskriterier (K2) Testestimering (K2) Testtilgang (teststrategier) (K2) Overvågning og kontrol af testfremdriften (K2) Termer Overvågning af testfremdrift(k1) Testrapportering (K2) Testkontrol (K2) Konfigurationsstyring (K2) Termer Baggrund Risiko og test (K2) Termer Baggrund Projektrisici (K2) Produktrisici (K2) Hændelseshåndtering (K3) Termer Baggrund Værktøjsstøtte til test (K2) Typer af testværktøjer (K2) Effektiv brug af værktøjer: Mulige fordele og risici (K2) Introduktion af værktøj i en organisation (K1) Typer af testværktøjer (K2) Termer Klassificering af testværktøj (K2) Værktøjssupport til styring af test og tests (K1) Teststyringsværktøjer Kravstyringsværktøjer Hændelseshåndteringsværktøjer Konfigurationsstyringsværktøjer Værktøjsstøtte til statisk test (K1) Reviewværktøjer Statiske analyseværktøjer (U) Modelleringsværktøjer (U) Værktøjsstøtte til testspecifikation (K1) Testdataforberedelsesværktøjer (U) Værktøjsstøtte til testafvikling og -logging (K1) Testafviklingsværktøjer Testharness-/enhedstest-rammeværktøjer (U) Testsammenlignere Dækningsmåleværktøjer (U) Sikkerhedsværktøjer Værktøjsstøtte til performance og overvågning (K1) Version 2007 Side 7 af maj 2007

8 Værktøjssupport til specifikke programområder (K1) Værktøjssupport vha. af andre værktøjer (K1) Effektiv brug af værktøjer: mulige fordele og risici(k2) Termer Mulige fordele og risici ved værktøjsstøtte til test (for alle værktøjer (K2) Specielle overvejelser for nogle værktøjstyper (K1) Testafviklingsværktøjer Performancetestværktøjer Statiske analyseværktøjer Teststyringsværktøjer Introduktion af et værktøj i en organisation (K1) Termer Baggrund Referencer Referencer Tillæg A Syllabus-baggrund Historien om dette dokument Formål for Foundation Certificate qualification Formål for international kvalifikation (bearbejdet efter ISTQB-mødet i Sollentuna, November 2001) Adgangskrav for denne kvalifikation Baggrund og historie for Foundation Certificate in Tillæg B Undervisningsmål/vidensniveau Niveau 1: Husk (K1) Niveau 2: Forstå (K2) Niveau 3: Anvende(K3) Reference...73 Tillæg C Gældende regler for ISTQB Foundation syllabus Generelle regler Aktuelt indhold Undervisningsformål Referencer Informationskilder Tillæg D Bemærkning til undervisere Specifikationsbaseret eller black-box-teknikker Strukturbaseret eller white-box-teknikker Hændelseshåndtering Tillæg E Releasenotat syllabus Indeks Version 2007 Side 8 af maj 2007

9 Taksigelser Dette dokument er skrevet af Working Party Foundation Level (2007 udgave): Thomas Müller (formand), Dorothy Graham, Debra Friedenberg, og Erik van Veendendal. Hovedteamet takker reviewteamet (Hans Schaefer, Stephanie Ulrich, Meile Posthuma, Anders Pettersson, og Wonil Kwon) og alle nationale boards for forslag til den nuværende version af Syllabus. Dette dokument er skrevet af Working Party Foundation Level (2005 udgave): Thomas Müller (formand), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson og Erik van Veendendal. Kerne-teamet takker review-teamet og alle nationale nævn for forslag til den aktuelle syllabus. En særlig tak til (Østrig) Anastasios Kyriakopoulos, (Danmark) Klaus Olsen, Christine Rosenbeck- Larsen, (Tyskland) Matthias Daigl, Uwe Hehn, Tilo Linz, Horst Pohlmann, Ina Schieferdecker, Sabine Uhde, Stephanie Ulrich, (Indien) Vipul Kocher, (Israel) Shmuel Knishinsky, Ester Zabar, (Sverige) Anders Claesson, Mattias Nordin, Ingvar Nordström, Stefan Ohlsson, Kennet Osbjer, Ingela Skytte, Klaus Zeuge, (Schweiz) Armin Born, Sandra Harries, Silvio Moser, Reto Müller, Joerg Pietzsch, (Storbritannien) Aran Ebbett, Isabel Evans, Julie Gardiner, Andrew Goslin, Brian Hambling, James Lyndsay, Helen Moore, Peter Morgan, Trevor Newton, Angelina Samaroo, Shane Saunders, Mike Smith, Richard Taylor, Neil Thompson, Pete Williams, (USA) Dale Perry. Version 2007 Side 9 af maj 2007

10 Introduktion til denne syllabus Formålet med dette dokument Denne syllabus danner grundlag for Qualification på Foundationniveau. (herefter kaldet ISTQB) giver den til den nationale eksaminationsenhed til godkendelse af kursusudbydere og til at udlede eksamensspørgsmål på deres lokale sprog. Kursusudbydere fremstiller undervisningsmateriale og bestemmer passende undervisningsmetoder til akkreditering, og syllabussen hjælper kandidater med deres forberedelse til eksamen. Information om historie og baggrund for denne syllabus findes i Bilag eller Appendix) A. Certified Tester Foundationniveau i software-test Kvalifikationen på Foundationniveau er rettet mod enhver, der er involveret i test af software. Dette inkluderer personer i roller som f.eks. testere, testanalytikere, testingeniører, testkonsulenter, testansvarlige, bruger- accepttestere og softwareudviklere. Kvalifikationen på Foundationniveau er også egnet til enhver, der ønsker grundlæggende forståelse af softwaretest, som f.eks. projektledere, kvalitetsansvarlige, softwareprogrammører, forretningsanalytikere, it-ledere og virksomhedsledere. Indehavere af Foundation Certificate vil være i stand til at opnå et højere kvalifikationsniveau i softwaretest. Undervisningsformål/vidensniveau Der gives kognitive niveauer for hvert afsnit i denne syllabus: K1: huske, kende, genkalde. K2: forstå, forklare, begrunde, sammenligne, klassificere, kategorisere, give eksempler, opsummere. K3: anvende, bruge. Der er yderligere oplysninger og eksempler om undervisningsformål i Bilag B. Alle termer, der er oplistet under Termer lige under kapiteloverskrifter, skal kunne huskes(k1), også selvom de ikke udtrykkeligt er nævnt i undervisningsformålet. Eksamen Eksamen i Foundation Certificate er baseret på denne syllabus. Svar på eksamensspørgsmål kan kræve brug af materiale i mere end et afsnit i denne syllabus. Alle afsnit i denne syllabus er eksamensrelevante. Eksamensformen er multiple choice-opgaver. Eksamen kan gennemføres som en del af et godkendt uddannelsesforløb eller tages individuelt (f.eks. i et uddannelsescenter). Version 2007 Side 10 af maj 2007

11 Akkreditering Kursusudbydere, hvis kursusmateriale følger denne syllabus, kan godkendes af et nationalt nævn, der er godkendt af ISTQB. Retningslinjer for akkreditering kan indhentes fra nævnet eller enheden, der giver akkrediteringen. Et akkrediteret kursus er anerkendt som værende i overensstemmelse med denne syllabus og har tilladelse til at en ISTQB-eksamen kan gennemføres som en del af kurset. Yderligere retningslinjer for undervisere findes i Tillæg D. Detaljeringsgrad Detaljeringsgraden i denne syllabus gør det muligt at gennemføre ensartet undervisning og eksamination. For at opnå dette formål, består syllabus af: Generelle undervisningsformål, der beskriver hensigten med foundationniveauet. En liste over oplysninger om undervisningsform, indeholdende en beskrivelse og referencer til ekstra kilder, hvis det ønskes. Undervisningsformål for hvert vidensområde, der kognitivt beskriver udbytte af undervisning og den tankegang, der skal opnås. En liste over termer, som de studerende skal kunne huske og forstå. En beskrivelse af de nøglekoncepter, der skal undervises i, indeholdende kilder som godkendt litteratur eller standarder. Syllabussens indhold er ikke en beskrivelse af hele vidensområdet inden for softwaretest; den afspejler den detaljeringsgrad, der skal dækkes i kurser på foundationniveau. Sådan er denne syllabus organiseret Der er seks hovedkapitler. Overskriften viser niveauerne for de indlæringsmål, der er dækket i kapitlet. F.eks.: 2. Test igennem hele softwarens livscyklus (K2) 115 minutter viser, at kapitel 2 har indlæringsmål på K1 (antages, når der er vist et højere niveau) og K2 (men ikke K3), og det forventes, at det tager 115 minutter at undervise i kapitlets materiale. I hvert kapitel er der et antal afsnit. Hvert afsnit har også indlæringsmål og den fornødne tid angivet. Underafsnit, der ikke har nogen tidsangivelse, kan indeholdes i den tid, der er angivet for afsnittet. Version 2007 Side 11 af maj 2007

12 Testprincipper (K2) 155 minutter Undervisningsformål for grundlæggende test Formålene viser, hvad du skal kunne efter fuldførelse af hvert enkelt modul Hvorfor er test nødvendig? (K2) Beskriv med eksempler hvordan en defekt kan skade en person, miljøet eller en virksomhed. (K2) Skeln mellem rodårsagen til en defekt og effekten heraf. (K2) Giv årsager til hvorfor det er nødvendigt at udføre test ved at give eksempler på det. (K2) Beskriv hvorfor test er en del af kvalitetssikring, og giv eksempler på, hvordan test bidrager til en højere kvalitet. (K2) Husk termerne fejltagelse (error) defekt, fejl, afvigelse og de tilsvarende termer fejltagelse (mistake) og bug. (K1) 1.2. Hvad er test? (K2) Husk de almindelige formål for test. (K1) Beskriv formålet ved test i softwareudvikling, vedligeholdelse og drift som en metode til at finde defekter, skabe tillid og forhindre defekter. (K2) 1.3. Generelle testprincipper (K2) Forklar de grundlæggende principper ved test. (K2) 1.4. Grundlæggende testproces (K1) Husk de grundlæggende testaktiviteter fra planlægning til testafslutningsaktiviteter og hovedopgaverne for hver enkelt testaktivitet. (K1) 1.5. Psykologien i test (K2) Husk, at testens succes påvirkes af psykologiske faktorer (K1): o klare testformål afdækker testerens effektivitet o blindhed overfor egne fejl; o venlig kommunikation og feedback på fejl. Stil testerens og udviklerens holdninger op imod hinanden. (K2) Version 2007 Side 12 af maj 2007

13 1. Hvorfor er test nødvendig (K2) 20 minutter Termer Bug, defekt, fejl, afvigelse, fejltagelse, kvalitet, risiko Kontekst i softwaresystemer (K1) Softwaresystemer fylder mere og mere i vores liv, fra forretningssystemer (f.eks. bankverdenen) til forbrugerprodukter (f.eks. biler). Det fleste mennesker har haft oplevelser med software, der ikke fungerede som forventet. Software, der ikke fungerer korrekt, kan føre til mange problemer, herunder tab af penge, tid eller virksomhedsomdømme og kan medføre selv svære personskader eller død Årsager til softwarefejl (K2) En fejltagelse er en menneskelig handling, der kan medføre en defekt (fejl, bug) i koden, i softwaren, i et system eller i et dokument. Hvis der opstår en defekt i koden, vil systemet ikke gøre det, det skal (eller det det ikke skal gøre), hvilket medfører en afvigelse. Defekter i software, systemer eller dokumenter kan medføre afvigelser, men det er ikke alle defekter, der medfører dette. Defekter opstår, fordi vi ikke er perfekte, og fordi der er tidspres, kompleks kode, infrastrukturel kompleksitet, ændret teknologi og/eller mange samspil mellem systemer. Afvigelser kan også være forårsaget af miljøbetingelser: stråling, magnetisme, elektroniske felter, og forurening kan medføre fejl i firmware eller påvirke softwareafviklingen ved ændring af hardwaretilstande Testrollen ved softwareudvikling, vedligeholdelse og drift (K2) Omhyggelig systemtest og dokumentation kan hjælpe til med at reducere risikoen for problemer under drift og bidrage til softwaresystemets kvalitet, hvis de fundne defekter rettes, før systemet tages i brug. Softwaretest kan også være påkrævet til imødekommelse af kontraktlige, juridiske krav eller industrispecifikke standarder Test og kvalitet (K2) Ved hjælp af test er det muligt at måle softwarekvaliteten, hvad angår fundne defekter både for funktionelle og ikke-funktionelle krav og egenskaber (f.eks. pålidelighed, brugbarhed, effektivitet vedligeholdelsesegnethed og portabilitet). Se Kapitel 2 for mere information om ikke-funktionel test. For mere information om softwareegenskaber, se Softwareudvikling Softwareproduktkvalitet (ISO 9126). Test kan give tillid til softwarekvaliteten, hvis der findes få eller ingen defekter. En rigtig designet test, der gennemføres, reducerer det overordnede risikoniveau i et system. Når der findes defekter ved testen, forbedres softwarekvaliteten, når disse defekter rettes. Version 2007 Side 13 af maj 2007

14 Der skal læres af tidligere projekter. Ved at forstå rodårsagen til de fundne defekter i andre projekter, kan processerne forbedres, og dermed kan man forhindre, at disse defekter opstår igen og dermed forbedre kvaliteten i fremtidige systemer. Dette er et aspekt af kvalitetssikring. Test bør være integreret som en del af kvalitetssikringsaktiviteterne (dvs. sideløbende med udvikling af standarder, uddannelse og defektanalyse) Hvor megen test er nok? (K2) Når man skal beslutte, hvor megen test, der er behov for, skal man tage hensyn til risikoniveauet, herunder tekniske og virksomhedsprodukt- og projektrisici samt projektbegrænsninger, som f.eks. tid og budget. (Risiko drøftes yderligere i Kapitel 5.) Test bør give tilstrækkelige information til interessenterne til at de kan træffe beslutninger om frigivelse af softwaren eller systemet, der testes, til næste udviklingstrin eller til overdragelse til kunder på et veldefineret grundlag. Version 2007 Side 14 af maj 2007

15 1.2 Hvad er test? (K2) 30 minutter Termer Debugging, krav, review, testcase, testning, test- formål. Baggrund En almindelig opfattelse af test er, at det kun betyder at køre tests, dvs. eksekvering af software. Dette er en del af det at teste, men udgør ikke alle testaktiviteterne. Der findes testaktiviteter både før og efter testafviklingen, nemlig aktiviteter såsom planlægning og kontrol, valg af testbetingelser, design af testcases og kontrol af resultater, evaluering af slutkriterier, rapportering om testprocessen og systemet under testen, og afslutning og lukning (f.eks. efter fuldførelse af en testfase). Test omfatter også review af dokumenter (herunder kildekode) og statisk analyse. Både dynamisk test og statisk test kan bruges som middel til opnåelse af de samme mål og giver information til forbedring af det testede system og til udviklings- og testprocessen. Der kan være forskellige testformål: finde defekter; få tillid til kvalitetsniveauet og give information; forebygge defekter. Den tankeproces, det er at designe tests tidligt i forløbet (verifikation af testgrundlag via testdesign) kan hjælpe med at forebygge, at defekter indføres i koden. Review af dokumenter (f.eks. krav) hjælper også med at forebygge at defekter opstår i koden. Forskellige synsvinkler på test afstedkommer forskellige formål. F.eks.: i udviklingstest (f.eks. komponent-, integrations- og systemtest) kan hovedformålet være at få så mange afgivelser som muligt, så softwaredefekter kan identificeres og rettes. I accepttest kan hovedformålet være at få bekræftet, at systemet virker som forventet, for at få tillid til, at det har opfyldt kravene. I nogle tilfælde kan hovedformålet med test være at vurdere softwarekvaliteten (uden hensigter om at rette defekter), for at give informationer til interessenter om risikoen ved at frigive systemet på et givet tidspunkt. Vedligeholdelsestest indebærer ofte test af, at der ikke er opstået nye defekter ved udvikling af ændringerne. Ved driftstest kan hovedformålet være at vurdere systemegenskaber, som f.eks. pålidelighed eller tilgængelighed. Debugging og test er ikke det samme. Test kan vise afvigelser, der er forårsaget af defekter. Debugging er den udviklingsaktivitet, der finder årsagen til en defekt, reparerer koden og kontrollerer, at defekten er rettet korrekt. Efterfølgende gentest foretaget af tester sikrer, at rettelsen rent faktisk retter afvigelsen. Ansvaret for hver aktivitet er meget forskellig, dvs. testere tester, og udviklere debugger. Testprocessen og dens aktiviteter er forklaret i Afsnit 1.4. Version 2007 Side 15 af maj 2007

16 1.3 Generelle testprincipper (K2) 35 minutter Termer Udtømmende test. Principper Der er igennem de seneste 40 år foreslået en række testprincipper, som giver almindelige retningslinjer gældende for al test. Princip 1 Testviser tilstedeværelse af defekter Test kan vise at defekter er til stede, men kan ikke bevise, at der ikke er nogen defekter. Test reducerer sandsynligheden for, at der er endnu ikke afslørede defekter tilbage i softwaren, men selvom der ikke er fundet defekter, er det ikke et bevis for korrekthed. Princip 2 Udtømmende test er umulig Test af alt (alle kombinationer af inputs og startbetingelser) er ikke mulig, bortset fra i helt ubetydelige tilfælde. I stedet for udtømmende test bør risikovurdering og prioritering bruges for at fokusere testindsatsen. Princip 3 Tidlig test Testaktiviteter bør starte så tidligt som muligt i softwarens eller systemudviklingens livscyklus og bør være fokuseret på definerede formål. Princip 4 Defekt-klyngedannelse Et lille antal moduler indeholder de fleste af de defekter, der er fundet ved test forud for frigivelsen eller er ansvarlige for de fleste driftsafvigelser. Princip 5 Pesticide-paradoks Hvis de samme tests afvikles igen og igen, vil det samme sæt testcases til sidst ikke finde nogen nye fejl. For at overvinde dette pesticide-paradoks skal testcases reviewes og revideres regelmæssigt, og nye og anderledes tests skal skrives for at afprøve forskellige dele af softwaren eller systemet for muligvis at finde flere defekter. Princip 6 Test er afhængig af sammenhængen Test udføres forskelligt i forskellige sammenhænge. Sikkerhedskritisk software testes f.eks. anderledes end et e-handelssite. Princip 7 Fravær-af-fejl-fejltagelsen Det hjælper ikke at finde og rette defekter, hvis det fremstillede system ikke opfylder brugernes behov og forventninger. Version 2007 Side 16 af maj 2007

17 1.4 Grundlæggende testproces (K1) 35 minutter Termer Bekræftet test. gentest, udgangskriterier, hændelse, regressionstest, testgrundlag, testbetingelser, testdækning, testdata, testafvikling, testlog, testplan, testprocedure, testpolitik, teststrategi, testsuite, testopsummeringsrapport og test-delprodukter. Baggrund Den mest synlige del af test er afvikling af tests. Men for at være effektiv bør testplaner også indeholde den tid, der skal bruges til planlægning af tests, design af testcases, forberedelse af afvikling og evaluering af status. Den grundlæggende testproces består af følgende hovedaktiviteter: planlægning og kontrol; analyse og design; implementering og afvikling; vurdering af slutkriterier og rapportering; testlukningsaktiviteter. Selv om der er en logisk rækkefølge, kan procesaktiviteterne overlappe hinanden eller finde sted samtidig Testplanlægning og kontrol (K1) Testplanlægning er verifikation af testopdraget, definition af testformålet og specifikation af testaktiviteter for at opnå formål og opdrag. Testkontrol er den løbende aktivitet at sammenligne den aktuelle fremdrift med planen og rapportere status, inklusiv afvigelser fra planen. Det omfatter træfning af de forholdsregler, der er nødvendige for at opfylde projektets opdrag og formål. For at testen kan kontrolleres, skal den overvåges gennem hele projektet. Test- planlægning skal tage højde for feedback fra overvågnings- og kontrolaktiviteter. Testplanlægning og kontrolopgaver er defineret i kapitel 5 i denne syllabus Testanalyse og design (K1) Testanalyse og design er den aktivitet, hvor det generelle testformål omdannes til håndgribelige testbetingelser og testcases. Testanalyse og design har følgende hovedopgaver: Review af testgrundlaget (som f.eks. krav, arkitektur, design, grænseflader). Evaluering af testbarhed for testgrundlag og testobjekter. Identificering og prioritering af testbetingelser eller testkrav baseret på analyse af testelementer, specifikationen, opførsel og struktur. Design og prioritering af testscases. Identifikation af nødvendige testdata til support af testvilkår og testcases. Version 2007 Side 17 af maj 2007

18 Design af testmiljø-setup og identifikation af evt. påkrævet infrastruktur og værktøjer Testimplementering og afvikling (K1) Testimplementering og afvikling er aktiviteterne, hvor testprocedurer eller scripts er specificeret ved at kombinere testcases i en planlagt rækkefølge og inkludere nødvendig information for testafvikling, opsætning af testmiljø og kørsel af test. Testimplementering og afvikling har følgende hovedopgaver: Udvikling, implementering og prioritering af testcases. Udvikling og prioritering af testprocedurer, dannelse af testdata og eventuelt forberedelse af testharness og skrivning af automatiserede testscripts. Dannelse af sekvenser af test ud fra testprocedurer for effektiv testafvikling. Verifikation af at testmiljøet er korrekt opsat. Afvikling af testprocedurer enten manuelt eller vha. afviklingsværktøjer i forhold til den planlagte rækkefølge. Logging af resultatet af testafviklingen og registrering af identitet og version af softwaren under test, testværktøjer og test-delprodukter. Sammenligning af faktiske resultater med forventede resultater. Rapportering af uoverensstemmelser som hændelser og analyse af dem for at fastlægge deres årsag (f.eks. en defekt i koden, i de specificerede testdata, i testdokumentet eller en fejltagelse i udførelsen af testen). Gentagelse af testaktiviteter som et resultat af de aktiviteter, der er blevet udført for hver uoverensstemmelse. F.eks. gen-afvikling af en test, der tidligere fejlede for at få bekræftet en rettelse (gentest), afvikling af en rettet test og/eller afvikling af tests for at sikre, at der ikke er opstået defekter i uændrede områder i softwaren, eller at en defektrettelse ikke har afdækket andre defekter (regressionstest) Evaluering af udgangskriterier og rapportering (K1) Evaluering af udgangskriterier er den aktivitet, hvor testafviklingen vurderes i forhold til de fastlagte formål. Det bør udføres for hvert testniveau. Evaluering af udgangskriterier har følgende hovedopgaver: Kontrol af testlogs i forhold til de udgangskriterier, der er specificeret i testplanlægningen. Vurdering af, om der er behov for flere tests, eller om de specificerede udgangskriterier bør ændres. Skrivning af en testopsummeringsrapport til interessenterne. Version 2007 Side 18 af maj 2007

19 1.4.5 Testlukningsaktiviteter (K1) Testlukningsaktiviteter indsamler data fra fuldførte testaktiviteter for at konsolidere erfaring, testdelprodukter, facts og tal. F.eks. når et softwaresystem frigives, et testprojekt er fuldført (eller annulleret), når man er nået til en milepæl, eller når en vedligeholdelsesrelease er fuldført. Testlukningsaktiviteter indeholder følgende hovedopgaver: Kontrol af hvilke af de planlagte leverancer der er leveret, lukning af hændelsesrapporter eller oprettelse af ændringsregistreringer for dem der stadig måtte være åbne, og dokumentation af godkendelsen af systemet. Færdiggørelse og arkivering af test-delprodukter, testmiljøet og testinfrastrukturen til senere genbrug. Overdragelse af test-delprodukter til vedligeholdelsesorganisationen. Analyse af de opnåede erfaringer til brug for fremtidige releases og projekter og forbedring af testmodenhed. Version 2007 Side 19 af maj 2007

20 1.5 Psykologien i test (K2) 35 minutter Termer Fejlgætning, uafhængighed. Baggrund Den tankegang, der skal bruges ved test og review, er forskellig fra den, der skal bruges ved softwareudvikling. Med den rette tankegang er udviklere i stand til at teste deres egen kode, men overdragelse af dette ansvar til en tester gøres typisk for at fokusere indsatsen og få ekstra udbytte i form af f.eks. en uafhængig vurdering fra uddannede og professionelle testressourcer. Uafhængig test kan udføres på alle testniveauer. En vis grad af uafhængighed (for at undgå ophavsmandens forudindtagethed) er ofte mere effektivt til at finde defekter og afvigelser. Uafhængighed er imidlertid ikke en erstatning for kendskab, og udviklere kan effektivt finde mange defekter i deres egen kode. Der kan defineres mange uafhængighedsgrader: Tests designet af den person/de personer, der skrev softwaren under test (lav uafhængighedsgrad). Tests designes af en anden person/andre personer (f.eks. fra et udviklingsteam). Tests designet af en person/personer fra en anden organisationsenhed (f.eks. et uafhængigt testteam) eller testspecialister (f.eks. usability eller performance testspecialister). Tests designes af en person/personer fra en anden organisation eller virksomhed (dvs. ved outsourcing eller certificering af en ekstern enhed). Mennesker og projekter styres af formål. Mennesker har en tendens til at tilpasse deres planer til de formål, der er sat af ledelsen eller interessenterne, f.eks. at finde defekter eller til at bekræfte, at softwaren virker. Det er derfor vigtigt klart at fastslå formålene for test. Fund af afvigelser under test kan opfattes som kritik af produktet og af ophavsmanden. Test ses derfor ofte som en destruktiv aktivitet, selvom den er meget konstruktiv hvad angår håndtering af produktrisici. At søge efter afvigelser i et system kræver nysgerrighed, professionel pessimisme, et kritisk øje, opmærksomhed på detaljen, god kommunikation med udviklingskollegaer og erfaring som fejlgætning kan baseres på. Hvis fejl, defekter eller afvigelser kommunikeres på en konstruktiv måde, kan misstemning mellem testere, analytikere, designere og udviklere undgås. Dette gælder såvel for review som for test. Både testeren og testlederen skal have gode samarbejdsevner for at kunne kommunikere faktuelle oplysninger om defekter, fremdrift og risici på en konstruktiv måde. For ophavsmanden til softwaren eller dokumentet kan defektoplysninger hjælpe dem med at forbedre deres færdigheder. De defekter, der findes og rettes under en test, sparer både tid og penge senere og reducerer risici. Der kan opstå kommunikationsproblemer, især hvis testere kun ses som nogle, der er budbringere af uønskede nyheder om defekter. Der er imidlertid mange måder, hvorpå man kan forbedre kommunikation og samarbejdet mellem testere og andre: Version 2007 Side 20 af maj 2007

21 Start hellere med samarbejde end med kamp mind alle om det fælles mål om bedre kvalitet i systemer. Kommuniker produktobservationer på en neutral måde, med fokus på facts uden at kritisere den person, der har skabt det, skriv f.eks. objektive og faktuelle hændelsesrapporter og review-observationer. Forsøg at forstå den anden persons følelser, og hvorfor vedkommende reagerer, som han/hun gør. Sørg for, at den anden person har forstået, hvad du har sagt vice versa. Referencer Black, 2001, Kaner, Beizer, 1990, Black, 2001, Myers, ,3 Beizer, 1990, Hetzel, 1988, Myers, Hetzel, Black, 2001, Craig, Black, 2001, Hetzel, 1988 Version 2007 Side 21 af maj 2007

22 2. Test igennem hele softwarens livscyklus (K2) 115 minutter Undervisningsformål for test igennem hele softwarens livscyklus Formålene viser, hvad du skal kunne efter fuldførelse af hvert enkelt modul. 2.1 Softwareudviklingsmodeller (K2) Forstå sammenhængen mellem udvikling, testaktiviteter og arbejdsprodukter i udviklingslivscyklusen, og giv eksempler baseret på projekt- og produktegenskaber og kontekst K2) Vide at softwareudviklingsmodeller skal tilpasses projektets kontekst og produktegenskaberne. (K1) Husk baggrunden for forskellige testniveauer og egenskaber for en god test i enhver livscyklusmodel. (K1) 2.2 Testniveauer (K2) Sammenlign de forskellige testniveauer: hovedformål, typiske testobjekter, typiske testmål (f.eks. funktionel eller strukturel) og relaterede delprodukter, personer der tester, defekt- og afvigelsestyper, der skal findes. (K2) 2.3 Testtyper (K2) Sammenlign fire softwaretesttyper (funktionel, ikke-funktionel, strukturel og ændringsrelateret) med eksempler. (K2) Vide at funktionelle og strukturelle tests forekommer på alle testniveauer. (K1) Find og beskriv ikke-funktionelle testtyper, baseret på ikke-funktionelle krav. (K2) Find og beskriv testtyper, baseret på analysen af softwaresystemets struktur eller arkitektur. (K2) Beskriv formålet med gentest og regressionstest. (K2) 2.4 Vedligeholdelsestest (K2) Sammenlign vedligeholdelsestest (test af et eksisterende system) med test af et nyt program, hvad angår testtyper, testudløsere og testomfang. (K2) Angiv årsager til vedligeholdelsestest (ændring, konvertering og lukning). (K1) Beskriv den rolle regressionstest og effektanalyse har i vedligeholdelse. (K2) Version 2007 Side 22 af maj 2007

23 2.1 Softwareudviklingsmodeller (K2) 20 minutter Termer Commercial off-the-shelf (COTS), iterativ-inkrementel udviklingsmodel, testniveau, validering, verificering, V-model. Baggrund Test eksisterer ikke i isolation. Testaktiviteter er knyttet til softwareudviklingsaktiviteter. Forskellig udviklingslivscyklusmodeller kræver forskellige tilgange til test V-model (sekventiel udviklingsmodel) (K2) Skønt der findes forskellige V-modeller, anvender en almindelig V-modeltype fire testniveauer svarende til de fire udviklingsniveauer. De fire anvendte niveauer i denne syllabus er følgende: Komponent(unit-)test; Integrationstest; Systemtest Accepttest. Det betyder i praksis, at en V-model kan have flere, færre eller andre udviklingsniveauer, afhængig af projektet og softwareproduktet. Der kan f.eks. være komponentintegrationstest efter komponenttest, og systemintegrationstest efter systemtest. Softwarearbejdsprodukter (som f.eks. forretningsscenarier eller usecases, kravspecifikationer, designdokumenter og kode), der er produceret under udvikling, er ofte grundlag for test på et eller flere testniveauer. Referencer vedr. generiske arbejdsprodukter omfatter Capability Maturity Model Integration (CMMI) eller Softwarelivscyklusprocesser (IEEE/IEC 12207). Verificering og validering (og tidlig testdesign) kan udføres under udvikling af softwarearbejdsprodukterne Iterativ-inkrementelle udviklingsmodeller (K2) Iterativ-inkrementel udvikling er processen med etablering af krav, design, opbygning og test af et system, udført som en serie kortere udviklingscykler. Eksempler er: prototypefremstilling, rapid application development (RAD), Rational Unified Process (RUP) og agile udviklingsmodeller. Det endelige system, der er fremstilles i en iteration, kan testes på mange niveauer som en del af dets udvikling. Et inkrement, der føjes til andre, tidligere udviklede, danner et voksende delsystem, der også bør testes. Regressionstest bliver vigtigere og vigtigere i alle iterationerne efter den første. Verificering og validering kan udføres på hvert inkrement Test i en livscyklusmodel (K2) I enhver livscyklusmodel er der adskillige karakteristika for en god test: For hver udviklingsaktivitet er der en tilsvarende testaktivitet. Hvert testniveau har et testformål, der specifikt gælder for niveauet. Analyse og design af tests til et bestemt testniveau skal starte under den tilsvarende udviklingsaktivitet. Testere bør involveres i review af dokumenter, så snart udkast er tilgængelige i udviklingslivscyklusen. Version 2007 Side 23 af maj 2007

24 Testniveauer kan kombineres og omorganiseres alt efter projektets eller systemarkitekturens natur. Ved f.eks. integration af et kommercielt off-the-shelf (COTS)-softwareprodukt i et system, kan køberen udføre integrationstest på systemniveau (f.eks. integration til infrastruktur og andre systemer, eller anden systemanvendelse) og accepttest (funktionel og/eller ikke-funktionel og bruger og/eller driftstest). Version 2007 Side 24 af maj 2007

25 2.2 Testniveauer (K2) 40 minutter Termer Alfatest, betatest, komponenttest (også kendt som enheds-, modul- eller programtest), drivere, felttest, funktionelle krav, integration, integrationstest, ikke-funktionelle krav, regelaccepttest, robusthedstest, stubbe, systemtest, testdrevet udvikling, testmiljø, brugeraccepttest. Baggrund For hvert testniveau kan følgende identificeres: deres generiske formål, delprodukt(er) der refereres for udledning af testcases (dvs. testgrundlag), testobjekt (dvs. hvad der testes), typiske defekter og afvigelser, der skal findes, krav til testharness og værktøjsstøtte og specifikke metoder og ansvar Komponenttest (K2) Komponenttest søger efter defekter i og kontrollerer funktionen af software (f.eks. moduler, programmer, objekter, klasser etc.), der kan testes individuelt. Det kan gøres isoleret fra resten af systemet, afhængig af konteksten i udviklingslivscyklussen og systemet. Stubbe, drivere og simulatorer kan anvendes. Komponenttest kan indeholde test af funktionalitet og specifikke ikke-funktionelle egenskaber, f.eks. ressourceopførsel (f.eks. hukommelseslæk) eller robusthedstest såvel som strukturel test (f.eks. forgreningsdækning). Testcases tager udgangspunkt i arbejdsprodukter som f.eks. specifikation af komponenten, softwaredesignet eller datamodellen. Typisk foregår komponenttest med adgang til den kode, der testes og med støtte fra udviklingsmiljøet, som f.eks. en enhedstest-ramme eller et debugging-værktøj og involverer i praksis ofte den programmør, der skrev koden. Defekter rettes typisk, så snart de er fundet, uden formel hændelsesregistrering. En metode i komponenttest er at forberede og automatisere testcases før kodning. Det kaldes en test-først-metode eller testdrevet udvikling. Denne metode er meget iterativ og er baseret på cyklusser i udvikling af testcases, derpå fremstilling og integration af små stykker kode og afvikling af komponenttests, indtil de består Integrationstest (K2) Integrationstest tester grænseflader mellem komponenter, samspil med andre dele i et system, som f.eks. styresystem, filsystem, hardware eller grænseflader mellem systemer. Der kan være mere end et niveau af integrationstest, og det kan udføres på testobjekter af forskellig størrelse. F.eks.: Komponentintegrationstest tester samspillet mellem softwarekomponenter og udføres efter komponenttest. Systemintegrationstest tester samspillet mellem forskellige systemer og kan udføres efter systemtest. I dette tilfælde kan udviklingsorganisationen måske kun kontrollere den ene side af grænsefladen, så ændringer kan være destabiliserende. Forretningsprocesser, Version 2007 Side 25 af maj 2007

26 der er implementeret som arbejdsforløb kan involvere en række systemer. Problemer på tværs af platforme kan være store. Jo større omfang af integration er, jo sværere bliver det at isolere afvigelser til en specifik komponent eller et system, hvilket kan føre til øget risiko. Systematiske integrationsstrategier kan være baseret på systemarkitekturen (som f.eks. top-down og bottom-up), funktionelle opgaver, transaktionsprocesrækkefølger, eller andre system- eller komponentaspekter. For at reducere risikoen for at finde en defekt på et sent tidspunkt, bør integration normalt være inkrementel i stedet for big-bang. Test af specifikke ikke-funktionelle egenskaber(f.eks. performance) kan være indeholdt i integrationstest. Ved hvert integrationstrin koncentrerer testerne sig udelukkende om selve integrationen. Hvis de f.eks. integrerer et modul A med et modul B, er de interesseret i at teste kommunikationen mellem modulerne, ikke funktionaliteten af hvert enkelt modul. Der kan anvendes både funktionelle og strukturelle metoder. Ideelt set bør testere forstå arkitekturen og have indflydelse på integrationsplanlægningen. Hvis integrationstests planlægges før komponenter eller systemer er bygget, kan disse bygges i den rækkefølge, der er nødvendig for at opnå den mest effektive test Systemtest (K2) Systemtest drejer sig om den adfærd for systemet/produktet, der er defineret af omfanget af et udviklingsprojekt eller program. Ved systemtest bør testmiljøet så vidt muligt svare til det endelige mål- eller produktionsmiljø for at minimere risikoen for at miljøspecifikke afvigelser ikke findes ved test. Systemtest kan indeholde tests, der er baseret på risici og/eller kravspecifikationer, forretningsprocesser, usecases eller andre højniveaubeskrivelser af systemadfærd, samspil med styresystem og systemressourcer. Systemtest bør undersøge både funktionelle og ikke-funktionelle krav til systemet. Krav kan være tekst og/eller modeller. Testere skal også håndtere ufuldstændige eller udokumenterede krav. Systemtest af funktionelle krav starter med brug af de bedst egnede specifikationsbaserede teknikker (Black-box) for det aspekt af systemet, der skal testes. Der kan f.eks. dannes en beslutningstabel for kombinationer af de effekter, der er beskrevet i forretningsreglerne. Strukturbaserede teknikker (white-box) kan derefter anvendes til at vurdere grundigheden af testen vedrørende et strukturelement, som f.eks. menu-struktur eller webside-navigation. (Se Kapitel 4.) Systemtest udføres ofte af et uafhængigt testteam Accepttest (K2) Accepttest er ofte kundernes eller systembrugernes ansvar; andre interessenter kan også være involveret. Målet med accepttest er at skabe tillid til systemet, dele af systemet eller specifikke ikkefunktionelle egenskaber i systemet. Det er ikke hovedformålet med accepttest at finde defekter. Accepttest kan fastlægge systemets parathed til anvendelse og brug, skønt det ikke nødvendigvis Version 2007 Side 26 af maj 2007

27 er det sidste testniveau. Der kan f.eks. komme en stor-skala systemintegrationstest efter accepttesten af et system. Accepttest kan også forekomme som mere end blot et enkelt testniveau, f.eks.: Et COTS-softwareprodukt kan blive accepttestet, når det installeres eller integreres. Accepttest af en komponents brugervenlighed kan være udført under komponenttest. Accepttest af en ny funktionel forbedring kan komme før systemtest. Typiske former for accepttest indeholder følgende: Brugeraccepttest Verificerer typisk systemets brugsegnethed for virksomhedens brugere. Drifts(accept)test Systemadministratorernes accept af systemet, herunder: test af backup/gendan; katastrofegendannelse; brugerhåndtering; vedligeholdelsesopgaver; periodisk kontrol af sikkerhedssårbarhed. Kontrakt- og regelaccepttest Kontraktaccepttest udføres i forhold til en kontrakts acceptkriterier for fremstilling af kundetilpasset software. Acceptkriterierne bør være defineret, når aftalen indgås. Regelaccepttest udføres i forhold til de lovbestemmelser, der skal overholdes, som f.eks. statslige, retslige eller sikkerhedsmæssige lovbestemmelser. Alfa- og beta- (eller felt-)test Udviklere af markeds- eller COTS-software ønsker ofte at få feedback fra mulige eller eksisterende kunder på markedet, før et softwareprodukt frigives for kommercielt salg. Alfatest udføres hos udviklingsorganisationen. Betatest eller felttest udføres af personer på deres egne lokationer. Begge udføres af mulige kunder, ikke af produktudviklerne. Organisationer kan også bruge andre termer, som f.eks. fabriksaccepttest og accepttest på installationsstedet af systemer, der tidligere er testet og derefter flyttet til et en kundes lokation. Version 2007 Side 27 af maj 2007

28 2.3 Testtyper (K2) 40 minutter Termer Black-box-test, kodedækning, funktionel test, tværoperationalitetstest, loadtest, vedligeholdelsesegnethedstest, performancetest, flytbarhedstest, pålidelighedstest, sikkerhedstest, specifikationsbaseret test, stresstest, strukturel test, brugervenlighedstest, whitebox test. Baggrund En gruppe testaktiviteter kan have det formål at verificere softwaresystemet (eller en del af et system), baseret på en specifik grund eller testmål. En testtype er fokuseret på et bestemt testformål; det kunne være test af en funktion, der udføres af softwaren; en ikke-funktionel kvalitetsegenskab, som f.eks. pålidelighed eller brugervenlighed, strukturen eller arkitekturen af softwaren eller systemet, eller relateret til ændringer, dvs. bekræftelse af at defekter er rettet (gentest) og søgning efter utilsigtede ændringer (regressionstest). Der kan udvikles og/eller anvendes en softwaremodel i strukturel og funktionel test. F.eks. i funktionel test en procesflowmodel, en tilstandsovergangsmodel eller en almindelig sprogspecifikation; og til strukturel test en kontrolflowmodel eller menustrukturmodel Test af funktion (funktionstest) (K2) De funktioner, som et system, undersystem eller en komponent, skal udføre, kan være beskrevet i arbejdsprodukter, som f.eks. kravspecifikation, usecases, en funktionel specifikation, eller de kan være udokumenterede. Funktionerne er hvad systemet gør. Funktionelle tests er baseret på funktioner og egenskaber (beskrevet i dokumenter eller forstået af testerne), og deres interoperalitet med specifikke systemer, og de kan udføres på alle testniveauer (f.eks. kan tests til komponenter være baseret på en komponentspecifikation). Specifikationsbaserede teknikker kan bruges til at udlede testbetingelser og testcases fra funktionaliteten af softwaren eller systemet. (Se Kapitel 4.) Funktionel test tager softwarens eksterne adfærd i betragtning (black-box-test). En type af funktionel test, sikkerhedstest, undersøgelser de funktioner (f.eks. firewall), der er relateret til opdagelse af trusler, som f.eks. vira, fra ondsindede personer udefra. En anden type funktionel test, interoperationel test, evaluerer softwarens evne til at interagere med en eller flere udvalgte componenter eller systemer Test af ikke-funktionelle softwareegenskaber (ikke-funktionel test) (K2) Ikke-funktionel testomfatter, men er ikke begrænset til, performancetest, loadtest, stresstest, brugervenlighedstest, vedligeholdelsesegnethedstest, pålidelighedstest og flytbarhedstest. Det er testen, der viser, hvordan systemet fungerer. Ikke-funktionel test kan udføres på alle testniveauer. Ordet ikke-funktionel test beskriver de tests, der er nødvendige for at måle de system- og softwareegenskaberne, der kan opgøres mængdemæssigt på en variabel skala, som f.eks. svartid for performancetest. Disse tests kan Version 2007 Side 28 af maj 2007

29 henvise til en kvalitetsmodel, som f.eks. den der er defineret i Software Engineering Software Product Quality (ISO 9126) Test af softwarestruktur/-arkitektur (strukturel test) (K2) Strukturel (white-box) test kan udføres på alle testniveauer. Strukturelle teknikker anvendes bedst efter specifikationsbaserede teknikker, for at hjælpe med måling af testens grundighed via fastlæggelse af dækning af en strukturtype. Dækning er det omfang en struktur er blevet berørt af en sekvens af testcases, udtrykt som en procentdel af de elementer, der er dækket. Hvis dækningen ikke er 100 %, kan der designes flere tests til at teste de elementer, der manglede og dermed øge dækningen. Dækningsteknikker er beskrevet i Kapitel 4. På alle testniveauer og især ved komponenttest og komponentintegrationstest kan værktøjer anvendes til måling af dækning af kodeelementer, som f.eks. instruktioner eller beslutninger. Strukturel test kan være baseret på systemets arkitektur, som f.eks. et kalde-hierarki. Strukturelle testmetoder kan også anvendes ved system-, systemintegrations- eller accepttest - niveauer (f.eks. til forretningsmodeller eller menustrukturer) Test i forbindelse med ændringer (bekræftelsestest (gentest) og regressionstest) (K2) Efter en defekt er registreret og rettet, bør softwaren testes igen for at få bekræftet, at den oprindelige defekt er fjernet korrekt. Dette kaldes gentest. Debugging (defektrettelse) er en udviklingsaktivitet, ikke en testaktivitet. Regressionstest er en gentagelse af testen af et allerede testet program, efter der har været foretaget en ændring, for at finde ud af om der er opstået eller afdækket nogle defekter som følge af ændringen/ændringerne. Disse defekter kan være i softwaren der testes eller i en anden relateret eller urelateret softwarekomponent. Den udføres, når softwaren eller miljøet ændres. Omfanget af en regressionstest er baseret på risikoen, der er ved ikke at finde defekter i software, der fungerede tidligere. Tests bør være repeterbare, hvis de skal anvendes til gentest og til støtte for regressionstest. Regressionstest kan udføres på alle testniveauer gælder for funktionel, ikke-funktionel og strukturel test. Regressionssekvenser af testcases køres mange gange og udvikler sig normalt langsomt, så regressionstest er en god automatiseringskandidat. Version 2007 Side 29 af maj 2007

30 2.4 Vedligeholdelsestest (K2) 15 minutter Termer Effektanalyse, vedligeholdelsestest. Baggrund Når et softwaresystem først er taget i brug, anvendes det ofte i mange år eller årtier. I denne periode bliver systemet og dets omgivelser ofte rettet, ændret eller udvidet. Vedligeholdelsestest udføres på et eksisterende styresystem, og udløses af ændringer, flytning eller lukning af softwaren eller systemet. Ændringer omfatter planlagte forbedringsændringer (f.eks. release-baserede), rettelses- og nødændringer, og ændringer i omgivelserne, som f.eks. planlagt opgradering af styresystem eller database, eller patches for en nylig funden eller konstateret sårbarhed i styresystemet. Vedligeholdelsestest for flytning (f.eks. fra en platform til en anden) bør indeholde driftstests af det nye miljø, såvel som af den ændrede software. Vedligeholdelsestest ved lukning af et system kan indeholde test af dataflytning eller arkivering, hvis der er tale om en lang dataopbevaringsperiode. Ud over at teste, hvad der er ændret, så indeholder vedligeholdelsestest også omfattende regressionstest af de dele af systemet, der ikke er ændret. Omfanget af vedligeholdelsestest hænger sammen med risikoen ved ændringen, størrelsen af det eksisterende system og størrelsen af ændringen. Afhængigt af ændringerne kan vedligeholdelsestest udføres på et hvilket som helst eller alle testniveauer for en hvilken som helst eller alle testtyper. Bestemmelsen af hvordan det eksisterende system kan blive påvirket af ændringer kaldes en effektanalyse, og den anvendes til at hjælpe med bestemmelse af, hvor meget regressionstest der skal udføres. Vedligeholdelsestest kan være svært, hvis specifikationerne ikke er opdaterede eller mangler. Referencer CMMI, Craig, 2002, Hetzel, 1988, IEEE Hetzel, Copeland, 2004, Myers, Beizer, 1990, Black, 2001, Copeland, Black, 2001, ISO Beizer, 1990, Copeland, 2004, Hetzel, Hetzel, 1988, IEEE Black, 2001, Craig, 2002, Hetzel, 1988, IEEE 829 Version 2007 Side 30 af maj 2007

31 3. Statiske teknikker (K2) 60 minutter Undervisningsmål for statiske teknikker Formålene viser, hvad du skal kunne efter fuldførelse af hvert enkelt modul. 3.1 Statiske teknikker og testproces (K2) Kende softwarearbejdsprodukter, der kan undersøges ved hjælp af forskellige statiske teknikker. (K1) Beskrive vigtigheden og værdien af at overveje statiske teknikker til vurdering af softwarearbejdsprodukter. (K2) Forklare forskellen mellem statiske og dynamiske teknikker. (K2) Beskrive formålet for statiske analyser og review, og sammenligne dem med dynamisk test. (K2) 3.2 Reviewproces (K2) Huske faser, roller og ansvar for et typisk formelt review. (K1) Forklare forskellen mellem forskellige reviewtyper: uformelt review, teknisk review, walkthrough og inspektion. (K2) Forklare faktorer for en vellykket review-gennemførsel. (K2) 3.3 Statisk analyse med værktøjer (K2) Huske typiske defekter og fejl, der findes ved statisk analyse, og sammenligne dem med reviews og dynamisk test. (K1) Opliste typiske fordele ved statisk analyse. (K1) Opliste typiske kode- og designdefekter, der kan findes med statisk analyseværktøjer. (K1) Version 2007 Side 31 af maj 2007

32 3.1 Statiske teknikker og testproces (K2) 15 minutter Termer Dynamisk test, statisk test, statisk teknik. Baggrund Til forskel fra dynamisk test, som kræver afvikling af software, afhænger statisk test af den manuelle gennemgang (review) og automatiserede analyse (statisk analyse) af koden eller anden projekt dokumentation. Reviews er en måde at teste softwarearbejdsprodukter (herunder kode) og kan udføres længe før afvikling af dynamisk test. Defekter, der findes under reviews tidligt i livscyklus, er ofte meget billigere at fjerne end de der findes ved afvikling af tests (f.eks. defekter, der findes i krav). Et review kan udføres som en helt manuel aktivitet, men der findes også værktøjsstøtte. Den vigtigste manuelle aktivitet er at undersøge et arbejdsprodukt og lave kommentarer til det. Alle softwarearbejdsprodukter kan gennemgås, herunder kravspecifikationer, designspecifikationer, kode, testplaner, testspecifikationer, testcases, testscripts, brugervejledninger og websider. Fordele ved reviews omfatter tidlig fejlfinding og rettelse, forbedringer i udviklingseffektivitet, reduceret udviklingstid, reducerede testudgifter og tid, reduktioner i livstidsomkostninger, færre defekter og forbedret kommunikation. Reviews kan finde mangler, f.eks. i kravene, det ellers ikke er sandsynligt at finde ved dynamisk test. Reviews, statisk analyse og dynamisk test har samme formål at finde defekter. De er komplementerende: de forskellige teknikker kan på en effektiv måde finde forskellige defekttyper. Sammenlignet med dynamisk test, finder statisk teknik snarere grundende til fejl (defekter) end selve fejlen. Typiske defekter, der er lettere at finde ved reviews end ved dynamisk test er: afvigelser fra standarder, kravdefekter, designdefekter, utilstrækkelig vedligeholdelsesegnethed og ukorrekte grænseflade-specifikationer. Version 2007 Side 32 af maj 2007

33 3.2 Reviewproces (K2) 25 minutter Termer Indgangskriterier, formelt review, uformelt review, inspektion, metrikker, moderator/ inspektionsleder, kollegareview, reviewer, referent, teknisk review, walkthrough. Baggrund De forskellige typer review varierer fra meget uformelle (f.eks. uden skriftlig vejledning til reviewerne) til meget formelle (dvs. velstruktureret og regelbundet). Formaliteten af en reviewproces er relateret til faktorer som f. eks. modenhed i udviklingsprocessen, eventuelle juridiske eller lovregulerede krav eller behovet for et audit-spor. Måden, som et review udføres på, afhænger af det aftalte formål med reviewet (f.eks. at finde defekter, at opnå forståelse eller diskussion og konsensus om beslutning) Faser ved et formelt review (K1) Et typisk formelt review har følgende hovedfaser: Planlægning: valg af personale, tildeling af roller, definition af indgangs- og udgangskriterier for mere formelle reviewtyper (f.eks. inspektion).og valg af hvilke dele af dokumenter, der skal undersøges. Kick-off: fordeling af dokumenter, forklaring af formål, proces og dokumenter til deltagere, og kontrol af indgangskriterier (for mere formelle reviewtyper). Individuel forberedelse: arbejde udført af hver af deltagerne før reviewmødet, hvor de noterer mulige defekter, spørgsmål og bemærkninger. Reviewmøde: diskussion eller logging med dokumenterede resultater eller referater (for mere formelle reviewtyper). Mødedeltagerne kan blot notere defekter, lave anbefalinger til håndtering af defekter eller træffe beslutninger om defekterne. Gen-bearbejdning: rette fundne defekter, udføres typisk af ophavsmanden. Opfølgning: kontrol af at der er gjort noget ved defekterne, indsamling af metrikker og kontrol af udgangskriterier (ved mere formelle reviewtyper) Roller og ansvar (K1) Et typisk formelt review indeholder følgende roller: Manager: bestemmer udførelsen af reviews, tildeler tid i projektplaner og fastslår, om målet med reviewet er nået. Moderator: den person, der leder review af dokumentet eller dokumentsættet, herunder planlægning af review, afvikling af mødet og opfølgning efter mødet. Om nødvendigt kan moderatoren mægle mellem de forskellige synspunkter og er ofte den person, der bærer ansvaret for reviewets succes. Ophavsmand: forfatteren eller den hovedansvarlige person for de(t) dokument(er), der skal reviewes. Reviewer: personer med en specifik teknisk eller forretningsmæssig baggrund (også kaldet checkere eller inspektorer) der, efter den nødvendige forberedelse, finder og beskriver observationer (f.eks. defekter) i det undersøgte produkt. Reviewer bør vælges, Version 2007 Side 33 af maj 2007

34 så de repræsenterer forskellige perspektiver og roller i reviewprocessen, og de bør deltage i eventuelle reviewmøder. Referent (eller recorder): dokumenterer alle observationer, problemer og åbne punkter, der blev berørt under mødet. Ved at se på dokumenter fra en anden vinkel og anvende checklister, kan reviews gøres mere effektive, f.eks. en checkliste, der er baseret på perspektiver som bruger, vedligeholder, tester eller drift, eller en checkliste med typiske kravproblemer Reviewtyper (K2) Et enkelt dokument kan være genstand for mere end et review. Hvis der anvendes mere end en type review kan rækkefølgen variere. Der kan f.eks. udføres et uformelt review før et teknisk review, eller der kan udføres en inspektion af en kravspecifikation før en walkthrough med kunder. Hovedegenskaber, muligheder og formål for almindelige reviewtyper er: Uformelt review Nøgleegenskaber: ingen formel proces; der kan være parprogrammering eller en teknisk leder, der reviewer design og kode; kan eventuelt dokumenteres; kan variere i brugbarhed afhængig af revieweren; hovedformål: billig måde at opnå et udbytte på. Walkthrough Nøgleegenskaber: møde ledet af ophavsmand; scenarier, dry runs, kollegagruppe; ubegrænsede sessioner; eventuelt et formøde til forberedelse af reviewer, reviewrapport, liste over resultater og referent (som ikke er ophavsmand) kan variere i praksis fra meget uformel til meget formel; hovedformål: læring, opnå forståelse, finde defekter Teknisk review Nøgleegenskaber: dokumenteret, defineret defekt-findings-proces, der indbefatter kollegaer og tekniske eksperter kan udføres som kollegareview uden deltagelse af ledelsen; ledes ideelt set af en uddannet moderator (ikke ophavsmanden); forberedelse ved formøde; eventuelt brug af checklister, reviewrapport, liste over resultater og ledelsesdeltagelse; kan variere i praksis fra meget uformel til meget formel; hovedformål: diskutere, træffe beslutninger, evaluere alternativer, finde defekter, løse tekniske problemer og kontrollere overensstemmelse med specifikationer og standarder. Inspektion Nøgleegenskaber: ledes af en uddannet moderator (ikke ophavsmanden); sædvanligvis eksamination udført af kollegaer; Version 2007 Side 34 af maj 2007

35 definerede roller; inklusiv metrikker;. formel proces baseret på regler og checklister med indgangs- og udgangskriterier; forberedelse ved formøde; inspektionsrapport, liste med observationer; formel opfølgningsproces. eventuel procesforbedring og læser; hovedformål: at finde defekter. Walkthroughs, tekniske review og inspektioner kan udføres af en ligeværdig kollegagruppe på samme organisatoriske niveau. Denne type review kaldes et kollegareview Succesfaktorer for reviews (K2) Succesfaktorer for reviews indbefatter: Hvert review har et klart forud defineret formål. De rigtige personer i forhold til reviewformål er involveret. De fundne defekter er velkomne og formuleret objektivt. Personlige emner og psykologiske aspekter håndteres (ved f.eks at gøre det til en positiv oplevelse for ophavsmanden). Den anvendte reviewteknik er velegnet til både type og niveau af softwarearbejdsprodukter og reviewere. Checklister eller roller anvendes, hvis de kan medvirke til at øge effektiviteten ved identifikation af defekter. Der gives undervisning i reviewteknik, især de mere formelle teknikker, som f.eks. inspektion. Ledelsen støtter en god reviewproces (f.eks. ved at indarbejde passende tid til reviewaktiviteter i projektplanerne). Der er lagt vægt på læring og procesforbedring. Version 2007 Side 35 af maj 2007

36 3.3 Statisk analyse vha. værktøjer (K2) 20 minutter Termer Oversætter, kompleksitet, kontrolflow, dataflow, statisk analyse. Baggrund Formålet ved statisk analyse er at finde defekter i softwarekildekoden og softwaremodellerne. Statisk analyse udføres uden egentlig eksekvering af den software, der undersøges vha. værktøjet; dynamisk test eksekverer softwarekoden. Statisk analyse kan lokalisere defekter, der er svære at finde ved test. Som ved reviews finder statiske analyser defekter snarere end afvigelser. Statiske analyseværktøjer analyserer programkode (f.eks. kontrolflow og dataflow), såvel som genereret output som f.eks. HTML og XML. Værdien ved statisk analyse er: Tidlig opdagelse af defekter forud for afvikling af test Tidlig advarsel om mistænkelige aspekter i kode eller design, som f.eks. et højt kompleksitetstal, vha. beregning af metriker. Identifikation af defekter, der ikke så let findes ved dynamisk test. Opdagelse af afhængigheder og inkonsistenser i softwaremodeller som f.eks. links. Forbedret vedligeholdelsesegnethed af kode og design. Forebyggelse af defekter, hvis der er taget ved lære af udviklingen. Typiske defekter fundet ved statiske analyseværktøjer indbefatter: reference til en variabel med en udefineret værdi; inkonsistent grænseflade mellem moduler og komponenter; variable, der aldrig anvendes; utilgængelig (død) kode; overtrædelse af programmeringsstandarder; sikkerhedssårbarheder; syntaksovertrædelser i kode og softwaremodeller. Statiske analyseværktøjer anvendes typisk af udviklere (der kontrollerer i forhold til fastlagte regler og programmeringsstandarder) før og under komponent- og integrationstest og af designere under softwaremodelarbejdet. Statiske analyseværktøjer kan give et stort antal advarselsmeddelelser, der skal styres godt for at få det største udbytte af værktøjet. Oversættere kan tilbyde noget støtte til statisk analyse, herunder beregning af metrikker. Referencer 3.2 IEEE Gilb, 1993, van Veenendaal, Gilb, 1993, IEEE Van Veenendaal, 2004 Version 2007 Side 36 af maj 2007

37 4. Testdesignteknik (K3) 285 minutter Undervisningsmål for testdesignteknik Formålene viser, hvad du skal kunne efter fuldførelse af hvert enkelt modul. 4.1 Testudviklingsprocessen (K2) Skelne mellem en testdesign-specifikation, testcase-specifikation og en testprocedurespecifikation(k2) Sammenligne termerne testbetingelse, testcase og testprocedure(k2) Evaluere kvaliteten af testcase. o der viser tydelig sporbarhed til kravene; o der indeholder et forventet resultat. (K2) Oversætte testcases til en velstruktureret testprocedurespecifikation på et detaljeniveau, der er relevant i forhold til testernes viden(k3) 4.2 Kategorier af testdesignteknik (K2) Huske årsager til at både specifikationsbaserede (black-box) og strukturbaserede (whitebox) metoder til testcasedesign er nyttige, og opliste de almindelige teknikker for hver(k1) Forklare egenskaber og forskelle mellem specifikationsbaseret test, strukturbaseret test og erfaringsbaseret test(k2) 4.3 Specifikationsbaserede eller black-box-teknikker (K3) Skrive testcases fra givne softwaremodeller vha. følgende testdesignteknikker: (K3) o ækvivalenspartitionering;. o grænseværdianalyse; o beslutningstabeltest. o tilstandsovergangstest Forstå hovedformålet med hver af de fire teknikker, hvilket testniveau og -type, der kunne bruge teknikken, og hvordan dækning kan måles(k2) Forstå konceptet af usecase test og fordelene herved(k2) 4.4 Strukturbaseret eller white-box-teknikker (K3) Beskrive konceptet og vigtigheden af kodedækning(k2) Forklare koncepter for instruktions- og beslutningsdækning og forstå, at disse koncepter også kan anvendes på andre testniveauer end komponenttest (f.eks. for forretningsprocedurer på systemniveau)(k2) Skrive testcases fra givne kontrolflows vha. følgende testdesignteknikker: (K3) o instruktionstest. o beslutningstest Vurdere fuldstændigheden af instruktions- og beslutningsdækning(k3) 4.5 Erfaringsbaserede teknikker (K2) Huske årsager til skrivning af testcases baseret på intuition, erfaring og kendskab til almindelige defekter(k1) Sammenligne erfaringsbaserede teknikker med specifikationsbaserede testteknikker(k2) Version 2007 Side 37 af maj 2007

38 4.6 Valg af testteknik (K2) Opliste de faktorer, der påvirker valget af den passende testdesignteknik til en bestemt problemtype, som f.eks. systemtype, risiko, kundekrav, modeller til usecase-modellering, kravmodeller og testerkendskab(k2) Version 2007 Side 38 af maj 2007

39 4.1 Testudviklingsprocessen (K2) 15 minutter Termer Testcase-specifikation, testdesign, testafviklingsrækkefølge, testprocedure-specifikation, testscript, sporbarhed. Baggrund Processen, beskrevet i dette afsnit, kan udføres på flere måder, fra meget uformel med lidt eller ingen dokumentation til meget formel (som den er beskrevet herunder). Formalitetsniveauet afhænger af konteksten for testen, herunder organisationen, testmodenhed og udviklingsprocesser, tidsbegrænsninger og de involverede personer. Ved testanalyse analyseres testbasisdokumentationen for at bestemme, hvad der skal testes, dvs. for at identificere testbetingelserne. En testbetingelse er defineret som et element eller en hændelse, der kan verificeres af en eller flere testcases (f.eks. en funktion, transaktion, kvalitetsegenskab eller et strukturelt element). Ved at etablere sporbarhed fra testbetingelser tilbage til specifikationerne og kravene muliggøres både effektanalyse, når kravene ændres, og bestemmelse af kravsdækningen for et sæt af tests. Ved testanalyse bliver den detaljerede testtilgang implementeret for at vælge den testdesignteknik som skal bruges, baseret på, blandt andre overvejelser, på identificerede risici (se Kapitel 5 for flere oplysninger om risikoanalyse). Ved testdesign bliver testcases og testdata dannet og specificeret. En testcase består af et sæt inputværdier, afviklings-startbetingelser, forventede resultater og afviklings-post-betingelser, udviklet til at dække en eller flere bestemte testbetingelser. Standard for Software Test Dokumentation (IEEE 829) beskriver indholdet af testdesign-specifikationer (indeholdende testkrav) og testcase-specifikationer. Forventede resultater bør fremstilles som en del af specifikationen af en testcase og indeholde outputs, ændringer i data og tilstande og andre eventuelle konsekvenser af testen. Hvis der ikke er defineret nogle forventede resultater, så kan et sandsynligt, men fejlagtigt resultat måske fortolkes som et korrekt. Forventede resultater bør ideelt defineres forud for testafviklingen. Under testimplementering er testcases udviklet, implementeret, prioriteret og organiseret i testprocedurespecifikationen. Testproceduren (eller det manuelle testscript) specificerer rækkefølgen af handlinger for afviklingen af en test. Hvis tests køres vha. et testafviklingsværktøj, bliver rækkefølgen af handlinger specificeret i et testscript (der er en automatiseret testprocedure). De forskellige testprocedurer og automatiserede testscripts bliver efterfølgende omdannet til en testafviklingsplan, der definerer rækkefølgen, som de forskellige testprocedurer og eventuelle automatiserede testscripts afvikles i, når de skal udføres, og af hvem de udføres. Testafviklingsplanen medtager faktorer som regressionstests, prioritering og tekniske og logiske afhængigheder. Version 2007 Side 39 af maj 2007

40 4.2 Kategorier af testdesignteknikker (K2) 15 minutter Termer Black-box testdesignteknikker, erfaringsbaserede testdesignteknikker, specifikationsbaserede testdesignteknikker, strukturbaserede testdesignteknikker, white-box testdesignteknikker. Baggrund Formålet med en testdesignteknik er at identificere testbetingelser og testcases. Det er en klassisk skelnen at angive testteknikker som black-box eller white-box. Black-box teknikker:(som også indeholder specifikationsbasere- og erfaringsbaseredeteknikker) er en måde at udlede og vælge testbetingelser eller testcases baseret på en analyse af dokumentationen for testgrundlaget og erfaringen fra udviklere, testere og brugere, hvad enten det er funktionelt eller ikke-funktionelt, for en komponent eller et system uden reference til dets struktur. White-box-teknik (også kaldet strukturelle eller strukturbaserede teknikker) er baseret på en analyse af den interne struktur af en komponent eller et system. Nogle teknikker falder helt klart i en enkelt kategori; andre har elementer af flere kategorier. Denne syllabus refererer til specifikationsbaserede eller erfaringsbaserede metoder som black-boxteknikker og strukturbaseret som white-box-teknikker. Almindelige egenskaber for specifikationsbaserede teknikker: Modeller, enten formelle eller uformelle, anvendes til specifikation af det problem, der skal løses, af softwaren eller af komponenterne. Fra disse modeller kan der systematisk udledes testcases. Almindelige egenskaber for strukturbaserede teknikker: Oplysninger om hvordan softwaren er konstrueret anvendes til at udlede testcases, f.eks. kode og design. Omfanget af dækning af softwaren kan måles ud fra eksisterende testcases, og der kan systematisk udledes testcases for at øge dækningen. Almindelige egenskaber for erfaringsbaserede teknikker: Personers kendskab og erfaring anvendes til at udlede testcases. o testeres, udvikleres, brugeres og andre interessenter kendskab til softwaren, dens anvendelse og dets omgivelser. o kendskab til sandsynlige defekter og deres fordeling. Version 2007 Side 40 af maj 2007

41 4.3 Specifikationsbaserede eller black-boxteknikker (K3) 150 minutter Termer Grænseværdianalyse, beslutningstabeltest, ækvivalenspartitionering, tilstandsovergangstest, usecase test Ækvivalenspartitionering (K3) Input til softwaren eller systemet er opdelt i grupper, der forventes at have samme opførsel, så det er sandsynligt, at de bliver behandlet på samme måde. Ækvivalenspartitioner (eller klasser) kan findes for både gyldig og ugyldig data, dvs. værdier der bør afvises. Partitioner kan også identificeres for output, interne værdier, tidsrelaterede værdier (f.eks. før eller efter en hændelse) og for grænsefladeparametre (f.eks. under integrationstest). Tests kan designes til at dække partitioner. Ækvivalenspartitionering (ÆP)kan anvendes på alle testniveauer. Ækvivalenspartitionering som teknik kan anvendes til at opnå input- og outputdækning. Den kan anvendes til input fra mennesker, input via grænseflader til et system eller grænsefladeparametre i integrationstest Grænseværdianalyse (K3) Det er mest sandsynligt, at adfærd på kanten af hver ækvivalenspartition bliver forkert, så grænser er et område, hvor test kan forventes at afsløre defekter. Maksimum- og minimumværdierne for en partition er dens grænseværdier. En grænseværdi for en gyldig partition er en gyldig grænseværdi; grænseværdien for en ugyldig partition er en ugyldig grænseværdi. Der kan designes tests til at dække både gyldige og ugyldige grænseværdier. Når der designes testcases, vælges en test på hver grænseværdi. Grænseværdianalyse kan anvendes på alle testniveauer. Den er relativt let at anvende, og dens defektfindings-kapacitet er høj; detaljerede specifikationer er nyttige. Denne teknik betragtes ofte som en forlængelse af ækvivalenspartitionering. Den kan anvendes på ækvivalensklasser for brugerinput på skærmen, såvel som f.eks. på tidsgrænser (f.eks. time out, krav til transaktionshastigheder) eller tabelintervaller (f.eks. tabelstørrelsen er 256*256). Grænseværdier kan også anvendes til udvælgelse af testdata Test af beslutningstabel (K3) Beslutningstabeller er en god måde at fange systemkrav, der indeholder logiske betingelser, og til at dokumentere internt systemdesign. De kan anvendes til at registrere komplekse forretningsregler, som et system skal implementere. Specifikationen analyseres, og betingelser og systemhandlinger identificeres. Inputbetingelserne og handlingerne er ofte angivet på en sådan måde, at de enten kan være sande eller falske (Boolean). Beslutningstabellen indeholder også udløsende betingelser, ofte kombinationer af sand og falsk for alle inputbetingelser og deraf følgende handlinger for hver betingelseskombination. Hver kolonne på tabellen svarer til en forretningsregel, der definerer en unik kombination af betingelser, der medfører afvikling af de handlinger, der hænger sammen med reglen. Den dækningsstandard, der normalt anvendes sammen med en beslutningstabeltest, er at have mindst en test pr. kolonne, hvilket typisk involverer dækning af alle kombinationer af udløsende betingelser. Version 2007 Side 41 af maj 2007

42 Styrken ved beslutningstabeltest er, at den danner betingelseskombinationer, der måske ellers ikke var blevet afviklet under test. Den kan anvendes i alle situationer, når softwarens handling afhænger af adskillige logiske beslutninger Tilstandsovergangstest (K3) Et system kan udvise forskellige reaktioner afhængig af aktuelle betingelser eller tidligere historie (dets tilstand). I dette tilfælde kan dette systemaspekt vises som et diagram over tilstandsovergang. Testeren får mulighed for at betragte softwaren som tilstande, overgange mellem tilstande, input eller hændelser der udløser tilstandsændringer (overgange) og handlinger, der kan være resultatet af disse overgange. Tilstandene i systemet eller genstanden under test er adskilte, kan identificeres og findes i begrænset antal. En tilstandstabel viser sammenhængen mellem tilstande og input og kan fremhæve mulige overgange, der er ugyldige. Tests kan designes til at dække en typisk rækkefølge af tilstande, til at dække hver eneste tilstand, til at aktivere alle overgange, til at aktivere specifikke rækkefølger af overgange eller til at teste ugyldige overgange. Tilstandsovergangstest anvendes meget i den indlejrede softwareindustri og teknisk automatisering generelt. Teknikken er også velegnet til at modellere et forretningsobjekt, der har specifikke tilstande eller til test af skærm-dialog-flows (f.eks. til internetprogrammer eller forretningsscenarier) Usecase test (K2) Tests kan specificeres fra usecases eller forretningsscenarier. En usecase beskriver samspillet mellem aktører, herunder bruger og systemet, der giver et værdiresultat til en systembruger. Hver usecase har startbetingelser, der skal opfyldes for at en usecase fungerer korrekt. Hver usecase afsluttes med post-betingelser, der er de observerbare resultater og den endelige systemtilstand efter at usecasen er fuldført. En usecase har sædvanligvis et almindeligt (dvs. mest sandsynligt) scenarium og nogle gange alternative forgreninger. Usecases beskriver proces-flow gennem et system baseret på dets sandsynlige faktiske anvendelse, så testcases, der tager udgangspunkt i usecases, er de bedste til at afdække defekter i det virkelige proces-flow. Usecases, der ofte refereres til som scenarier, er meget nyttige til design af accepttests med deltagelse af kunde/bruger. De hjælper også med til at afdække integrationsdefekter, der er forårsaget af samspil og interferens mellem forskellige komponenter, og som individuel komponenttest ikke ville se. Version 2007 Side 42 af maj 2007

43 4.4 Strukturbaseret eller white-box-teknikker (K3) 60 minutter Termer Kodedækning, beslutningsdækning, instruktionsdækning, strukturbaseret test. Baggrund Strukturbaseret test/white-box test er baseret på en identificeret struktur i softwaren eller systemet, som det fremgår af følgende eksempler: Komponentniveau: Strukturen er den, der er i selve koden, dvs. instruktioner, beslutninger eller forgreninger. Integrationsniveau: Strukturen kan være et kaldetræ (et diagram, hvor moduler kalder andre moduler). Systemniveau: Strukturen kan være en menustruktur, forretningsproces- eller en websidestruktur. I dette afsnit behandles to koderelaterede strukturteknikker til kodedækning baseret på instruktioner og beslutninger. Til beslutningstest kan der anvendes et kontrolflow-diagram til at visualisere alternativer for hver beslutning Instruktionstest og dækning (K3) Ved komponenttest er instruktionsdækning en fastlæggelse af den procentdel af eksekverbare instruktioner, der er aktiveret af et testcasesæt. Instruktionstest udleder test cases til afvikling af specifikke instruktioner, normalt for at øge instruktionsdækning Beslutningstest og dækning (K3) Beslutningsdækning, der er relateret til forgreningstest, er fastlæggelse af procentdelen af beslutningsresultat (f.eks. Sand eller Falsk mulighederne i en IF-instruktion), der er aktiveret af et testcasesæt. Beslutningstest udleder testcases til afvikling af specifikke beslutningsresultater, normalt for at øge beslutningsdækning. Beslutningstest er en form for kontrolflow-test, da den genererer et specifikt kontrolflow gennem beslutningspunkter. Beslutningsdækning er stærkere end instruktionsdækning: 100 % beslutningsdækning garanterer 100 % instruktionsdækning, men ikke vice versa Andre strukturbaserede teknikker (K1) Der findes stærkere niveauer af strukturel dækning ud over beslutningsdækning, f.eks. betingelsesdækning og multibetingelsesdækning. Dækningskonceptet kan også anvendes på andre testniveauer (f.eks. på integrationsniveau), hvor procentdelen af moduler, komponenter eller klasser, der er blevet aktiveret af et testcasesæt, kan udtrykkes som modul-, komponent- eller klassedækning. Værktøjsstøtte er nyttig til strukturel test af kode. Version 2007 Side 43 af maj 2007

44 4.5 Erfaringsbaserede teknikker (K2) 30 minutter Termer Udforskende test, fejlangreb. Baggrund Erfaringsbaseret test er hvor tests udledes ud fra testernes evner, intuition og erfaring med lignende programmer og teknologier. Anvendt til at øge værdien at systematiske teknikker kan disse teknikker være nyttige til at identificere specielle tests, der ikke så let fanges af formelle teknikker, især når den anvendes efter mere formelle tilgange. Imidlertid kan effektiviteten af denne teknik variere voldsomt afhængigt af testernes erfaringer. En almindelig brugt erfaringsbaseret teknik er fejlgætning. Almindeligvis forudser testere fejl på baggrund af deres erfaring. En struktureret tilgang til fejlgætningsteknikken er opstilling af en liste over mulige fejl og design af tests, der angriber disse fejl. Denne systematiske tilgang kaldes fejlangreb. Disse lister over defekter og afvigelser kan opbygges på basis af erfaring, tilgængelig defekt- og afvigelsesdata og fra almindeligt kendskab til, hvorfor der opstår fejl i software. Udforskende test er samtidig testdesign, testafvikling, testlogning og læring, baseret på et testcharter, der indeholder testformål, og den udføres i tidsbokse. Det er en tilgang, der er mest nyttig, hvor der kun er få eller utilstrækkelige specifikationer og et stort tidspres, eller til at øge værdien af eller komplementere mere formel test. Den kan tjene som kontrol af testprocessen for at hjælpe med at sikre, at de mest alvorlige defekter findes. Version 2007 Side 44 af maj 2007

45 4.6 Valg af testteknikker (K2) 15 minutter Termer Ingen specifikke termer. Baggrund Valget af hvilke testteknikker, der skal anvendes, afhænger af forskellige faktorer, herunder systemtypen, regulerede standarder, kunde- eller kontraktkrav, risikoniveau, risikotype, testformål, tilgængelig dokumentation, testernes kendskab, tid og budget, udviklingslivscyklus, usecasemodeller og tidligere erfaring med fundne defekttyper. Nogle teknikker er bedre i bestemte situationer og til bestemte testniveauer; andre kan anvendes på alle testniveauer. Referencer 4.1 Craig, 2002, Hetzel, 1988, IEEE Beizer, 1990, Copeland, Copeland, 2004, Myers, Copeland, 2004, Myers, Beizer, 1990, Copeland, Beizer, 1990, Copeland, Copeland, Beizer, 1990, Copeland, Kaner, Beizer, 1990, Copeland, 2004 Version 2007 Side 45 af maj 2007

46 5. Teststyring (K3) 170 minutter Undervisningsformål for teststyring Formålene viser, hvad du skal kunne efter fuldførelse af hvert enkelt modul Testorganisation (K2) Kende til vigtigheden af uafhængig test. (K1) Opliste fordele og ulemper ved uafhængig test i en organisation. (K2) Kende de forskellige teammedlemmer, der skal overvejes ved oprettelse af et testteam. (K1). Huske typiske testleder- og testeropgaver. (K1) 5.2. Testplanlægning og estimering (K2). Kende de forskellige niveauer og formål for testplanlægning. (K1) Opsummere formål og indhold af testplanen, testdesign-specifikationen og testproceduredokumenter i henhold til Standard for Software Test Dokumentation (IEEE 829). (K2) Skelne mellem konceptuelt forskellige testmetoder, så som analytisk, modelbaseret, metodisk, process/standard-overensstemmende, dynamisk/heuristisk, konsulterende og regressions-uoverensstemmende. (K2) Skelne mellem grunden til testplanlægning for et system og til at planlægge testafvikling. (K2) Skrive en testafviklingsplan for et givent sæt af testcases, når der tages hensyn til prioritering og tekniske og logistiske afhængigheder. (K3) Liste testforberedelses- og testafviklingsaktiviteter, som skal overvejes under testplanlægning. (K1) Huske typiske faktorer, der påvirker indsatsen vedrørende test. (K1) Skelne mellem to begrebsmæssigt forskellige estimeringsmetoder: Den metrikbaserede metode og den ekspertbaserede metode. (K2) Kende/retfærdiggøre passende udgangskriterier for specifikke testniveauer og grupper af testcases (f.eks. integrationstest, accepttest eller testcases til brugervenlighedstest) (K2) 5.3. Overvågning og kontrol af testfremdrift (K2) Huske almindelige metrikker, der anvendes til overvågning af testforberedelse og afvikling. (K1). Forstå og fortolke testmetrikker til testrapportering og testkontrol (f.eks. defekter, der er fundet og rettet, og tests der er bestået/fejlet). (K2) Opsummere formål og indhold af testopsummeringsrapportdokument i henhold til Standard for Software Test Dokumentation (IEEE 829) (K2) 5.4. Konfigurationsstyring (K2) Opsummere hvordan konfigurationsstyring støtter test. (K2) 5.5 Risiko og test (K2) Beskrive en risiko som et muligt problem, der kunne true gennemførelsen af et eller flere af interessenternes projektformål. (K2) Version 2007 Side 46 af maj 2007

47 Huske, at risici bestemmes af sandsynlighed (for at det sker) og effekt (den skade, der sker, hvis det sker). (K1) Skelne mellem projekt- og produktrisici. (K2) Kende typiske produkt- og projektrisici. (K1) Beskrive, ved hjælp af eksempler, hvordan risikoanalyse og risikostyring kan anvendes ved testplanlægning. (K2) 5.6 Hændelseshåndtering (K3) Kende indholdet af en hændelsesrapport i forhold til Standard for Software Test Dokumentation (IEEE 829). (K1) Skrive en hændelsesrapport, der dækker observationen af en afvigelse under test. (K3) Version 2007 Side 47 af maj 2007

48 5.1 Testorganisation (K2) 30 minutter Termer Tester, testleder, testansvarlig Testorganisation og uafhængighed (K2) Effektiviteten for at finde defekter ved test og reviews kan forbedres ved at anvende uafhængige testere. Muligheder for uafhængighed er: Ingen uafhængige testere. Udviklere tester deres egen kode. Uafhængige testere i udviklingsteamsene. Uafhængigt testteam eller gruppe i organisationen, der rapporterer til projektstyring eller højere ledelse. Uafhængige testere fra virksomhedsorganisationen eller brugergruppen. Uafhængige testspecialister til specifikke testformål, som f.eks. brugervenlighedstestere, sikkerhedstestere eller certificerende testere (der godkender et softwareprodukt efter standarder og lovbestemmelser). Uafhængige testere, der er outsourcet eller eksterne i forhold til organisationen. Ved store, komplekse, sikkerhedskritiske projekter er det sædvanligvis bedst at have flere testniveauer, hvor nogle eller alle niveauer udføres af uafhængige testere. Udviklingsmedarbejdere kan deltage i test, især på de lavere niveauer, men deres mangel på objektivitet begrænser ofte deres effektivitet. Uafhængige testere kan have autoritet til at kræve og definere testprocesser og regler, men testere bør kun påtage sig sådanne procesrelaterede roller, når der er klart styringsmandat til at gøre det. Fordelene ved uafhængighed indbefatter: Uafhængige testere ser andre og forskellige defekter, og er uvildige. En uafhængig tester kan verificere de antagelser, personer har gjort under specifikation og implementering af systemet. Ulemper indbefatter: Isolation fra udviklingsteamet (hvis de behandles som fuldstændig uafhængige). Uafhængige testere kan være flaskehalsen som det sidste kontrolpunkt. Udviklere kan miste sansen for kvalitetsansvar. Testopgaver kan udføres af personer med en specifik testrolle eller kan udføres af nogen med en anden rolle, som f.eks. projektleder, kvalitetsansvarlig, udvikler, forretnings- og domæneekspert, infrastruktur eller it-drift Testlederes og testeres opgaver (K1) I denne syllabus beskrives to teststillinger, testleder og tester. De aktiviteter og opgaver, der udføres af personer i disse to roller afhænger af projekt- og produktkonteksten, personerne der fylder rollerne, og organisationen. Version 2007 Side 48 af maj 2007

49 Nogle gange kaldes testlederen testansvarlig eller testkoordinator. Rollen som testleder kan udføres af en projektleder, en udviklingschef, en kvalitetssikringsansvarlig eller en leder for en testgruppe. I større projekter kan der være to stillinger: testleder og testansvarlig. Typisk planlægger, overvåger og kontrollerer testlederen de testaktiviteter og opgaver, som defineret i Afsnit 1.4. Testlederens opgaver kan typisk indbefatte: Koordinere teststrategien og planen med projektledere og andre. Skrive eller gennemse en teststrategi for projektet og testpolitik for organisationen. Bidrage med testperspektivet i andre projektaktiviteter, som f.eks. integrationsplanlægning. Planlægge testene under overvejelse af konteksten og forståelse af testformål og risiciene herunder valg af testtilgang, estimering af tid, indsats og udgifter for testen, tilvejebringelse af ressourcer, definition af testniveauer, cyklusser og planlægning af hændelseshåndtering. Starte specifikation, forberedelse, implementering og afvikling af tests, overvåge testresultater og kontrollere slutkriterier. Tilpasse planlægningen baseret på testresultater og fremdrift (nogle gange dokumenteret i statusrapporter) og gøre det nødvendige for at kompensere for problemer. Opsætte passende konfigurationsstyring af test-delprodukter med henblik på sporbarhed. Introducere egnede metrik systemer til måling af testfremdrift og evaluering af kvaliteten af testen og produktet. Beslutte hvad der skal automatiseres, i hvilken grad og hvordan. Vælge værktøjer til at støtte test og organisere eventuel uddannelse i brug af værktøj for testere. Træffe beslutning om implementering af testmiljø. Skrive testopsummeringsrapporter baseret på de oplysninger, der indsamles under test. Testerens opgaver kan typisk indbefatte: Reviewe og bidrage til testplaner. Analysere, reviewe og vurdere brugerkrav, specifikationer og modeller for testbarhed. Fremstille testspecifikationer. Opsætte testmiljø (ofte koordineret med systemadministrationen og netværksstyring). Forberede og fremskaffe testdata. Implementere tests på alle testniveauer, afvikle og registrere tests, evaluere resultater og dokumentere afvigelser fra forventede resultater. Bruge testadministrations- eller styringsværktøjer og testovervågningsværktøjer som krævet. Automatisere tests (kan være understøttet af en udvikler eller en testautomatiseringsekspert). Måle performance af komponenter og systemer (hvis nødvendigt). Reviewe tests, der er udviklet af andre. Personer, der arbejder med testanalyse, testdesign, specifikke testtyper eller testautomatisering kan være specialister i disse roller. Afhængig af testniveauet og de risici, der relaterer sig til produktet og projektet, kan forskellige personer overtage rollen som tester, idet der bevares en grad af uafhængighed. Typiske vil testere på komponent- og integrationsniveau være udviklere, testere på accepttestniveau være forretningseksperter og brugere, og testere til driftsaccepttest være operatører. Version 2007 Side 49 af maj 2007

50 5.2 Testplanlægning og estimering (K2) 40 minutter Termer Testtilgang Testplanlægning (K2) Dette afsnit beskriver formålet med testplanlægning i udviklings- og implementeringsprojekter og for vedligeholdelsesaktiviteter. Planlægning kan være dokumenteret i en hovedtestplan og i separate testplaner for testniveauer, som f.eks. systemtest og accepttest. Oversigt over testplanlægningsdokumenter er givet i Standard for Software Test Dokumentation (IEEE 829). Planlægning er påvirket af organisationens testpolitik, omfanget af test, formål, risici, begrænsninger, alvorlighed, testbarhed og tilgængelighed af ressourcer. Jo mere projekt- og testplanlægningen skrider frem, jo mere information er tilgængelig, og jo flere detaljer kan inkluderes i planen. Testplanlægning er en løbende aktivitet og den udføres i alle livscyklusprocesser og aktiviteter. Feedback fra testaktiviteter anvendes til at erkende ændrede risici, så planen kan justeres Testplanlægningsaktiviteter (K2) Testplanlægningsaktiviteter kan indeholde: Fastsætte omfang og risiko, og identificere formålene med test. Definition af den overordnede testmetode (teststrategi), inklusive definition af testniveauer og indgangs- og udgangskriterier. Integration og koordination af testaktiviteter i softwarelivscyklusaktiviteterne: anskaffelse, levering, udvikling, drift og vedligeholdelse. Træfning af beslutninger om, hvad der skal testes, hvilke roller der skal udgøre testaktiviteterne, hvordan testaktiviteterne skal udføres, hvordan testresultater skal evalueres. Tidsplanlægge testanalyse og design aktiviteter. Tidsplanlægge testimplementering, afvikling og evaluering. Tildeling af ressourcer til de forskellige definerede aktiviteter. Definition af mængde, detaljeniveau, struktur og skabelon for testdokumentation. Valg af metrikker til overvågning og kontrol af testforberedelse og afvikling, defektløsning og risikomomenter. Fastsættelse af detaljeniveauet for testprocedurer for at kunne give oplysninger nok til at understøtte reproducerbar testforberedelse og afvikling Udgangskriterier (K2) Formålet med udgangskriterier er at definere, hvornår test skal stoppes, som f.eks. ved afslutning af et testniveau, eller når et testsæt har et specifikt mål. Typiske udgangskriterier kan bestå af: Måling af grundighed, som f.eks. kode-, funktionalitets- og risikodækning. Vurdering af defekttæthed eller pålidelighedsmålinger. Udgifter. Version 2007 Side 50 af maj 2007

51 Restrisici som f.eks. defekter, der ikke er rettet eller manglende testdækning i visse områder. Tidsplaner så som sådanne, som er baseret på time-to-market Testestimering (K2) To metoder til testestimering er dækket i denne syllabus: Den metrikbaserede tilgang: Estimering af testindsats baseret på metrikker fra tidligere eller lignende projekter eller baseret på typiske værdier. Den ekspertbaserede tilgang: Estimering af opgaver af ejeren af disse opgaver eller af eksperter. Når testindsatsen er estimeret, kan ressourcer identificeres, og der kan laves en tidsplan. Testindsatsen kan være afhængig af en række faktorer, herunder: Karakteristika for produktet: kvaliteten af specifikationen og andre oplysninger, der anvendes til testmodeller (dvs. testgrundlag), produktstørrelsen, kompleksiteten i problemdomænet, kravene til pålidelighed og sikkerhed og kravene til dokumentation. Karakteristika for udviklingsprocessen: organisationens stabilitet, anvendte værktøjer, testproces, de involverede personers evner og tidspres. Testresultatet: antal defekter og mængden af nødvendig genbearbejdning Testtilgang (teststrategier) (K2) En måde at klassificere testtilgang eller strategier på er baseret på det tidspunkt, hvor størstedelen af testdesignarbejdet er begyndt: Præventive metoder, hvor tests designes så tidligt som muligt. Reaktive metoder, hvor testdesign kommer efter, at softwaren eller systemet er fremstillet. Typiske metoder eller strategier indeholder: Analytiske metoder, som f.eks. risikobaseret test, hvor test rettes mod områder, hvor der er størst risiko. Modelbaserede metoder, som f.eks. stokastisk test vha. statistiske oplysninger om afvigelseshyppigheder (som f.eks. pålidelighedsvækstmodeller) eller anvendelse (som f.eks. driftsprofiler). Metodiske tilgange, som f.eks. afvigelsesbaseret (herunder fejlgætning og fejlangreb), erfaringsbaseret, checklistebaseret og kvalitetsegenskabsbaseret. Proces- og standarddefinerede metoder, som f.eks. de der er angivet af industrispecifikke standarder eller forskellige agile metodikker. Dynamiske og heuristiske metoder, som f.eks. udforskende test, hvor test er mere reaktiv i forhold til hændelser end planlagt, og hvor afvikling og vurdering er sideløbende opgaver. Konsultative metoder, som f.eks. de hvor testdækning primært drives af råd og vejledning af teknologi- og/eller forretningsdomæneeksperter uden for testteamet. Regressionsmodsætningsmetoder, som f.eks. de der indeholder genbrug af eksisterende testmateriale, omfattende automatisering af funktionelle regressionstests og standard testsæt. Version 2007 Side 51 af maj 2007

52 Forskellige metoder kan kombineres, f.eks. en risikobaseret dynamisk metode. Valget af en testtilgang bør overveje konteksten, herunder: Risiko for projektfiasko, fare for projektet og risiko for produktafvigelse for mennesker, miljøet og virksomheden. Medarbejdernes evner og erfaringer i de foreslåede teknikker, værktøjer og metoder. Formålet med testopgaven og testteamets mission. Regelbestemte aspekter, som f.eks. eksterne og interne bestemmelser for udviklingsprocessen. Produktets og forretningens natur. Version 2007 Side 52 af maj 2007

53 5.3 Overvågning og kontrol af testfremdriften (K2) 20 minutter Termer Defekttæthed, afvigelseshyppighed, testkontrol, testovervågning, testrapport Overvågning af testfremdrift(k1) Formålet med testovervågning er at give feedback og synlighed af testaktiviteterne. De oplysninger, der skal overvåges, kan indsamles manuelt eller automatisk og kan anvendes til at måle udgangskriterier, som f.eks. dækning. Metrikker kan også anvendes til at vurdere fremdriften i forhold til tidsplanen og budgettet. Almindelige testmetrikker indbefatter: Procentdelen af arbejde, der er brugt til testcaseforberedelse (eller procentdelen af planlagte testcases der er forberedt). Procentdelen af arbejde, der er brugt til testmiljøforberedelse. Afvikling af testcase (f.eks. antal testcases, der er kørt/ikke kørt, og testcases, der har bestået/fejlet). Defektoplysninger (f.eks. defekttæthed, defekter, der er fundet og rettet, afvigelseshyppighed og resultater af gentest). Testdækning af krav, risici eller kode. Testernes subjektive tillid til produktet. Datoer for testmilepæle. Testudgifter, herunder udgifterne sammenlignet med fordelene ved at finde den næste defekt eller at køre den næste test Testrapportering (K2) Testrapportering vedrører opsummering af oplysninger om testopgaven, herunder: Hvad der skete i testperioden, som f.eks. datoer, hvor udgangskriterierne blev opfyldt. Analyseret information og metrikker til at støtte anbefalinger og beslutninger om fremtidige handlinger, som f.eks. en vurdering af tilbageværende defekter, det økonomiske udbytte ved fortsat test, udestående risici, og tillidsniveauet for den testede software. Oversigten over en testopsummeringsrapport er givet i Standard for Software Test Dokumentation (IEEE 829). Metrikker bør indsamles under og ved afslutningen af et testniveau for at vurdere: Tilstrækkelighed af testformålene for det givne testniveau. Tilstrækkelighed af de udførte testtilgange. Effektiviteten af testen i forhold til dens formål Testkontrol (K2) Testkontrol beskriver vejledning og rettelseshandlinger som et resultat af de oplysninger og de metrikker, der er indsamlet og rapporteret. Handlinger kan dække enhver testaktivitet og kan påvirke enhver anden livscyklusaktivitet eller opgave. Version 2007 Side 53 af maj 2007

54 Eksempler på testkontrolhandlinger er: Træffe beslutninger baseret på information fra testovervågning. Omprioritere tests, når en identificeret risiko opstår (f.eks. ved sen levering af software). Ændre testtidsplanen på grund af tilgængelighed af et testmiljø. Sætte et indgangskriterium, der kræver at rettelser testes igen (gentest) af en udvikler, før de accepteres i en build. Version 2007 Side 54 af maj 2007

55 5.4 Konfigurationsstyring (K2) 10 minutter Termer Konfigurationsstyring, versionsstyring. Baggrund Formålet med konfigurationsstyring er at etablere og fastholde produktintegriteten (komponenter, data og dokumentation) for softwaren eller systemet igennem hele projektets og produktets livscyklus. For test kan konfigurationsstyring involvere sikring af, at: Alle test-delproduktelementer er identificeret, versionsstyret, sporet for ændringer, relateret til hinanden og relateret til udviklingselementer (testobjekter), så sporbarhed kan fastholdes igennem testprocessen. Alle identificerede dokumenter og softwareelementer refereres entydigt i testdokumentationen. Konfigurationsstyring hjælper testeren til entydigt at identificere (og til at gendanne) det testede element, testdokumenter, testene og testharnesset. Under testplanlægning bør konfigurationsstyringsprocedurer og infrastruktur (værktøjer) vælges, dokumenteres og implementeres. Version 2007 Side 55 af maj 2007

56 5.5 Risiko og test (K2) 30 minutter Termer Produktrisiko, projektrisiko, risiko, risikobaseret test. Baggrund Risiko kan defineres som muligheden for at en hændelse, fare, trussel eller situation opstår og dens uønskede konsekvenser, et muligt problem. Risikoniveauet bestemmes af sandsynligheden for, at der opstår en uheldig hændelse og effekten heraf (den skade, der opstår som følge af hændelsen) Projektrisici (K2) Projektrisici er risici, der omslutter projektets evne til at leve op til sit formål, som f.eks.: Organisatoriske faktorer: o færdigheder og personalemangel; o o o personlige og uddannelsesmæssige emner; politiske emner, som f.eks. testeres problemer med at kommunikere deres behov og testresultater; manglende opfølgning på oplysninger, der er fundet ved test og reviews (f.eks. ingen forbedring af udviklings- og testpraksis). forkert attitude imod eller forventninger til test (f.eks. ikke værdsættelse af værdien af at finde defekter under test). Tekniske emner: o problemer med definition af de rigtige krav; o omfanget af krav, der kan blive mødt under givne begrænsninger; o kvalitet af design, kode og tests. Leverandøranliggender: o afvigelse fra en tredjepart; o kontraktuelle anliggender. Når disse risici analyseres, styres og mildnes, skal den testansvarlige følge veletablerede projektstyringsprincipper. Afsnittet vedr. testplaner i Standard for Software Test Dokumentation (IEEE 829) kræver, at der angives risici og alternativ planer Produktrisici (K2) Mulige afvigelsesområder (uheldige fremtidige hændelser eller farer) i softwaren eller systemet er kendt som produktrisici, da de udgør en risiko for produktkvaliteten, som f.eks. Levering af afvigelsebehæftet software. Mulighed for, at softwaren/hardwaren kan medføre skade på en person eller en virksomhed. Ringe softwareegenskaber (f.eks. funktionalitet, pålidelighed, brugervenlighed og performance). Software der ikke udfører dets tilsigtede funktioner. Risici anvendes til at bestemme, hvor test skal begynde, og hvor der skal testes yderligere; test anvendes til at reducere risikoen for, at en uheldig effekt opstår, eller for at reducere effekten af en uheldig reaktion. Version 2007 Side 56 af maj 2007

57 Produktrisici er en speciel risikotype til måling af projektsucces. Test som en risikokontrolaktivitet giver feedback om restrisici ved måling af effektiviteten af fjernelse af kritiske defekter og af alternativplaner. En risikobaseret testmetode giver proaktiv lejlighed til at reducere produktrisikoniveauer, og den kan og bør starte i begyndelsen af et projekt. Den involverer identifikation af produktrisici og brugen af dem til at vejlede testplanlægning og kontrol, specifikation og afvikling af tests. I en risikobaseret metode kan de identificerede risici anvendes til: At bestemme de testteknikker, der skal anvendes. At bestemme omfanget af den test, der skal udføres. At prioritere test i et forsøg på at finde de kritiske defekter så tidligt som muligt. At bestemme om der kan anvendes nogen ikke-test-aktiviteter til at reducere risikoen (f.eks. ved at give uddannelse til uerfarne designere). Risikodrevet test trækker på projektinteressenternes samlede viden og indsigt til at bestemme risici og de niveauer af test, der er nødvendige for at håndtere disse risici. I sikringen af at risikoen for en produktafvigelse minimeres, giver risikostyringsaktiviteter en disciplineret metode til at: Vurdere (og regelmæssigt revurdere) hvad der kan gå galt (risici). At bestemme hvilke risici, der er vigtige at håndtere. At implementere handlinger, der skal håndtere disse risici. Endvidere kan test give støtte til identifikation af nye risici, kan hjælpe med at bestemme hvilke risici, der bør reduceres og kan sænke usikkerhed omkring risici. Version 2007 Side 57 af maj 2007

58 5.6 Hændelseshåndtering (K3) 40 minutter Termer Hændelsesregistrering hændelseshåndtering. Baggrund Eftersom et af formålene med test er at finde defekter, skal uoverensstemmelser mellem aktuelle og forventede resultater registreres som hændelser. Hændelser bør følges fra opdagelse og klassifikation til rettelse og bekræftelse af løsningen. For at håndtere alle hændelser til afslutning bør en organisation etablere en proces og regler for klassifikation. Hændelser kan opstå under udvikling, review, test eller ved anvendelse af et softwareprodukt. De kan blive rejst for problemer i kode eller det fungerende system eller i enhver dokumenttype, herunder krav, udviklingsdokumenter, testdokumenter, og brugeroplysninger, som f.eks. Hjælp eller installationsvejledninger. Hændelsesrapporter har følgende formål: At give udviklere og andre parter feedback om problemet for at muliggøre identifikation, isolation og rettelse efter behov. At give testledere et middel til at følge kvaliteten af systemet under test og testens fremdrift. At give ideer til testprocesforbedring. Detaljer i hændelsesrapporten kan omfatte: Dato for udstedelse, udstedende organisation og forfatter. Forventede og faktiske resultater. Identifikationaf testelement, (konfigurationselement) og miljø. Software- eller systemlivscyklusproces, i hvilken hændelsen blev observeret. Beskrivelse af hændelsen, for at gøre det muligt at gentage den og finde en løsning, inklusive logfiler, databasedumps eller skærmprint.. Omfang eller grad af påvirkning af interessenternes/interessentens interesser. Alvorlighed af påvirkning af systemet. Vigtighed/prioritet for rettelse. Hændelsesstatus (f.eks. åben, i bero, kopi, venter på at blive rettet, rettelse afventer gentest, lukket). Konklusioner, anbefalinger og godkendelser. Globale problemer, som f.eks. andre områder, der kan blive påvirket af en ændring som følge af hændelsen. Ændringshistorie, som f.eks. rækkefølgen af handlinger, der udføres af projektteammedlemmer angående hændelsen for at isolere, reparere og bekræfte den som rettet. Referencer, indeholdende identiteten af den testcasespecifikation, som afdækkede problemet. Strukturen på en hændelsesrapport er også beskrevet i Standard for Software Test Dokumentation (IEEE 829) og er her benævnt en uregelmæssighedsrapport. Version 2007 Side 58 af maj 2007

59 Referencer Black, 2001, Hetzel, Black, 2001, Hetzel, Black, 2001, Craig, 2002, IEEE 829, Kaner Black, 2001, Craig, 2002, Hetzel, 1988, IEEE Craig, Black, 2001, IEEE Black, 2001, IEEE 829 Version 2007 Side 59 af maj 2007

60 6. Værktøjsstøtte til test (K2) 80 minutter Undervisningsformål for værktøjssupport til test Formålene viser, hvad du skal kunne efter fuldførelse af hvert enkelt modul Typer af testværktøjer (K2) Klassificer forskellige typer af testværktøjer i forhold til testprocesaktiviteterne. (K2) Kende værktøjer, der kan hjælpe udviklerne med deres test. (K1) 6.2. Effektiv brug af værktøjer: Mulige fordele og risici (K2) Opsummere mulige fordele og risici ved testautomatisering og værktøjsstøtte til test. (K2) Vide, at testafviklingsværktøjer kan have forskellig scriptteknik, herunder datastyret og nøgleordsstyret. (K1) 6.3. Introduktion af værktøj i en organisation (K1) Anføre hovedprincipperne ved introduktion af et værktøj i en organisation. (K1) Anføre målene for en proof-of-concept-/pilotfase for værktøjsvurdering. (K1) Vide, at der kræves andet end blot erhvervelse af et værktøj til god værktøjsstøtte. (K1) Version 2007 Side 60 af maj 2007

61 6.1 Typer af testværktøjer (K2) 45 minutter Termer Konfigurationsstyringsværktøj, dækningsværktøj, debugging-værktøj, driver, dynamisk analyseværktøj, hændelseshåndteringsværktøj, loadtestværktøj, modelleringsværktøj, overvågningsværktøj, performancetestværktøj, undersøgelseseffekt, kravstyringsværktøj, reviewprocesstøtteværktøj, sikkerhedsværktøj, statisk analyseværktøj, stresstestværktøj, stub, testsammenligner, testdataforberedelsesværktøj, testdesignværktøj, testharness, testafviklingsværktøj, teststyringsværktøj, rammeværktøj for komponenttest Klassificering af testværktøj (K2) Der findes en række værktøjer, der støtter forskellige aspekter ved test. Værktøjer er i denne syllabus klassificeret i forhold til de testaktiviteter de støtter. Nogle værktøjer støtter en aktivitet; andre kan støtte mere end en aktivitet, men er klassificeret under den aktivitet, som de er tættest forbundet til. Nogle kommercielle værktøjer tilbyder støtte til en enkelt aktivitetstype; andre kommercielle værktøjsleverandører tilbyder værktøjsrækker eller familier, der yder støtte til mange eller alle disse aktiviteter. Testværktøjer kan forbedre testaktiviteternes effektivitet ved at automatisere opgaver, der gentages. Testværktøjer kan også forbedre testpålideligheden ved f.eks. at automatisere store datasammenligninger eller simulere adfærd. Nogle typer testværktøjer kan være invaderende, idet værktøjet selv kan påvirke det aktuelle testresultat. Aktuel timing kan f.eks. være forskellig, afhængig af hvordan du måler den med forskellige performanceværktøjer, eller du kan få forskellig måling af kodedækning, afhængig af hvilket dækningsværktøj, du anvender. Konsekvensen af invaderende værktøjer kaldes undersøgelseseffekt. Nogle værktøjer tilbyder støtte, der er mere egnet til udviklere (f.eks. under komponent- og komponentintegrations- test). Sådanne værktøjer er markeret med (U) i klassifikationerne nedenfor Værktøjssupport til styring af test og tests (K1) Styringsværktøjer kan anvendes til alle testaktiviteter i hele softwarens livscyklus. Teststyringsværktøjer Egenskaber for teststyringsværktøjer omfatter: Støtte til styring af tests og de udførte testaktiviteter. Grænseflader til testafviklingsværktøjer, fejlopfølgningsværktøjer og kravstyringsværktøjer. Uafhængig versionsstyring eller grænseflade til et eksternt konfigurationsstyringsværktøj. Støtte til sporbarhed af tests, testresultater og hændelser til kildedokumenter, som f.eks. kravspecifikationer. Registrering af testresultater og generering af fremdriftsrapporter. Version 2007 Side 61 af maj 2007

62 Kvantitativ analyse (metrikker) relateret til tests (f.eks. testkørsel og beståede tests) og testobjektet (f.eks. oprettede hændelser) for at kunne give oplysninger om testobjektet og for at kontrollere og forbedre testprocessen. Kravstyringsværktøjer Kravstyringsværktøjer lagrer krav, kontrollerer for ensartethed og udefinerede (manglende) krav, muliggør prioritering af krav og giver mulighed for at individuelle tests er sporbare til krav, funktioner og/eller egenskaber. Sporbarhed kan rapporteres i teststyringsfremdriftsrapporter. Dækning af krav, funktioner og/eller egenskaber vha. et sæt af tests kan også rapporteres. Hændelseshåndteringsværktøjer Hændelseshåndteringsværktøjer lagrer og styrer hændelsesrapporter, dvs. defekter, afvigelser eller opfattede problemer og uregelmæssigheder og støtter styring af hændelsesrapporter på måder, der indbefatter: Lettere prioritering. Tildeling af aktiviteter til person (f.eks. rettelse eller gentest). Statustilskrivning (f.eks. afviste, klar til test eller i bero til næste frigivelse). Disse værktøjer, gør det muligt at følge hændelsernes fremdrift over tid, giver ofte støtte til statistisk analyse og giver rapporter om hændelser. De er også kendt som fejlopfølgningsværktøjer. Konfigurationsstyringsværktøjer Konfigurationsstyringsværktøjer er ikke egentlige testværktøjer, men er typisk nødvendige til at holde styr på de forskellige versioner og builds af softwaren og tests. Konfigurationsstyringsværktøjer: Lagrer oplysninger om versioner og build af software og test-delprodukter. Muliggør sporbarhed mellem test-delprodukter, softwarearbejdsprodukter og produktvarianter. Er særligt nyttige, når der udvikles mere end en konfiguration af hardware-/softwaremiljøet (f.eks. til forskellige styresystemversioner, forskellige biblioteker eller oversættere, forskellige browsere eller forskellige computere) Værktøjsstøtte til statisk test (K1) Reviewværktøjer Reviewværktøjer (også kaldet reviewprocesstøtteværktøjer) kan lagre oplysninger om reviewprocesser, lagre og kommunikere reviewkommentarer, rapportere om defekter og indsats, styre referencer til reviewregler og/eller tjeklister og holde styr på sporingen mellem dokumenter og kildekode. De kan også give hjælp til online-reviews, hvilket er nyttigt, hvis teamet er geografisk spredt. Statiske analyseværktøjer (U) Statiske analyseværktøjer giver støtte til udviklere, testere og kvalitetssikringspersonale til at finde defekter før dynamisk test. Deres hovedformål indbefatter: Håndhævelse af kodestandarder. Version 2007 Side 62 af maj 2007

63 Analyse af strukturer og afhængigheder (f.eks. linkede websider). Hjælp til forståelse af koden. Statiske analyseværktøjer kan kalkulere metrikker fra koden (f.eks. kompleksitet), der kan give værdifulde oplysninger, f.eks. til planlægning og risikoanalyse. Modelleringsværktøjer (U) Modelleringsværktøjer kan validere softwaremodeller. F.eks. kan en databasemodelchecker finde defekter og inkonsistenser i datamodellen; andre modelleringsværktøjer kan finde defekter i en tilstandsmodel eller en objektmodel. Disse værktøjer kan ofte hjælpe med generering af nogle testcases baseret på modellen (se også testdesignværktøjer nedenfor). Hovedfordelen ved statiske analyseværktøjer og modelleringsværktøjer er rentabiliteten ved at finde flere defekter på et tidligere tidspunkt i udviklingsprocessen. Som et resultat heraf kan udviklingsprocessen accelerere og forbedres ved at have mindre omarbejdning Værktøjsstøtte til testspecifikation (K1) Testdesignværktøjer Testdesignværktøjer genererer testinputs eller eksekverbare tests fra krav, fra en grafisk brugergrænseflade, fra designmodeller (tilstand, data eller objekt) eller fra kode. Denne værktøjstype kan også generere forventede udfald (dvs. kan bruge et testorakel). De genererede tests fra en tilstands- eller en objektmodel er nyttige til verifikation af implementering af modellen i softwaren, men er sjældent tilstrækkelige til verifikation af alle aspekter af softwaren eller systemet. De kan spare værdifuld tid og give øget grundighed af testen på grund af fuldstændigheden af de tests, som værktøjet kan generere. Andre værktøjer i denne kategori kan hjælpe med støtte til generering af tests gennem levering af strukturerede skabeloner, sommetider kaldt en testramme, der genererer tests eller teststubbe og derved fremskynder testdesignprocessen. Testdataforberedelsesværktøjer (U) Testdataforberedelsesværktøjer manipulerer databaser, filer eller dataoverførsler til opsætning af data, der skal anvendes under afvikling af tests. En fordel ved disse værktøjer er, at det sikres at ægte data, der overføres til et testmiljø, gøres anonyme af hensyn til databeskyttelse Værktøjsstøtte til testafvikling og -logging (K1) Testafviklingsværktøjer Testafviklingsværktøjer gør det muligt at afvikle tests automatisk eller halvautomatisk, vha. lagrede inputs og forventede resultater gennem brug af et scriptsprog. Scriptsproget gør det muligt at håndtere tests med en begrænset indsats, f.eks. at gentage testen med forskellige data eller at teste en anden del af systemet med tilsvarende trin. Generelt indeholder disse værktøjer dynamiske sammenligningsfaciliteter og giver en testlog for hver testkørsel. Testafviklingsværktøjer kan også anvendes til at optage tests, når de refereres til som afspilningsværktøjer. Optagelse af testinputs under udforskende test eller unscriptet test kan være nyttig for at kunne gentage og/eller dokumentere en test, hvis der f.eks. opstår en afvigelse. Version 2007 Side 63 af maj 2007

64 Testharness-/enhedstest-rammeværktøjer (U) Testharness kan gøre det lettere at teste komponenter eller en del af et system ved at simulere miljøet, hvori testobjektet skal køre. Det kan gøres, enten fordi andre komponenter fra miljøet endnu ikke er tilgængelige og er udskiftet af stubbe og/eller drivere, eller simpelthen for at give et forudsigeligt og kontrollerbart miljø, hvor fejl kan lokaliseres til objektet under test. Der kan dannes en ramme, hvor en del af koden, objektet, metoden eller funktionen, enheden eller komponenten kan eksekveres ved kald til det objekt, der skal testes og/eller ved at give feedback til objektet. Rammen kan gøre dette ved at give mulighed for kunstigt at levere input til testobjektet og/eller ved at levere stubbe der kan aftage outputtet fra objektet i stedet for de rigtige outputmål. Testharnessværktøjer kan også anvendes til at levere en eksekveringsmodel i middleware, hvor sprog, styresystemer eller hardware skal testes sammen. Disse værktøjer kaldes ofte enhedstest-rammeværktøjer, når de har særligt fokus på komponenttestniveauet. Denne type værktøj hjælper ved afvikling af komponenttests i parallel med opbygning af koden. Testsammenlignere Testsammenlignerne bestemmer forskelle mellem filer, databaser eller testresultater. Testafviklingsværktøjer indeholder typisk dynamiske sammenlignere, men posteksekveringssammenligning kan udføres af et separat sammenligningsværktøj. En testsammenligner kan anvende et testorakel, specielt hvis det er automatiseret. Dækningsmåleværktøjer (U) Dækningsmåleværktøjer kan enten være invaderende eller ikke-invaderende afhængig af den måleteknik, der anvendes, hvad der måles og kodesproget. Kodedækningsværktøjer måler procentdelen af specifikke typer af kodestruktur, der er blevet aktiveret (f.eks. instruktioner, forgreninger eller beslutninger og modul- eller funktionskald). Disse værktøjer viser, hvor grundigt den målte strukturtype er aktiveret af et testsæt. Sikkerhedsværktøjer Sikkerhedsværktøjer kontrollerer for computervira og angreb der giver afvisning af service. En firewall f.eks. er ikke et egentligt testværktøj, men kan anvendes til sikkerhedstest. Sikkerhedsværktøjer søger efter specifikke systemsårbarheder Værktøjsstøtte til performance og overvågning (K1) Dynamiske analyseværktøjer (U) Dynamiske analyseværktøjer finder defekter, der kun åbenbares, når softwaren eksekverer sådan noget som tidsafhængigheder eller hukommelseslæk. De anvendes typisk ved komponent- og komponentintegrationstest og ved test af middleware. Performancetest-/loadtest-/stresstestværktøjer Performancetestværktøjer overvåger og rapporterer om, hvordan et system opfører sig under forskellige simulerede anvendelsesbetingelser. De simulerer en belastning på et program, en database eller et systemmiljø, som f.eks. et netværk eller en server. Værktøjerne benævnes ofte efter det, de måler, som f.eks. belastning eller stress, så de er også kendt som loadtestværktøjer eller stresstestværktøjer. De er ofte baseret på automatiseret gentagen testafvikling kontrolleret af parametre. Overvågningsværktøjer Version 2007 Side 64 af maj 2007

65 Overvågningsværktøjer er ikke egentlige testværktøjer, men giver oplysninger, der kan anvendes til testformål, og som ikke er tilgængelige på andre måder. Overvågningsværktøjer analyserer uafbrudt, verificerer og rapporterer om anvendelsen af specifikke systemressourcer og giver advarsler om mulige serviceproblemer. De lagrer oplysninger om version og build af software og test-delprodukter og muliggør sporbarhed Værktøjssupport til specifikke programområder (K1) Individuelle eksempler på de værktøjstyper, der er klassificeret oven for, kan være specialiserede til anvendelse i en bestemt programtype. Der er f.eks. performancetestværktøjer, der specifikt er beregnede til web-baserede programmer, statiske analyseværktøjer til specifikke udviklingsplatforme og dynamiske analyseværktøjer, der specifikt er beregnede til test af sikkerhedsforhold. Kommercielle værktøjsfamilier kan fokusere på specifikke programområder (f.eks. indlejrede systemer) Værktøjssupport vha. af andre værktøjer (K1) De testværktøjer, der er oplistet her, er ikke de eneste værktøjstyper, der anvendes af testere de kan f.eks. også anvende regneark, SQL, ressource- eller debuggingværktøjer (U). Version 2007 Side 65 af maj 2007

66 6.2 Effektiv brug af værktøjer: mulige fordele og risici(k2) 20 minutter Termer Datastyret (test), nøgleordsstyret (test), scriptsprog Mulige fordele og risici ved værktøjsstøtte til test (for alle værktøjer (K2) Blot det at købe eller lease et værktøj garanterer ikke succes med værktøjet. Hver værktøjstype kan kræve ekstra indsats for at opnå rigtige og varige fordele. Der er potentielle fordele og muligheder ved anvendelse af værktøjer til test, men der er også risici. Mulige fordele ved anvendelse af værktøjer indbefatter: Repetitivt arbejde reduceres (f.eks. kørsel af regressionstests, genindtastning af de samme testdata, og kontrol i forhold til kodestandarder). Større konsistens og repeterbarhed (f.eks. tests afviklet vha. et værktøj, og tests udledt fra krav). Objektiv vurdering (f.eks. statiske målinger, dækning). Let adgang til oplysninger om tests eller testafvikling (f.eks. statistikker og grafer om testfremdrift, hændelseshyppighed og performance). Risici ved anvendelse af værktøjer indbefatter: Urealistiske forventninger til værktøjet (herunder funktionalitet og let anvendelighed). Undervurdering af tiden, udgifterne og indsatsen for den første introduktion af et værktøj (herunder undervisning og ekstern ekspertise). Undervurdering af tiden og den nødvendige indsats til opnåelse af betydelige og vedvarende fordele ved værktøjet (herunder behov for ændringer i testprocessen og vedvarende forbedring af den måde, værktøjet anvendes på). Undervurdering af den nødvendige indsats til at vedligeholde testdelprodukter, der er genereret af værktøjet. For stor tillid til værktøjet (erstatning for testdesign eller hvor manuel test ville være bedre) Specielle overvejelser for nogle værktøjstyper (K1) Testafviklingsværktøjer Testafviklingsværktøjer gentager scripts, der er designet til at implementere tests, der er lagret elektronisk. Denne værktøjstype kræver ofte en stor indsats for at opnå betydelige fordele. Optagelse af tests ved at optage handlinger fra en manuel tester ser attraktivt ud, men denne metode kan ikke udvides til store antal automatiserede tests. Et optaget script er en lineær fremstilling med specifikke data og handlinger som en del af hvert script. Denne type scripts kan være ustabile, når der opstår uventede hændelser. Version 2007 Side 66 af maj 2007

67 En datastyret metode skiller testinput (data) ud, normalt i et regneark, og anvender et mere generisk script, der kan læse testdata og udføre samme test med forskellig data. Testere, der ikke er kendt med scriptsproget, kan indsætte testdata til disse foruddefinerede scripts. Ved en nøgleordsstyret metode indeholder regnearket nøgleord, der beskriver de handlinger der skal udføres, (også kaldet handlingsord) og testdata. Testere (selvom de ikke er kendt med scriptsproget) kan definere tests vha. nøgleordene, der kan tilpasses til det program, der testes. Der er behov for teknisk ekspertise i scriptsproget til alle metoder (enten hos testere eller hos specialister i testautomatisering). Uanset hvilken teknik der anvendes, skal de forventede resultater for hver test lagres til senere sammenligning. Performancetestværktøjer Ved performancetestværktøjer er der behov for nogen med ekspertise i performancetest til at hjælpe med design af tests og fortolkning af resultaterne. Statiske analyseværktøjer Statiske analyseværktøjer, der anvendes på kildekode, kan håndhæve kodestandarder, men hvis de anvendes på eksisterende kode, kan de generere en masse meddelelser. Advarselsmeddelelser forhindrer ikke koden i at blive oversat til et eksekverbart program, men bør ideelt set adresseres, så vedligeholdelse af koden bliver lettere i fremtiden. En gradvis implementering med filtre indsat til udelukkelse af visse meddelelser i begyndelsen vil være en effektiv metode. Teststyringsværktøjer Teststyringsværktøjer skal samarbejde med andre værktøjer eller regneark for at fremstille information i det bedste format i forhold til organisationens aktuelle behov. Rapporter skal designes og overvåges, så de kan gøre nytte. Version 2007 Side 67 af maj 2007

68 6.3 Introduktion af et værktøj i en organisation (K1) 15 minutter Termer Ingen specifikke termer. Baggrund Hovedovervejelserne ved udvælgelse af et værktøj til en organisation indbefatter: Vurdering af organisationens modenhed, styrker og svagheder og identifikation af muligheder for en forbedret testproces understøttet af værktøjer. Vurdering i forhold til klare krav og formålskriterier. En test af om den krævede funktionalitet er til stede og bestemmelse af, om produktet opfylder formålene (proof-of concept). Vurdering af leverandøren (herunder undervisning, support og kommercielle aspekter). Identifikation af interne krav for coaching og mentoring i brug af værktøjet. Introduktion af det valgte værktøj i en organisation starter med et pilotprojekt, som har følgende formål: Lære flere detaljer om værktøjet. Evaluere hvordan værktøjet passer til eksisterende processer og fremgangsmåder, og bestemme, hvad der skal ændres. Beslutte standardmåder for anvendelse, styre, lagre og vedligeholde værktøjet og testdelprodukter (f.eks. fastsætte navnekonventioner for filer og tests, oprettelse af biblioteker og definition af modulopbygningen af sæt af testcases). Vurdere, om der fordele kan opnås for en fornuftig omkostning. Succesfaktorer for udbredelse af værktøjet i en organisation indbefatter: Trinvis udrulning af værktøjet til resten af organisationen. Tilpasning og forbedring af processerne, så de passer til anvendelse af værktøjet. Tilbyde undervisning og coaching/mentoring af nye brugere. Definere retningslinjer for anvendelse. Implementere en måde at tage ved lære af anvendelsen af værktøjet. Overvåge værktøjsanvendelse og fordele. Referencer Buwalda, 2001, Fewster, Fewster, 1999 Version 2007 Side 68 af maj 2007

69 7. Referencer Standarder ISTQB Ordliste over termer anvendt i Version 1.0 (Note: bør være 1.3) [CMMI] Chrissis, M.B., Konrad, M. og Shrum, S. (2004) CMMI, Guidelines for Process Integration and Product Improvement, Addison Wesley: Reading, MA Se afsnit 2.1 [IEEE 829] IEEE Std 829 (1998/2005) IEEE Standard for Software Test Documentation (er i øjeblikket under revision) Se afsnittene 2.3, 2.4, 4.1, 5.2, 5.3, 5.5, 5.6 [IEEE 1028] IEEE Std 1028 (1997) IEEE Standard for Software Reviews Se afsnit 3.2 [IEEE 12207] IEEE 12207/ISO/IEC , Software life cycle processes Se afsnit 2.1 [ISO 9126] ISO/IEC :2001, Software Engineering Software Product Quality Se afsnit 2.3 Bøger [Beizer, 1990] Beizer, B. (1990) Techniques (2nd edition), Van Nostrand Reinhold: Boston Se afsnittene 1.2, 1.3, 2.3, 4.2, 4.3, 4.4, 4.6 [Black, 2001] Black, R. (2001) Managing the Testing Process (2nd edition), John Wiley & Sons: New York Se afsnittene 1.1, 1.2, 1.4, 1.5, 2.3, 2.4, 5.1, 5.2, 5.3, 5.5, 5.6 [Buwalda, 2001] Buwalda, H. et al. (2001) Integrated Test Design and Automation, Addison Wesley: Reading, MA Se afsnit 6.2 [Copeland, 2004] Copeland, L. (2004) A Practitioner s Guide to Software Test Design, Artech House: Norwood, MA Se afsnittene 2.2, 2.3, 4.2, 4.3, 4.4, 4.6 [Craig, 2002] Craig, Rick D. og Jaskiel, Stefan P. (2002) Systematic, Artech House: Norwood, MA Se afsnittene 1.4.5, 2.1.3, 2.4, 4.1, 5.2.5, 5.3, 5.4 [Fewster, 1999] Fewster, M. og Graham, D. (1999) Software Test Automation, Addison Wesley: Reading, MA Se afsnittene 6.2, 6.3 [Gilb, 1993]: Gilb, Tom og Graham, Dorothy (1993) Software Inspection, Addison Wesley: Reading, MA Se afsnittene 3.2.2, Version 2007 Side 69 af maj 2007

70 [Hetzel, 1988] Hetzel, W. (1988) Complete Guide to, QED: Wellesley, MA Se afsnittene 1.3, 1.4, 1.5, 2.1, 2.2, 2.3, 2.4, 4.1, 5.1, 5.3 [Kaner, 2002] Kaner, C., Bach, J. og Pettticord, B. (2002) Lessons Learned in, John Wiley & Sons: Se afsnittene 1.1, 4.5, 5.2 [Myers 1979] Myers, Glenford J. (1979) The Art of, John Wiley & Sons: Se afsnittene 1.2, 1.3, 2.2, 4.3 [van Veenendaal, 2004] van Veenendaal, E. (ed.) (2004) The Testing Practitioner (Kapitlerne 6, 8, 10), UTN Publishers: The Netherlands Se afsnittene 3.2, 3.3 Version 2007 Side 70 af maj 2007

71 Tillæg A Syllabus-baggrund Historien om dette dokument Dette dokument blev forberedt i perioden af en arbejdsgruppe bestående af medlemmer udpeget af (ISTQB). Det blev først reviewet af et udvalgt reviewpanel og derefter af repræsentanter fra det internationale softwaretestsamfund. De regler, der er anvendt ved fremstillingen af dette dokument, findes i Tillæg C. Dokumentet er pensum for Foundation Certificate in, det første international kvalifikationsniveau godkendt af ISTQB ( Formål for Foundation Certificate qualification At opnå anerkendelse af test som en væsentlig og professionel softwareteknisk specialisering. At levere en standardmodel til udvikling af testeres karriere. At sørge for, at professionelt kvalificerede testere bliver anerkendt af arbejdsgivere, kunder og kollegaer, og til at hæve testeres profil. At fremme konsistent og god testpraksis inden for alle softwaretekniske discipliner. At identificere testemner, der er relevante og værdifulde for industrien. At sætte softwareleverandører i stand til at ansætte godkendte testere og dermed få en kommerciel fordel i forhold til deres konkurrenter ved at reklamere for deres testeransættelsespolitik. At skabe en mulighed for testere og de der har interesse i test til at opnå en internationalt anerkendt kvalifikation i emnet. Formål for international kvalifikation (bearbejdet efter ISTQB-mødet i Sollentuna, November 2001) At blive i stand til at sammenligne testevner på tværs af forskellige lande. At sætte testere i stand til lettere at bevæge sig på tværs af landegrænserne. At gøre det muligt for multinationale/internationale projekter at få en fælles forståelse af testemner. At øge antallet af kvalificerede testere over hele verden. At får større effekt/værdi som et internationalt baseret initiativ i stedet for en landespecifik metode. At udvikle en fælles international enhed med forståelse og kendskab til test via denne syllabus og terminologi, og til at øge kendskabsniveauet for test for alle deltagere. At fremme test som et erhverv i flere lande. At sætte testere i stand til at opnå en anerkendt kvalifikation på deres eget sprog. At gøre det muligt at dele kendskab og ressourcer på tværs af lande. At opnå international anerkendelse af testere og denne kvalifikation gennem deltagelse fra mange lande. Version 2007 Side 71 af maj 2007

72 Adgangskrav for denne kvalifikation Adgangskriteriet for at tage ISTQB Foundation Certificate in -eksamen er at kandidater har en interesse i softwaretest. Det anbefales imidlertid på det kraftigste, at kandidater også: Har lidt baggrund i enten softwareudvikling eller softwaretest, f.eks. seks måneders erfaring som system- eller brugeraccepttester eller som softwareudvikler. Tager et kursus, der er godkendt til ISTQB-standarder (af et af de ISTQB-anerkendte nationale nævn). Baggrund og historie for Foundation Certificate in Den uafhængige certificering af softwaretestere begyndte i Storbritannien gennem British Computer Societys Information Systems Examination Board (ISEB), da der blev etableret et softwaretestnævn i 1998 ( I 2002 begyndte ASQF i Tyskland at støtte en tysk testerkvalifikations-ordning ( Denne syllabus er baseret på ISEB- og ASQFsyllabierne; den omfatter reorganiseret, opdateret og lidt nyt indhold, og der er lagt målrettet vægt på emner, der vil give mest praktisk hjælp til testere. Et eksisterende Foundation Certificate i (f.eks. fra ISEB, ASQF eller et ISTQBanerkendt nationalt nævn), der er godkendt før Certificate blev frigivet, anses for at svare til Certificate. Foundation Certificate bliver ikke forældet og behøver ikke at blive fornyet. Datoen, da det blev udstedt, er vist på certifikatet. I hvert af de deltagende lande bliver lokale forhold kontrolleret af et nationalt ISTQB-anerkendt softwaretestnævn. De nationale nævns opgaver er specificeret af ISTQB, men er implementeret i hvert enkelt land. Opgaverne i landenævnene forventes at omfatte akkreditering af kursusudbydere og afholdelse af eksamen. Version 2007 Side 72 af maj 2007

73 Tillæg B Undervisningsmål/vidensniveau Følgende undervisningsformål er defineret som gældende for denne syllabus. Der bliver eksamineret i alle emne i syllabussen i henhold til undervisningsformålet for dem. Niveau 1: Husk (K1) Kandidaten kender, kan huske og genkalde sig en term eller et koncept. Eksempel Kan huske definitionen på en afvigelse som: manglende levering af service til en slutbruger eller enhver anden interessent eller aktuel anderledes opførsel af komponenten eller systemet i forhold til dets forventede levering, service eller resultat. Niveau 2: Forstå (K2) Kandidaten kan udvælge årsager eller forklaringer for udsagn, der er relateret til emnet og kan opsummere, sammenligne, klassificere, kategorisere og give eksempler på testkonceptet. Eksempler Kan forklare årsagen til hvorfor tests bør designes så tidligt som muligt: For at finde defekter, når de er billigere at fjerne. For at finde de vigtigste defekter først. Kan forklare ligheder og forskelle mellem integrations- og systemtest: Ligheder: test af mere end en komponent og kan teste ikke-funktionelle aspekter. Forskelle: integrationstest koncentrerer sig om grænseflade og samspil, og systemtest koncentrerer sig om forhold for hele systemet, som f.eks. start-til-slut bearbejdning. Niveau 3: Anvende(K3) Kandidaten kan udvælge den anvendelse for et koncept eller teknik og bruge det i en given kontekst. Eksempel Kan identificere grænseværdier for gyldige og ugyldige partitioner. Kan vælge testcases fra et givent tilstandsovergangsdiagram for at dække alle overgange. Reference (For kognitive niveauer af undervisningsformål) Anderson, L. W. og Krathwohl, D. R. (eds) (2001) A Taxonomy for Learning, Teaching, and Assessing: A Revision of Bloom's Taxonomy of Educational Objectives, Allyn & Bacon: Version 2007 Side 73 af maj 2007

74 Tillæg C Gældende regler for ISTQB Foundation syllabus De regler, der er oplistet her, blev anvendt ved udvikling og review af denne syllabus. (Der er vist et TAG efter hver regel som forkortelse for reglen.) Generelle regler SG1. Syllabussen bør være forståelig og til at forholde sig til for personer med 0 til 6 måneders (eller mere) erfaring i test. (6-MONTH) SG2. Syllabussen bør være mere praktisk end teoretisk. (PRACTICAL) SG3. Syllabussen bør være klar og entydig for dens tiltænkte læsere. (CLEAR) SG4. Syllabussen bør være forståelig for personer fra forskellige lande og være let at oversætte til forskellige sprog. (TRANSLATABLE) SG5. Syllabussen bør bruge amerikansk engelsk. (AMERICAN-ENGLISH) Aktuelt indhold SC1. Syllabussen bør indeholde de nyeste testkoncepter og bør reflektere den aktuelle bedste praksis i softwaretest, hvor der er general enighed om det. Syllabussen skal reviewes hvert tredje til femte år. (RECENT) SC2. Syllabussen bør minimere tidsspecifikke emner, som f.eks. aktuelle markedsbetingelser, så den kan have en hyldetid på tre til fem år. (SHELF-LIFE). Undervisningsformål LO1. Undervisningsformål bør skelne mellem emner, der skal kunne huskes (kognitivt niveau K1), emner, som kandidaten bør forstå begrebsmæssigt (K2), og de som kandidaten bør være i stand til at praktisere/anvende (K3). (KNOWLEDGE-LEVEL) LO2. Beskrivelsen af indholdet bør være i overensstemmelse med undervisningsformålet. (LOCONSISTENT) LO3. For at illustrere undervisningsformålet bør prøveeksamensspørgsmål for hvert hovedafsnit udgives sammen med syllabussen. (LO-EXAM) Overordnet struktur ST1. Syllabussens struktur bør være klar, og tillade krydsreferencer til og fra andre dele, fra eksamensspørgsmål og fra andre relevante dokumenter. (CROSS-REF) ST2. Overlap mellem afsnittene i syllabussen bør minimeres. (OVERLAP) ST3. Hvert afsnit i syllabussen bør have samme struktur. (STRUCTURE-CONSISTENT) Version 2007 Side 74 af maj 2007

75 ST4. Syllabussen bør indeholde version, udstedelsesdato og sidenummer på hver side. (VERSION) ST5. Syllabussen bør indeholde vejledning med angivelse af den tid, der skal anvendes på hvert afsnit (for at afspejle vigtigheden af hvert emne). (TIME-SPENT) Referencer SR1. Der opgives kilder og referencer for koncepter i syllabussen for at hjælpe kursusudbydere med at finde flere oplysninger om emnet. (REFS) SR2. Hvor der ikke er nogen let identificerbare og klare kilder, bør der være opgivet flere detaljer i syllabussen. F.eks. er definitioner givet i ordlisten, så det kun er termerne, der er oplistet i syllabussen. (NON-REF DETAIL) Informationskilder De termer, der er anvendt i syllabussen, er defineret i ISTQB s ordliste over termer, der anvendes i softwaretest. Der findes en tilgængelig version af ordlisten fra ISTQB. Der er også medtaget en liste over anbefalede bøger om softwaretest i denne syllabus. Listen over de vigtigste bøger er en del af referenceafsnittet. Version 2007 Side 75 af maj 2007

76 Tillæg D Bemærkning til undervisere Hvert hovedemne i syllabussen er tildelt en tid i minutter. Formålet med dette er både at give en vejledning om den relative mængde tid, der skal afsættes til hvert afsnit i et godkendt kursus og for at give et overslag over det minimum af tid der skal bruges til undervisning for hvert afsnit. Undervisere må bruge mere tid end angivet, og kandidater må også bruge mere tid på læsning og studie. Et kursusforløb behøver ikke at følge samme rækkefølge som den, der er givet i syllabussen. Syllabussen indeholder referencer til etablerede standarder, som skal anvendes ved forberedelsen af undervisningsmaterialet. Hver standard, der anvendes, skal være den der er angivet i den aktuelle version af denne syllabus. Der må også anvendes og refereres til andre publikationer, skabeloner og standarder, der ikke er refereret til i denne syllabus, men der vil ikke blive eksamineret i dem. De specifikke områder i syllabussen, der kræver praktiske øvelser, er som følger: 4.3 Specifikationsbaseret eller black-box-teknikker Praktisk arbejde (korte øvelser) der dækker følgende fire teknikker skal være indeholdt i kurset: ækvivalenspartitionering, grænseværdianalyse, beslutningstabeltest, tilstandsovergangstest. Lektionerne og øvelserne, der er relateret til disse teknikker, bør være baseret på de referencer, der er givet for hver enkelt teknik. 4.4 Strukturbaseret eller white-box-teknikker Praktisk arbejde (korte øvelser) bør være indeholdt vedr. vurdering af om et testsæt opnår 100 % instruktions- og 100 % beslutningsdækning, ligesom design af testcases for nogle givne kontrolflows. 5.6 Hændelseshåndtering Praktisk arbejde (kort øvelse) bør være indeholdt for at dække skrivning og/eller vurdering af en hændelsesrapport. Version 2007 Side 76 af maj 2007

77 Tillæg E Releasenotat syllabus Læringsmål (LM) nummeret for nemmere at kunne huske dem. 2. Ordlyd ændret i følgende LM: (indhold og niveau I LM er uændret): 1.1.5, 1.5.1, 2.3.5, 4.1.3, 4.1.3, 4.1.4, 4.3.2, LM flyttet fra afsnit LM og flyttet fra afsnit 4.1. K-niveau ændret i afsnit LM Skrive en testafviklingsplan for et givent sæt af testcases, når der tages hensyn til prioritering og tekniske og logistiske afhængigheder. (K3) flyttet fra afsnit 4.1 til LM LM Skelne mellem konceptuelt forskellige testmetoder, så som analytisk, modelbaseret, metodisk, process/standard-overensstemmende, dynamisk/heuristisk, konsulterende og regressions-uoverensstemmende. (K2) tilføjet da afsnit 5.2 specificerer emnet og LM manglede. 7. LM Liste testforberedelses- og testafviklingsaktiviteter, som skal overvejes under testplanlægning. (K1) er blevet tilføjet. Tidligere indgik den i afsnit 1.4 og var dækket af LM Afsnit 4.1 er ændret til Testudviklingsprocessen fra Identifikation af testbetingelser og design af testcases. 9. Afsnit 2.1 behandler nu de to udviklingsmodeller, sekventielt versus iterativt-inkrementelt. 10. Begreber kun omtalt i første afsnit de indgår i. Fjernet fra efterfølgende afsnit. 11. Alle begreber i ental. 12. Nye begreber: Fejlangreb (4.5), hændelseshåndtering (5.6), gentest (1.4), fejlgætning (1.5), uafhængighed (1.5), iterativ-inkrementel udviklingsmodel (2.1), statisk test (3.1) og statisk teknik (3.1). 13. Slettede begreber: software, test, udvikling (af software), testbasis, uafhængighedstest, kontraktuel accepttest (2.2), lukning (2.4), modifikation (2.4), migration (2.4), kick-off (3.2), reviewmøde (3.2), reviewproces (3.2). 14. "D" angivelse er blevet flyttet fra afsnit Testdataforberedelsesværktøjer Version 2007 Side 77 af maj 2007

78 Indeks afvigelse...13;47;56;63;73 akkreditering...2;10;11;72 ansvar...20;25;26;31;33 arkitektur...17;22;29 arkivering...19;30 automatisering...29;42;51 beslutningsdækning...37;43;76 beslutningstabeltest...41;42;76 beslutningstest...37;43 betatest...25 Black-box-teknik...37;40;41;76 Black-box-test...25;27;28 bottom-up...26 brugervenlighed...27;28;56 brugervenlighedstest...28;48 bug...12;13 checklister...34;35;62 commercial off the shelf (COTS)...24 dataflow...36 datastyret metode...67 debugging...15;25;61 debuggingværktøjer...65 defekt...13;15;18;26;29;34;44;50;53 defekttæthed...50;53 design af testcases...17;76 driftsaccepttest...49 driftstests...30 drivere...25;64 dynamisk test...15;31;32;36;62 dynamiske analyseværktøjer...65 dækning...29;37;40;41;43;53;66 eksamen...10;11;72 enhedstestmodel...25 enhedstestmodelværktøjer...64 erfaringsbaseret teknik...37;40 fabriksaccepttest...27 fejl...12;13;15;16;20;31;44;53;56;64 fejlgætning...20;51 fejlhyppighed...53 fejltagelse...13;18 flytbarhedstest...28 forbedring...15;19;21;27;66;68 formelt review...31;33 formål for test...12 forventede resultater...18;39;49;58;63;67 funktionalitet...25;50;56;66;68 funktionel test...28 funktionelle krav... 25;26 funktionelle opgaver gentest... 15;18;22;28;29;58;62 gruppereview... 33;34 grænseværdianalyse... 37;76 handlingsord hændelse... 17;39;41;56 hændelsesstyring ikke-funktionel test... 13;28 ikke-funktionelle krav... 22;25;26 indgangskriterier indkapslede systemer inkrementel udviklingsmodel inspektion... 31;33;34;35 inspektionsleder instruktionstest integration... 15;24;25;26 integrationstest... 23;24;25;26;27;36;41;46;73 introduktion af et værktøj i en organisation... 60;68 ISO... 13;29;30;69 kodedækning... 28;29;37;43;50;61 kodelinjedækning kompleksitet... 13;36;63 komponentintegrationstest... 23;29 komponenttest... 23;25;27;29;37;42;43;64 konfigureringsstyring... 46;49;55 kontrolflow... 36;43 krav... 26;32;33;39;53;56;62;63;66;68 kravsspecifikation... 28;34 kravsstyringsværktøjer kundetilpasset software kvalifikation... 71;72 kvalitet... 12;13;56 loadtest... 28;64 loadtestværktøjer lukning... 15;19;22;30 migration modelværktøjer modenhed... 19;33;68 moderator... 33;34 målinger... 33;35;36;46;51;53;62;63;66 nøgleordsstyret metode opfølgning... 33;56 optaget script patches performancetest... 28;67 Version 2007 Side 78 af maj 2007

79 performancetestværktøjer...65;67 Pesticide-paradoks...16 probe-effekt...61 produktrisici...47;56;57 projektrisici...14;47 proof-of-concept...60 prototypefremstilling...23 pålidelighed...13;15;28;51;56 pålidelighedstest...28 påvirkningsanalyse...30;39 rapid application development (RAD)...23 Rational Unified Process (RUP)...23 recorder...34 referent...33;34 regressionstest...17;18;22;28;29;30 regulationsaccepttest...25 review...9;15;20;21;31;32;33;34;35;58 reviewer...33 reviewproces...33;35 risici...20;26;39;47;49;50;53;56;57;60;66 risikobaseret metode...57 risikobaseret test...51;56 robusthedstest...25 roller...31;33;34;35;48;49;50 scriptsprog...63;66;67 sikkerhed...51 sikkerhedstest...28;64 sikkerhedsværktøjer...64 simulatorer...25 softwareudvikling...12;13;72 softwareudviklingsmodeller...22 specifikationsbaseret teknik...29;40 specifikationsbaseret test...28;37 sporbarhed...37;39;49;62;65 stakeholdere...14;40 statisk analyse...15;31;32;36;61 statisk teknik...31 stresstest...28 stresstestværktøjer...64 strukturbaseret test...37;43 strukturel test...28;29 stubbe...25;64 styringsværktøjer...49 systemintegrationstest...23 systemtest...13;15;23;25;26;27;50;73 teknisk review...31;33;34 test af tilstandsovergang...41;76 test af vedligeholdelsesegnethed...28 testafvikling...17;18;44;63;64 testafviklingsplan...39 testafviklingsværktøjer...60;61 testanalyse...49 testansvarlig... 48;49 testbetingelser... 15;17;28;39;40 testcases... 16;18;25;28;32;37;39;40;41;43;53;63;73 testcasespecifikation... 37;39 testdata... 17;18;39;49;66;67 testdesign... 15;17;23;39;44;49;51;66 testdesignteknik... 37;38;39;40 testdesignværktøjer testdækning... 17;51;53 tester... 15;20;22;25;34;46;48;49;66 testestimering test-first-metode testformål... 15;17;23;28;44;45;48;65 testgrundlag... 15;17;25;51 testharness... 18;55;61 testindsats testkontrol... 46;53 testleder... 46;48;49 testlog... 17;63 testmetoder... 23;29;49;51;53 testmiljø... 18;19;25;49;54;63 testmål... 22;28 testniveauer... 20;22;23;28;29;30;37;41;43;45;48;49;50 testorakel... 63;64 testovervågning... 46;53 testplan... 17;46 testplanlægning... 46;49;50;55;57 testprincipper... 12;16 testprocedure... 37;39 testprocedurespecifikation... 37;39 testrapport testrapportering testrække tests 15;16;17;18;22;23;26;28;29;32;39;41;44;46 ;49;51;54;55;56;57;61;62;63;66;67;68;73 testsammendragsrapport... 17;18;53 testscript teststrategi... 17;49;50 teststyret udvikling teststyring teststyringsværktøjer testtyper... 22;30;49 testware... 17;18;19;49;62;65 top-down transaktionsprocesrækkefølge typer af testværktøjer uafhængighed... 20;48;49 udforskende test... 44;51;63 udgangskriterier... 17;18;33;35;46;50;53 Version 2007 Side 79 af maj 2007

80 udtømmende test...16 udvikling...14;15;22;23;25;32;45;50;58;71;74 uformelt review...31;33;34 undervisningsformål...10;11;73 use cases...23;26;28;42 use casetest...37 validering...23 vedligeholdelsestest...22;30 verifikation...15;17;63 versionsstyring... 55;61 V-model værktøjssupport... 25;32;60;66 værktøjssupport til test walkthrough... 31;33;34 White-box test... 28;43 White-box-teknik... 37;40;43;76 ækvivalensklasse... 37;41 ændringer... 25;28;29;30;39;42;55;66 Version 2007 Side 80 af maj 2007