Föreläsning 3 Verifiering och Validering

Transkript

1 ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Föreläsning 3 Verifiering och Validering Jonas Wisbrant 2 Detta har hänt... Pratat och skapat krav och plan Några har kommit i kontakt med IP3-projekt Övning 2 Riskhantering, intressenter och kravgranskning. Genomfört granskningar inför 2 x 0.99? 3

2 Är instruktionerna oklara, projektet rörigt och allmänt frustrerande? Agenda Kursinformation: Kursmål Verifiering och validering Vad är testning? Testprocessen Testtekniker Konfigurationshantering - intro: står inte så tydligt i boken regler för projektet finns i projektmaterialet på kurswebben 5

3 Kursinformation V 3: Nu kl 13 F: Testning, versioner Idag kl 24 deadline: PP SRS föregående granskningar wiki-ice: SMS --> ange: Grupp + problem To 12.30: Kursombudsmöte - tankar och idéer till: Mikael Bergquist & Bjarni Birgersson (C) Per Ahlbom & Alexander Pieta Theofanous (D) Carolin Sundvik (I) To (eller ÖK): Återkoppling på 2 x 0.99 inför MS1 Övning 3: Test Om testfall: T.1-8 (i förväg) Skapa testplan: T V 4: 0.x Individual inspection Inspection meeting Inspection protocoll Supervisor feedback Hög tid att kolla på koden Downloads på: etsa01/projekt2011/ haardvarugraenssnitt_oc h_drivrutiner/ 0.99 Supervisor review Må kl 13 F: Arkitektur, design, kodning, versioner Ti kl 24: MS 1 eller To Ö: Mer om test Good version 7 Better version

4 Kursmål (beställningen) Kunskap och förståelse kunna definiera grundläggande begrepp inom utveckling av stora programvarusystem. kunna beskriva de vanligaste processerna för utveckling av stora programvarusystem. kunna förklara de viktigaste momenten i kravhanteringsprocessen. kunna förklara hur testning går till. kunna beskriva vad en arkitekturdesign är. kunna beskriva de viktigaste stegen i projektplanering och projektuppföljning. kunna beskriva hur organisationer planerar och genomför en serie av projekt. Färdighet och förmåga kunna utveckla projektplan, kravspecifikation och testplan för ett mindre projekt. kunna granska projektplan, kravspecifikation och testplan för ett mindre projekt. kunna skriftligen formulera text i projektdokumentation. Värderingsförmåga och förhållningssätt förstå komplexiteten i uppgiften att utveckla ett programvarusystem. ha förståelse för ingenjörens yrkesroll. 8 Varför trillade den första Ariane V-raketen ned?

5 Verifiering och validering 10 Verifiering bygger vi produkten rätt? Dvs följer vi kravspecifikationen? Validering bygger vi rätt produkt? Dvs kommer beställaren att bli nöjd? 11

6 Varför testar man? Man vill hitta fel för att man vill förbättra produkten Man vill visa att produkten är bra Man vill ta reda på hur många fel som finns i produkten för att man vill veta hur bra produkten är. men oavsett vilket så kan man aldrig visa att det inte finns fel, bara att det finns fel 12 Fel, fel, och fel Fault Fel (failure) Fel Fel (error) felrättning felidentifiering observation av fel 13

7 Testprocessen och integration [Acceptanstest] system systemtest. up m to t Bo p To do n w integrationstest. enhetstest. komponenter = består av 14 Testprocessen, V-modellen Acceptanstest (VoV) Kravhantering Systemtest (Verifiering) Integrations-test Design Implementation Enhetstest 15

