Testing av programvare. INF1050: Gjennomgang, uke 08

Transkript

1 Testing av programvare INF1050: Gjennomgang, uke 08

2 Kompetansemål Testing av programvare Hva og hvorfor? Testfaser Ulike nivåer Testtyper Spesifikasjonsbasert testing / Strukturbasert testing Testdrevet utvikling

3 Bakgrunn for testing Hva er testing? Hvorfor er testing viktig? De syv testprinsippene

4 Testing: Hva og hvorfor? Testing Utforsker et system / systemkomponenter for å avdekke feil eller mangler Nødvendig for kvalitetssikring av et system Sørge for at systemet som bygges holder høy standard Etablere gode kunderelasjoner Påser at systemet innfrir funksjonelle og ikke-funksjonelle krav Forsikre seg om at man har laget det man skal lage, og på en god måte Økonomisk gevinst Avdekking av feil under utvikling er ofte rimeligere enn når systemet er tatt i bruk Et svært viktig tema i systemutvikling!

5 De syv testprinsippene 1. Testing viser feil Testing kan bare vise at feil / defekter eksisterer Testing kan ikke bevise at et program er feilfritt 2. Fullstendig testing er umulig Det er umulig å teste alt Kan ikke teste alle mulige kombinasjoner mellom input og betingelser 3. Tidlig testing Testing bør starte så tidlig som mulig i utviklingsprosessen Testinnsatsen bør fokuseres på tydelig definerte mål

6 De syv testprinsippene 4. Konsentrasjon av feil (defect clustering) Et samlet mindretall av komponenter / moduler inneholder de fleste feilene Feil er ikke jevnt fordelt i kildekoden Noen komponenter er mer komplekse å utvikle enn andre Enkelte utviklere kan være mindre kompetente og dermed produsere flere feil 5. Plantevernmiddelparadokset (pesticide paradox) Hvis de samme testene kjøres gang på gang, vil de til slutt ikke finne flere feil Tester bør oppdateres og tilpasses jevnlig Nye tester bør inkluderes ved behov Øker sannsynligheten for å oppdage ytterligere feil i systemet

7 De syv testprinsippene 6. Testing er kontekstavhengig Testinnsatsen avhenger av konteksten Ulike systemer bør testes på ulike måter Testfokus varierer fra system til system Eksempel: Sikkerhetskritiske system testes ikke på samme måte som trivielle spill 5. Fravær av feil -fellen Et feilfritt system er ikke nødvendigvis et brukbart system Validering Bygger vi det riktige produktet? Verifisering Bygger vi produktet riktig?

8 Gjennomgang av ukesoppgaver Ukens tema: Testing av programvare

9 Oppgave 1(a) Testing viser feil som oppdages under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.

10 Oppgave 1(a): Løsningsforslag Forklar hvorfor testing ikke kan bevise fravær av feil Absence of evidence is not evidence of absence

11 Oppgave 1(a): Løsningsforslag Forklar hvorfor testing ikke kan bevise fravær av feil Kun fordi det ikke oppdages, betyr ikke at det ikke finnes Å bevise et negativ: Kan man bevise at julenissen ikke eksisterer? Hvordan vite det man ikke vet? Tester kan være skrevet av utviklere Tunnelsyn: Fokuserer bare på det man forventer av feil Utfordrende å sette seg fullt inn i brukerens perspektiv Tester kan være skrevet feil / inneholde mangler

12 Oppgave 1(b) Forklar hvorfor det ikke er nødvendig for et program å være fullstendig feilfritt før det overleveres til kunden

13 Oppgave 1(b): Løsningsforslag Forklar hvorfor det ikke er nødvendig for et program å være fullstendig feilfritt før det overleveres til kunden Enkelte feil kan aksepteres / ignoreres De fleste programmer er ikke så kritiske at de ikke kan inneholde feil Feil i systemet betyr ikke nødvendigvis at systemet er ubrukelig Det kan være feil i områder brukeren aldri oppdager Økonomisk motivasjon Som regel lite lønnsomt å avdekke / rette opp alle feilene før release

14 Oppgave 2 Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode

15 Oppgave 2: Løsningsforslag Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode Fordeler Ressursbesparende Redusert tid og reduserte kostnader Unødvendig at eksterne team skal finne feil utviklere selv kan finne Utviklere kjenner allerede til den interne strukturen og koden i systemet Desto mindre kode, desto lettere er testingen Utviklere kan derfor delta i testinnsatsen tidlig i utviklingsprosessen

16 Oppgave 2: Løsningsforslag Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode Ulemper Testing og utvikling er to forskjellige grener Testere og utviklere har derfor helt ulike utgangspunkt

