Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

1 Validering og verifisering Kirsten Ribu 04.04.2005.

Liknende presentasjoner


Presentasjon om: "1 Validering og verifisering Kirsten Ribu 04.04.2005."— Utskrift av presentasjonen:

1 1 Validering og verifisering Kirsten Ribu

2 2 I dag Validering og verifisering Inspeksjon Testing

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

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

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

8 8

9 9 Hva slags feil?

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

14 14

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

19 19 Eksempel – lag en prototyp med HTML:

20 20

21 21

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 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 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 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 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 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 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 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 33 Vær-data sekvensdiagram

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

35 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 36 Eksempel

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

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

42 42 V-modellen (verifikasjonsmodellen)

43 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 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 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 46 Enhetstesting i praksis Målet er å skrive automatiserte enhetstester

47 47 JUnit Java-basert verktøy Kan lastes ned gratis på

48 48 Eksempel på JUnit

49 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 50 Neste gang Gjesteforelesning: Å være gründer. En systemutviklingside blir til forretning. Yngve Lindsjørn Kompetanseweb as.


Laste ned ppt "1 Validering og verifisering Kirsten Ribu 04.04.2005."

Liknende presentasjoner


Annonser fra Google