Är instruktionerna oklara, projektet rörigt och allmänt frustrerande?

Transkript

1 Detta har hänt... Pratat och skapat krav och plan Övning 2 Riskhantering, intressenter och kravgranskning. Genomfört granskningar inför 2 x 0.99 och omarbete? ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Föreläsning 3 Verifiering och Validering Jonas Wisbrant Är instruktionerna oklara, projektet rörigt och allmänt frustrerande? 2 3 Kursinformation V 3: Nu kl 13 Föreläsning: Testning, versioner Idag kl 24 deadline: PP SRS föregående granskningar Wiki-ICE: SMS --> ange: Grupp + problem To: Övning 3: Test Om testfall: T.1-8 (i förväg) Påbörja testplan: T Återkoppling på 2 x 0.99 inför MS1 0.x Good version Individual inspection Inspection meeting Inspection protocoll 0.99 Supervisor review To 12.30: Kursombudsmöte - tankar och idéer till: V 4: Supervisor feedback 1.0 Ti kl 15 F: Arkitektur, design, kodning, versioner On kl 24: MS 1 eller To Ö: Mer om test 5 Better version

2 Hög tid att kolla på koden Agenda Kursinformation: Kursmål Verifiering & Validering Vad är testning? Testprocessen Testtekniker Konfigurationshantering - intro: Downloads på: projekt2012/ haardvarugraenssnitt_och_ drivrutiner/ står inte så tydligt i boken regler för projektet finns i projektmaterialet på kurswebben 6 Kursmål (beställningen) Varför trillade den första Ariane V-raketen ned? 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. Ariane 5 Flight 501 Failure A Case Study of Errors Ken Robinson School of Computer Science and Engineering University of New South Wales 16th December 1996 Revised: 22rd March

3 Verifiering bygger vi produkten rätt? Dvs följer vi kravspecifikationen? Verifiering och validering Validering bygger vi rätt produkt? Dvs kommer beställaren att bli nöjd? 10 Varför testar man? 11 Fel, fel, och fel Man vill hitta fel för att man vill förbättra produkten Fault Fel (failure) Man vill visa att produkten är bra Fel Man vill ta reda på hur många fel som finns i produkten för att man vill veta hur bra produkten är. Fel (error) men oavsett vilket så kan man aldrig visa att det inte finns fel, bara att det finns fel felrättning 12 felidentifiering observation av fel 13

4 Testprocessen och integration Testprocessen, V-modellen [Acceptanstest] system Kravhantering. m to ot up Systemtest (Verifiering) n w p To B Acceptanstest (VoV) systemtest do Integrations-test Design integrationstest. komponenter Implementation enhetstest. Enhetstest = består av 14 Dynamisk vs statisk testning Dynamisk testning: Exekvera programmet för att hitta fel Enhetstest, testfall för procedurer För att testa procedur F(x1,...xn), gör följande: Verktyg? Ja tack! 1. dynamisk Statisk testning: Hitta fel utan att exekvera programmet projekt 5. statisk Statiskt Done! 15 Sätt tillstånd till rätt värde Definiera värden för parametrar x1, xn Anropa Svar = F(x1,...xn) Jämför Svar med rätt resultat Registrera om resultatet var korrekt eller inte Kan stödjas med verktyg, t ex CuTest, CUnit, Med objektorientering kan t ex JUnit användas 16 17

5 Integrationstest / Systemtest Testplanering Testfall bestäms t ex baserat på specifikationer av gränssnitt i design Testplan: 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 Indata: Projektplan Kravspec... Design Manual Prototyper... Testplanering Testprocess (t ex stat / dyn, miljö) Kravspårning Testobjekt Tidplan (test) Dokumentation av resultat HW & SW requirements Begränsningar Testfall Testfall, två exempel Spårbarhet mot krav 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. 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 Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F

6 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 Kravspecifikationen används för att ta fram testfall White-box - Kräver tillgång till koden - Tanken är att testfallen ska täcka all kod 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 Ekvivalenspartitionering Gränsvärdestestning Hitta värden för in och utdata som behandlas på samma sätt Komponent För n variabler, ett intervall var vanlig gränsvärden : innanför eller på gränser => 4n+1 testfall (gröna) 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 1 Variabel

7 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 Parvis testning 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 (n "1) + (n " 2) = i = i = n(n "1) /2 par 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 # i=1 (n " n) + (n "1) 2 n"1 # i= 0 värden parametrar = m 2 n(n "1) /2 Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F Stresstestning White-box testing Kontrollera vad som händer vid hög belastning, t ex: Kräver tillgång till koden Tanken är att testfallen ska täcka all kod Men vad menas med all kod? Telefonväxel # telefoner > max # samtidiga samtal > max ERROR: ArrayOutOfBounds? 28 29

8 Täcka rader Täcka vägar 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! 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 31 Ett lite större exempel CC = #bågar - #noder +2 = = = 4 If: CC = = 2 CC används också som ett mått på komplexitet If-else: CC = = 2 CC = =

9 Andra förslag på white box test Genomförande av test och rapportering I simulerad miljö Branch coverage täcka alla bågar endast i utvecklingsmiljön I mer verklig miljö Simple path coverage alla vägar, utan att ta hänsyn till om de är linjärt oberoende) i testuppsättning I verklig miljö Alla fel rapporteras/registreras [Fenton et al., Software Metrics a Rigorous and Practical Approach ] Tänk kommunikation: - mellan individer och organisationer - över tiden CC = = 3 34 Testfall Resultat Feltyp Allvarlighet Ev ytterligare beskrivning Tänk dokumentation: - Vad fungerar? - Vad fungerar ännu INTE? 35 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?

10 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 Många dokument Testpro tokoll Konfigurationshantering - intro Design Utb.- plan fortsätter föreläsning 4 Test Manualer Projektplan Krav Process Kod Binär Olika versioner Olika produktvarianter Olika kunder 40 41

11 Tekniska och politiska versioner? Ändringshantering i ert projekt Teknisk version varje gång man sparar 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) - 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 Versionshistoria i dokument och ändringsformulär 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 Dvs, era versionsnummer för kravspecifikation blir t ex Eller implementera detta i wikin i samråd med handledare 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 som ni själva vill - Från och med 1.0 ska ni följa procedurer för ändringshantering 44 45

12 Alltså V 3: Nu kl 15 F: Testning, versioner Idag kl 24 deadline: PP_ SRS_ x föregående granskningar wiki-ice: SMS --> ange: Grupp + problem fr/to 12.30: Kursombudsmöte - tankar och idéer till: - Alfredsson, Emilia (I) Sartorius, Carolina (D) Eliasson, Anton (D) Wigren, Adam (C) Gråborg, Mikael (C) To: Återkoppling på 2 x 0.99 inför MS1 Övning 3: Test Om testfall: T.1-8 (i förväg) Skapa testplan: T Dags att kolla på koden för garaget V 4: Ti kl 13 F: Arkitektur, design, kodning, versioner On kl 24: MS 1 eller To Ö: Mer om test Om Acceptanstest SMIL 50 år Lunds universitet / LTH / Datavetenskap / ETSA01från VT 2012 / F