Costruire casi di test è difficile, costoso e tedioso. Può facilmente richidere diversi mesi di lavoro. Gli sviluppatori di sistemi e i clienti che devono accettare un sistema necessitano di strumenti, sia software che metodologici per semplificare la fase di testing di un sistema. Siccome il testing richiede molte risorse e quindi è molto costoso, la sua automatizzazione può ridurre significativamente il costo dello sviluppo SW [Ferguson et al. 96]. Sfortunatamente, la maggior parte dei sistemi non fornisce un supporto automatico per la generazione dei casi di test [Offutt et al. 95]. Lo stato attuale della ricerca mostra che c’è stato un maggior progresso nella direzione del testing software che in quello del generazione di casi di test a partire dalle specifiche, piuù interessante relativamente al test di accettazione dei sistemi di automazione. Nel testing del codice, il codice stesso è usato per generare i casi di test. Questo approccio al testing, tipicamente white box, consente di analizzare la correttezza di un programma considerandone il funzioamento interno. In questo approccio i casi di test cercanodi esercitare tutti deli elemnti di un programma, garantendo la copertura di del codice. Il tool più noto che segue l’approccio code based è Godzilla che implementa il constraint-based testing. Nel mondo object oriented, i metodi principali includono il testing dei metodi, il testing delle classi, il testing dei cluster e il testing di sistema. L’approccio code based è essenziale nel testing del codice di un’applicazione, ma non copre tutte le esigenze di verifica di correttezz di un sistema. Nella verifica di correttezza e in particolare nel test di accettazione, è essenziale considerare gli obiettivi, o requisiti, di un sistema. La verifica di correttezza di un sistema si deve quindi basare su una specifica dei requisiti del sistema stesso che costituisca il riferimento corretto. La generazione di casi di test basata su specifica è considerata black box in quanto il sistema è visto come una scatola nera che trasforma gli ingressi nelle uscite ed è basata su quello che il sistema dovrebbe fare. Ciò nonostante approcci gray box, in cui non si considera solo l’IO del sistema ma anche alcuni aspetti interni possone essere adottati nella pratica. TRIO in particolare consente di specificare i requisiti di un sistema in modo dichiarativo e di generare casi di test sia di tipo black-box che grey-box. Tale approccio consente di affrontare la verifica di un sistema sia considerando la trasformazione dei suoi ingrssi , che forzando determinati comportamenti interni, ad esempio per garantire la correttezza di una tecnica di fault tolerance. L’uso di un sistema dipende fortemente dalla sua affidabilità che necessita di un approfondito testing del sistema e che può beneficiare enormemente dalla generazione automatica di casi di test a partire dalla specifica dei requisiti. Nonostante la mancanza di strumenti commerciali nell’area della generazione di casi di test da specifica, questa costituisce un aspetto fondamentale del testing.

Questo rapporto presenta due diversi approcci al testing specification based :SOFL, un metodo di generazione di casi di test basato su specifiche predicative e DAS-BOOT un metodo applicabile a specifiche object oriented. L’annesso presenta un metodo di testing basato su TRIO e messo a punto nel ambito del progetto EC-FAST. L’approccio e le tecniche presentate consentono di generare casi di test per la verifica di sistemi industriali specificati utlizzando l’approccio dichiarativo TRIO. Questo approccio consente di formalizzare i requisiti di un sistema real time reattivo e di analizzare la sua correttezza e adeguatezza utlizzando tecniche di generazione di modelli. Nell’ambito del progetto FAST sono stati sviluppati dei meccanismi di erifica e validazione delle specifiche e per la derivazione di casi di test per l’assessment di un sistema rispetto alle sue specifiche iniziali. L’annesso, dopo aver inquadrato il tema del testing basato su specifica, presenta le tecniche sviluppate e i futuri sviluppi