1 Validering og verifisering Kirsten Ribu 2005. 2 I dag Validering og verifisering Inspeksjon Testing.

Presentasjon om: "1 Validering og verifisering Kirsten Ribu 2005. 2 I dag Validering og verifisering Inspeksjon Testing."— Utskrift av presentasjonen:

1 1 Validering og verifisering Kirsten Ribu 2005

2 2 I dag Validering og verifisering Inspeksjon Testing

3 3 Noen ord om prosjektet Sjekk kurssidene jevnlig. Endringer forekommer (forelesningsplanen) Hvordan fungerer gruppene?  Fungerer arbeidsfordelingen?  Fungerer møtene?  Hvordan gjør dere rapportering? Kom med spørsmål! Husk å logge alle problemer/løsninger = skal inn i prosessrapporten Samle alle filer i ett dokument etter hvert

4 4 Innlevering i dag Leveranse III  Oppdatert prosjektplan (husk versjonsnummer)  Oppdatert use case modell med beskrivelser  Sekvensdiagram for 2 sentrale use case  Estimat over forventet tidsbruk (antall timer)  Tidsplan (aktivitetsplan)

5 5 Tilbakemeldinger Tirsdager kl 0940 og onsdag kl 1210 Ta ellers kontakt med Kirsten på mail og kom på kontoret for samtale Husk: Dette er et praktisk fag, og øvelse gjør mester! Men det er en del teori som skal på plass også ;-) Endelig leveranse: Systemet må ikke være ferdig!  En protoyp med noe funskjonalitet er godt nok, men BESKRIVELSENE er viktige!

6 6 Validering og verifisering Å sørge for at et datasystem tilfredsstiller brukerens behov

7 7 Hvorfor validering og verifisering? For å kunne vurdere hva vi gjør og hvorfor vi gjør det Behov for verifisering øker med størrelsen på systemet Ca 1/3 av utviklingstiden brukes å testing Noen ganger opp til 50% Systemutvikling er en industriell prosess!

8 8 Inspeksjoner (statisk verifisering)  Analyse av systemet  kodeinspeksjon og gjennomgang av dokumentasjon for å oppdage probelemer Testing (dynamic verifisering)  Observasjon av systemoppførsel  Systemet kjøres med testdata Statisk og dynamisk verifisering

9 9 V&V: Validering: “Bygger vi det riktige systemet?”  Snakke med brukerne  Bruke use case modellen Verifikasjon: “Bygger vi systemet riktig?”  Manuelle inspeksjonsmetoder  Automatisert testing

10 10 Mennesker gjør feil Det vi lager er ikke det vi burde laget Det vi lager har defekter Vi trenger ikke nødvendigvis ”best mulig” kvalitet: Godt nok er bra nok. Jo senere en feil oppdages, desto mer alvorlig er det Feil kan være forretningskritisk (i ytterste konsekvens kan menneskeliv gå tapt)

11 11 Hva slags feil?

12 12 Hvorfor finnes feil i ferdige produkter? Det som er laget er feil (ikke det kunden vil ha) Ikke alle feil prioriteres rettet:  Kategori 1: Kritiske feil som MÅ rettes (lansering holdes igjen til feilen er rettet)  Kategori 2: Kritiske feil som bør rettes (betydelig reduksjon av kvaliteten)  Kategori 3: Ikke-kritiske feil (kosmetiske feil)

13 13 Forts. I praksis umulig å få verifisert alle kombinasjoner av input til et system Tendens til å teste og vektlegge bekreftelser, i motsetning til å prøve å falsifisere.  NB! Det er en vesentlig forskjell i holdning mellom det å utvikle og det å teste.  En god utvikler er ”konstruktiv”, mens en god tester er ”destruktiv”.  Mange organisasjoner velger derfor å skille rollene, dvs. å ha egne testere. Tendens til å tro at sist funnet feil er “siste feil”.

14 14 Hvordan verifisere? Finn ut om vi har laget systemet riktig: Sammenlign produktet med kravspesifikasjonen Kravspek er visualisert i use case modellen beskrevet i use case’ne

15 15 Hensikten med testing Finne feil Vurdere kvaliteten på systemet i forhold til kravene Riktig kvalitet ( ikke nødvendigvis ’beste kvalitet’) Vite når systemet er ferdig!

16 16 Kvalitetssikringsstandarder ISO 9000 – familien ISO 9001 standarden beskriver kvalitetssikringsarbeidet i hele livssyklusen Utviklingsprosesse (for eksempel RUP) er også en kvalitetssikringsprosess

17 17 3 måter: Prototyping  Benyttes tidlig i utviklingsprosessen  Lage et utkast til hvordan det endelige systemet kan se ut.  Testes mot sluttbruker Inspeksjoner  Benyttes i alle faser av utviklingsprosessen  Gjennomgang av leveranser  Utføres hovedsakelig mennesker, men kan være programmer Testing  Gjøres sent i utviklingsprosessen  Sjekke hvor godt systemet oppfyller kravene  Resultatet av kjøringer sammenlignes med fasit

18 18 Ikke motsetninger Inspeksjoner og testing bør brukes sammen under programvareutviklingen Test casene bør også inspiseres! Inspeksjoner avdekker feil ved test casene Dermed kan det lages mer effektive måter å teste systemet på

19 19 1.Prototyping Utkast til hvordan systemet kan se ut  Tegninger (storyboarding)  Skjermbilder uten funksjonalitet Brukes til validering av systemet i krav/analyse- fasen  Enkelt for brukere å forholde seg til (i forhold til modeller og dokumenter)  Avdekker effektivt manglende/feil krav og forretningsregler Ulemper:  Gode prototyper kan gi falske forventninger i forhold til hvor langt prosjektet har kommet  Brukere kan bli opphengt i irrelevante detaljer

