Verifiering & validering -

Transkript

1 Verifiering & validering - INGENJÖRSPROCESSEN forts. METODIK ETSA01 VT13 Verifiering och validering rep. INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT 1 1 Från F3 Verifiering & Validering Verifiering Bygger vi produkten rätt? Följer vi kravspecifikationen? Validering Bygger vi rätt produkt? Kommer beställaren att bli nöjd? Når beställaren sina affärsmål? 2

2 Från F3 Enhetstest Test av minsta testbara komponent Ofta klass eller metod 3 Från F3 Integrationstest Testfall bestäms t ex baserat på specifikationer av gränssnitt i design Test av subsystem

3 Från F3 Systemtest Testar det fullständiga systemet Är kravspecifikationen uppfylld? 5 Från F3 Acceptanstest Test för att säkerställa att utlovat system har utvecklas Kan utföras av beställaren 6

4 Från F3 Black-box vs. White-box Black-box Programmet ses som en svart låda och man utnyttjar inte någon kunskap om koden i samband med definition av testfall Kravspecifikationen används för att ta fram testfall Testar utfall/resultat White-box Kräver tillgång till koden Testar utfall och inre funktion» täcker vi koden?» täcker vi vägarna? 7 Från F3 Ekvivalenspartitionering Hitta värden för in- och utdata som behandlas på inbördes enhetligt sätt ekvivalensklasser ekvivalensklasser indata utdata ekvivalensklasser 8

5 Från F3 Gränsvärdestestning Vanliga gränsvärden Robust-test Kombinationer av gränsfall (vita) (gröna) (röda) variabel 1 variabel 2 9 Från F3 Parvis testning Vissa fel single mode T ex lägga in viss typ av kurs Andra fel uppstår som kombination av två parametrar: T ex lägga in viss typ av kurs för viss institution Parvis testning: täck alla möjliga kombinationer av värden för alla möjliga par av parametrar Eller ännu fler parametrar T ex lägga in viss typ av kurs för viss institution för visst år och viss studentgrupp Antag ett system för att hantera kurser och studenter, med följande parametrar: Kurstyp (G1, G2, A) Institution (CS, EIT, Math, ) År (2006, 2007, 2008, 2015) Studentgrupp (C, D, E, ) 10

6 Verifiering & validering - INGENJÖRSPROCESSEN forts. METODIK ETSA01 VT13 Verifiering och validering forts. INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT White-box testing Kräver tillgång till koden Tanken är att testfallen ska täcka all kod Men vad menas med all kod? Betrakta kodens kontrollflödesgraf 12

7 Täcka rader (statement coverage) Exekvera alla rader minst en gång Alla noder i kontrollflödesgrafen 13 Täcka grenar (branch coverage) Exekvera alla grenar minst en gång Alla bågar i kontrollflödesgrafen Innefattar även komplett radtäckning 14

8 Täcka vägar (path coverage) Exekvera samtliga vägar från startnod till slutnod Innefattar även komplett grentäckning Antalet testfall exploderar med loopar! 4 vägar Hur många vägar? 15 Täcka enkla vägar (simple path coverage) Exekvera samtliga linjärt oberoende vägar från startnod till slutnod Innefattar komplett grentäckning Hanterar problematiken med loopar Ofta en rimlig kompromiss Vägar: (1,1) (0,0) (1,0) (0,1) Ej linjärt oberoende! 16

9 McCabe s Cyclomatic Complexity (CC) Används för att beräkna antalet enkla vägar i en kontrollflödesgraf Antal linjärt oberoende vägar: CC = #bågar - #noder + 2 Krav En enda komponent i grafen En unik startnod samt en unik slutnod 17 Exempel (CC = #bågar - #noder + 2) 3 linjärt oberoende vägar If: CC = = 2 If-else: CC = = 2 2 linjärt oberoende vägar CC = = 3 18

10 Ett lite större exempel CC = #bågar - #noder +2 = = = 4 19 Praktisk testning: Demo av testverktyg 1. Motivering av parvis testning Systemtestning av en diskmaskin 2. Praktiskt exempel Kvalitetssäkring av personnummerklass 1. Webbtjänst Hexawise: Optimala testfall för parvis testning 2. Optimala testfall! testfall i Junit 3. Kodtäckning med CodeCover i Eclipse

