Mis on mutatsiooni testimine? (Näide)

Mis on mutatsioonide testimine?

Mutatsiooni testimine on tarkvara testimise tüüp, mille käigus lähtekoodi teatud lauseid muudetakse ehk muteeritakse, et kontrollida, kas testjuhtumid suudavad lähtekoodist vigu leida. Mutatsioonitestimise eesmärk on tagada testjuhtumite kvaliteet robustsuse osas, et need muteeritud lähtekoodis läbi kukuksid.

Mutantprogrammis tehtavad muudatused peavad olema äärmiselt väikesed, et need ei mõjutaks programmi üldist eesmärki. Mutatsioontestimist nimetatakse ka veapõhiseks testimisstrateegiaks, kuna see hõlmab programmis tahtlikult vea loomist. See on üks vorm Valge Box Testimine mida rakendatakse peamiselt ajal, mil Üksuse testimine.

Mutatsioonitestimise pakkus välja Richard Lipton 1971. aastal tudengitöös ja see vormistati DeMillo, Liptoni ja Saywardi 1978. aasta artiklis „Näpunäited testandmete valiku kohta“. See kaotas tolleaegsete arvutuskulude tõttu hoo ja on sellest ajast alates taas populaarsust kogunud selliste keelte jaoks nagu Java, C#, Python, JavaSkript ja XML.

Kuidas mutatsioonitesti läbi viia?

Järgnevalt on toodud mutatsioonitestimise, tuntud ka kui mutatsioonianalüüsi, sammud:

Samm 1: Programmi lähtekoodi lisatakse vigu, luues palju versioone, mida nimetatakse mutantideks. Iga mutant peaks sisaldama ühte viga ja eesmärk on põhjustada mutantversiooni ebaõnnestumine, mis näitab testide tõhusust.

Samm 2: Testijuhtumeid rakendatakse nii originaalprogrammile kui ka mutantprogrammile. A Testjuhtum peaks olema piisav ja seda kohandatakse programmis esinevate vigade tuvastamiseks.

Samm 3: Võrdle originaal- ja mutantprogrammi tulemusi.

Samm 4: Kui originaalprogramm ja mutantprogramm genereerivad erineva väljundi, siis test lõpetab mutandi töö. Seega on test piisavalt hea, et tuvastada muutus originaal- ja mutantprogrammi vahel.

Samm 5: Kui algne programm ja mutantprogramm genereerivad sama väljundi, hoitakse mutanti elus. Sellistel juhtudel tuleb luua tõhusamad testid, mis tapavad kõik mutandid.

Allolev diagramm tracsamad viis sammu, alates algsest programmist läbi mutantide genereerimise kuni surma või ellujäämise otsuseni.

Kuidas luua mutantprogramme?

Mutatsioon ei ole midagi muud kui üksik süntaktiline muudatus, mis tehakse programmilauses. Iga mutantprogramm peaks algsest programmist erinema täpselt ühe mutatsiooni võrra.

