Hvad er modultestning? Definition, eksempler

Af: Thomas Hamilton Thomas Hamilton
Hours Opdateret

⚡ Smart opsummering

Modultestning kontrollerer individuelle underprogrammer, subrutiner, klasser og procedurer i stedet for det samlede program, så fejl dukker op i en lille, velforstået kodeblok, hvor de forbliver billige at finde og reparere.

  • 🎯 Formål: Målet er at afsløre fejl i et modul, ikke at demonstrere, at modulet fungerer.
  • ⚪ Orientering: Teknikken er i vid udstrækning "white box", suppleret med "black box"-cases hentet fra specifikationen.
  • ⏩ parallelitet: Flere moduler kan testes på samme tid, hvilket forkorter det samlede testvindue.
  • 🔗 To metoder: Moduler kombineres enten trinvis, trinvis eller ikke-trinvis i én arbejdsgang.
  • 🧰 Stilladser: Drivere leverer testdata til et modul, mens stubber erstatter de moduler, det kalder.
  • 🆚 Ejendomsret: Testere skriver modultests efter kodning, mens udviklere skriver enhedstests undervejs.
  • ⚠️ Udfordringer: Ikke-inkrementelt arbejde, misforståede testdoblinger og hyppig fejlfinding optager det meste af indsatsen.
Læs mere

Modultest forklaret med metoder, drivere, stubber og sammenligninger

Hvad er modultestning?

Modul test er en type softwaretest, der kontrollerer individuelle underprogrammer, subrutiner, klasser eller procedurer i et program. I stedet for at teste hele softwareprogrammet på én gang anbefaler modultest at teste programmets mindre byggesten.

Modultestning er i vid udstrækning orienteret mod en "white box". Formålet med modultestning er ikke at demonstrere modulets korrekte funktion, men at demonstrere tilstedeværelsen af ​​en fejl i det. Denne inversion er vigtig: en kørsel, der ikke finder noget, har bekræftet meget lidt, hvorimod en kørsel, der afslører en defekt, har gjort sit job.

Testning på modulniveau muliggør også introduktion af parallelisme i testprocessen, fordi det skaber muligheden for at teste flere moduler samtidigt i stedet for at vente på en komplet build.

Hvorfor lave modultest

Modultestning anbefales, fordi det ændrer økonomien i fejldetektering.

  • Sandsynligheden for at identificere fejl eller bugs i mindre dele af et program bliver højere.
  • Flere moduler kan testes samtidigt, og tilgangen understøtter derfor parallel testning.
  • Kompleksiteten af ​​testning kan nemt håndteres, da hvert modul er ræsonneret for sig selv.
  • En fejl fundet i ét modul er tracmulig med en lille mængde kode, så fejlfindingstiden falder kraftigt.

Hvordan laver man modultest?

Designe en test sag er det vigtige segment af modultestning. Når en tester designer testcases til en modultest, skal vedkommende tage to ting i betragtning.

  • Specifikation for modulet
  • Modulets kildekode

Analyser modulets logik ved hjælp af en eller flere af hvid boks metoder, og derefter supplere disse testcases ved at anvende black box metoder til modulspecifikationen. Realistiske værdier er lige så vigtige som de valgte stier, så forbered testdata ved siden af ​​sagerne snarere end bagefter.

Når testcasene er designet, er næste trin at kombinere modulerne til testning. Den anvendte metode er enten en inkremental eller ikke-inkrementel fremgangsmåde.

  • Ikke-inkrementel metode — alle moduler testes uafhængigt. Først kombineres alle modulerne og derefter tester hele programmet.
  • Trinvis metode — hvert modul testes først og tilføjes derefter gradvist til den testede samling. Den udfører en trinvis gentest.
  • Inden for inkrementel testning er der to tilgange, top down og bunden op testning.
  • For at udføre modulet med de valgte data kræves der en driver til at levere testdata, overvåge udførelsen og registrere resultaterne.

Valget mellem de to metoder er et afvejningsmoment mellem opsætningsindsats og diagnosticerbarhed.

Aspect Trinvis metode Ikke-inkrementel metode
Combination (Kombination) Et modul ad gangen, tilføjet til en testet samling Alle moduler kombineret og derefter testet sammen
Stillads nødvendig Flere drivere og stubber, skrevet progressivt Færre testdoblinger, da der er rigtige moduler til stede
Fejlisolation Stærk — en fejl peger på det modul, der lige er tilføjet Svag — en fejl kan opstå hvor som helst
Bedst egnet til Store builds med mange interagerende moduler Små programmer med få moduler og lav kobling

RELATEREDE ARTIKLER

Drivere og stubber i modultestning

Driveren nævnt ovenfor er den ene halvdel af et par. Da et modul under test sjældent sidder øverst eller nederst i kaldkæden, erstatter testere det, der mangler på hver side af det, med dummykode.

  • Chauffør — erstatter det kaldende modul over det, der testes. Det leverer testdataene, kalder modulet, overvåger udførelsen og registrerer resultaterne. Bottom-up-testning afhænger af drivere, fordi de lavere moduler er klar før de højere.
  • Stub — erstatter et kaldt modul under det, der testes. Den accepterer kaldet og returnerer et fast, kendt svar, så modulet under test kan fuldføre sin sti. Top-down-testning afhænger af stubs, fordi de højere moduler er klar først.

