Inf1055 Modul B 26 april 2017:

Transkript

1 Inf1055 Modul B 26 april 2017: Del 1: - Testing Yngve Lindsjørn ynglin@ifi.uio.no 1

2 Oversikt - Testing Hva er testing? Validering &Verifisering Testfaser Enhetstesting Integrasjonstesting Systemtesting Akseptansetesting Typer av test Blackbox testing Whitebox testing Regresjonstesting Testdrevet utvikling (TDD) Brukes ofte ved smidig metodikk Testing pleier ofte å dukke opp på eksamen i en eller annen form 2

3 Fra INF3121 Software testing 3

4 Antall feil Gjennomsnittet ute i industrien: feil per 1000 linjer med kode (S. McConnell, 2004) feil per 1000 linjer med kode feil per 1000 linjer med kode ikke oppdaget før levering (M. Wooldridge, 2000) Gjennomsnittet blant Microsoft sine applikasjoner: feil per 1000 linjer med kode 0.5 feil per 1000 linjer med kode ikke oppdaget før levering (S. McConnell, 2004) 4 HiOA - Systemutvikling -> Testing 3

5 Kostnad for å rette feil Kostnad for å rette feil Tidspunkt når feil blir oppdaget Arkitektur Konstruksjon Systemtest Etter release Kravspesifikasjon Kravspesifikasjon 1x 3x 5-10x 10x x Feil introdusert Arkitektur 1x 10x 15x x Konstruksjon 1x 10x 10-25x (NIST, M. Newman, 2002) 5

6 Oppgave Bruk to minutter på å tenke over (skriv gjerne) feil i programvare du har opplevd. Har noen av feilene vært alvorlige? Diskuter med person(e) ved siden av deg. 6

7 Hva er testing? Helt enkelt: For en gitt input forventer vi en gitt output Hensikten er: Å vise at systemet gjør det systemet er ment å gjøre Å oppdage feil før systemet blir tatt i bruk Testing viser bare feil som du oppdager under kjøring av testen. Den beviser ikke at systemet er feilfritt. Testing er en del av en mer generell verifikasjons- og valideringsprosess. 7

8 Validering & Verifisering Validering: Bygger vi det riktige produktet? Programvaren bør gjøre det brukerne virkelig ønsker Fokus på hele systemet Gjøres som regel i ekte eller simulerte omgivelser Verifisering: Bygger vi produktet riktig? Stemmer det med kravspesifikasjonen? Fokus på komponent/delsystem Gjøres som regel i laboratorium (test servere..) 8

9 Testing bør være Repeterbar Hvis en test avdekker en feil vil du ønske å kjøre testen på nytt for å finne andre feil Hvis du retter en feil vil du ønske å kjøre testen på nytt for å kontrollere Systematisk Tilfeldig testing er ikke tilstrekkelig Velge en rekke testsett som dekker spennet med tilstander programmet kan ha Velge en rekke testsett som er representative for ekte bruk av programmet Dokumentert Holde orden på hvilke tester som er utført og hva resultatet var 9

10 Generelle retningslinjer for testing Velg input som tvinger systemet til å generere alle feilmeldinger Design input som fører til overbelastning ( overflow ) Gjenta samme input eller serier av input en rekke ganger Prøv å framprovosere ugyldig output Prøv å tvinge fram beregningsresultater som er for stort eller for lite 10

11 Testfaser Utviklingstesting. Testing foregår under utviklingsfasen Brukertesting /Akseptansetesting. Brukerne eller potensielle brukere tester systemet i egne omgivelser 11

12 Utviklingstesting Enhetstesting (unit testing). Individuelle programenheter eller objektklasser testes. Fokus på å teste funksjonaliteten til objekter og metoder. Integrasjonstesting. Ulike individuelle enheter er integrert til sammensatte komponenter. Fokus på å teste grensesnittet til komponenter. Systemtesting. Noen eller alle komponentene i et system er integrert og systemet testes som en helhet. Fokus på å teste interaksjoner mellom komponenter. 12

13 Enhetstesting Enhetstesting er prosessen å teste individuelle komponenter isolert Enheter (Units) kan være Individuelle metoder i et objekt Objektklasser med attributter og metoder Sammensatte komponenter med definert grensesnitt 13