17 Oppgave 2: Løsningsforslag Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode Ulemper Vanskelig å skille mellom hvordan det virker og hvordan det skal virke Utviklere kan se seg blinde på egen kode Utviklere har ofte en formening om hvor feilene ligger, og fokuserer ensidig på disse Kan være vanskelig å løsrive seg fra utviklermentaliteten Utviklere er ikke nødvendigvis kompetente testere Løsningen Bruk eksterne testere / team til å gjennomføre testingen

18 Oppgave 2: Løsningsforslag Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode Interne eller eksterne testere? Testing er en vurdering av kvalitet Interne testere kan oppleve det som vanskelig å poengtere medarbeideres feil Eksterne testere / testteam Eksterne testere kan ofte se (andre) feil / mangler som utviklere selv ikke oppdager Kommer inn med andre antakelser og forutsetninger enn utviklerne Eksterne testere nyter ofte mer troverdighet hos organisasjonen / ledelsen Kan uttrykke feil på en ærlig og kritisk måte

19 Oppgave 3 Hva er regresjonstesting? Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting.

20 Oppgave 3: Løsningsforslag Hva er regresjonstesting? Ulike testkategorier

21 Oppgave 3: Løsningsforslag Hva er regresjonstesting? Regresjonstesting Testing relatert til endringer Når? Etter at kildekoden / systemet har blitt endret Mål Avdekke eventuelle feil som har blitt introdusert i kildekoden etter endring Konsekvensanalyse gjennomføres i forkant Kartlegger deler av kildekoden som har stor sannsynlighet for å bli påvirket Teknikker for regresjonstesting Test alt (full regresjonstest) Test utvalg Prioriter tester Kombinasjon av disse Regresjonstester og konfirmasjonstester er ikke det samme! Konfirmasjonstester skal bekrefte at eventuelle feil er blitt rettet opp

22 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Automatisering av tester Testing Nødvendig aktivitet for å sikre kvalitet Ønsker å dekke mest mulig funksjonalitet / avdekke feil gjennom testing Testinnsatsen kan være tidkrevende, kostbar, og ikke minst repetitiv Umulig å dekke testbehovet manuelt (spesielt for større systemer) Programvare og rammeverk forenkler testinnsatsen Kan overlate testingen til automatiserte prosesser

23 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Automatiserte tester og rammeverk Bruk av programvare / verktøy for å gjennomføre testing Tester kildekode om og om igjen, uten at dette må gjøres manuelt Fordeler Tester utføres på nøyaktig samme måte som tidligere Umiddelbar sammenligning av forventet og faktisk utfall av testene Økt testomfang Ressursbesparende Tid / Innsats / Penger

24 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Eksempel: Enkel side for innlogging (krever grundig testing!) Input Brukernavn og passord Regler Riktig kombinasjon skal gi tilgang til siden Vi skriver tester for to ulike scenarioer Brukeren er allerede registrert Brukeren er ikke registrert

25 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Spesifikasjon for test_1 og test_2 ID Beskrivelse Pre-betingelse Input Prosedyre Forventet resultat 1 Gyldig bruker logges inn Brukeren er allerede registrert 1. Oppgi input (brukernavn og Gyldig brukernavn passord) Gyldig passord 2. Klikk "logg inn" Bruker logges inn Ugyldig 1. Oppgi input (brukernavn og 2 Ugyldig bruker avvises Brukeren er ikke registrert brukernavn passord) Ugyldig passord 2. Klikk "logg inn" Bruker avvises

26 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Vi kjører begge testene, og antar at vi har følgende innhold i databasen

27 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Vi har nå oppdaget en feil i systemet! Test 1 var vellykket En registrert bruker fikk logget inn Test 2 var mislykket En uregistrert bruker fikk logget inn Vi gjør de nødvendige endringene Eksempel: Endre kildekode / Restrukturer databasen / Endre koblingen mellom disse Kjører en konfirmasjonstest for å bekrefte at feilen er rettet Kjører en regresjonstest for å avdekke eventuelle nye feil i systemet

28 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Vi kjører testene på nytt, og anta vi nå har følgende scenario:

29 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Selv om feilen er rettet opp, har vi nå introdusert nye feil Hvordan går vi frem? Vi må gjøre ytterligere endringer for å rette opp nye feil Vi må bekrefte at nye feil er rettet opp Vi må igjen bekrefte at endringer ikke har introdusert nye feil Både før og etter kjøring av testene Dette er svært tidkrevende, spesielt for større systemer!

