Co je testování mutací? (Příklad)
⚡ Chytré shrnutí
Testování mutací záměrně zavádí do zdrojového kódu malé chyby a poté spouští existující sadu testů s každou chybnou verzí a měří, zda jsou tyto testy dostatečně silné k detekci změny.
Co je testování mutací?
Testování mutací je typ testování softwaru, při kterém se určité příkazy zdrojového kódu mění nebo mutují, aby se ověřilo, zda testovací případy dokáží najít chyby ve zdrojovém kódu. Cílem testování mutací je zajistit kvalitu testovacích případů z hlediska robustnosti, aby selhaly s mutovaným zdrojovým kódem.
Změna provedená v mutantním programu musí být extrémně malá, aby neovlivnila celkový cíl programu. Testování mutací se také nazývá strategie testování založená na chybách, protože zahrnuje úmyslné vytvoření chyby v programu. Je to forma... Bílá Box Testování který se uplatňuje hlavně během Testování jednotek.
Testování mutací bylo navrženo v roce 1971 ve studentské práci Richarda Liptona a formalizováno v článku „Hints on Test Data Selection“ z roku 1978 od DeMilla, Liptona a Saywarda. Ztratilo na síle kvůli tehdejší výpočetní ceně a od té doby znovu získalo půdu pod nohama díky jazykům jako Java, C#, Python, JavaSkript a XML.
Jak provést testování mutací?
Následují kroky k provedení testování mutací, známého také jako analýza mutací:
Krok 1: Chyby se do zdrojového kódu programu zavádějí vytvořením mnoha verzí nazývaných mutanty. Každá mutantní verze by měla obsahovat jednu chybu a cílem je způsobit selhání mutantní verze, což demonstruje efektivitu testovacích případů.
Krok 2: Testovací případy jsou aplikovány na původní program a také na mutantní program. Testovací případ by měla být adekvátní a je vylepšena tak, aby detekovala chyby v programu.
Krok 3: Porovnejte výsledky původního a mutantního programu.
Krok 4: Pokud původní program a mutantní program generují odlišný výstup, pak je mutant testovacím případem ukončen. Testovací případ je tedy dostatečně dobrý k detekci rozdílu mezi původním a mutantním programem.
Krok 5: Pokud původní program a mutantní program generují stejný výstup, mutant zůstává při životě. V takových případech je třeba vytvořit efektivnější testovací případy, které všechny mutanty zlikvidují.
Níže uvedený diagram tracprochází stejnými pěti kroky, od původního programu přes generování mutantů až po verdikt o zabití nebo přežití.
Jak vytvořit mutantní programy?
Mutace není nic jiného než jediná syntaktická změna provedená v programovém příkazu. Každý mutantní program by se měl od původního programu lišit právě o jednu mutaci.
| Původní program | Mutantní program |
| Pokud (x>y) Vytisknout „Ahoj“ Jiný Vytisknout „Ahoj“ |
Pokud (x Vytisknout „Ahoj“ Jiný Vytisknout „Ahoj“ |
Ve výše uvedené dvojici se změnil pouze operátor porovnání, ale testovací případ, kde x je větší než y, nyní vypíše „Hi“ místo „Hello“. Ilustrace ukazuje tuto jednu syntaktickou úpravu.
Co změnit v Mutant Programu?
Existuje několik technik, které lze použít ke generování mutantních programů. Níže uvedené tři rodiny pokrývají většinu mutačních operátorů, které jsou součástí nástrojů.
| Operanáhradní operátory | Operátory modifikace výrazů | Operátory modifikace příkazů |
| Nahraďte operand jiným operandem (x za y nebo y za x) nebo konstantní hodnotou. | Nahraďte operátor nebo vložte nový operátor v příkazu programu. | Programové příkazy jsou upraveny tak, aby vytvářely mutantní programy. |
| Příklad: If(x>y) nahraďte hodnoty x a y If(5>y) nahraďte x konstantou 5 |
Příklad: If(x==y) Můžeme nahradit == za >= a mít mutantní program jako If(x>=y) a vložení ++ do příkazu If(x==++y) |
Příklad: Odstraňte část else v příkazu if-else Smažte celý příkaz if-else, abyste zkontrolovali, jak se program chová. |
Některé příklady operátorů mutace:
- Výměna štítku GOTO
- Náhrada příkazu vrácení
- Smazání výpisu
- Vkládání unárních operátorů (například – a ++)
- Výměna logického konektoru
- Srovnatelné nahrazení názvu pole
- Odebrání části else z příkazu if-else
- Přidávání nebo nahrazování operátorů
- Náhrada výpisu změnou údajů
- Úprava dat pro proměnné
- Úprava datových typů v programu
OperaTory, které se dotknou okrajové podmínky, přežívají nejčastěji, takže výsledky mutací často poukazují na mezery v analýza hraničních hodnot.
Typy testování mutací
In Softwarové inženýrstvíTestování mutací se v zásadě dělí na tři typy – mutace výroků, mutace hodnot a mutace rozhodnutí.
- Statement Mutation – příkaz je vyjmut, vložen nebo smazán, takže výsledkem může být odstranění některých řádků kódu.
- Hodnotová mutace – hodnoty primárních parametrů a konstant jsou upraveny, například změnou hranice smyčky nebo prahové hodnoty.
- Rozhodovací mutace – řídicí příkazy se změní, například flipping relační operátor nebo negace podmínky.
Nástroje seskupují své operátory pod těmito třemi nadpisy, takže rodina, která vytvořila přeživšího mutanta, testerovi sdělí, jaký druh tvrzení chybí. Přeživší rozhodovací mutant obvykle označuje netestovanou větev, která se překrývá s testování smyčky.
Automatizace testování mutací
Ruční testování mutací je extrémně časově náročné a složité, proto je vhodné používat automatizované nástroje, které také snižují náklady. Nástroj pro testování mutací sestavuje mutanty, plánuje běhy, zaznamenává, které mutanty každý neúspěšný test usmrtil, a hlásí skóre.
Seznam dostupných nástrojů:
- Stryker — open-source framework pro testování mutací s edicemi pro JavaSkript a TypeScript (StrykerJS), C# a .NET (Stryker.NET) a Scala (Stryker4s).
- PIT, také označován jako PITest – systém testování mutací pro Java a JVM, které mutuje zkompilovaný bajtkód a zapojuje se do Mavenu a Gradle staví vedle sebe JUnit.
Oba běží jako krok sestavení, takže patří do stejného průběžná integrace potrubí jako zbytek testování automatizace apartmá.
Skóre mutace
Mutační skóre je definováno jako procento usmrcených mutantů z celkového počtu mutantů.
Skóre mutace = (zabití mutanti / celkový počet mutantů) * 100
Vzorec je uveden níže ve formě, ve které jej uvádí většina nástrojů.
Testovací případy jsou popsány jako adekvátní pro mutaci, když skóre dosáhne 100 procent. V praxi musí jmenovatel vylučovat ekvivalentní mutanty — mutanty, jejichž změněná syntaxe se chová přesně jako originál, takže je žádný test nemůže zabít. Nástroje proto hlásí počet zabitých mutantů děleno počtem zabitých plus přeživších neekvivalentních mutantů a nechají testera označit ekvivalenty.
Experimentální výsledky ukázaly, že testování mutací je účinným způsobem, jak měřit adekvátnost testovacích případů. Hlavní nevýhodou jsou náklady na generování mutantů a provádění každého testovacího případu proti každému z nich.
Testování mutací vs. Code Krytí
Vysoký pokrytí testu neprokazuje silné testy. Pokrytí řádků a větví zaznamenává, které příkazy byly spuštěny, nikoli to, zda bylo něco následně ověřeno, takže test, který volá metodu a nic netvrdí, se stále počítá jako pokrytý. Testování mutací tuto mezeru uzavírá, protože mutant zemře pouze tehdy, když tvrzení skutečně selže.
| Vzhled | Code krytí | Skóre mutace |
| Co měří | Které řádky nebo větve testy provedly | Které vnesené chyby testy odhalily |
| Citlivý na tvrzení | Ne – test s nulovými tvrzeními stále přidává pokrytí | Ano – mutant přežije, když žádné tvrzení neselže |
| Cena za běh | Jeden přístrojový test | Jeden testovací běh na přeživšího mutanta, zatím mnohem pomalejší |
| Typické použití | Rychlá brána pro každý commit | Hloubější pravidelná kontrola kritických modulů |
| Režim selhání | 100% pokrytí bez skutečného ověření | Ekvivalentní mutanti, které nelze nikdy zabít |
Tyto dvě metriky se doplňují. Pokrytí označuje kód, který nebyl nikdy dosažen; skóre mutace označuje dosažený kód, který nebyl nikdy zkontrolován. Obě poskytují stejné proces správy vad, spolu s opatřeními, jako je hustota defektů.
Výhody testování mutací
Níže jsou uvedeny výhody testování mutací:
- Je to účinný přístup k dosažení vysokého pokrytí zdrojového programu.
- Testuje samotnou testovací sadu, což žádná jiná technika testování softwaru dělá přímo.
- Testování mutací přináší vývojářům softwaru dobrou úroveň detekce chyb.
- Metoda odhaluje nejasnosti ve zdrojovém kódu a má schopnost odhalit chyby, ke kterým se běžné běhy nikdy nedostanou.
- Přeživší mutanti jsou akční: každý z nich pojmenuje konkrétní řádek a konkrétní změnu, které si suita nevšimla.
- Zákazníci z tohoto testování profitují v tom, že získají spolehlivější a stabilnější systém.
Nevýhody mutačního testování
Na druhou stranu jsou zde nevýhody testování mutací:
- Testování mutací je extrémně nákladné a časově náročné, protože je třeba vygenerovat a zkompilovat velké množství mutantních programů.
- Vzhledem k časově náročnému procesu je fér říci, že toto testování nelze provést bez automatizačního nástroje.
- Každý mutant je procvičován stejným počtem testovacích případů jako původní program, takže je nutné spustit velkou populaci mutantů na celé testovací sadě.
- Ekvivalentní mutanty nelze zabít žádným testem a jejich oddělení od skutečných přeživších obvykle vyžaduje manuální kontrolu.
- Protože metoda mění zdrojový kód, není použitelná pro Černá Box Testování.
Kdy použít testování mutací
Výše uvedený cenový profil znamená, že testování mutací se zřídka provádí napříč celou kódovou základnou při každém commitu. Vyplatí se tam, kde je nezjištěná chyba drahá a testovaný kód je dostatečně malý na to, aby se rychle změnil.
- Bezpečnostně kritická nebo finanční logika — výpočet plateb, daňová pravidla a kontroly autorizace, kde je tichá chybná odpověď horší než havárie.
- Apartmány s podezřele vysokým krytím — když je pokrytí téměř 100 procent, ale vady se stále projevují.
- Refaktoring staršího kódu — výsledky mutací odhalují, zda by stávající testy zachytily regresi.
- Knihovny a sdílené komponenty — chyba v opakovaně použitém složka násobí se u každého volajícího.
- Týmy trénující testem řízený vývoj — skóre ověřuje, zda testy napsané jako první skutečně fungují.
Obvykle se nevyplatí spouštět na jednorázových prototypech, na řídkých „lepicích“ spojovacím prvku nebo generovaném kódu bez logiky větvení, nebo na sadách s převahou pomalých kódů. integrační testy který už tak trvá hodiny na jeden průchod.
Většina týmů proto rozsah běhu zahrnuje změněné soubory, nastavuje prahovou hodnotu pro důležité moduly a umožňuje širšímu regresní testování zbytek sady životní cyklus testování softwaru.



