TDT4242 · NTNU

Studieguide for TDT4242 Avansert programvareutvikling

Komplett pensumoversikt for avansert programvareutvikling ved NTNU — med forklaringer, sentrale begreper, eksamenstips og vanlige fallgruver. Eksamensoptimalisert basert på tidligere eksamener.

Introduksjon

Denne studieguiden dekker pensum i TDT4242 Avansert programvareutvikling ved NTNU (også kjørt under tittelen Software Requirements and Testing / Advanced Software Engineering). Faget kobler sammen kravspesifikasjon og testing/kvalitetssikring til ett hele: hvordan man fanger gode krav, og hvordan man verifiserer at programvaren faktisk oppfyller dem.

Eksamen er en 4-timers skoleeksamen som blander noen få flervalgsspørsmål med større drøftings- og anvendelsesoppgaver knyttet til en case-organisasjon (en matprodusent med sporbarhetssystem, eller en offentlig IT-virksomhet). Du skal ikke skrive mye kode — i stedet skal du spesifisere krav, velge og begrunne testmetoder, inspisere kode for feil og drøfte kvalitet, sikkerhet og prosess.

Faste eksamensmønstre (basert på oppgavesettene 2015–2016):

Flervalg (ca. 10–20 spørsmål): definisjoner og begreper innen testteknikker (domæne-, sti-, gray-box, mutasjonstesting), test doubles, TDD, kravkvalitet, mis-use cases og INVEST. Feil svar gir minuspoeng — svar blankt når du er usikker.
Kravspesifikasjon (stor oppgave): spesifiser funksjonelle og ikke-funksjonelle krav fra en case-beskrivelse, begrunn metodevalg (user stories vs. use cases vs. GORE), lag use case-diagram og tekstlige use cases.
Testing (stor oppgave): beskriv V-modellen, velg testnivå/teknikk per aktivitet, lag konkrete testtilfeller (ofte scenariotesting), forklar TDD.
Inspeksjon (stor oppgave): finn feil i en kodebit ved hjelp av en inspeksjonssjekkliste, presenter funn i tabellform (linjenummer – feiltype – funn – forbedring).
Ikke-funksjonelle krav og sikkerhet: definer sikkerhetskrav, bruk mis-use cases, drøft pålitelighet og kvalitet (ISO 9126).
Prosess/strategi: bimodal IT, Lean Startup, smidig utvikling og når de passer for case-organisasjonen.

Hjelpemidler: Tidligere har eksamen vært både «alt trykt og håndskrevet materiale tillatt» og «kun utskrift av standardene ISO 9126, IEEE 829 og IEEE 1059». Sjekk semesterets emnebeskrivelse for gjeldende hjelpemiddelkode.

Råd: Sensor belønner begrunnede valg, ikke utenatlister. Når du velger en metode (testteknikk, kravmetode), forklar alltid hvorfor den passer akkurat denne casen.

Temaene i denne guiden er rangert etter eksamensvekt: kravspesifikasjon først (35–40 % av begge eksamenssettene), deretter testing (20–30 %), kvalitetssikring, inspeksjoner og sikkerhet, og til slutt prosessforbedring, pålitelighet, risikostyring og konfigurasjonsstyring, som i hovedsak dukker opp som deler av de store drøftingsoppgavene.

Testing

Eksamensrelevant

Test doubles, black/gray/white-box, domæne- og stitesting, scenariotesting og V-modellen. Det desidert viktigste temaet — kommer i både flervalg og stor oppgave hver gang.

Hva er testing — og hva er det ikke

Testing er aktiviteten der vi kjører programvaren med valgte inndata for å finne avvik mellom faktisk og forventet oppførsel. Et viktig poeng: testing kan vise tilstedeværelse av feil, men aldri bevise fravær av feil (Dijkstra). Målet er derfor ikke «null feil», men tilstrekkelig tillit til at systemet kan leveres.

White-, black- og gray-box

White-box (strukturell): testene utledes fra koden/strukturen. Eksempler: stitesting (path testing), code coverage, mutasjonstesting. Krever tilgang til kildekoden.
Black-box (funksjonell): testene utledes fra spesifikasjonen uten kjennskap til intern struktur. Eksempler: ekvivalensklasser, grenseverdianalyse, scenariotesting.
Gray-box: kombinasjon — noe intern kunnskap (f.eks. datastrukturer) brukes til å lage black-box-lignende tester. Domænetesting regnes som en gray-box-teknikk.

Domænetesting og stitesting

Domænetesting deler inndataromet inn i delomåder (domæner) avgrenset av predikater i koden, og velger testpunkter på og like ved grensene. Hovedutfordringen er å identifisere de riktige predikatene og presisjon på grensene. Åpne grenser (<, >) og lukkede grenser (≤, ≥, ==) må behandles ulikt.

For sammensatte betingelser med AND-predikater eksploderer antallet tester. For å oppnå full dekning av en betingelse med $n$ uavhengige binære predikater forbundet med AND/OR trengs i verste fall $2^n$ kombinasjoner.

Eksempel — grenseverdier i en temperaturvakt

