Validering og verifisering

1. Validering og verifisering Kirsten Ribu 04.04.2005

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

3. Validering og verifisering • Hva ligger i disse begrepene: • Å sørge for at et datasystem tilfredsstiller brukerens behov!

4. 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!

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

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

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

9. Hva slags feil?

10. 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)

11. Forts. • I praksis er det umulig å få verifisert alle kombinasjoner av input til et system • Det er en 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. • Det er lett å tro at sist funnet feil er “siste feil”.

12. Hvordan verifisere? • Finn ut om vi har laget systemet riktig: • Sammenlign produktet med kravspesifikasjonen • Kravspesifikasjonen er visualisert i use case modellen beskrevet i use case’ne • Bruk use casene til å teste

13. 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!

15. Det er 3 måter å verifisere/validere på: • 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

16. 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å

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

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

19. Eksempel – lag en prototyp med HTML:

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. Automatisert kodeanalyse • Programmer som analyserer kildekode og avdekker avvik fra spesifiserte krav • Sjekker at alle klassenavn begynner med store bokstaver • Sjekker at metoder ikke er for lange • Sjekker at input-paramtere valideres • Sjekke at alle metoder er dokumentert • Ikke-eksekverbar kode • Variabler som aldri brukes • Minnehåndtering • Kan integreres i utviklingsmiljøet, versjonshåndteringssystemet eller byggesystemet • For eksempel kan kode hvor verktøyene rapporterer feil i nektes innsjekking • Raskt å kjøre (billig) i motsetning til inspeksjon • – Men mange ting fanges ikke opp her. • Eksempel på verktøy: • – kompilatorer • – jDepend • – jMetric

27. Fordeler • Mer enn 60% av alle feil kan oppdages ved kodeinspeksjon Med matematisk verifisering kan 90% av feil i koden oppdages. • Mange ulike defekter oppdages under en enkelt inspeksjonsrunde • (Ved testing: Kan ofte bare oppdage 1 feil - programmet kræsjer f.eks ved feil)

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

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

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

31. Retningslinjer for testing • Velg input som tvinger systemet til å generere feilmeldinger: • Bruk input som overbelaster systemet • Gjenta samme input flere ganger • Tving fram ugyldig output • Tving systemet til å gjøre beregeninger som frambringer for store eller for små resultater

32. Use cases • Use cases kan brukes til å lage tester • Use case identifiserer operasjoner som skal testes, og er en støtte når man designer test cases. • Input og output kan lages på basis av et sekvensdiagram

33. Vær-data sekvensdiagram

34. Bruk pre-og postbetingelser til testing • Bruk inputs som bekrefter prebetigelser (bruker er registrert) • Samme med postbetingelser (bruker er registrert, melding er sendt)

35. 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)

36. Eksempel

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

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

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

40. 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)

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

42. V-modellen (verifikasjonsmodellen)

43. Testplan – skal inn i prosjektet • V&V-plan (kvalitetssikringsplan) er en del av prosjektplanen • Fokus på feilavdekking/-retting ved kjøring av programmer • Testplanen bør inneholde beskrivelse av • enhetstest (UT) • integrasjonstest (IT) • systemtest (ST) • akspetansetest (AT) • Tidsplan (hvilke tester når) • Ressursbruk (mennesker/systemer/maskiner/data) • Testleveranser (testscript, testrapporter, dokumentasjon, etc.) • Risikofaktorer

44. Eksempel • For hvert testdesign • Gjennomføring av test for en eller flere ”features” • Relatert til kravspesifikasjon • ”Features” som skal testes/ikke testes • Hvilke ”test-cases” inngår • For hver test-case • Situasjoner som tester funksjonalitet • Input og forventet output • Eksekveringsbetingelser (f.eks. hvilke kundedata som skal ligge i databasen) • Testprosedyre (detaljert steg-for-steg beskrivelse for gjennomføring av testen)

45. Testdata • Eksempel: • Skal teste at en kunde flytter fra Oslo til Svalbard • Skal ikke betale moms • Bruker Per som testdata • Ok første gang • Andre gang feiler testen siden Per ble flyttet i test nr 1 • ==> Testdata må resettes mellom hver test • Dette er vanskelig/umulig • Vanskelig: • å finne komplette/realistiske testdata • å isolere testdata mellom tester • å teste konfidensielle data • Testdatabaser får fort dårlig datakvalitet • Blir ikke vedlikeholdt på linje med produksjonsdatabaser • Data blir herjet mer med enn data i produksjon • Feil i kode kan føre til inkonsistente tilstander

46. Enhetstesting i praksis Målet er å skrive automatiserte enhetstester

47. JUnit • Java-basert verktøy • Kan lastes ned gratis på www.junit.org

48. Eksempel på JUnit

49. 4. Gjenbruk • Kode som gjenbrukes er allerede testet • Mange penger å spare • Men den er ikke nødvendigvis testet for ditt bruk • ikke testet i din anvendelse • ikke testet med din konfigurasjon

50. Neste gang Gjesteforelesning: Å være gründer. En systemutviklingside blir til forretning. Yngve Lindsjørn Kompetanseweb as.