AUTOMATIKUS TESZTELŐ RENDSZEREK SZEREPE A TÖMEGKÉPZÉSBEN. Espák Miklós Debreceni Egyetem, Informatikai Kar. Összefoglaló

Informatika a felsőoktatásban 2008

Debrecen, 2008. augusztus 27-29.

AUTOMATIKUS TESZTELŐ RENDSZEREK SZEREPE A TÖMEGKÉPZÉSBEN AUTOMATIC TEST SYSTEMS IN MASS EDUCATION

Espák Miklós Debreceni Egyetem, Informatikai Kar Összefoglaló A tömegképzés egyre nagyobb kihívások elé állítja az oktatókat. Ma már nem lepődünk meg, ha egy tantárgyat egyszerre akár félezer hallgató próbál meg teljesíteni. A számonkérések összehangolása, és követelmények egységesen tartása komoly szervezettséget igényel. A hallgatók létszámától független probléma, hogy bizonyos gyakorlati ismeretek elsajátítása eleve nem lehetséges a korlátozott heti óraszámban. Ezeknél a tárgyaknál különösen fontos az otthoni munka elősegítése. Ez rendszeresen kiadott, egységes házi feladatokkal, és otthonról hozzáférhető, könnyen feldolgozható tananyagokkal, útmutatókkal valósítható meg. Tanszékünkön kialakítottunk egy olyan infrastruktúrát, amelyben a házi feladatok kiadása és számonkérése egységes módon, elektronikus úton történik. A rendszert számos, programozással foglalkozó tantárgynál és programozói versenyre felkészítésben is használjuk. Mivel a rendszer kiemelten fontos célja az otthoni gyakoroltatás, ezért az ellenőrzéshez használt tesztelő program a hallgatók számára is elérhető, és a kiadott feladatokhoz már a kitűzéskor mellékelünk teszteseteket is, melyekkel beadás előtt bárki ellenőrizheti a megoldását. Bár nem garantálható, hogy mindenki saját, önálló megoldását adja be a feladatokra, plágium-ellenőrzéssel és esetleges programvédésekkel ki lehet szűrni a nem saját munkák túlnyomó többségét. A rendszer csak szabad szoftverre épül, és viszonylag szerény hardver erőforrások mellett is üzembe helyezhető.

Kulcsszavak tömegképzés, tesztelő rendszer, házi feladat, plágium

Abstract The challenge of education of student masses tends to be more and more serious. You will not be surprised today when even a half thousand students enroll for a course. The coordination of exams and keeping the requirements unified presses for a high level of organization. Independently from the headcount of students, it is not possible to get practice at some fields during the limited number of lessons per week. In the case of these courses it is especially important to support the students' work at home. This can be achieved by regularly delivered, uniform home works, and with curricula, guides available from home. At our department we have developed an infrastructure, in which the publication and evaluation of home works can be performed in a uniform, electronic way. The system is used in several courses about programming languages, and also for preparation of students for programming contests. As the main purpose of the system is to get the students practice at home, the test software used for the evaluation is available for the students, and test cases for the exercises are also available from the time the home work is delivered, using which anybody can test their solution before submitting it. Although it cannot be guaranteed that every student will submit his/her own solution, but using plagiarism-detection and incidental program defenses the majority of collective works can be filtered out. The system relies on open source software exclusively, and can be deployed even on weak hardware resources.

Keywords mass education, test system, home work, plague

1