Et kølelager skal varsle hvis temperaturen er over 4°C i mer enn 10 minutter. Predikatet er (temp > 4) AND (tid > 10) — begge grenser er åpne.

temp	tid	Forventet	Begrunnelse
4,0	15	Ingen alarm	På grensen, $>$ er falsk for temp
4,1	15	Alarm	Like over temp-grensen
5,0	10	Ingen alarm	På grensen, $>$ er falsk for tid
5,0	10,5	Alarm	Like over tid-grensen, begge sanne

Vi tester systematisk på og like over hver grense fordi de fleste grensefeil (forveksling av $<$ og $\le$ ) avsløres nettopp her.

Test doubles

For å teste en komponent isolert erstatter vi dens avhengigheter med test doubles. Det er hovedformålet: å kunne utvikle og teste komponenter uavhengig av andre.

Stub: returnerer forhåndsbestemte svar på kall.
Mock: stub som i tillegg verifiserer at den ble kalt riktig (antall, rekkefølge, argumenter).
Fake: en forenklet, men fungerende implementasjon (f.eks. in-memory database).
Dummy/Spy: objekter som fyller en plass eller registrerer kall.

Merk: en assertion er ikke en test double — det er en kontroll inne i selve testen.

Testnivåer og V-modellen

V-modellen kobler hver utviklingsaktivitet (venstre side) til en tilsvarende testaktivitet (høyre side):

Utviklingsaktivitet	Testaktivitet	Egnet teknikk
Kravspesifikasjon	Akseptansetest	Black-box
Systemdesign	Systemtest	Black-box
Detaljdesign	Integrasjonstest	White-/gray-box
Koding	Enhetstest	White-box

Modellen gjelder også for smidige prosjekter, som kan ses som en sekvens av små V-er — hver iterasjon har sin egen mini-V.

Regresjonstesting

I vedlikeholdsfasen kjøres produktet mot tidligere testtilfeller for å sikre at endringer ikke har ødelagt eksisterende funksjonalitet. Dette kalles regresjonstesting og er den klassiske grunnen til å automatisere testpakker.

Scenariotesting

For komplekse systemer med mange samvirkende komponenter er scenariotesting egnet: hvert testtilfelle følger en realistisk arbeidsflyt fra start til slutt og knytter produktet direkte til de beskrevne kravene.

Eksempel — fire scenarioer for et sporbarhetssystem

Vare mottas, pakkes ut, lagres ved –10°C og sendes videre uten produksjon (ren sporbarhet).
Vare mottas, lagres ved –10°C, sendes til produksjon og nedkjøles til –20°C (kølekjede holdes).
Vare mottas, lagres ved –10°C, sendes til produksjon og varmes til 100°C (varmebehandling — sjekk >70°C i >10 min).
Tre varer kombineres til ett nytt produkt (resept + sammenslått sporbarhetskjede).

Scenarioene dekker alle hovedtilstandene (mottak → lagring → produksjon → forsendelse) og knytter hver til konkrete krav.

Nøkkelformler

•Full betingelsesdekning av $n$ uavhengige AND/OR-predikater: opptil $2^n$ tester
•Black-box → fra spesifikasjon; White-box → fra kode; Gray-box → kombinasjon
•Domænetesting: velg testpunkter PÅ og LIKE VED predikatgrenser
•Test double-typer: Stub, Mock, Fake, Dummy, Spy (Assertion er IKKE en double)
•V-modell: enhet→white, integrasjon→white/gray, system→black, akseptanse→black
•Regresjonstesting = kjøre mot tidligere testtilfeller etter endring

Vanlige feil

⚠️Tror testing kan bevise at programmet er feilfritt — det kan kun påvise feil, aldri fravær
⚠️Regner ut feil antall tester for AND-predikater: fem AND-predikater krever $2^5 = 32$ , ikke 5 eller 16
⚠️Forveksler åpne ( $<,>$ ) og lukkede ( $\le,\ge,==$ ) grenser i domænetesting — grensepunktet selv hører til ulik side
⚠️Kaller en assertion for et test double — assertion er kontrollen inne i testen, ikke en erstatning for en avhengighet
⚠️Plasserer domænetesting som ren white-box — det regnes som gray-box
⚠️Lager testtilfeller uten forventet resultat — et komplett testtilfelle MÅ ha forhåndsbetingelse, inndata, handling og forventet utfall

Eksamenstips

💡På «skriv fire komplette testtilfeller»: velg én teknikk (ofte scenariotesting), begrunn valget, og skriv hvert tilfelle med forhåndsbetingelse + inndata + forventet resultat
💡Begrunn ALLTID testnivå/teknikk ut fra casen: kompleksitet → integrasjon/system, behov for tillit før levering → akseptanse- og pålitelighetstesting
💡Husk tilordningen i V-modellen utenat — den brukes både i flervalg og drøftingsoppgave
💡Ved flervalg om test doubles: hovedformålet er å teste komponenter ISOLERT — velg det alternativet
💡Pass på minuspoeng i flervalg (−0,5 ved feil) — svar blankt når du er reelt usikker

Laster...

Laster…