Diskutera medan vi väntar Ingen kursinformation idag. MS1 på onsdag MS2 på onsdag efter påsk. 1. Läs kurswebben och kursplanen och egen projektplan 2. Fråga projekthandledarna Föreläsning 4: och praktisk testning Ingenjörsprocessen metodik ETSA01 VT14 Jonas Wisbrant 161 162 Agenda Arkitektur, design, kodning, produktlinjer Test fortsättning: White box Demo - datorstödd testning: Optimala par ==> JUnit testfall i eclips ==> Arkitektur & Ingenjörsprocessen metodik ETSA01 VT14 Jonas Wisbrant 163 164
täckning är både en aktivitet och ett resultat täckning 165 166 Modulär nedbrytning men man kan ju även designa bottomup Helt system Helt system M1 M2 M3 M1 Helt system M2 M21 M22 M11 M3 M12 M11 M12 M21 M22 M1 M11 M12 M2 M21 M22 M3 Hela systemet M1 M11 M12 M2 M21 M22 M3 167 168
täckning täckning täckning täckning Alltså Koppling Top-down Bottom-up Toppom-dup I hur stor utsträckning är enheter i programmet kopplade till varandra? Man vill ha låg koppling 169 170 Koppling påverkas av Samhörighet (Cohesion) 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 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 M1 M2 M21 M22 M11 M3 M12 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 Funktionell när innehållet står för en enstaka funktion, t ex sortera vektor 171 172
täckning täckning täckning täckning Diskutera i grupper om 2-3 personer Mål med en arkitekturdesign - dokumentet 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? 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 Helt system M1 M11 M12 M2 M21 M22 M3 173 174 Arkitekturdesign, olika vyer Arkiterturer - exempel /patterns 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 Delad data Del- system 1 gemensam information repository Del- system 2 Del- system 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 175 176
Delad data gemensam information repository Client-server -modellen Klient 1 Klient 2 Delsystem 1 Delsystem 2 Delsystem n Fördelar: Svårigheter: - Effektivt med mycket data - Alla delsystem använder samma dataform - De som producerar data måste inte veta så mycket om mottagaren - Backup, etc lätt Nätverk Betj. 1 Betj. 1 Betj. m Fördelar: - Vidareutveckling kan vara svårt eftersom mycket bygger på en viss datamodell Distribuerad arkitektur Lätt att lägga till klienter och betjänare X Klient n Nya enheter måste kanske anpassas Ingen gemensam datamodell Svårigheter: X V-modellen för programvaruutvecking Layered system: Exempel OSI - referensarkitektur Hur ska man välja arkitektur? - 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, 177 Säkerhet mot intrång (Security) - Inte för mycket kommunikation, - Redundanta komponenter, Prestanda (svarstid, genomströmning) Tillgänglighet täckning påverkar beslutet, t ex: X
täckning täckning täckning - 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 c i i=1 Helt system 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? M1 M11 M12 M2 M21 M22 M3 178 Inte uppenbart hur man ska mäta detta 179 6-5-1=0 6-13 - 1 = -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 VT14 Jonas Wisbrant Även resurser i organisationen kan påverka design/arkitektur Organisation speglar design (och vice versa?) 180 181
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 182 183 Varför vill man ha denna typ av standarder? Ökad rörlighet Personer kan gå mellan projekt Plattformar & produktlinjer Ingenjörsprocessen metodik ETSA01 VT14 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? 184 185
Plattformar inom produktutveckling Software product line Inte bara inom programvara: Black & Decker Battery Pack Motor Pack A software product line is a set of software-intensive systems that share a common, managed set of feature that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. F k1 F k2 F kn Bilindustri Peugeot, Fiat, Toyota, etc Plattform v. k F k+1.1 F k+1.2 F k+1.m Plattform v. k+1 186 187 Vad innebär detta? kursens projekt Parallell utveckling ==> lägre kostnader, fler produkter, kortare tid till marknad per produkt Ökad komplexitet: t ex nya krav och påverkar flera produkter (och plattformar). Mer komplexa projektplaner, testning, organisation Långsiktiga beslut för plattform, kortsiktiga beslut för produkter Ingen mall finns Alla klasser ska beskrivas Namn, konstruktorer, publika metoder, ärvning Ange även ansvarig för klasser/metoder Nya produkter innehåller funktioner från tidigare produkter -> I stort sett aldrig specifikation från 0. Mycket arv Rita grafiskt (klassdiagram) Följ gränssnitt enligt projektbeskrivningen. 188 189
Föreläsning 5 inleds med en tecknad serie - sammanfattning 6.2 6.5 och 7.1.1 7.1.3 i andra kurser -> ingår inte i denna kurs 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 krav påverkar arkitekturen Plattformsbaserad utveckling ger parallellism och kortare tid till marknad, men också ökad komplexitet 190 191 Från F3 Black-box vs. White-box Verifiering och & validering Verifiering validering- forts. rep. 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 Testar utfall/resultat Ingenjörsprocessen metodik ETSA01 VT13 INGENJÖRSPROCESSEN METODIK ETSA01 VT14 Jonas Wisbrant White-box Kräver tillgång till koden Testar utfall och inre funktion - täcker vi koden? - täcker vi vägarna? 1921 193
Från F3 Från F3 Ekvivalenspartitionering stestning Hitta värden för in- och utdata som behandlas på inbördes enhetligt sätt Vanliga gränsvärden Robust-test (gröna) (röda) ekvivalensklasser Kombinationer av gränsfall (vita) ekvivalensklasser indata utdata variabel 1 ekvivalensklasser 194 195 variabel 2 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, ) Verifiering och & validering - forts. INGENJÖRSPROCESSEN Ingenjörsprocessen metodik METODIK ETSA01 ETSA01 VT13 VT14 Jonas Wisbrant 196 197 6
White-box testing Täcka rader (statement coverage) 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 Exekvera alla rader minst en gång Alla noder i kontrollflödesgrafen 198 199 Täcka grenar (branch coverage) Täcka vägar (path coverage) Exekvera alla grenar minst en gång Alla bågar i kontrollflödesgrafen Innefattar även komplett radtäckning 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? 200 201
Täcka enkla vägar (simple path coverage) McCabe s Cyclomatic Complexity (CC) Exekvera samtliga linjärt oberoende vägar från startnod till slutnod Innefattar komplett grentäckning Hanterar problematiken med loopar Ofta en rimlig kompromiss 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 1 1 0 0 Vägar: (1,1) (0,0) (1,0) (0,1) Ej linjärt oberoende En enda komponent i grafen En unik startnod samt en unik slutnod 202 203 Exempel (CC = #bågar - #noder + 2) Ett lite större exempel CC = #bågar - #noder +2 = = 16-14+2 = 4 3 linjärt oberoende vägar If: CC = 3-3+2 = 2 If-else: CC = 4-4+2 = 2 2 linjärt oberoende vägar CC = 8-7+2 = 3 204 205
Praktisk testning: Demo av testverktyg Parvis testning för systemtest av diskmaskin 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 Testparametrar: Temperatur (45, 55, 65) Miljöläge Nedsmutsningsgrad Utfall: Diskresultat Temp (on, off) (lätt, måttlig, grov) (rent, smutsigt) Miljö Resultat Smuts 206 207 Parvis testning för systemtest av diskmaskin 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 3 x 2 x 3 = 18 möjliga testfall 208 209
diskmaskin: Möjliga par Temperatur-Miljöläge 45-on, 45-off 55-on, 55-off 65-on, 65-off (3 x 2 komb.) Temperatur-Nedsmutsningsgrad (3 x 3 komb.) Miljöläge-Nedsmutsningsgrad (2 x 3 komb.) 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 210 211 9 testfall räcker för att testa alla parameterpar extern modul för personnummer Demo Verifiering av praktisk & validering testning- forts. INGENJÖRSPROCESSEN Ingenjörsprocessen metodik METODIK ETSA01 ETSA01 VT13 VT14 Jonas Wisbrant 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? 212 21 213
Verifieringsapproach Personnummerkoll för användare Skapande av testfall genom black box-tekniker Ekvivalenspartitionering Parvis testning White box-testning för att avgöra testkvalitet stestning 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) 214 215 Personnummerkoll för användare Hexawise ID format Separator Only digits Input date Checksum User category Verktyg för att generera testfall för parvis täckning 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) 216 Vi kan inte testa 5 x 3 x 2 x 2 x 4 x 2 = 480 kombinationer 217
218 Category Format Sep Only digits Birth date Checksum Test 1 child standard - TRUE correct correct 20 testfall täcker alla exvivalensklasspar 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 Jonas Wisbrant ETSA01 - Ingenjörsprocessen TRUEmetodik invalid day incorrect 219 Formulera testfallen i JUnit 220 Category Format Sep Only digits Birth date Checksum Test 1 child standard - TRUE correct correct 20 testfall täcker alla exvivalensklasspar Test 2 child short / FALSE future date incorrect Test 3 child long / TRUE invalid month correct Några av förslagen är omöjliga man måste hitta dem själv 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 Jonas Wisbrant ETSA01 - Ingenjörsprocessen TRUEmetodik invalid day incorrect 221 Mäta kodtäckning med CodeCover
Summering: Parvis testning och kodtäckning 1. Generera testfall för parvis testning Testning är dyrt Testning ofta den enskilt dyraste aktiviteten i ett utvecklingsprojekt 2. Implementera de möjliga testfallen i JUnit 3. Exekvera testfallen med CodeCover $$$ 222 83% - vad innebär det? 223 När är testningen färdig? Snabbguide på hemsidan Finns inga garantier att alla defekter är hittade Man kan alltid testa mer Avbryta för sent Avbryta för tidigt Slösade resurser Defekter finns kvar Försenad release Missnöjda användare Ökade kostnader Dyr support 224 Dyrt underhåll 225