Attività di test e strategie del testing software di una applicazione

Nello sviluppo di un’applicazione software il testing è un’attività tanto complessa quanto imprescindibile. In genere si compone di più fasi: si inizia con la progettazione dei casi di test, scegliendo particolari parametri di input del sistema e stimando quali saranno i relativi output nel caso in cui il sistema operi secondo le sue specifiche; infine si termina con la valutazione dei risultati ottenuti. Il test avrà avuto successo se il suo obiettivo sarà stato raggiunto: rivelare la presenza di malfunzionamenti nei sistemi. Ma, comunque, nulla garantirà dalla loro assenza.

Non esiste un momento temporale preciso nel progetto di un’applicazione in cui ha inizio il test: l’approccio migliore suggerirebbe di testare il software ad ogni fase dello sviluppo, per collaudare passo dopo passo il comportamento del sistema. Esistono varie strategie di testing: ciascuna di esse agisce su un particolare aspetto. Tra gli aspetti di un sistema più consistenti ci sono:

1. L’analisi delle singole componenti e della loro integrazione: si realizza mediante test di unità e test di interfaccia;
2. La conoscenza delle funzionalità interne: si realizza mediante test “white box” oppure “black box”;
3. La valutazione delle prestazioni: mediante test prestazionale e test di stress;

Strategie per le attività di test

In generale, in un sistema molto complesso sarà difficile (se non impossibile) testare tutte le sue componenti contemporaneamente. Se anche fosse fattibile, probabilmente si manifesterebbero parecchie difficoltà nell’individuare della sorgente dell’errore. Per questo nasce il test più semplice, il test delle unità, che prevede l’analisi di una singola unità del programma per volta. Un’unità può rappresentare un isolato programma, una funzione, una procedura, o anche un modulo. Quando il sistema è composto da diversi oggetti interagenti, si accede alle loro funzionalità attraverso la definizione di un’interfaccia. Effettuare un test su tale interfaccia è fondamentale per verificare il corretto funzionamento dell’intero sistema: gli errori riscontrabili nell’uso di un’interfaccia potrebbero essere molteplici poiché legati alla collaborazione fra elementi diversi,ecc. Dunque, un caso particolare di test delle unità è il test delle interfacce.

Per test strutturale o “white box” si intendono quei casi in cui è nota la struttura interna del programma (moduli, funzioni, procedure,ecc.) e quindi si cerca di scoprire gli errori logici commessi dal programmatore.

Nel test funzionale o “black box” non si ha la conoscenza di come il sistema sia strutturato; esso è visto come una scatola nera. Il test verrà progettato avendo presenti soltanto le specifiche del sistema.

Il test prestazionale si occupa di verificare che il sistema possa supportare una ingente quantità di carico di lavoro. In questo tipo di test, si tende ad aumentare via via il carico, fino a che le prestazioni del sistema diventano intollerabili.

Un’ulteriore strategia di test è il test di regressione, che ha senso effettuare nel momento in cui si apportano modifiche al progetto iniziale. Il termine “regressione” spiega bene il concetto base di questo approccio: verificare se, a seguito di una qualche modifica nel programma, la qualità del software sia regredita, cioè se siano stati introdotti dei difetti non presenti nella versione precedente alla modifica. La strategia consiste nel riapplicare al software modificato i test progettati per la sua versione originale e confrontare i risultati.