Rapporto tecnico contenente l’analisidelle tecniche di verifica e convalida

Indice1 Introduzione 3

2 Verification & Validation 3

3 Verifica del dimostratore 53.1 Strategie di test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Metodi di test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3 Fasi di test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Verifica del dimostratore all’interno del progetto 84.1 Testing di integrazione . . . . . . . . . . . . . . . . . . . . . . . . 8

4.1.1 Esecuzione del test . . . . . . . . . . . . . . . . . . . . . . 84.1.2 Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.1.3 Stub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.1.4 Regression Testing . . . . . . . . . . . . . . . . . . . . . . 94.1.5 Confronti fra i vari approcci . . . . . . . . . . . . . . . . . 94.1.6 Testing di Release . . . . . . . . . . . . . . . . . . . . . . 104.1.7 Performance testing . . . . . . . . . . . . . . . . . . . . . 10

4.2 Unit testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2.1 Benefici . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2.2 Separazione dell’interfaccia dall’implementazione . . . . . 124.2.3 Limitazioni dello unit testing . . . . . . . . . . . . . . . . 124.2.4 Applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Framework unit testing 135.1 unittest - Unit testing framework . . . . . . . . . . . . . . . . . . 135.2 Struttura di Test Base . . . . . . . . . . . . . . . . . . . . . . . . 145.3 Eseguire i Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.4 Esiti dei Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.5 Affermare la Verità . . . . . . . . . . . . . . . . . . . . . . . . . . 155.6 Verificare una Eguaglianza . . . . . . . . . . . . . . . . . . . . . . 175.7 Quasi uguali? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.8 Verificare le eccezioni . . . . . . . . . . . . . . . . . . . . . . . . . 205.9 Test Fixtures (Impianti di Test) . . . . . . . . . . . . . . . . . . . 205.10 Test Suite (Raccolte di Test) . . . . . . . . . . . . . . . . . . . . 21

1

6 Convalida delle Tassonomie 236.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.2 Visualizzare le Tassonomie . . . . . . . . . . . . . . . . . . . . . . 246.3 Modificare le Tassonomie . . . . . . . . . . . . . . . . . . . . . . 24

6.3.1 Unione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.3.2 Cancellazione . . . . . . . . . . . . . . . . . . . . . . . . . 256.3.3 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.3.4 Trascina e rilascia . . . . . . . . . . . . . . . . . . . . . . 25

6.4 Convalidare le tassonomie . . . . . . . . . . . . . . . . . . . . . . 266.4.1 Controllo diretto . . . . . . . . . . . . . . . . . . . . . . . 266.4.2 Convalida delle metriche . . . . . . . . . . . . . . . . . . . 266.4.3 Applicazione classificatori semplici . . . . . . . . . . . . . 27

Riferimenti bibliografici 28

2

1 IntroduzioneQuesto documento descrive i processi di sviluppo del software indicati in in-gegneria del software come Verifica e Convalida1 relativi al progetto. Questaguida definisce la verifica e la convalida del software e fornisce le linee guidasu come effettuarle. Tale documento sostituisce il Software Verification andValidation Plan.

2 Verification & ValidationIn [1] la V&V viene definita nel seguente modo: “La V&V del software é unadisciplina dell’ingegneria del software che valuta il software nel contesto delsistema, in relazione a tutti gli elementi del sistema come hardware, utenti ealtri software.”. Sono definite nel seguente modo:

• Convalida: Stiamo costruendo il prodotto giusto? Soddisfa i requisiti delcliente?

• Verifica: Stiamo costruendo il prodotto nel modo giusto? Rispetta lespecifiche date?

In altre parole la convalida si occupa di verificare che il sistema soddisfi leesigenze del cliente, mentre la verifica si preoccupa di verificare se il sistema é benprogettato, senza errori eccetera. La verifica aiuterá unicamente a determinarela qualitá del software, ma non la sua utilitá.

La verifica comprende tutte le attivitá connesse con la produzione di softwaredi alta qualitá come test, inspection, analisi della progettazione e analisi dellespecifiche. Si tratta di un processo relativamente oggettivo in quanto, se i variprodotti e la documentazione sono espressi con sufficiente precisione, nessungiudizio soggettivo dovrebbe essere necessario per verificare il software.

Al contrario, la convalida é un processo estremamente soggettivo, in quantochi l’esegue valuta dal proprio punto di vista la corrispondenza tra il sistemasviluppato e le richieste dell’utente che commissiona il progetto del sistema. Laconvalida comprende attivitá quali modellazione dei requisiti e valutazione delprototipo.

Nel tradizionale ciclo di vita del software per verifica si intende il processodi controllo col quale si riscontra che i prodotti in ciascuna fase dello svilupposoddisfano i requisiti della fase precedente. La convalida viene impiegata soloall’inizio e alla fine del progetto attraverso l’analisi dei requisiti e i test di ac-cettazione (Acceptance Testing). Questo punto di vista, comune a molti libridi ingegneria del software, é ingannevole in quanto presuppone erroneamenteche i requisiti del cliente possano essere raccolti esclusivamente all’inizio di unprogetto e che tali requisiti non possano cambiare mentre il software é in fasedi sviluppo. Nella pratica i requisiti cambiano nel corso del progetto, in partecome reazione al progetto stesso. Pertanto sia la convalida che la verifica sononecessari per tutti i passi del ciclo di vita del software.

L’obiettivo di questo documento é quindi quello di mostrare sia i differentitipi di test automatici applicabili durante lo sviluppo del dimostratore che i

1 In inglese, ci si riferisce a tali processi col termine Verification & Validation o V&V

3

vari tipi di algoritmi utilizzabili per convalidare le varie tassonomie generate daldimostratore.

4

3 Verifica del dimostratoreLo scopo dei test é rilevare gli errori logici scritti nel codice. Il codice deveessere testato utilizzando il piú possibile differenti tipi di dati di input. I testdovrebbero essere pianificati ed approfonditi, in quanto si stima che la fase ditest puó occupare fino al 50% del tempo assegnato per lo sviluppo del software.

