Testiranje mutacija (ili analiza mutacija ili program mutacija) koristi se za dizajniranje novih softverskih testova i procjenu kvaliteta postojećih softverskih testova. Testiranje mutacija uključuje pravljenje malih promjena u programu koji se testira. Svaka promijenjena verzija se naziva mutant. Test detektuje, a time i odbacuje, mutanta nakon neuspjeha testa – neuspjeh koji ukazuje na to da je test uspješno prepoznao da se ponašanje mutanta razlikuje od ponašanja originalnog koda. Odbacivanje se naziva ubijanje mutanta. Vrijednost skupa testova mjeri se postotkom mutanata koje ubija. Skup testova može se zatim poboljšati, dodavanjem novih testova dizajniranih za ubijanje dodatnih mutanata.
Stvaranje mutanata se vrši pomoću dobro definiranih operatora mutacija koji ili oponašaju tipične programske greške (kao što je korištenje pogrešnog operatora ili naziva varijable) ili prisiljavaju stvaranje vrijednih testova (kao što je dijeljenje svakog izraza s nulom).
Testiranje mutacija je oblik testiranja bijele kutije. Its purpose is to help the tester develop effective regression tests by locating weaknesses in the test data used to test the program and discovering sections of the tested program's code that are seldom or never accessed during execution.
Uvod Veći dio ovog članka govori o "mutaciji programa", u kojoj se program modificira. Opšta definicija "analize mutacija" je korištenje dobro definiranih pravila definiranih na sintaktičkim strukturama za sistematske promjene softverskih artefakata.Paul Ammann and Jeff Offutt. Introduction to Software Testing. Cambridge University Press, 2008. Analiza mutacija je primijenjena na druge probleme, ali se obično primjenjuje na testiranje. Dakle, „testiranje mutacija“ se definira kao korištenje analize mutacija za dizajniranje novih softverskih testova ili za procjenu postojećih softverskih testova. Dakle, analiza mutacija i testiranje mogu se primijeniti na modele dizajna, specifikacije, baze podataka, testove, XML i druge vrste softverskih artefakata, iako je mutacija programa najčešća.
Pregled Testovi se mogu kreirati kako bi se provjerila ispravnost implementacije datog softverskog sistema, ali kreiranje testova i dalje postavlja pitanje da li su testovi ispravni i da li dovoljno pokrivaju zahtjeve povezane s implementacijom. (This technological problem is itself an instance of a deeper philosophical problem named "Quis custodiet ipsos custodes?" ["Who will guard the guards?"].) Ideja iza testiranja mutacija je da program koji se testira radi kako je predviđeno, tako da ako se uvede mutant i funkcionalnost se promijeni, to znači da je uvedena greška, koju testovi zatim trebaju pronaći. Na ovaj način testovi se testiraju. Ako testni paket ne otkrije mutant, to obično ukazuje na to da testni paket nije u stanju locirati greške koje predstavlja mutant, ali također može ukazivati na to da mutacija ne uvodi nikakve greške. To jest, mutacija je validna promjena, ona koja ili proizvodi željeni rezultat ili ona koja ne utiče na funkcionalnost. Jedan (uobičajeni) način na koji mutant može biti validan je da je kod koji je promijenjen "mrtav kod" koji se nikada ne izvršava. Da bi testiranje mutacija funkcionisalo u velikom obimu, obično se uvodi veliki broj mutanata, što dovodi do kompajliranja i izvršavanja izuzetno velikog broja kopija programa. Ovaj problem troškova testiranja mutacija smanjio je njegovu praktičnu upotrebu kao metode testiranja softvera. Međutim, povećana upotreba okvira za objektno orijentisane programske jezike i jedinično testiranje dovela je do stvaranja alata za testiranje mutacija koji testiraju pojedinačne dijelove aplikacije.
Ciljevi Ciljevi testiranja mutacija su višestruki: identificirati slabo testirane dijelove koda (one za koje mutanti nisu ubijeni) identificirati slabe testove (one koji nikada ne ubijaju mutante) izračunati rezultat mutacije, rezultat mutacije je broj ubijenih mutanata / ukupan broj mutanata. saznati o propagaciji greške i infekciji stanja u programu.
Historija Testiranje mutacija je prvobitno predložio Richard Lipton kao student 1971.,Mutation 2000: Uniting the Orthogonal autora A. Jeffersona Offutta i Rolanda H. Untcha, a prvi put razvijen i objavljen od strane DeMilla, Liptona i Saywarda.Richard A. DeMillo, Richard J. Lipton i Fred G. Sayward. Savjeti o odabiru testnih podataka: Pomoć za programere u praksi. IEEE Computer, 11(4):34-41. April 1978. Prvu implementaciju alata za testiranje mutacija izvršio je Timothy Budd kao dio svog doktorskog rada (pod nazivom Analiza mutacija) na Univerzitetu Yale, 1980.Tim A. Budd, Mutation Analysis of Program Test Data. PhD thesis, Yale University New Haven CT, 1980.
Nedavno, s dostupnošću ogromne računarske snage, došlo je do ponovnog porasta analize mutacija unutar zajednice računarskih nauka, te je urađen rad na definiranju metoda primjene testiranja mutacija na objektno orijentisane programske jezike i neproceduralne jezike kao što su XML, SMV i konačni automati.
U 2004., kompanija pod nazivom Certess Inc. (sada dio Synopsys-a) proširila je mnoge principe na domen verifikacije hardvera. Dok analiza mutacija očekuje samo da će otkriti razliku u proizvedenom izlazu, Certess to proširuje provjerom da li će provjerivač u testnom okruženju zapravo otkriti razliku. Ovo proširenje znači da se procjenjuju sve tri faze verifikacije, naime: aktivacija, propagacija i detekcija. To su nazvali funkcionalnom kvalifikacijom. Fuzzing može se smatrati posebnim slučajem testiranja mutacija. U fuzzingu, poruke ili podaci koji se razmjenjuju unutar komunikacijskih interfejsa (i unutar i između softverskih instanci) se mutiraju kako bi se otkrili kvarovi ili razlike u obradi podataka. CodenomiconKaksonen, Rauli. A Functional Method for Assessing Protocol Implementation Security (Licentiate thesis). Espoo. 2001. (2001) i Mu Dynamics (2005) su razvili koncepte fuzzinga u potpuno prihvstljivu platformu za testiranje mutacija, zajedno s monitorima za temeljito vježbanje implementacija protokola.
Pregled testiranja mutacija Testiranje mutacija zasniva se na dvije hipoteze. Prva hipoteza je „kompetentnog programera“. Ova hipoteza tvrdi da kompetentni programeri pišu programe koji su blizu tačnosti. „Blisko“ bi trebalo biti zasnovano na ponašanju, a ne na sintaksi. Druga hipoteza se naziva „efekat spajanja“. Efekat spajanja tvrdi da se jednostavni kvarovi mogu kaskadno gomilati ili „sparivati“ kako bi formirali druge emergentne kvarove.A. Jefferson Offutt. 1992. Investigations of the software testing coupling effect. ACM Trans. Softw. Eng. Methodol. 1, 1 (January 1992), 5-20.A. T. Acree, T. A. Budd, R. A. DeMillo, R. J. Lipton, and F. G. Sayward, "Mutation Analysis," Georgia Institute of Technology, Atlanta, Georgia, Technique Report GIT-ICS-79/08, 1979. Suptilne i važne greške također otkrivaju mutanti višeg reda, što dodatno podržava efekat spajanja.Smith B., "On Guiding Augmentation of an Automated Test Suite via Mutation Analysis," 2008Yue Jia; Harman, M., "Constructing Subtle Faults Using Higher Order Mutation Testing," Source Code Analysis and Manipulation, 2008 Eighth IEEE International Working Conference on , vol., no., pp.249,258, 28-29 Sept. 2008Maryam Umar, "An Evaluation of Mutation Operators For Equivalent Mutants," MS Thesis, 2006Polo M. and Piattini M., "Mutation Testing: practical aspects and cost analysis," University of Castilla-La Mancha (Spain), Presentation, 2009Anderson S., "Mutation Testing", the University of Edinburgh, School of Informatics, Presentation, 2011 Mutanti višeg reda omogućavaju se stvaranjem mutanata s više od jedne mutacije. Testiranje mutacija se vrši odabirom skupa operatora mutacije, a zatim njihovom primjenom na izvorni program jedan po jedan za svaki primjenjivi dio izvornog koda. Rezultat primjene jednog operatora mutacije na program naziva se mutant. Ako je testni paket u stanju detektirati promjenu (tj. jedan od testova ne uspije), tada se kaže da je mutant ubijen.
Naprimjer, razmotrimo sljedeći fragment C++ koda: Ako je (a && b) {c = 1;} else {c = 0;}
Operator mutacije uslova bi zamijenio && sa || i proizveo bi sljedeći mutant: ako (a || b) {c = 1;} else {c = 0;} Da bi test ubio ovog mutanta, moraju biti ispunjena sljedeća tri uvjeta: Test mora doseći mutiranu naredbu. Ulazni podaci testa trebaju zaraziti stanje programa uzrokujući različita stanja programa za mutanta i originalni program. Na primjer, test sa a = 1 i b = 0 bi to učinio. Neispravno stanje programa (vrijednost 'c') mora se propagirati na izlaz programa i biti provjereno testom. Ovi uvjeti se zajednički nazivaju RIP model. Testiranje slabih mutacija (ili pokrivenost slabih mutacija) zahtijeva da su ispunjeni samo prvi i drugi uvjet. Testiranje jakih mutacija zahtijeva da su ispunjena sva tri uvjeta. Jaka mutacija je moćnija, jer osigurava da skup testova zaista može uhvatiti probleme. Slaba mutacija je usko povezana s metodama pokrivenost koda. Potrebno je mnogo manje računarske snage da bi se osiguralo da testni paket zadovoljava testiranje slabih mutacija nego testiranje jakih mutacija. Međutim, postoje slučajevi kada nije moguće pronaći testni slučaj koji bi mogao ubiti ovog mutanta. Rezultirajući program je bihevioralno ekvivalentan originalnom. Takvi mutanti se nazivaju "ekvivalentni mutanti".
Detekcija ekvivalentnih mutanata jedna je od najvećih prepreka praktičnoj upotrebi testiranja mutacija. Napor potreban za provjeru da li su mutanti ekvivalentni ili ne može biti vrlo visok, čak i za male programe.P. G. Frankl, S. N. Weiss, and C. Hu. All-uses versus mutation testing: An experimental comparison of effectiveness. Journal of Systems and Software, 38:235–253, 1997. A 2014 systematic literature review of a wide range of approaches to overcome the Equivalent Mutant ProblemOvercoming the Equivalent Mutant Problem: A Systematic Literature Review and a Comparative Experiment of Second Order Mutation by L. Madeyski, W. Orzeszyna, R. Torkar, M. Józala. IEEE Transactions on Software Engineering Identificirao je 17 relevantnih tehnika (u 22 članka) i tri kategorije tehnika: otkrivanje (DEM); sugeriranje (SEM); i izbjegavanje generiranja ekvivalentnih mutanata (AEMG). Eksperiment je pokazao da mutacija višeg reda općenito, a posebno JudyDiffOp strategija, pružaju obećavajući pristup problemu ekvivalentnih mutanata. Pored ekvivalentnih mutanata, postoje i „subsumirani mutanti“ koji postoje na istoj lokaciji izvornog koda kao i drugi mutant, i za koje se kaže da ih je drugi mutant „subsumirao“. Subsumirani mutanti nisu vidljivi alatu za testiranje mutacija i ne doprinose metrikama pokrivenosti. Na primjer, recimo da imate dva mutanta, A i B, koji oba mijenjaju liniju koda na isti način. Mutant A se prvo testira, a rezultat je da kod ne radi ispravno. Mutant B se zatim testira, a rezultat je isti kao i kod mutanta A. U ovom slučaju, smatra se da je Mutant B podvrgnut Mutantu A, budući da je rezultat testiranja Mutanta B isti kao i rezultat testiranja Mutanta A. Stoga, Mutant B ne treba biti testiran, jer će rezultat biti isti kao i kod Mutanta A.
Operatori mutacije Da bi se izvršile sintaktičke promjene u programu, operator mutacije služi kao smjernica koja zamjenjuje dijelove izvornog koda. S obzirom na to da mutacije zavise od ovih operatora, naučnici su kreirali kolekciju operatora mutacije, kako bi se prilagodili različitim programskim jezicima, poput Jave. Učinkovitost ovih operatora mutacije igra ključnu ulogu u testiranju mutacije..
Istraživači su istražili mnoge operatore mutacije. Evo nekoliko primjera operatora mutacije za imperativne jezike:
Delecija naredbi Dupliranje ili umetanje naredbi, npr. goto fail;Apple's SSL/TLS bug by Adam Langley. Zamjena logičkih podizraza sa true i false Zamjena nekih aritmetičkih operacija drugima, npr. + sa *, - sa / Zamjena nekih logičkih relacija drugima, npr. > sa >=, == i <= Zamjena varijabli drugima iz istog opsega (tipovi varijabli moraju biti kompatibilni) Uklanjanje tijela metode.