Repetisjon av testing. Vi undersøker om systemet virker slik det skal

Repetisjon av testing Vi undersøker om systemet virker slik det skal

Test av software For å teste om alle kravene er oppfylt må kravspesifikasjon og utviklingsdokumenter gjennomgås. Hvordan programmet fungerer testes på datamaskin Derfor er testing en viktig del av arbeidet med å utvikle programmet Testingen og testdokumentasjonen er en viktig del av dokumentasjonen som skal vise at programmet fyller kravene som er satt

Testing er Systematisk kjøring av programmet under kontrollerte betingelser for å Finne feil Dokumentere korrekt implementasjon Øke tiltroen til programmet Analysere program, dokumentasjon og andre beskrivelser

Terminologi noen ord og uttrykk Confidens Defect Debug Error Fail Failure Reliability Testing Validation Verification Debugging Terminologilisten Tiltro, tillit Feil eller Mangel Finne, analysere og rette, fjerne feil 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 Hensikten med testing er å Kjøre programmet for å påvise/finne feil Kjøre programmet for å vurdere kvaliteten Kjøre programmet for å vurdere tiltroen til det (confidens) Analysere program eller dokumentasjon for å finne svakheter (defects) Hensikten med debuging er å: Lokalisere og rette feil Lokalisere feilen - hvor finnes den? Analysere feilen - hva består feilen i? Rette og fjerne feilen Teste rettingen slik at ikke nye feil er introdusert

Debugging

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

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, validering og evaluering Teste Undersøke ved hjelp av tester om systemet fungerer slik det er beskrevet Validere Bekrefte hvordan systemet virkelig fungerer, om beskrivelsen er gyldig Evaluere Vurdere hvordan systemet passer til bruk i en organisasjonen i forhold til en beskrivelse Hensikten er å dokumentere at et datasystem fungerer slik det er forutsatt

To viktige spørsmål Bygger vi det riktige systemet - validering? Snakke med brukerne Lese kravspesifikasjonene og bestillinger Virksomhetsanalyse Bygger vi systemet riktig - verifisering? Inspisere kode Teste funksjoner Teste delsystemer Systemtest Akseptansetesten Kundens systemtest Evalueringen I hvor stor grad kan vi si at de to spørsmålene er oppfylte?

Forskjellige typer feil Kategori 1: Kritiske feil som MÅ rettes Lansering holdes igjen til feilen er rettet Kategori 2: Kritiske feil som bør rettes Betydelig reduksjon av kvaliteten Kategori 3: Ikke-kritiske feil kosmetiske feil Kategori 4: Ubetydelige feil Skrivefeil, feil fargenyanser,..

Systemets livsløp Strategsk behov Hva vil vi? Hvor går vi? Analyse og spesifikasjon Hvordan lager vi veien Utvikling Verktøyet for å komme dit Implementering Datakonvertering Forvaltning Drift og vedlikehold Systemavslutning Fase ut systemet og fjerne det

V-modellen Forutsetter at utvikling og testing er likeverdige aktiviteter Til hvert steg i utviklingen hører en test Kundespesifikasjon Kravspesifikasjon Funksjonell systemdesign Teknisk systemdesign Programmering

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

Komponent- Klasse- Modul- Enhets-test Laveste testnivå Tester at modulen (klassen) virker isolert Forsikre oss om at kode eksekverer uten kjørefeil Simulerer omgivelsene til komponenten Utføres av utviklere Skrives ofte som automatiske tester Hva testes? dataflyt grenseverdier feilhåndteringsmekanismer

Integrasjonstest Teste samspillet mellom enheter. Målet er å rette feil knyttet til funksjoner som enhetene bare kan utføre sammen og som dermed ikke kan avdekkes under enhetstesting. Tester at komponenten (klassen) virker sammen med andre komponenter Simulerer ofte andre sub-systemer Bruker konstruerte testdata Utføres ofte av utviklere Gjøres ofte manuelt, men kan med fordel automatiseres

Systemtest Forsikre oss om at systemet fungerer i henhold til kravspesifikasjon, de avtalte kravene Tester at systemet oppfører seg korrekt i samspill med omgivelsene Systemtest kjøres etter at hele systemet er satt sammen, og i et testmiljø som skal simulere et driftsmiljø.

Akseptansetest - Mottakstest Kunden har ansvaret for å gjennomføre testen Tester at systemet lar brukerne gjøre det de trenger Tester med reelle data Utføres gjerne i samarbeid mellom kunder og testere Avklarer om kunden aksepterer systemet

Andre testtyper Funksjonstester - Black Box testing Hvordan systemet fungerer Strukturtester - White Box testing Ikke-funksjonelle tester Testing av alt annet enn funksjonalitet Pålitelighet, robusthet, brukskvalitet, brukervennlighet, dokumentasjon, vedlikehold. Endringstester Gjennomføres når det gjennomføres endringer i softwaren