A volte i test e il debugging sono considerati parte dello stesso processo. Inrealtá sono molto diversi:

• Il test stabilisce l’esistenza di difetti. Puó essere utilizzato per testarele prestazioni e l’affidabilitá del software. Dopo aver eseguito i test sipuó effettuare una stima della sicurezza di funzionamento del sistema. Leprestazioni del programma possono essere giudicate misurando il tempod’esecuzione dei test.

• Il debug si occupa di individuare e correggere i difetti. Ha lo scopo diindividuare le aree in cui il programma non é conforme alle sue specifiche.I test sono progettati per rivelare la presenza di difetti nel sistema perpoterli rimuovere.

Il debugger deve generare ipotesi sul comportamento osservabile del pro-gramma per poi testare tali ipotesi e verificarle nella speranza di trovare ildifetto che ha causato il problema. Il test delle ipotesi puó portare a dover rin-tracciare manualmente il difetto nel codice. Possono essere necessari nuovi testper localizzare il problema. Strumenti di debug interattivi che mostrano i valoriintermedi delle variabili del programma e una traccia delle istruzioni eseguitepossono essere utilizzati per aiutare il processo di debug.

Quando si scopre un difetto nel programma, il programma deve essere cor-retto e il sistema deve essere risottoposto ai test. Questa forma di test vienechiamato test di regressione e viene utilizzato per verificare che le modifiche alprogramma non hanno introdotto nuovi difetti nel sistema.

3.1 Strategie di testDiverse strategie di test possono essere adottate a seconda del tipo di sistemada testare e del processo di sviluppo utilizzato. Ci sono due diverse strategiedisponibili: Top-Down Testing e Bottom-Up Testing.

Nel Top-Down Testing, l’alto livello di un sistema viene testato primadi testare i componenti dettagliati. Il software viene rappresentato come unsingolo componente astratto con sotto-componenti rappresentati da Stub. GliStub hanno la stessa interfaccia del componente ma presentano funzionalitámolto limitate.

Dopo che la componente di alto livello viene testata i suoi sub-componentivengono implementati e testati nello stesso modo. Questo processo continuaricorsivamente fino al basso livello del software. L’intero sistema puó quindiessere completamente testato. Il Top-Down Testing deve essere usato nellosviluppo dei programmi Top-Down in modo che un componente di sistema vienetestato non appena viene programmato.

Utilizzando un approccio Top-Down gli errori di progettazione inosservatipossono essere rilevati nella fase iniziale del processo di test. Poiché questi erro-ri di solito sono errori strutturali, la loro scoperta puó evitare la riprogettazione

5

o la reimplementazione del codice. Il Top-Down Testing ha l’ulteriore vantaggiodi permettere l’implementazione del prototipo software in una fase molto pre-coce dello sviluppo, il che puó fornire una spinta psicologica nello sviluppo. Laconvalida puó iniziare nelle prime fasi del processo di testing mentre una demopuó essere resa disponibile agli utenti il piú presto possibile.

Il Bottom-Up Testing é una strategia opposta al Top-Down. Vengonotestati i moduli di livello inferiore nella gerarchia per poi risalire la gerarchia deimoduli fino a quando l’ultimo modulo viene testato. Questo tipo di test é adattoa sistemi orientati agli oggetti dove i singoli oggetti vengono testati utilizzandoi propri sistemi di test. I singoli oggetti vengono poi integrati e viene testatal’intera raccolta di oggetti.

3.2 Metodi di testEsistono fondamentalmente due diversi metodi utilizzati per il test del software:il Black-box Testing e il White-box Testing.

Il Black-box Testing (talvolta chiamato Functional Testing) tratta il si-stema da un punto di vista esterno, ovvero come una scatola nera di cui non épossibile vedere l’interno. La struttura del programma non viene quindi presain considerazione, in quanto i test vengono esclusivamente eseguiti in base a cióche esegue il programma.

Tale metodo é utile per controllare se il programma risponde ai requisiticoncordati col cliente nella fase di specifica. L’approccio Black-box solitamentesegue il seguente algoritmo:

1. Si scrive e si testa il codice del singolo componente.

2. Si aggiunge il componente alle parti di codice giá scritte e testate.

3. Si effettuano test e debug sul codice.

4. Si ripetono i punti 1-2-3 fino a quando non vengono aggiunti tutti icomponenti del codice.

5. Si consegna il codice per gli Acceptance Test.

L’Acceptance Test viene utilizzato verso la fine dello sviluppo del software esegue un piano di test concordato. Si applica il metodo Black-box per vedere seil software é conforme ai requisiti funzionali del cliente, in quanto non é possibiletestare i singoli moduli isolati2.

Un segmento del programma principale che passa i dati al modulo si chiamaDriver. Il Driver puó anche stampare i risultati che il modulo gli passa. Unsottoprogramma fittizio che viene chiamato dal modulo sotto test si chiamaStub. Lo Stub puó accettare o passare i dati al modulo di test e confermareche la transazione si é verificata semplicemente scrivendo un messaggio sulloschermo.

Pertanto nel Black-box Testing il programmatore controlla gli ingressi e leuscite del modulo. I dettagli del sistema sono trattati come se fossero in unascatola nera e non possono quindi essere visti. Il programmatore (tester) nonesamina il codice che sta per essere testato.

2 Questo problema puó essere superato scrivendo nei file di test piccole sezioni di codiceche scambiano i dati tra i moduli

6

Il White-Box Testing (talvolta chiamato Structural Testing) tratta il si-stema come una scatola bianca o trasparente di cui é possibile vedere l’interno.La struttura del programma viene quindi presa in considerazione, in quantoi test vengono progettati sul programma. L’approccio White-Box solitamentesegue il seguente algoritmo:

1. Si garantisce che tutte le istruzioni del programma siano state testatealmeno una volta.

2. Si testano tutte le dichiarazioni booleane del codice e si verificano quali diquesti percorsi non sono stati testati nell’approccio Black-Box.

3. Si testano tutti i cicli analizzando i loro limiti operativi.

4. Si verifica la validitá delle strutture dati interne.

