Vad är modultestning? Definition, exempel

Vad är modultestning?

Modultestning är en typ av mjukvarutestning som kontrollerar enskilda delprogram, subrutiner, klasser eller procedurer i ett program. Istället för att testa hela programmet på en gång rekommenderar modultestning att man testar programmets mindre byggstenar.

Modultestning är till stor del white box-orienterad. Syftet med modultestning är inte att visa att modulen fungerar korrekt, utan att visa att det finns ett fel i den. Den inversionen spelar roll: en körning som inte hittar någonting har bekräftat väldigt lite, medan en körning som avslöjar en defekt har gjort sitt jobb.

Modulnivåtestning möjliggör också introduktion av parallellitet i testprocessen, eftersom det skapar möjligheten att testa flera moduler samtidigt istället för att vänta på en komplett version.

Varför göra modultestning

Modultestning rekommenderas eftersom det förändrar ekonomin för feldetektering.

• Sannolikheten att identifiera fel eller buggar i mindre delar av ett program blir högre.
• Flera moduler kan testas samtidigt, och metoden stöder därför parallell testning.
• Testningens komplexitet kan hanteras enkelt, eftersom varje modul resonerar kring sig själv.
• En defekt som hittats inuti en modul är tracmöjlig för en liten mängd kod, så felsökningstiden minskar kraftigt.

Hur gör man modultestning?

Designa en testfall är det viktiga segmentet av modultestning. När en testare utformar testfall för ett modultest måste hen ta hänsyn till två saker.

• Specifikation för modulen
• Modulens källkod

Analysera modulens logik med hjälp av en eller flera av de vit ruta metoder, och komplettera sedan dessa testfall genom att tillämpa svart låda metoder till modulspecifikationen. Realistiska värden är lika viktiga som de valda vägarna, så förbered testdata vid sidan av fallen snarare än efteråt.

När testfallen är utformade är nästa steg att kombinera modulerna för testning. Metoden som används är antingen en steg eller ett icke-inkrementell metod.

• Icke-inkrementell metod — alla moduler testas oberoende av varandra. Först kombineras alla moduler och sedan testas hela programmet.
• Stegvis metod — varje modul testas först och läggs sedan gradvis till i den testade samlingen. Den utför ett stegvis omtest.
• Inom stegvis testning finns det två tillvägagångssätt, upp och ner och botten upp testning.
• För att köra modulen med vald data krävs en drivrutin för att leverera testdata, övervaka körningen och samla in resultaten.

Valet mellan de två metoderna är en avvägning mellan installationsansträngning och diagnosticerbarhet.

Drivrutiner och stubbar i modultestning

Drivrutinen som nämns ovan är ena halvan av ett par. Eftersom en modul som testas sällan sitter högst upp eller längst ner i anropskedjan, ersätter testare det som saknas på endera sidan av den med dummykod.

• Chaufför — ersätter den anropande modulen ovanför den som testas. Den tillhandahåller testdata, anropar modulen, övervakar exekveringen och samlar in resultaten. Bottom-up-testning är beroende av drivrutiner, eftersom de lägre modulerna är redo före de högre.
• Stump — ersätter en anropad modul under den som testas. Den accepterar anropet och returnerar ett fast, känt svar så att modulen som testas kan slutföra sin sökväg. Top-down-testning är beroende av stubbar, eftersom de högre modulerna är redo först.

Ett bearbetat fall konkretiserar parkopplingen. Om en betalningsberäkningsmodul är klar medan utcheckningsskärmen som anropar den inte är det, matar en förare modulen med en uppsättning ordersummor och registrerar vad som kommer tillbaka. Om skatteuppslagningstjänsten som modulen anropar också är oavslutad returnerar en stub en fast skattesats så att beräkningen fortfarande körs. Ingen av ställningarna levereras; båda kasseras när de riktiga modulerna anländer, vilket är anledningen till att missförstånd av testdubblar listas senare som en återkommande utmaning.

Exempeltips för modultestning

Här är några tips att tänka på innan du utför modultestning.

• RevVisa testfall innan du använder dem.
• Undvik förvirring kring källan till avvikelser.
• Använd automatiserade testverktyg.
• Undersök variabler som ska vara oförändrade.
• Byt moduler mellan testare för att undvika självtester.
• Återanvänd testfallen.

Det femte tipset väger tyngre än dess längd antyder. En utvecklare som bara testar den modul som just skrivits upprepar samma antaganden som skapade defekten, så att rotera moduler mellan personer är en av de billigaste kvalitetsvinsterna som finns.

Enhetstestning vs modultestning

De två termerna används synonymt i många grupper, men författarskapet och omfattningen skiljer sig åt.

Modultestning kontra komponenttestning kontra integrationstestning

Modultestning ligger också bredvid två angränsande nivåer som är lätta att förväxla med den. Tabellen separerar dem efter vad som testas och vem som normalt utför det.

I vardagsbruk komponenttestning och modultestning behandlas ofta som samma aktivitet, medan integrationstest börjar först när de enskilda modulerna har godkänts var för sig.

Utmaningar i modultestning

Det här är de utmaningar som team oftast möter när modultestning introduceras.

• Icke-inkrementell testning kräver mer arbete — att kombinera allt först innebär att ett enda fel kan skicka testare tillbaka genom hela programmet.
• Missförstånd test fördubblas — en stubb som returnerar ett orealistiskt värde producerar en grön körning som inte bevisar någonting.
• Felsökning av tester ofta — stöttningskod har sina egna defekter, och tid som läggs på att fixa en drivrutin är tid som inte läggs på att testa modulen.
• Måste förstå koden — den vita rutans orientering innebär att en testare som inte kan läsa modulen inte kan utforma meningsfulla fall för den.

Vanliga frågor