1 / 37

Validering og verifisering

Validering og verifisering. Kirsten Ribu 2005. I dag. Validering og verifisering Inspeksjon Testing. Noen ord om prosjektet. Sjekk kurssidene jevnlig. Endringer forekommer (forelesningsplanen) Hvordan fungerer gruppene? Fungerer arbeidsfordelingen? Fungerer møtene?

step
Download Presentation

Validering og verifisering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Validering og verifisering Kirsten Ribu 2005

  2. I dag • Validering og verifisering • Inspeksjon • Testing

  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. 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. 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. Validering og verifisering • Å sørge for at et datasystem tilfredsstiller brukerens behov

  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. Statisk og dynamisk verifisering • 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

  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. 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. Hva slags feil?

  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. 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. 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. 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. Kvalitetssikringsstandarder • ISO 9000 – familien • ISO 9001 standarden beskriver kvalitetssikringsarbeidet i hele livssyklusen • Utviklingsprosesse (for eksempel RUP) er også en kvalitetssikringsprosess

  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. 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. 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. Verktøy • • Penn og papir • • Whiteboard • • Tegneprogrammer • • HTML-editorer • • GUI-byggere • • Modellbaserte prototypingsverktøy • • Programmeringsspråk

  21. Eksempel

  22. 2. Inspeksjon • Dokumentgjennomgang • Kodegjennomgang

  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. 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. 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. 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. 3. Testing - Typer av test • V-modellen • Testplan • Testdata • Ekvivalensklasser • Enhetstesting (med verktøy og eksempler gjerne relatert til XP) • Testdrevet utvikling • Gjenbruk

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

  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. Type test • Enhetstest/funksjonstest • Hvem tester: Programmerer • Integrasjons- og systemtest • Hvem tester: Tester • Akseptansetest • Hvem tester: Installatør og kunde • Drift: • Kunde

  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. 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. 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. Black- og white-box testing Komponent Inndata Utdata Black box: Gir input forventet output? Komponent Inndata Xxxxxxxxxx Utdata White box: Følger hvert trinn i komponenten. Midlertidige utskrifter.

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

More Related