[vmchecker-user] FYI: Discutii PT despre vmchecker

Lucian Adrian Grijincu lucian.grijincu at gmail.com
Thu Jul 24 18:02:02 EEST 2008


Part 2.


---------- Forwarded message ----------
From: Lucian Adrian Grijincu <lucian.grijincu at gmail.com>
Date: 2008/6/25
Subject: Re: vmchecker - testare automatizată
To: Virgil Palanciuc <virgil.palanciuc at gmail.com>
Cc: Bogdan Nitulescu <bogdannitulescu at yahoo.com>


Cam cum merge acum sistemul de la SO (și aproape sigur și PSO):
* ca la PT temele se trimit din interfața web de pe cs.pub.ro/~so
* o temă trebuie să aibă un Makefile cu acțiunea "build" și să creeze
un fișier executabil, o bibliotecă, etc. cu nume specificat în temă.
* tema studentului e copiată pe un vmware (care este pus și la
dispoziția studenților - ei au pe calc. personale același sistem cu al
nostru pentru testare).
* se copie pe vmware și sistemul de testare al temei respective.
* există un alt fișier Makefile (Makefile.checker) scris de asistenții
SO care este rulat după ce s-a rulat "build" din Makefile-ul
studentului. Makefile.checker compilează pe loc un tester (dacă e
nevoie) și execută o serie de teste.
* dacă `make build` și `make -f Makefile.checker` rulează cu succes și
se termină în timpul alocat outputul testerului (stdout, stderr) este
trimis într-un fișier pe
so at cs.pub.ro:~/teme/ok/stud/$(NUME_STUDENT)/$(DATA_ORA_UPLOAD)/NOTA.
În so at cs.pub.ro:~/teme/ok/stud/$(NUME_STUDENT)/$(DATA_ORA_UPLOAD) se
mai pune și conținutul arhivei temei studentului.
* după întârzierile, warningurile din output în fișierul NOTA se scrie
punctajul maxim pe care l-ar putea lua acel student la acea temă. În
sesiune asistenții mai scad în funcție de implementare (nu se
eliberează resurse, erori neprinse de tester, etc.).
* mașina virtuală este restaurată la versiunea originală pentru a nu
influența rezultatul testelor pt alți studenți.

Și acum punctual:

>  In esenta - noi am avea nevoie sa ruleze un compilator facut de ei (ne pot
> face "submit" doar de executabil, e ok).
>  Din punctul meu de vedere, "cerintele" ideale pt PT ar fi cam urmatoarele
> (discutam, daca voi aveati in plan sa faceti altceva):
>
> 1. Userul (studentul) se autentifica, face "submit" de un executabil; acesta
> este pus intr-o locatie prestabilita si redenumit in mod standard (e.g.
> "tema.bin")
Momentan fișierul executabil este creat cu Makefile. Cred că e varianta corectă.