14 Testing av objektklasser Komplett testing av en klasse involverer Testing av alle metoder av et objekt (instans) av klassen Sette verdier og teste alle attributter Teste objektet i alle mulige tilstander Arvemekanisme gjør det vanskeligere å designe objektklassetester, siden vi på forhånd ikke vet hvor informasjonen som vi vil teste befinner seg 14

15 Automatisk testing Enhetstesting bør automatiseres så langt det lar seg gjøre, slik at tester kan kjøres uten manuell innblanding I automatisk enhetstesting brukes et automatiseringsrammeverk (for eksempel JUnit) for å skrive og kjøre testene 15

16 To typer enhetstester Tester normal bruk, for å sjekke om enheten/ komponenten oppfører seg som forventet Tester unormal bruk, for eksempel unormal input for å sjekke at enheten/komponenten ikke krasjer 16

17 Integrasjonstesting (grensesnittesting) Programvarekomponenter er ofte sammensatt av mange objekter som samhandler Funksjonaliteten til objektene aksesseres gjennom deres definerte grensesnitt Å teste sammensatte komponenter fokuserer på at grensesnittet oppfører seg i henhold til spesifikasjonen Kan anta at enhetstester på alle individuelle objekter som utgjør komponenten allerede er testet 17

18 Systemtesting Systemtesting involverer integrerte komponenter som til sammen skaper en versjon av systemet og som tester det integrerte systemet Fokuset i systemtesting er å teste samhandlingen mellom komponenter (eller sammensatte komponenter) Systemtesting sjekker at komponentene er kompatible, at de samhandler korrekt, og at de sender riktige data til riktig tid gjennom grensesnittene. 18

19 Oppgave Bruk to minutter på å foreslå testcase (skriv gjerne) for usecaset send penger i appen Vipps. Diskuter med personen ved siden av 19

20 Fra E-resept- ulike moduler/systemer Faglige grunndata til bruk i e-resept skal leveres av Legemiddelverket gjennom deres FEST tjeneste. Grunndata levert fra FEST skal kunne kombineres med annen grunndata i mottakersystemene... FEST= forskrivnings- og ekspedisjonsstøtte VRS=Vareregisteret HELFO=Helseøkonomiforvaltningen Informasjon om Legemidler skal baseres på informasjon fra Athene og kombineres med informasjon fra VRS. Informasjon om Legemidler skal omfatte alle legemidler som har fått utdelt varenummer i VRS og finnes tilgjengelig i apotek. Legemiddelverket skal levere interaksjonsdata i FEST.. Informasjon om handelsvarer blir hentet fra to kilder, VRS skal levere alle handelsvarer som er relevant for multidosepakking og HELFO skal levere oversikt over pris og produkter som er refusjonsberettiget på blåresept (alle handelsvarer). 20

21 Akseptansetesting Evaluere systemet som leveres I smidig metodikk (XP, Scrum..) bruker man ofte funksjonell testing av brukerhistorier som akseptansetester Fokus: Validere at systemet som er utviklet faktisk er det kunden vil ha Mål : Bekrefte at systemet imøtekommer kundens krav og er klar til bruk 21

22 Testprosessen Integrasjonstesting Akseptansetesting Enhetstesting Systemtesting 22

23 Testdrevet utvikling Testdrevet utvikling (test-driven development (TDD)) er en tilnærming der testing og koding gjøres parallelt Kode utvikles i steg (inkrementelt), sammen med en test for hvert inkrement. Går ikke til neste inkrement før koden passerer testen TDD ble introdusert som en del av smidig metodikken i XP. Men TDD kan også brukes i plandrevet utviklingsprosess 23

24 Prosessaktiviteter i testdrevet utvikling Start med å identifisere funksjonaliteten som kreves i et inkrement. Normalt lite og kan implementeres i få linjers kode Skriv en test for denne funksjonaliteten og lag testen som automatisk test Kjør testen, sammen med andre tester som er implementert. Første gang er ikke koden skrevet for dette inkrementet, slik at testen vil feile Implementer funksjonaliteten, og kjør testen på nytt Når alle testene er OK (ikke feiler), starter implementering av funksjonalitet i neste inkrement 24

25 Fordeler ved testdrevet utvikling Dekning av kode All segment av kode har minst en assosiert test Regresjonstesting En regresjonstest-pakke utvikles inkrementelt og samtidig med at programmet utvikles Enklere å finne feil ( debugging ) Når en test feiler, er det enkelt å finne ut hvor feilen ligger Systemdokumentasjon Testene er i seg selv en form for dokumentasjon som beskriver hva koden gjør 25