5. Si creano nuovi dati di test per le sezioni di codice non collaudate.

Pertanto nel White-Box Testing il programmatore guarda ogni possibiledettaglio del sistema.

3.3 Fasi di testFatta eccezione per i piccoli programmi, i sistemi non dovrebbero essere testaticome una singola unitá monolitica. I grandi sistemi sono sviluppati in sottosistemi costruiti su moduli, che a loro volta sono composti da procedure e fun-zioni. Il processo di test dovrebbe quindi procedere per tappe in cui si effettuail test seguendo l’implementazione del sistema. Il processo di test piú diffuso écostituito da cinque fasi:

1. Unit Testing: I singoli componenti sono testati per garantire il lorocorretto funzionamento. Ogni componente viene testato in modo indipen-dente senza altri componenti del sistema.

2. Module Testing: Si testano i componenti indipendenti, quali proceduree funzioni. Un modulo incapsula i relativi componenti in modo che possaessere testato senza altri moduli del sistema.

3. Subsystem Testing: Si testano i moduli che sono stati integrati in sottosistemi. I sotto sistemi possono essere progettati in modo indipendente.I problemi piú comuni che si presentano nei sistemi software di grandidimensioni sono i collegamenti sbagliati tra i vari sotto sistemi. Il processodi test dei sotto sistemi dovrebbe quindi concentrarsi sul rilevare tali errorianalizzando le loro interfacce.

4. System Testing: Si integrano i sotto sistemi nel sistema completo. Ilprocesso di test si occupa di trovare gli errori derivanti da interazioniimpreviste tra i sotto sistemi e i componenti di sistema. Inoltre si convalidail sistema in modo che soddisfi i requisiti funzionali e non funzionali.

5. Acceptance Testing: Questa è la fase finale del processo di test primache il sistema venga accettato per l’uso operativo. Il test di accettazio-ne puó rivelare errori e omissioni nella definizione dei requisiti di sistema

7

perché l’utilizzo nel test dei dati reali esercita il sistema in modo diversodai dati di test. Può anche rivelare problemi dei requisiti per cui le strut-ture del sistema non soddisfano le esigenze dell’utente o le prestazioni delsistema non sono accettabili.

4 Verifica del dimostratore all’interno del proget-to

Si è valuto all’interno del progetto di eseguire il testing di integrazione e utiliz-zare come metodo di verifica del dimostratore l’unit testing. In questo capitoloandremmo ad analizzare più nel dettaglio lo stato dell’arte del testing di inte-grazione e dell’unit testing e la metodologia software utilizzata per la verificadel dimostratore interno al nostro progetto.

4.1 Testing di integrazioneIl Testing di integrazione, richiede la costruzione del sistema a partire dai suoicomponenti ed il testing del sistema risultante per scoprire problemi che nasco-no dall’interazione fra i vari componenti. Richiede l’identificazione di gruppi dicomponenti che realizzano le varie funzionalità del sistema e la loro integrazionemediante componenti che li fanno lavorare insieme. Partendo da una architet-tura organizzata gerarchicamente, le integrazioni possono essere realizzate conapproccio top-down o bottom-up o misto.

4.1.1 Esecuzione del test

