PV7180 – Verifiering och Validering Föreläsning 7 Software

Litteratur
• Musa, ”Software Reliability Engineering”
PV7180 – Verifiering och Validering
• Wohlin et al, ”Software Reliability”
• Wood, ”Predicting Software Reliability”
Föreläsning 7
• Hamlet, ”Are We Testing for True Reliability”
Software Reliability
– Tillförlitlighet i programvara
• (Sommerville, ”Software Engineering”, Kap 21)
– Avsnittet om Reliability
Software Reliability - Tillförlitlighet
V&V Förtroende
• Definition:
– ”The probability of a device performing its purpose
adequately for the period of time intended under the
operating conditions encountered”
• Beror på systemets syfte, användarnas förväntningar
och marknadsmiljön
– Programvarans funktion
– Förtroendenivån är beroende av hur kritisk
programvara är för organisationen
– Användarförväntningar
– Användarna kan ha lågt ställda förväntningar för
viss programvara
– Marknadsmiljön
– Att få en produkt på marknaden kan vara
viktigare än att hitta defekter i programmet
• Hårdvara jämfört med mjukvara?
Förhindra fel (Failure prevention)
• Målsättning: Producera tillförlitlig programvara
Undvika
Detektering
Utvecklingsprocess
Statisk och
dynamisk V&V
Bugg
Borttagande
Utvärdering
Debugging
Bedömning
Förutsägelser
Certifiering
Utvärdering
• Bedömning
– Att kvantifiera den nuvarande tillförlitligheten
• Förutsägelser
– Att förutsäga en framtida tillförlitlighetsnivå
• Certifiering
– Att försäkra sig om en tillförlitlighetsnivå
Tolerans
Redundans,
”Recovery blocks”
1
Mått för att värdera tillförlitlighet i programvara
• Tillförlitlighetsmått
– Felintensitet
– MTTF eller MTBF
– Mean Time To Failure
– Mean Time Between Failures
– Tillgänglighet
• Mått för indikation av möjliga tillförlitlighetsproblem
– Defekter funna under inspektion
– Antal fel per KLOC
Fault vs. Failures (jmfr Fel – körningsfel)
• ”Fault removal” och ”failure occurrences”
• På vilket sätt är tillförlitligheten kopplad?
Fault
Error, fault and failure (jmfr ”Fel”)
Kan leda till
Human
error
Kan leda till
Fault
Failure
Att länka indata till utdata
Indata
Indata som orsakar felaktig utdata
Failure
Korrekthet (Correctness)
Tillförlitlighet (Reliability)
• Erfarenheten säger: ”Software Failure Analysis” [Adams]
– 61 % faults resulterar i 2,8 % av failures
– 1,6 % faults resulterar i 58 % av failures
• Därför måste fokus från tillförlitlighetshållet vara på ”faults” som
resulterar i ”failures” och denna fokus kombineras med fokus på
systemets kritiska delar
Krav på tillförlitlighet
Programvara
Utdata
Felaktig utdata
Validering av tillförlitlighet
• Validering av tillförlitlighet inbegriper att köra programvaran för
att utvärdera om den når tillräckliga nivåer av tillförlitlighet
• Exempel
– ”The software shall be as reliable as possible”
– ”The software shall exhibit no more than N faults /
1000 lines of code”
• Är dessa krav på tillförlitlighet?
• Kan inte inkluderas som en del av normal defekttestning
eftersom data för defekttestning vanligtvis inte är typisk
användardata
• Statistisk testning måste användas där statistisk viktig
dataexempel baseras på simulerad användning för att utvärdera
tillförlitligheten
• Kraven bör således uttrycka att tillförlitlighetstest görs på ett
speciellt sätt
2
Varför testning baserad på statistisk
användning?
Statistisk testning
• Att testa programvaras tillförlitlighet snarare än
upptäcka fel
• Statistisk testning och tillförlitlighetscertifiering är en
central del i Cleanroom – Varför?
• Att mäta antalet ”faults” tillåter att förutsägelser om
tillförlitligheten hos programvaran kan göras
• Effektiv användning av testresurser
• ”Faults”, med hög påverkan på tillförlitligheten hittas
tidigt
• Att en acceptabel nivå av tillförlitlighet kan specificeras
och programvaran testad och bearbetad till dess att
denna nivå nåtts
Erfarenheter visar…
Valideringsprocessen för tillförlitlighet
MTBF
• Etablera den operativa profilen för systemet
Fall i tillförlitlighet
• Konstruera testdata som motsvarar den operativa
profilen
Funktionella tester
Systemtest
• Testa systemet och observera antalet ”failures” och
tiderna för dessa
Operativ
Tid
• Beräkna tillförlitligheten efter det att ett statistiskt
ansenligt antal ”failures” har observerats
• Målsättning: Minimera ”fallet” mellan olika faser
Operativa profiler
En operativ profil
• En operativ profil är en mängd av testdata vilken dess
frekvens baseras på den verkliga frekvensen av dessa
indata från normal användning av systemet.
• En nära koppling till den verkliga användningen är
nödvändig, annars motsvarar den observerade
tillförlitligheten inte den verkliga användningen av
systemet
• Kan genereras från riktig data insamlad från ett
existerande system eller (mera ofta) baseras på
antaganden gjorda om mönster gjorda i system
3
Generering av operativa profiler
• Bör genereras automatisk när så är möjligt
• Automatisk profil generering är svårt för interaktiva
system
• Är förhållandevis enkelt för ”normal” indata men det är
svårt när det gäller att generera och förutse
”oförutsedd” indata och skapa testdata för dem
Modellering av tillförlitlighet
• En tillförlitlighets-tillväxt-modell är en matematisk
modell över systemets tillförlitlighetsförändring
efterhand som det testas och felaktigheter tas bort
• Används för att extrapolera tillförlitlighetsförutsägelser
genom att extrapolera gällande data
– Förenklar testplanering och kundförhandlingar
• Beroende av statistisk testning för att mäta
tillförlitligheten hos systemversioner
”Lika-stegs”-tillväxt för tillförlitlighet
Observerad tillförlitlighetstillväxt
• ”Lika-stegs”-tillväxt för tillförlitlighet är enkel men
motsvarar inte verkligheten
• Tillförlitlighet behöver inte nödvändigtvis öka med
förändringar eftersom ändringar kan introducera nya
fel
• Tillförlitlighetstillväxttakten tenderar att sakta ned med
tiden samtidigt med att frekvent uppträdande fel hittas
och tas bort från programvaran
”Slumpmässigstegs”-tillväxt för tillförlitlighet
Val av tillväxtmodell
• Flera olika tillväxtmodeller har föreslagits
• Ingen universell modell kan appliceras
• Tillförlitlighet mäts och observerad data passas in på
flera modeller
• Den modell som passar bäst bör användas för
tillförlitlighetsförutseenden
4
Att förutse tillförlitlighet
Frågeställningar
• Frågor som skall besvaras
– Vilken är den nuvarande tillförlitlighetsnivån?
(bedömning)
– När når vi kraven?
(förutsägelse)
– Kan vi säkerställa att vi har en specifik tillförlitlighet?
(fastställa)
Två stora problem med vissa modeller
Problem med tillförlitlighetsvalidering
• Två problem:
– De förutsätter att rättande aktiviteter i programvara
alltid är korrekt och aldrig ökar antalet fel i
programvaran
– De förutsätter att alla fel bidrar lika mycket till
tillförlitligheten och att varje fel som rättas till bidrar
med samma mängd av tillförlitlighetstillväxt
• Osäkerhet i operativa profiler
– Är den operativa profilen en rättvis spegling av den
verkliga användningen av systemet?
• Vissa mer sofistikerade modeller försöker överbygga
dessa antaganden
• Höga kostnader för datagenerering
– Det är mycket dyrt att generera och kontrollera det
stora antalet av testfall som krävs
• Statistisk osäkerhet för system med hög tillförlitlighet
– Det kan vara omöjligt att generera tillräckligt med fel
för att göra statistiskt korrekta slutsatser
”Software Reliability” i praktiken
• Formulera testbara tillförlitlighetskrav
• Mät tillförlitlighetsassocierade attribut under utveckling
• Modellera systemanvändningen
• Testa i förhållande till förväntad användning
• Bedöm, förutse och säkerställ tillförlitligheten
• Leverera programvara med kvantifierad tillförlitlighet
5