Black-box testing - funksjonstesting Kildekoden er ukjent Black-box testing betrakter programvaren som en svart boks og kjenner bare grensesnittet mot omverdenen. Brukes til integrasjonstester, systemtester og akseptansetesten Testene utledes fra spesifikasjonen Kan brukes på alle systemer og nivåer Gi systemet inndata, kontroller utdata Viktig å finne inndata som fører til feil eller bekrefter at funksjonen fungerer riktig Bruke kunnskaper om anvendelsesområdet Gjennomføre systematiske testdatautvalg

Utfordringer ved Black-box testing Parametere kan ha feil rekkefølge og type Feil kan oppstå på grunn av feil i testomgivelsene test bed altså utenfor modulen som testes for eksempel i en driver eller en stub

White-box testing - strukturtesting Kildekoden er kjent White-box testing forutsetter kjennskap til den indre struktur og virkemåte til programmet som testes. Brukes mest i enhetstestene av de ulike modulene. Enhetstesten for egenutviklede moduler bør være whitebox testing Enhetstester for hyllevare og gjenbrukmoduler bør være black-box tester. Dermed testes grensesnittet til modulen som er de ulike funksjonene som er tilgjengelige i grensesnittet til modulen. For enhetstesten er utvikleren testansvarlig og bør utføre testen.

White-box testing - strukturtesting Andre navn Glass-box, Clear-box Målet er å teste alle programsetninger Egnet for små programmoduler Analysere kode for å identifisere ekvivalensklasser

Ekvivalensklasser Systemets inndata deles i grupper (klasser) En ekvivalensklasse er en datamengde der alle elementene behandles likt ekvivalensklasser kan identifiseres fra spesifikasjonen Tommelfingerregel Velg data som ligger godt inne i ekvivalensklassen og på grensen Grenseverdier blir ofte behandlet feil av programmet.

Black- og white-box testing Komponent Inndata Utdata Black box: Gir input forventet output? Komponent Inndata Xxxxx xxxxx Utdata White box: Følger hvert trinn i komponenten. Midlertidige utskrifter.

Kvalitet av programvare Kvalitet i hvilken grad en samling av iboende egenskaper oppfyller krav Krav behov eller forventninger som er angitt, vanligvis underforstått eller obligatoriske Krav kan fremsettes av forskjellige personer

Kvalitet en subjektiv vurdering Kvalitet er å oppfylle krav Den som formulerer kravet vurderer om produktet oppfyller kravet Forskjellige personer med ulike krav vurderer derfor kvalitet ulikt Krav er det samme som behov og forventninger Derfor er Kvalitet er en subjektiv vurdering Kvalitet tidsavhengig

Kvalitet av et IT-system Systemets evne til å oppfylle krav, ønsker og forventninger Hvor godt systemet stemmer med med de opprinnelige skriftlige spesifikasjoner Forholdet mellom forventet og opplevd ytelse og funksjon av systemet Opplevd kvalitet Subjektiv vurdering av den enkelte bruker som kommer i kontakt med systemet

Kvalitetsegenskap Generelle kvalitetsattributter Korrekthet Utfører det som er spesifisert i kravene Pålitelighet Du kan stole på programmet Robusthet Tåler at det skjer uforutssette ting

Når har et program riktig kvalitet? Når det har høyest mulig kvalitet? Når det har få feil? Når det oppfyller våre ønsker best mulig? Når det er utviklet etter bestemte kvalitetskrav? Når det er utviklet i land med menneskerettigheter? Når virksomheten har etiske retningslinjer? Når det er utviklet etter anerkjente metoder? Når det er utviklet med anerkjente verktøy? Når det ikke gjør skade på brukere eller andre?

Innhold i en kravspesifikasjon Innledning Oppdragsgiver, prosjekt- og brukergrupper Overordnet systembeskrivelse Hensikten, grafer med dataflyt, konsekvenser Rammebetingelser Tilgjengelighet, datasikkerhet, kapasitet Funksjonelle egenskaper Spesifisere skjermbilder, rapporter, inndata. Logisk datamodell Sammenhengen mellom datasettene,

Evaluering av systemkvaliteten Vurdert ut fra kravspesifikasjonen Hva har brukerne bedt om? Hva er det brukerne ønsker eller forventer Vurdert ut fra hvordan systemet fungerer i bruk Hva er det brukerne faktisk trenger Vurdert ut fra systemets plass/rolle i organisasjonen

Objektive og subjektive kvalitetskrav Objektive krav Funksjonskrav Ytelseskrav Tekniske krav Subjektive Bruksmessige krav Estetiske krav Symbolske krav

Akseptansetest Akseptansetesten utføres for å avgjøre om et produkt oppfyller kundens behov, og stemmer overens med spesifikasjonen og annen dokumentasjon. Akseptansetesten er siste mulighet for en kunde å avvise et utilstrekkelig produkt, før det settes i drift. En godt gjennomført akseptansetest kan beskytte kunden mot tap som skyldes dårlige produkter

Plass i V-modellen Kundespesifikasjon Akseptansetesting Kravspesifikasjon Systemtesting Design Integrasjonstesting Modul implementasjonmodultesting + MIT