8 Dynamisk vs statisk testning Dynamisk testning: Exekvera programmet för att hitta fel Statisk testning: Hitta fel utan att exekvera programmet projekt statisk dynamisk Verktyg? Ja tack! Statiskt Done! 16 Enhetstest, testfall för procedurer För att testa procedur F(x1,...xn), gör följande: 1. Sätt tillstånd till rätt värde 2. Definiera värden för parametrar x1, xn 3. Anropa Svar = F(x1,...xn) 4. Jämför Svar med rätt resultat 5. Registrera om resultatet var korrekt eller inte Kan stödjas med verktyg, t ex CuTest, CUnit, Med objektorientering kan t ex JUnit användas 17

9 Integrationstest/Systemtest Testfall bestäms t ex baserat på specifikationer av gränssnitt i design Test utförs i samband med integration av olika delar av systemet Testfall måste utföras för varje del som integreras --> automatisering önskvärd Regressionstest = upprepad testning vid ändring av programvara Kan utföras under utveckling och under underhåll 18 Testplanering Indata: Projektplan Kravspec... Design Manual Prototyper... Testplanering Testplan: Testprocess (t ex stat / dyn, miljö) Kravspårning Testobjekt Tidplan (test) Dokumentation av resultat HW & SW requirements Begränsningar Testfall 19

10 Testfall, två exempel Test case: Buy cola Pre-condition: Machine in start state. Post-condition: Machine in start state. A cola can received. 1.Press the cola selection button. 2.Insert a 10kr coin. 3.Insert a 5kr coin. 4.Receive a cola can. Test case: Press more than one button Pre-condition: Machine in start state. Post-condition: Machine in start state. A water can is received. 1.Press the water selection button. 2.Press the beer selection button. 3.Insert a 5kr coin. 4.Receive a water can. Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F3 20 Spårbarhet mot krav Alla krav ska testas av minst ett testfall Alla testfall ska testa minst ett krav Detta kan t ex visas i en matris (krav x testfall) i testplanen 21

11 Black-box vs. White-box Black-box Programkoden ses som en svart låda och man utnyttjar inte någon kunskap om koden i samband med definition av testfall White-box - Kräver tillgång till koden - Tanken är att testfallen ska täcka all kod Kravspecifikationen används för att ta fram testfall 22 Black-box -test Programkoden 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 23

12 Ekvivalenspartitionering Hitta värden för in och utdata som behandlas på samma sätt Komponent 24 Gränsvärdestestning För n variabler, ett intervall var vanlig gränsvärden : innanför eller på gränser => 4n+1 testfall (gröna) Variabel 1 Robust-test: även utanför gränserna => 6n+1 testfall (röda) worst-case : även alla kombinationer av gränsfall (men inte robust-test): 5^n testfall (vita) Variabel 2 25

13 Parvis testning Antag ett system för att hantera kurser och studenter, med följande parametrar: Kurstyp (G1, G2, A) Institution (CS, EIT, Matematik, ) År (2006, 2007, 2008, 2015) Studentgrupp (C, D, E, ) 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 Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F3 26 Parvis testning värden parametrar n parametrar med m möjliga värden vardera ger m 2 par av värden för varje par av parametrar Första med resten ger m 2 (n-1) par, andra med resten m 2 (n-2) par, osv Antal par = Varje testfall täcker n # m 2 (n " k) = m 2 #(n " k) = m 2 n k=1! Om varje testfall täcker olika par krävs det alltså m 2 testfall I praktiken omöjligt ha unika par för varje testfall! och olika antal värden för olika parametrar n k=1 n"1 # (n " n) + (n "1) 2 n"1 # (n "1) + (n " 2) = i = i = n(n "1) /2 i=1 i= 0 = m 2 n(n "1) /2 par 27

14 Stresstestning Kontrollera vad som händer vid hög belastning, t ex: Telefonväxel # telefoner > max # samtidiga samtal > max ERROR: ArrayOutOfBounds? 28 White-box testing Kräver tillgång till koden Tanken är att testfallen ska täcka all kod Men vad menas med all kod? 29

15 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 användbara 30 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) +2 31