1. Bevezetés A bolognai folyamat megnövelte a diákok szabadságát, és lehetővé tette, hogy nagy tömegben kerüljenek be a felsőoktatásba. Az angolszász típusú piramisszerű, több lépcsős rendszer (BA, MA, PhD) lehetővé teszi nagy tömegek befogadását, és a szelekciót nem annyira a felvételi előtt, mint inkább a bekerülés után végzi el. A hirtelen megnövekedett hallgatói tömegek viszont nagy kihívások elé állítja az oktatókat. Megszokottá vált, hogy egyes tárgyakból rendszeresen akár félezernél is több hallgató oktatását kell megoldani egy kurzus során. Ezen hallgatók számonkéréseinek összehangolása, a leadott anyag és követelmények egységesen tartása komoly szervezettséget igényel. A hallgatók létszámától független probléma, hogy bizonyos gyakorlati ismeretek elsajátítása eleve nem lehetséges a korlátozott heti óraszámban. Ezeknél a tárgyaknál különösen fontos az otthoni munka elősegítése. Ez rendszeresen kiadott, egységes házi feladatokkal, és otthonról hozzáférhető, könnyen feldolgozható tananyagokkal, útmutatókkal valósítható meg. A tapasztalat azt mutatja, hogy az otthoni feladatoknak maga a kitűzése még részletes tananyagok mellett sem jelent kellő motivációt a hallgatók jelentős része számára. A feladatok számonkérése viszont a nagy hallgatói létszám mellett viszont nem egyszerű. Szerencsére az otthoni munka számonkérése megfelelő infrastruktúra kialakításával és automatizált tesztelő rendszerek használatával megoldható. Mivel a házi feladatoknál nem garantálható az önálló megoldás, azok eredményét nem lehet fenntartás nélkül, egy az egyben elfogadni. A másolásokat plágium-ellenőrző szoftverrel ki kell szűrni, és zárthelyi dolgozatokat továbbra is kell tartani, bár ezek szerepe csökkenhet, hiszen főképpen azt kell fölmérniük, hogy az illető valóban szerzett-e gyakorlatot a házi feladatok megoldásával. 2. Követelmények összehangolása Amint említettem, a hallgatói létszám az első- és másodéves alapozó tárgyaknál igen magas, főleg, mivel ezeket több szakon is hallgatják. A Magas szintű programozási nyelvek 1 tárgyat a 2007/08 tanév 2. félévében közel négyszáz olyan hallgató vette fel, aki a gyakorlatot még nem teljesítette, de korábbi éveken ennél magasabb létszámok is előfordultak. Ez ebben a félévben húsz gyakorlati csoportot jelentett. Mivel a gyakorlatvezetők nagy része a tehetséges felsőbb éves hallgatók közül kerül ki, ezért a körük évről évre változik. Ilyen körülmények között igen nagy hangsúlyt kap az egységes követelmények, számonkérések kialakítása a hallgatók felé, valamint teendők szétosztása a gyakorlatvezetők között és a rendszeres kommunikáció. Jelenleg rendszeres számonkérésekkel próbáljuk motiválni a hallgatókat a folyamatos tanulásra. Ennek eszközei a közös, egész évfolyamot érintő zárthelyi dolgozatok, és a szintén egységesen kiadott és számon kért házi feladatok. Jelen cikk tárgyát az utóbbiakhoz kialakított infrastruktúra képezi. Könnyen belátható, hogy ilyen volumennél a házi feladatok „kézi” feldolgozása irdatlan terhet jelentene, ezért olyan infrastruktúrát kellett kialakítani, amelyben a megoldások automatikusan tesztelhetők. Az elsődleges szempont ugyanakkor a rendszer kialakításakor nem a számonkérés, hanem az önálló gyakorlás elősegítése volt. 3. Korábbi rendszerek

2



