Wat is moduletesten? Definitie, voorbeelden

⚡ Slimme samenvatting

Moduletesten controleren individuele subprogramma's, subroutines, klassen en procedures in plaats van het geassembleerde programma. Hierdoor komen defecten aan het licht binnen een klein, goed begrepen codeblok, waar ze goedkoop te lokaliseren en te repareren zijn.

🎯 Doel: Het doel is om fouten in een module aan het licht te brengen, niet om aan te tonen dat de module werkt.
⚪ Oriëntatie: De techniek is grotendeels white box, aangevuld met black box-cases die zijn afgeleid van de specificaties.
⏩ Parallellisme: Meerdere modules kunnen tegelijkertijd worden getest, waardoor de totale testperiode wordt verkort.
🔗 Twee methoden: Modules worden stapsgewijs, incrementeel of niet-incrementeel in één keer gecombineerd.
🧰 Steiger: Drivers leveren testgegevens aan een module, terwijl stubs de modules vervangen die de driver aanroept.
🆚 Eigendom: Testers schrijven moduletests na het coderen, terwijl ontwikkelaars unit tests schrijven tijdens het coderen.
⚠️ Uitdagingen: Niet-incrementeel werk, verkeerd begrepen test-doubles en frequent debuggen vergen het grootste deel van de inspanning.

Meer informatie

Wat is moduletesten?

Module testen Moduletesten is een type softwaretest waarbij individuele subprogramma's, subroutines, klassen of procedures in een programma worden gecontroleerd. In plaats van het hele softwareprogramma in één keer te testen, adviseert moduletesten om de kleinere bouwstenen van het programma te testen.

Moduletesten zijn grotendeels white-box-georiënteerd. Het doel van moduletesten is niet om de correcte werking van de module aan te tonen, maar om de aanwezigheid van een fout aan te tonen. Die omkering is belangrijk: een test die niets vindt, bevestigt weinig, terwijl een test die een defect aan het licht brengt, zijn doel heeft bereikt.

Testen op module-niveau maakt het ook mogelijk om parallellisme in het testproces te introduceren, omdat het de mogelijkheid biedt om meerdere modules tegelijk te testen in plaats van te wachten op een complete build.

Waarom moduletesten doen?

Moduletesten worden aanbevolen omdat ze de economische aspecten van defectdetectie veranderen.

De kans om fouten of bugs te identificeren in kleinere delen van een programma wordt groter.
Meerdere modules kunnen gelijktijdig worden getest, waardoor parallel testen mogelijk is.
De complexiteit van het testen kan eenvoudig worden beheerd, aangezien elke module op zichzelf wordt geanalyseerd.
Er is een defect gevonden in een van de modules. tracHet is mogelijk om een kleine hoeveelheid code te gebruiken, waardoor de debugtijd aanzienlijk afneemt.

Hoe moduletesten uitvoeren?

Het ontwerpen van een testcase Dit is een belangrijk onderdeel van moduletesten. Bij het ontwerpen van testgevallen voor een moduletest moet een tester rekening houden met twee dingen.

Specificatie voor de module
De broncode van de module

Analyseer de logica van de module met behulp van een of meer van de volgende methoden: witte doos methoden, en vul deze testgevallen vervolgens aan door toepassing van zwarte doos methoden volgens de modulespecificatie. Realistische waarden zijn net zo belangrijk als de gekozen paden, dus bereid de volgende zaken voor. testgegevens gelijktijdig met de gevallen, in plaats van erna.

Nadat de testgevallen zijn ontworpen, is de volgende stap het combineren van de modules voor het testen. De gebruikte methode is ofwel een incrementele nodig heeft of niet-incrementeel methode.

Niet-incrementele methode — Alle modules worden onafhankelijk getest. Eerst worden alle modules gecombineerd en vervolgens wordt het hele programma getest.
Incrementele methode — Elke module wordt eerst getest en vervolgens geleidelijk toegevoegd aan de te testen verzameling. Er wordt een stapsgewijze hertest uitgevoerd.
Binnen incrementeel testen zijn er twee benaderingen, ondersteboven en van onder naar boven testen.
Om de module met de geselecteerde gegevens uit te voeren, is een driver nodig die de testgegevens aanlevert, de uitvoering bewaakt en de resultaten vastlegt.