> 2. Inainte de asta, asistentul sa poata cumva sa "configureze" tema (sa puna
> un "fisier de configurare", in care sa scrie cum trebuie rulat testul - pt.
> fiecare rulare, sa puna o linie de genul "tema.bin -options
> /tests/t3/file1.in -o /results/file1.out", si  una sau mai multe linii in
> care sa scrie cum se testeaza acea rulare - e.g. "simulator /file1.out
> <my_data1 > my_results; compare my_results my_reference1; simulator
> /file1.out <my_data2 >my_results; compare my_results my_reference2")
Ficare temă are Makefile.checker și niște fișiere adiționale (tester,
input, output standard, etc.) scrise de echipa SO și care sunt puse la
dispoziția studenților.

> 3. Pe baza configurarii, se ruleaza pe rand tema studentului pe fiecare
> test, si se testeaza daca rezultatele sunt corecte.
>  3.a. Se ruleaza tema studentului ("tema.bin -options /tests/t3/file1.in -o
> /results/file1.out"); se captureaza, in fisiere diferite, stdout si stderr.
> Daca stderr nu e gol, se declara testul "FAILED" si i se trimite studentului
> (ca feedback)  output-ul de pe stdout si cel de pe stderr.
>  3.b.  Daca pe stderr nu a fost scris nimic, se trece la rularea liniilor de
> "simulare"; ultima linie din liniile de "simulare" va fi cea care va produce
> un "raport sintetic", scriind pe stderr "ce teste au picat" si pe stdout "ce
> teste au trecut"; statusul (FAIL/PASS) se deduce din dimensiunea
> "fisierului" stderr (daca e gol, testul e "passed")
>  3.c. Pentru un test, i se trimit inapoi studentului:
>         i. status (Failed/passed)
>         ii. daca e "FAILED" in 3.a - output-ul lui de pe stderr + cel de pe
> stdout
>         iii. altfel, output-ul de pe stdout din pasul 3.a + ouput-ul de
> stdout/stderr din pasul 3.b (cea care produce "raportul").
>  3.d Daca status-ul e "passed", se trece la executarea urmatorului test (
> "tema.bin -options /tests/t3/file2.in -o /results/file2.out");

> 4. toate mesajele trimise studentului + binarul trimis de student, se
> logheaza intr-un "history" al temei ( se tine minte si "cine a trimis
> binarul", "data/ora")
aici sunt salvate sursele și log-ul testerului:
so at cs.pub.ro:~/teme/ok/stud/$(NUME_STUDENT)/$(DATA_ORA_UPLOAD)

> 5. Trebuie sa existe posibilitatea ca scripturile asistentului sa modifice o
> "stare globala" care nu se reseteaza niciodata (e.g. sa scrie undeva "de
> cate ori a incercat fiecare student sa testeze tema", sa scrie chestii de
> genul "testul  1 a rulat in 1.2 s, testul 2 in 0,4 s samd")
Se poate extinde. Momentan, dacă vrei un raport trebuie să te uiți în
toate variantele pe care le-a uploadat studentul (sunt păstrate toate
și sunt verificate toate cu Moss - poate se trimit teme copiate pe
care le modifică cât pot până când moss-ul le consideră suficient de
diferite. Păstrarea tuturor variantelor ajută și atunci studentul
trimite tema2 în locul temei1 din neatenție: se poate șterge uploadul
greșit și restaura ultima variantă la cea corectă.)

> 6. Trebuie ca "ultima linie de simulare" (i.e. programul care produce
> "raportul de test" sa poata accesa niste date globale, (ideal ar fi sa fie
> stocate intr-o baza de date) - ca sa poata produce "on the fly" clasamente
> (de ex., daca mai dam o tema ca T4 unde e 'competitie' pt. 100++, sa poata
> sa-i spuna studentului ca "programele optimizate de tine au rulat in medie
>  in 231512 cicli, momentan esti pe locul 4"; eventual si sa-i spune "pe
> testul 1 ai cel mai bun timp, pe testul 2 esti pe locul 10; pe testul 3 pe
> locul 4 samd")
Se poate extinde. Momentan există un tabel generat automat cu notele
maxime alte fiecarui student și outputul temei lui. Din nou, "notele
maxime" inseamnă notele generate pe baza testerului. Se mai scade pe
calitatea codului, buguri neprinse de checker, etc.

> 7. Aici e o cerinta mai "tricky": nu vreau sa poata studentii sa-si "afiseze
> programul de intrare". Daca vrem sa stie testele, le publicam noi.
>   I.e., daca facem "concurs", nu e ok ca ei sa vada input-ul (daca ei fac
> 'submit' cu un program de "echo", o sa le zicem 'failed' si atasam programul
> de intrare) ... si atunci, trebuie sa putem filtra output-ul lor pe baza de
> "regular expression" sau macar pe baza de "substring, case-insensitive".
> Ma gandesc ca vom pune o regula in care zicem, "se considera copiere si
> luati 0/picati materia daca afisati programul de intrare pe STDOUT, in
> scopul de a-l vedea" - dar as vrea si ceva care sa verifice "automat" ( de
> ex. - sa punem numele variabilelor "vljklsdhautas" si daca gasim acest
> string in output - sa se blocheze automat trimirea output-ului catre
> student, si sa fie notificat asistentul pt. a vedea daca studentul a
> incercat sa "triseze" sau pur si simplu a afisat de ex o eroare de parsare
> (sa zicem ca nu si-a definit bine regula pt. 'identificator' si nu
> recunostea cuvantul "vljklsdhautas" ) ).
Cred că se poate și mai simplu: să avem două seturi de teste:
* unele care verifică doar funcționalitatea temei și
outputul/stderr-ul să fie vizibile în log
* unele cu stdout=stderr=/dev/null - degeaba afișează ei outputul, noi
nu-l băgăm în seamă.

>    Cam asta ar fi... sper ca nu am fost prea incoerent :), astept
> sugestii/sa discutam cum altfel s-ar putea face.
>
>   BTW, exista un server (utilizabil) care sa reziste la 50 de submit-uri
> paralele?  Ca ma gandesc, ca nu e exclus ca in ziua de dinainte de deadline,
> serverul ala sa fie super-incarcat... bine, puteti sa faceti rularea
> testelor asincron (si asa trebuie facuta daca vrem sa avem sanse sa nu pice
> serverul de web)... da' totusi, ar trebui sa se termine intr-un timp decent
> testarea/rularea. Stiu ca exista teoretic un super-mega calculator la dl.
> Cristea, da' nu stiu daca avem voie sa-l folosim noi pt acest "test
> framework'

Temele sunt puse intr-o coadă. Pe sistem e înregistrată ora de upload
și în funcție de aceasta se calculează penalizările. Tema poate să fie
corectată fără nici o problemă cu câteva ore după dacă sunt mulți în
coadă. Noi avem un calc special la SO și PSO: sanctuary.cs.pub.ro care
nu face (cel puțin nu știu eu) alceva decât rulare de teste.


--
Lucian


More information about the vmchecker-user mailing list