Az első próbálkozás egységes tesztelő rendszer alkalmazására a PCRM nevű tesztelő szoftver volt. A program Gunda Lénárd korábbi hallgatónk fejlesztése, amely azelőtt kitűnően vizsgázott az ACM versenyek helyi fordulóinak lebonyolításánál (Kósa et al., 2005, 2006). A program a beadott megoldásokat e-mailben várja, a kapott levelekből a tárgy vagy a csatolt állomány neve alapján megállapítja, hogy az melyik feladat megoldása, a forrást lementi, teszteli az előre elkészített tesztesetekre, végül eredményt generál HTML oldalak formájában. A program nyelve C++, az nyílt forráskódú és jól dokumentált. Mivel a szoftver kifejezetten ACM versenyekhez készült, ezért igényelt némi módosítást, hogy házi feladatok ellenőrzéséhez is alkalmazható legyen. Ezeket a szerző el is végezte. Sajnos rengeteg problémánk adódott ezek után is. Ezek túlnyomó része abból adódott, hogy az e-mailes beküldés rendkívül kiszámíthatatlannak bizonyult. Ugyan a szoftver küldött válaszlevelet a beküldés sikerességéről, ezekre a hallgatók sokszor nem figyeltek oda. Gyakran előfordult, hogy a tárgy megadása eleve hibás volt, vagy a levélszemétszűrő módosította a tárgyat, ami miatt a PCRM nem ismerte fel, melyik feladat megoldása lenne az. De a legnagyobb tömegben az okozott problémát, hogy a hallgatók legtöbbje megbízhatatlan ingyenes levelezőrendszereket illetve elavult levelezőprogramokat használt. Ezek sokszor hiányos módon töltötték ki a levél fejlécét, ami miatt a PCRM nem tudta eldönteni, melyik csatolt fájl tartalmazza a forrást. Az egyik feladatsor beküldési határideje körül a [freemail] rendszer a levelek kb. egyharmadánál a csatolt szöveges fájlokhoz egy változó méretű bináris adatot toldott, ami miatt a lementett állományok természetesen lefordíthatatlanná váltak. A hallgatók egyharmada ekkor ez a levelezőrendszert használta, és mivel minden feladat megoldását külön levélben kellett feladni, kb. 300 hibás forrásprogramot kellett megtalálni és a végükről kivágni a bináris részt. A másik nagy probléma a rendszerrel annak zárt volta volt. Ugyan a PCRM nyílt forrású, otthoni beüzemeléséhez legalább egy POP3 szervert kell telepíteni. Ugyan értékelés után az összes tesztesetet közzé tettük, a hallgatók az esetlegesen nagy számú tesztesetre csak kézzel tudták lefuttatni a programjaikat saját platformjukon. Ez rengeteg eltérést okozott az általunk kapott eredményhez képest, aminek az oka rendszerint az volt, hogy a különböző platformokon másképp reagáltak a programok pl. az inicializálatlan változókra, más kapcsolókat használtak a fordításhoz stb. Az említett és egyéb problémák miatt rengeteg reklamáció érkezett, amik feldolgozása maga is időt rabló volt. A sok probléma és a gyenge eredmények miatt a házi feladatok eredménye végül nem játszott döntő szerepet az aláírások megítélésében. A visszajelzések rendkívül vegyesek voltak. Sokaknak segítettek a rendszeres otthoni házi feladatok (kéthetente, összesen hat feladatsor), de számos hallgatónak kedvét szegték a jelentkező technikai problémák és a nem várt kudarcok a teszten. 4. Nyílt tesztelő rendszer A szerzett tapasztalatokból kiindulva – egy év kihagyás után – nekiláttam egy olyan tesztelőrendszer kialakításának, amely mentes a korábbi problémáktól. A követelmények a következők voltak:  

egységesség: a hallgatók azonos körülmények között, ugyanazzal a tesztelővel ellenőrizhessék a programjaikat, mint amivel a gyakorlatvezetők teszik ezt. nyitottság: a rendszer legyen a hallgatók számára nyitott, vagyis pontosan ismerhessék a tesztelés menetének részleteit.

3


  4.1.


hordozhatóság: a tesztkörnyezet otthon is egyszerűen kialakítható legyen. rugalmasság: a rendszer a későbbi igényekhez könnyen igazítható legyen. A tesztkörnyezet kialakítása

Az egységesség követelménye miatt egy referencia tesztkörnyezetet kellett kialakítani egy olyan kiszolgálón, amelyre a hallgatók bejelentkezhetnek és parancsokat futtathatnak. Mivel eleinte nem állt rendelkezésre dedikált gép a feladatra, ezért a tanszék szerverén, viszonylag szűk erőforrások mellett kellett kiépíteni a környezetet. 4.2.

Az infrastruktúra alapjai

