Grunnleggende testteori

Error-Fault-Failure Error : Fault (defect eller bug): Failure: når en programmerer koder feil eller utelater kode (evt. miljøpåvirkning) årsaken til en fault Fault (defect eller bug): feil i kode kan lede til failure dersom koden der den befinner seg eksekveres Failure: uoverensstemmelse mellom aktuell oppførsel og forventet oppførsel vi må vite hva forventet oppførsel er (definert i spesifikasjon /krav) forårsakes av faults

Testing er ikke debugging Testing vs. debugging Testing er ikke debugging Hensikten med testing er å: Systematisk kjøring av programmet for å påvise/finne failures (indikerer tilstedeværelse av faults) Kjøre programmet for å vurdere kvaliteten Kjøre programmet for å vurdere om det er til å stole på(confidens) Analysere program kode eller dokumentasjon for å hindre faults Spare penger Hensikten med debugging er å: Lokalisere og rette faults Lokalisere fault Rette og fjerne fault Teste rettingen slik at ikke nye faults er introdusert

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.

Testing I Systematisk eksekvering av programmet under kontrollerte betingelser for å demonstrere korrekt implementasjon av kravene øke tilliten til programmet finne failures  Dynamisk testing I tillegg inkluderer testing statiske metoder Statisk analyse av software ved bruk av verktøy. Manuell sjekking av programkode, dokumentasjon og andre beskrivelser  Statisk testing

Testing II 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. Hvor mye et system skal testes avhenger av systemets risiko. I tillegg spiller tid og ressurser inn.

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 Drift, Vedlikehold og Maskinplattform Det er ofte en konflikt mellom disse faktorene og det er nødvendig å prioritere mellom dem.

Den grunnleggende testprosessen 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.

1. Testplanlegging og kontroll Mål for testingen må defineres. Bruk av ressurser må planlegges (ansatte, utstyr, tid). Alt må dokumenteres i en testplan. Avvik må rapporteres. Hovedmålet er å sette opp en teststrategi.

Teststrategi Optimaliser fordelingen av tester til de delene av systemet som trenger det mest. Avklar hvilke testteknikker som skal benyttes Definer testintensitet (avslutningskriterier) for delsystemene. Avhenger av: hvilken testdekning som ønskes hvilke testeteknikker som benyttes

2. Testanalyse og design Vurder spesifikasjonen for å finne ut hva som bør testes. Lag logiske testtilfeller fra: Spesifikasjon til testobjektet(black-box) Kildekoden (white-box) Logisk testtilfelle Definer betingelser Definer forventet resultat Lag testtilfeller for både forventet og ikke-forventet input. Design test-bed /testeomgivelser.

3. Testimplementasjon og gjennomføring Transformer logiske testtilfeller til konkrete testtilfeller. Konkret testtilfelle: Velg en verdi Vurder hvilket logisk tilfelle verdien tilhører Utfør testen Vurder om virkelig resultat stemmer med forventet logisk resultat i testtilfellet Logg og mål testdekning.

Eksempel – logisk og virkelig Testnummer Inputverdi Forventet verdi(%) 1 X <= 3 2 3 < X <= 5 50 3 5 < X <= 8 75 4 X > 8 100 7 12

4. Evaluering og rapportering Testobjektet vurderes mot de kriteriene som ble satt i planleggingen. Kriterier for å avslutte testingen: Testdekning Feildeteksjonsrate Tid og kostnader Skriv testoppsummeringsrapport

5. Avslutning Erfaringer underveis bør analyseres og gjøres tilgjengelig for videre prosjekter Spesielt avvik mellom planen og testevirkeligheten, samt de antatte årsakene. Testetilfeller, testelogger, testinfrastruktur, verktøy etc. bør gis til de som er ansvarlig for vedlikehold.

Testingens 7 grunnregler 1. Tester påviser feil, ikke feilfrihet 2. Fullstendig testing er umulig 3. Testing skal starte så tidlig som mulig 4. Feil hoper seg opp 5. Tester mister effekten 6. Tester er kontekstavhengige 7. Et feilfritt system trenger ikke være et nyttig system

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

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

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

4 – Feil 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

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

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

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

Oppsummering Testing er viktig for å kvalitetssikre utviklingsprosessen Den grunnleggende testprosessen består av: planlegging og kontroll analyse og design implementasjon og gjennomføring evaluering og rapprtering avslutning Et testtilfelle består av input, forventet resultat og virkelig resultat Mennesker gjør feil Testingens 7 grunnregler er viktige retningslinjer