Hva er modultesting? Definisjon, eksempler

⚡ Smart oppsummering

Modultesting sjekker individuelle delprogrammer, subrutiner, klasser og prosedyrer i stedet for det samlede programmet, slik at feil dukker opp i en liten, godt forstått kodeblokk hvor de fortsatt er billige å finne og reparere.

🎯 Målet: Målet er å avdekke feil i en modul, ikke å demonstrere at modulen fungerer.
⚪ Orientering: Teknikken er i stor grad hvit boks, supplert med svarte boks-tilfeller hentet fra spesifikasjonen.
⏩ parallellitet: Flere moduler kan testes samtidig, noe som forkorter det totale testvinduet.
🔗 To metoder: Moduler kombineres enten trinnvis, trinnvis eller ikke-trinnvis i én omgang.
🧰 Stillas: Drivere leverer testdata til en modul, mens stubber erstatter modulene den kaller.
🆚 Eie: Testere skriver modultester etter koding, mens utviklere skriver enhetstester underveis.
⚠️ utfordringer: Ikke-inkrementelt arbeid, misforståtte testdublinger og hyppig feilsøking tar opp mesteparten av innsatsen.

Les mer

Hva er modultesting?

Modultesting er en type programvaretesting som sjekker individuelle delprogrammer, subrutiner, klasser eller prosedyrer i et program. I stedet for å teste hele programvaren samtidig, anbefaler modultesting å teste programmets mindre byggesteiner.

Modultesting er i stor grad hvitboksorientert. Målet med modultesting er ikke å demonstrere at modulen fungerer som den skal, men å demonstrere tilstedeværelsen av en feil i den. Denne inversjonen er viktig: en kjøring som ikke finner noe har bekreftet svært lite, mens en kjøring som avslører en feil har gjort jobben sin.

Modulnivåtesting tillater også at parallellisme introduseres i testprosessen, fordi det skaper muligheten til å teste flere moduler samtidig i stedet for å vente på en komplett bygging.

Hvorfor gjøre modultesting

Modultesting anbefales fordi det endrer økonomien ved feildeteksjon.

Sannsynligheten for å identifisere feil eller bugs i mindre deler av et program blir høyere.
Flere moduler kan testes samtidig, og tilnærmingen støtter derfor parallell testing.
Kompleksiteten i testingen kan håndteres enkelt, siden hver modul resonneres for seg selv.
En feil funnet inne i én modul er tractilgjengelig for en liten mengde kode, slik at feilsøkingstiden reduseres kraftig.

Hvordan utføre modultesting?

Designe en testforsøk er det viktige segmentet av modultesting. Når en tester utformer testtilfeller for en modultest, må vedkommende ta hensyn til to ting.

Spesifikasjon for modulen
Modulens kildekode

Analyser modulens logikk ved å bruke ett eller flere av hvit boks metoder, og deretter supplere disse testtilfellene ved å bruke svart boks metoder til modulspesifikasjonen. Realistiske verdier er like viktige som de valgte stiene, så forbered testdata ved siden av sakene heller enn etterpå.

Når testtilfellene er utformet, er neste trinn å kombinere modulene for testing. Metoden som brukes er enten en inkrementell eller ikke-inkrementell metoden.

Ikke-inkrementell metode — alle moduler testes uavhengig. Først kombineres alle modulene og deretter tester hele programmet.
Inkrementell metode — hver modul testes først og legges deretter gradvis til den testede samlingen. Den utfører en trinnvis ny testing.
Innenfor trinnvis testing finnes det to tilnærminger, topp ned og nede opp testing.
For å kjøre modulen med de valgte dataene, kreves det en driver for å levere testdataene, overvåke utførelsen og registrere resultatene.

Valget mellom de to metodene er en avveining mellom oppsettinnsats og diagnostiserbarhet.

Aspekt	Inkrementell metode	Ikke-inkrementell metode
Kombinasjon	Én modul om gangen, lagt til i en testet samling	Alle moduler kombinert, deretter testet sammen
Stillas nødvendig	Flere drivere og stubber, skrevet progressivt	Færre testdobler, siden ekte moduler er til stede
Feilsøking	Sterk — en feil peker på modulen som nettopp ble lagt til	Svak – en feil kan oppstå hvor som helst
Passer best til	Store bygg med mange samvirkende moduler	Små programmer med få moduler og lav kobling

Drivere og stubber i modultesting

Driveren nevnt ovenfor er den ene halvdelen av et par. Fordi en modul under test sjelden sitter øverst eller nederst i anropskjeden, erstatter testere det som mangler på hver side av den med dummykode.

Driver — erstatter den kallende modulen over den som testes. Den leverer testdataene, kaller modulen, overvåker utførelsen og registrerer resultatene. Bottom-up-testing er avhengig av drivere, fordi de lavere modulene er klare før de høyere.
stub — erstatter en kalt modul under den som testes. Den aksepterer kallet og returnerer et fast, kjent svar slik at modulen som testes kan fullføre banen sin. Top-down-testing er avhengig av stubber, fordi de høyere modulene er klare først.