A rendszer számára eleinte a tanszék bizonyos feladatait ellátó, Debian GNU/Linuxot futtató Pentium 4 számítógép volt elérhető. Bár később a processzor sem bizonyult gyorsnak a beadott megoldások kötegelt tesztelésekor, a szűk keresztmetszetet mégis a kevés memória (1 GB) jelentette. Biztonsági okokból nem szerettem volna a hallgatóknak a munkatársakéhoz hasonló felhasználói fiókot adni, ezért elkülönített környezetet kellett kialakítani. A megoldást a chroot adta. A parancs segítségével egy felhasználó megváltoztathatja önmaga (parancsértelmezője) számára a fájlrendszer gyökérpontját. Így, ha az eredeti fájlrendszer egy külön könyvtárában elhelyezünk egy minimális, de működőképes Debian rendszert, akkor már csak azt kell megoldani, hogy a hallgatók bejelentkezve ezt a könyvtárat lássák az állományrendszer gyökereként. Az ilyen rendszert börtönnek (angolul: jail) nevezik. Szerencsére ezen feladatok megoldására voltak kész Debian csomagok. A Debian alaprendszer telepítését a debootstrap paranccsal, a bejelentkezések átirányítását a börtönbe pedig a libpam-chroot nevű PAM modullal lehetett elvégezni. A rendszer előnye, hogy takarékosan bánik az erőforrásokkal, ugyanakkor viszonylag biztonságos. A takarékosság abban nyilvánul meg, hogy nem szükséges külön memóriarészt elkülöníteni a tesztkörnyezet futtatásához, és nem kell külön kernelt futtatni sem. A biztonság viszont kimerül annyiban, hogy a felhasználók nem látják a teljes fájlrendszert, viszont a külső rendszerben futó folyamatokat igen. 1 A rendszer hátránya a megnövekedett adminisztráció. A felhasználókat a külső rendszeren és a börtönben egyaránt létre kell hozni, és gondoskodni kell arról hogy a két felhasználói adatbázis szinkronban legyen, és a megfelelő felhasználók a börtönbe kerüljenek. Ügyelni kell arra is, hogy a külső rendszer kernel moduljai mindig elérhetők legyenek a börtönben is. Miután a számítógép erősebb hardvert kapott, az adminisztrációs terhek csökkentése végett külön virtuális gépet alakítottam ki a XEN segítségével. Ennek az előnye, hogy a hallgatói szerver lényegében teljesen függetlenné vált a tanszéki feladatokat ellátó operációs rendszertől, bár azonos hardveren futott azzal. A virtuális gép teljesen önálló fájlrendszerrel, felhasználói adatbázissal, folyamatkezeléssel és hálózattal rendelkezik. Ennek a megoldásnak egyetlen hátránya az volt, hogy a még mindig szűkös memóriát meg kellett osztani a két operációs rendszer között, és sajnos előfordult, hogy a beadási határidő előtti nagy rohamban a rossz elosztás miatt a virtuális gép kifogyott a memóriából.

1 A C programok futtatásához ugyan nem, de Java programokéhoz szükséges a /proc könyvtár felcsatolása. Bizonyos biztonsági ellenőrzésekhez (pl. hogy egy szkript megállapíthassa, hogy ki futtatja), szintén szükséges a proc fájlrendszer.

4



Később – a Sun Microsystems jóvoltából – sikerült hozzájutnunk egy szerverhez, amely átvette a tanszéki szerverünk e feladatát, ideális körülményeket biztosítva a hallgatók gyakorlásához. 4.3.

A tesztkörnyezet

