Page 1
ETSA01 Ingenjörsprocessen förprogramvaruutveckling – Metodik
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Föreläsning 3Verifiering och Validering
2
Jonas Wisbrant
• 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 ?
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Detta har hänt....
3
Page 2
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Är instruktionerna oklara, projektet rörigt och allmänt frustrerande?
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
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
Page 3
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Kursinformation • V 3:
– Nu kl 13 F: Testning, versioner
– Idag kl 24 deadline: PP0.99 + SRS0.99 + föregående granskningar
• wiki-ICE: SMS --> 0730-24 96 75 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.15-16
• V 4: – Må kl 13 F: Arkitektur, design, kodning, versioner– Ti kl 24: MS 1 eller 0.991...– To Ö: Mer om test
6
0.x
Individual inspection
Inspection meeting
0.99 Inspection protocoll
Good version
Better version
Supervisor review
Supervisor feedback
1.0
0.0991
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Hög tid att kolla på koden
7
Downloads på: http://cs.lth.se/kurs/etsa01/projekt2011/haardvarugraenssnitt_och_drivrutiner/
Page 4
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
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
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Varför trillade den första Ariane V-raketen ned?
Page 5
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Verifiering och validering
10
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
• 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
Page 6
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
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
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Fel, fel, och fel…
Fel(error)
Fel
Fault Fel(failure)
felrättning felidentifiering observation av fel
13
Page 7
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Top down
Testprocessen och integration
komponenter
system
….
….
….
Bottom up
= består av
systemtest
integrationstest
enhetstest
14
[Acceptanstest]
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Testprocessen, V-modellen
Implementation Enhetstest
Design Integrations-test
Kravhantering Systemtest(Verifiering)
Acceptanstest(VoV)
15
Page 8
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Dynamisk vs statisk testning
• Dynamisk testning:– Exekvera programmet för
att hitta fel
• Statisk testning:– Hitta fel utan att exekvera
programmet
projekt
statisk
dynamisk
16
StatisktDone!Verktyg?
Ja tack!
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
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ärde2. Definiera värden för parametrar x1,…xn3. Anropa Svar = F(x1,...xn)4. Jämför Svar med rätt resultat5. 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
Page 9
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
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
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
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
Page 10
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F3
Testfall, två exempel
Test case: Buy colaPre-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 buttonPre-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.
20
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
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
Page 11
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
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
22
White-box- Kräver tillgång till koden
- Tanken är att testfallen ska täcka all kod
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
”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
Page 12
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Ekvivalenspartitionering
Komponent
Hitta värden för in och utdata som behandlas på samma sätt
24
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
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)
• 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 2
25
Page 13
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / 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
26
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,…)
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Parvis testning
n parametrar med m möjliga värden vardera ger m2 par av värden för varje par av parametrar
Första med resten ger m2(n-1) par, andra med resten m2(n-2) par, osv
Antal par =
Varje testfall täcker par
Om varje testfall täcker olika par krävs det alltså m2 testfall• I praktiken omöjligt ha unika par för varje testfall• och olika antal värden för olika parametrar
!
m2 (n " k)k=1
n
# = m2 (n " k) = m2nk=1
n
# (n " n) + (n "1)2
= m2n(n "1) /2
!
(n "1) + (n " 2) + ...+1= i = i = n(n "1) /2i= 0
n"1
#i=1
n"1
#
parametrar
värd
en
27
Page 14
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Stresstestning
Telefonväxel
# telefoner > max# samtidiga samtal > max…
ERROR: ArrayOutOfBounds ?
Kontrollera vad som händer vid hög belastning, t ex:
28
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
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
Page 15
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
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
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
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-else-statement precis som för if-then
Visualisera eventuellt genom att rita graf
Antal linjärt oberoende vägar: CC = #(bågar) - #(noder) +2
31
Page 16
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Enkla exempel
If:CC = 3-3+2 = 2Statement cov: 1
If-else:CC = 4-4+2 = 2Statement cov: 2
CC = 8-7+2 = 3Statement cov: 2
32
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Ett lite större exempel
CC = #bågar - #noder +2 = = 16-14+2 = 4
CC används också som ettmått på komplexitet
33
Page 17
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
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 Metricsa Rigorous and Practical Approach”]
34
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Genomförande av test och rapportering
I simulerad miljö – endast i utvecklingsmiljön
I mer verklig miljö – i testuppsättning
I verklig miljö
Alla fel rapporteras/registreras– Testfall– Resultat– Feltyp– Allvarlighet– Ev ytterligare beskrivning
35
Tänk kommunikation:- mellan individer
och organisationer- över tiden
Tänk dokumentation:- Vad fungerar?- Vad fungerar
ännu INTE?
Page 18
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Testprotokoll
Redogör för resultatet av testT ex en tabell med testfall, testresultat datum, etc
36
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Skillnader och likheter mellan en testrapport och ett granskningsprotokoll?
Page 19
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
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Färdigtestat?
38
Tillräckligt bra?
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
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.
39
VerifieringValideringDynamisk testningStatisk testningEnhetstestIntegrationstestSystemtest
AcceptanstestTestfallKravtäckningsmatrisBlack-box-testWhite-box-testEkvivalenspartitioneringGränsvärdestestning
Parvis testningStresstestCode coverageBransch coverageTestprotokollFelrapport
Page 20
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Konfigurationshantering - intro
[mer nästa vecka]
40
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Krav
Test
Design
Kod
Manu-alerProjekt-
planProcess
Utb.-plan
Olika versioner Olika produktvarianter Olika kunder …
…
Många dokument…
41
Testprotokoll
Binär
Page 21
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
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
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Kort version av vår process: 1. Person A finds out that there is
something wrong in a document2. 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.
Ä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)
43
Page 22
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
Versionshistoria i dokument och ändringsformulär
44
Eller implementera detta i wikin i samråd med handledare
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3
- 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
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
1.2 --”--
45
Page 23
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F3 46Om Acceptanstest från SMIL 50 år