Co je testování modulů? Definice, příklady
Thomas Hamilton
⚡ Chytré shrnutí
Testování modulů kontroluje jednotlivé podprogramy, podprogramy, třídy a procedury, nikoli sestavený program, takže vady se objevují uvnitř malého, dobře srozumitelného bloku kódu, kde je snadné je najít a opravit.
Co je testování modulů?
Testování modulů je typ testování softwaru, který kontroluje jednotlivé podprogramy, podprogramy, třídy nebo procedury v programu. Namísto testování celého softwarového programu najednou doporučuje testování modulů testovat menší stavební bloky programu.
Testování modulů je z velké části orientováno na metodu „bílé krabice“. Cílem testování modulů není prokázat správné fungování modulu, ale prokázat přítomnost chyby v něm. Důležitá je tato inverze: běh, který nic nenajde, potvrdil jen velmi málo, zatímco běh, který odhalí vadu, splnil svůj účel.
Testování na úrovni modulů také umožňuje zavedení paralelismu do testovacího procesu, protože vytváří příležitost testovat více modulů současně namísto čekání na kompletní sestavení.
Proč dělat modulové testování
Testování modulů se doporučuje, protože mění ekonomiku detekce defektů.
- Pravděpodobnost identifikace chyb nebo bugů v menších částech programu se zvyšuje.
- Více modulů lze testovat současně, a proto tento přístup podporuje paralelní testování.
- Složitost testování lze snadno zvládnout, protože každý modul je zvažován samostatně.
- Uvnitř jednoho modulu byla nalezena vada. tracje možné pracovat s malým množstvím kódu, takže doba ladění prudce klesá.
Jak provést testování modulu?
Navrhování a modelový případ je důležitým segmentem testování modulů. Při navrhování testovacích případů pro testování modulů musí tester vzít v úvahu dvě věci.
- Specifikace modulu
- Zdrojový kód modulu
Analyzujte logiku modulu pomocí jednoho nebo více z bílý rámeček metody a poté tyto testovací případy doplnit aplikací Černá skříňka metody specifikace modulu. Realistické hodnoty jsou stejně důležité jako zvolené cesty, proto si připravte testovací data vedle případů, nikoli poté.
Jakmile jsou testovací případy navrženy, dalším krokem je kombinace modulů pro testování. Použitá metoda je buď inkrementální nebo neinkrementální metoda.
- Neinkrementální metoda — všechny moduly jsou testovány nezávisle. Nejprve se všechny moduly zkombinují a poté se otestuje celý program.
- Inkrementální metoda — každý modul je nejprve otestován a poté je postupně přidáván do testované kolekce. Provádí se postupné opakované testování.
- V rámci inkrementálního testování existují dva přístupy, vzhůru nohama a zdola nahoru testování.
- Pro spuštění modulu s vybranými daty je vyžadován ovladač pro dodávání testovacích dat, monitorování provádění a zachycení výsledků.
Volba mezi těmito dvěma metodami je kompromisem mezi náročností nastavení a diagnostickou schopností.
| Vzhled | Inkrementální metoda | Neinkrementální metoda |
| Kombinace | Jeden modul po druhém, přidávaný do testované kolekce | Všechny moduly zkombinované a následně testované společně |
| Potřeba lešení | Více ovladačů a pahýlů, psaných postupně | Méně zdvojených testů, protože jsou přítomny skutečné moduly |
| Izolace poruch | Silné – selhání ukazuje na právě přidaný modul | Slabý – selhání může vzniknout kdekoli |
| Nejlépe se hodí | Velké sestavení s mnoha interagujícími moduly | Malé programy s malým počtem modulů a nízkou propojeností |
Ovladače a pahýly v testování modulů
Výše zmíněný ovladač je jednou polovinou dvojice. Protože testovaný modul se zřídka nachází na vrcholu nebo spodku řetězce volání, testeři nahrazují fiktivním kódem vše, co chybí na obou jeho stranách.
- Řidič — nahrazuje volající modul nad testovaným modulem. Dodává testovací data, volá modul, monitoruje provádění a zachycuje výsledky. Testování zdola nahoru závisí na ovladačích, protože nižší moduly jsou připraveny dříve než ty vyšší.
- Pahýl — nahradí volaný modul pod testovaným modulem. Přijme volání a vrátí pevnou, známou odpověď, aby testovaný modul mohl dokončit svou cestu. Testování shora dolů závisí na stubech, protože moduly vyšší úrovně jsou připraveny jako první.
Zpracovaný případ konkretizuje párování. Pokud je modul pro výpočet platby dokončen, zatímco obrazovka pokladny, která jej volá, není, řidič předá modulu sadu celkových částek objednávky a zaznamená, co se vrátí. Pokud je služba vyhledávání daní, kterou modul volá, také nedokončená, útržek vrátí pevnou daňovou sazbu, takže výpočet stále probíhá. Ani jeden z prvků lešení se neodesílá; oba jsou po doručení skutečných modulů zahozeny, a proto je test nedorozumění doubles dále uváděn jako opakující se problém.
Příklady tipů pro testování modulu
Zde je několik tipů, které je třeba zvážit před provedením testování modulů.
- Revpřed použitím si prohlédněte testovací případy.
- Vyhněte se nejasnostem ohledně zdroje nesrovnalostí.
- Používejte automatizované testovací nástroje.
- Prozkoumejte proměnné, které by měly zůstat nezměněny.
- Vyměňujte moduly mezi testery, abyste se vyhnuli autotestům.
- Znovu použijte testovací případy.
Pátý tip má větší váhu, než naznačuje jeho délka. Vývojář, který testuje pouze právě napsaný modul, opakuje stejné předpoklady, které způsobily chybu, takže střídání modulů mezi lidmi je jedním z nejlevnějších možných zisků z hlediska kvality.
Testování jednotek vs testování modulů
Tyto dva pojmy se v mnoha týmech používají zaměnitelně, přesto se autorství a rozsah liší.
| Testování modulu | Testování jednotek |
| Modulové testy jsou sbírkou testů napsaných testerem poté, co byl nějaký kód napsán vývojářem | Jednotkové testy je soubor testů napsaných vývojářem během procesu vývoje softwaru |
| Testování modulů může zahrnovat kombinování jednotkových testů | Testování jednotek může testovat jednotky izolovaně. |
Testování modulů vs. testování komponent vs. testování integrace
Testování modulů se nachází hned vedle dvou sousedních úrovní, které si s ním lze snadno zaměnit. Tabulka je odděluje podle toho, co se testuje a kdo to obvykle provádí.
| Vzhled | Testování modulů | Testování součástí | Integrační testování |
| V testu | Jeden podprogram, třída nebo procedura | Jedna samostatná komponenta s jejími bezprostředními závislostmi | Rozhraní mezi kombinovanými moduly |
| Obvyklý majitel | Tester, po napsání kódu | Tester | Integrační tester |
| Lešení | Ovladače a pahýly | Stuby pro externí závislosti | Postupně méně zdvojených testů |
| Odhalená vada | Logická chyba uvnitř modulu | Chyba chování v komponentě | Chyba rozhraní a předávání dat |
V každodenním používání testování komponent a testování modulů jsou často považovány za stejnou činnost, zatímco integrační testování začíná až poté, co jednotlivé moduly projdou samostatně.
Výzvy v testování modulů
Toto jsou výzvy, se kterými se týmy setkávají nejčastěji při zavádění testování modulů.
- Nepřírůstkové testování vyžaduje více práce — kombinace všeho na začátku znamená, že jediná chyba může poslat testery zpět do celého programu.
- Test nedorozumění se zdvojnásobuje — stub, který vrací nerealistickou hodnotu, vytvoří zelený sled, který nic nedokazuje.
- Časté ladění testů — kód pro generování lešení má své vlastní chyby a čas strávený opravou ovladače je čas, který nebyl stráven testováním modulu.
- Je potřeba porozumět kódu — orientace bílé krabice znamená, že tester, který neumí modul číst, pro něj nemůže navrhnout smysluplné případy.