En bearbejdet case gør parringen konkret. Hvis et betalingsberegningsmodul er færdigt, mens den kasseskærm, der kalder det, ikke er det, giver en chauffør modulet et sæt ordretotaler og registrerer, hvad der kommer tilbage. Hvis den skatteopslagstjeneste, som modulet kalder, også er ufærdig, returnerer en stub en fast skattesats, så beregningen stadig kører. Ingen af ​​stilladserne leveres; begge kasseres, når de rigtige moduler ankommer, hvilket er grunden til, at misforståelser af testfordoblinger senere opføres som en tilbagevendende udfordring.

Eksempeltips til modultestning

Her er et par tips, du bør overveje, inden du udfører modultestning.

  • RevSe testcases, før du bruger dem.
  • Undgå forvirring omkring kilden til uoverensstemmelser.
  • Brug automatiserede testværktøjer.
  • Undersøg variabler, der skal være uændrede.
  • Byt moduler mellem testere for at undgå selvtest.
  • Genbrug testcasesene.

Det femte tip har mere vægt, end dets længde antyder. En udvikler, der kun tester det modul, der lige er skrevet, gentager de samme antagelser, der skabte fejlen, så det at rotere moduler mellem personer er en af ​​de billigste kvalitetsgevinster, der er tilgængelige.

Enhedstest vs modultest

De to udtryk bruges i flæng i mange teams, men forfatterskabet og omfanget er forskellige.

Modul test Enhedstest
Modultests er en samling af tests skrevet af en tester, efter at noget kode er blevet skrevet af en udvikler Enhedstest er en samling af tests skrevet af en udvikler under softwareudviklingsprocessen
Modultestning kan involvere en kombination af enhedstestene Enhedstestning kan teste enheder isoleret

Modultest vs. komponenttest vs. integrationstest

Modultestning ligger også ved siden af ​​to tilstødende niveauer, der er lette at forveksle med det. Tabellen adskiller dem efter, hvad der testes, og hvem der normalt udfører det.

Aspect Modul test Komponentprøvning Integrationstest
Under test Et underprogram, en klasse eller en procedure En selvstændig komponent med dens umiddelbare afhængigheder Grænsefladerne mellem kombinerede moduler
Sædvanlig ejer Tester, efter koden er skrevet tester Integrationstester
Stilladser Chauffører og stubber Stubbe til eksterne afhængigheder Gradvist færre testdobler
Defekt eksponeret Logisk fejl inde i modulet Adfærdsfejl i komponenten Grænseflade- og dataoverførselsfejl

I daglig brug komponenttest og modultestning behandles ofte som den samme aktivitet, mens integrationstest begynder først, når de enkelte moduler hver især er bestået.

Udfordringer i modultestning

Det er disse udfordringer, som teams oftest møder, når modultestning introduceres.

  • Ikke-trinvis test kræver mere arbejde — at kombinere alt først betyder, at en enkelt fejl kan sende testere tilbage gennem hele programmet.
  • Misforståelse test fordobles — en stub, der returnerer en urealistisk værdi, producerer en grøn kørsel, der ikke beviser noget.
  • Ofte fejlfinding af tests — scaffolding-kode bærer sine egne fejl, og tid brugt på at reparere en driver er tid, der ikke bruges på at teste modulet.
  • Skal forstå koden — den hvide boks-orientering betyder, at en tester, der ikke kan læse modulet, ikke kan designe meningsfulde cases for det.

Ofte Stillede Spørgsmål

xUnit-familien dækker de fleste sprog, med mocking-biblioteker, der leverer stubs, og et dækningsværktøj, der viser, hvilke stier der blev nået. Valget følger modulets sprog, ikke testniveauet.

En model læser modulkilden, opregner grenene og foreslår en case for hver, inklusive randværdier, som en manuel gennemgang ofte overser. Revview er fortsat nødvendigt, fordi genererede tilfælde hævder, hvad koden gør, snarere end hvad specifikationen kræver.

Ja, og det er i scaffolding, at sådanne assistenter klarer sig bedst, da en driver eller stub er repetitiv kode med en kendt form. De returnerede værdier kræver stadig en menneskelig beslutning, fordi en plausibel stub kan skjule selve den fejl, der søges efter.

Nok til at hver gren og hver grænse i modulet er blevet anvendt mindst én gang. Et procentmål alene er misvisende, fordi en høj dækning af udsagn stadig kan efterlade hele beslutningsresultater uafprøvede.

Efter et modul kompileres og før dets grænseflader testes sammen. Det er det første testniveau, der anvendes på leveret kode, hvilket er grunden til, at fejl, der opdages her, aldrig når integrations- eller systemstadierne.

Følg den eksisterende kode. Top-down passer til projekter, hvor kontrollogikken skrives først, og de lavere moduler stubbes; bottom-up passer til projekter, hvor forsyningsmoduler lander først, og drivere kalder dem.

Modulet kompilerer uden problemer, dets specifikation er tilgængelig, dets afhængigheder er enten til stede eller stubbet, og testdataene er klar. Hvis man starter uden specifikationen, bliver øvelsen til en beskrivelse af koden.

Testning kan aldrig bevise, at et modul ikke har nogen defekter, kun at det har overlevet de afprøvede tilfælde. Design af kørsler, der forsøger at ødelægge modulet, returnerer derfor mere information end design af kørsler, der forventes at bestå.

Opsummer dette indlæg med: