Testing av programvare

Transkript

1 Inf mars 2017: Testing av programvare Yngve Lindsjørn 1

2 Oversikt 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 Fra INF3121 Software testing 4

5 Fra INF3121 Software testing 5

6 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) 6 HiOA - Systemutvikling -> Testing 3

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

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

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

10 Kontrollering av syntaks Det er mer foretrukket å oppdage feil under compile-time fremfor runtime Syntakssjekking brukes i flere IDEer: Sjekker bare om et program «ser» riktig ut Gjør ingen dypere analyse enn å kontrollere programspesifikke nøkkelord, gyldige datatyper etc. «Lint»-programmer brukes i flere og flere IDEer: Gjør mer holistiske analyser, f.eks.: this line will never be executed this variable may not be initialized IDE à Integrated development environment, f.eks. Visual Studio eller Eclipse Lint à Verktøy som flagger mistenkelig kode 10 21

11 Fire teststadier 1. Bestemme hva som skal måles 2. Bestemme hvordan testingen skal gjennomføres 3. Utvikle test cases 4. Lage et testorakel (B. Bruegge & A. H. Dutoit, 2009) 11 22

12 1. Bestemme hva som skal måles Analytisk kunnskap om funksjonelle krav: Use case Forventet input Ugyldig output Design-kunnskap om systemets struktur, algoritmer, datastrukturer: Kontrollstrukturer (loop, test branches) Datastrukturer (arrayer, lister, databaser) Implementasjon-kunnskap: F.eks. algoritmer: Division by zero Test cases utelukkende for interrupt handler 12 23

13 2. Bestemme hvordan testingen skal gjennomføres Kodeinspeksjon Black-box eller white-box Velge tilnærming for integrasjonstesting Hvem skal teste? 13 24

14 3. Utvikle test cases Et test case er et sett med testdata eller situasjoner som vil bli bruk til å måle enheten (kode, modul, system) som testes eller det attributtet som kontrolleres Kryssjekke test cases og eliminere duplikater Automatisering av så mange tester som mulig Mål: finne the laveste antallet med testcases som dekker flest mulig stier 14 25

15 4. Lag et testorakel Et orakel inneholder alle predikerte resultater for et sett med test cases Testorakelets prediksjoner må skrives ned før den faktiske testingen begynner Menneskelig orakel: En ekspert kan undersøke input og tilhørende output og avgjøre om programmet leverer riktig output for gitt input Input Testobjekt Passerer testen? Auomatisert orakel: Et system som er i stand til å utføre oppgaven over Output (M. Kamkar, 2007) Testorake l 15 26

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

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

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

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

20 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 20

21 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 21

22 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 22

23 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 23

24 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 24

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

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

27 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 27

28 Testprosessen Integrasjonstesting Akseptansetesting Enhetstesting Systemtesting 28

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

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

31 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 31

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

33 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 33

34 Black-box testing Gitt input Forventet output Systemet 34

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

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

37 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 37

38 White box testing Gitt input Forventet output Systemet 38

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

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

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