Livsløpstesting av IT-systemer
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 å sørge for at et datasystem tilfredsstiller brukerens behov best mulig
Validering ISTQB Gjøre de riktige tingene 1. Bekreftelse ved hjelp av undersøkelse og samling av objektiv informasjon at kravene for en spesifikk forventet bruk har blitt oppfylt. [ISO 9000] 2. Evaluering av et system mot kravspesifikasjon eller brukerens eller kundens behov for å se om en har utviklet det rette system. Se også verifikasjon. 3. Prosessen med å vurdere programvaren for å sikre overensstemmelse med spesifiserte eller implisitte krav.
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?
Vi tester fordi Det vi lager ikke er det vi burde lage Det vi lager har feil Vi trenger ikke best mulig, men god nok kvalitet. Feil kan være forretningskritiske Bedrifter kan gå konkurs 1996 - FoxMeyer - Medisinfirma. Dårlig systemtilpasning Menneskeliv kan gå tapt 1985 1987 Therac-25 Strålebehandling Store kostnader 1990 Tress-90 blir ikke ferdig 1,2 milliarder 1994 Flyplassåpning Denver Colorado utsettes ett år 1996 Ariane 5 styrter 5 milliarder 2000 Mars Orbiter forsvinner. Blanding av fot og meter
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
Generell V-modell Kravspesifikasjon Akseptansetest Funksjonell systemdesign Systemtest Teknisk systemdesign Integrasjonstest Komponentspesifikasjon Komponenttest Programmering
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
Komponent- Klasse- Modul- Enhets-test Testobjekt Biten, funksjonen, Modulen som skal testes Testomgivelser Hjelpefunksjoner for å gjennomføre testen Driver Program som kaller komponenten - innverdier Stub Program som komponenten kaller opp - utverdier Hensikten med testen Forsikre seg om at objektet fungerer korrekt og fullstendig Kontrollere robusthet fravær av feilfunksjon Vurdere effektivitet på komponenten Vurdere hvordan komponenten vedlikeholdes Teststrategi Avklare hvilken testmetode som skal benyttes
Integrasjonstesting. Systematisk framgangsmåte for å sette sammen moduler og testing for å avdekke svakheter i grensesnittet mellom modulene. Forsikre oss om at bitene i et større system fungerer sammen Selv om enhetene fungerer hver for seg betyr det ikke at de fungerer sammen, fordi. Data kan gå tapt på tvers av moduler En modul kan ha en uventet effekt på en annen Sub-funksjoner spiller ikke sammen
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
Teststrategier - 1 Top-down testing Starter med øverste komponent Fordel trenger ikke drivere da komponentene selv er drivere til programmene under Ulemper komponenter som ikke er ferdige må erstattes med stubber Bottom-up testing Starter med laveste komponent Fordel - trenger ikke stubber da komponentene selv er stubber til programmene over Ulemper høyere komponenter som ikke er ferdige må erstattes med drivere
Teststrategier - 2 Ad-hoc testing Komponentene integreres etter hvert som de ferdigstilles Fordel tidsbesparende komponentene testes når de er ferdige Ulemper Manglende komponenter må erstattes med drivere og stubber Backbone testing Stammen i programmet bygges og Komponentene integreres etter hvert som de ferdigstilles Fordel komponentene testes uavhengig av rekkefølge Arbeidskrevende å planlegge og lage stammen
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ø.
Systemtest Å bekrefte at systemet oppfører seg korrekt i samspill med omgivelsene og fyller de overordnede kravene. Hvilke krav testes? funksjonelle ikke-funksjonelle: sikkerhetstesting stresstesting ytelsestesting recovery testing
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 Mer om denne i egen forelesning
Andre testtyper - egne forelesninger Funksjonstester Black Box testing Hvordan systemet fungerer Ikke-funksjonelle tester Testing av alt annet enn funksjonalitet Pålitelighet, robusthet, brukskvalitet, brukervennlighet, dokumentasjon, vedlikehold. Strukturtester - White box testing Endringstester Gjennomføres når det gjennomføres endringer i softwaren
Black-box test Tar utgangspunkt i kravene Både funksjonelle og ikke-funksjonelle Tester alle grensesnitt Tester grenseverdier for input og output Omgivelsene simuleres
White-box test Tester som baserer seg på kunnskap om hvordan enheten er kodet. Kjører all kode Forsøker å kjøre alle veier Kjører alle løkker null, en og maks antall ganger Teste alle utfall av betingelser Tester feiltilstander og initialtilstander Tester hva som skjer ved overbelastning og ressursknapphet.
Exploratory (ad hoc) testing (ET) Lage og forbedre tester mens du kjører dem Tillegg til skript basert testing Feil rapporteres som for vanlig testing Feilene beskrives slik at de kan repeteres Test rundt et tema Hva er den beste testen jeg kan utføre nå? ET utnytter testerens dyktighet og erfaring
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.