Mi az a modultesztelés? Meghatározás, példák
Thomas Hamilton
⚡ Okos összefoglaló
A modultesztelés az egyes alprogramokat, alprogramokat, osztályokat és eljárásokat ellenőrzi az összeállított program helyett, így a hibák egy kis, jól érthető kódblokkban jelennek meg, ahol olcsón megtalálhatók és javíthatók.
Mi az a modultesztelés?
Modul tesztelés egy olyan szoftvertesztelési típus, amely egy programban lévő egyes alprogramokat, alprogramokat, osztályokat vagy eljárásokat ellenőrzi. A teljes szoftverprogram egyszerre történő tesztelése helyett a modultesztelés a program kisebb építőelemeinek tesztelését javasolja.
A modultesztelés nagyrészt fehér doboz alapú. A modultesztelés célja nem a modul megfelelő működésének bemutatása, hanem egy benne lévő hiba meglétének kimutatása. Ez az inverzió számít: egy olyan futtatás, amely semmit sem talál, nagyon keveset igazolt, míg egy olyan futtatás, amely hibát tár fel, elvégezte a munkáját.
A modul szintű tesztelés lehetővé teszi a párhuzamosság bevezetését a tesztelési folyamatba, mivel lehetőséget teremt több modul egyidejű tesztelésére a teljes build megvárása helyett.
Miért érdemes modultesztelni
A modulok tesztelése ajánlott, mivel megváltoztatja a hibakeresés gazdaságosságát.
- Annak az esélye, hogy a program kisebb részeiben is hibákat vagy programhibákat azonosítsunk, nagyobb lesz.
- Több modul tesztelhető egyszerre, így a megközelítés támogatja a párhuzamos tesztelést.
- A tesztelés összetettsége könnyen kezelhető, mivel minden modult külön kell megvitatni.
- Az egyik modulban talált hiba trackis mennyiségű kóddal is használható, így a hibakeresési idő jelentősen lecsökken.
Hogyan kell elvégezni a modul tesztelését?
Tervezés a próbaper a modultesztelés fontos része. A modultesztelés teszteseteinek tervezésekor a tesztelőnek két dolgot kell figyelembe vennie.
- A modul specifikációi
- A modul forráskódja
Elemezze a modul logikáját egy vagy több elem felhasználásával fehér doboz módszereket, majd ezeket a teszteseteket kiegészítjük a következő alkalmazásával: fekete doboz metódusokat a modul specifikációjához. A realisztikus értékek ugyanolyan fontosak, mint a kiválasztott útvonalak, ezért készítse elő a teszt adat az esetek mellett, nem pedig utána.
Miután a tesztesetek elkészültek, a következő lépés a modulok tesztelésre való kombinálása. Az alkalmazott módszer vagy egy járulékos vagy nem inkrementális módszer.
- Nem inkrementális módszer — minden modult külön tesztel. Először az összes modult egyesíti, majd a teljes programot teszteli.
- Inkrementális módszer — minden modult először tesztelnek, majd fokozatosan hozzáadják a tesztelt gyűjteményhez. Lépésenkénti újratesztelést hajt végre.
- Az inkrementális tesztelésen belül két megközelítés létezik, fentről lefelé és a alulról felfelé tesztelés.
- A modul kiválasztott adatokkal történő végrehajtásához illesztőprogramra van szükség a tesztadatok ellátásához, a végrehajtás monitorozásához és az eredmények rögzítéséhez.
A két módszer közötti választás a beállítási erőfeszítés és a diagnosztizálhatóság közötti kompromisszum.
| Aspect | Inkrementális módszer | Nem inkrementális módszer |
| Kombináció | Egy modul egyszerre, hozzáadva egy tesztelt gyűjteményhez | Az összes modult egyesítették, majd együtt tesztelték |
| Állványzatra van szükség | Több illesztőprogram és csonk, fokozatosan írva | Kevesebb tesztduplikáció, mivel valódi modulok vannak jelen |
| Hiba izolálása | Erős – a hiba az újonnan hozzáadott modulra mutat | Gyenge – a kudarc bárhol keletkezhet |
| A legalkalmasabb | Nagyméretű építmények sok interaktív modullal | Kis programok kevés modullal és alacsony csatolással |
Illesztőprogramok és csonkok a modultesztelésben
A fent említett meghajtóprogram egy pár egyik fele. Mivel egy tesztelt modul ritkán helyezkedik el a híváslánc tetején vagy alján, a tesztelők a hiányzó részeket próbakóddal helyettesítik be.
- Vezető — lecseréli a tesztelt modul feletti hívó modult. Ez biztosítja a tesztadatokat, meghívja a modult, figyeli a végrehajtást és rögzíti az eredményeket. Az alulról felfelé irányuló tesztelés a meghajtóprogramoktól függ, mivel az alsóbb modulok a magasabbak előtt elkészülnek.
- tuskó — lecseréli a tesztelt modul alatt meghívott modult. Elfogadja a hívást, és egy fix, ismert választ ad vissza, így a tesztelt modul befejezheti az útját. A felülről lefelé irányuló tesztelés a csonkoktól függ, mivel a magasabb szintű modulok készülnek el először.
Egy kidolgozott eset kézzelfoghatóvá teszi a párosítást. Ha egy fizetési-számítási modul befejeződött, de a hívást indító fizetési képernyő még nem, a sofőr betáplálja a modult a rendelési összegek halmazával, és rögzíti a visszaadott adatokat. Ha a modul által meghívott adókereső szolgáltatás is befejezetlen, egy bizonylat fix adókulcsot ad vissza, így a számítás továbbra is fut. Egyik állványzat sem kerül kiszállításra; mindkettőt elvetik, amint a valódi modulok megérkeznek, ezért szerepel a félreértett tesztek duplázása később visszatérő kihívásként.
Példatippek a modul teszteléséhez
Íme néhány tipp, amit érdemes megfontolni a modul tesztelése előtt.
- RevHasználat előtt tekintse meg a teszteseteket.
- Kerülje a félreértéseket az eltérések forrásával kapcsolatban.
- Használjon automatizált teszteszközöket.
- Vizsgáljuk meg azokat a változókat, amelyeknek változatlannak kell maradniuk.
- Cserélje ki a modulokat a tesztelők között az önellenőrzések elkerülése érdekében.
- Használd újra a teszteseteket.
Az ötödik tipp nagyobb súllyal bír, mint amennyit a hossza sugall. Egy fejlesztő, aki csak az imént megírt modult teszteli, ugyanazokat a feltételezéseket ismétli, amelyek a hibát okozták, így a modulok emberek közötti rotációja az egyik legolcsóbb elérhető minőségnövelési mód.
Unit Testing vs Modul Testing
A két kifejezést sok csapatban felcserélhetően használják, mégis a szerzőség és a hatókör eltér.
| Modul tesztelése | Egység tesztelése |
| A modultesztek olyan tesztek gyűjteménye, amelyeket egy tesztelő ír, miután egy fejlesztő írt egy kódot | Mértékegységek a szoftverfejlesztési folyamat során a fejlesztő által írt tesztek gyűjteménye |
| A modultesztelés magában foglalhatja az egységtesztek kombinálását | Az egységtesztelés során az egységek elszigetelten is tesztelhetők. |
Modul tesztelés vs. komponens tesztelés vs. integrációs tesztelés
A modultesztelés két szomszédos szint mellett helyezkedik el, amelyeket könnyű összetéveszteni vele. A táblázat a tesztelés tárgyát képező és a tesztelést általában végző személy szerint választja el őket.
| Aspect | Modul tesztelés | Komponens tesztelése | Integrációs tesztelés |
| Teszt alatt | Egy alprogram, osztály vagy eljárás | Egy önálló komponens a közvetlen függőségeivel | Az egyesített modulok közötti interfészek |
| Szokásos tulajdonos | Tesztelő, miután a kód megírásra került | vizsgáló | Integrációs tesztelő |
| Állvány | Illesztőprogramok és csonkok | Külső függőségek csonkjai | Fokozatosan kevesebb tesztduplázódás |
| Feltárult hiba | Logikai hiba a modulon belül | Viselkedési hiba a komponensben | Interfész- és adatátviteli hiba |
A mindennapi használatban alkatrész tesztelése és a modultesztelést gyakran ugyanazon tevékenységként kezelik, míg integrációs tesztelés csak akkor kezdődik, ha az egyes modulok külön-külön is sikeresen teljesítették a feladatot.
Kihívások a modul tesztelésében
Ezekkel a kihívásokkal találkoznak a csapatok a leggyakrabban, amikor bevezetik a modultesztelést.
- A nem növekményes tesztelés több munkát igényel – ha mindent először kombinálunk, egyetlen hiba is visszaküldheti a tesztelőket az egész programon keresztül.
- Félreértés teszt megkettőzik — egy irreális értéket visszaadó csonk egy zöld futtatást eredményez, ami semmit sem bizonyít.
- Gyakran előforduló hibakeresési tesztek – az állványozási kódnak megvannak a maga hibái, és az illesztőprogram javítására fordított idő nem a modul tesztelésére fordított idő.
- Meg kell érteni a kódot – A fehér doboz orientáció azt jelenti, hogy egy tesztelő, aki nem tudja elolvasni a modult, nem tud értelmes eseteket tervezni hozzá.