30 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Bruker heller automatiserte tester og rammeverk Kan mate verktøyet med data Mange ulike kombinasjoner av input og betingelser Kan la programvaren, og ikke menneskene, gjøre jobben Slipper å teste 100, eller 1000 kombinasjoner for hånd! Kan lage samlinger av ulike (regresjons)tester Kan kjøre flere (regresjons)tester etter hverandre

31 Oppgave 4(a) Hva forstår du med begrepet stresstesting?

32 Oppgave 4(a): Løsningsforslag Hva forstår du med begrepet stresstesting? Stresstesting Stresse systemet under test Kartlegge systemets stabilitetsegenskaper Avdekke antall transaksjoner / operasjoner et system er i stand til å takle Fremprovosere systemkollaps Hensikt Eksponere breaking points Avdekke kapasitet i henhold til systemkrav og spesifikasjon Avdekke hvordan systemet håndterer kollaps

33 Oppgave 4(b) Foreslå hvordan du vil stressteste et minibanksystem der det er mulig å sjekke saldo på konto og ta ut kontanter

34 Oppgave 4(b): Løsningsforslag Foreslå hvordan man kan stressteste et minibanksystem Formål med stresstester Stresse systemet til det kollapser En vellykket stresstest avdekker systemets breaking points Fremgangsmåte La minibanksystemet utføre mange transaksjoner samtidig Sjekk deretter om alle transaksjoner ble behandlet korrekt Redegjør for hvorvidt systemet taklet stresset / hvordan? Utvid stresstesten til systemet krasjer / tilfredsstiller spesifikasjonen

35 Oppgave 5 Hva er forskjellen på enhetstest og integrasjonstest?

36 Oppgave 5: Løsningsforslag Hva er forskjellen på enhetstest og integrasjonstest? Ulike testnivåer Testing av programvare er en omfattende prosess Bør stykkes opp Man kan (bør) ikke teste alt på en gang Testing bør starte så tidlig som mulig Hvordan teste så tidlig som mulig? Det er begrenset hvor mye man kan teste tidlig i utviklingsfasen Testing deles ofte opp i ulike testnivåer Hvert nivå er tydelig definert med tanke på formål og aktiviteter

37 Oppgave 5: Løsningsforslag Hva er forskjellen på enhetstest og integrasjonstest? Ulike testnivåer

38 Oppgave 5: Løsningsforslag Hva er forskjellen på enhetstest og integrasjonstest? Enhetstesting Tester individuelle enheter / komponenter (kildekode) Eksempel: Enheter i programmering Klasser / Metoder Enheten testes isolert fra resten av systemet Gjennomføres ofte tidlig i utviklingen / testingen Formål Forsikre seg om at enheten gjør akkurat som den skal Uavhengig av samspill med øvrige komponenter

39 Oppgave 5: Løsningsforslag Hva er forskjellen på enhetstest og integrasjonstest? Karakteristikker for god enhetstesting Isolasjon Testene til en klasse X avhenger ikke av å ha implementert andre klasser Testene i en klasse X skal ikke feile på grunn av feil i øvrige klasser Uavhengighet Hver enhetstest skal være selvforsynt Skal virke uavhengig av andre enhetstester som kjøres Enkelhet En enhetstest = Ett scenario

40 Oppgave 5: Løsningsforslag Hva er forskjellen på enhetstest og integrasjonstest? Eksempel: Enhetstesting Anta at vi har satt navn til Anders Forventer at hentnavn() skal returnere en tekststreng med verdien Anders For hver gang Anders returneres, regnes testen som vellykket Hvis andre verdier returneres (feil datatype, null, osv.), regnes testen som mislykket

41 Oppgave 5: Løsningsforslag Hva er forskjellen på enhetstest og integrasjonstest? Integrasjonstesting Sammensetning av flere enkeltstående enheter til komponenter Tester disse komponentene sammen Avdekker hvordan komponentene interagerer med hverandre

42 Oppgave 6(a) Hva er forskjellen på blackbox- og whitebox-testing?

43 Oppgave 6(a): Løsningsforslag Hva er forskjellen på blackbox- og whitebox-testing? Blackbox-testing Spesifikasjonsbasert testing Tester funksjonaliteten til en komponent i henhold til spesifikasjonen Hva skal komponenten gjøre? Gjør den det? Ikke fokus på underliggende intern struktur / logikk

44 Oppgave 6(a): Løsningsforslag Hva er forskjellen på blackbox- og whitebox-testing? Whitebox-testing Strukturbasert testing Tester den interne strukturen til et system Hvordan realiseres funksjonaliteten? Hvilken logikk ligger i grunn? Eksaminerer kildekoden Brukes ofte for å måle dekningsgrad av testene Hvor mye har vi testet?

