Strategia di Test: Testing top-down e bottom-up

Il testing

L’attività di test costituisce la fase più critica dell’intero ciclo di vita del software: dallo unit test, effettuato dal programmatore sul componente appena sviluppato, al system test effettuato dal capo progetto sull’intera applicazione, qualsiasi carenza o superficialità può indurre gravi inaffidabilità del software. Per disporre di un software robusto e pronto a successive evoluzioni è sempre indispensabile un test accurato. Infatti solo l’esecuzione di un esauriente piano di test, dopo ogni modifica o evoluzione, è in grado di fornire garanzie sufficienti sulla non regressione del software in uso. Tuttavia, a causa del suo elevato costo (può incidere anche per il 50% sul costo del prodotto software), il test è spesso eseguito in modo superficiale ed incompleto, rendendo così inaffidabile il software ed inducendo una continua crescita dei costi di manutenzione.
La fase di test e collaudo serve a verificare che il prodotto software sia corretto.

Obiettivo del testing

L’obiettivo di questa fase non deve essere quello di far vedere che il software non contiene errori, bensì di trovarne il maggior numero possibile. Infatti per grandi programmi è utopistico aspettarsi che il codice venga prodotto senza errori.
Per raggiungere questo scopo non è opportuno far testare il codice allo stesso team che lo ha prodotto, infatti si assegna di solito un team specifico per il test.

Strategia di test

Come la progettazione anche il test può essere effettuato top-down oppure bottom-up.

Con la strategia bottom-up vengono prima collaudati i moduli di più basso livello nella gerarchia prodotta dalla progettazione, si tratta cioè delle unità più piccole ed elementari che compongono il programma.
Quando sono valutati corretti, si passa al livello superiore che viene testato utilizzando le funzionalità del precedente livello, si risale quindi così fino al sistema intero.

Si tratta di un approccio che richiede alcune complicazioni: generalmente sono necessari dei driver, cioè del software ausiliario che simula la chiamata ad un modulo generando dati da passare come parametri. I driver fanno le veci della parte di codice non ancora integrata nella porzione testata del programma: la parte alta della gerarchia dei moduli.

Vantaggi e svantaggi della strategia bottom-up:

1. Il processo di test ed integrazione delle unità è intuitivamente più semplice da realizzare .
2. Più tardi viene scoperto un errore, più è costoso eliminarlo, in quanto richiede la sua correzione, solitamente con un modulo foglia e la ripetizione parziale del test fino ai moduli nei quali è stato trovato l’errore.

L’approccio top-down si comporta in modo diametralmente opposto. Inizialmente si testa il modulo corrispondente alla radice, senza utilizzare gli altri moduli del sistema. In loro vece vengono utilizzati dei simulatori, detti stub, si tratta di elementi che possono restituire risultati casuali, richiedere i dati al collaudatore, possono essere una versione semplificata del modulo.
Dopo aver testato il modulo radice della gerarchia si integrano i suoi figli diretti simulando i loro discendenti per mezzo di stub. Si prosegue in questo modo fino a quando non vengono integrate tutte le foglie della gerarchia.

Vantaggi e svantaggi della strategia top-down.

1. Vengono scoperti prima gli errori più costosi da eliminare. Ciò risulta particolarmente utile se la progettazione è anch’essa di tipo top-down e le fasi di progettazione, realizzazione e test sono parzialmente sovrapposte: un errore di progetto nella parte alta della gerarchia può essere scoperto e corretto prima che venga progettata la parte bassa
2. In ogni istante è disponibile un sistema incompleto ma funzionante
3. Gli stub possono essere costosi da realizzare

Come già per la progettazione, viene solitamente adottata una soluzione di compromesso tra le due strategie, per attenuare gli inconvenienti che ognuna presenta.

Con entrambe le metodiche non è conveniente integrare ad ogni passo il maggior numero possibile di moduli. Ad esempio in una strategia bottom-up testare i figli di un modulo e poi integrarli tutti assieme con il padre per testare questo, porta a codici non funzionanti senza una precisa idea di dove sia l’errore. Risulta invece conveniente introdurre i moduli testati uno alla volta, si riesce in questo modo a localizzare meglio gli errori. In generale si osserva che è più conveniente effettuare test frequenti e brevi.