A tesztkörnyezet szabad szoftvereken alapul. Mivel a nyitottság és a rugalmas bővíthetőség fő követelmények voltak, ezért a tesztelő alapjául az egyik legelterjedtebb szkriptnyelvet választottam, a GNU/Linux rendszerek alapértelmezett parancsértelmezőjét, a Bash-t. Ennek számos előnye van egy fordítóprogramos megoldással szemben. Egyrészt a kód nyitott, a módosítások gyorsan elvégezhetők. Másrészt, a shell szkriptekből a Linux parancsok bármelyike könnyedén és hatékony módon meghívható, és ezek palettája igen gazdag, egyúttal rendkívül rugalmasan kombinálhatók. A tesztelést a test.sh szkript végzi. A szkript a munkakönyvtárban elhelyezett, illetve paraméterként megadott programforrásokat teszteli. A tesztelés menetét egy naplóállományba írja. A tényleges tesztelést csak akkor végzi el a szkript, ha nincs a forrásnál újabb napló, egyébként a friss napló végén szereplő eredményt olvassa ki. A tényleges tesztelés a forrásfájlok lefordításával indul. Ezután a szkript futtatja a binárist az összes tesztesetre. Az egyes tesztesetekre végzett sikeres futtatások után az eredmény ellenőrzése történik. Ha egy tesztesetre az ellenőrzés sikertelen eredményt ad, akkor a tesztelés véget ér. A fordítást, a futtatást és a kimenet ellenőrzését a compile.sh, run.sh illetve check.sh szkriptek végzik. Ezeket a tesztelő először a feladat bin alkönyvtárában keresi, így a tesztelővel azonos könyvtárban megadott alapértelmezett változatok az adott feladat igényeink megfelelően átdefiniálhatók. A fordítást végző compile.sh paraméterei a lefordítandó források állománynevei. Visszatérési értéke sikeres fordítás esetén 0. A futtatást végző run.sh paraméterei a teszteseteket tartalmazó könyvtár és a teszteset száma. Visszatérési értéke nem létező teszteset esetén -1, egyébként a program visszatérési értéke. Az ellenőrzést végző check.sh a program kimenetét a tesztesethez megadott összes lehetséges kimenettel összeveti. Paraméterei a program kimenetét tartalmazó állomány, a teszteseteket tartalmazó könyvtár és a teszteset száma. Visszatérési értéke 0, ha a program kimenete egyezik valamelyik elfogadott kimenettel, egyébként 1. A tesztesetek bemenetét és argumentumait testN.in és testN.args alakú névvel kell elhelyezni közvetlenül a feladat könyvtárának test alkönyvtárában. A tesztesetek számozása (N) 1-től indul, és folyamatos. Az I-ik tesztesetnél a program bemenete testI.in lesz, parancssori argumentumait pedig a testI.args állományból kapja. A testI.in és a testI.args közül legalább az egyiknek léteznie kell. A tesztesetek elfogadott kimeneteit testN.out illetve testN-M.out nevű állományokban kell elhelyezni, ahol N a teszteset száma, M pedig tetszőleges. A szkript paraméterei a feladat könyvtára és a tesztelendő források nevei. Ez elhagyható, ekkor a munkakönyvtárban lévő összes forrásfájl tesztelésre kerül. A test.sh visszatérési értéke jelzi, hogy a program átment-e a teszten (0), nem létezik-e (1), fordítási hibát ad-e (3), érvénytelen memóriahivatkozás miatt szakadt-e meg (139), ki lette lőve (137) stb. Ez az egyszerű szkriptrendszer rendkívül rugalmas. Mivel a fordítást, a futtatást és az ellenőrzést végző szkriptek akár feladatonként egyediek lehetnek, ezért egyszerűen beállíthatók bizonyos korlátok a feladat futtatására pl. az ulimit paranccsal. A parancsot időkorlát és néha memóriakorlát beállítására használjuk, hogy kiszűrjük a végtelen ciklusokat

5



és bizonyos megoldási módokat. Az időkorlátot áthágó programok kilövési jelzéssel (137) terminálnak. 4.4.

Felhasználók, védelem