20 20 Verktøy Penn og papir Whiteboard Tegneprogrammer HTML-editorer GUI-byggere Modellbaserte prototypingsverktøy Programmeringsspråk

21 21 Eksempel

22 22 2. Inspeksjon Dokumentgjennomgang Kodegjennomgang

23 23 Dokumentgjennomgang Gjennomgang av dokumenter med formål å finne feil og mangler Forskjellige teknikker kan benyttes  ”parprogrammering” (kontinuerlig inspeksjon)  Forskjellige typer gjennomgangsmøter (dokumentet presenteres i møtet, distribueres på forhånd Hvem bør gjennomgå dokumentet?  De som skal ha systemet  De som skal bruke dokumentet  De som har vært delaktige i utformingen av dokumentet  Eksperter (rollen / forretningsområdet)

24 24 Kodegjennomgang Gjennomgang av kildekoden for å finne feil og mangler  Funksjonelle feil (avvik fra design og kravspesifikasjon)  Avvik fra kodestandard og retningslinjer (for eksempel navngiving av klasser)  Tekniske feil (for eksempel feil i en hashmap- funksjon)  Testbarhet (for eksempel dokumentasjonsmangler, muligheten for isolasjon, etc) Forskjellige teknikker kan benyttes  Parprogrammering (kontinuerlig kodegjennomgang)  Distribusjon til en eller flere for gjennomlesning  Koden gjennomgås av en review-gruppe i et møte  Aspektbasert inspeksjon

25 25 Inspeksjons-team Hvem bør gjennomgå kode?  Sjefsprogrammerer/designere  Juniorprogrammerere (opplæring)  Testere  Tekniske eksperter  Arkitekter Minst 4 medlemmer i teamet:  Den som har laget koden  Inspektør som finner feil, uoverenstemmelser, mangel på konsistens  OPpleser som leser koden for teamet  Møteleder som noterer feilene som blir funnet

26 26 Fordeler Mer enn 60% av alle feil kan oppdages ved kodeinspeksjon (Fagan) Med matematisk verifisering kan 90% av feil i koden oppdages. Mange ulike defekter oppdages under en enkelt inspeksjonsrund  (Ved testing: Kan ofte bare oppdage 1 feil - programmet kræsjer f.eks ved feil) Gjenbruker kunnskap om domenet og programmeringsspråk  Inspektørene har sannsynligvis sett vanlig feil relatert til programmeringsspråket og i den type applikasjoner.  Derfor er det fokus på denne type feil under inspeksjonen

27 27 3. Testing - Typer av test V-modellen Testplan Testdata Ekvivalensklasser Enhetstesting (med verktøy og eksempler gjerne relatert til XP) Testdrevet utvikling Gjenbruk

28 28 Testing En form for ”induktiv bevisføring”, dvs. å vise (sannsynliggjøre) at alle svaner er hvite ved å observere et representativt utvalg av alle svaner. Test er både verifikasjon og validering Testing kontrollerer ny funksjonalitet, samt at eksisterende funksjonalitet fortsatt virker (regresjonstesting) Effektiv testing gjøres ved:  Testbare krav  Testbare programvarestrukturer  Bruk av ekvivalensklasser  Testverktøy  Gjenbruk

29 29 Testing vs. debugging Testing er ikke det samme som debugging Testing er å finne feil Debugging er å rette feil men begge deler gjøres ofte i test- fasen av prosjektet (noe uklare grenser)

30 30 Eksempel

31 31 Det første virkelige tilfelle av ”bug” 9. september 1945, kl. 3:45 p.m., fant forskere ved Harvard universitetet årsaken til at Mark II Aiken Relay kalkulatoren oppførte seg merkelig En møll ble funnet fanget mellom punkter på relé #70, panel F Maskinen ble ”debugget” med en pinsett! Dokumentert i loggen som ”First actual case of bug being found.” med møllen tapet inn ved siden av

32 32 Type test Enhetstest/funksjonstest  Hvem tester: Programmerer Integrasjons- og systemtest  Hvem tester: Tester Akseptansetest  Hvem tester: Installatør og kunde Drift:  Kunde

33 33 Typer testing Enhetstest  Tester at komponenten (klassen) virker isolert  Simulerer omgivelsene til komponenten  Utføres av utviklere  Skrives ofte som automatiske tester Integrasjonstest  Tester at komponenten (klassen) virker sammen med andre komponenter  Simulerer ofte andre sub-systemer  Bruker konstruerte testdata  Utføres ofte av utviklere  Gjøres ofte manuelt, men kan med fordel automatiseres

34 34 Typer testing forts. Betatest  Utvalgte kunder tar i bruk systemet før offisiell lansering Akseptansetest  Tester at systemet lar brukerne gjøre det de trenger  Tester med reelle data  Utføres gjerne i samarbeid mellom kunder og testere Systemtest  Tester at systemet oppfører seg korrekt i samspill med omgivelsene

35 35 Type testing forts. Ytelsestest (tester ytelse = hastigheten på én transaksjon) Stresstest (overbelastningstest) (tester skalerbarhet = hastigheten på mange samtidige transaksjoner) Recoverability-test (tester systemets håndtering av uforutsette avbrudd)

36 36 Black- og white-box testing Inndata Komponent Utdata Xxxxx xxxxx Inndata Komponent Utdata Black box: Gir input forventet output? White box: Følger hvert trinn i komponenten. Midlertidige utskrifter.

37 37 Neste gang Brukergrensesnitt: Haakon Aspelund fra Sosialdepartementet kommer i 1 time og snakker om Universell design (design for alle).