Univerza v Ljubljani
Fakulteta za raˇ cunalniˇ stvo in informatiko
Robert Jutreˇsa
Primerjava orodij za mutacijsko testiranje javanskih programov
DIPLOMSKO DELO
VISOKOˇSOLSKI STROKOVNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE
RA ˇCUNALNIˇSTVO IN INFORMATIKA
Mentor : viˇs. pred. dr. Igor Roˇ zanc
Ljubljana, 2022
besedilo, slike, grafi in druge sestavine dela kot tudi rezultati diplomskega dela lahko prosto distribuirajo, reproducirajo, uporabljajo, priobˇcujejo javnosti in pre- delujejo, pod pogojem, da se jasno in vidno navede avtorja in naslov tega dela in da se v primeru spremembe, preoblikovanja ali uporabe tega dela v svojem delu, lahko distribuira predelava le pod licenco, ki je enaka tej. Podrobnosti licence so dostopne na spletni strani creativecommons.si ali na Inˇstitutu za intelektualno lastnino, Streliˇska 1, 1000 Ljubljana.
Izvorna koda diplomskega dela, njeni rezultati in v ta namen razvita program- ska oprema je ponujena pod licenco GNU General Public License, razliˇcica 3 (ali novejˇsa). To pomeni, da se lahko prosto distribuira in/ali predeluje pod njenimi pogoji. Podrobnosti licence so dostopne na spletni strani http://www.gnu.org/
licenses/.
Besedilo je oblikovano z urejevalnikom besedil LATEX.
Kandidat: Robert Jutreˇsa
Naslov: Primerjava orodij za mutacijsko testiranje javanskih programov Vrsta naloge: Diplomska naloga na visokoˇsolskem programu prve stopnje Raˇcunalniˇstvo in informatika
Mentor: viˇs. pred. dr. Igor Roˇzanc Opis:
Pri mutacijskem testiranju iz izhodiˇsˇcnega programa tvorimo veˇcjo mnoˇzico spremenjenih programov (mutantov) in na njih preverjamo uˇcinkovitost vna- prej doloˇcenega nabora testov. Tovrsten pristop je zahteven tako z vidika izvedbe kot porabe ˇcasa, zato mora biti podprt z uˇcinkovitimi orodji.
V diplomskem delu poiˇsˇcite nekaj znanih orodij za izvedbo mutacijskega te- stiranja javanskih programov (µJava, PIT, Jumble, Major), jih preuˇcite ter objektivno primerjajte med seboj. V ta namen najprej doloˇcite nabor kriteri- jev, ki obsegajo razliˇcne vidike kakovosti orodij (funkcionalnost, zanesljivost, uˇcinkovitost, uporabnost, prenosljivost) in po njih ocenite orodja.
Osrednji del primerjave zahteva izdelavo tipiˇcnega javanskega programa (s poudarkom na aritmetiˇcnem raˇcunanju in logiˇcnih oziroma primerjalnih ope- racijah), ki ga na primerljiv naˇcin mutacijsko testirajte z vsemi orodji ter primerjate pridobljene rezultate. V sklepnem delu izpostavite celovito oceno posameznih orodij z vidika vaˇse uporabniˇske izkuˇsnje.
Title: Comparison of tools for mutation testing of Java programs Description:
In mutation testing, a larger set of modified programs (mutants) is created from the baseline program and they are used to check the effectiveness of a predetermined set of tests. This approach is demanding both for implemen- tation and time consumption, so it must be supported by effective tools.
tively compare them with each other. For this, define a set of criteria covering different aspects of tool quality (functionality, reliability, efficiency, usability, portability) first and evaluate the selected tools based on them.
The central part of the comparison requires the implementation of a typical Java program (with emphasis on arithmetic calculation and logical or com- parative operations), on which the mutation testing is performed with all tools in a comparable way, and compare the results obtained. Finally, hi- ghlight the overall assessment of individual tools from the view of your user experience.
Rad bi se zahvalil svojemu mentorju dr. Igorju Roˇzancu za predstavitev ideje in nadaljnjo aktivno pomoˇc in svetovanje pri razvoju diplomskega dela.
Zahvalo bi rad izrekel tudi Eli ˇZuˇzul Jovanovi´c za stalno spodbudo in podporo tako v ˇzivljenju kot pri izdelavi diplomskega dela in ˇstudiju nasploh.
Posebno bi se pa zahvalil dr. David Schulerju za pomoˇc pri implementaciji orodja JavaLanche, ki je bila na ˇzalost neuspeˇsna v ˇcasu nastanka diplom- skega dela.
Kazalo
Povzetek Abstract
1 Uvod 1
1.1 Opis sistema . . . 2
2 Tematsko ozadje 3
2.1 Kakovost in testiranje programske opreme . . . 3 2.2 Testiranje enot/modulov . . . 4 2.3 Mutacijsko testiranje . . . 4
3 Metodologija 9
3.1 Orodja . . . 10 3.2 Ocenjevanje . . . 26 3.3 Javanski program . . . 30
4 Rezultati in analiza 33
4.1 Pregled rezultatov . . . 34 4.2 Konˇcno ocenjevanje orodij . . . 37
5 Sklep 45
Clanki v revijahˇ 49
Clanki v zbornikihˇ 51
Dodatek A 59
Dodatek B 71
Seznam uporabljenih kratic
kratica angleˇsko slovensko
PO program software programska oprema
P program/code program/koda
TS test suite mnoˇzica testov
TC test case testni primer
MT mutation testing mutacijsko testiranje MO mutation operator mutacijski operator
MS mutation score mutacijski rezultat
M mutants mutanti
K killed mutants uniˇceni mutanti
E equivalent mutants enakovredni mutanti
OS operating system operacijski sistem
CPU central processing unit centralna procesna enota
Povzetek
Naslov: Primerjava orodij za mutacijsko testiranje javanskih programov Avtor: Robert Jutreˇsa
Delo se loteva problematike izbire najbolj primernega orodja za izvajanje mu- tacijskega testiranja z vidika sploˇsnega uporabnika. Pri tem se upoˇstevajo statistiˇcni podatki porabe ˇcasa in raˇcunalniˇskih virov ter empiriˇcni podatki, kot so uporabniˇska prijaznost in funkcionalnosti, ki jih orodje ponuja.
Problem mutacijskega testiranja je predvsem njegova ˇcasovna in raˇcunska zahtevnost. Iz tega razloga bi sploˇsni uporabnik iskal uˇcinkovito in prepro- sto orodje, s pomoˇcjo katerega bi lahko izvedel preverjanje kakovosti svojega nabora testov ter poslediˇcno javanskega programa. Pri izbiri najbolj primer- nega orodja je treba upoˇstevati svoje znanje in potrebe specifiˇcnega primera uporabe. To vkljuˇcuje izbiro, kaj ˇzeli testirati, kako veˇsˇc je z uporabo tovr- stnih orodij in kaj ima na voljo z vidika raˇcunalniˇskih virov.
Ocenjevanje orodij je bil glavni izziv dela. V ta namen so bile izbrane ˇzelene lastnosti in podlastnosti oziroma kriteriji, ki jim mora orodje v doloˇceni meri ustrezati, da se oceni kot dobro. Za to so bile za vsak kriterij doloˇcene Li- kertove lestvice, na podlagi katerih so bila orodja razvrˇsˇcena. Vsako mesto na lestvici je dodalo uteˇzeno ˇstevilo toˇck h konˇcni oceni.
Najboljˇsa konˇcna ocena pripada orodju, ki naj bi bilo za sploˇsnega uporab- nika najboljˇsa izbira za mutacijsko testiranje. V primeru tega dela je to orodje PIT, ki je zaradi integracije v Eclipse IDE okolje najpreprostejˇse za namestitev in uporabo ter ima konkurenˇcno kakovost rezultatov.
Abstract
Title: Comparison of java mutation testing tools Author: Robert Jutreˇsa
This work addresses the issue of choosing the most appropriate tool for per- forming the mutation testing from the point of view of the common user. It considers statistics of time and computer resources consumption, as well as empirical data such as user-friendliness and the functionality of the tool.
The problem with mutation testing is its time and computational complexity.
For this reason, the common user would want an efficient and simple tool to perform a quality check of his test set and consequently the Java program.
When choosing the most suitable tool, the actual user’s knowledge and spe- cific needs must be considered. This includes the selection of what is to be tested, how skilled the user is in using similar tools, and what is at the user’s disposal in terms of computer resources.
Evaluating selected tools was the main challenge of this work. For this pur- pose, a set of desired properties and sub-properties or criteria is defined, that the tool must to a certain extent adhere to be considered successful. A Likert scale is defined for every criterion and used to rank the tools. The weighted ranking marks are used to calculate the final score.
The best final rating corresponds to a tool that offers the best choice for mutation testing to the general user. In the case of this work, it is PIT, which is the easiest to install and use, as it is integrated into the Eclipse IDE environment. It has a competitive quality of results, too.
Poglavje 1 Uvod
Ko uporabnik razvija program preko testno vodenega razvoja, ˇzeli posredno na nekem koraku preveriti njegovo kakovost, s tem pa preverja tudi kako- vost testov. Eden izmed pristopov, ki je uporabniku pri tem na voljo, je mutacijsko testiranje. Gre za umetno vstavljanje pogostih semantiˇcnih na- pak v kodo. S ˇstetjem napak, ki jih zaznajo uporabnikovi testi, se preverja kakovost testov. Uporabnik se mora pri tem sooˇciti z veˇcjo skupino moˇznih orodij, malo primeri uporabe, na razpolago so mu pa pogosto omejeni viri informacij. To lahko uporabnika odvrne od procesa, ki je sicer uporaben in uˇcinkovit za izpopolnjevanje mnoˇzice testov in kode ter s tem posredno za zagotavljanje kakovosti.
V ta namen je bil naˇs cilj izbrati najbolj primerno orodje za mutacijsko testi- ranje, ki je primerno za sploˇsnega uporabnika oziroma nekoga, ki ga zanima proces mutacijskega testiranja. Poleg tega ˇzelimo uporabniku pribliˇzati pro- ces in idejo mutacijskega testiranja. Izbiro najprimernejˇsega orodja bo treba podkrepiti s statistiˇcnimi podatki in empiriˇcno analizo razliˇcnih pomembnih lastnosti kakovosti programske opreme. Nabor podatkov in analiza bo zaradi ˇcasovnih omejitev in nepoznavanja globlje analize porabe raˇcunalniˇskih virov procesa v Linux sistemu in v javanskih razvojnih orodjih (kot so Ant, Gra- dle in Maven) bolj povrˇsinska in osnovna, a zadostna, da bo konˇcni rezultat jasno in nedvoumno predstavljen.
1
Delo bo najprej predstavilo tematiko mutacijskega testiranja, ter pred tem testiranje programske opreme v sploˇsnem. Mutacijsko testiranje bo razde- ljeno na veˇc pomembnih vidikov in vsak bo podrobneje predstavljen. Nato bo predstavljena ˇse metodologija, kjer bodo podrobno opisana vsa obravnavana orodja skupaj z njihovim delovanjem, postopkom namestitve in uporabe.
Odsek o metodologiji bo vseboval tudi definicije kriterijev in ocen, na pod- lagi katerih bodo sestavljeni konˇcni rezultati. Na koncu sledi ˇse predstavitev statistiˇcnih in empiriˇcnih rezultatov ter konˇcni pregled in predstavitev ocen.
1.1 Opis sistema
Raziskovalno delo se je izvajalo na 64-bitnem operacijskem sistemu (angl.
operating system - OS) Ubuntu 21.10 LTS [51]. Uporabljeni sta bili dve razliˇcici Jave, in sicer 7 ter 8. Programi so bili napisani z uporabo orodja Eclipse IDE 2021-09 [26], ki pa za svoje delovanje potrebuje razliˇcico Java 11, tako da so na sistemu nameˇsˇcene vse tri. Za pisanje javanskih testov je bila uporabljena knjiˇznica JUnit4 [34].
Specifikacije raˇcunalnika:
• Matiˇcna ploˇsˇca: X570-A PRO
• Spomin: DDR4 3200 MHz 4 x 16 GB
• Procesor: AMD Ryzen 9 5950X 3.4 GHz s ˇsestnajstimi jedri
• Grafiˇcna kartica: NVIDIA GeForce RTX 3070 s 1500 MHz frekvenco jedra in 8 GB spomina
• Disk: TOSHIBA HDWD240 HDD s kapaciteto 4TB in Samsung SSD 970 EVO s kapaciteto 1TB (namestitev Ubuntu OS se nahaja na 50 GB velikem razdelku slednjega).
Poglavje 2
Tematsko ozadje
2.1 Kakovost in testiranje programske opreme
Mednarodna organizacija za standardizacijo (angl. International Standard Organization - ISO) definira kakovost kot seˇstevek znaˇcilnosti entitete, da zagotovi navedene in nakazane znaˇcilnosti. Bolj sploˇsno jo ljudje vidijo kot neprekinjeno in dosledno zagotavljanje ustreznosti in skladnosti s specifika- cijami [14].
Kakovost programske opreme (angl. software - PO) se zagotavlja (tudi) preko testiranja PO, katerega cilj je uˇcinkovito zaznavanje napak v zapletenih pro- gramskih sistemih [17], ki zadoˇsˇcajo kriterijem uporabnikov in delujejo kot priˇcakovano v vseh primerih. Vendar je popolno zagotavljanje tega skoraj nemogoˇce, ker po navadi vse zahteve niso znane vnaprej, pa tudi znane zah- teve so pogosto premalo natanˇcne. Za ustrezno kakovost PO se testiranje izvaja na razliˇcnih ravneh programske strukture [47]. Testiranje tako poteka od najniˇzje do najviˇsje ravni programske strukture:
Testiranje enot/modulov (angl. unit testing ali module testing) je testi- ranje enega odseka kode (recimo javanske metode ali razreda) v izolaciji. Ker zahteva konkretno implementacijo, to testiranje izvaja razvijalec sam.
Integracijsko testiranje(angl. integration testing) oceni, ali moduli med- sebojno pravilno komunicirajo preko skupnega vmesnika. Tudi to testiranje
3
izvaja skupina razvijalcev PO.
Sistemsko testiranje (angl. system testing) preverja, ali nastali program- ski izdelek kot celota zadoˇsˇca potrebnim specifikacijam. Po navadi ga izvaja posebna skupina testerjev.
Sprejemno testiranje (angl. acceptance testing) je konˇcno testiranje PO, ki ga izvaja skupina strokovnjakov z domenskim znanjem. Njegov namen je zagotoviti, da so izpopolnjene uporabnikove zahteve [47].
2.2 Testiranje enot/modulov
Testiranje enot je proces, ki testira eno enoto programa (angl. program - P) v izolaciji. Programski test je sestavljen iz mnoˇzice testov (angl. test suite - TS), ki jo sestavljajo testni primeri (angl. test case - TC). Ti kliˇcejo metodo ali funkcijo programa in primerjajo izhod s priˇcakovanim rezultatom.
Taka oblika testiranja omogoˇca tudi testno voden razvoj (angl. Test Driven Development - TDD), ki temelji na ideji, da programer najprej napiˇse teste in ˇsele nato program z namenom, da bi zadostil testom. Pri tem veˇckrat zaganja program in ga na podlagi rezultatov testov izboljˇsuje tako dolgo, dokler P povsem ne ustreza testnim zahtevam [12].
Pri tej obliki testiranja se ugotavlja, kako dobro vhodi testov preverijo doloˇcene strukture P, ne meri pa kakovosti posameznih TC [47].
2.3 Mutacijsko testiranje
Mutacijsko testiranje (angl. mutation testing - MT) je pristop, ki stremi k preverjanju ustreznosti in uˇcinkovitosti TS in ocenjevanju ˇstevila napak, ki so prisotne v P. Gre za idejo umeˇsˇcanja napak v P z namenom, da se preveri, kako P deluje ob pojavitvi napak, ki naj bi jih zasledili testi. Spremenjeni P se imenujejo mutanti (angl. mutants - M), ki nastanejo z uporabo mutacijskih operatorjev (angl. mutation operators - MO). Mutanti so zaznani (angl.
detected), ko TC, ki je bil na originalnem programu uspeˇsen, ni uspeˇsen
Diplomska naloga 5 med testiranjem novega spremenjenega P. Poslediˇcno jih oznaˇcimo tudi kot uniˇcene (angl. killed mutants - K). Zivi mutantiˇ (angl. live mutants) so tisti, ki ostanejo ne zaznani [17, 47]. Mutanti, ki so sintaktiˇcno razliˇcni, vendar semantiˇcno enaki originalni kodi, se imenujejo enakovredni mutanti (angl. equivalent mutants - E), saj ni nobenih razlik v rezultatih njihovega izvajanja in jih ne more odkriti noben TC. Vztrajni neenakovredni mutanti (angl. stubborn non-equivalent mutants) so taki, ki jih ne more odkriti noben prisoten TC v TS, zaradi ˇcesar je treba dopolniti TS z dodatnimi TC.
Mutanti se delijo tudi na ˇsibke (angl. weak mutants), te uniˇci vsak TC, vztrajne (angl. resistant mutants), uniˇci jih en sam TC inmutante, ki jih je teˇzko uniˇciti (angl. hard to kill mutants), uniˇci jih en sam TC, pri ˇcemer ta TC uniˇci samo tega mutanta [18]. Rezultat MT je ocena mnoˇzice testov z imenom mutacijski rezultat (angl. mutation score - MS), ki je definirana kot
M S(P, T S) = K
M −E (2.1)
Rezultat je koliˇcnik med K in ˇstevilom M. Predstavlja ˇstevilo od 0 do 1 (oziroma 0 % do 100 %), kar ustreza ustreznosti TS za nabor M, tvorjen iz P. Pri tem, je treba ˇstevilo E odˇsteti od ˇstevila vseh M, ker ne prispevajo k oceni MS. Prispevajo pa k raˇcunskemu ˇcasu za mutacijsko testiranje [17, 47].
2.3.1 Problem enakovrednih mutantov
E kvarijo konˇcni mutacijski rezultat (enaˇcba 2.1), zato se jim moramo v pro- cesu testiranja izogniti oziroma jih zaznati in ne upoˇstevati pri raˇcunanju MS. Za to obstajajo razliˇcni algoritmi.
Pri zaznavanju E sta najbolj pogosta pristopa optimizacija prevajalnika in matematiˇcne omejitve. Prvi deluje na predpostavki, da so enakovredni mu- tanti bodisi optimizacija ali poslabˇsanje izvirnega programa, ki semantiˇcno deluje pravilno. ˇCe mutant zadovolji katerokoli optimizacijsko pravilo, ga algoritem zazna in odstrani. Drugi pristop pa preprosto upoˇsteva, da so vsi testi, ki jih ne uniˇci noben mutant, enakovredni in torej neveljavni.
Pri izogibanju E govorimo v glavnem o selektivnih mutacijah in mutacijskem
testiranju viˇsjega reda. Prvi pristop govori o tem, da se izberejo mutacijski operatorji, ki tvorijo manjˇse ˇstevilo E. V drugem pristopu se ustvarijo mu- tanti z veˇc kot eno mutacijo [41]. Pri mutacijskem operatorju za zamenjavo aritmetiˇcnih operatorjev (angl. Arithemtic Operator replacement - AOR) re- cimo mutacije drugega reda prinesejo boljˇse ocene kot mutacije prvega reda [25].
2.3.2 Mutacijski operatorji
Mutanti nastanejo kot posledica uporabe mutacijskih operatorjev, ki so de- jansko mnoˇzica sintaktiˇcnih pravil, ki je odvisna od programskega jezika. Cilj MO je, da simulira pogoste sintaktiˇcne napake, ki bi jih lahko naredil progra- mer med pisanjem programa. Znanih je veˇc vrst MO, med katere se uvrˇsˇcajo tradicionalni MO (ali MO na nivoju metode) (angl. tradicional/method le- vel mutation operators), objektno orientirani MO (angl. object/class level mutation operators), MO za spreminjanje programov soˇcasnega izvajanja (angl. concurrent constructions modification operators) in MO za spremi- njanje spletnih aplikacij (angl. web operators) [41].
MO na nivoju metode vsebujejo razliˇcna sintaktiˇcna pravila, med katera so- dijo medsebojna zamenjava aritmetiˇcnih, relacijskih, pogojnih, logiˇcnih in operatorjev dodelitve ter brisanje oziroma prirejanje izrazov. Nabor MO na nivoju metode lahko vsebuje tudi sintaktiˇcna pravila za spremembo vrnitve- nih izrazov (angl. return expression) (vraˇcanje prazne vrednosti, vraˇcanje niˇcelnih vrednosti itd.) [41, 9, 16].
Naloga objektno orientiranih MO je poskrbeti za znaˇcilnosti, ki jih v program prinese objektno orientiran pristop. Te so dedovanje (angl. inheritance), en- kapsulacija (angl. encapsulation), polimorfizem (angl. polymorphism) in dinamiˇcno povezovanje (angl. dynamic binding) [17]. V grobem vsebujejo spreminjanje doloˇcil dostopnosti spremenljivk in metod, spreminjanje metod in spremenljivk podrazreda in spreminjanje tipiziranja med glavnim razre- dom in podrazredom. Za Javo obstajajo tudi posebni MO na tem podroˇcju, ki obravnavajo kljuˇcni besedi this in static, ter metode za branje (angl.
Diplomska naloga 7
Oznaka Ime Primer
AOR Zamenjava aritmetiˇcnih operatorjev (angl. Arithmetic Operator
Replacement)
+ -> -
ROR Zamenjava relacijskih operatorjev (angl. Relational Operator Replacement)
> -> !=
COR Zamenjava pogojnih operatorjev (angl.
Conditional Operator Replacement)
&& -> ||
LVR Zamenjava vrednosti (angl. Literal Value Replacemen)
"Hello" -> ""
SDL Brisanje izjav (angl. Statement Deletion)
a = b -> //a = b
SOR Zamenjava binarnega shift operatorja (angl. Shift Operator Replacement)
<< -> >>>>
Tabela 2.1: Primeri pogostih MO [38, 49, 46]
get) in nastavljanje (angl. set) spremenljivk [8, 17].
Poglavje 3 Metodologija
Cilj diplomskega dela je primerjava orodij za mutacijsko testiranje za pro- gramski jezik Java. To je pomenilo, da je bilo najprej potrebno poiskati in izbrati ustrezen nabor orodij, ki sluˇzijo namenu mutacijskega testiranja, nato je bilo treba zastaviti in definirati primerne kriterije, na podlagi katerih bodo orodja ocenjena. Na koncu smo sestavili ˇse ustrezen javanski program in sovpadajoˇci TS, ki zagotavlja primerno pokritost.
Pri izbiri primernih orodij smo se na zaˇcetku osredotoˇcili na nekaj bolj zna- nih, med njimiµJava, PIT, Major in Jumble (podpoglavje 3.1). Vsako orodje je bilo nato ocenjeno pri treh korakih uporabe: namestitev, uporaba in pri- kaz rezultatov. Ocenjevanje je potekalo glede na jasno definirane kriterije in ustrezno Likertovo lestvico, ki je bila predhodno doloˇcena za zagotavljanje korektnosti ocenjevanja in konˇcnih rezultatov.
Za potrebe dela je bilo skupno pregledanih 9 orodij. Izmed teh sta bili dve (LittleDarwin [37] in metamutator [40]) takoj zavrˇzeni zaradi pomanjkanja informacij o samih orodjih. Ostala orodja so bila preizkuˇsena. Izmed njih so se trije (Judy, JavaLanche in Jester, opisana v podpoglavju 3.1.5) med preizkuˇsanjem izkazala za neustrezna in so bila prav tako zavrˇzena. Ostala ˇstiri orodja (omenjena zgoraj) so bila bolj podrobno pregledana in ocenjena.
Javanski program za praktiˇcni del diplomskega dela je bil zasnovan s ciljem, da ˇcim bolj ustreza izbranemu naboru MO. Ti so bili izbrani za vsako orodje
9
posebej glede na omejitve orodja, vendar tako, da delujejo za razliˇcna orodja ˇcim bolj podobno. To je pomenilo, da so nekatera orodja operirala z veˇcjim naborom MO kot ostala.
3.1 Orodja
Ker je roˇcno ustvarjanje in testiranje mutantov ˇcasovno zamuden proces, se je razvila potreba po avtomatizaciji tega procesa [17]. V ta namen so se raz- vila orodja, ki omogoˇcajo tvorbo in izvajanje mutantov ter soˇcasno beleˇzijo rezultate izvajanja z namenom, da uporabniku podajo ustrezno poroˇcilo o te- stiranju. Izbrana orodja bodo podrobneje opisana v nadaljevanju, v sploˇsnem pa vsa obravnavana orodja izvajajo mutacije na vmesni kodi. Obiˇcajno im- plementirajo optimizacijo za tvorbo mutantov in obravnavanje enakovrednih mutantov [5, 41].
Za delovanje potrebujejo vmesno kodo - nabor*.class datotek, tako samih javanskih programov kot tudi JUnit testov, nekatera tudi *.java datoteke izvorne kode. Preko vhodnih parametrov ali konfiguracije spremenijo svoj naˇcin delovanja. Tako z izbranim naborom MO izvedejo tvorbo mutantov ter nato izvajanje testov. Kot rezultat vrnejo rezultate testiranja, ki obsegajo oceno mutacijskega testiranja - MS, nabor K in nabor preˇzivelih mutantov.
Vsa orodja sicer operirajo z naborom MO, ki predstavlja razˇsiritev izhodiˇsˇcnega nabora MO, orodja za mutacijsko testiranje Mothra [15] za programski jezik Fortran [5], vendar se ga lotevajo na drugaˇcne naˇcine. Veˇcina jih deluje zgolj preko terminala, kar omeji uporabnost za sploˇsnega uporabnika. Zadnja sku- pna lastnost veˇcine orodij je ta, da so podprta le v starejˇsih verzijah Jave.
Edina izjema je PIT, ki je podprt v verzijah Jave 8 in naprej [41, 45].
3.1.1 µJava
µJava [38] je orodje sestavljeno iz dveh glavnih komponent: generatorja in izvajalca mutantov (slika 3.1). Izvaja mutacije na dveh nivojih: na izvorni kodi izvede mutacije na nivoju metode, na vmesni kodi pa izvede mutacije
Diplomska naloga 11 na nivoju objektov. Pri prvem uporablja optimizacijo v obliki MSG (angl.
Mutation Generation Schema), ki tvori opis mutanta (angl. meta-mutant), ki vsebuje vse mutacije programa. To omogoˇca, da je treba za izvajanje le dvakrat prevesti kodo, enkrat izvorno kodo in enkratopis mutanta.
Na nivoju vmesne kode se izvaja bit-kodno pretvarjanje (angl. bytecode translation). To je proces, ki lahko neposredno vpliva na strukturo programa, torej spreminja deklaracije spremenljivk in metod. MSG za mutacije na nivoju objektov ni primerna, ker tega ne more narediti. Mutiranje vmesne kode izvaja orodje s pomoˇcjo zunanjega API-ja (BCEL API [23]), ki pregleda in izvede ustrezne spremembe. Orodje ne uporablja nobenega naˇcina za odkrivanje E [41]. Dokumentiran je tudiµJava vtiˇcnik za Eclipse IDE, ampak nismo mogli najti delujoˇce povezave za prenos.
Slika 3.1: Arhitektura orodjaµJava [38]
Namestitev: Orodje se v obliki dveh*.jardatotek, prenese z uradne sple- tne strani. Imensko sta to paketa mujava.jar in openjava.jar. Ti paketi se prenesejo v ˇzeleno mapo, ki sluˇzi kot delovna mapa orodja. Poleg tega morata biti paketa za pravilno izvajanje orodja umeˇsˇcena v sistemske spre-
menljivke OS, skupaj s ˇse tremi *.jar paketi. Ker orodje nima integrirane podpore za knjiˇznico JUnit [41], sta prva dva paketa junit in hamcrest.
Tretji je tools, ki je v domaˇci mapi Jave. To tudi pomeni, da orodje ni veˇc podprto od osme razliˇcice Jave naprej, saj je bila uporaba te datoteke za njo opuˇsˇcena.
Na koncu sta potrebna ˇse dva koraka. V delovni mapi orodja mora biti ustvarjena java.config datoteka, ki vsebuje absolutno pot delovne mape.
Zadnji korak se lahko izvede na roke ali pa preko v orodju definiranega ukaza.
Ta je ustvarjanje primerne datoteˇcne strukture, ki zagotovi, da delovna mapa vsebuje podmape z imenisrc, testset,classes inresults.
Uporaba: Uporabnik mora pred uporabo poskrbeti, da so datoteke v pra- vilnih podmapah. To pomeni, da se mora izvorna koda programa (*.java datoteke) nahajati v podmapi src, prevedene datoteke programa (*.class datoteke), v podmapiclassesin prevedene datoteke JUnit testov (*.class datoteke), v podmapitestset. Samo mutacijsko testiranje je pri tem orodju izvajano preko dveh grafiˇcnih uporabniˇskih vmesnikov (angl. graphical user interface - GUI). Prvi poskrbi za tvorbo mutantov, drugi pa za izvajanje te- stiranja.
Prvi vmesnik se sproˇzi v delovni mapi orodja z ukazom java mujava.gui .GenMutantsMain. Pri tem je treba poskrbeti, da OS uporablja razliˇcico Jave 8 ali starejˇso. Ukaz odpre GUI (slika 3.2), ki je sestavljen iz treh zavih- kov. V prvem uporabnik izbere MO za tvorbo mutantov ter Java datoteke, ki jih ˇzeli mutirati. Proces mutiranja izvede s klikom na gumb. V drugem si lahko uporabnik ogleda nastale tradicionalne mutante (mutante na nivoju metode) in v tretjem nastale mutante na nivoju objektov. Nastale mutante si uporabnik lahko ogleda tudi v podmapiresult\[ime java datoteke], kjer lahko v ustreznih podmapah najde*.javain*.classdatoteke originalnega programa ter nastalih mutantov za vsako metodo in razred.
Diplomska naloga 13
Slika 3.2: µJava GUI za tvorbo mutantov
Po koncu tvorbe mutantov uporabnik zapre GUI in odpre GUI za izvajanje mutacijskega testiranja (slika 3.3). To stori z ukazom java mujava.gui.
RunTestMain. Tudi ta vsebuje tri zavihke. Druga dva sta enaka kot pri prvem, prvi zavihek pa je namenjen izvajanju mutacijskega testiranja. Tu- kaj lahko uporabnik izbere izvajanje testiranja na vseh mutantih ali le na mutantih na nivoju metode/objektov. Nato izbere Java razred za testiranje, pripadajoˇco datoteko s testi, doloˇci ˇcas v sekundah za izvajanje posameznega testa, s ˇcimer se prepreˇcijo potencialne neskonˇcne zanke. Testiranje uporab- nik izvede s klikom na gumb. Po konˇcanem izvajanju se rezultati pokaˇzejo samo v GUI in (v primerjavi s prejˇsnjim korakom) ne se ustvarijo dnevniˇske
datoteke. Pregled rezultatov je loˇcen za mutante na nivoju metode in objek- tov, sestavljajo pa ga podatki, ki uporabniku povedo, koliko mutantov je preˇzivelih, koliko uniˇcenih, koliko je bilo vseh mutantov, ter kakˇsen je MS.
Uporabniku se v seznamih tudi natanˇcno pove, kateri mutanti so bili uniˇceni in kateri ne.
Slika 3.3: µJava GUI za izvajanje mutacijskega testiranja
3.1.2 Jumble
Jumble [3] je orodje, ki se lahko uporablja izkljuˇcno iz terminala OS. Za tvorbo mutantov uporablja prevajanje vmesne kode z uporabo enakega API- ja kotµJava, torejBCEL. V nasprotju zµJavo ne uporablja nobenih naprednih
Diplomska naloga 15 metod za zmanjˇsanje cene MT, zato izvaja prevajanje za vsakega mutanta posebej, pri ˇcemer je omejen le na mutante na nivoju metode. Jumble ob vsakem zagonu s pomoˇcjo BCEL naloˇzi enega mutanta v JVM podproces.
Ker je pa tako izvajanje lahko spominsko zahtevno, Jumble sproti preverja razpoloˇzljivost spominskega prostora posameznih JVM podprocesov in jih izprazni, ˇce je to potrebno. Jumble izvaja tudi preverjanje pojavitve ne- skonˇcnih zank, tako da vsakega mutanta, katerega izvajanje traja dlje kot je izbrana ˇcasovna meja (enaˇcba 3.1) oznaˇci za preˇzivelega. ˇSe ena izmed optimizacij za pohitritev izvajanja je uporaba kombinacije treh hevristik, s katerimi ˇzeli za vsakega mutanta odkriti test, ki bo mutanta zaznal in uniˇcil.
Tako kot priµJavi je dokumentiran vtiˇcnik za Eclipse IDE, ki pa nam ga ˇzal ni uspelo namestiti.
RU N T IM E LIM IT = 10∗RU N T IM E OF ORIGIN AL T EST + 2s (3.1) Namestitev: Orodje se namesti kot en sam *.jar paket, ki je prenesen z uradne spletne strani. Ta paket se poloˇzi v delovno mapo orodja, ki jo uporabnik definira sam. Uporabnik mora poskrbeti ˇse za to, da OS uporablja verzijo Jave 8 ali starejˇso.
Slika 3.4: Primer izpisa poteka MT pri orodju Jumble
Uporaba: Za izvajanje mutacijskega testiranja mora uporabnik v termi- nalu OS vnesti ukazjava -jar jumble_binary_1.3.0.jar [ime razreda programa] [ime razreda testov]. Ukazjava -jar jumble.jar --help uporabniku v terminalu izpiˇse nabor zastavic, preko katerih lahko vpliva na
izvajanje programa. Te vkljuˇcujejo tudi vklope drugih MO, natanˇcnejˇsi izpis rezultatov, katere metode naj MT ne upoˇsteva, in podobno. Ko uporabnik izvede ukaz za zagon, se zaˇcne MT, ki uporabnika v terminal sproti obveˇsˇca o svojem napredku. S pikami oznaˇcuje K, s T pa oznaˇcuje mutante, pri ka- terih je priˇslo do prekoraˇcitve ˇcasa. Ko naleti na mutanta, pri katerem se uspeˇsno izvedejo vsi testi, torej mutant ni zaznan, opozori v konzoli z lokacijo v kodi in mutantom, ki je bil na tej lokaciji ustvarjen (slika 3.4). Jumble po konˇcanem izvajanju ustvari dnevniˇske datoteke, ˇce je uporabnik ukazu dodal ustrezno zastavico.
Slika 3.5: PIT v Eclipse trˇziˇsˇcu
3.1.3 PIT
PIT [16] je uporabniku na voljo v dveh oblikah. Prva bolj popularna je kot vtiˇcnik za razliˇcne urejevalnike besedila (kot so ItelliJ [28] in Eclipse) (slika 3.5), druga pa kot orodje, ki ga je mogoˇce uporabljati iz terminala OS. Orodje omogoˇca integracijo v razliˇcna javanska razvojna orodja kot so Gradle, Ant in Maven [27, 22, 24], poleg tega pa omogoˇca tudi popolno podporo JU- nit knjiˇznice. Za tvorbo mutantov uporablja manipulacijo vmesne kode, kar omogoˇca hitrejˇse izvajanje mutiranja. Ceno mutacijskega testiranja zniˇzuje z izogibanjem reˇzijskim stroˇskom pomnilnika. Pri tem ne zahteva, da se ka- terikoli program zapiˇse na disk naprave, v pomnilniku pa se hrani samo en mutant naenkrat. Mutacije izvaja v dveh korakih. V prvem pregleda vse ra- zrede javanskega programa ter si zapomni vse potencialne lokacije v kodi in
Diplomska naloga 17 MO za mutante. Nato se ustvarijo JVM (angl. Java Virtual Machine) pod- procesi, pri katerih vsak ustvari enega mutanta in ga vstavi v glavni JVM.
Kot naˇcin manjˇsanja cene MT PIT skrbi tudi za to, da so mutanti prisotni samo v metodah, ki jih lahko testira z JUnit testi. Implementirana je tudi strategija izogibanja E, in sicer tako, da PIT predvsem uporablja MO, ki ne tvorijo veliko koliˇcino le-teh [41].
Namestitev: Ker je PIT na voljo v obliki vtiˇcnika za Eclipse IDE, je name- stitev zelo enostavna. Uporabnik mora le obiskati Eclipse trˇziˇsˇce v zavihku pomoˇc znotraj orodja. Ob kliku na gumb Install/Namesti Eclipse sam iz- vede namestitev. Edini pogoj, za katerega mora uporabnik poskrbeti pred uporabo orodja PIT, je ta, da ima testirani javanski projekt dodana junit inhamcrest paketa.
Uporaba: Pred izvajanjem ima uporabnik moˇznost konfiguracije izvajanja orodja. To lahko stori ali preko konfiguracijskega zagona (slika 3.6a) ali preko preferenc okna (sliki 3.6b, 3.6c). Ko uporabnik izbere ˇzeljeno skupino MO in nastavi ostale ˇzelene konfiguracije v preferencah okna, lahko z desnim kli- kom na*.java datoteko (JUnit teste) odpre meni, ki vsebujeRun As opcijo (dosegljiva tudi preko drugih delov Eclipse GUI). Ta odpre podmeni, kjer se nahaja opcija Pit Mutation Test. Ob kliku na to opcijo se odpre meni in ˇce je na voljo veˇc konfiguracij zagona testiranja, uporabnik izbere ˇzeljeno in zaˇzene testiranje. Med testiranjem se potek izpisuje v Eclipse konzolo, kjer se izpiˇse tudi tekstovna oblika rezultatov. Poleg tega se ustvarita ˇse dva zavihka imenovanaPIT MutationsinPIT Summary (slika 3.7). Prvi vsebuje pregled vseh nastalih mutantov, uniˇcenih in preˇzivelih. Poda tudi informa- cijo o tem, v kateri vrstici je bil mutant, ter sploˇsni opis spremembe, ki pa ni natanˇcna. Zadnji vsebuje povzetek rezultatov za razrede, pri ˇcemer rezultate razdeli tudi po javanskih paketih.
(a) Sploˇsne nastavitve
(b) Izbira MO
(c) Nastavitve ob zagonu
Slika 3.6: Konfiguracijske moˇznosti za orodje PIT
Diplomska naloga 19
Slika 3.7: Primer tekstovnega izpisa rezultatov MT orodja PIT v Eclipse konzoli
3.1.4 Major
Arhitektura Major orodja [19] je sestavljena iz dveh delov, iz prevajalniku integriranega mutatorja in analizatorja mutacij (slika 3.8). Mutator je po meri narejen Java prevajalnik (javac), ki hkrati poskrbi tudi za izvajanje mutacij. Ta pristop je optimalnejˇsi kot mutiranje izvorne ali vmesne kode.
Mutiranje izvorne kode nima semantiˇcnih informacij, kar povzroˇca mutante, ki se ne morejo zagnati. Posamiˇcno tvorjenje mutantov predstavlja ˇcasovno in spominsko zahteven proces.
Slika 3.8: Arhitektura Major orodja [19]
Mutiranje vmesne kode ima omejitev pretvarjanja preprostejˇse sintakse v bolj zahtevno, kar lahko povzroˇci nastanek mutantov, ki v izvorni kodi ne bi
bili moˇzni (slika 3.9). Same mutacije izvede tako, da spremeni sintaktiˇcno drevesno strukturo (angl. Abstract Syntax Tree - ATS) v procesu prevajanja.
To pomeni, da so na voljo recimo informacije o tipu spremenljivk. Uporaba ATS prepreˇcuje tudi veˇckratno prevajanje.
Analizator mutantov izvaja sam proces testiranja. Pri tem uporablja tri op- timizacije: zapomni si, kateri testi testirajo katero metodo, najprej poganja teste s krajˇsim ˇcasom izvajanja in analiza MT uporablja ˇze znane podatke iz prejˇsnjih korakov za krajˇsanje ˇcasa raˇcunanja. Major uporabniku ponuja tudi funkcionalnost lastnega domensko specifiˇcnega jezika (angl. Domain Speci- fic Language - DSL), ki daje uporabniku moˇznost izbire paketov/javanskih razredov za mutiranje. Za vsakega lahko doloˇci tudi katere MO ˇzeli upora- biti. Major DSL daje uporabniku tudi moˇznost, da izbere vnaprej definirane MO ali tvori svoje MO (slika 3.10). To uporabnik naredi v posebnih *.mml datotekah, ki jih nato prevede s priloˇzenim mmlc prevajalnikom.
Slika 3.9: Primer pretvarjanja kode v bolj zahtevno ob prevajanju [19]
Namestitev: Orodje Major se prenese z uradne spletne strani v obliki*.zip datoteke, ki se razˇsiri v poljubno delovno mapo. Ta vsebuje primere *.mml datotek, celotno knjiˇznico, testne primere MT za in brez ogrodja Ant, doku- mentacijo, config.jar datoteko, ki jo mora uporabnik dodati med sistem- ske spremenljivke OS, in lastni mmlc, javac in ant prevajalnik. Ker prenos orodja vsebuje vse potrebne datoteke, mora uporabnik pred uporabo samo
Diplomska naloga 21 ˇse poskrbeti, da OS uporablja razliˇcico Jave 7 ali starejˇso.
Uporaba: Uporabo se lahko zaˇcne z definicijo svoje*.mmldatoteke, ki se jo prevede s terminalskim ukazom mmlc file.mml file.mml.bin. Nato upo- rabnik prevede in mutira svojo izvorno datoteko z ukazomjavac -XMutator
=[*.mml.bin datoteka] [*.java datoteka], kjer sejavacnavezuje na po meri narejen prevajalnik, ki je priloˇzen med prenesenimi datotekami. Upo- rabnik ima na voljo tudi ukazjavac -help, ki mu pove, kakˇsne zastavice so na voljo pri izvajanju tega ukaza. Ob tem koraku se kreira tudimutants.log datoteka, ki uporabniku pokaˇze, kakˇsne mutante je orodje ustvarilo. Nato uporabnik prevede ˇse izvorno datoteko s testi z ukazomjavac -cp .:[pot do datoteke]/config.jar [*.java datoteka s testi]. Datoteka z JU- nit testi se mora nahajati v isti mapi kot izvorna datoteka prej prevede- nega programa. V kolikor se JUnit knjiˇznica ne nahaja med sistemskimi spremenljivkami OS, jo mora uporabnik dodati ukazu z uporabo zastavice -cp. Nazadnje uporabnik izvede ˇse samo mutacijsko testiranje z ukazom ant mutation.test, kjer se ant navezuje na datoteko, ki je priloˇzena Major orodju. Uporabnik mora pri izvajanju tega ukaza biti pozoren, da izpolnjuje naslednje pogoje:
• delovna mapa mora vsebovati podmape bin (s prevedenimi *.class datotekami), src (z izvorno kodo programa) in test (z izvorno kodo JUnit testov),
• delovna mapa mora vsebovati build.xml datoteko, primerno lahko uporabnik dobi v example/antpodmapi orodja in
• delovna mapa mora vsebovati mutants.log datoteko, ki je bila nare- jena v procesu prevajanja izvorne kode programa.
Ob koncu izvajanja ukaza se uporabniku v konzolo izpiˇse povzetek rezultatov, poleg tega pa se kreirajo tudi *.csv datoteke, ki vsebujejo bolj podrobne rezultate. Med drugim analitiˇcne podatke procesa, informacije o tem, kateri mutanti so bili uniˇceni in kateri ne in podobno.
Slika 3.10: Primer *.mml datoteke
3.1.5 Slepe ulice
Med iskanjem ustreznih orodij za mutacijsko testiranje so bila raziskana in testirana tudi orodja, ki praktiˇcno niso bila uporabna ali pa se jih ni dalo namestiti.
Judy: Judy [32, 10] je orodje, ki uporablja lastni FAMTA Light pristop k mutacijskemu testiranju. Pri tem procesu gre za definiranje toˇck v kodi vsa- kega razreda, s ˇcimer nastane opis mutanta. Med izvajanjem nato poseben proces doloˇca, ali se bo izvedla originalna metoda ali pa ena izmed njenih mutacij. V resnici se kreirajo mutanti metod programa in mutanti samega programa, ki se nato dinamiˇcno kliˇcejo med testiranjem. Mutacije orodje izvaja na izvorni kodi in v ˇcasu prevajanja, zato ni potrebe po ponovnem prevajanju za kreiranje vsakega mutanta. Vsebuje vse osnovne MO za krei- ranje mutantov na nivoju metode ter ˇse nekaj dodatnih.
Judy je, kot orodje, zasnovano zelo dobro, ponuja veliko z vidika hitrosti in MO, ki jih ponuja. Teˇzava je nastala pri izvajanju MT, saj je bila konfi- guracija ˇzelenih MO neuspeˇsna. Ker program ne vrne uporabniku nobenih
Diplomska naloga 23 dnevniˇskih datotek, v katerih bi lahko dejansko videli nastale mutante, je tako testiranje ˇzal neuporabno. Poleg tega je dokumentacija na spletni strani namenjena starejˇsi razliˇcici orodja in poslediˇcno neuporabna pri najnovejˇsi razliˇcici. Treba je omeniti, da so se pri starejˇsi razliˇcici med izvajanjem MT pojavljale napake, ki niso bile zlahka odpravljive. Zaradi ˇcasovnih omejitev smo to orodje opustili.
Jester: Jester [31, 11] je orodje, ki izvaja zelo preproste mutacije na izvorni kodi. Pri samem izvajanju testiranja uporablja svoj modificiran JUnit izva- jalec testov. ˇZal je Jester zelo neuˇcinkovit, saj za vsakega nastalega mutanta izvaja prevajanje programa in izvajanje testiranja z uporabo TS [13]. Po- slediˇcno ima preveˇc enostaven pristop k MT, saj orodje uporablja le MO, ki tvorijo zelo slabe rezultate [42].
Poleg ˇze omenjenih sistemskih teˇzav je priˇslo do teˇzav tudi pri sami uporabi.
Spletna dokumentacija je slaba, datoteke orodja pa so primarno narejene za Windows OS [52]. Kot posledica tega je bila prilagoditev na Ubuntu OS ˇcasovno zahtevna oziroma z vidika sploˇsnega uporabnika praktiˇcno kar ne- mogoˇca.
JavaLanche: JavaLanche [30, 20] je orodje, ki izvaja mutacije na vmesni kodi. Narejen je z idejo avtomatskega in uˇcinkovitega testiranja, zato imple- mentira veˇc optimizacij (kot so selektivno izbiranje mutacij), ki zmanjˇsajo tudi koliˇcino E. Na voljo je kot Eclipse vtiˇcnik in GitHub projekt.
Poglavitni problem tega orodja je v tem, da ni veˇc vzdrˇzevano. Eclipse vtiˇcnik ni veˇc na voljo in spletni streˇzniki s potrebnimi datotekami za delovanje niso veˇc aktivni. Potrebne manjkajoˇce datoteke so bile sicer pridobljene s strani razvijalca, a je bila uporaba tudi tega orodja opuˇsˇcena zaradi omejenega ˇcasa za spreminjanje konfiguracije Maven projekta, v obliki katerega je orodje na voljo na spletni strani GitHub.
3.1.6 Obstojeˇ ce primerjave orodij
V tem razdelku bosta na kratko predstavljeni dve raziskavi, ki sta bili ˇze narejeni glede primernosti in uporabe razliˇcnih orodij.
Jakub Moˇzucha se je v svojem magistrskem delu [41] omejil na podrobnejˇso primerjavo med orodji PIT in Judy. Ob upoˇstevanju kriterijev, kot so avto- matizacija, stanje razvoja, odprto-kodnost in vrsta licence je originalni nabor osmih orodij zoˇzil na dve (Judy in PIT), s pomoˇcjo katerih je nato izvajal eksperimente. Med drugim je priˇsel do ugotovitve, da je navkljub dejstvu, da PIT proizvede veliko veˇcjo koliˇcino mutantov, njegovo izvajanje bolj kon- stantno v primerjavi z Judy. Judy je sicer relativno hitrejˇse orodje, kadar se uporablja nad manjˇsimi projekti, vendar izvajanja ne zakljuˇci uspeˇsno pri veˇcjih projektih.
V raziskavi ”How effective are mutation testing tools?...”[35] so se avtorji primerjave lotili z vidika petih vpraˇsanj:
1. Kako uˇcinkovita so orodja pri odkrivanju resniˇcnih napak?
2. Ali lahko katerokoli orodje zazna mutante, ki so jih ustvarila ostala orodja?
3. Kako so orodja primerljiva z referenˇcnim naborom mutantov?
4. Ali je priˇslo do ugotovitev, kako izboljˇsati uˇcinkovitost orodij?
5. Kakˇsna je relativna cena izvajanja mutacijskega testiranja orodij?
Priˇsli so do naslednjih odgovorov.
1. Izmed 125 resniˇcnih napak, ki so jih uporabili za analizo, je najboljˇse orodje (razvojna razliˇcica PIT - PITRV) odkrilo 122 napak, kar je bilo za 6% veˇc od ostalih primerjanih.
2. Nobeno izmed orodij ni primerno za zaznavanje mutantov, ki so jih ustvarila druga orodja.
3. V referenˇcnem naboru mutantov je PITRV dosegel najveˇcji MS, sledili so mu µJava, Major in PIT.
Diplomska naloga 25 4. Tako za PIT, kot PITRV predlagajo izboljˇsavo pri detektiranju MO za mutiranje pogojnih operatorjev (in, ali, negacija) (angl. Conditio- nal Operator Replacement - COR). Za orodje Major predlagajo imple- mentacijo vstavljanja unarnega aritmetiˇcnega operatorja (++ in −−) (angl. Short-cut Arithmetic Operator Replacement - AORS), prav tako pa bolj standardno implementacijo MO za zamenjavo relacijskih ope- ratorjev (angl. Relational Operator Replacement - ROR). ZaµJavo so predlagali implementacijo MO, ki bi mutiral spremenljivke.
5. ˇCeprav PITRV dosega najboljˇse rezultate pri ostalih testih, je tudi naj- manj uˇcinkovit. Sledijo mu µJava, Major in PIT.
3.1.7 Izbira mutacijskih operatorjev
Mutacijske operatorje vsakega orodja je bilo treba izbrati tako, da so vsi po- krivali ˇcim bolj enak skupni nabor. Nekateri MO so navedeni v tabeli 2.1.
Ker PIT uporabniku v obliki Eclipse vmesnika ponuja najmanjˇso svobodo glede izbiranja MO, so bili izbori ostalih orodij prilagojeni njemu. Izmed treh skupin MO, ki jih ponuja PIT, torejdefaults,strongerinall, je bila izbrana skupina defaults. Ta vsebuje MO, ki sluˇzijo kot ROR, AOR, SDL, LVR in drugi (PIT jih imenuje nekoliko drugaˇce) [46].
Jumble prav tako vsebuje dva MO, na katera uporabnik nima vpliva. To sta negacija pogojnih mej in mutacija aritmetiˇcnih operatorjev, ki sovpadata z operatorjema ROR in AOR. Temu so bili dodani ˇse AORS in MO, ki sovpa- dajo z LVR. Jumble ne podpira operatorja SDL [33].
Kljub temu da Major ponuja moˇznost lastno definiranih MO, so bili za po- trebe testiranja izbrani le vnaprej definirani MO. Te so AOR, COR, ROR, zamenjava vrednosti v izjavi (angl. Expression Value Replacement - EVR), LVR in SDL [49].
MuJava uporabniku omogoˇca izbiro med MO na nivoju metode in MO na ni- voju razreda. Slednji so bili izpuˇsˇceni, saj jih ostala orodja ne ponujajo in niso zdruˇzljivi s testiranim javanskim programom. Zanje tako ni povpraˇsevanja
v tem delu. Izbrani so bili MO AOR, AORS, ROR, COR, vstavljanje po- gojnega operatorja (angl. Conditional Operator Insertion - COI), brisanje negacije logiˇcnega izraza (angl. Conditional Operator Deletion - COD), SDL, brisanje uporabe spremenljivk (angl. Variable Deletion - VDL) in brisanje konstant (angl. Constant Deletion - CDL) [38].
3.2 Ocenjevanje
Ocenjevanje orodij bo potekalo iz staliˇsˇca uporabnika in ne razvijalca. To pomeni, da bodo orodja ocenjena na podlagi tega, kako uˇcinkovita so v iz- vajanju svoje primarne funkcije in kako uporabniˇsko prijazna so na razliˇcnih stopnjah upravljanja. To vkljuˇcuje namestitev orodja, tvorbo in izvajanje mutantov ter prikazovanje rezultatov MT. V ta namen je bilo treba zastaviti jasno definirane kriterije in ocene, ki nakaˇzejo, kakˇsne lastnosti ima idealno orodje in kakˇsno je razmerje pomembnosti med njimi.
Konˇcne ocene orodij bodo doloˇcene glede na uteˇzeno povpreˇcje (enaˇcba 3.2), kjer so vrednosti x ocene glede na definirano Likertovo lestvico, ki jih bo orodje dobilo pri posameznem kriteriju, ter uteˇzi w, ki bodo 1 za tri glavne kriterije (definirane v podpoglavju 3.2.1), ter 0.75 za ostala dva kriterija.
¯ xw =
Pwx
Pw (3.2)
Uteˇzi so doloˇcene glede na pomembnost kriterija. Za glavne kriterije smo doloˇcili polno vrednost ocene (100% oziroma 1), manj pomembnim kriteri- jem smo pa doloˇcili triˇcetrtinsko vrednost ocene (75% oziroma 0.75). Taka uteˇz se nam je zdela dober kompromis med tem, da kriterij prispeva manj h konˇcni oceni, ne postane pa brezpredmeten.
Ker so posamezne Likertove lestvice razliˇcnih velikosti, bodo vse ocene nor- malizirane na lestvico s petimi stopnjami. To pomeni, da bodo pridobljene ocene Likertovih lestvic posameznega kriterija pomnoˇzene s koeficientom
5 maxSum.
Diplomska naloga 27
3.2.1 Izbira kriterijev
Lastnosti, ki bodo pri posameznem orodju ocenjene, so bile povzete po ISO 9126 [29] standardu. Najveˇcjo teˇzo bodo imela tista, ki so uporabniku naj- bolj pomembna, to so: zanesljivost, uporabnost in uˇcinkovitost [21]. ISO 9126 ne podaja nobenih referenˇcnih toˇck za pomen obravnavanih lastnosti ali podlastnosti z vidika testiranja, zato bodo obravnavane lastnosti defini- rane na sledeˇci naˇcin [1, 21]:
Funkcionalnost: kriterij upoˇsteva kolikˇsno svobodo ponuja orodje pri izbiri MO, koliko velik je nabor MO, ter kako natanˇcni in uporabni so rezultati MT v primerjavi z drugimi orodji.
Zanesljivost: kriterij opisuje zanesljivost programa, ko se testiranje izvede veˇckrat in odstopanja glede potrebnega ˇcasa in pomnilniˇskega prostora.
Uˇcinkovitost: pri tem kriteriju bosta upoˇstevana podatka koliko ˇcasa in pomnilnika potrebuje orodje za izvajanje.
Uporabnost: pod ta kriterij se uvrˇsˇcajo podatki, kot so uporabniˇska prija- znost orodja in kako dobra dokumentacija je na voljo.
Prenosljivost: ta kriterij upoˇsteva, kako preprosto je orodje za namestitev in ali njegovo uporabo omejuje druga programska oprema ali OS.
3.2.2 Likertova lestvica
Likertova lestvica [7] je znanstveno sprejet in potrjen naˇcin za merjenje stri- njanja v druˇzboslovju in izobraˇzevalnih raziskavah. Obstaja veˇc vrst Liker- tove lestvice, najbolj popularne so 2, 3, 5, 7 in 10 stopenjske lestvice. Med njimi je najbolj pogosta 5 stopenjska, ki spraˇsuje anketiranca po mnenju na lestvici od “sploh se ne strinjam” do “popolnoma se strinjam” [6]. V diplomi se bosta uporabljali 3 in 5 stopenjska lestvica. Prva se izkaˇze za zadostno [4], in v praksi daje anketirancu moˇznosti “se strinjam”, “se ne strinjam” in
“sem nevtralen”. Kjer to ne bo dovolj, bo uporabljena 5 stopenjska lestvica.
Likertove lestvice bodo vsebovale opise priˇcakovanega obnaˇsanja orodij pri
posameznem kriteriju, velikost lestvice pa bo definirana glede na ˇstevilo toˇck pomembnosti, ki jih obsega kriterij.
Orodje bo za izbran kriterij umeˇsˇceno na mesto na lestvici. Vsako mesto je vredno doloˇceno ˇstevilo toˇck in predstavlja oceno kriterija, ˇce je ta sestavljen iz samo enega dela (tabele 3.3, 3.2, 3.5). Kjer pa je kriterij sestavljen iz dveh delov (tabeli 3.1 in 3.4), pa je ocena kriterija seˇstevek obeh mest, ki ju orodje zavzema.
MO 1 Orodje ponuja vnaprej definiran nabor MO, na ka- terega uporabnik nima vpliva.
MO 2 Orodje ponuja vnaprej definirane skupine MO, med katerimi lahko uporabnik izbira.
MO 3 Orodje ponuja prosto izbiro iz omejenega nabora MO.
MO 4 Orodje ponuja prosto izbiro iz veˇcjega nabora MO.
MO 5 Orodje uporabniku poleg ˇze definiranih MO po- nuja moˇznost za lastno definicijo MO.
REZ 1 Rezultati ponujajo omejene informacije glede MT oz. MS ni najbolj primerljiv z ostalimi orodji.
REZ 2 Rezultati ponujajo manj omejene informacije glede MT oz. MS je bolj primerljiv z ostalimi orodji.
REZ 3 Rezultati ponujajo podrobne informacije glede MT oz. MS je primerljiv z ostalimi orodji.
Tabela 3.1: Likertovi lestvici za kriterij funkcionalnosti
Diplomska naloga 29
ZA 1 ZA 2 ZA 3
Orodje ni zanesljivo med veˇckratnim izvajanjem (velika
odstopanja mutacijskega
rezultata in potrebnega ˇcasa/raˇcunalniˇskih
virov).
Orodje je dokaj zanesljivo med
veˇckratnim izvajanjem (majhna
odstopanja mutacijskega
rezultata in potrebnega ˇcasa/raˇcunalniˇskih
virov).
Orodje je zelo zanesljivo (ni
odstopanj mutacijskega
rezultata in potrebnega ˇ
casa/raˇcunalniˇskih virov).
Tabela 3.2: Likertova lestvica za kriterij zanesljivosti
U ˇC 1 U ˇC 2 U ˇC 3
Orodje porabi veˇc ˇ
casa in raˇcunalniˇskih virov za izvajanje v primerjavi z drugimi.
Orodje porabi povpreˇcno koliˇcino ˇcasa in raˇcunalniˇskih
virov za izvajanje v primerjavi z drugimi.
Orodje porabi manj ˇ
casa in raˇcunalniˇskih virov za izvajanje v primerjavi z drugimi.
Tabela 3.3: Likertova lestvica za kriterij uˇcinkovitost UP 1 Orodje ni lahko za uporabo.
UP 2 Orodje predstavlja izzive pri uporabi, a ni prezah- tevno.
UP 3 Orodje je preprosto za uporabo.
DO 1 Orodje ima slabo dokumentacijo.
DO 2 Orodje ima solidno dokumentacijo.
DO 3 Orodje ima dobro dokumentacijo.
Tabela 3.4: Likertovi lestvici za kriterij uporabnost
PR 1 PR 2 PR 3 Program je zahtevno
namestiti na katerikoli sistem
(potrebna je konfiguracija odvisnosti).
Program je dokaj preprosto namestiti na katerikoli sistem
(potrebna je konfiguracija nekaterih odvisnosti).
Program je preprosto namestiti na katerikoli sistem.
Tabela 3.5: Likertova lestvica za kriterij prenosljivost
3.3 Javanski program
Javanski program (dodatek A) je bil namensko zasnovan, da izraˇza znaˇcilnosti izbranega nabora MO za vsako mutacijsko orodje (podpoglavje 3.1).
Zasnovani program predstavlja kalkulator. Sestavljen je kot en sam razred z veˇc metodami, njegova priˇcakovana uporaba pa bi bila kot knjiˇznica ma- tematiˇcnih funkcij. Program je tako sestavljen iz metod, ki vraˇcajo reˇsitve matematiˇcnih izrazov brez uporabe integriranih knjiˇznic z izjemo funkcije Math.abs()in konstanteMath.PI. Program sestavlja 19 glavnih in 2 pomoˇzni metodi, ki sluˇzita za raˇcunanje potenc z decimalnimi eksponenti. Metode za raˇcunanje trigonometriˇcnih funkcij (sin, cos,tan, arcsin), eksponentne funkcije in raˇcunanje naravnega logaritma so implementacije formul Taylorje- vih vrst, privzetih iz [39]. Funkcija za raˇcunanje korena pa je implementacija Newtonove metode za raˇcunanje n-tega korena [2].
Odloˇcitev za implementacijo kalkulatorja je bila sprejeta predvsem zaradi prisotnosti AOR MO, ki je eden najbolj osnovnih MO. Zaradi omejitev ne- katerih orodij in zagotavljanja, da vsa orodja delujejo na kar se da primerljiv naˇcin, je bilo treba poskrbeti za prisotnost pogojnih izrazov, ki so prisotni pri prepreˇcevanju napak (deljenje z 0 in podobno) in iterativnem raˇcunanju
Diplomska naloga 31 Taylorjevih vrst v obliki do-while zank. Ker je program zasnovan kot sku- pina funkcij, za mutacije return izrazov, ni bilo treba posebej poskrbeti.
Testi so napisani z uporabo knjiˇznice JUnit4. Napisanih je bilo 124 testov (primeri v dodatku B), ki se vsi uspeˇsno izvedejo. Dovoljeno odstopanje pri natanˇcnosti rezultatov je bilo 0.001. Za izvajanje testov pa je bilo potrebno
≈0.013s. Testiranje se je izvajalo z uporabo Eclipse IDE.
Preverili smo tudi pokritosti kode, ki jo zagotavljajo testi. Uporabili smo Eclipse IDE, ki ponuja to moˇznost, ko se v orodje uvozi ustrezna JUnit knjiˇznica. Izkazalo se je, da testi zagotavljajo 100 % pokritost kode.
Poglavje 4
Rezultati in analiza
Za vsako orodje smo izvedli naslednje meritve:
• ˇstevilo mutantov,
• ˇcas tvorbe mutantov,
• mutacijski rezultat,
• ˇcas potreben za izvajanje mutacijskega testiranja in
• povpreˇcna poraba spomina in centralne procesne enote (angl. central processing unit - CPU) (s standardnim odklonom).
Ker mutacijsko testiranje (in tvorjenje mutantov) po definiciji ni nakljuˇcno, sta bili meritvi ˇstevila mutantov in mutacijsko testiranje (z izjemo pri orodju Major) konstantni.
Meritve za povpreˇcno porabo CPU in spomina so bile izvrˇsene s pomoˇcjo Ubuntu paketa sysstat [48], bolj natanˇcno ukaza pidstat [44]. Z ukazom pidstat 1 -ruh -C java > pidStat.csvse je standardni izhod ukaza pre- usmeril v csv datoteko, v katero se je nato vsako sekundo zapisala izbrana statistika. Ob zakljuˇcenem izvajanju se je izvedel ˇse ukaz sed -i -r -e
"s/,/./g" -e "s/ +/,/g" -e "s/#,//g" pidStat.csv, da se je zapis v datoteki pretvoril v pravilni*.csv format.
33
Nato sta se z uporabo programa LibreOffice [36] povpreˇcila stolpca CPU%
in MEM%, ki vsebujeta podatke o skupni porabi CPU in spomina za doloˇcen proces. Jumble, Major in PIT uporabniku tudi sami sporoˇcijo ˇcas izvajanja in tvorjenja mutantov, medtem ko je bil za orodjeµJava uporabljen Ubuntu ukaztime[50]. Konˇcni podatki za vsako orodje predstavljajo povpreˇcje petih izvajanj z uporabo enake kode in testov.
4.1 Pregled rezultatov
Orodja ˇze pri prvem pregledu rezultatov izvajanj delujejo razliˇcno. Samo ˇstevilo tvorjenih mutantov se med njimi moˇcno razlikuje (tabela 4.1), med najmanjˇsim in najveˇcjim ˇstevilom tvorjenih mutantov je razlika kar 800. Sta pa pri istih dveh orodjih prisotni tudi skrajnosti MS (torej najveˇcji in naj- manjˇsi rezultat) (tabela 4.1). Poleg tega so vsa orodja (z izjemo orodja Major) bila konstantna glede izvajanja MT in so v vsaki ponovitvi vraˇcala enak MS. Major je pa imel nihanje z najveˇcjo razliko 0.3% (tabela 4.2).
µJava PIT Jumble Major ˇStevilo mutantov 998 194 263 676
MS [%] 93 89 89 90.12
Tabela 4.1: ˇStevila tvorjenih mutantov in mutacijski rezultat
Major MS [%] 90.09 89.94 90.24 90.24 90.09
Tabela 4.2: Mutacijski rezultati za pet ponovitev uporabe orodja Major Pri zgoraj obravnavanih podatkih ni bilo velike razlike med skrajnostmi iz- merjenih podatkov, je pa pri naslednji razlika bolj opazna. Orodje µJava pri vseh ˇstirih ˇse obravnavanih meritvah (ˇcas tvorbe mutantov, ˇcas izvajanja mutacijskega testiranja, poraba spomina in poraba CPU) izstopa med vsemi kot najslabˇsa. Pri tvorbi mutantov je dosegla ˇcas, ki je za ≈ 100% veˇcji od
Diplomska naloga 35 naslednjega, pri izvajanju MT pa ˇcas, ki je kar za ≈ 300% veˇcji od nasle- dnjega (tabeli 4.3 in 4.4). Ta podatek v kombinaciji z velikimi odstopanji, ki jih orodje kaˇze pri porabi spomina in CPU (tabeli 4.5 in 4.6), pomeni, da orodje ni konkurenˇcno z vidika optimizacije.
µJava PIT Jumble Major 1. ˇcas [ms] 12950 <1000 5843 332 2. ˇcas [ms] 12920 <1000 5786 321 3. ˇcas [ms] 12510 <1000 5841 328 4. ˇcas [ms] 12680 <1000 5986 330 5. ˇcas [ms] 12410 <1000 5911 328 Povpreˇcje [ms] 12690 <1000 5873.4 327.8
Tabela 4.3: ˇCasi tvorbe mutantov
µJava PIT Jumble Major 1. ˇcas [s] 442.54 6 106.52 105.7 2. ˇcas [s] 448.39 6 106.26 103.6 3. ˇcas [s] 449.9 7 106.99 105.4 4. ˇcas [s] 442.73 5 106.71 102.9 5. ˇcas [s] 447.21 5 107.02 103.2 Povpreˇcje [s] 446.154 5.8 106.7 104.16
Tabela 4.4: ˇCasi izvajanja mutacijskega testiranja
Za podatke v tabelah 4.5 in 4.6 je treba poudariti, da so podatki za orodji PIT in Jumble nepopolni. Podatki orodja PIT so pravzaprav povpreˇceni podatki za orodje Eclipse IDE v ˇcasu, ko izvaja testiranje z uporabo orodja PIT. Zaradi njegove uˇcinkovitosti, ki je razvidna iz tabel 4.3 in 4.4, je bila koliˇcina zbranih podatkov zelo majhna in zato nepopolna.
Pri tem je bil upoˇstevan tudi podatek, da je poraba orodja Eclipse IDE v stanju pripravljenosti ≈ 1% za CPU in ≈ 1.3% za spomin. Ta deleˇz je bil
odˇstet, da bi dobil natanˇcnejˇsi podatek o raˇcunalniˇskih virih, ki jih porabi za izvajanje orodje PIT.
Pri orodju Jumble je priˇslo do pojava, ko se je ob doloˇcenih trenutkih ta izvajal v veˇc kot samo enem procesu na sistemu (Linux jedro je obravnavalo veˇc kot en proces, ki se je izvajal preko Java ukaza). Ta sekundarni proces je zavzel zelo malo raˇcunalniˇskih virov, zato so ti podatki lahko zavajajoˇci.
Standardna odklona sta bila zaradi tega pojava zelo velika (tabela 4.7). Tudi ob predpostavki, da so resniˇcne vrednosti porabe raˇcunalniˇskih virov proti zgornji meji, so le-te ˇse vedno med najmanjˇsimi. Ta pojav ni bil prisoten pri nobenem izmed drugih treh orodij.
µJava PIT Jumble Major 1. meritev [%] 2417.16 173.57 36.57 113.67 2. meritev [%] 2411.66 174.86 38.72 114.46 3. meritev [%] 2413.13 170 37.04 113.32 4. meritev [%] 2431.53 188.67 37.08 114.3 5. meritev [%] 2521.27 181.17 38.55 113.64 Povpreˇcje [%] 2438.95 177.65 37.592 113.88
Tabela 4.5: Povpreˇcna poraba CPU
µJava PIT Jumble Major 1. meritev [%] 6.72 0.53 0.21 2.43 2. meritev [%] 6.84 0.53 0.23 2.42 3. meritev [%] 6.44 0.52 0.2 2.42 4. meritev [%] 6.61 0.47 0.21 2.42 5. meritev [%] 6.3 0.5 0.22 2.4 Povpreˇcje [%] 6.58 0.51 0.214 2.418
Tabela 4.6: Povpreˇcna poraba spomina
Diplomska naloga 37 Poraba spomina Poraba CPU
AVG SD 0.412 45.726
Tabela 4.7: Standardna odklona porabe raˇcunalniˇskih virov za orodje Jumble
4.2 Konˇ cno ocenjevanje orodij
4.2.1 Funkcionalnost
Ocene v tabeli 4.8 za podlastnost Nabor Mutacijskih Operatorjev so bile doloˇcene glede na tabelo 3.1. Nobeno izmed orodij nima strogo doloˇcenega nabora MO, na katerega uporabnik nima vpliva, torej nobeno orodje ne spada v prvo skupino kriterija. PIT, ki spada v drugo skupino, ima sicer velik nabor MO, vendar uporabnik nanj nima velikega vpliva - dejansko zgolj z izbiro treh skupin, kjer zadnja predstavlja vse MO iz obeh drugih skupin.
Jumble, ki spada v tretjo skupino, ima na voljo samo sedem MO, vendar lahko uporabnik poljubno izbira med petimi izmed njih. µJava ima izmed vseh najveˇcji nabor MO. Med vsemi orodji je tudi edino orodje, ki ponuja MO na nivoju razredov, zato je tukaj uvrˇsˇcena v ˇcetrto skupino. Major je kljub manjˇsemu naboru MO uvrˇsˇcen v peto skupino, saj uporabniku ponuja moˇznost lastno definiranih MO, ki morajo ustrezati standardu Major-Mml formata [49].
MO 1 MO 2 MO 3 MO 4 MO 5
PIT Jumble µJava Major
Tabela 4.8: Tabela ocen za kriterij funkcionalnost ob upoˇstevanju nabora MO
REZ 1 REZ 2 REZ 3 Jumble Major µJava PIT
Tabela 4.9: Tabela ocen za kriterij funkcionalnost ob upoˇstevanju prikaza rezultatov
Podlastnost Primernost Rezultatov (tabela 4.9) predstavlja drugi del krite- rija funkcionalnosti. Ocenjuje, kako dobro orodje prikazuje rezultate MT (tabela 3.1) in kako primerljivo (korektno) orodje oceni TS. Kadar prever- jamo kakovost TS za neki P, ˇzelimo imeti ˇcim veˇcji MS. V naˇsem primeru pa iˇsˇcemo orodje, ki odkrije najveˇcje ˇstevilo pomanjkljivosti v testni TS. To pomeni, da ˇce orodje vrne niˇzji MS, v primerjavi z drugimi, je odkrilo veˇc pomanjkljivosti in tako uporabniku bolje omogoˇci izpopolnjevanje TS.
Orodje Jumble glede na ˇstevilo toˇck pripada drugi skupini, saj ne ponuja opisnih rezultatov pri izpisu v terminal. Ob izvajanju izpisuje stanje mutan- tov (slika 3.4), kjer opozori, ali je pri mutantu priˇslo do prekoraˇcitve ˇcasa, a se ta podatek ne nahaja v datotekah s podatki o izvajanju. Uporabnik tako dejansko ne ve, pri katerem mutantu je priˇslo do prekoraˇcitve ˇcasa. Jumble ponuja datoteko, kjer so naˇsteti vsi mutanti in konkretno njihove mutacije.
V datoteko doda tudi seˇstevek potrebnega ˇcasa za tvorbo mutantov, celotni ˇcas izvajanja MT in MS pa izpiˇse v terminal sistema. Zaradi nepopolnih podatkov, ki jih orodje nudi uporabniku, je bil umeˇsˇcen v to skupino, kajti brez roˇcnega ˇstetja ne gre. Kljub pomanjkljivi predstavitvi rezultatov ima primerljiv rezultat oziroma najde najveˇc potencialno neodkritih napak zno- traj naˇsega programa.
PIT v nasprotju z drugimi ne ponuja moˇznosti zapisa podatkov v avtomat- sko kreiranih datotekah. Vse informacije o rezultatih so le znotraj Eclipse IDE orodja. V Eclipse konzoli med izvajanjem izpisuje ˇcas vsakega mutanta in njegovo stanje, na koncu pa uporabniku izpiˇse ˇse skupni ˇcas izvajanja ter pregled nad statistko (recimo odstotek uniˇcenih mutantov pri vsakem MO).
Poleg tega se kreirata ˇse dve okni. Prvo vsebuje vse kreirane mutante, njihovo
Diplomska naloga 39 stanje po konˇcanem izvajanju ter opis mutacije, ki je bila nad tem mutantom izvedena. Uporabniku je priroˇcno tudi drugo okno, ki mu pove skupni MS ter MS za posamezne testirane Javanske razrede. Poleg tega vrne MS enak temu, kot ga vrne Jumble, torej odkrije najveˇcje ˇstevilo potencialno neodkri- tih napak v programu. To skupaj s prikazom rezultatov, ki je bolj podroben in celovit, kot ga nudi Jumble, orodje PIT uvrˇsˇca v najboljˇso skupino tega kriterija.
Major prav tako pripada najboljˇsi skupini. Uporabniku poda najveˇc podrob- nosti glede testiranih mutantov. Poleg pregleda mutacij za vsakega posame- znega mutanta (kjer je podano tudi konˇcno stanje mutanta) in preproste ˇcasovne analize (ˇcas priprave, ˇcas kreiranja mutantov, ˇcas izvajanja mu- tacijskega testiranja) uporabniku nudi podatke o tem, koliko mutantov je povzroˇcilo semantiˇcno napako, koliko mutantov je prekoraˇcilo ˇcas izvajanja, koliko mutantov je bilo uniˇcenih ali preˇzivelih, koliko mutantov so pokrili testi in koliko testov je bilo neuspeˇsnih med izvajanjem. Njegov rezultat je tudi primerljiv z orodjema Jumble in PIT, saj je bil v povpreˇcju le malo viˇsji.
µJava spada v drugo skupino kriterija, tako kot Jumble. Veˇcino rezulta- tov uporabnik dobi preko grafiˇcnega vmesnika. Tam vidi ˇstevilo uniˇcenih in preˇzivelih mutantov ter MS. Izpiˇse recimo, kateri mutanti so bili uniˇceni in kateri ne, same mutante pa si lahko uporabnik ogleda v drugem razdelku GUI. Prednost pred drugimi orodji je avtomatsko shranjevanje mutantov, saj ustvari datoteˇcno drevesno strukturo, v kateri so spremenjene datoteke iz- vornega programa, ki jih uporabnik lahko naprej poljubno uporablja. Kljub najveˇcjemu ˇstevilu tvorjenih mutantov je bil pri µJavi ohranjen najmanjˇsi deleˇz mutantov. To pomeni, da bi v primerjavi z ostalimi orodji odkrilo najmanj potencialnih neodkritih napak P (pomanjkljivosti v TS).
4.2.2 Zanesljivost
ZA 1 ZA 2 ZA 3 PIT Jumble µJava
Major
Tabela 4.10: Tabela ocen za kriterij zanesljivost
Pri tem kriteriju so se upoˇstevali izmerjeni podatki, orodja pa so bila razvrˇsˇcena (tabela 4.10) glede na lestvico iz tabele 3.2.
Za uvrstitev v tretjo stopnjo tega kriterija je vseh pet glavnih meritev (ˇcas tvorbe mutantov, ˇcas izvajanja MT, poraba spomina in poraba CPU), mo- ralo imeti mala odstopanja v primerjavi z drugimi orodji. V medsebojni primerjavi so odstopanja pri orodjih Jumble in Major manjˇsa kot pri orodjih PIT in µJava, zato sta bila razvrˇsˇcena viˇsje. Ker pa je bil Major edino ne- dosledno orodje glede MS, je bilo razvrˇsˇceno eno skupino niˇzje kot Jumble.
Ker nobeno orodje ni imelo velikih odstopanj med posameznimi izvajanji, ni nobeno uvrˇsˇceno v prvo skupino.
4.2.3 Uˇ cinkovitost
U ˇC 1 U ˇC 2 U ˇC 3 µJava Major Jumble
PIT
Tabela 4.11: Tabela ocen za kriterij uˇcinkovitost
Kriterij obravnava statistiˇcne podatke izvajanja z vidika koliˇcine virov, ki jih mora uporabnik imeti na voljo za nemoteno uporabo orodja (tabela 4.11).
Kriterij je definiran v tabeli 3.3.
Diplomska naloga 41 V tej kategoriji sta orodji Jumble in PIT v najboljˇsi skupini. ˇCeprav me- ritve za Jumble niso najbolj natanˇcne, je zgornja meja porabe CPU orodja ˇse vedno med manjˇsimi, skupaj s porabo pomnilnika. Njegovi izmerjeni ˇcasi so sicer primerljivi z orodjem Major, a jih to orodje doseˇze z manjˇso porabo raˇcunalniˇskih virov. PIT kljub malo veˇcji povpreˇcni porabi CPU svoje rezul- tate doseˇze v zdaleˇc najkrajˇsem ˇcasu in je zato uvrˇsˇcen v najboljˇso skupino.
µJava je tukaj del najslabˇse skupine. Razlog za to je v njeni veliki ˇcasovni zahtevnosti in koliˇcini porabljenih raˇcunalniˇskih virov, ki ni primerljiva z nobenim izmed drugih orodij.
4.2.4 Uporabnost
UP 1 UP 2 UP 3 Jumble µJava PIT
Major
Tabela 4.12: Tabela ocen za kriterij uporabnost ob upoˇstevanju zahtevnosti uporabe
Tabela 4.12 prikazuje razvrstitev za prvo podlastnost, ki definira kriterij upo- rabnosti. Obravnava preprostost uporabe orodja z vidika sploˇsnega uporab- nika (tabela 3.4). Jumble in Major sta tukaj del najslabˇse skupine. Jumble se sicer zaˇzene z uporabo enega samega ukaza, vendar je razumevanje nje- gove sintakse lahko teˇzavno za nekoga, ki ni veˇsˇc uporabe terminala. Upo- raba orodja Major zahteva uporabo veˇc ukazov, saj je vrstni red in pravilno (mogoˇce) nastavljanje ukazov lahko prav tako teˇzavno. To v povezavi s po- trebnim znanjem za Major-Mml zapis lastno definiranih mutacijskih opera- torjev pomeni, da njegova uporaba ni preprosta. µJava medtem od uporab- nika obiˇcajno priˇcakuje interakcijo z GUI, ki ga dobi preko ukaza v terminalu.
Ta ukaz je preprost in predstavljen v dokumentaciji. PIT spada v najboljˇso skupino, saj njegova celotna uporaba poteka znotraj Eclipse IDE, torej prav tako preko GUI.
DO 1 DO 2 DO 3 Jumble PIT Major
µJava
Tabela 4.13: Tabela ocen za kriterij uporabnost ob upoˇstevanju dokumenta- cije, ki je na voljo
Tabela 4.13 prikazuje ocene glede primernosti dokumentacije orodij, defini- rane v tabeli 3.4. Orodje Jumble je v najslabˇsi skupini, saj je njegova doku- mentacija omejena le na informacije, ki so na uradni spletni strani. ˇCeprav orodje nima veliko funkcionalnosti, so le-te omejene, saj se osredotoˇcajo na Eclipse vtiˇcnik, ki ni veˇc podprt. PIT in µJava sta v drugi skupini, saj imata bolj podrobno dokumentacijo. PIT ima podrobno opisano integracijo za razliˇcna javanska okolja ter povrˇsno dokumentacijo za uporabo vtiˇcnika.
Ponuja tudi podroben opis in primere za vse MO ter del s pogostimi vpraˇsanji glede uporabe. µJava ponuja zelo podroben opis korakov za namestitev in uporabo, tako za Linux kot za Windows operacijske sisteme. Major ima naj- bolj podrobno dokumentacijo. Ta obsega tako uporabo preko terminala, kot preko integracije v Java okolje Ant. Opisuje tudi vse vnaprej definirane MO, ter proces kreiranja lastnih skupaj s sintakso. Taka dokumentacija je zelo zaˇzeljena pri uporabi orodja.
4.2.5 Prenosljivost
PR 1 PR 2 PR 3
µJava Jumble PIT Major
Tabela 4.14: Tabela ocen za kriterij prenosljivost
Diplomska naloga 43 Tabela 4.14 obravnava kriterij prenosljivosti, kot je definiran v tabeli 3.5.
PIT je orodje, ki je integrirano v Eclipse IDE, zato zaseda mesto v skupini za najveˇc toˇck. Namestiti se ga da povsod, kjer se, da namestiti Eclipse IDE.
Njegova namestitev je tako tudi zelo preprosta in ni omejena s staro razliˇcico Jave. Namestitev Jumble je druga po zahtevnosti, saj zavzema prenos ene
*.jar datoteke. Je v drugi skupini, ker je njegova uporaba omejena na razliˇcico Jave 8 ali starejˇso, ki je sicer ˇse prosto dostopna in podprta. µJava in Major zasedata mesto v najslabˇsi skupini. Major predvsem iz razloga, ker je uporaba omejena na razliˇcico Jave 7 ali starejˇso, ki ni veˇc podprta in pre- nosljiva samo ˇse z uradne strani skupine Oracle [43]. Sama namestitev sicer ni zahtevna, saj so vse datoteke prenosljive v eni *.zip datoteki. Potrebna pa je namestitev sistemskih spremenljivk OS, ki za sploˇsnega uporabnika ni najbolj preprosta. Slednje pa velja tudi za orodjeµJava, kjer je treba v sis- temske spremenljivke dodati ˇse veˇc datotek, zato je tako ta proces ˇse dodatno zahteven.
4.2.6 Povzetek ocen
PIT Major Jumble µJava 4.13 3.33 3.67 2.75
Tabela 4.15: Tabela seˇstevkov ocen vseh orodij
V tabeli 4.15 so konˇcne ocene za vsa orodja glede na naˇcin seˇstevanja ocen, ki je definiran v poglavju 3.2. Orodje PIT je zmagovalec, kar je bilo tudi predvidljivo, saj je ˇse edino podprto orodje, ki je aktivno v razvoju in dobiva posodobitve (nobeno drugo ne deluje z razliˇcicami Jave 9 in naprej, PIT pod- pira tudi razliˇcico Jave 11). Ne glede na najmanjˇse ˇstevilo mutantov (tabela 4.1) dosega najboljˇse mutacijske rezultate. ˇCe bi normalizirali ˇstevilo testov, bi to pomenilo najveˇc odkritih pomanjkljivosti v TS. Kljub pomanjkljivosti glede izbire MO ima PIT veliko prednost pred ostalimi orodji v preprostosti in uˇcinkovitosti.
µJava je dosegla najmanjˇse ˇstevilo toˇck. Razlog je v zahtevnosti uporabe in namestitve ter predvsem neuˇcinkovitosti. Pri vseh kriterijih dosega pov- preˇcne ocene in ne izstopa na nobenem podroˇcju z izjemo velikega nabora MO ter prisotnosti MO na nivoju razreda. ˇZal oboje ne pripomore k boljˇsemu mutacijskemu rezultatu.
