Verifikasjon og validering

Presentasjon om: "Verifikasjon og validering"— Utskrift av presentasjonen:

1 Verifikasjon og validering
Sommerville kap 19

2 Mål Forstå forskjellen mellom validering og verifikasjon
Bli kjent med inspeksjon som en metode for å bedre kvaliteten på produktene i systemutviklingen. Forstå hvorfor statisk analyse er en viktig verifikasjonsteknikk Forstå Cleanroom-metoden for programutvikling og dens effektivitet.

3 Validering og verifikasjon
Analyseprosesser som sikrer at programvaren stemmer med spesifikasjonen og møter kundens behov. Følger systemets livssyklus Verifikasjon sikrer at systemet stemmer med spesifikasjonen både funksjonelt og ikke funksjonelt Validering sikrer at systemet møter kundens forventning Validering allerede fra kravspesifikasjon

4 Programvareinspeksjon og -testing
Kalles også statisk og dynamisk testing Inspeksjon Innebærer gjennomgang av dokumentasjon: prosjektplaner, kravspesifikasjon, designdiagrammer, kildekode, dokumentasjon. Inspeksjon kan skje i alle faser Inspeksjon kan støttes av programvare Statisk testteknikk Programvaretesting Kjøring av programmet med data Undersøker om utdata og programmets oppførsel er som spesifisert Dynamisk testteknikk

5 Inspeksjon Inspeksjonsteknikker
Dokumentinspeksjon Programinspeksjon Automatisk kildekodeanalyse Formell verifikasjon Sjekker bare sammenheng mellom spesifikasjon og program Kan ikke vise om programvaren er nyttig i praksis Kan heller ikke vise om ikke-funksjonelle krav er oppfylt Brukes mye, men i praksis mindre enn dynamisk testing.

6 Programvaretesting Kjøre programmet med virkelighetsnære data
Finne feil ved utdata og oppførsel Kan utføres under og etter implementering To testtyper Defekttesting – testing som prøver å finne feil ved programmet. Etterligner ikke virkelig brukssituasjon. Statistisk testing – testing av ikke-funksjonelle egenskaper. Testene etterligner virkelig brukssituasjon med inndata og frekvens av kommandoer. Flytende grense

7 Mål for V&V er tiltro (confidence)
V&V skal gi tiltro til at programmet skal være nyttig godt nok etter brukernes forventninger (ikke feilfritt) Nødvendig tiltro varierer med Programvarens formål Brukernes forventninger Markedsforhold

8 Feilretting (debugging – avlusing)
Avlusing ( Grace Hopper) Avlusing og testing gjøres ofte samtidig, men er egentlig separate prosesser Ingen enkel metode for avlusing Erfaring viktig Avhengig av språk

9 Feilretting Finne feilen Rette feilen Ofte vanskelig å finne feilen
Få feilen til å gjenoppstå Isolere feilen Manuell tracing (trinnvis kjøring) Interaktive debuggere Symboltabellen Variabelverdier Rette feilen

10 Feilretting er ofte mislykket
Årsaker Fokus på å rette feilen Lang avstand i tid fra utforming til koding Uegnet dokumentasjon Designsvakheter: Høy kobling, manglende innkapsling, for lite oppsplitting. Testing nødvendig for å se om feilen virkelig er rettet og man ikke har laget nye feil. Regresjonstesting Dyrt å gjøre fullstendig hver gang Lettere med god dokumentasjon

11 Debugging-prosessen

12 Planlegging av validering og verifikasjon
Kostnaden kan komme opp i halvparten av prosjektets budsjett. Planlegging gir best mulig utbytte. V-modellen Dette bør planlegges Balanse mellom statisk og dynamisk testing Standarder og framgangsmåter Sjekklister Planen er dynamisk

13 Testfaser i programvareprosessen – V-modellen

14 Testplan Testprosessen Sporbarhet til brukerkrav Hva skal testes
Tidsplan for testing Testdokumentasjonsprosedyre Krav til maskinvare og programvare for testing Rammer

15 Statisk testing (inspeksjon)
Dynamisk testing er dyrt og dårlig Tester må utvikles. Ofte en eller få feil å finne per kjøring pga datakorrupsjon eller krasj Statisk testing kan gjøres på flere systemrepresentasjoner. Ingen interaksjoner mellom feil En hel modul kan inspiseres per seanse Inspeksjon er effektivt og billig 60 til 90% av feilene kan finnes med inspeksjon Tester også om programvaren følger standarder, portabilitet og vedlikeholdbarhet. Effektivt mot feil i komponenter og undersystemer fordi Mange feil kan finnes på et inspeksjonsmøte Gjenbruk av kunnskap om språk og problemområde

16 Statisk testing (inspeksjon)
Kan ikke teste dynamisk oppførsel Upraktisk: Inspeksjon av store sammensatte systemer. Dynamisk testing må brukes på: Integrerte systemer Brukergrensesnitt Pålitelighetstesting For å teste om systemet virkelig fyller brukerens behov