A szerveren minden felhasználó saját fiókkal rendelkezik, amelyről elérheti a teszteléshez szükséges parancsokat. Kezdetben ezeket minden félév elején a tanulmányi rendszerből gyűjtött tantárgyfelvételi listák alapján hoztam létre, egy közös kezdőjelszót beállítva mindenkinek, amelyet az első bejelentkezésükkor meg kellett változtatniuk. A chrootolt környezet miatt a felhasználók később nem tudták megváltoztatni a jelszavukat, de a gyakorlatvezetők bármikor vissza tudták állítani valaki kezdőjelszavát. Az adminisztráció további egyszerűsítése végett a szerveren már nincsenek lokális felhasználók a hallgatók számára, ehelyett az autentikációt az Egyetem központi LDAP szervere végzi, így a hallgatók ugyanazzal a névvel és jelszóval tudnak bejelentkezni, amellyel például a tanulmányi rendszert érik el. Mivel a tesztrendszert már több tantárgyhoz is használják, ezért az egyes tárgyakhoz van egy-egy adminisztrátori fiók is (pl. prog1zsuri). Ezek tartalmazzák az adott tantárgyhoz kiadott feladatokat, és ide kerülnek az azokra beadott megoldások is. A feladatok kiértékelése is itt történik. Ezekhez az adott tárgy gyakorlatvezetői hozzáférnek, így el tudják végezni egyegy feladatsor teszteseteinek összeállítását és a beadott megoldások határidő utáni kiértékelését. Az egyes tantárgyakhoz tartozik egy-egy felhasználói csoport is (pl. prog1), amelybe a felhasználókat a félév elején vesszük fel kötegelten, de később a gyakorlatvezetők is fel tudnak a csoportjukba felhasználókat. Ez azért is fontos, mert ugyan az autentikációt távoli szerver végzi, de a gépre csak azok tudnak bejelentkezni, akik tagjai valamelyik helyi felhasználói csoportnak. Ez biztonsági okokból is fontos, mivel így a felhasználók száma a minimálisan szükségesre korlátozható. Mivel a felhasználók száma nagy, és a külső autentikáció miatt nem tudjuk garantálni, hogy a jelszavuk kellően erős, ezért az ún. bruteforce támadások ellen a fail2ban programmal védekezünk. Ezzel óvatosan kell bánni, ugyanis az alapbeállításai agresszívek. Ha egy számítógépes labor NAT mögött van, akkor annak összes számítógépe a szerver számára ugyanazon IP címmel látszik, így ha több hallgató egymás után eltéveszti a jelszavát, akkor az egész labor kapcsolata percekre megszűnhet a szerverrel. A biztonsági kérdések másik köre a tesztelő rendszer kijátszása elleni védekezés. Ennek legfontosabb eleme a jogosultságok megfelelő szabályozása és a szkriptekbe épített ellenőrzések, amik segítségével mindenki csak a saját nevében tud programot beadni, és a saját eredményét képes lekérdezni. 5. Gyakorlás és számonkérések Jelenleg egy félév során három alkalommal tűzünk ki házi feladatsort, melyek közül az utolsó kettő zárthelyi dolgozatot előz meg. A házi feladatok előre deklaráltan úgy vannak összeállítva, hogy a dolgozatra felkészülést segítsék. A feladatsorok összeállításának, a tesztesetek elkészítésének és a határidő utáni ellenőrzésnek a feladata a gyakorlatvezetők között van felosztva. Mivel a rendszer már harmadik éve üzemel, a gyakorlatvezetők nagy része ismeri azt a „másik oldalról”. A rendszer felhasználói (hallgatók) és adminisztrátori (oktatók) dokumentációja tanszékünk wiki oldalán érhető el. A hallgatóknak szóló információk mellé kerülnek fel a feladatsorok. A wiki szerepe itt az, hogy egyszerűen, böngészőn keresztül szerkeszthető oldalakat ad, jogosultságkezeléssel és verziókövetéssel.

6



