Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Verifikasjon og validering In 140 Sommerville kap 19.

Liknende presentasjoner


Presentasjon om: "Verifikasjon og validering In 140 Sommerville kap 19."— Utskrift av presentasjonen:

1 Verifikasjon og validering In 140 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  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 –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 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

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 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


Laste ned ppt "Verifikasjon og validering In 140 Sommerville kap 19."

Liknende presentasjoner


Annonser fra Google