IN3240 - Kap 3 Static Testing

Hva er Static Testing?

Enkel forklaring

Static Testing betyr at vi undersøker programmet uten å kjøre det.

Vi ser på for eksempel:

• kravspesifikasjoner

• design

• kildekode

• testplaner

for å finne feil.

Hva er målet?

Å finne feil før programmet kjøres.

Det gjør at mange feil kan oppdages tidligere og blir billigere å rette.

Eksempel

Du leser gjennom et Java-program og oppdager at en variabel aldri blir brukt.

Du har ikke kjørt programmet.

Likevel fant du en feil.

Det er Static Testing.

Hva er Dynamic Testing?

Dette er motsetningen til Static Testing.

Enkel forklaring

Dynamic Testing betyr at vi kjører programmet og ser hvordan det oppfører seg.

Eksempel

Du starter programmet.

Klikker på "Logg inn".

Programmet krasjer.

Dette er Dynamic Testing.

Forskjellen mellom static testing og dynamic testing

Static Testing	Dynamic Testing
Programmet kjøres ikke	Programmet kjøres
Leser dokumenter eller kode	Utfører tester på programmet
Finner feil tidlig	Finner feil når systemet kjører

Hva er forskjellen mellom Static Testing og Dynamic Testing?

Static Testing utføres uten å kjøre programmet. Vi undersøker dokumenter eller kode. Dynamic Testing utføres ved å kjøre programmet og kontrollere hvordan det oppfører seg.

Hvorfor er Static Testing viktig?

Fordeler:

• Finner feil tidlig.

• Er ofte billigere enn å finne feil senere.

• Kan forbedre kvaliteten på krav, design og kode.

• Kan redusere antall feil som oppdages under Dynamic Testing.

Hva er Static Testing? Gi et eksempel.

Static Testing er testing uten å kjøre programmet. Vi undersøker dokumenter eller kildekode for å finne feil. Et eksempel er å gjennomgå kildekoden eller en kravspesifikasjon for å oppdage problemer før programmet kjøres.

Hva er en Review?

Enkel forklaring

En Review er når én eller flere personer leser gjennom et dokument eller kode for å finne feil, uten å kjøre programmet.

Hva kan vi reviewe?

Vi kan reviewe mange typer dokumenter, for eksempel:

• Kravspesifikasjoner

• Design

• Kildekode

• Testplaner

• Testtilfeller

Poenget er å finne feil tidlig.

Eksempel

Et team har skrevet en kravspesifikasjon.

Før programmeringen starter, leser flere personer gjennom dokumentet.

De oppdager at ett krav er uklart.

De retter kravet.

ingen kode er skrevet ennå.

Dette er en Review.

Hvorfor bruker vi Reviews?

Reviews brukes fordi de kan:

• finne feil tidlig

• forbedre kvaliteten på dokumenter

• redusere kostnader

• skape en felles forståelse i teamet

review - prosessen

Forelesningen beskriver en review som en prosess med flere aktiviteter. Den viktigste tanken er:

1. Planlegging – bestem hva som skal reviewes og hvem som deltar.

2. Individuell gjennomgang – deltakerne leser materialet hver for seg og noterer feil.

3. Review-møte – deltakerne diskuterer funnene.

4. Rework – forfatteren retter feilene.

5. Oppfølging – kontroller at feilene er rettet.

Hva er de viktigste stegene i en Review?

Planlegging → Individuell gjennomgang → Review-møte → Rework → Oppfølging.

Roller i en Review (Author)

Personen som har skrevet dokumentet.

Roller i en Review (Reviewer)

Personen som leser dokumentet og prøver å finne feil.

Roller i en Review (Moderator)

Leder reviewen og sørger for at prosessen følger planen.

Roller i en Review (Scribe)

Skriver ned feil og kommentarer under review-møtet.

Hva er hensikten med Reviews?

Hensikten er å oppdage feil tidlig, forbedre kvaliteten på dokumenter og redusere kostnader ved feilretting.

Hva er forskjellen mellom Review og Dynamic Testing?

• Review utføres uten å kjøre programmet.

• Dynamic Testing utføres ved å kjøre programmet.