45 Oppgave 6(a): Løsningsforslag Eksempel: Blackbox-testing Beslutningstabeller Årsak-virkning Viser forretningslogikk Ulike scenarioer gir ulike utfall Viser forventet resultat basert på input-verdier Ikke nødvendig å vite hvordan dette er implementert internt i systemet Vi er kun interesserte i spesifikasjonen Hva systemet skal gjøre

46 Oppgave 6(a): Løsningsforslag Eksempel: Blackbox-testing Ekvivalensinndeling Dele dataverdier inn i grupper som skal behandles likt Datasamlingene kalles ekvivalensklasser Alle verdier internt i klassen skal håndteres på samme måte av systemet Eksempel: Ruters beregning av priser for enkeltbilletter De aller minste (under 4 år) Barn (fra 4 til og med 15 år) Voksen (fra og meg 16 til og med 66 år) Honnør (fra og med 67 år) 0 NOK 17 NOK 33 NOK 17 NOK

47 Oppgave 6(a): Løsningsforslag Eksempel: Blackbox-testing Eksempel: Teste om Ruters system beregner korrekt billettpris? Vi kan teste alle aldre, én etter én Tester først om 0 år gir forventet pris Tester deretter om ett år gir forventet pris Tester deretter om to år gir forventet pris Osv. Problem? Dette er både tidkrevende og unødvendig Vi har ulike verdier (alder) som behandles på samme måte

48 Oppgave 6(a): Løsningsforslag Eksempel: Blackbox-testing Eksempel: Teste om Ruters system beregner korrekt billettpris? Siden noen intervaller (alder) gir samme utfall (pris), lar vi disse tilhøre samme klasse Vi lager ekvivalensklasser for dataverdiene Ekvivalensklasser Holder å teste én verdi fra hver klasse, fremfor alle verdier

49 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Hvordan og hvorfor måle instruks- og forgreningsdekning? Vi ønsker å teste så mye som mulig Må kunne vite hva som har blitt testet Programinstruksdekning Antall instrukser som testes i et program Forenklet: Én instruks = Én kodelinje Forgreningsdekning Antall forgreninger (mulige utfall) som testes i et program Oppstår ved IF, ELSE-IF, CASE, osv.

50 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Pseudokode for et enkelt program 1 READ A 2 READ B 3 C = A + 2 * B 4 IF C > 50 THEN 5 PRINT LARGE C 6 ENDIF

51 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Programinstruksdekning Test 1_1: A = 2, B = 3 Test 1_2: A = 0, B = 25 Test 1_3: A = 47, B = 1 Hvilke instrukser dekkes av testene?

52 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Programinstruksdekning Test 1_1: A = 2, B = 3 // C = 8 Test 1_2: A = 0, B = 25 Test 1_3: A = 47, B = 1 Hvilke instrukser dekkes av testene?

53 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Programinstruksdekning Test 1_1: A = 2, B = 3 Test 1_2: A = 0, B = 25 // C = 50 Test 1_3: A = 47, B = 1 Hvilke instrukser dekkes av testene?

54 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Programinstruksdekning Test 1_1: A = 2, B = 3 Test 1_2: A = 0, B = 25 Test 1_3: A = 47, B = 1 // C = 49 Hvilke instrukser dekkes av testene?

55 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Programinstruksdekning Vi dekker 5 av 6 instrukser Instruksdekning = 83 % Hvordan nå 100 % dekning? Trenger en annen test Test 1_4: A = 20, B = 25

56 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Programinstruksdekning Test 1_4: A = 20, B = 25 // C = 70 Instruksdekning = 100 % Trenger egentlig bare én test C > 50

57 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Forgreningsdekning Avgjørelser har minst ett enten/eller-utfall Disse utfallene skaper forgreninger i koden 1 READ A 2 READ B 3 IF A > B THEN C = 0 4 ENDIF Hvor mange tester trenger vi for å nå 100 % forgreningsdekning?

58 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Først: Instruksdekning Kun én test er nødvendig for 100 % instruksdekning A = 12, B = 10 // Alle instrukser blir eksekvert Forgreningsdekning Hver gren må eksekveres T/F, Y/N Testforutsetninger A må være mindre enn eller lik B

59 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Forgreningsdekning A må være mindre enn eller lik B A = 2, B = 4 // Alle grener er nå eksekvert Vi vet nå hvor mye som har blitt testet Vi har 100 % forgreningsdekning Vi har 100 % instruksdekning

60 Oppgave 6(b) Forklar fordeler og ulemper med hver av teknikkene

