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
© Copyright 2024