För att validera alla kriterier förutom antalet stödjande programmeringsspråk kommer verktygen att analysera tre samlingar av programmeringsuppgifter studenter lämnat in. Uppgifterna kommer från en introduktionskurs i webbutveckling med fokus på backend-utveckling i Python. Kursen består av totalt sex inlämningsuppgifter där svårighetsgraden ökar gradvis.
Den första samlingen verktygen kommer att analysera innehåller 66 lösningar av den första programmeringsuppgiften i kursen. Uppgiften är väldigt trivial och innehåller därför flera kodstycken som är garanterade att finnas med i alla inlämningar. Detta då flera kodstycken delas ut i kombination med uppgiftens instruktioner. Kravet om att verktygen ska kunna exkludera baskod kommer därför att valideras med hjälp av den här samlingen. Utformningen på testet består av att verktygen analyserar samlingen två gånger. Den första gången utan och den andra gången med baskod. Den andra samlingen verktygen kommer att analysera består av 57 lösningar från den sjätte och sista inlämningsuppgiften i kursen. Denna inlämningsuppgift går ut på att studenten ska skapa en valfri CRUD-tjänst. Studentens inlämning kan därför bestå av flera Python-, HTML- och JavaScript-filer som är strukturerade i olika kataloghierarkier. De filer som är av intresse för att analyseras av verktygen är endast Pythonfilerna, vilka ansvarar för webbtjänstens backend-logik. Därför kommer denna samling att användas för att validera om verktygen klarar av att hantera flera filer som en inlämning.
Den tredje samlingen verktygen kommer att analysera består av sju plagiatversioner och en originalversion. Originalversionen är en slumpmässigt utvald students inlämning från den andra samlingen. Plagiatet i de sju versionerna baseras på de åtta typer av plagiat studenter kan begå enligt Martins m.fl. [9]. Dessa åtta metoder för plagiat listas tidigare i detta arbetes avsnitt 3.1.3. Fyra av de sju versionerna i samlingen tillämpar Martins m.fl.:s första, andra, tredje och sjunde variant av plagiat. De tre resterande versionerna är korrigerade till att kombinera två varianter med varandra. Den första kombinationen tillämpar Martins m.fl.:s andra och sjunde variant av plagiat. Den andra tillämpar deras andra och tredje variant av plagiat. Den tredje och sista kombinationen består av deras tredje och sjunde variant av plagiat. Syftet med samlingen är att säkerställa att verktygens detektering verkligen fungerar. JPlag kommer att analysera samlingen tre gånger. För varje gång ändras verktygets så kallade token-värde, vilket påverkar dess noggrannhet i jämförelserna av programmen [13]. Tokenvärdet kommer att testas med standardvärdet 12 följt av 6 och 18.
För att validera kvaliteten på resultatet från verktygen används information från litteraturstudien kombinerat med en subjektiv bedömning av användarupplevelsen. Denna bedömning grundar sig delvis i den information som hittats genom litteraturstudien, men tar också hänsyn till det som bearbetats under intervjuerna. Tiden det tar att analysera samlingarna för varje verktyg mäts också. Mätningen används sedan för att jämföra verktygen i studien mot varandra. Detta då det framkommer från intervjuerna att det inte får ta för lång tid. Ett annat krav som framkommer från intervjuerna är att verktyget ska hantera flera programmeringsspråk. För att säkerställa detta används litteraturstudien som referens. Anledningen till att använda Python för analysen i arbetet är att språket inte använts i tidigare studier. Genom att göra det i denna studie kan det försäkras att verktygen faktiskt klarar av att undersöka språket i fråga.
6 Diskussion av metodik för praktisk testning
I föregående sektion framkommer de viktigaste kraven ett verktyg bör uppfylla om det ska användas på ett universitet. Dessa krav användes till uttagningen av vilka verktyg som ska vidare undersökas. De verktyg som utsågs var JPlag och MOSS. Båda verktygen kommer därför att genomgå en testdel, för att kontrollera att de verkligen uppfyller kraven. Testdelen kommer även försäkra om verktygens faktiska funktion fungerar, vilket är att upptäcka plagiat i källkod. Den här sektionen kommer att behandla likheter och skillnader angående den valda testmetodiken jämfört mot tidigare forskningsarbeten.
Stora delar av testmetodiken i det här arbetet förhåller sig till den Hage m.fl. [4] använder i sitt arbete. Den delar även likheter med Martins m.fl. [9]. De gemensamma delarna i arbetena emellan är att författarna själva skapar egna kopior med olika varianter av plagiat verktygen får analysera. I det här arbetet baseras plagiatet i kopiorna på de metoder Martins m.fl. definierat. Valet till varför kopiorna inte baseras på Hage m.fl.:s definierade metoder beror på att de är mer fokuserade för programmeringsspråket Java. Martins m.fl.:s varianter av plagiat är mer generella än vad Hage m.fl.:s är, vilket innebär att de kan uppträda i en större omfattning programmeringsspråk.
De första tre av de sju kopiorna i den tredje samlingen tillhör de lexikala varianterna av plagiat [10]. De lexikala varianterna eller metoderna är de minst avancerade för en student att begå [9], vilket är skälet till varför de väljs ut. Det krävs ingen förståelse för koden eller programmet för att studenten ska kunna modifiera originalet till en kopia som lexikalt skiljer sig. Den fjärde kopian i den tredje samlingen baseras på Martins sjunde metod av plagiat [10]. Den tillhör bland de strukturella metoderna för plagiat, istället för de lexikala [10]. Motivet till varför denna variant också väljs ut beror på att studenten endast behöver se till att programmet behåller samma beteende som originalet [9], vilket gör metoden till en mycket förekommande typ av plagiat.
De stora likheterna i metodiken i det här arbetet jämfört med Hage m.fl.:s är att verktygen både genomgår en känslighetsanalys och appliceras på en samling av verkliga programmeringsuppgifter. Den största avvikelsen är att verktygen också kommer att analysera en samling av introduktionsuppgifter i det här arbetets testdel. Denna del går ut på att undersöka verktygens egenskap för att exkludera baskod från inlämningsuppgifterna.
Sammanfattningsvis delar det här arbetets testmetodik flera likheter med den metodik Hage m.fl. och Martins m.fl. använder i sina forskningsartiklar. Metodiken i detta arbete avviker också på ett eller flera plan jämfört med tidigare använda metodiker. Anledningen till varför metodiken i det här arbetet har sina avvikelser beror på en sak. Det är att målet med testningen inte är detsamma. Testningen i det här arbetet fokuserar inte på att mäta hur effektiva verktygen är på att upptäcka olika sorters plagiat. Den fokuserar istället på att skapa en grund av argument för vilket verktyg ett universitet skulle ha störst användning av. Denna grund skapas genom att validera om verktygen uppfyller de viktigaste kraven intervjuerna tillsammans med litteraturstudien frambringat, ett verktyg bör uppfylla om det ska användas på ett universitet.
Med JPlag är det möjligt att ställa in verktygets känslighet genom att ändra värdet på minsta matchlängd för de tokens verktyget genererar. Det är tidigare känt att ett lägre tokenvärde upptäcker fler likheter i den källkod verktyget analyserar gentemot
ett högre värde [13]. Beroende på den källkod verktyget analyserar ökar också risken för fler false-positives vid ett lägre tokenvärde [13]. Valet till att testa JPlag med tre olika token-värden är för att undersöka hur effektiviteten för att upptäcka de olika varianterna av plagiat påverkas.
7 Resultat från den praktiska testningen
I den här sektionen kommer resultatet från analyserna av de tre samlingarna med inlämnade programmeringsuppgifter att presenteras. De tre samlingarna är som tidigare nämnt i avsnitt 5.2, utformade för att validera verktygen JPlag och MOSS. Valideringen går ut på att undersöka om verktygen uppfyller de framtagna kriterierna ett verktyg bör tillgodose för effektiv användning på ett universitet. Dessa kvalitativa kriterier är, som tidigare nämns i avsnitt 5:
● Kvaliteten på resultaten ● Uteslutning av baskod ● Inlämning som grupp av filer
● Att verktyget kan hantera flera programmeringsspråk
Den praktiska testningen undersöker i störst utsträckning det andra och det tredje kriteriet i ovanstående lista. Dessa två kriterier valideras med hjälp av att låta verktygen analysera den första och den andra samlingen av inlämningsuppgifter. Det första och fjärde kriteriet kan däremot inte valideras helt och hållet med hjälp av den praktiska testningen. Det första kriteriet blir mer av en diskussionsfråga, där presentationen av resultatet bedöms subjektivt senare i arbetet. De subjektiva åsikterna kommer också att jämföras med Hage m.fl.:s [4] betygsättning på JPlag’s och MOSS’s visualisering av resultatet. För att säkerställa det fjärde kriteriet, vilket är att verktyget stödjer flera programmeringsspråk, används framför allt litteraturstudien som referens.
Den tredje samlingen verktygen analyserar fokuserar inte på att validera något av de ovanstående kriterierna. Den är istället till för att säkerställa att verktygens detektering av plagiat verkligen fungerar. Samlingen innehåller, som tidigare nämns i avsnitt 5.2, en slumpmässigt utvald students inlämningsuppgift från den andra samlingen tillsammans med sju kopior. De sju kopiorna är justerade till att innehålla olika varianter eller kombinationer av plagiat. Verktygen kommer då att klassificera hur lika dessa kopior är jämfört med originalversionen. Detta gör det möjligt att kunna säkerställa om verktygens detektering fungerar eller inte för olika metoder av plagiat samt för källkod skriven i Python.