GJENNOMGANG UKESOPPGAVER 9 TESTING

Transkript

1 GJENNOMGANG UKESOPPGAVER 9 TESTING INF1050 V16 KRISTIN BRÆNDEN

2 1 A) Testing viser feil som du oppdager under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.

3 Hvordan vite det du ikke vet?

4 Løsningsforslag oppgave 1A "Unknown unknowns" Det mulig at testene ikke dekker alle mulige utfall Vanskelig å teste mot noe du ikke vet er der Man vet aldri om man har oppdaget alle feil, fordi de ikke er oppdaget, ennå Hva om testene ikke er skrevet riktig?

5 1 B) Forklar hvorfor det ikke er nødvendig for et program å være fullstendig feilfritt før det overleveres kunden.

6 Løsningsforslag oppgave 1B De fleste programmer er ikke så kritiske at det ikke kan være gjenstående feil ved levering av produkt Noen feil blir ikke oppdaget før lenge etter at et system er tatt i bruk - for eksempel en funksjon som sjeldent brukes og med spesiell input Som regel lite lønnsomt å forsøke å rette alle feil før det settes i produksjon. Dette vet både kunde og leverandør, og ulike kontraksmessige forhold regulerer slik feilretting

7 2 Mange argumenterer for at utviklere ikke bør teste sin egen kode, men at all testing bør overlates til et eget testteam. Diskuter for og imot at utviklere selv tester sin egen kode.

8 Løsningsforslag oppgave 2 Fordeler med at utviklerne tester sin egen kode: Det er tidsbesparende at de selv tester koden, spesielt i enhetstesting og tidlig i utviklingsfasen. Mange feil blir oppdaget under whitebox-testing. Unødvendig at et uavhengig testteam skal finne feil som utvikler lettere finner fordi de kjenner den interne strukturen og koden i systemet.

9 Løsningsforslag oppgave 2 Ulemper med at utviklerne tester sin egen kode Da utviklerne kjenner den interne strukturen i koden, er det mulig at de kun tester for de utfallene som de selv kjenner til. Mens utviklerne kan se seg blinde på egen kode og struktur, kan et uavhengig testteam ha andre perspektiver som er viktige i testingen. Dette gjør at man kan teste for flere utfall.

10 3 Hva er regresjonstesting? Forklar hvorfor bruk av automatiserte tester og bruk av testrammeverk som JUnit forenkler regresjonstesting.

11 Løsningsforslag oppgave 3 Når vi benytter regresjonstesting utfører vi de samme testene om igjen etter hver kodeendring, selv om kodeendringen ikke nødvendigvis ligger i den koden som omhandler testen "Gamle" feil kommer ofte tilbake etter kodeendringer, og en av årsakene er at utviklere kan sjekke inn feil versjon av kode Det er ofte slik at en endring et sted i koden kan ha følger andre steder i programmet som man ikke forutså på forhånd

12 Løsningsforslag oppgave 3 Testrammeverk forenkler regresjonstesting fordi: Istedenfor å teste gammel kode om og om igjen selv, lager vi automatiserte tester som gjør dette for oss Det sier seg selv at automatisk testing vil være en stor fordel for regresjonstesting fordi man automatisk kjører samme test om igjen og om igjen

13

14 Eksempel JUnit

15 4 A) Hva forstår du med begrepet «stress-testing»?

16 Løsningsforslag oppgave 4A I stresstesting forsøker vi å finne antall transaksjoner eller operasjoner som et system tåler. Stresstesting handler om å utføre så mange operasjoner at deler av eller hele systemet bryter sammen. Vi noterer oss antall og type transaksjoner som ble utført i det dette forekommer.

17 4 B) Foreslå hvordan du vil stressteste et minibanksystem der det er mulig å sjekke konto og ta ut kontanter i NOK.

18 Løsningsforslag oppgave 4B Eksempel: - Kan forsøke å kjøre mange oppkoblinger mot den samme banken - Kan se hvor mange ulike brukere systemet takler samtidig

19 5 Forklar forskjellen på enhetstest og integrasjonstest (eller grensesnitttest i Sommerville). Gi et konkret eksempel.

20 Enhetstester Enhetstesting tester individuelle enheter av kildekode I objektorientert programmering kan det være en hel klasse eller en metode Enheten testes helt isolert fra resten av systemet Formålet med en enhetstest er å forsikre at koden gjør akkurat det den skal

21 Enhetstester La oss si at vi vil enhetsteste en metode hentnavn() For å teste denne metoden isolert fra resten av systemet, mater vi programmet med et vilkårlig navn I vårt tilfelle Anders For hver gang Anders returneres er testen vellykket Får vi et annet navn, feil datatype eller null, skriver vi ut at testen har mislyktes, siden vi får en feil verdi

22 Integrasjonstester I integrasjonstesting setter vi sammen enheter og gjør tester på komponenter

23 Løsningsforslag oppgave 5 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.

24 6 A) Hva er forskjellen på black-boxtesting og whitebox-testing?

25 Løsningsforslag oppgave 6A 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 Fra forelesning

26 Løsningsforslag oppgave 6A Black-box

27 Løsningsforslag oppgave 6A 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. Fra forelesning

28 Løsningsforslag oppgave 6A White-box

29 6 B) Forklar fordeler og ulemper ved hver av dem

30 Fordeler black-box 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 et brukerperspektiv og kan dermed avsløre mangler i kravspesifikasjonen Planleggingen av testingen kan påbegynnes tidlig Fra forelesning

31 Ulemper black-box Kan kun teste et lite antall input, og mange stier (paths) og tilstander vil derfor ikke bli testet 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 Fra forelesning

32 Fordeler white-box 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 Fra forelesning

33 Ulemper white-box 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 Fra forelesning

34 7 Foreslå «testcases» for usecaset «ta ut penger» i en minibank. Ta for deg enhetstesting og integrasjonstesting.

35 Løsningsforslag oppgave 7 Enhetstester Blir PIN-kode validert korrekt? Blir kort godkjent korrekt? Blir kort spyttet ut korrekt? Integrasjonstester Henter man saldo fra riktig konto? Trekkes riktig beløp fra konto?

36 8 Hvorfor er det viktig å utføre både funksjonell og ikke-funksjonell testing?

37 Løsningsforslag oppgave 8 Funksjonell testing: HVA systemet gjør Eks: Tester om systemet gjør det de funksjonelle kravene spesifiserer F.eks om A1 gir output A2

38 Løsningsforslag oppgave 8 Ikke-funksjonell testing: HVORDAN systemet virker Eks: Tester brukervennlighet, effektivitet etc.

39 9 Hvorfor er det viktig å utføre vedlikeholdstesting?

40 Løsningsforslag oppgave 9 Kan utføre vedlikeholdstesting: Når programvare endres Når plattform o.l. endres Når programvare fjernes Alle disse tilfellene kan føre til nye feil/at gamle feil oppstår igjen. Derfor er denne typen testing viktig.

41 TAKK FOR MEG Spørsmål? Basert på slides av André Lincoln Read og Kristian Saksvik Munkvold + Emilie Hallgren KRISTIN BRÆNDEN