De keuze tussen de twee methoden is een afweging tussen de benodigde insteltijd en de diagnosemogelijkheden.

Aspect	Incrementele methode	Niet-incrementele methode
Combinatie (combination)	Eén module tegelijk, toegevoegd aan een geteste verzameling.	Alle modules gecombineerd en vervolgens samen getest.
Steigers nodig	Meer chauffeurs en afkortingen, stapsgewijs geschreven.	Minder test-doubles, omdat er echte modules aanwezig zijn.
Foutisolatie	Sterk — een storing wijst naar de zojuist toegevoegde module.	Zwak — een storing kan overal ontstaan.
Het meest geschikt voor:	Grote constructies met veel onderling verbonden modules	Kleine programma's met weinig modules en een lage koppeling.

Drivers en stubs in moduletesten

De hierboven genoemde driver is de ene helft van een paar. Omdat een te testen module zelden aan het begin of einde van de aanroepketen staat, vervangen testers de ontbrekende delen aan beide kanten door dummycode.

bestuurder — vervangt de aanroepende module boven de te testen module. Het levert de testgegevens, roept de module aan, bewaakt de uitvoering en legt de resultaten vast. Bottom-up testen is afhankelijk van drivers, omdat de lagere modules eerder gereed zijn dan de hogere.
Stomp — vervangt een aangeroepen module onder de te testen module. Het accepteert de aanroep en retourneert een vast, bekend antwoord, zodat de te testen module zijn pad kan voltooien. Top-down testen is afhankelijk van stubs, omdat de modules op een hoger niveau als eerste gereed zijn.

Een uitgewerkt voorbeeld maakt de koppeling concreet. Als een module voor betalingsberekening klaar is, terwijl het afrekenscherm dat deze aanroept dat nog niet is, voert een driver een set ordertotalen in de module in en registreert de resultaten. Als de service voor belastingberekening die de module aanroept ook nog niet klaar is, retourneert een testcase een vast belastingtarief, zodat de berekening toch kan worden uitgevoerd. Geen van beide testonderdelen wordt daadwerkelijk geleverd; beide worden verwijderd zodra de echte modules arriveren. Daarom wordt het misverstand over test-doubles later genoemd als een terugkerende uitdaging.

Voorbeeldtips voor het testen van modules

Hier volgen een paar tips om rekening mee te houden voordat u moduletests uitvoert.

RevBekijk de testgevallen voordat je ze gebruikt.
Voorkom verwarring over de oorzaak van de verschillen.
Gebruik geautomatiseerde testtools.
Onderzoek de variabelen die ongewijzigd zouden moeten blijven.
Wissel modules tussen testers om zelftests te voorkomen.
Hergebruik de testgevallen.

De vijfde tip is belangrijker dan de lengte doet vermoeden. Een ontwikkelaar die alleen de zojuist geschreven module test, herhaalt dezelfde aannames die tot het defect hebben geleid. Daarom is het rouleren van modules tussen verschillende ontwikkelaars een van de goedkoopste manieren om de kwaliteit te verbeteren.

Unittesten versus moduletesten

De twee termen worden in veel teams door elkaar gebruikt, maar het auteurschap en de reikwijdte verschillen.

Moduletesten	Testen van een eenheid
Moduletests zijn een verzameling tests die door een tester zijn geschreven nadat een ontwikkelaar code heeft geschreven	Eenheidstests Tests zijn een verzameling tests die door een ontwikkelaar zijn geschreven tijdens het softwareontwikkelingsproces.
Moduletesten kunnen het combineren van de unit tests omvatten.	Eenheidstesten kunnen eenheden afzonderlijk testen.

Moduletesten versus componenttesten versus integratietesten

