Verifikasjon og validering Sommerville kap 19

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.

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

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

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.

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

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

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

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

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

Debugging-prosessen

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

Testfaser i programvareprosessen – V-modellen

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

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

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

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.

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

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

Inspeksjonsprosessen

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

Sjekkliste for inspeksjon

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

Statisk analyse tester dette:

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

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

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

Cleanroom-prosessen

Inkrementell utvikling

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

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

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

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