Így a gyakorlatvezetők a megfelelő jogosultság birtokában egyszerűen beszerkeszthetik és publikálhatják a feladatsorokat, és azok esetleges idő közbeni változásai (pl. értelmezési problémák miatt) a hallgatók számára nyomon követhetők. A feladatokhoz kitűzéskor tesztesetek is készülnek, melyek publikusak. A hallgatók a szerveren két egyszerű paranccsal tudnak programot tesztelni, illetve beadni:  prog1-teszt feladat [forrás]...  prog1-bead feladat [forrás]... A parancsok egyetlen kötelező paramétere a feladat neve (pl. 2/1), további paraméterekként megadhatók forrásfájlok, de alapértelmezetten az aktuális könyvtárban talált összes forrás tesztelésre illetve beadásra kerül. (Az egyéni felhasználói fiókok miatt a felhasználónevet nem kell átadni.) A tesztelő részletes naplót készít, amiben mindig megjelenik a hiba oka: hibás kimenetnél az eltérés a várt kimenethez képest (diff), érvénytelen memóriahivatkozás esetén a hiba jellege és a bekövetkeztekor érvényes hívási lánc (valgrind). Igyekeztünk megelőzni az esetleges figyelmetlenségeket, ezért a beadó szkript figyelmeztet és megerősítést kér, ha a hallgató előzetesen nem tesztelte a beadni kívánt programját, vagy nem arra a feladatra tesztelte, amire be kívánja adni. Tehát a hallgatók az előzetesen kiadott tesztesetekkel gyakorolhatnak közvetlenül a szerveren, de azok és a test.sh letöltésével akár otthon is. A határidő utáni teszteléshez új teszteseteket készítünk. Ezek jellege nem tér el a korábbiaktól, a cél velük csupán az, hogy a hallgatók valóban a feladatot, és ne a tesztesetet akarják megoldani. Azért, hogy a régi és új teszthalmaz azonos jellegű legyen, a tesztinputokat leggyakrabban programmal generáljuk, az outputok előállításához pedig referenciamegoldást készítünk. Így az eredmények közlésekor egyúttal a referenciamegoldásokat is közölni tudjuk. Még így is gyakran előfordul, hogy valamely program az előzetes teszteseteken átmegy, a véglegeseken pedig nem. Beadási határidő után ezek a programok még egy hétig javíthatók. Fontos, hogy a végleges teszteket is előre el kell készíteni, így az értékelés már a beadási határidőt követő napon elvégezhető. A kötegelt ellenőrzésre, az eredmények generálására és lekérdezésére külön szkriptek szolgálnak. Az adatok szöveges fájlokba (CSV) kerülnek. A zárthelyi dolgozatok eredményét a gyakorlatvezetők szintén ilyen formában készítik el, és töltik fel a szerverre. Így a hallgatók a prog1-eredmeny paranccsal az összes eredményüket lekérdezhetik. A másik előnye a CSV-nek, hogy egy egyszerű Python szkripttel az eredmények összesíthetők és Excel fájlformátumba alakíthatók. Az egész évfolyamon egységes feladatok azért is előnyösek, mert a hallgatók könnyebben tudják egymást is segíteni. A tantárgyhoz kapcsolódó webes fórumok igen aktívak. 6. Plágiumellenőrzés A házi feladatoknál nyilvánvalóan nem garantálható, hogy azok valóban a hallgatók önálló megoldásai. Bár azt nem védhetjük ki, hogy valaki külső forrásból származó programot adjon be, de a beadott megoldások között az egyezőket ki tudjuk szűrni egy plágiumellenőrző programmal. Erre a JPlag nevű, webszolgáltatásként működő szoftvert használjuk. A JPlag használata minimális előkészítést igényel (ki kell gyűjteni mindenkinek az utoljára beadott megoldását), és a beadott programokat páronként összehasonlítva HTML oldalak formájában generálja az eredményt, melyeken a megadott mértékű hasonlóságot mutató programok összevethetők. Főleg az egyszerűbb feladatsoroknál lehetnek véletlen egyezések, ezért a

7