11 Parvis testning för systemtest av diskmaskin Testparametrar: Temperatur (45, 55, 65) Miljöläge (on, off) Nedsmutsningsgrad (lätt, måttlig, grov) Utfall: Diskresultat (rent, smutsigt) Temp Miljö Resultat Smuts Parvis testning för systemtest av diskmaskin 3 x 2 x 3 = 18 möjliga testfall

12 Parvis testning Samtliga kombinationer av parameterpar testas En black box-teknik Färre testfall än vad som krävs för uttömmande testning Men en rimlig nivå för att hitta defekter Generera testdata som uppnår parvis täckning med ett minimalt antal testfall är svårt ett kombinatoriskt optimeringsproblem Systemtest diskmaskin: Möjliga par Temperatur-Miljöläge (3 x 2 komb.) 45-on, 45-off 55-on, 55-off 65-on, 65-off Temperatur-Nedsmutsningsgrad (3 x 3 komb.) Miljöläge-Nedsmutsningsgrad (2 x 3 komb.)

13 Parvis testning för systemtest av diskmaskin! Temp.! Miljö.! Smuts! T1! 45! On! Lätt! T2! 55! Off! Lätt! T3! 65! On! Lätt! T4! 45! Off! Medel! T5! 55! On! Medel! T6! 65! Off! Medel! T7! 45! On! Grov! T8! 55! Off! Grov! T9! 65! On! Grov! 9 testfall räcker för att testa alla parameterpar Demo Verifiering av praktisk & validering testning - INGENJÖRSPROCESSEN forts. METODIK ETSA01 VT13 INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT 26 26

14 extern modul för personnummer Nytt krav på cykelgaraget! Beställaren vill att ha stöd för personnummer Del av betalningsmodellen Projektet bestämmer sig för att integrera funktionalitet hittad i öppen källkod Kvalitetssäkring av den externa koden krävs Hur gör man? Verifieringsapproach Skapande av testfall genom black box-tekniker Ekvivalenspartitionering Parvis testning White box-testning för att avgöra testkvalitet Kodtäckningstestning

15 Personnummerkoll för användare Personnummer anges enligt format: XXXXXX-XXXX eller XXXXXX+XXXX (standard: + betyder > 100 år) XXXXXXXX-XXXX (long format) XXXXXXXXXX (short format) Sista siffran är en kontrollsiffra (Luhn-algoritmen) Istället för accepteras även / Personer klassificeras i en ålderskategori <10, 10-18, 18-65, 66-99, >99 Vi identifierar följande ekvivalensklasser: User category (child, teen, adult, senior, golden) ID format (standard, short, long) Separator (-, /) Only digits (true, false) Input date (valid, future date, invalid month, invalid day) Checksum (correct, incorrect) Personnummerkoll för användare ID format Separator Only digits Input date Checksum User category Vi identifierar följande ekvivalensklasser: User category (child, teen, adult, senior, golden) ID format (standard, short, long) Separator (-, /) Only digits (true, false) Input date (valid, future date, invalid month, invalid day) Checksum (correct, incorrect) Vi kan inte testa 5 x 3 x 2 x 2 x 4 x 2 = 480 kombinationer

16 Hexawise Verktyg för att generera testfall för parvis täckning Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise testfall täcker alla exvivalensklasspar Category! Format! Sep! Only digits! Birth date! Checksum! Test 1! child! standard! -! TRUE! correct! correct! Test 2! child! short! /! FALSE! future date! incorrect! Test 3! child! long! /! TRUE! invalid month! correct! Test 4! child! standard! -! FALSE! invalid day! incorrect! Test 5! teen! short! -! TRUE! correct! incorrect! Test 6! teen! standard! /! TRUE! future date! correct! Test 7! teen! standard! -! FALSE! invalid month! correct! Test 8! teen! long! -! TRUE! invalid day! correct! Test 9! adult! long! /! FALSE! correct! incorrect! Test 10! adult! standard! -! TRUE! future date! correct! Test 11! adult! short! /! FALSE! invalid month! correct! Test 12! adult! short! /! FALSE! invalid day! incorrect! Test 13! senior! standard! -! TRUE! correct! correct! Test 14! senior! long! /! FALSE! future date! incorrect! Test 15! senior! short! -! FALSE! invalid month! incorrect! Test Lund 16! University senior! Computer Science short! ETSA01 Ingenjörsprocessen -! TRUE! - Metodik VT13 Exercise invalid 1 day! incorrect! 32

