Mi az a mutációs tesztelés? (Példa)
Thomas Hamilton
⚡ Okos összefoglaló
A mutációtesztelés szándékosan visz be apró hibákat a forráskódba, majd lefuttatja a meglévő tesztkészletet minden hibás verzión, azt mérve, hogy ezek a tesztek elég erősek-e a változás észleléséhez.
Mi az a mutációs tesztelés?
Mutációs tesztelés A mutációs tesztelés egy olyan szoftvertesztelési típus, amelynek során a forráskód bizonyos utasításait megváltoztatják, vagy mutálják, hogy ellenőrizzék, a tesztesetek képesek-e hibákat találni a forráskódban. A mutációs tesztelés célja a tesztesetek minőségének biztosítása a robusztusság szempontjából, hogy azok a mutált forráskóddal szemben is megbukjanak.
Egy mutáns programban végrehajtott változtatásnak rendkívül kicsinek kell lennie, hogy ne befolyásolja a program általános célját. A mutációtesztelést hibaalapú tesztelési stratégiának is nevezik, mivel szándékosan hoz létre hibát a programban. Ez a tesztelés egy formája fehér Box Tesztelés amelyet főként akkor alkalmaznak, amikor Egység tesztelése.
A mutációtesztelést Richard Lipton javasolta 1971-ben egy diákdolgozatában, és DeMillo, Lipton és Sayward 1978-as „Tippek a tesztadatok kiválasztásához” című cikkében formalizálták. A korabeli számítási költségek miatt lendületet vesztett, és azóta olyan nyelvek számára tért vissza, mint a Java, C#, Python, JavaSzkript és XML.
Hogyan kell végrehajtani a mutációtesztet?
A mutációtesztelés, más néven mutációanalízis végrehajtásának lépései a következők:
Lépés 1: A hibákat a program forráskódjába úgy építik be, hogy számos verziót, úgynevezett mutánsokat hoznak létre. Minden mutánsnak egyetlen hibát kell tartalmaznia, és a cél az, hogy a mutáns verzió hibát okozzon, ami a tesztesetek hatékonyságát demonstrálja.
Lépés 2: A teszteseteket az eredeti programra és a mutáns programra is alkalmazzuk. Teszt eset megfelelőnek kell lennie, és úgy van beállítva, hogy észlelje a program hibáit.
Lépés 3: Hasonlítsd össze az eredeti és a mutáns program eredményeit.
Lépés 4: Ha az eredeti program és a mutáns program eltérő kimenetet generál, akkor a teszteset megöli a mutánst. Így a teszteset elég jó ahhoz, hogy detektálja az eredeti és a mutáns program közötti változást.
Lépés 5: Ha az eredeti program és a mutáns program ugyanazt a kimenetet generálja, a mutáns életben marad. Ilyen esetekben hatékonyabb teszteseteket kell létrehozni, amelyek elpusztítják az összes mutánst.
Az alábbi ábra tracugyanazt az öt lépést követi, az eredeti programtól a mutánsok generálásán át a megölt vagy túlélő ítéletig.
Hogyan készítsünk mutáns programokat?
A mutáció nem más, mint egyetlen szintaktikai változtatás, amelyet egy programutasításon hajtanak végre. Minden mutáns programnak pontosan egy mutációval kell eltérnie az eredeti programtól.
| Eredeti Program | Mutáns Program |
| Ha (x>y) Nyomtassa ki a „Hello” Más Nyomtassa ki a "Szia" |
Ha (x Nyomtassa ki a „Hello” Más Nyomtassa ki a "Szia" |
A fenti párban csak az összehasonlító operátor változott, viszont egy teszteset, ahol x nagyobb, mint y, most „Hi”-t ír ki a „Hello” helyett. Az ábra ezt az egy szintaktikai módosítást mutatja.
Mit kell megváltoztatni a Mutant Programban?
Több technika is létezik mutáns programok létrehozására. Az alábbi három család lefedi a legtöbb olyan mutációs operátort, amelyekkel az eszközök együtt szállítódnak.
| Operaés helyettesítő operátorok | Kifejezésmódosító operátorok | Utasításmódosító operátorok |
| Cserélje le az operandust egy másik operandusra (x-et y-nal, vagy y-t x-szel) vagy egy konstans értékre. | Operátor cseréje vagy új operátor beszúrása egy programutasításba. | A programozott utasításokat úgy módosítják, hogy mutáns programokat hozzanak létre. |
| Példa: Ha(x>y) cserélje ki az x és y értékeket Ha(5>y) cserélje ki x-et 5 konstansra |
Példa: Ha(x==y) A == helyére >= kerülhet, így a mutáns program a következő lesz: If(x>=y) és ++ beillesztése az utasításba Ha(x==++y) |
Példa: Törölje az else részt az if-else utasításban Töröld a teljes if-else utasítást a program viselkedésének ellenőrzéséhez |
Néhány példa a mutációs operátorokra:
- GOTO címkecsere
- A visszáru nyilatkozat cseréje
- Nyilatkozat törlése
- Egyoperátoros operátorok beszúrása (például – és ++)
- Logikai csatlakozó csere
- Összehasonlítható tömbnévcsere
- Az „else” rész eltávolítása egy „if-else” utasításból
- Operátorok hozzáadása vagy cseréje
- Nyilatkozat pótlása az adatok megváltoztatásával
- Változók adatmódosítása
- Adattípusok módosítása a programban
Operaazok a mutációk maradnak fenn leggyakrabban, amelyek egy határfeltételt érintenek, így a mutációs eredmények gyakran a határérték-elemzés.
A mutációvizsgálat típusai
In SzoftverfejlesztésA mutációtesztelést alapvetően három típusra osztják: állításmutáció, értékmutáció és döntésmutáció.
- Állítás mutáció – egy utasítást kivágnak, beillesztenek vagy törölnek, így az eredmény egyes kódsorok eltávolítása lehet.
- Értékmutáció – az elsődleges paraméterek és konstansok értékei módosulnak, például egy hurokkorlát vagy egy küszöbérték megváltoztatásával.
- Döntési mutáció – a vezérlő utasítások megváltoznak, például a flipping egy relációs operátor vagy egy feltétel negálása.
Az eszközök e három címszó alá csoportosítják az operátoraikat, így a túlélő mutánst létrehozó család megmondja a tesztelőnek, hogy milyen típusú állítás hiányzik. Egy túlélő döntési mutáns általában egy nem tesztelt ágat jelöl, amely átfedésben van a következővel: hurok tesztelés.
A mutációteszt automatizálása
A mutációtesztelés rendkívül időigényes és bonyolult manuálisan végrehajtani, ezért célszerű automatizáló eszközöket használni, amelyek a költségeket is csökkentik. A mutációtesztelési eszköz összeállítja a mutánsokat, ütemezi a futtatásokat, rögzíti, hogy az egyes sikertelen tesztek során melyik mutáns pusztult el, és jelenti az eredményt.
A rendelkezésre álló eszközök listája:
- Stryker — egy nyílt forráskódú mutációtesztelési keretrendszer, amelyhez különböző kiadások tartoznak JavaScript és TypeScript (StrykerJS), C# és .NET (Stryker.NET), valamint Scala (Stryker4s).
- PIT, más néven PITest — egy mutációtesztelő rendszer Java és a JVM, amely mutálja a lefordított bájtkódot, és csatlakozik a Mavenhez, és Gradle mellett építkezik JUnit.
Mindkettő egy építési lépésként fut, tehát ugyanabba a csoportba tartoznak. folyamatos integráció a csővezeték többi részeként automatizálási tesztelés tovább.
Mutációs pontszám
A mutációs pontszámot az elpusztult mutánsok százalékos arányaként definiáljuk az összes mutáns számához képest.
Mutációs pontszám = (elölt mutánsok / összes mutáns száma) * 100
A képlet az alábbiakban látható abban a formában, ahogyan a legtöbb eszköz kiírja.
A teszteseteket akkor tekintjük megfelelő mutációnak, ha az eredmény eléri a 100 százalékot. A gyakorlatban a nevezőnek ki kell zárnia a következőket: ekvivalens mutánsok — mutánsok, amelyek megváltozott szintaxisa pontosan úgy viselkedik, mint az eredeti, így egyetlen teszt sem tudja őket elpusztítani. Az eszközök ezért az elpusztított mutánsok számát osztva a elpusztított és a túlélő, nem ekvivalens mutánsok számával jelentik, és hagyják, hogy a tesztelő megjelölje az ekvivalenseket.
Kísérleti eredmények kimutatták, hogy a mutációtesztelés hatékony módszer a tesztesetek megfelelőségének mérésére. A fő hátránya a mutánsok generálásának és az egyes tesztesetek mindegyiken történő futtatásának költsége.
Mutációs tesztelés vs. Code Lefedettség
Magas teszt lefedettség nem bizonyítja az erős teszteket. A vonal- és elágazás-lefedettség azt rögzíti, hogy mely utasítások futottak le, nem pedig azt, hogy utólag ellenőriztek-e valamit, így egy olyan teszt, amely meghív egy metódust, de nem állít semmit, továbbra is lefedettnek számít. A mutációtesztelés ezt a hiányosságot pótolja, mivel egy mutáns csak akkor hal meg, ha egy állítás ténylegesen meghiúsul.
| Aspect | Code lefedettség | Mutációs pontszám |
| Mit mér | Mely vonalakon vagy ágakon futottak a tesztek | Milyen befecskendezett hibákat észleltek a tesztek |
| Érzékeny az állításokra | Nem – egy teszt, amelyben nulla állítás van, továbbra is növeli a lefedettséget | Igen – egy mutáns túléli, ha egyetlen állítás sem vall kudarcot |
| Egy futás költsége | Egy műszeres tesztüzem | Egy tesztfuttatás túlélő mutánsonként, eddig lassabb |
| Tipikus felhasználás | Gyors átjáró minden commit után | A kritikus modulok alaposabb, időszakos ellenőrzése |
| Meghibásodás | 100 százalékos lefedettség valódi ellenőrzés nélkül | Egyenértékű mutánsok, amelyeket soha nem lehet megölni |
A két metrika kiegészíti egymást. A lefedettség a soha el nem ért kódot nevezi meg; a mutációs pontszám pedig a soha el nem ért, de ellenőrizetlen kódot. Mindkettő ugyanazt a hibakezelési folyamatolyan intézkedések mellett, mint a hibasűrűség.
A mutációteszt előnyei
A mutációtesztelés előnyei a következők:
- Ez egy hatékony megközelítés a forrásprogram magas lefedettségének eléréséhez.
- Magát a tesztkészletet teszteli, amit más nem szoftvertesztelési technika közvetlenül csinálja.
- A mutációtesztelés jó szintű hibaészlelést biztosít a szoftverfejlesztők számára.
- A módszer feltárja a forráskód kétértelműségeit, és képes olyan hibákat is feltárni, amelyeket a szokásos futtatások soha nem érnek el.
- A túlélő mutánsok ellen lehet cselekedni: mindegyik megnevez egy adott sort és egy adott változást, amelyet a kíséret nem vett észre.
- Az ügyfelek egy megbízhatóbb és stabilabb rendszert kapnak ebből a tesztelésből.
A mutációteszt hátrányai
Másrészt a mutációtesztelés hátrányai a következők:
- A mutációtesztelés rendkívül költséges és időigényes, mivel nagyszámú mutáns programot kell generálni és lefordítani.
- Mivel időigényes, elmondható, hogy ez a tesztelés automatizálási eszköz nélkül nem végezhető el.
- Minden mutánst ugyanannyi tesztesettel tesztelnek, mint az eredeti programot, tehát egy nagyméretű mutáns populációt kell futtatni a teljes tesztkészleten.
- Az ekvivalens mutánsokat semmilyen teszttel nem lehet elpusztítani, és a valódi túlélőktől való elkülönítésük általában manuális ellenőrzést igényel.
- Mivel a metódus megváltoztatja a forráskódot, nem alkalmazható a következőkre: Fekete Box Tesztelés.
Mikor használjunk mutációtesztelést?
A fenti költségprofil azt jelenti, hogy a mutációtesztelést ritkán futtatják le egy teljes kódbázison minden egyes véglegesítéskor. Megtérül, ha egy nem észlelt hiba költséges, és a tesztelt kód elég kicsi ahhoz, hogy gyorsan mutálódjon.
- Biztonságkritikus vagy pénzügyi logika — fizetésszámítás, adózási szabályok és engedélyezési ellenőrzések, ahol egy néma rossz válasz rosszabb, mint egy összeomlás.
- Gyanúsan magas lefedettségű lakosztályok — amikor a lefedettség közel 100 százalékos, de a hibák továbbra is eltűnnek.
- Régi kód újragondolása — a mutációs eredmények feltárják, hogy a meglévő tesztek kimutatnának-e regressziót.
- Könyvtárak és megosztott komponensek — egy újrafelhasznált összetevő minden hívóra megsokszorozódik.
- Gyakorló csapatok tesztvezérelt fejlesztés – a pontszám azt ellenőrzi, hogy az elsőként megírt tesztek valódi munkát végeznek-e.
Általában nem érdemes eldobható prototípusokon, vékony ragasztóval vagy elágazási logika nélküli generált kódon, illetve lassú rendszerek által uralt csomagokon futtatni. integrációs tesztek aminek már egyetlen menete is órákig tart.
A legtöbb csapat ezért a módosított fájlokra kiterjeszti a futtatást, küszöbértéket határoz meg a fontos modulokra, és hagyja, hogy a szélesebb közönség is foglalkozzon velük. regressziós teszt a lakosztály a többit is magával viheti szoftvertesztelés életciklusa.