26 Regresjonstesting Fokuserer på å finne feil etter endring av kode (som regel større kodeendring) Søker å finne feil som var der tidligere Kjører tidligere tester om igjen Fordel med automatiserte tester Testene må være godkjent før kodeendringen blir godtatt ( commited ) 26

27 Black-box testing Black-box testing er en metode (eller strategi) som tester funksjonaliteten til et program i motsetning til den interne strukturen eller kildenkoden Kunnskap om intern struktur eller programmering er ikke nødvendig Tester er bygd rundt spesifikasjoner og krav, dvs. hva programmet er ment å gjøre Black-box testing kan brukes på alle nivåer av programvaretesting: Enhetstesting, integrasjonstesting, systemtesting og brukertesting 27

28 Black-box testing Gitt input Forventet output Systemet 28

29 Fordeler med black-box testing Krever ikke programmeringskunnskaper Kan bruke uavhengige testere som ikke har vært involvert i utviklingen Unngår at testere gjør samme antagelser som utviklerne Resultater kan tolkes uten å kjenne til detaljer ved implementasjonen Testing gjøres fra en brukerperspektiv og kan dermed avsløre mangler i kravspesifikasjonen Planleggingen av testingen kan påbegynnes tidlig 29

30 Ulemper med black-box testing Kan kun teste et lite antall input og mange stier (paths) og tilstander vil derfor forbli utestet Man er aldri sikker på hvor mye av systemet eller hvilke deler av systemet som er testet Kan i noen tilfeller være redundante om utviklerne allerede har kjørt tilsvarende tester Selv om man kan planlegge disse testene tidlig kan de som regel ikke anvendes før i senere testfaser 30

31 White-box testing White-box testing (glass-box testing, strukturell testing) tester interne strukturer eller kode i et program, i motsetning til dens funksjonalitet I white-box testing kreves og brukes programmeringsferdigheter til å designe testene White-box testing brukes vanligvis under enhetstesting, men kan også brukes i integrasjons- og systemtesting. Kan avdekke mange feil eller problemer, men oppdager ikke ting som ikke er implementert i henhold til kravspesifikasjonen, heller ikke manglende krav 31

32 White box testing Gitt input Forventet output Systemet 32

33 Fordeler med white-box testing Kan utføres i et tidlig stadie -> trenger ikke vente på grensesnitt (f.eks. GUI) Testingen er mer grundig, systematisk og strukturert Fordi det krever innsikt i strukturen vil man enkelt finne ut av hvilken input/data som mest effektivt tester programmet Hjelper til med å optimalisere koden Tvinger utvikler til å begrunne kode Kan skrelle vekk overflødige kodelinjer 33

34 Ulemper med white-box testing Krever programmeringskunnskaper Kan kun utføres av utviklere som har vært involvert i utviklingen Som å studere innsiden av en motor for å forstå hvorfor bilen ikke fungerer -> gir ikke alltid riktige svar Kan være vanskelig å gjennomføre hvis implementasjonen forandres veldig ofte 34

35 Appendix: Mange typer tester Fasilitetstesting - > utfører systemet all påkrevd funksjonalitet? Volumtesting -> kan systemet håndtere store datavolum? Stresstesting -> klarer systemet å håndtere høy påkjenning? Utholdenhetstesting -> vil systemet klare kontinuerlig arbeid over lenger tid? Brukbarhetstesting -> kan brukere bruke systemet på en enkel måte? Sikkerhetstesting -> klarer systemet å takle angrep? Ytelsestesting -> hvor god er responstiden? Lagringstesting -> er det noen uforventede datalagringsproblemer? Konfigurasjonstesting -> vil systemet fungere på alle typer av påtenkt maskinvare? Installasjonstesting -> klarer vi å installere systemet? Pålitelighetstesting -> hvor pålitelig er systemet over tid? Gjenopprettingstesting -> hvor bra klarer systemet å gjenopprette fra feil? Vedlikeholdstesting -> hvor vedlikeholdbart er systemet? Dokumentasjonstesting -> hvor presis, dekkende, brukbar etc. er dokumentasjonen? Operasjonstesting -> er operatørenes instruksjoner dekkende og forståelige? Regresjonstesting -> gjenta alle gamle tester ved hver systemendring 35