17 Formulera testfallen i JUnit Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise testfall täcker alla exvivalensklasspar Category! Format! Sep! Only digits! Birth date! Checksum! Test 1! child! standard! -! TRUE! correct! correct! Test 2! child! short! /! FALSE! future date! incorrect! Några av förslagen är omöjliga man måste hitta dem själv Test 3! child! long! /! TRUE! invalid month! correct! Test 4! child! standard! -! FALSE! invalid day! incorrect! Test 5! teen! short! -! TRUE! correct! incorrect! Test 6! teen! standard! /! TRUE! future date! correct! Test 7! teen! standard! -! FALSE! invalid month! correct! Test 8! teen! long! -! TRUE! invalid day! correct! Test 9! adult! long! /! FALSE! correct! incorrect! Test 10! adult! standard! -! TRUE! future date! correct! Test 11! adult! short! /! FALSE! invalid month! correct! Test 12! adult! short! /! FALSE! invalid day! incorrect! Test 13! senior! standard! -! TRUE! correct! correct! Test 14 senior! long! /! FALSE! future date! incorrect! Test 15! senior! short! -! FALSE! invalid month! incorrect! Test Lund 16! University senior! Computer Science short! ETSA01 Ingenjörsprocessen -! TRUE! - Metodik VT13 Exercise invalid 1 day! incorrect! 34

18 Mäta kodtäckning med CodeCover Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 35 Summering: Parvis testning och kodtäckning 1. Generera testfall för parvis testning 2. Implementera de möjliga testfallen i JUnit 3. Exekvera testfallen med CodeCover Kodtäckning 83% - vad innebär det? Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 36

19 Testning är dyrt! Testning ofta den enskilt dyraste aktiviteten i ett utvecklingsprojekt $$$ När är testningen färdig? Finns inga garantier att alla defekter är hittade! Man kan alltid testa mer Avbryta för sent Avbryta för tidigt Slösade resurser Försenad release Ökade kostnader Defekter finns kvar Missnöjda användare Dyr support Dyrt underhåll

20 Snabbguide på hemsidan Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 39

21 Föreläsning 4: Design och praktisk testning INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT 53 Agenda Ingen kursinformation Läs webben och kursplanen i kompendiet 2. fråga projekthandledarna MS1 på onsdag & MS2 på måndag Kan 6 personer göra flera saker samtidigt? Arkitektur, design, kodning, produktlinjer 54 Test fortsättning: White box Demo - datorstödd testning: Optimala par ==> JUnit testfall i eclips ==>kodtäckning

22 Arkitektur & Design INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT 55 Design är både en aktivitet och ett resultat 56

23 Design Resurser Produktmål Tidplan Projektplan Idé Affärsmål Användarfall Risker Krav Design Gränssnitt hårdvara Funktionella krav Kvalitetskrav Granskning Validera Kodgranskning Kravtäckning Utvärdering Underhåll Release Support Releasebeslut Acceptanstest Testdokumentation Felrapport Systemtest Gränsvärde Whitebox Ekvivalensklasser Återanvänd kod Programkod Blackbox Kodtäckning Integrationstest Versioner Applikation Varianter Konfigurationer Enhetstest 57 Modulär nedbrytning Helt system Helt system Helt system M1 M1 M11 M12 M2 M3 M2 M21 M3 M22 58

24 men man kan ju även designa bottom-up M1 M11 M12 Hela systemet M11 M12 M21 M22 M2 M21 M22 M3 M1 M11 M12 M2 M3 M21 M22 59 Alltså Idé Affärsmål Validera Utvärdering Underhåll Produktmål Användarfall Release Funktionella krav Support Tidplan Resurser Kvalitetskrav Releasebeslut Risker Kravtäckning Projektplan Acceptanstest Krav Testdokumentation Granskning Felrapport Design Systemtest Gränsvärde Gränssnitt hårdvara Kodgranskning Whitebox Ekvivalensklasser Återanvänd kod Integrationstest Programkod Blackbox Kodtäckning Versioner Applikation Varianter Konfigurationer Enhetstest Idé Affärsmål Validera Utvärdering Underhåll Produktmål Användarfall Release Funktionella krav Support Tidplan Resurser Kvalitetskrav Releasebeslut Risker Kravtäckning Projektplan Acceptanstest Krav Testdokumentation Granskning Felrapport Design Systemtest Gränsvärde Gränssnitt hårdvara Kodgranskning Whitebox Ekvivalensklasser Återanvänd kod Integrationstest Programkod Blackbox Kodtäckning Versioner Applikation Varianter Konfigurationer Enhetstest Top-down Bottom-up Toppom-dup 60

