TCExam: applicazione web per test on line

Sono stato alla ConfSL è ho assistito ad un software per fare test/quiz on line chiamato TCExam, realizzato in PHP e rilasciato con GPL 3 a cura di Nicola Asuni che ho conosciuto personalmente. Nicola, già autore di TCPDF, si è concentrato sull’aderenza agli standard (XHTML 1.0, CSS 2.0 e WAI-AAA) che all’uso di AJAX che eventualmente potete aggiungere (concordo con lui anche perchè questo tipo di software è generalmente inglobato in altri ed è preferibile avere l’aderenza agli standard).

L’installazione, la versione attuale è 9.0.017, è semplice basta estrarre il file zip e copiarlo ad esempio nella cartella htdocs di Xampp e andare all’indirizzo:

http://localhost/TCexam/install/install.php

dove dovrete mettere i parametri di connessione al vostro database MySQL (default) o PostgreSQL. La procedura creerà un database con una 15 di tabelle.

Fatto ciò finite nella schermata di login. Dovete sapere però che esiste sia il lato pubblico che quello amministrativo che trovate all’indirizzo:

http://localhost/TCexam/admin/code/

e inserire le credenziali di amministratore admin/1234.

Occorre dire che il sistema di autenticazione si può basare su CAS, LDAP, Radius; i file di configurazione li trovate nella cartella shared/config.

La cosa interessante è che il software è multilingua ed è disponibile in Arabo, Bulgaro, Portoghese brasiliano, Cinese, Tedesco, Greco, Inglese, Spagnolo, Francese, Hindi, Ebreo, Ungherese, Indonesiano, Italiano, Giapponese,Marathi, Malese, Olandese, Polacco, Russo, Turco, Vietnamita.
Le lingue sono in un unico file che trovate nel path shared/config/lang/language_tmx.xml

Dal pannello potete creare utenti e assegnare loro dei gruppi. Potete importare/esportare utenti in formato XML o CSV e vedere lo stato dei risultati.

Le domande sono strutturare in moduli e argomenti e possono essere di tipo a risposta singola, multipla, libera e ordinamento delle risposte.
L’editing delle domande e risposte è basato su un editor che permette l’aggiunta di formule e immagini in Latex (cosa ottima) tramite tag quindi non visuale, tuttavia si può vedere la preview. Le domande possono essere importate/esportare in XML mentre la lista si può esportare anche in PDF.

La creazione dei test è anch’essa semplice. Per ogni test potete specificare la data di inizio e fine (fa fede quella del server), i gruppi di utenti che possono partecipare, i punti da assegnare per risposta corretta, sbagliata o non data, i punti minimi per passare l’esame e che tipo di domande aggiungere.

E’ possibile esportare il test in PDF così magari da stamparlo. Sul PDF generato compare un logo e un’intestazione specificati nel file shared/config/tce_pdf.php mentre l’immagine si trova nella cartella images.

A questo punto non vi resta che augurarvi buon test e se avete bisogno di aiuto chiedete direttamente a lui che è molto disponibile !

Junit e SoapUI, strumenti per testare web services

In genere durante il processo di sviluppo di una applicazione una delle fasi sottovalutate è quella di testing.

La fase testing dovrebbe in teoria iniziare non appena i requisiti della applicazione sono stati definiti e dovrebbe poi continuare per il tutto il processo di sviluppo poichè all’aumentare della complessità della applicazione i test devono garantirne il suo funzionamento e, dunque, esistono diversi livelli di test da quelli di unità a quelli di sistema e validazione (acceptance test).

Indipendentemente dai livelli esistono test di varia natura da quelli funzionali a quelli di robustezza e performance. In sostanza come avete potuto capire il tutto puo’ richiedere abbastanza tempo e quindi se si cerca di rendere quanto più automatica questa fase è meglio.

Nel mondo Java il tutto inizia con le librerie di Junit. Rilasciate con licenza Common Public Licence 1.0 sono arrivate, al momento in cui scrivo, alla versione 4.5 (del 8/8/2008). Esse permettono di automatizzare la fase di testing scrivendo metodi che contengono alcune chiamate alle librerie e tra queste esistono i metodi “assertEquals()” che verificano che 2 oggetti (quello atteso e quello di cui si dispone) sono uguali (da cui poi tuttte le derivazioni come il confronto tra booleani, stringhe ecc.).

Nonostante siamo alla versione 4.x la serie precedente, 3.x, viene mantenuta questo perchè le classi che contengono i metodi devono essere opportunamente scritte, in particolare con la 3.x ad esempio i nomi dei metodi devono avere una certa struttura (testXXX, cioè devono iniziare per test) mentre la 4.x permette di avere una certa elasticità usando pero’ le annotazioni come javadoc. Eclipse 3.4 annovera tra le sue librerie sia Junit 3 (3.8.2) e Junit 4 (4.3.1) e permette di creare Test case usando l’una o l’altra libreria. In questo esempio vedere come creare Junit Test case con la versione 4.

Un’ultima cosa che dovete sapere su Junit è che potete raggruppare i Test case in Test suite che eseguono più test. Inoltre quando si scrivono metodi per i test può capitare che questi condividano degli oggetti inizializzati; Junit permette di inizializzare, e poi distruggere, risorse condivise tramite i metodi setUp() e tearDown(), vi lascio poi scoprire il tutto facendovi spulciare la documentazione.

Ant, non solo vi permette di automatizzare il tutto con il suo Junit task, ma vi crea anche, a partire dai risultati di ogni test, dei sempli report.

Quando create dei web services usando il plugin di Axis2, Codegen Wizard, per Eclipse probabilmente avrete notato l’opzione che genera anche i test cases che alla fine non sono altro che semplici client che dovete inizializzare dando l’end point da contattare e costruendo gli oggetti che da passare allo stub. Inoltre potete modificare il file Ant generato per generare i report che vi avevo accennato prima.

Junit è pero’ la punta di un iceberg. Difatti si sono evolute applicazioni che si occupano solo della fase di testing come Cactus, Fitnesse (che è un wiki che fa acceptance test) , Selenium che allargano l’orizzonte anche alle applicazioni web, lo stesso Spring tra l’altro contiene un modulo per il testing. Se poi parliamo di performance esiste jMeter (a cui SOAPUI fa concorrenza).

SoapUI è una applicazione rivolta ai web services che abbiamo già incontrato quando vi ho accennatto alla possibilità di validare i file wsdl per migliorare l’interoperabilità.

Una delle funzionalità carine è quella di creare al volo una richiesta SOAP automaticatimente generata a partire dal file wsdl, generando poi report e test di copertura su file wsdl.

Junit non è poi l’unico testing framework esistono TestNG ed anche Nunit (che è il porting di Junit per .NET) e una miriade di applicazioni che vengono usate per testare i vari linguaggi.

A questo punto vi auguro buona esplorazione in questo mondo che, anche per me, si sta rivelando sempre più grande e al tempo stesso affascinante (soprattutto come sviluppatore pigro che vorrebbe automatizzare tutto ciò ).

P.S: Occorre dire che lo stesso Eclipse nel suo piccolo permette di testare on-line il servizio web. Difatti cliccando con il tasto destro del mouse sul file wsdl dovreste ritrovarvi nel menu contestuale la voce Web Services da cui la sotto voce Test with Web Services Explorer che è una interfaccia web che vi permette di compilare i campi  da mandare nella richiesta SOAP e subito sotto vedere la risposta.

Link interessante: http://wso2.org/library/3862

Alla prossima