BlackBox, WhiteBox og andre testmetoder Etter ønske fra studentene 26. november 2009
Hva er testing? Testing er å undersøke IT-systemer eller deler av det for å vurdere om kravene til det som testes er tilfredstilt. Det vil si å: utføre analyser for å kontrollere software og dokumentasjon mot krav og forventninger. utføre programmer og kontrollere om resultat er som spesifisert eller som forventet.
Hvorfor teste? Finne og rette feil før systemet blir tatt i bruk Spare penger ved å rette og forebygge feil på et tidlig tidspunkt. Jo lenger ut i utviklingsfasen en feil oppdages og rettes, desto større blir kostnadene. Sertifisere software. Vurdere kvaliteten til systemet. Når testingen er utført har en god kunnskap og erfaring om hvordan systemet fungerer.
Testing av store systemer krever metodisk arbeid Lage testplan Beskrive formålet med testen Hvilke steg som skal testes Hvilke data som skal testes Lage testdata med størst mulig dekning Gjennomføre testingen etter testplanen Rapportere resultatene
Forløp Avklare forutsetninger og mål Beskrive de aktuelle testtilfeller Avklare hvordan testen skal gjennomføres Gjennomføre testingen Dokumentere testingen Rapportere Graden av formalitet avhenger av hvordan testen skal brukes i fremtiden
To hovedtyper Statisk testing Analyser som utføres på skrevne dokumenter, Reviews / gjennomganger / inspeksjoner Hensikten er å dokumentere at systemet følger spesifikasjonene eller finne avvik Finner misforståelser og glemte ting. Billig metode. Gjøres før dynamisk. Dynamisk testing Kjøring av testobjektet på en datamaskin Hensikten er å bekrefte verdier eller finne avvik fra forventede verdier Uferdige deler av programmet må erstattes av testomgivelser, driver og stub
Mange testnivåer Modultest: Finne feil i detaljdesign og kode. Modulintegrasjonstest: Test av modulinteraksjon. Moduler på samme plattform eller i samme prosess. For å finne grensesnittfeil. Høyere nivå integrasjonstest: Test av interaksjon mellom subsystemer. Moduler på forskjellige plattformer eller i flere prosesser. For å finne grensesnittfeil. Vanligvis på målplattformen. Systemtest: Test mot kravspesifikasjon. Funksjonell test: Test av hver funksjon mot dens krav. For å finne høynivå-designfeil og misforståtte krav. Interaksjonstest: Test av funksjoner med en annen. For å finne konflikter mellom funksjoner. Ikke funksjonell test: Test spesielle ting og systemegenskaper. System integrasjonstest: Test av interaksjon mellom systemet og andre eksterne systemer. For å finne grensesnittfeil. Akseptansetest: Kundetest for å se om systemet oppfyller kontraktskrav og forventninger. Er systemet brukbart i praksis?
Mange typer av tester Whitebox-testing Teste modulens indre oppbygging Blackbox-testing teste modulens funksjonalitet Statistisk testing beregne systemets pålitelighet Stresstesting måle belastningen før systemet feiler Benchmarking sammenligne systemer
White-box testing - strukturtesting Andre navn Glass-box, Clear-box Målet er å teste alle programsetninger Egnet for små programmoduler Analysere kode for å identifisere ekvivalensklasser
White-box testing - strukturtesting Systematisk dekning av programdeler (linjer, forgreninger etc.). Lett å måle med automatiske verktøy. Viktig å vite at alt er testet. Kildekoden er kjent White-box testing forutsetter kjennskap til den indre struktur og virkemåte til modulen som testes. Enhetstesten for egenutviklede moduler er som oftest white-box testing Utvikleren er som oftest ansvarlig for å utføre enhetstesten
Black-box testing - funksjonstesting Systematisk test som bygger på spesifikasjoner på alle nivåer. Finner misforståelser, glemte ting, funksjonelle feil. Kildekoden er ukjent Black-box testing betrakter programvaren som en svart boks og kjenner bare grensesnittet mot omverdenen. Brukes på mange nivå, som integrasjonstest, systemtest og akseptansetest Testene utledes fra spesifikasjonen Gir systemet inndata, kontroller utdata Viktig å finne inndata som fører til feil eller bekrefter at funksjonen fungerer riktig Bruke kunnskaper om anvendelsesområdet Gjennomføre systematiske testdatautvalg Tester for hyllevare og gjenbrukmoduler bør være black-box tester. Da testes grensesnittet til modulen og de ulike funksjonene med grensesnittet i modulen.
Utfordringer ved Black-box testing Parametere kan ha feil rekkefølge og type Feil kan oppstå på grunn av feil i test bed, alle omgivelser testobjektet trenger for å testes Testobjekt Programenheten som skal testes Driver Programmet som kaller testobjektet Stub Programmet som kalles av testobjektet PoC Point of Control - input PoO Point of Observation output
Marerittet Antar: z = f(x) + g(y) - Om z får en uventet verdi under kjøring hva er grunnen? Er funksjonen feil z = f(x) - g(y)? Er det feil i f(x) eller g(y)? Er det feil i verdien til argumentene x=1, men skal være x=0 Er det feil i en testdriver Er det feil i en teststub
Modul-, Enhets-test Laveste testnivå Tester at modulen (enheten, objektet) virker isolert Forsikre oss om at kode eksekverer uten kjørefeil Simulerer testomgivelsene til komponenten Driver Program som kaller komponenten - innverdier Stub Program som komponenten kaller opp - utverdier Utføres av utviklere Skrives ofte som automatiske tester Tester: dataflyt grenseverdier feilhåndteringsmekanismer
Integrasjonstest Teste samspillet mellom enheter. Forsikre oss om at bitene i et større system fungerer sammen Grunner til at de ikke at de fungerer sammen kan være: Data kan gå tapt på tvers av moduler En modul kan ha en uventet effekt på en annen Sub-funksjoner spiller ikke sammen Tester at komponenten (klassen) virker sammen med andre komponenter Simulerer ofte andre sub-systemer Bruker konstruerte testdata Utføres ofte av utviklere
Systemtest Bekrefter at systemet oppfører seg korrekt i samspill med omgivelsene, og fyller de overordnede kravene i kravspesifikasjon. Systemtest kjøres etter at hele systemet er satt sammen, og i et testmiljø som skal simulere et driftsmiljø. Tester både funksjonelle og Ikke-funksjonelle krav som: sikkerhet stresspåvirkning ytelse feilhåndtering
Akseptansetest Akseptansetesten utføres for å avgjøre om et produkt oppfyller kundens behov, og stemmer overens med spesifikasjonen og annen dokumentasjon. Akseptansetesten er siste mulighet for en kunde å avvise et utilstrekkelig produkt, før det settes i drift. En godt gjennomført akseptansetest kan beskytte kunden mot tap som skyldes dårlige produkter
Akseptansetest Kunden har ansvaret for å gjennomføre testen Tester at systemet lar brukerne gjøre det de trenger Tester med reelle data Utføres gjerne i samarbeid mellom kunder og testere
Struktur i en akseptansetest Akseptansetesten består av fem faser: 1. Bestemme hvor kritisk systemet er (Analyser krav til testen) 2. Bestemme hvilke kvaliteter som skal testes eller evalueres (Spesifiser detaljerte krav til testen) 3. Designe testen 4. Utfør testen 5. Rapporter resultatene De første tre fasene tilhører planleggingen og er først og fremst kundens ansvar. De siste to fasene krever sterk deltakelse av leverandøren.
Planleggingen Avklare hvor mye ressurser som skal brukes på testen Avklare hva som skal testes alt eller prioritet Risiko for feil og viktighet i praktisk bruk. Finne feilene som er viktigst i drift Beslutte hvilke funksjonskrav som skal testes. Beskriv scenarier for de enkelte funksjonene. Velge testdata Klargjøre for testingen
Gjennomføre akseptansetesten Gjennomføre testen etter testplanene Kundens medarbeidere kjører testen og vurderer resultatene Utføres nye tester underveis skal en senere fortsette der en forlot den planlagte testen. Feil som oppstår registreres Feil som ikke påvirker det videre testforløpet registreres og testen fortsetter. Feil som stopper testen registreres og rettes umiddelbart Testen inkluderer vurdering av brukerhåndbok Beslutte om systemet skal aksepteres