pusztán a hasonlóság mértéke alapján nem lehet visszacsatolni a kapott eredményeket. Ezért azokat ismét feldolgozzuk, és megkeressük, hogy kinek kivel hány programja egyezett a kritikusnak vélt mértékben. Ha valakinek ugyanazzal a pár emberrel egyezett több programja is, akkor nagy bizonyossággal mondható, hogy másolás történt. Az egyszerű programok véletlenszerű egyezéseinél ugyanis sok ember programja egyezni szokott, viszont a különböző feladatoknál más és más embereké. A páronkénti kritikus egyezések számának kigyűjtése Python szkripttel történik a JPlag eredménye alapján. A szkript kigyűjti azok nevét, akiknél többszörös egyezés volt kis számú emberrel. Ezeknek a hallgatóknak a következő pár hétben meg kell védeni a beadott programjaikat, különben a feladatsorral szerzett összes pontjuk elvész. 7. Felhasználás A tesztkörnyezetet jelenleg a Magas szintű programozási nyelvek 1 (C), Magas szintű programozási nyelvek 2 (Java, C#) és a Programozás labor (C++) tárgyakhoz használjuk változatlan formájában, és programozási versenyekre való felkészítéshez (az előbbieken túl még Pascal) használjuk egy kissé módosított változatát. A módosításra azért volt szükség, mert versenykörülmények között nincsenek előre közzétett tesztesetek, és a tesztelést sem a versenyző végzi, hanem a zsűri ellenőrzi a beadás után közvetlenül a programokat. Hasonló okból a versenyzők nem kaphatják meg a teszt részletes kimenetét, csupán a végeredményt. Mindezek a igen kevés, gyorsan elvégezhető korrekciót igényeltek a beadást végző szkripten (a szkript végén végre kellett hajtani a tesztet). A tesztkörnyezet a talált forrásállományok kiterjesztése alapján választja ki a fordításhoz és futtatáshoz szükséges parancsokat. Ezidáig C, Java, C#, C++ és Pascal nyelvű programokat teszteltünk, de a lista könnyedén bővíthető. Az említett nyelveket a JPlag is támogatja. A C# programokhoz a Mono környezetet használjuk. Ugyanezen a hallgatói szerveren folyik Assembly (HLA) oktatás is, amely szintén erre az infrastruktúrára épül, de egyéni tesztelő rendszert használ, aminek az oka, hogy a feladatok nem közösek, hanem személyre szabottan generáltak. 8. Konklúzió A hallgatói létszám növekedésével a követelmények és a számonkérések egységben tartása egyre nagyobb szervezettséget igényel. Mivel a programozás elsajátítása kizárólag sok gyakorlással történhet, ezért a hallgatókat rá kell venni a folyamatos otthoni munkára. Ezt otthoni munkát próbáltuk meg elősegíteni azzal, hogy egy egységes tesztkörnyezetet teremtettünk, amely otthonról is elérhető, vagy könnyen reprodukálható. Ebben a hallgatók ellenőrzött körülmények között tudnak gyakorolni, ugyanis az előre elkészített tesztesetek és a részletes tesztelési napló segít a hibák felderítésében. A tapasztalat alapján pusztán a házi feladatok kiadása nem jelent kellő motivációt a hallgatók számára, ezért meg kell oldani azok számonkérését is. Ekkora tömegnél ez elképzelhetetlen valamilyen automatizmus nélkül. Az egységes tesztkörnyezet ebben is segít. A hallgatók ugyanitt beadhatják a programjaikat, amik határidő után kötegelten ellenőrizhetők, és belőlük eredmény generálható. A rendszer bevezetése óta a zárthelyi dolgozatok minősége érezhetően javult.

8



A tárgyalt módszerekkel a rendszer viszonylag szűkös erőforrások mellett is biztonságosan kivitelezhető. Irodalomjegyzék [1] Kósa Márk, Pánovics János, Gunda Lénárd (2005) PCRM: Kiértékelő szoftver programozói versenyekhez. Informatika a felsőoktatásban 2005, Debrecen [2] Kósa Márk, Pánovics János, Gunda Lénárd (2005) An evaluation tool for programming contests. Teaching Mathematics and Computer Science, 2005, 3/1, 103-119. [3] Kósa Márk, Pánovics János, Gunda Lénárd (2006) An evaluation tool for programming contests. Teaching Mathematics and Computer Science, 2005, 3/1, 103-119.

9

AUTOMATIKUS TESZTELŐ RENDSZEREK SZEREPE A TÖMEGKÉPZÉSBEN. Espák Miklós Debreceni Egyetem, Informatikai Kar. Összefoglaló

Recommend Documents