Caratteristiche, approccio e utilizzo del testing basato su modelli

Introduzione ai modelli

L’uso di un modello per descrivere il comportamento di un sistema è un vantaggio dimostrato e importante per i team di sviluppo. I modelli possono essere utilizzati in molti modi per tutto il ciclo di vita del prodotto, tra cui: miglioramento della qualità delle specifiche, generazione del codice, analisi dell’affidabilità e generazione di test. Proprio i test basati su modelli sono una tecnica nuova e in evoluzione per generare una suite di casi di test dai requisiti. Gli sviluppatori che usano questo approccio si concentrano su un modello di dati e su di un’infrastruttura di generazione invece che su singoli test manuali. Diversi studi hanno dimostrato come le tecniche di generazione di test combinatorie consentano agli sviluppatori di ottenere un’ampia copertura del dominio di input con un piccolo numero di test.

Testing basato su modelli

L’idea generale dei test basati sul modelli (di sistemi deterministici) è la seguente. Un modello di comportamento esplicito codifica il comportamento previsto di un’implementazione chiamato sistema sotto test, o SUT. I linguaggi di modellazione includono diagrammi di stato, reti di Petri, UML-RT o codice. Vengono selezionate le tracce del modello e queste tracce costituiscono i casi di test per il SUT: input e output previsto. Il modello deve essere più astratto del SUT. In generale, l’astrazione può essere ottenuta in due modi diversi:

1. per mezzo di incapsulamento: strutture di tipo macro come si trovano nei compilatori, nelle chiamate alle librerie, nell’MDA o J2EE;
2. omettendo deliberatamente dettagli e perdendo informazioni come il comportamento temporale. Ora, se il modello non fosse più astratto del SUT nel secondo senso, allora gli sforzi della validazione del modello corrisponderebbe esattamente agli sforzi della validazione del SUT. Bisogna notare inoltre che il termine di validazione viene usato quando un artefatto viene confrontato con requisiti spesso impliciti e informali.

Mentre l’uso dell’astrazione nei test basati sul modelli appare metodicamente indispensabile, e, per motivi di padronanza intellettuale, auspicabile, comporta un costo: i dettagli che non sono codificati nel modello ovviamente non possono essere testati sulla base di questo modello. Inoltre, comporta l’obbligo di colmare i diversi livelli di astrazione tra modello e SUT: l’input al modello, come indicato da un caso di test, si concretizza prima che venga dato al SUT. L’output di quest’ultimo viene astratto prima di essere confrontato con l’output del modello definito dal caso di test. La speranza è che si possa dividere la complessità intrinseca di un sistema in un modello astratto e componenti di driver che realizzano concretizzazioni e astrazioni. La granularità del confronto tra l’output del sistema e del modello dipende dalla precisione desiderata del processo di test: come caso estremo, ogni uscita può essere estratta in base al fatto se sia stata lanciata o meno un’eccezione. In alcune situazioni, questo può essere abbastanza significativo per iniziare ulteriori azioni.

Nella maggior parte dei casi, è necessario un criterio di selezione sull’insieme di tutte le tracce del modello. Le chiamiamo specifiche del caso di test. Queste specifiche sono intensionali: piuttosto che specificare singolarmente ciascun caso di test, si specificano le caratteristiche e alcuni casi di test derivati del generatore automatico o manuale che mostrano le caratteristiche. Gli esempi includono i criteri di copertura, le distribuzioni di probabilità o la definizione di uno stato del modello che si considera interessante. Possono anche essere forniti da requisiti funzionali sotto forma di modelli ambientali ristretti che assicurino che il modello del SUT possa eseguire solo alcuni passi. Questo include anche i modelli di errore. In questo senso, le specifiche per i casi di test possono essere strutturali, stocastiche o funzionali.

La figura seguente illustra l’approccio generale del test basato su modelli. Il test basato su modelli usa modelli astratti per generare tracce (caso di test per una implementazione) in base ad una specifica del caso di test. Questa specifica del caso di test è un criterio di selezione sull’insieme delle tracce del modello (nel caso di sistemi reattivi, un insieme finito di tracce finite deve essere scelto da un insieme infinito di tracce infinite). Poiché i test di derivazione, esecuzione e valutazione sono attività costose, si vorrebbe che questo set fosse il più piccolo possibile. Le tracce generate possono anche essere verificate manualmente per accertare che il modello rappresenta i requisiti di sistema: simile alla simulazione, questa è un’attività di validazione, che riguarda la verifica della presenza o meno di un artefatto (il modello in questo caso) conforme alle effettive esigenze dell’utente. Infine, le tracce del modello, vale a dire i casi di test, sono usate per aumentare la fiducia che l’implementazione corrisponda al modello o per dimostrare che non lo sia. Il testing è quindi un’attività di verifica: l’implementazione viene controllata per correttezza su modelli che può essere interpretato come una specifica di comportamento, e che rappresenta i requisiti formalizzati degli utenti.

Questo approccio solleva immediatamente una serie di interrogativi difficili:

1. Ovviamente, nell’approccio di cui sopra, il modello deve rappresentare fedelmente i requisiti dell’utente, ovvero, il comportamento previsto deve essere valido. Perché dovrebbe scegliere di costruire un modello costoso, convalidarlo, derivarne i test ed eseguirli su di un SUT piuttosto che convalidare direttamente il SUT?
2. Poiché la costruzione di sistemi e di software si verifica (come qualsiasi attività di progettazione) in tempi e costi elevati, possiamo creare un singolo modello per generare sia casi di test che codice di produzione?

Alla prima domanda viene data risposta richiedendo che i modelli siano più astratti, o “più semplici”, rispetto al SUT. Poichè questi modelli sono più astratti, sono più facili da far comprendere, convalidare, mantenere e con più probabilità di essere suscettibili alla generazione dei casi di test. L’approccio sopra descritto per i test basati su modelli viene quindi modificato come segue. La parte di input della traccia di un modello, il caso di test, viene concretizzata (γ nella figura) prima che venga imesso nell’implementazione. Viceversa, l’output del SUT viene astratto (αS nella figura) prima di essere confrontato con l’output del modello. Si noti che questo approccio comporta un costo: aspetti del SUT che sono stati sottratti ovviamente non possono essere direttamente testati sulla base del modello astratto. Alla seconda domanda viene data risposta discutendo su diversi scenari di test basati su modelli che riguardano differenti intrecci e caratteristiche di modelli e codice costruiti.

Approssimativamente, si può dire che una sorta di ridondanza è indispensabile: scegliere di derivare entrambi i casi di test e le implementazioni da un singolo modello richiede di sapere esattamente cosa significa in termini di garanzia di qualità: in questo modo, i generatori di codice e le ipotesi sull’ambiente possono essere verificati.

Si potrebbe obiettare che se il modello dovesse essere comunque valido, allora potremmo generare codice da esso senza necessità di ulteriori test. Sfortunatamente, questo non è un’opzione praticabile in generale. Dal momento che il SUT consiste non solo di un pezzo di codice che deve essere verificato ma anche di un ambiente costituito da hardware, sistema operativo e componenti software proprietari, sarà sempre necessario eseguire dinamicamente il SUT. Questo perché il modello contiene ipotesi sull’ambiente, e questi possono o non possono essere giustificati.