Planlegging av testen Akseptansetesten består av fem faser: 1. Bestemme hvor kritisk systemet er (Analyser krav til testen) 2. Bestemme hvilke kvaliteter som skal testes eller evalueres (Spesifiser detaljerte krav til testen) 3. Designe testen 4. Utfør testen 5. Rapporter resultatene De første tre fasene tilhører planleggingen og er først og fremst kundens ansvar. De siste to fasene krever sterk deltakelse av leverandøren.

Utarbeide testkrav Beskriv scenarier og dokumenter hver funksjon Beskrivelsene skal vise hvordan en bruker utfører funksjonene. Oppstår situasjoner som ikke passer med tidligere beskrivelser så lag nye scenarier. Sjekk alt som er spesifisert Se etter situasjoner ikke er spesifisert, men allikevel er viktige. Eksempler: registrering av motstridende opplysninger slutt på papir midt i en jobb som krever utlisting duplisert registrering av opplysninger som ikke skal dupliseres generelle betjeningsfeil oppnår ikke kontakt med database, server etc.

Hva skal testes alt eller prioritet? Risiko for feil og viktighet i praktisk bruk. Vektlegger at testen skal finne maksimalt antall feil. Prioriterer komplekse systemdeler Deler hvor en vet at det har vært usikkerhet, der det har vært strid, endringer, og der det har vært mye feil i tidligere tester. Slike systemdeler kan (men må ikke) gi trøbbel senere. Finne feilene som er viktigst i drift Teste funksjoner som brukes oftest i praksis. Sjeldne situasjoner og sjeldent brukte funksjoner testes kuttes ut. Det finnes statistiske metoder til å evaluere testen beregne forventet pålitelighet i drift.

Valg av testdata For hvert scenario finnes fram til variasjonsbredden i input- og outputdata og det velges forskjellige data som dekker denne variasjonen. Valg av testdata medfører ekvivalensklasseinndeling, grenseverdianalyse, årsaks-virkningsanalyse og bruk av parvise kombinasjoner Hvert scenario bør utføres flere ganger med ulike testdatasett.

Oppsummering Kunden bør forberede testscenarier samtidig med spesifikasjonen. Kundens testansvarlige skal arbeide med test på heltid (i spesifikasjons- og testfasen). Testen gjøres grundig, men skal ikke finne for mange feil. Testen inkluderer vurdering av brukerhåndbok og andre dokumenter. En må avtale tidlig hva som er feil og hva som er endringsønsker. Testen (eller deler av den) bør kjøres om igjen etter feilretting.

Metrikker og målinger Vi vil gjerne vite: Hvor stort er programmet? Hvor godt er programmet? Hvor lett er det å vedlikeholde? Hvor mange feil er det i programmet? Hva vil testingen koste? Hvor lang tid tar det å utvikle et lignende program?

Grunnlaget for å bruke metrikker Behov for på en objektiv måte kunne Beskrive funksjonalitet Sammenligne systemer Evaluere systemer Forutsi Programkompleksitet Utviklingstider Utviklingskostnader

Hva er en metrikk? En metrikk er en målbar egenskap både for et system eller en prosess målbar egenskap eller størrelse i en eller flere deler av et informasjonssystem beregnet eller komponert indikator basert på to eller flere målinger karakteristikk av et produkt eller prosess En metrikk bør være en objektiv størrelse som ikke påvirkes av personen som utfører målingene

Typer av metrikker Produktmetrikker Antall kodelinjer Størrelse på installert program Mengden av dokumentasjon Prosessmetrikker Utviklingstid, Planlagt og virkelig Ressursbruk, Planlagt og virkelig Produktivitet, Kodelinjer, funksjonspoeng Kvalitet, feil/kodelinjer Metode for utviklingen Kompetanse til utviklingsteamet

Metrikker for ikke-funksjonelle krav Egenskap Hastighet Størrelse Brukbarhet Brukskvalitet (Usability) Pålitelighet Robusthet Portabilitet Mål Utførte transaksjoner per sekund, Behandlede hits/s Bruker/hendelsesresponstid, Skjermoppfriskningstid kb, MB Treningstid, Antall hjelpesider Gjennomsnittlig betjeningstid per transaksjon MTBF Gjennomsnittstid mellom svikt Oppetid MTTR Gjenstarttid etter svikt Andel av hendelser som fører til svikt Andel av målavhengige setninger Antall mål

Hva er statisk testing? Analyser utført på skrevne dokumenter Hensikten er å finne avvik fra spesifikasjonene Resultatene kan brukes til å optimalisere utviklingsprosessen og gi innspill til den dynamiske testingen

Testtyper Strukturerte gruppegjennomganger Reviews Gjennomganger, inspeksjoner Statiske analyser Bruke compilere for å kontrollere syntaks og variabler Teste konvensjoner og standarder Utføre dataflytanalyse Utføre kontrollstrukturanalyse Definere metrikker

Hva er dynamisk testing? Kjøring av testobjektet på en datamaskin Hensikten er å finne avvik fra forventede verdier eller bekrefte verdier Uferdige deler av programmet erstattes av testomgivelser, driver og stub Enkle moduler testes som White-box Kompliserte moduler testes som Black-box Testdataene deles i ekvivalensklasser