Algne programm	Mutantide programm
Kui (x>y) Trüki "Tere" Teine Trüki "Tere"	Kui (x Trüki "Tere" Teine Trüki "Tere"

Ülaltoodud paaris muutus ainult võrdlusoperaator, kuid testjuhtum, kus x on suurem kui y, kuvab nüüd „Hello“ asemel „Tere“. Illustratsioon näitab seda ühte süntaktilist muudatust.

Mida mutantprogrammis muuta?

Mutantprogrammide genereerimiseks on mitu tehnikat. Allpool olevad kolm mutatsioonioperaatorite perekonda hõlmavad enamikku tööriistadega kaasasolevatest mutatsioonioperaatoritest.

Operand asendusoperaatorid	Avaldise muutmise operaatorid	Lause muutmise operaatorid
Asenda operand teise operandiga (x y-ga või y x-ga) või konstandi väärtusega.	Asendage programmilauses operaator või sisestage uus operaator.	Programmilisi avaldusi muudetakse mutantsete programmide loomiseks.
Näide: Kui(x>y) asenda x ja y väärtused Kui(5>y) asenda x konstandiga 5	Näide: Kui(x==y) Me saame == asendada >=-ga ja luua mutantprogrammi kujul If(x>=y) ja ++ lisamine lausesse Kui(x==++y)	Näide: Kustutage if-else lausest else osa Kustuta kogu if-else lause, et kontrollida programmi käitumist

Mõned näidismutatsioonioperaatorid:

• GOTO sildi asendamine
• Tagastusavalduse asendamine
• Avalduse kustutamine
• Unaarsete operaatorite sisestamine (näiteks – ja ++)
• Loogiline pistiku vahetus
• Võrreldav massiivi nime asendamine
• if-else lause osa "else" eemaldamine
• Operaatorite lisamine või asendamine
• Väljavõtte asendamine andmete muutmisega
• Muutujate andmete muutmine
• Andmetüüpide muutmine programmis

Operaneed, mis puudutavad piiritingimust, jäävad kõige sagedamini ellu, seega mutatsioonitulemused osutavad sageli tagasi lünkadele piirväärtuste analüüs.

Mutatsiooni testimise tüübid

In TarkvaraarendusMutatsioontestimine jaguneb põhimõtteliselt kolmeks – lausemutatsioon, väärtusmutatsioon ja otsustusmutatsioon.

• Lause mutatsioon – lause lõigatakse, kleebitakse või kustutatakse, seega võib tulemuseks olla mõne koodirea eemaldamine.
• Väärtuste mutatsioon – primaarparameetrite ja konstantide väärtusi muudetakse, näiteks tsükli piiri või lävendi muutmine.
• Otsuse mutatsioon – juhtlauseid muudetakse, näiteks flipping relatsioonioperaator või tingimuse eitamine.

Tööriistad rühmitavad oma operaatorid nende kolme pealkirja alla, seega perekond, mis tekitas ellujäänud mutandi, ütleb testijale, millist tüüpi väide puudub. Ellujäänud otsustusmutant tähistab tavaliselt testimata haru, mis kattub järgmisega: silmustestimine.

Mutatsioonide testimise automatiseerimine

Mutatsioonitestimine on äärmiselt aeganõudev ja käsitsi teostamiseks keeruline, seega on soovitatav kasutada automatiseerimistööriistu, mis vähendavad ka kulusid. Mutatsioonitööriist koostab mutandid, ajastab testide ajastamise, registreerib, milline mutant iga ebaõnnestunud testi puhul hukkus, ja annab tulemuse.

Saadaval olevate tööriistade loend:

• Stryker — avatud lähtekoodiga mutatsioonitestimise raamistik, millel on versioonid järgmistele rakendustele: JavaSkript ja TypeScript (StrykerJS), C# ja .NET (Stryker.NET) ning Scala (Stryker4s).
• PIT, kirjutatud ka kui PITest — mutatsioonide testimise süsteem Java ja JVM, mis muteerib kompileeritud baitkoodi ning ühendub Maveniga ja Gradle ehitab kõrvuti JUnit.

Mõlemad toimivad ehitusetappidena, seega kuuluvad nad samasse pidev integratsioon torujuhe nagu ülejäänud osa automaatika testimine kohta.

Mutatsiooni skoor

Mutatsiooniskoor on defineeritud kui surmatud mutantide protsent mutantide koguarvust.

Mutatsiooni skoor = (tapetud mutandid / mutantide koguarv) * 100

Valem on näidatud allpool kujul, nagu enamik tööriistu seda kuvab.

Testijuhtumeid kirjeldatakse mutatsioonile vastavatena, kui skoor ulatub 100 protsendini. Praktikas peab nimetaja välistama samaväärsed mutandid — mutandid, mille muudetud süntaks käitub täpselt nagu originaal, seega ükski test ei suuda neid tappa. Seetõttu kuvavad tööriistad tapetud mutantide arvu jagatud tapetud ja ellujäänud mitteekvivalentsete mutantide arvuga ning lasevad testijal märgistada ekvivalente.

Eksperimentaalsed tulemused on näidanud, et mutatsioonitestimine on tõhus viis testjuhtumite adekvaatsuse mõõtmiseks. Peamine puudus on mutantide genereerimise ja iga testi igaühe vastu käivitamise kulud.

Mutatsioonitestimine vs Code Katmine

Kõrge testi katvus ei tõesta tugevaid teste. Joone ja haru katvus salvestab, millised laused käivitati, mitte seda, kas midagi hiljem kontrolliti, seega loetakse kaetuks test, mis kutsub välja meetodi ja ei väida midagi. Mutatsioontestimine täidab selle lünga, sest mutant sureb ainult siis, kui väide tegelikult ebaõnnestub.

Aspekt	Code katmine	Mutatsiooni skoor
Mida see mõõdab	Milliseid ridu või harusid testid teostasid	Milliseid süstitud vigu testid tuvastasid
Väidete suhtes tundlik	Ei — test ilma ühegi väiteta lisab ikkagi katvust	Jah – mutant jääb ellu, kui ükski väide ei vea nurju.
Jooksu hind	Üks instrumenteeritud katsesõit	Üks katse iga ellujäänud mutandi kohta, seni aeglasem
Tüüpiline kasutamine	Kiire värav iga commit'i puhul	Kriitiliste moodulite põhjalikum perioodiline kontroll
Rikke režiim	100% katvus ilma tegeliku kinnituseta	Samaväärsed mutandid, mida ei saa kunagi tappa

Need kaks mõõdikut täiendavad teineteist. Katvus nimetab koodi, milleni kunagi ei jõutud; mutatsiooniskoor nimetab saavutatud koodi, mida kunagi ei kontrollitud. Mõlemad annavad sama tulemuse. defektide haldamise protsesskoos selliste meetmetega nagu defektide tihedus.

Mutatsioonitesti eelised

Mutatsioonitesti eelised on järgmised:

• See on võimas lähenemisviis lähtekoodiprogrammi kõrge katvuse saavutamiseks.
• See testib testikomplekti ennast, mida ükski teine ​​ei kasuta tarkvara testimise tehnika teeb otse.
• Mutatsioonitestimine annab tarkvaraarendajale hea veatuvastuse taseme.
• Meetod paljastab lähtekoodi ebaselguse ja suudab paljastada vigu, milleni tavalised käivitamised kunagi ei jõua.
• Ellujäänud mutandid on hagistatavad: igaüks neist nimetab konkreetse rea ja konkreetse muudatuse, mida sviit ei märganud.
• Kliendid saavad sellest testimisest kasu, kuna saavad usaldusväärsema ja stabiilsema süsteemi.

Mutatsioonitesti puudused

Teisest küljest on mutatsioonitestimisel järgmised puudused:

• Mutatsioonitestimine on äärmiselt kulukas ja aeganõudev, kuna tuleb genereerida ja kompileerida suur hulk mutantprogramme.
• Kuna see on aeganõudev, võib õiglane öelda, et seda testimist ei saa teha ilma automatiseerimistööriistata.
• Iga mutanti testitakse sama arvu testidega kui algset programmi, seega tuleb kogu testikomplekti suhtes käivitada suur mutantide populatsioon.
• Samaväärseid mutante ei saa ühegi testiga tappa ja nende eraldamine tõelistest ellujäänutest vajab tavaliselt käsitsi ülevaatamist.
• Kuna meetod muudab lähtekoodi, ei ole see rakendatav Must Box Testimine.

Millal mutatsioonitesti kasutada

Ülaltoodud kuluprofiil tähendab, et mutatsioontestimist tehakse harva iga commit'i ajal kogu koodibaasil. See tasub end ära seal, kus avastamata vea parandamine on kulukas ja testitav kood on piisavalt väike, et kiiresti muteeruda.

• Ohutuskriitiline või finantsloogika — maksete arvutamine, maksureeglid ja autoriseerimiskontrollid, mille puhul vaikne vale vastus on hullem kui krahh.
• Kahtlaselt kõrge levialaga sviidid — kui katvus on peaaegu 100 protsenti, kuid defektid siiski esinevad.
• Pärandkoodi ümberkujundamine — mutatsioonitulemused näitavad, kas olemasolevad testid suudaksid regressiooni tabada.
• Teegid ja jagatud komponendid — korduvkasutatava seadme viga komponent korrutub iga helistaja pealt.
• Harjutavad meeskonnad testipõhine arendus — tulemus kontrollib, kas esimesena kirjutatud testid teevad päris tööd.

Tavaliselt ei ole mõtet töötada ühekordsete prototüüpide, õhukese liimi või genereeritud koodiga, millel puudub hargnemisloogika, või sviitidega, mida domineerivad aeglased protsessid. integratsioonitestid mis juba niigi ühe läbimise jaoks tunde võtab.

Seetõttu piiravad enamik meeskondi muudetud failide käitamist, määravad oluliste moodulite jaoks lävendi ja lasevad laiemal tasandil regressioonitest sviit kannab ülejäänud osa tarkvara testimise elutsükkel.

KKK