17 Inspeksjon og dynamisk testing
Ikke enten eller, men både og Inspeksjon kan brukes på dynamiske tester Inspeksjon kan være vanskelig å innføre Dynamisk testing er vanlig Uvante kostnader tidlig i prosjektet Effektiv inspeksjon krever erfaring Brukes på kildekode, men også på andre dokumenter: prosjektplan Kravspesifikasjon Arkitektur og utformingsdiagrammer Dokumentasjon etc.

18 Programinspeksjon Formalisert inspeksjon (IBM/Fagan '70s)
Mye brukt og finnes i flere varianter. Idé: Inspeksjonslaget studerer kildekoden linje for linje består av minst fire forskjellige roller: Forfatter, (Leser), Tester, Moderator/Ordstyrer, (Referent, Sjefsmoderator). Eller de representerer synspunkter: Sluttbruker, Kvalitetssikring, Testing, Standard Formål: Finne programfeil Forutsetninger Spesifikasjon for koden må foreligge Inspeksjonslaget er kjent med standardene Oppdatert kildekode med korrekt syntaks

19 Programinspeksjon Prosess Følger sjekkliste
Moderatoren planlegger møtet Oversikt: Programmet med spesifikasjon sendes møtedeltakerne fra forfatter. Individuell forberedelse: Deltakerne leser gjennom koden for å finne feil Inspeksjonsmøtet (maks 2 timer) identifiserer problemer (ikke løsninger) Forfatteren retter problemene Moderatoren følger opp Følger sjekkliste Språkavhengig Bygger på erfaring Forbedres stadig Lages og vedlikeholdes av organisasjonen

20 Inspeksjonsprosessen

21 Programinspeksjon Kan brukes til å forbedre prosessen: Hvorfor oppstod feilene Erstatter enhetstesting i mange org. Effektivitet avhenger av erfaring, programmeringsspråk og anvendelsesområde. Oversiktsfase 500 l/h Individuell forberedelse 125 l/h Inspeksjonsmøte l/h Med 4 personers lag ca en arbeidsdag/100linjer <50% av kostnadene med tilsvarende dynamisk testing. Krever følsom ledelse. Inspeksjon kan være tøft for forfatteren Skille mellom inspeksjon og personvurdering Moderator må trenes opp

22 Sjekkliste for inspeksjon

23 Automatisk statisk analyse
Programvare som skanner kildekoden for å finne feil eller anomalier. Finner f.eks: Ikke initialiserte variabler Ubrukte variabler Out of Range muligheter Passer godt sammen med programinspeksjon

24 Statisk analyse tester dette:

25 Automatisk statisk analyse
Trinn i prosessen Kontrollflytanalyse Databruksanalyse Grensesnittanalyse (Informasjonsflytanalyse) (Path-analyse) Spesielt verdifullt for språk med svak typing. Eksempel Lint Ikke kosteffektivt for moderne språk

26 LINT static analysis 138% more lint_ex.c #include <stdio.h>
printarray (Anarray) int Anarray; { printf(“%d”,Anarray); } main () int Anarray[5]; int i; char c; printarray (Anarray, i, c); printarray (Anarray) ; 139% cc lint_ex.c 140% lint lint_ex.c lint_ex.c(10): warning: c may be used before set lint_ex.c(10): warning: i may be used before set printarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(11) printf returns value which is always ignored LINT static analysis

27 Cleanroom-prosessen Unngå feil ved systematisk inspeksjon
Mål: Programvare med 0-feil Erstatter enhetstesting Fem hjørnesteiner Formell spesifikasjon med tilstandsendringsmodell Inkrementell utvikling Strukturert programmering Statisk verifisering Statistisk testing

28 Cleanroom-prosessen

29 Inkrementell utvikling

30 Inkrementell utvikling
Selvgående inkrementer Nyttige og testbare Integrasjon for hvert inkrement Kravspesifikasjonsendringer en del av prosessen Viktigste funksjonalitet først Flere runder mulig Best gyldighetstesting av det viktigste Rigorøs inspeksjon støttes Trinnvis transformasjon fra spesifikasjon via tilstandsmodell til kode Drøfting klarlegger om transformasjonene er korrekte

31 Team i Cleanroom prosessen
Spesifikasjonsteamet Brukerkravspesifikasjon Verifikasjonsspesifikasjon Utviklingsteamet Utvikling Verifisering Sertifiseringsteamet Utvikling av statistiske tester

32 Hvor godt fungerer Cleanroom-prosessen?
Gir programvare med svært få feil uten høyere pris Flere suksesshistorier – systemer som svikter sjelden Statisk verifikasjon er kosteffektivt. Gjennomsnittlig oppdaget 2,3 feil per 1000 linjer i testfasen Test med studenter: De fleste team utnyttet metoden bra. Bedre kvalitet: flere kommentarer, enklere struktur. Fungerer bra med dyktige og interesserte deltakere Tvil om den kan brukes over alt

33 Hovedpunkter Verifikasjon og gyldighetstesting Testplan
Statisk verifikasjon Programinspeksjon sjekkliste sjekkteam Statiske analysatorer Cleanroom programutvikling