25 Koppling I hur stor utsträckning är enheter i programmet kopplade till varandra? Man vill ha låg koppling 61 Koppling påverkas av Idé Affärsmål Validera Utvärdering Underhåll Produktmål Användarfall Release Funktionella krav Support Tidplan Resurser Kvalitetskrav Releasebeslut Risker Kravtäckning Projektplan Acceptanstest Krav Testdokumentation Granskning Felrapport Design Systemtest Gränsvärde Gränssnitt hårdvara Kodgranskning Whitebox Ekvivalensklasser Återanvänd kod Integrationstest Programkod Blackbox Kodtäckning Versioner Applikation Varianter Konfigurationer Enhetstest Idé Affärsmål Validera Utvärdering Underhåll Produktmål Användarfall Release Funktionella krav Support Tidplan Resurser Kvalitetskrav Releasebeslut Risker Kravtäckning Projektplan Acceptanstest Krav Testdokumentation Granskning Felrapport Design Systemtest Gränsvärde Gränssnitt hårdvara Kodgranskning Whitebox Ekvivalensklasser Återanvänd kod Integrationstest Programkod Blackbox Kodtäckning Versioner Applikation Varianter Konfigurationer Enhetstest Antal gränssnitt mellan olika delar Typ av gränssnitt Enkla gränssnitt ger lägre koppling än komplicerade gränssnitt Åtkomst av interna detaljer ger högre koppling än endast anrop av funktioner Kommunikation av endast data ger lägre koppling än kommunikation av kontrollinformation Helt system M1 M2 M11 M12 M3 M21 M22 62 Vid objektorientering komponent-nivå-koppling t ex när en klass har en annan klass som instansvariabel Interaktionskoppling (som gränssnitt ovan) Koppling baserat på ärvning

26 Samhörighet (Cohesion) 63 Hur väl innehållet i en del hänger samman Slumpvis inga meningsfulla beroenden, bara paketerat Logiskt t ex en modul som sköter all utmatning av data Temporal t ex en modul som sköter all uppstart eller avslut Procedurbaserad när procedurer som utförs efter varandra slås ihop, t ex innehållet i en loop Kommunikationsbaserad när delar som behandlar samma data slås ihop Sekvensiell när serier av procedurer som utgör indata till varandra slås samman Idé Affärsmål Validera Utvärdering Underhåll Produktmål Användarfall Release Funktionella krav Support Tidplan Resurser Kvalitetskrav Releasebeslut Risker Kravtäckning Projektplan Acceptanstest Krav Testdokumentation Granskning Felrapport Design Systemtest Gränsvärde Gränssnitt hårdvara Kodgranskning Whitebox Ekvivalensklasser Återanvänd kod Integrationstest Programkod Blackbox Kodtäckning Versioner Applikation Varianter Konfigurationer Enhetstest Idé Affärsmål Validera Utvärdering Underhåll Produktmål Användarfall Release Funktionella krav Support Tidplan Resurser Kvalitetskrav Releasebeslut Risker Kravtäckning Projektplan Acceptanstest Krav Testdokumentation Granskning Felrapport Design Systemtest Gränsvärde Gränssnitt hårdvara Kodgranskning Diskutera i grupper om 2-3 personer Whitebox Ekvivalensklasser Återanvänd kod Integrationstest Programkod Blackbox Kodtäckning Versioner Applikation Varianter Konfigurationer Enhetstest Varför är det viktigt med låg koppling och hög samhörighet i allmänhet i ert projekt Hur ska man göra för att uppnå detta rent konkret i ett projekt som ert? Helt system M1 M11 M12 M2 M21 M22 M3 64

