Grunnleggende testteori Etter Hans Schaefer
Industri- og softwareprodukt 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 teste 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
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
Terminologi noen ord og uttrykk Confidens Defect Error Fail Failure Reliability Testing Validation Verification Debugging Terminologilisten Tiltro, tillit Feil eller Mangel Feil, Avvik Åfeile Problem, Avvik Pålitelighet Hele testprosessen Validere Bekrefte mot forventet bruk riktig system Verifisere - Bekrefte at krav er oppfylt systemet er riktig Finne, analysere og rette, fjerne feil
Testing og debuging - uttrykk Hensikten med testing er å Kjøre programmet for å påvise/finne feil Kjøre programmet for å vurdere kvaliteten Kjøre programmet for å vurdere om det har tillit (confidens) Analysere program eller dokumentasjon for å finne svakheter (defects) Hensikten med debuging er å: Lokalisere og rette feil Lokalisere feilen? Hva består feilen i? Rette og fjerne feilen Teste rettingen slik at ikke nye feil er introdusert
Debugging
Den første bug 9. september 1945, kl. 3:45 p.m., fant forskere ved Harvard universitetet årsaken til at Mark II Aiken Relay kalkulatoren oppførte seg merkelig En møll ble funnet fanget mellom punkter på relé #70, panel F Maskinen ble debugget med en pinsett! Dokumentert i loggen som First actual case of bug being found. med møllen tapet inn ved siden av
Testing Systematisk kjøring av programmet under kontrollerte betingelser for å Dokumentere at systemet er korrekt implementert Øke tilliten til programmet Finne feil Analysere program, dokumentasjon og andre beskrivelser En fullstendig testing av systemet er umulig Testing kan derfor aldri dokumentere fravær av feil, bare at de ikke har opptrådt under testingen
Programkvalitet summen av alle kvalitetskriteriene Funksjonalitet Oppfylle kravene, alle funksjoner Sikkerhet Pålitelighet - stabilitet - Reliability Brukervennlighet - Usability Nytte - Efficiency Drift, Vedlikehold og Maskinplattform Det er nødvendig å prioriter mellom kriteriene
Den grunnleggende testprosessen Kronologisk beskriving 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 Rapportering Avslutning
Teststrategi Lag en testspesifikasjon Avklar hvilke testteknikker som skal brukes Finn testtilfeller Test logikk og lag konkrete tilfeller Ikke glem grenseverdiene!!
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
Testtilfeller Logisk testtilfelle Definer betingelser Definer forventet resultat 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
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
Testpsykologi Verken vi eller systemene er feilfrie If anything can go wrong it will Murphys lov Systemutvikling vurderes som positivt Testing - finne feil vurderes som negativt Den som utvikler ser ikke egne svakheter Da ville ikke svakheten vært der Vurderer alltid eget arbeid som riktig Utvikling skjer i utviklingsmiljø som er forskjellig fra test- og bruks- og driftsmiljø
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
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 innverdier 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 riktige 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 minst mulige
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 klæddær 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 Om 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 testes og nye feil finnes
6 Tester er kontekstavhengige Testen må tilpasses bruk og omgivelser for 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 fyller kravene som er satt eller er brukbart i en virksomhet Å involvere brukere tidlig i utviklingen og bruke prototyper for å vurdere løsninger er en sikker måte til å unngå vansker
Oppsummering Terminologi er viktig omforent forståelse Testing er viktig for å kvalitetssikre utviklingsprosessen Grunnleggende testprosessen begynner med planlegging og slutter med rapport Et testtilfelle består av input, forventet resultat og virkelig resultat Mennesker gjør feil Testingens 7 grunnregler er viktige retningslinjer
Testing i et uviklingsløp Review Kundespesifikasjon Prosjekttid Akseptansetesting Plan&Spesifiser Forbered Utfør Avslutt Review Kravspesifikasjon Plan&Spesifiser Systemtesting Forbered Utfør Avslutt Design Review Integrasjonstesting Plan&Spesifiser Forbered Utfør Avslutt Review Modul implementasjonmodultesting + MIT P&S Forbered Utfør Avslutt