Et bearbeidet tilfelle gjør sammenkoblingen konkret. Hvis en betalingsberegningsmodul er ferdig mens kasseskjermen som kaller den ikke er det, mater en sjåfør modulen et sett med ordretotaler og registrerer hva som kommer tilbake. Hvis skatteoppslagstjenesten som modulen kaller også er uferdig, returnerer en stub en fast skattesats, slik at beregningen fortsatt kjører. Ingen av stillasdelene leveres; begge forkastes når de virkelige modulene ankommer, og det er derfor misforståelser av testdobler blir oppført senere som en tilbakevendende utfordring.

Eksempeltips for modultesting

Her er noen tips du bør vurdere før du utfører modulesting.

RevSe testtilfeller før du bruker dem.
Unngå forvirring rundt kilden til avvikene.
Bruk automatiserte testverktøy.
Undersøk variabler som skal være uendret.
Bytt moduler mellom testere for å unngå selvtester.
Bruk testtilfellene på nytt.

Det femte tipset har mer vekt enn lengden antyder. En utvikler som bare tester modulen som nettopp er skrevet, gjentar de samme antagelsene som forårsaket feilen, så det å rotere moduler mellom folk er en av de billigste kvalitetsgevinstene som er tilgjengelige.

Enhetstesting vs modultesting

De to begrepene brukes om hverandre i mange team, men forfatterskapet og omfanget er forskjellige.

Modultesting	Enhetstesting
Modultester er en samling tester skrevet av en tester etter at noe kode er skrevet av en utvikler	Enhetstester er en samling tester skrevet av en utvikler under programvareutviklingsprosessen
Modultesting kan innebære å kombinere enhetstestene	Enhetstesting kan teste enheter isolert

Modultesting vs. komponenttesting vs. integrasjonstesting

Modultesting ligger også ved siden av to tilstøtende nivåer som er lette å forveksle med. Tabellen skiller dem etter hva som testes og hvem som vanligvis utfører det.

Aspekt	Modultesting	Komponenttesting	Integrasjonstesting
Under testing	Ett delprogram, en klasse eller en prosedyre	En selvstendig komponent med sine umiddelbare avhengigheter	Grensesnittene mellom kombinerte moduler
Vanlig eier	Tester, etter at koden er skrevet	tester	Integrasjonstester
stillas	Drivere og stubber	Stubber for eksterne avhengigheter	Gradvis færre testdobler
Feil eksponert	Logikkfeil inne i modulen	Oppførselsfeil i komponenten	Grensesnitt- og dataoverføringsfeil

I daglig bruk komponenttesting og modultesting blir ofte behandlet som den samme aktiviteten, mens integrasjonstesting starter først når de enkelte modulene er bestått hver for seg.

Utfordringer i modultesting

Dette er utfordringene team møter oftest når modultesting introduseres.

Ikke-inkrementell testing krever mer arbeid – å kombinere alt først betyr at én enkelt feil kan sende testere tilbake gjennom hele programmet.
Misforståelse test dobles — en stubb som returnerer en urealistisk verdi produserer en grønn løp som ikke beviser noe.
Feilsøking av tester ofte — stillaskode har sine egne feil, og tid brukt på å fikse en driver er tid som ikke brukes på å teste modulen.
Trenger å forstå koden — den hvite boksorienteringen betyr at en tester som ikke kan lese modulen, ikke kan designe meningsfulle tilfeller for den.

Spørsmål og svar

xUnit-familien dekker de fleste språk, med mocking-biblioteker som leverer stubber og et dekningsverktøy som viser hvilke stier som ble nådd. Valget følger modulens språk, ikke testnivået.

En modell leser modulkilden, lister opp grenene og foreslår et tilfelle for hver, inkludert grenseverdier som en manuell gjennomgang ofte overser. Revview er fortsatt nødvendig, fordi genererte tilfeller hevder hva koden gjør snarere enn hva spesifikasjonen krever.

Ja, og det er ved hjelp av stillasering at slike assistenter fungerer best, siden en driver eller stub er repeterende kode med en kjent form. De returnerte verdiene trenger fortsatt en menneskelig avgjørelse, fordi en plausibel stub kan skjule selve feilen som jaktes på.

Nok til at hver gren og hver grense i modulen har blitt utøvd minst én gang. Et prosentmål alene er misvisende, fordi høy dekning av utsagn fortsatt kan føre til at hele beslutningsutfall blir uutprøvd.

Etter at en modul kompileres og før grensesnittene testes sammen. Dette er det første testnivået som brukes på levert kode, og det er derfor feil som oppdages her aldri når integrasjons- eller systemstadiene.

Følg koden som finnes. Top-down passer til prosjekter der kontrolllogikken skrives først og nedre moduler stubbes; bottom-up passer til prosjekter der verktøymoduler lander først og drivere kaller dem.

Modulen kompilerer uten problemer, spesifikasjonen er tilgjengelig, avhengighetene er enten tilstede eller stubbet, og testdataene er klare. Å starte uten spesifikasjonen gjør øvelsen til en beskrivelse av koden.

Testing kan aldri bevise at en modul ikke har noen defekter, bare at den overlevde de tilfellene som ble prøvd. Å designe kjøringer som forsøker å ødelegge modulen returnerer derfor mer informasjon enn å designe kjøringer som forventes å bestå.