16 Enkla exempel If: CC = = 2 Statement cov: 1 If-else: CC = = 2 Statement cov: 2 CC = = 3 Statement cov: 2 32 Ett lite större exempel CC = #bågar - #noder +2 = = = 4 CC används också som ett mått på komplexitet 33

17 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) [Fenton et al., Software Metrics a Rigorous and Practical Approach ] 34 Genomförande av test och rapportering I simulerad miljö endast i utvecklingsmiljön I mer verklig miljö i testuppsättning Tänk kommunikation: - mellan individer och organisationer - över tiden I verklig miljö Alla fel rapporteras/registreras Testfall Resultat Feltyp Allvarlighet Ev ytterligare beskrivning Tänk dokumentation: - Vad fungerar? - Vad fungerar ännu INTE? 35

18 Testprotokoll Redogör för resultatet av test T ex en tabell med testfall, testresultat datum, etc 36 Skillnader och likheter mellan en testrapport och ett granskningsprotokoll?

19 Färdigtestat? När vi gjort vad vi lovat i projekt- och testplan: t ex visat att alla kraven på alla abstraktionsnivåer är uppfyllda:...traverserat alla grenar i koden......med alla upptänkliga kombinationer av variabler......på alla plattformar......med max+ belastning Tillräckligt bra? 38 Sammanfattning - Test Testning kan påvisa fel, men inte bevisa att det inte finns fel Testprocessen kopplar samman integration med testning: enhetstest, integrationstest, systemtest, acceptanstest Testmetoder kan vara antingen black box eller white box Dokumentgranskning är en testform där man kritiskt läser ett dokument på ett systematiskt sätt. Verifiering Validering Dynamisk testning Statisk testning Enhetstest Integrationstest Systemtest Acceptanstest Testfall Kravtäckningsmatris Black-box-test White-box-test Ekvivalenspartitionering Gränsvärdestestning Parvis testning Stresstest Code coverage Bransch coverage Testprotokoll Felrapport 39

20 Konfigurationshantering - intro [mer nästa vecka] 40 Många dokument Testpro tokoll Design Utb.- plan Test Manualer Projektplan Krav Process Kod Binär Olika versioner Olika produktvarianter Olika kunder 41

21 Tekniska och politiska versioner? Teknisk version varje gång man sparar - Praktiskt men inget man fattar beslut kring Politisk version när man ändrar nummer: - Låser historiken - Underlag för beslut - Beskriver förändringar - Kopplar ihop olika dokument - Möjliggör ordnad förgrening 42 Ändringshantering i ert projekt Baserat på: Efter baseline dvs efter att milstolpe uppnåtts Ansvariga för dokument som bestämmer vem som får ändra vad Uppdatering av versionsnummer Spridande av information inom gruppen Speciella regler för kravspecifikationen (efter baseline får man inte ändra utan att ansöka hos projekthandledaren) Kort version av vår process: 1. Person A finds out that there is something wrong in a document 2. Person A locates the fault in the document (currently in version 1.0) 3. Person A notifies the person responsible for the document (person B) and asks for permission to change it 4. Person B gives person A permission to change the document 5. Person A updates the document, updates the version number to 1.1 and gives it to person B. 6. Person B is now responsible for telling all persons that are working with the document or depend on it, that there is a new version. 43

22 Versionshistoria i dokument och ändringsformulär Eller implementera detta i wikin i samråd med handledare 44 Dvs, era versionsnummer för kravspecifikation blir t ex 0.0 första version inom projektet 0.x nya versioner efter arbete med dokumentet 0.99 version inlämnad till projekthandledare 1.0 dokument för godkänd milstolpe 1.1 ny version efter att projekthandledare godkänt ändring Innan 0.99 gör ni mycket som ni själva vill - Från och med 1.0 ska ni följa procedurer för ändringshantering 45

23 Om Acceptanstest SMIL 50 år Lunds universitet / LTH / Datavetenskap / ETSA01från VT 2011 / F3 46