27 Mål med en arkitekturdesign - dokumentet Förståelse och kommunikation Möjliggöra återanvändning på hög nivå Stöd för konstruktion och utveckling Underlag för analys 65 Arkitekturdesign, olika vyer Idé Affärsmål Validera Utvärdering Underhåll Produktmål Användarfall Release Funktionella krav Support Tidplan Resurser Kvalitetskrav Releasebeslut Risker Kravtäckning Projektplan Acceptanstest Krav Testdokumentation Granskning Felrapport Design Systemtest Gränsvärde Gränssnitt hårdvara Kodgranskning Whitebox Ekvivalensklasser Återanvänd kod Integrationstest Programkod Blackbox Kodtäckning Versioner Applikation Varianter Konfigurationer Enhetstest Idé Affärsmål Validera Utvärdering Underhåll Produktmål Användarfall Release Funktionella krav Support Tidplan Resurser Kvalitetskrav Releasebeslut Risker Kravtäckning Projektplan Acceptanstest Krav Testdokumentation Granskning Felrapport Design Systemtest Gränsvärde Gränssnitt hårdvara Kodgranskning Whitebox Ekvivalensklasser Återanvänd kod Integrationstest Programkod Blackbox Kodtäckning Versioner Applikation Varianter Konfigurationer Enhetstest Modul-beskrivning t ex programkod med relationer Klass A är beroende av Klass B Komponenter och konnektorer t ex binärer och kopplingar Object A delar data med objekt B Allokeringsbeskrivningar fysisk allokering av systemets komponenter låsreglerna finns i systemet, låstimern finns i dörrposten 66

28 Arkiterturer - exempel /patterns Delad data gemensam information repository Client-server -modellen Klient 1 Klient 2 Klient n Nätverk Delsystem 1 Delsystem 2 Delsystem n Betj. 1 Betj. 1 Betj. m Abstract-machine modellen / Layered system Pipes and filters Hur ska man välja arkitektur? Idé Affärsmål Validera Utvärdering Underhåll Produktmål Användarfall Release Funktionella krav Support Tidplan Resurser Kvalitetskrav Releasebeslut Risker Kravtäckning Projektplan Acceptanstest Krav Testdokumentation Granskning Felrapport Design Systemtest Gränsvärde Gränssnitt hårdvara Kodgranskning Whitebox Ekvivalensklasser Återanvänd kod Integrationstest Programkod Blackbox Kodtäckning Versioner Applikation Varianter Konfigurationer Enhetstest Idé Affärsmål Validera Utvärdering Underhåll Produktmål Användarfall Release Funktionella krav Support Tidplan Resurser Kvalitetskrav Releasebeslut Risker Kravtäckning Projektplan Acceptanstest Krav Testdokumentation Granskning Felrapport Design Systemtest Gränsvärde Gränssnitt hårdvara Kodgranskning Whitebox Ekvivalensklasser Återanvänd kod Integrationstest Programkod Blackbox Kodtäckning Versioner Applikation Varianter Konfigurationer Enhetstest Kvalitetskrav påverkar beslutet, t ex: Prestanda (svarstid, genomströmning) - Inte för mycket kommunikation, Säkerhet mot intrång (Security) - Kritiska funktioner i lägre lager, Säkerhet för användaren (Safety) - Operationer i begränsat antal moduler, Underhållbarhet - Komponenter som är lätta att förstå för sig själva, låg komplexitet, Tillgänglighet - Redundanta komponenter, 68

29 Whitebox Några förslag: Graph impurity Informationsflöde = size * (inflow * outflow)2 Weighted methods per class:... WMC= n i=1 c i Helt system M1 M11 M12 M2 M21 M22 M3 69 Inte uppenbart hur man ska mäta detta! Ett förslag: Graph impurity Idé Affärsmål Validera Utvärdering Underhåll Produktmål Användarfall Release Funktionella krav Support Utvärdering - Mått på design? Tidplan Resurser Kvalitetskrav Releasebeslut Risker Kravtäckning Projektplan Acceptanstest Krav Testdokumentation Granskning Felrapport Design Systemtest Gränsvärde Gränssnitt hårdvara Kodgranskning Hur avgör man om en design är bra? Ekvivalensklasser Återanvänd kod Integrationstest Programkod Blackbox Kodtäckning Versioner Applikation Varianter Konfigurationer Enhetstest Idé Affärsmål Validera Utvärdering Underhåll Produktmål Användarfall Release Funktionella krav Support Tidplan Resurser Kvalitetskrav Releasebeslut Risker Kravtäckning Projektplan Acceptanstest Krav Testdokumentation Granskning Felrapport Design Systemtest Gränsvärde Gränssnitt hårdvara Kodgranskning Whitebox Ekvivalensklasser Återanvänd kod Integrationstest Programkod Blackbox Kodtäckning Versioner Applikation Varianter Konfigurationer Enhetstest GI = n e 1 n = antal noder e = antal bågar GI = 0: perfekt Är detta ett bra mått på en design? - Varför? - Varför inte? 6-5-1= = -8 70

