Verifiering & Validering. Integrationstest. Enhetstest. Verifiering och & validering rep. -

Transkript

1 Från F3 Verifiering och & validering rep. - INGENJÖRSPROCESSEN forts. METODIK ETSA01 VT13 INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT 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? Från F3 Från F3 Test av minsta testbara komponent Ofta klass eller metod Testfall bestäms t ex baserat på specifikationer av gränssnitt i design Test av subsystem 3

2 Från F3 Från F3 Testar det fullständiga systemet Är kravspecifikationen uppfylld? Test för att säkerställa att utlovat system har utvecklas Kan utföras av beställaren 5 6 Från F3 Från F3 Black-box vs. White-box Ekvivalenspartitionering Black-box Programmet ses som en svart låda och man utnyttjar inte någon kunskap om koden i samband med definition av testfall specifikationen används för att ta fram testfall Hitta värden för in- och utdata som behandlas på inbördes enhetligt sätt ekvivalensklasser ekvivalensklasser Testar utfall/resultat White-box indata utdata Kräver tillgång till koden Testar utfall och inre funktion» täcker vi koden? ekvivalensklasser» täcker vi vägarna? 7 8

3 Från F3 Från F3 stestning Parvis testning Vanliga gränsvärden Robust-test Kombinationer av gränsfall (vita) variabel 1 (gröna) (röda) 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, ) variabel White-box testing Verifiering och & validering forts. - INGENJÖRSPROCESSEN forts. METODIK ETSA01 VT13 INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT 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

4 Täcka rader (statement coverage) Täcka grenar (branch coverage) Exekvera alla rader minst en gång Exekvera alla grenar minst en gång Alla noder i kontrollflödesgrafen Alla bågar i kontrollflödesgrafen Innefattar även komplett radtäckning Täcka vägar (path coverage) Täcka enkla vägar (simple path coverage) Exekvera samtliga vägar från startnod till slutnod Innefattar även komplett grentäckning Antalet testfall exploderar med loopar! Exekvera samtliga linjärt oberoende vägar från startnod till slutnod Innefattar komplett grentäckning Hanterar problematiken med loopar Ofta en rimlig kompromiss 4 vägar Hur många vägar? Vägar: (1,1) (0,0) (1,0) (0,1) Ej linjärt oberoende! 15 16

5 McCabe s Cyclomatic Complexity (CC) Exempel (CC = #bågar - #noder + 2) 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 linjärt oberoende vägar En enda komponent i grafen If: CC = = 2 If-else: CC = = 2 En unik startnod samt en unik slutnod 2 linjärt oberoende vägar CC = = Ett lite större exempel Praktisk testning: Demo av testverktyg CC = #bågar - #noder +2 = = = 4 1. Motivering av parvis testning ning 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. med CodeCover i Eclipse 19

6 Parvis testning för systemtest av diskmaskin 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 3 x 2 x 3 = 18 möjliga testfall Parvis testning diskmaskin: Möjliga par 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 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.)

7 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 extern modul för personnummer Verifieringsapproach 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 Skapande av testfall genom black box-tekniker Ekvivalenspartitionering Parvis testning White box-testning för att avgöra testkvalitet stestning Hur gör man?

8 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 User category Input date Checksum 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 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

9 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 Mäta kodtäckning med CodeCover 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 83% - vad innebär det? Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 35 Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 36

10 Testning är dyrt! När är testningen färdig? Testning ofta den enskilt dyraste aktiviteten i ett utvecklingsprojekt Finns inga garantier att alla defekter är hittade! Man kan alltid testa mer $$$ Avbryta för sent Slösade resurser Försenad release Ökade kostnader Avbryta för tidigt Defekter finns kvar Missnöjda användare Dyr support Dyrt underhåll Snabbguide på hemsidan Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 39

11 Föreläsning 4: och praktisk testning INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT 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 Test fortsättning: White box Demo - datorstödd testning: Optimala par ==> JUnit testfall i eclips ==>kodtäckning Arkitektur & INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT är både en aktivitet och ett resultat 55 56

12 Modulär nedbrytning Helt system Helt system M1 M2 M3 Helt system M1 M2 M11 M12 M3 M21 M men man kan ju även designa bottom-up Alltså M1 M11 M12 Hela systemet Top-down Bottom-up Toppom-dup M11 M12 M21 M22 M2 M21 M22 M3 M1 M11 M12 M2 M3 M21 M

13 Koppling Koppling påverkas av I hur stor utsträckning är enheter i programmet kopplade till varandra? Man vill ha låg koppling 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 M 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 Samhörighet (Cohesion) Diskutera i grupper om 2-3 personer 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 64 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 M2 M21 M22 M11 M3 M12

14 Mål med en arkitekturdesign - dokumentet Arkitekturdesign, olika vyer Förståelse och kommunikation Möjliggöra återanvändning på hög nivå Modul-beskrivning t ex programkod med relationer Klass A är beroende av Klass B Stöd för konstruktion och utveckling Underlag för analys 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 Arkiterturer - exempel /patterns Hur ska man välja arkitektur? Delad data Delsystem 1 gemensam information repository Delsystem 2 Delsystem n Abstract-machine modellen / Layered system Client-server -modellen Klient 1 Klient 2 Klient n Nätverk Betj. 1 Betj. 1 Betj. m Pipes and filters 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, barhet - Komponenter som är lätta att förstå för sig själva, låg komplexitet, Tillgänglighet - Redundanta komponenter, 68

15 - Mått på design? Hur avgör man om en design är bra? Ett förslag: Graph impurity Några förslag: Graph impurity Informationsflöde = size * (inflow * outflow)2 Weighted methods per class:... WMC= n i=1 c i 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? Helt system M1 M11 M12 M2 M21 M22 M3 69 Inte uppenbart hur man ska mäta detta! = = -8 /arkitektur handlar också om att fördela ansvar Varje modul/klass/etc ska utvecklas av någon Person, avdelning, företag, Kort om kodning INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT Även resurser i organisationen kan påverka design/arkitektur Organisation speglar design (och vice versa?) 71 72

16 Kodning Ett exempel på en kodningsstandard (Java) Kombineras med enhetstestning Kodningsstandarder kan finnas ar kan utföras 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 Varför vill man ha denna typ av standarder? Ökad rörlighet Personer kan gå mellan projekt Plattformar & produktlinjer INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT 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 76

17 kursens projekt - sammanfattning Ingen mall finns och i andra kurser -> ingår inte i denna kurs Alla klasser ska beskrivas görs på olika nivåer: arkitektur -> design -> kodning Namn, konstruktorer, publika metoder, ärvning Ange även ansvarig för klasser/metoder Man vill ha låg koppling och hög sammanhållning Exempel på vanliga arkitekturer: delad data, client server, layered system, pipes and filters Rita grafiskt (klassdiagram) krav påverkar arkitekturen Plattformsbaserad utveckling ger parallellism och kortare tid till marknad, men också ökad komplexitet Följ gränssnitt enligt projektbeskrivningen Förläsning 5 inleds med en tecknad serie Verifiering & validering - forts. INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT 83 84

18 White-box testing Kräver tillgång till koden Tanken är att testfallen ska täcka all kod Men vad menas med all kod? 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! Täcka vägar CC = Cyclomatic Complexity Enkla exempel 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 If: CC = = 2 If-else: CC = = 2 Antal linjärt oberoende vägar: CC = #(bågar) - #(noder) +2 CC = =

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