• Costruzione di Moduli guida (driver

– invocano l’unità sotto test, inviandole opportuni valori, relativi altest case.

• Moduli fittizi (stub)

– sono invocati dall’unità sotto test;

– emulano il funzionamento della funzione chiamata rispetto al casodi test richiesto (tenendo conto delle specifiche della funzione chia-mata) . Quando la funzione chiamata viene realizzata e testata, sisostituisce lo stub con la funzione stessa.

4.1.2 Driver

Tramite un framework di Testing Automation è necessario realizzare driver estub necessari per testare un modulo non terminale. Le classi di test rappresen-tano dei driver quando si riferiscono ad una classe non accessibile dall’esterno;Un driver deve avere la visibilità dei componenti da testare (o quanto menodell’interfaccia che vogliamo esercitare).

8

Figura 1:

4.1.3 Stub

Uno stub è una funzione fittizia la cui correttezza è vera per ipotesi. Esempio,se stiamo testando una funzione prod-scal(v1,v2) che richiama una funzioneprodotto(a,b) ma non abbiamo ancora realizzato tale funzione; nel metodo dri-ver scriviamo il codice per eseguire alcuni casi di test: Ad esempio chiamiamoprod-scal([2,4],[4,7]) Il metodo stub potrà essere scritto così:

i n t prodotto ( i n t a , i n t b){i f ( a==2 && b==4) return 8 ;

i f ( a==4 && b==7) return 28 ; }

La correttezza di questo metodo stub è data per ipotesi. Ovviamente perpoter impostare tale testing, bisognerà avere precise informazioni sul compor-tamento interno richiesto al modulo da testare.

4.1.4 Regression Testing

Man mano che si integrano i vari componenti, sarà anche necessario rieseguire iprecedenti test. Se si scoprono nuovi difetti, si dovrà capire se erano già presentinei precedenti incrementi, o se sono causati da quelli nuovi. Il test di regressionesi esegue anche dopo un intervento di manutenzione (per verificare che il sistemanon sia ‘regredito’).

4.1.5 Confronti fra i vari approcci

• Per la validazione dell’architettura

– Il Testing di integrazione Top-down scopre meglio gli errori presentinell’architettura.

• Per la dimostrazione del funzionamento del sistema

– Il Testing di integrazione Top-down permette una dimostrazione (li-mitata) fin dalle prime fasi dello sviluppo.

9

Figura 2:

• Implementazione del Test

– In genere è più semplice con l’approccio bottom-up.

• Osservazione del test

– Entrambi gli approcci hanno problemi. Può essere necessario codiceextra in entrambi i casi.

4.1.6 Testing di Release

E’ il processo di testing di una release del sistema che sarà rilasciata al cliente.Obiettivo primario è dimostrare che il sistema si comporti come specificato.Occorre provare che fornisce tutte le funzionalità, le prestazioni, l’affidabilità,etc. richieste, e che non fallisca. É in genere un testing black-box (a scatolanera) detto anche testing funzionale basato solo sulle specifiche del software; ITester non accedono al suo codice.

4.1.7 Performance testing

Dopo che il sistema è stato completamente integrato, è possibile testarne leproprietà emergenti, come le prestazioni ed affidabilità. I test di prestazione ingenere riguardano il carico e si pianificano test in cui il carico viene incrementatoprogressivamente finché le prestazioni diventano inaccettabili. Il carico deveessere progettato in modo da rispecchiare le normali condizioni di utilizzo.

10

4.1.8 Piano di test

Documento relativo all’intero progetto. Struttura:

• specifica delle unità di test (per un dato livello di test) Es. Modulo, gruppidi moduli, programma, sottosistemi, intero sistema;

• Caratteristiche da testare: funzionalità, prestazioni, vincoli di progetto,sicurezza

• Approccio: criterio di selezione dei test, criterio di terminazione, strumen-ti;

• Prodotti del test: es. Casi di test, rapporto finale, diario del test, statisti-che di copertura

• Schedulazione: quando effettuare il testing e lo sforzo per attività;

• Allocazione del personale.

4.2 Unit testingIn ingegneria del software, per unit testing (testing d’unità o testing unitario)si intende l’attività di testing (prova, collaudo) di singole unità software. Perunità si intende normalmente il minimo componente di un programma dotatodi funzionamento autonomo; a seconda del paradigma di programmazione olinguaggio di programmazione, questo può corrispondere per esempio a unasingola funzione nella programmazione procedurale, o una singola classe o unsingolo metodo nella programmazione a oggetti.

Lo unit testing viene normalmente eseguito dagli sviluppatori, e può essereoccasionalmente glass box, ovvero essere esplicitamente basato sulla conoscenzadell’architettura e del funzionamento interno di un componente oltre che sullesue funzionalità esternamente esposte. Come le altre forme di testing, lo unittesting può variare da completamente manuale ad automatico. Specialmentenel caso dello unit testing automatico, lo sviluppo dei test case (cioè delle sin-gole procedure di test) può essere considerato parte integrante dell’attività disviluppo (per esempio, nel caso dello sviluppo guidato da test).

4.2.1 Benefici

Lo scopo dello unit testing è quello di verificare il corretto funzionamento diparti di programma permettendo così una precoce individuazione dei bug. Unounit testing accurato può dare una prova certa se un pezzo di codice funzionacorrettamente, con importanti vantaggi:

Semplifica le modificheLo unit testing facilita la modifica del codice del modulo in momenti succes-

sivi (refactoring) con la sicurezza che il modulo continuerà a funzionare corret-tamente. Il procedimento consiste nello scrivere test case per tutte le funzioni ei metodi, in modo che se una modifica produce un fallimento del test, si possafacilmente individuare la modifica responsabile.

Semplifica l’integrazione

11

Lo unit testing semplifica l’integrazione di moduli diversi perché limita imalfunzionamenti dovuti a problemi nella interazione tra i moduli e non neimoduli stessi, rendendo i test di integrazione più semplici.

Un argomento molto dibattuto è quello della non necessità di test di in-tegrazione manuali, in caso si sia organizzata una procedura di unit testingsufficientemente completa. In realtà spesso un elaborato sistema di unit testingfornisce una falsa sicurezza e un test di integrazione gestito da esseri umani èin genere ugualmente necessario. Probabilmente la reale necessità del fattoreumano nella procedura di test dipende dalle caratteristiche del sistema nel qualesi sviluppa e soprattutto dalla disponibilità di risorse.

Supporta la documentazioneLo unit testing fornisce una documentazione viva del codice, perché è intrin-

secamente un esempio di utilizzo dell’API del modulo.I test case incorporano le caratteristiche critiche per il successo di un’unità

di codice. Tali caratteristiche indicano l’uso appropriato dell’unità e i compor-tamenti errati che devono essere identificati nel suo funzionamento. Pertanto lounit testing documenta tali caratteristiche, sebbene in molti ambienti questi nonpossono costituire la sola documentazione necessaria. In compenso, la tradizio-nale documentazione diventa spesso obsoleta a cause di successive modifiche delcodice non documentate.

Unit test già predisposti semplificano la vita al programmatore nel controlla-re che una porzione di codice stia ancora funzionando correttamente. Un buonunit testing produce test case che coprano tutti i percorsi del codice dell’unità,con particolare attenzione alle condizioni nei cicli (test sugli if, while, for).

In sistemi con unit testing continuo, tali test sono in grado di garantireautomaticamente integrità del codice ad ogni modifica.

4.2.2 Separazione dell’interfaccia dall’implementazione

Poiché alcune classi possono far riferimento ad altre, il test di una classe spessosi propaga alle altre. Un esempio è una classe che interagisce con un database:testare la classe spesso implica la scrittura del codice che interagisce con il da-tabase. Questo è un problema perché lo unit test non dovrebbe mai varcare iconfini della classe. La conseguenza è che il programmatore, nel progettare lounit testing, impara ad isolare la classe da analizzare, individuando l’interfacciacon il database ed implementandola con un mock object, una simulazione del-l’oggetto reale che può essere effettuata in condizioni controllate. L’effetto è untest più approfondito e quindi uno unit testing di qualità più elevata.

4.2.3 Limitazioni dello unit testing

In generale il testing non riesce ad identificare tutti gli errori in un programma elo stesso vale per lo Unit Testing che, analizzando per definizione le singole unità,non può identificare gli errori di integrazione, problemi legati alla performancee altri problemi legati al sistema in generale. Lo unit testing è più efficace seutilizzato in congiunzione con altre tecniche di testing del software.

Come ogni forma di testing, anche lo Unit Testing non può individuarel’assenza di errori ma può solo evidenziarne la presenza.

Il testing del software è un problema di matematica combinatoria. Per esem-pio, ogni test booleano richiede almeno due test, uno per la condizione di vero e

12

uno per quella di falso. Si può dimostrare che, per ogni linea di codice funziona-le, siano necessarie dalle 3 alle 5 linee di codice per il test. È quindi irrealisticotestare tutte le possibili combinazioni di input di qualsiasi codice non banalesenza un tool apposito di generazione di casi di test.

Per ottenere gli sperati benefici dallo unit test, è richiesto un rigoroso sensodi disciplina durante tutto il processo di sviluppo. È essenziale mantenere trac-cia non solo dei test che sono stati sviluppati ed eseguiti, ma anche di tutte lemodifiche effettuate al codice funzionale dell’unità in esame e di tutte le altre.L’uso di un sistema di controllo versione è essenziale. Se una versione succes-siva di una unità fallisce un test che aveva passato in precedenza, il sistema dicontrollo versione permette di evidenziare le modifiche al codice intervenute nelfrattempo.

4.2.4 Applicazioni

Extreme ProgrammingLo unit testing è la parte fondamentale dell’Extreme Programming (XP),

che si basa su uno unit testing framework, che può essere fornito da terze partio creato all’interno del gruppo di sviluppo.

L’Extreme Programming usa la creazione di unit test per lo Sviluppo Guida-to dal Test (TDD, Test Driven Development). Lo sviluppatore scrive uno unittest che evidenzi una funzionalità richiesta dalle specifiche o un difetto possi-bile. Il test può fallire perché la funzionalità non è stata ancora implementatao perché il difetto cercato è effettivamente verificato. Quindi lo sviluppatorescrive il codice funzionale più semplice possibile affinché il test sia eseguito consuccesso.

Tutte le classi sono testate in questo modo e lo sviluppatore rilascia il codicedi test insieme al codice funzionale da esso testato. La XP, con uno unit testingapprofondito, presenta tutti i benefici descritti sopra e i test sono utilizzatisuccessivamente come test di regressione.

TecnicheNormalmente lo unit testing è automatizzato, ma può anche essere eseguito

manualmente. Non c’è alcuna raccomandazione in proposito da parte delloIEEE. L’approccio manuale può richiedere la documentazione dei passi necessariper l’esecuzione dello unit test. In ogni caso, lo scopo dello unit test è quello diisolare un modulo a certificarne la correttezza e l’automatizzazione, a differenzadel test manuale, è un modo efficiente per raggiungere questi obbiettivi e portarei benefici descritti.

Con l’approccio automatico, per realizzare il completo isolamento del moduloda testare, il codice funzionale è testato al di fuori del suo ambiente naturale, inun apposito framework. Questo approccio ha il pregio di evidenziare dipendenzenon richieste del modulo in esame dagli altri.

In un framework automatizzato lo sviluppatore codifica i casi da testarein modo che verifichino la correttezza del modulo e durante l’esecuzione vieneriportato l’eventuale fallimento di ogni test. In alcuni casi di fallimento di testcritici, l’intera procedura di test viene fermata.

La conseguenza dello unit testing è un approccio alla programmazione chefavorisce la scrittura di codice in moduli indipendenti ed interoperanti, che asua volta contribuisce, insieme ai Design pattern e ad altre pratiche comuni allarealizzazione del miglior codice possibile.

13

Unit testing frameworkEsistono framework sviluppati per lo unit testing di una miriade di linguag-

gi. È generalmente possibile realizzare lo unit testing senza il supporto di unospecifico framework, scrivendo il codice che testi il modulo e che implementimeccanismi quali le asserzioni, le eccezioni o le uscite anticipate per segnala-re i fallimenti. Questo approccio è prezioso perché semplifica l’adozione dellounit testing, ma è anche limitato dall’assenza di molte funzionalità avanzate deiframework disponibili.

5 Framework unit testingAll’interno del progetto si è scelto di utilizzare il framework Unittest per laverifica del dimostratore scritto in python.

5.1 unittest - Unit testing frameworkIl modulo unittest, a cui talvolta ci si riferisce come PyUnit, è basato sul proget-to dell’ambiente XUnit, di Kent Beck ed Erich Gamma. Lo stesso modello vieneripetuto in molti altri linguaggi, incluso C, perl, Java e Smalltalk. L’ambienteimplementato da unittest supporta fixtures (impianti di test), test suites (rac-colte di test) ed un test runner (esecutore di test) per consentire l’automazionedel test per il proprio codice.

5.2 Struttura di Test BaseI test, così come definiti da unittest, sono composti da due parti: il codiceper gestire l’impianto di test, ed il test stesso. Test individuali sono creatisubclassando TestCase e riscrivendo od aggiungendo i metodi appropriati.

Figura 3:

In questo caso, SimplisticTest ha un singolo metodo test(), che fallirebbese True fosse mai False.

5.3 Eseguire i TestIl modo più semplice per eseguire i test di unittest è di includere:

14

Figura 4:

alla fine di ogni file di test, poi semplicemente eseguire lo script direttamenteda riga di comando:

Figura 5:

L’output abbreviato comprende il tempo impiegato per il test, assieme ad unindicatore di stato per ogni test (il puntino nella prima riga dell’output significache un test è stato superato). Per maggiori dettagli nel risultato del test siinclude l’opzione -v:

Figura 6:

5.4 Esiti dei TestI test hanno 3 risultati possibili:

Okil test viene superatoFailil test non viene superato e viene sollevata una eccezione AssertionError.Erroril test solleva una eccezione diversa da AssertionError.

15

Figura 7:

Non esiste un modo esplicito per far superare un test, quindi lo stato deltest dipende dalla presenza (od assenza) di una eccezione.

Quando un test fallisce o genera un errore, nell’ouput viene incluso anche iltraceback.

Figura 8:

Nell’esempio di cui sopra, testFail() fallisce, ed il traceback mostra la rigache comprende il codice che ha fallito. E’ comunque compito di colui che leggeil risultato del test di verificare il codice per desumere il significato semanticodel fallimento del test. Per facilitare la comprensione della natura del fallimentodel test, i metodi fail*() ed assert*() accettano tutti un parametro msg, chepuò essere usato per produrre un messaggio di errore più dettagliato.

16

Figura 9:

Figura 10:

5.5 Affermare la VeritàLa maggior parte dei test affermano la verità di una qualche condizione. Cisono alcuni diversi modi di scrivere dei test che verifichino una verità, a secondadella prospettiva dell’autore del test ed del risultato voluto del codice che sista verificando. Se il codice produce un valore che può essere valutato comevero, dovrebbero essere usati i metodi failUnless() ed assertTrue(). Seil codice produce un valore falso, ha più senso usare i metodi failIf() edassertFalse().

5.6 Verificare una EguaglianzaCome caso speciale, unittest comprende metodi per verificare l’eguaglianza didue valori.

Questi test speciali fanno comodo, visto che i valori confrontati appaiono nelmessaggio di fallimento, quando un test fallisce.

17

Figura 11:

Figura 12:

18

Figura 13:

5.7 Quasi uguali?Oltre alla stretta eguaglianza, è possibile verificare una quasi eguaglianza di nu-meri a virgola mobile usando failIfAlmostEqual() e failUnlessAlmostEqual().

Figura 14:

I parametri sono i valori da confrontare, ed il numero di posizioni decimalida utilizzare per il test.

5.8 Verificare le eccezioniCome detto precedentemente, se un test solleva una eccezione diversa da As-sertionError, viene trattata come un errore. Questo è molto utile per scoprireerrori che si compiono mentre si sta modificando del codice per il quale già esisteun test abbinato. Ci sono circostanze, comunque, nelle quali si vuole eseguireil test per verificare che un certo codice effettivamente produca una eccezione.

19

Ad esempio se un valore non valido viene passato come attributo di un ogget-to. In tali casi, failUnlessRaises() rende il codice più chiaro che catturarel’eccezione nel proprio codice. Si confrontino questi due test:

Figura 15:

I risultati per entrambi sono gli stessi, tuttavia il secondo test, che usafailUnlessRaises() è più succinto.

5.9 Test Fixtures (Impianti di Test)Fixtures sono risorse necessarie per un test. Ad esempio, se si stanno scrivendoparecchi test per la stessa classe, questi test necessitano tutti una istanza diquella classe da usere per il test. Altri impianti includono connessioni a databasee file temporanei (molta gente potrebbe argomentare che usando risorse esternei test non sono più considerabili a livello di unità, ma sono comunque test, esono comunque utili). TestCase include uno speciale aggancio per configuraree ripulire un qualsivoglia impianto che sia necessario per i propri test. Perconfigurare gli impianti, si riscrive setup(). Per ripulire, si riscrive tearDown().

Quando il test di esempio viene eseguito, si può vedere l’ordine di esecuzionedell’impianto e dei metodi di test:

20

Figura 16:

Figura 17:

21

5.10 Test Suite (Raccolte di Test)La documentazione della libreria standard descrive come organizzare manual-mente le raccolte di test. Automatizzare la costruzione di raccolte di test èspecialmente utile per vaste basi di codice, nelle quali i test collegati non so-no tutti nello stesso posto. Strumenti tipo nose facilitano la gestione dei testquando essi sono sparsi attraverso file e directory multiple.

22

6 Convalida delle TassonomieLa grande quantitá di informazioni presente nella rete e la difficoltá a reperirele giuste informazioni ha spinto le aziende a cercare una soluzione per risolverequesto problema. Le tassonomie sono significative categorizzazioni gerarchichedi documenti che riflettono le relazioni naturali tra i documenti e i loro obiettividi business. Per tale motivo uno degli obiettivi principali della ricerca é quellodi migliorare la qualitá delle tassonomie riducendo contemporaneamente il costocomplessivo necessario per crearle. Importanti tecnologie come Supervised andunsupervised text clustering sostituiscono solo in parte una soluzione completa,in quanto é necessaria l’iterazione dell’essere umano nella fase di editing e diconvalida delle tassonomie.

É opportuno comprendere e valutare ogni categoria di una tassonomia e vi-sualizzare le relazioni tra le categorie. Tecniche multiple permettono all’utentedi apportare modifiche sia alla categoria che ai livelli dei documenti. Per que-sto motivo é opportuno stabilire delle metriche per definire se la tassonomiagenerata dal sistema deve essere modificata dall’utente.

6.1 IntroduzioneLe aziende sono state in grado di aumentare sistematicamente la leva finanzia-ria acquisita con i dati aziendali tramite tecnologie quali sistemi di gestione didatabase relazionali e tecniche di data warehousing. Si é inoltre ipotizzato chela quantitá di conoscenze codificate nel testo elettronico supera di gran lungaquella disponibile nei soli dati. Tuttavia la capacitá di sfruttare questo patri-monio di conoscenze é solo all’inizio della sfida. Le aziende che possono trarrevantaggio da questo potenziale avranno sicuramente un vantaggio con una cre-scita maggiore di efficienza. Un passo importante nella realizzazione di questopotenziale é stato quello di strutturare le informazioni in modo significativo. Unprimo passo nell’ottenere una maggior comprensione é quello di utilizzare seg-menti di categorie significative. Ció porta inevitabilmente all’idea di tassonomie- organizzazioni gerarchiche naturali delle informazioni in allineamento con gliobiettivi strategici del business, dell’organizzazione e dei processi.

La ricerca per affrontare questa esigenza di sviluppo sulle tassonomie haconcentrato le tecniche di raggruppamento in gran parte intorno alle tecnichedi clustering.

Il nostro approccio per risolvere questo problema si concentra sulla visualiz-zazione, l’editing e la validazione dei risultati di clustering. Il problema che stia-mo cercando di risolvere é stato definito in letteratura [2] [3], come la convalidadi clustering.

I metodi di convalida sono stati generalmente basati su uno dei tre seguenticriteri: esterni, interni e relativi.

1. I criteri esterni utilizzano in genere un pre-specificato “ground truth”3con la quale siamo in grado di misurare direttamente la qualitá dei nostricluster.

2. I criteri interni si basano su statistiche o misure calcolate da una datatassonomia.

3 Nelle tecniche di apprendimento supervisionato si definisce ground truth l’accuratezzadella classificazione del training set.

23

3. I criteri relativi si basano sul confronto con tassonomie alternative.

É possibile utilizzare un approccio integrando tra loro criteri interni ed ester-ni, in cui nello step finale l’esperto umano agisce come un criterio esterno. Chia-ramente leggere ogni documento e categorizzarlo non é una soluzione praticabile;tuttavia la valutazione da parte di esperti che seguono come guida dei feedbackappropriati puó essere considerata un discreto approccio.

Se utilizziamo un sistema e una metodologia che tramite il clustering generatassonomie, l’utente potrà raffinarle verso un obiettivo desiderato, anche se nonprecedentemente noto. Avremmo la possibilitá di migliorarne la qualità e ilrelativo modello. Descrivendo in maniera chiara le funzionalitá importanti legatealla visualizzazione l’analista avrá tutti i feedback necessari per poter modificarela tassonomia stessa. Andremmo a studiare il nostro approccio alla convalidain modo da garantire all’utente la possibilità di modellarla a suo piacimento edeventualmente sulla base di future classificazioni di documenti.

6.2 Visualizzare le TassonomiePrima che un utente possa andare a modificare o valutare una tassonomia èopportuno capire prima le categorie presenti e le loro relazioni.

Per facilitare il processo di comprensione si rappresentano i documenti dentroun modello di spazio vettoriale, dove ogni documento viene convertito in uninsieme di vettori di frequenze ponderate basate sulle caratteristiche (parole efrasi). Tale spazio viene creato utilizzando il sistema di ponderazione TXN [4].Questo schema evidenzia parole con alta frequenza all’interno di un documentoe normalizza ciascun documento vettore per avere un unità di norma euclidea.La rappresentazione primaria per ogni categoria è il baricentro [5]. Come sivedrá, durante il processo di editing della categoria, non bisogna essere rigorosinel pretendere che ogni documento debba appartenere alla categoria del suobaricentro più vicino, né imporre che debbano appartenere a una sola categoria.

Per fornire una buona comprensione di una tassonomia, che sono general-mente strutture gerarchiche, é necessario fornire una serie di vedute che copronodiversi livelli di dettaglio. Le viste includono un livello globale unico all’internodi un albero (tutti figli di un solo genitore, tra cui la radice) e una vista det-tagliata di ogni singola categoria. Nelle categorie globali la “CategorizzazioneAlbero” presenta le sotto categorie visualizzandole come “cartelle”, che possonoessere espanse. Le “Categorie foglia” sono invece visualizzate come nodi. La se-lezione di una cartella puó portare l’utente verso un piú basso livello della vistadella tabella categoria, che mostra le statistiche relative solo alle categorie chesono sottoclassi immediate della categoria selezionata. La selezione di una fogliao la selezione di una riga nella tabella visualizza tutta la vista Categoria. Questavista fornisce diverse finestre differenti su una singola Categoria che aiutano aspiegare e riassumere il contenuto dei documenti della categoria selezionata.

6.3 Modificare le TassonomieUna volta che il gestore di contenuti comprende il significato delle classi dellatassonomia e il loro rapporto, il passo successivo è quello di fornire strumentiper la rapida evoluzione della tassonomia in base a quelle che sono le esigenze.

L’obiettivo non è quello di produrre una tassonomia “perfetta” per ogni scopopossibile. Tale tassonomia potrebbe non esistere o potrebbe richiedere troppo

24

sforzo per essere ottenuta. Invece si vuole concentrare gli sforzi degli utenti sullacreazione di una tassonomia “naturale piú pratica per lo scopo per cui é statacreata. Non c’é un metodo giusto o sbagliato per fare delle modifiche alla tasso-nomia. É importante che il cambiamento rifletta accuratamente quello che è ilpunto di vista sulla struttura desiderata dell’utente esperto. In questo contesto,l’utente ha sempre ragione. Bisogna fare in modo di permettere all’utente diapportare qualsiasi cambiamento che può essere considerato per lui desiderabile.In alcuni casi tali modifiche possono essere effettuate a livello di categoria, inaltri casi può essere necessaria una modifica più dettagliata sulla categoria diappartenenza. Si deve quindi fornire la capacità di modifica a tutti i livelli diuna tassonomia per consentire all’utente di effettuarla in maniera agevole.

Variazioni del livello di categoria implicano la modifica della tassonomia alivello macro, senza riferimento diretto ai singoli documenti all’interno di ognicategoria.

6.3.1 Unione

Unire due classi significa creare una nuova categoria a partire dall’unione di dueo più categorie esistenti. Un nuovo centroide viene quindi ricavato e non è altroche la media degli esempi combinati. L’utente fornisce alla nuova categoria unnome appropriato.

6.3.2 Cancellazione

Eliminare una categoria (o piú categorie) significa rimuovere la categoria e i suoifigli dalla tassonomia. L’utente deve considerare il fatto che questa operazionepuò avere conseguenze impreviste, dal momento che tutti gli esempi che prece-dentemente appartenevano alla categoria eliminata devono ora essere collocatiin una categoria diversa al livello attuale della tassonomia.

6.3.3 Clustering

In ogni nodo della categorizzazione albero l’utente puó richiedere la creazione disottoclassi tramite il clustering del testo, applicando un algoritmo di clusteringstandard, come k-means [6] [7] al set di documenti rappresentati dalla categoriaselezionata.

All’utente verrà chiesto di fornire un valore per il numero di classi da crea-re. Verranno prodotte automaticamente le sottoclassi derivate dall’applicazionedell’algoritmo di clustering al modello di spazio vettoriale. Ad ogni sottocate-goria ricavata verrà assegnato un nome in base alle caratteristiche che hannodella frequenza nella classe più differente da quella della frequenza di sfondo.Si può applicare questo stesso approccio di clustering ripetutamente in modoricorsivo su ogni categoria derivata fino a raggiungere un criterio di arresto (oin alternativa viene fornita una dimensione minima della categoria). La risul-tante sub-categorizzazione può essere modificata se lo si desidera per riflettereun partizionamento più naturale.

6.3.4 Trascina e rilascia

Dalla categorizzazione albero l’utente può selezionare qualsiasi categoria e tra-scinarla in qualsiasi cartella esistente. Tale operazione va eseguita, ad esempio,

25

quando in una categoria molto specifica viene creato il nodo radice dell’albero,che può naturalmente essere presente in una categoria più generale giá esistente.L’operazione di trascinamento della selezione di una categoria a una cartella haconseguenze per tutte le altre cartelle in una linea diretta dalla radice dell’albe-ro al nodo di destinazione (che guadagna il contenuto del nodo sorgente) e pertutte le altre cartelle in linea diretta formata dalla radice al nodo sorgente (cheperdono il contenuto del nodo di origine).

6.4 Convalidare le tassonomieOgni volta che viene apportata una modifica alla tassonomia è molto importanteper l’utente poter verificare che il cambiamento ha avuto l’effetto desideratosulla tassonomia e che eventuali conseguenze indesiderate sono dovute a effettinon intenzionali. L’obiettivo è quello di assicurare che le categorie siano tuttesignificative, complete, differenziabili in modo tale che i concetti rappresentatidalle sezioni del documento possono essere riportati automaticamente in nuovidocumenti futuri.

6.4.1 Controllo diretto

Il metodo più semplice per convalidare la tassonomia si ottiene tramite l’ispe-zione diretta delle categorie. Controllare alcuni dei documenti meno peculiaricon la tassonomia è un metodo particolarmente utile per accertare rapidamenteche la categoria non contiene alcun documento che non ci appartiene.

Un altro metodo di controllo visivo è quello di guardare i vicini più prossimidella categoria in corso di valutazione. Le aree del documento e la sovrapposi-zione ai margini evidenziano i candidati primari utilizzabili per ulteriori indaginie convalide.

6.4.2 Convalida delle metriche

Sono state condotte numerose ricerche riguardanti la valutazione dei risultatidegli algoritmi di clustering [3] [4]. Anche se le misure ottenute non sono deltutto applicabili alle tassonomie modificate per incorporare la conoscenza deldominio, ci sono alcuni concetti importanti che possono essere applicati da que-sto tipo di ricerca. La rappresentazione vettoriale sul modello di spazio [5] [8]permette di riassumere un livello della tassonomia tramite alcune statisticheutili come:

• Coesione: una misura di somiglianza nella categoria. É calcolata comela distanza media del coseno dei documenti all’interno di un categoriarispetto al baricentro di tale categoria.

• Distinzione: una misura di differenziazione tra le categorie. É calcolatacome uno meno la distanza del coseno della categoria al centroide dellecategorie contigue.

Questi due criteri sono una variazione di quelli proposti da [9]: compattezzae separazione.

Il vantaggio di questo approccio rispetto ad altre tecniche di convalida stati-stica è che sono facilmente calcolabili e comprensibili per un esperto di tassono-mie. Questi parametri si rivelano spesso utili per individuare due potenziali aree

26

di interesse in una tassonomia: le classi “varie” e le categorie diverse aventi con-tenuti simili. Le classi “varie” sono classi contenti una moltitudine di documentii cui argomenti sono molto differenti tra loro. Per tali classi può essere neces-sario suddividere ulteriormente o sotto categorizzare la classe di appartenenza.Per quanto riguarda invece le categorie diverse dal contenuto molto simile, sedue o più classi sono quasi indistinguibili in termini di contenuti possono esserecandidati ideali per fondersi insieme in una singola categoria.

Misure statistiche come la coesione e la distinzione forniscono una buona eapprossimativa misura di come il contenuto della parola in una categoria rifletteil suo significato di fondo.

Ad esempio, se una categoria che l’utente ha creato non è coesa il classificato-re potrebbe imparare a non riconoscere un nuovo documento come appartenentea tale categoria in quanto la categoria non è stata ben definita in termini di con-tenuti di parole. D’altra parte, se una categoria non è ben distinta, allora c’èalmeno un’altra categoria contenente documenti con un vocabolario simile. Ciòsignifica che un classificatore può avere difficoltà a distinguere in quale delle duecategorie simili il documento deve essere posizionato. Naturalmente la coesionee la distinzione sono metriche grezze e relative, non esistendo alcun valore disoglia fisso non si puó stabilire a priori quando una categoria non puó esserecoesa o distinta. In generale ogni volta che viene creata una nuova categoria siconsiglia all’utente di far si che la coesione e la distinzione per la nuova categorianon sia peggiore rispetto alla media dell’attuale livello della tassonomia.

6.4.3 Applicazione classificatori semplici

Metriche quali la coesione e la distinzione forniscono una misura approssima-tiva di quanto bene un dato documento della tassonomia può essere modellatoe utilizzato per classificare degli ulteriori nuovi documenti. Una misura piùaccurata può essere creata mediante l’applicazione di una serie di algoritmi diclassificazione semplici per un campione di formazione dei dati per poi vederecome esattamente tali classificatori lavorano su un equivalente campione astrat-to. Se uno o più classificatori raggiunge un alto livello di precisione per ciascunadelle categorie vi è sufficiente regolarità nel contenuto dei testi per classificareaccuratamente nuovi documenti, supponendo che venga utilizzato l’approccio dimodellazione giusto.

27

Riferimenti bibliografici

[1] D.R. Wallace, R.U. Fujii, “Software Verification and Validation: ItsRole in Computer Assurance and Its Relationship with Software ProjectManagement Standards”, 1989

[2] Dom, B. “Information-Theoretic External Cluster- Validity Measure”,IBM Research Report RJ 10219, 2001

[3] M. Halkidi, Y. Batistakis, M. Vazirgiannis, “On Clustering ValidationTechniques”, 2001

[4] G. Salton, C. Buckley, “Term-weighting approaches in automatic textretrieval”, 1988

[5] R.O. Duda, P. E. Hart, “Pattern Classification and Scene Analysis”,1973

[6] J.A. Hartigan, “Clustering Algorithms”, 1975

[7] E. Rasmussen “Clustering algorithms”, 1992

[8] G. Salton, M. J. McGill, “Introduction to Modern InformationRetrieval”, 1986

[9] J. Berry, G. Linoff, “Data Mining Techniques: For Marketing, Sales,and Customer Support”, 1996

28