30 Design/arkitektur handlar också om att fördela ansvar Idé Affärsmål Validera Utvärdering Underhåll Produktmål Användarfall Release Funktionella krav Support Tidplan Resurser Kvalitetskrav Releasebeslut Risker Kravtäckning Projektplan Acceptanstest Krav Testdokumentation Granskning Felrapport Design Systemtest Gränsvärde Gränssnitt hårdvara Kodgranskning Whitebox Ekvivalensklasser Återanvänd kod Integrationstest Programkod Blackbox Kodtäckning Versioner Applikation Varianter Konfigurationer Enhetstest Varje modul/klass/etc ska utvecklas av någon Person, avdelning, företag, Även resurser i organisationen kan påverka design/arkitektur Organisation speglar design (och vice versa?) 71 Kort om kodning INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT 72

31 Kodning Kombineras med enhetstestning Kodningsstandarder kan finnas Kodgranskningar kan utföras 73 Ett exempel på en kodningsstandard (Java) Basic - File names - File organization - Indention (4 characters) - Comments - Declarations (1/line) - Statements (if always with {}) - White space (2 lines between ) - Naming conventions Additional - Naming (semantic consistency, understandable abbreviations, ) - Constant names instead of raw numbers) - Every class should have a comment - Avoid static variables - File size < 200 LOC 74

32 Varför vill man ha denna typ av standarder? Ökad rörlighet Personer kan gå mellan projekt Erfarenheter best practice Trovärdighet Vilka problem finns att införa standarder? Vad kan man göra för att komma tillrätta med problemen? 75 Plattformar & produktlinjer INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT 76

33 Design kursens projekt Ingen mall finns Alla klasser ska beskrivas Namn, konstruktorer, publika metoder, ärvning Ange även ansvarig för klasser/metoder Rita grafiskt (klassdiagram) Följ gränssnitt enligt projektbeskrivningen. 81 Design - sammanfattning och i andra kurser -> ingår inte i denna kurs Design görs på olika nivåer: arkitektur -> design -> kodning Man vill ha låg koppling och hög sammanhållning Exempel på vanliga arkitekturer: delad data, client server, layered system, pipes and filters Kvalitetskravkrav påverkar arkitekturen Plattformsbaserad utveckling ger parallellism och kortare tid till marknad, men också ökad komplexitet 82

34 Förläsning 5 inleds med en tecknad serie 83 Verifiering & validering - forts. INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT 84

35 White-box testing Kräver tillgång till koden Tanken är att testfallen ska täcka all kod Men vad menas med all kod? 85 Täcka rader Exekvera alla rader minst en gång t.ex. 2 vägar genom if-then-else, och en väg genom if-then Verktyg finns! 86

36 Täcka vägar CC = Cyclomatic Complexity Följa alla linjärt oberoende vägar minst en gång. - T ex 2 vägar för if-then-elsestatement precis som för if-then Visualisera eventuellt genom att rita graf Antal linjärt oberoende vägar: CC = #(bågar) - #(noder) Enkla exempel If: CC = = 2 If-else: CC = = 2 CC = = 3 88

37 Ett lite större exempel CC = #bågar - #noder +2 = = = 4 CC används också som ett mått på komplexitet 89 Andra förslag på white box test Branch coverage täcka alla bågar Simple path coverage alla vägar, utan att ta hänsyn till om de är linjärt oberoende) 90 [Fenton et al., Software Metrics a Rigorous and Practical Approach ] CC = = 3