61 Oppgave 6(b): Løsningsforslag Forklar fordeler og ulemper med hver av teknikkene Fordeler: Blackbox-testing Krever ikke teknisk kompetanse Enkelte tester kan gjennomføres av ulike brukergrupper Planlegging av testinnsatsen kan starte tidlig Vi vet hva systemet skal gjøre Kan bruke uavhengige testere (ikke involvert i utviklingen) Resultater kan tolkes uten kjennskap til systemets interne strukturer Finner krav som ikke er implementert riktig / mangler

62 Oppgave 6(b): Løsningsforslag Forklar fordeler og ulemper med hver av teknikkene Ulemper: Blackbox-testing Usikkerhet rundt hvor mye / hvilke deler av systemet som er testet Vet ikke hva som forårsaker problemet Hvor i kildekoden ligger feilen? Hva trigget feilen? Vanskelig å utforme tester uten en tydelig kravspesifikasjon Tester kan vise seg å være redundante Utviklere har allerede kjørt tilsvarende tester

63 Oppgave 6(b): Løsningsforslag Forklar fordeler og ulemper med hver av teknikkene Fordeler: Whitebox-testing Kan utføres tidlig i systemutviklingsprosessen Trenger ikke vente på at grensesnittet skal lages Ser nærmere på underliggende logikk / struktur i koden Optimalisering av kode / Fjerne unødvendige kodelinjer Grundigere analyse av hva som forårsaker eventuelle problemer Kartlegger data / input som mest effektivt tester programmet Utviklere må begrunne kode / beslutninger rundt implementasjon

64 Oppgave 6(b): Løsningsforslag Forklar fordeler og ulemper med hver av teknikkene Ulemper: Whitebox-testing Krever teknisk kompetanse Programmerings- og testeferdigheter Bør være ekspert og allerede ha kjennskap til koden Krever tid og tilgang til kildekoden Utfordrende å gjennomføre hvis implementasjonen endres hyppig Finner ikke krav eller mangler som ikke er implementert

65 Oppgave 7 Foreslå testcases for use caset ta ut penger. Ta for deg enhetstesting og integrasjonstesting.

66 Oppgave 7: Løsningsforslag Foreslå testcases for use caset ta ut penger. Ta for deg enhetstesting og integrasjonstesting. Enhetstester Blir PIN-koden validert korrekt? Blir kortet godkjent korrekt? Blir kortet returnert korrekt? Integrasjonstester Henter man saldo fra rett konto? Trekkes korrekt beløp fra rett konto? Blir saldo oppdatert korrekt etter uttak?

67 Oppgave 8 Hvorfor er det viktig å utføre både funksjonell og ikkefunksjonell testing?

68 Oppgave 8: Løsningsforslag Hvorfor er det viktig å utføre både funksjonell og ikkefunksjonell testing? Funksjonell testing HVA systemet gjør Tester hvorvidt de funksjonelle kravene fra systemspesifikasjonen innfris Ikke-funksjonell testing HVORDAN systemet virker Tester ikke-funksjonelle krav Kvalitetsattributter (brukervennlighet, effektivitet) Samlet testinnsats øker produktkvaliteten

69 Oppgave 8: Løsningsforslag Hvorfor er det viktig å utføre både funksjonell og ikkefunksjonell testing? Validering Bygger vi det riktige produktet? Programvaren gjør det brukerne virkelig ønsker seg Fokus på hele systemet Verifisering Bygger vi produktet riktig? Stemmer det med kravspesifikasjonen? Fokus på komponenter / delsystemer

70 Oppgave 9 Hvorfor er det viktig å utføre vedlikeholdstesting?

71 Oppgave 9: Løsningsforslag Hvorfor er det viktig å utføre vedlikeholdstesting? Vedlikeholdstesting Testing etter at systemet er tatt i bruk Vanlig med endringer i et system Korrigeringer / Utvidelser / Øvrige forandringer Plattformer endres eller fjernes Avdekker om vedlikehold har introdusert nye feil / mangler Først: Kjør tester for endringene som ble utført Deretter: Kjør regresjonstest for systemet

72 Spørsmål? Ta kontakt Yulai Fjeld uio.no Husk å inkludere emnekoden! Andre gruppelærere Delta på gruppetimene

73 Takk til Foilene er basert på Tidligere presentasjoner laget av Emilie Hallgren og Kristin Brænden Eksisterende forelesningsnotater av Dag Sjøberg og Yngve Lindsjørn Sommerville, I. (2010). Software Engineering (9th Edition). Pearson.

74 Takk for meg Neste uke : Kontrakter