Moduletesten bevinden zich naast twee aangrenzende niveaus die er gemakkelijk mee verward kunnen worden. De tabel scheidt ze op basis van wat er getest wordt en wie het normaal gesproken uitvoert.

Aspect	Module testen	Component testen	Integratietesten
Wordt getest	Eén subprogramma, klasse of procedure	Eén op zichzelf staand component met zijn directe afhankelijkheden.	De interfaces tussen gecombineerde modules
Gebruikelijke eigenaar	Tester, nadat de code is geschreven	tester	Integratietester
steiger	Bestuurders en afscheuringen	Stubs voor externe afhankelijkheden	Steeds minder testdubbelwedstrijden
Hetfect blootgelegd	Logische fout in de module	Gedragsfout in het onderdeel	Interface- en gegevensoverdrachtsfout

In het dagelijks gebruik testen van componenten Moduletesten worden vaak als dezelfde activiteit beschouwd, terwijl integratie testen Het proces begint pas nadat de afzonderlijke modules elk op zich succesvol zijn afgerond.

Uitdagingen bij het testen van modules

Dit zijn de uitdagingen waar teams het vaakst tegenaan lopen wanneer moduletesten worden geïntroduceerd.

Niet-incrementeel testen vereist meer werk — Als je alles eerst combineert, kan één enkele fout ervoor zorgen dat testers het hele programma opnieuw moeten doorlopen.
Misverstandentest verdubbelt — een stub die een onrealistische waarde retourneert, produceert een groene run die niets bewijst.
Tests debuggen — De basiscode bevat eigen fouten, en de tijd die wordt besteed aan het repareren van een driver is tijd die niet wordt besteed aan het testen van de module.
Moet de code begrijpen — De whitebox-oriëntatie betekent dat een tester die de module niet kan lezen, geen zinvolle testgevallen ervoor kan ontwerpen.

Veelgestelde vragen

De xUnit-familie ondersteunt de meeste programmeertalen, met mocking-bibliotheken die de stubs leveren en een coverage-tool die laat zien welke paden zijn bereikt. De keuze hangt af van de programmeertaal van de module, niet van het testniveau.

Een model leest de broncode van de module, somt de vertakkingen op en stelt voor elke vertakking een scenario voor, inclusief grenswaarden die bij een handmatige verwerking vaak over het hoofd worden gezien. RevEen evaluatie blijft nodig, omdat gegenereerde gevallen aangeven wat de code doet in plaats van wat de specificatie vereist.

Ja, en dergelijke assistenten presteren het best in een scaffold-omgeving, omdat een driver of stub repetitieve code is met een bekende structuur. De geretourneerde waarden vereisen nog steeds een menselijke beoordeling, omdat een plausibel ogende stub juist het gezochte defect kan verbergen.

Voldoende dat elke vertakking en elke grens in de module minstens één keer is getest. Een percentage als streefwaarde is misleidend, omdat een hoge dekkingsgraad van de statements er nog steeds toe kan leiden dat complete beslissingsuitkomsten niet worden uitgeprobeerd.

Na het compileren van een module en voordat de interfaces ervan samen worden getest. Dit is het eerste testniveau dat wordt toegepast op de opgeleverde code, waardoor defecten die hier worden gevonden nooit de integratie- of systeemfase bereiken.

Volg de bestaande code. De top-down benadering is geschikt voor projecten waarbij de besturingslogica eerst wordt geschreven en lagere modules worden gesimuleerd; de bottom-up benadering is geschikt voor projecten waarbij hulpmodules eerst worden geïmplementeerd en drivers deze aanroepen.

De module compileert probleemloos, de specificatie is beschikbaar, de afhankelijkheden zijn aanwezig of gesimuleerd, en de testgegevens zijn gereed. Beginnen zonder de specificatie verandert de oefening in een beschrijving van de code.

Testen kan nooit bewijzen dat een module geen defecten heeft, alleen dat deze de geteste gevallen heeft doorstaan. Het ontwerpen van testruns die proberen de module te laten crashen, levert daarom meer informatie op dan testruns waarvan verwacht wordt dat ze slagen.