Cos’è e come automatizzare le attività di test software

L’automazione è tutto ciò che è possibile gestire mediante dei meccanismi che riducono o addirittura sostituiscono l’intervento dell’uomo.
Sebbene spesso si faccia uso dell’automazione inconsapevolmente, sono davvero innumerevoli i vantaggi per la società moderna discesi da questa tecnologia, fra tutti l’ottimizzazione dei tempi e della qualità di esecuzione delle operazioni. Grazie allo sviluppo tecnologico, l’automazione è stata applicata anche al processo di test del software. L’automazione del test software è l’insieme delle operazioni svolte da un apposito strumento software per controllare il corretto funzionamento di un altro software o applicazione. Automatizzare un test è fondamentale per compiere un lavoro più rapido ed efficace. Si pensi soltanto a quanto si riduce il rischio di incorrere in errori non rilevati dall’uomo! E’ straordinario oppure no?

Essenzialmente, sono tre le aree in cui l’automazione interviene:

1. Definizione dei casi di test;
2. Esecuzione del test;
3. Valutazione dell’esito del test.

Definizione dei casi di test

Un test non si improvvisa, ma va studiato e preparato. Affinché sia efficace, deve essere realizzato tenendo presenti le caratteristiche del programma da esaminare. La definizione dei casi di test è perciò mirata a progettare un particolare contesto di esecuzione, selezionando un insieme di dati di input da fornire al programma. Definire i casi di test manualmente è sicuramente un’attività lunga e complessa.
L’uso dell’automazione già a partire da questa fase da luogo a molti vantaggi, ma comunque bisogna porre attenzione ai casi di test generati, che potrebbero risultare poco efficaci rispetto al contesto e pertanto inutili. Allora è necessario che essi siano definiti in modo meticoloso e ragionato, e supportati da strumenti software particolarmente avanzati. Tuttavia, per sperare in un esito positivo del test, non è necessario disporre di una gran quantità di casi su cui lavorare. E’ più conveniente averne in numero inferiore, ed eventualmente combinarli per ottenerne di nuovi. Così si riduce sensibilmente il volume dei casi da valutare e quindi il tempo impiegato nel test.

Esecuzione del test

L’esecuzione di un test è governata da una struttura gerarchica chiamata
scaffolding, che si compone di tre livelli:

1. Driver;
2. Unità oggetto del test;
3. Stub.

Un driver (o modulo guida) simula la parte di programma che invoca l’unità da testare, in particolare preparandone l’ambiente di esecuzione (per esempio, crea ed inizializza variabili globali, apre file, ecc.). Lo stub (o modulo fittizio) simula la parte di programma invocata dall’unità: verifica l’ambiente di esecuzione preparato dal driver e l’accettabilità dei parametri passati e restituisce i risultati. Infine, il driver verifica i risultati ottenuti e li memorizza.
Per l’esecuzione automatica dei test si utilizzano appositi framework (strutture di supporto al software complete di librerie e ambiente di sviluppo integrato) che simulano il comportamento descritto. Oggi esistono innumerevoli framework dediti all’attività di test (definizione test-cases, esecuzione test, valutazione esito). Si valuterà in particolar modo un framework della famiglia XUnit, che nasce proprio come supporto open source per il test di applicazioni web: HtmlUnit. Oltre a questo, esistono altri strumenti di natura diversa ma comunque efficienti: uno di essi è Selenium, che è implementato come estensione del browser Mozilla Firefox. I due strumenti qui citati verranno ripresi nel corso della trattazione.

Valutazione dell’esito del test

Per poter valutare i risultati del test è necessario conoscere il comportamento atteso del programma e confrontarlo con quello osservato. E’ questo il concetto su cui si basa l’oracolo, che conosce il comportamento atteso per ogni caso di test. Utilizzando uno specifico set di dati di ingresso al sistema, l’oracolo identifica un determinato set di dati di uscita, che rappresentano il comportamento atteso.

L’esito di un test può essere valutato secondo due diverse metriche:

1. L’efficacia di un test, valutata come copertura dei casi di test;
2. L’utilità di un test all’interno dell’intero progetto, valutata come percentuale di copertura del codice (code coverage).

Il primo caso è presto spiegato: se durante il processo di test si riescono a “coprire” tutti i test case progettati, allora si è raggiunta una buona copertura per questi. Ciò vuoldire che il software è stato testato in modo corretto e che si è scoperto un numero elevato di malfunzionamenti. Nel secondo caso, invece, si cerca di stabilire la percentuale di linee di codice del progetto che sono state eseguite dai test. In un test solo il 100% di code coverage garantisce di aver individuato tutti i malfunzionamenti. Ma questo è un evento quantomeno improbabile.