1 Grunnleggende testteori
Industri - og software produkt Industriprodukt: Fysisk produkt Testes under produksjon og til slutt om produktet oppfyller kravene Tilpasses, endres, redesignes, og justeres så produktet oppfyller kravene. Softwareprodukt: Immaterielt produkt Kan ikke testes direkte Testes under utvikling for å finne svakheter og feil Mye vanskeligere fordi en ikke vet om alle feil er funnet og dermed oppfyller kravene når produktet er ferdig utviklet 2
Hva er testing? Testing er å kjøre programmet eller deler av det for å vurdere om kravene til det som testes er tilfredstiltfeiltesting finne feil og rette Statistisk testing beregne systemets pålitelighet Stresstesting måle belastningen før systemet feiler Benchmarking sammenligne systemer Systemtesting teste hele systemet Akseptansetest kundens test av hele systemet Whitebox-testing Teste modulens indre oppbygging Blackbox-testing teste modulens funksjonalitet 3
Test-minibanken(1) Opprett konto med 100 000 kr. 1. Ta ut 1000 kr. 2. Ta ut 2000 kr. 3. Ta ut 3000 kr. 4. Ta ut 4000 kr. 5. Ta ut 5000 kr. For hver uttak skriv ut saldo og uttak for å kontrollere at programmet regner riktig 4
Test-minibanken(2) Opprett konto med 100 000 kr. 1. Ta ut 40 000 kr. 2. Ta ut 60 000 kr. 3. Sett inn 10 000 kr. 4. Ta ut 10 001 kr. 5. Ta ut 9999 kr. 6. Ta ut 0 kr. 7. Ta ut -1 kr For hver uttak skriv ut saldo og uttak for å kontrollere at programmet regner riktig God dekning 5
Hvorfor teste software? Testingen og testdokumentasjonen er en viktig del av dokumentasjonen for å vise at IT-systemet fyller kravene som er forutsatt For å vurdere om kravene er oppfylt må kravspesifikasjon og utviklingsdokumenter gjennomgåes nøye. Hvordan programmet fungerer kan bare vurderes ved testing på datamaskin Derfor er testing en viktig del av arbeidet med å utvikle programmet 6
Error-Fault-Failure Error : når en programmerer koder feil eller utelater kode årsaken til en fault Fault (defect eller bug): feil i kode kan lede til failure dersom koden der den befinner seg eksekveres Failure: uoverenstemmelse mellom aktuelt resultat og oppførsel og forventet resultat og oppførsel avvik fra forventet resultat forårsakes av faults 7
Hensikten med testing er å: Testing vs. debugging Testing er ikke debugging Kjøre programmet for å påvise/finne failures (indikerer tilstedeværelse av faults) Kjøre programmet for å vurdere kvaliteten Kjøre programmet for å vurdere om det har tillit (confidens) Analysere program eller dokumentasjon for å hindre defects Hensikten med debugging er å: Lokalisere og rette faults Lokalisere fault Rette og fjerne fault Teste rettingen slik at ikke nye faults er introdusert 8
Den første bug 9. september 1945 fant forskere ved Harvard universitetet årsaken til at Mark II Aiken Relay kalkulatoren oppførte seg så merkelig. En møll ble funnet fanget mellom punkter på relé #70, panel F. Maskinen ble debugget med en pinsett! Hendelsen ble logget som First actual case of bug being found. med møllen tapet inn I dokumentet. 9
Testing Systematisk kjøring av programmet under kontrollerte betingelser for å dokumentere at systemet er korrekt implementert øke tilliten til programmet finne failures I tillegg inkluderer testing statiske metoder Analysere program, dokumentasjon og andre beskrivelser 10
Testing Fullstendig testing av hele systemet er som oftest umulig Testing kan derfor aldri dokumentere fravær av faults, bare at de ikke har opptrådt under testingen 11
Mål for programkvalitet summen av alle kvalitetskriteriene Testing: bidrar til å forbedre softwarekvalitet Men er også et mål for softwarekvalitet Følgende faktorer hører til under softwarekvalitet: Funksjonalitet: oppfylle kravene Sikkerhet Pålitelighet - Reliability Brukervennlighet - Usability Effektivitet - Efficiency Drift, Vedlikehold og Maskinplattform 12 Det er nødvendig å prioritere mellom kriteriene
Den grunnleggende testprosessen 13 Kronologisk beskrivelse av alle testoppgavene som skal gjennomføres Hver testoppgave må splittes i mindre oppgaver og spesifiseres nøyaktig planlegging og kontroll analyse og design implementasjon og gjennomføring evaluering og rapportering avslutning Selv om det logisk sett ser ut som om disse aktivitetene bør inntreffe etter hverandre, kan aktivitetene overlappe eller inntreffe samtidig.
Teststrategi Mål: optimalisere fordelingen av tester til de delene av systemet som trenger det mest. Avklar hvilke testteknikker som skal benyttes Definer testintensitet for delsystemene. Avhenger av: hvilken testdekning som ønskes hvilke testeteknikker som benyttes Finn testtilfeller Test logikk og lag konkrete tilfeller Ikke glem grenseverdiene!! 14
Teststrategi 1. Prioriter mellom delsystemene : de viktigste delsystemene testes først og mest inngående 2. Prioriter mellom funksjonene: de viktigste funksjonene testes først og mest inngående 3. Bruk verdier som ligger i området som er mest benyttet 15
Logisk testtilfelle Definer betingelser Definer forventet resultat Testtilfeller Virkelig testtilfelle Velg en verdi Vurder hvilket logisk tilfelle verdien tilhører Utfør testen Vurder om forventet virkelig resultat stemmer med forventet logisk resultat i testtilfellet 16
Eksempel logisk og virkelig Testnummer Inputverdi Forventet verdi(%) 1 X <= 3 0 2 3 < X <= 5 50 3 5 < X <= 8 75 4 X > 8 100 1 2 0 2 4 50 3 7 75 4 12 100 17
Testingens 7 grunnregler 1. Tester påviser feil, ikke feilfrihet 2. Fullstendig testing er umulig 3. Testing skal starte så tidlig som mulig 4. Feilene hoper seg opp 5. Tester mister effekten 6. Tester er kontekstavhengige 7. Et feilfritt system trenger ikke være et nyttig system 18
1 Tester påviser feil, ikke feilfrihet Testing kan vise om programmet inneholder feil ikke om programmet er feilfritt Riktig utførte tester reduserer sannsynligheten for at det foreligger skjulte feil Selv om en ikke finner feil med testing betyr ikke det at programmet er feilfritt 19
2 Fullstendig testing er umulig En fullstendig test der alle inputs og kombinasjoner testes mot alle forutsetninger lar seg ikke gjennomføre En fullstendig test av et IT-system vil føre til alt for mange tester i forhold til gevinsten Utfordringen er å utføre et riktig utvalg tester med hensyn til prioritering og risiko 20
3 Testing skal starte så tidlig som mulig Testaktivitetene bør starte så tidlig som mulig i utviklingsfasen og fokusere på definerte mål. Dermed finnes feilene tidligst mulig og kostnadene ved å rette dem blir minst mulige 21
4 Feilene hoper seg opp Ofte skjer en opphopning av feil i systemet Feil er vanligvis ikke jevnt eller tilfeldig fordelt i systemet men kommer i klynger Om det finnes mange feil ett sted i systemet finnes det også trolig flere i nærheten Påstandene er ikke allmenngyldige 22
5 Tester mister effekten Dersom en test gjentas mange ganger mister den effekten og nye feil påvises ikke Tester må omarbeides og tilpasses for å finne nye feil Deler av systemet som verken er testet eller brukt kan dermed bli testet og nye feil kan finnes 23
6 Tester er kontekstavhengige Testen må tilpasses bruk og omgivelser for systemet (risikoene tilknyttet bruk av det enkelte systemet) To systemer skal ikke testes på samme måte Hvert system skal testes individuelt avhengig av bruk, brukere og omgivelser Sikkerhetskritiske systemer trenger andre tester enn for eksempel et butikksystem 24
7 Et feilfritt system trenger ikke være et nyttig system Å finne og rette feil betyr ikke at systemet oppfyller kravene som er satt eller er brukbart i en virksomhet Å involvere brukere tidlig i utviklingen og bruke prototyper for å vurdere løsninger er forebyggende tiltak for å unngå problemer 25
Oppsummering 26 Testing er viktig for å kvalitetssikre utviklingsprosessen Den grunnleggende testprosessen består av: 1. planlegging og kontroll 2. analyse og design 3. implementasjon og gjennomføring 4. evaluering og rapprtering 5. avslutning Et testtilfelle består av input, forventet resultat og virkelig resultat Mennesker gjør feil Testingens 7 grunnregler er viktige retningslinjer