Hva er modultesting? Definisjon, eksempler

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.

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 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.

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