Testing del software: Tecniche di analisi statica e dinamica

Tecnica di Analisi Statica

La prima tecnica che vediamo per il testing del software è l’analisi statica. L’analisi statica è il processo di valutazione di un sistema o di un suo componente basato sulla sua forma, sulla sua struttura, sul suo contenuto o sulla documentazione di riferimento. Ciò significa che la valutazione avviene a prescindere dall’esecuzione del sistema o dell’oggetto che si sta testando.
Nonostante con il termine testing generalmente non ci si riferisca a questa tecnica, l’analisi statica è solitamente il primo controllo effettuato sul codice e sui requisiti applicativi con l’intento di riscontrare anomalie nel prodotto software.

Alcuni esempi di analisi statica sono: la compilazione del codice, revisioni, ispezioni, recensioni, analisi del flusso dei dati e analisi del flusso di controllo.
I compilatori eseguono un analisi statica, per verificare che un programma soddisfi particolari caratteristiche di correttezza per poter generare il codice.
Le anomalie rilevate dal compilatore all’interno del codice possono variare in base al linguaggio di programmazione, ma in genere possono essere identificati: nomi di identificatori non dichiarati, incoerenza tra tipi di dati coinvolti in una istruzione e codice non raggiungibile dal flusso di controllo.

Un altro tipo di analisi statica è il “code reading”, ovvero l’attenta rilettura del codice da parte del programmatore stesso o di un’altra persona.
Questa operazione può portare alla luce nuovi difetti, quali ad esempio: loop infiniti, inefficienza di algoritmi e non strutturazione del codice.
Quando quest’attività viene effettuata da un gruppo di persone preposte a tale mansione, tra cui solitamente almeno uno dei programmatori, e successivamente discussa e approfondita, viene anche chiamata ispezione o revisione.

L’analisi del flusso di controllo è invece una tecnica con cui viene data una rappresentazione del codice in un grafo, dove i nodi denotano istruzioni o predicati, mentre gli archi il passaggio del flusso di controllo.
L’attento esame di tale grafo può evidenziare l’esistenza di eventuali anomalie quali codice irraggiungibile e non strutturazione.
Infine, l’analisi del flusso dei dati esamina l’evoluzione del valore delle variabili durante l’esecuzione di un programma in modo statico, ovvero considerando le operazioni effettuate su tali variabili e non i dati veri e propri in esse contenuti in fase di esecuzione.
E’ importante associare all’analisi statica, anche il rilevamento di difetti generati in tutte quelle operazioni di analisi e progettazione dei requisiti/specifiche per l’applicazione che si intende realizzare.
I difetti che possono presentarsi sia per i requisiti informali, definiti dall’utente finale, che per le specifiche formali, definite dallo sviluppatore o dall’analista, sono ad esempio: ambiguità, contraddittorietà, imprecisione, mancanza.

L’analisi statica dei requisiti e delle specifiche, specialmente se effettuata prima dello sviluppo vero e proprio, può riscontrare un difetto alla radice, riducendo la probabilità di generarne altri e con un conseguente risparmio di tempo, risorse e denaro.

Tecnica di Analisi Dinamica

Tipicamente con il termine testing ci si riferisce all’analisi dinamica, che è il processo di valutazione di un sistema software o di un suo componente basato sull’osservazione del suo comportamento in esecuzione.
La precondizione necessaria per poter effettuare un test è la conoscenza del comportamento atteso per poterlo confrontare con quello osservato.
L’oracolo è quella componente che conosce il comportamento atteso per ogni caso di test e può essere umano, quindi basato sulla conoscenza delle specifiche e sul giudizio personale, oppure automatico, generato dalla definizione di specifiche formali oppure basato sui risultati di un software dello stesso tipo, ma sviluppato da altri.
Altri dati necessari per un’analisi dinamica sono una corretta configurazione del software, che include la specifica dei requisiti, le caratteristiche grafiche e di usabilità desiderate, la struttura dell’implementazione ed il codice sorgente, e la configurazione dei test, che comprende tutta la documentazione relativa al piano di test, le procedure e i casi di test e i tool specifici per il testing.

Come mostrato in figura la prima fase di un’analisi dinamica prevede l’esecuzione di tutte le procedure e dei casi di test, prendendo come input sia la configurazione del software che quella dei test.
I risultati prodotti verranno presi in input dalla seconda fase, che insieme ai valori attesi elaborati da un oracolo darà vita alla vera e propria fase di valutazione.
Questa fase prende solitamente il nome di convalida o verifica, in base al tipo di valutazione eseguito.
La convalida ha lo scopo di esaminare se il sistema costruito risolva i problemi che hanno motivato la realizzazione dell’applicativo, espressi sottoforma di requisiti (informali) definiti dall’utente, mentre la verifica, si occupa di controllare il rispetto delle specifiche (rigorose e formali) prodotte dall’analista a partire dai requisiti iniziali.
La valutazione produce due tipi di risultati: gli errori riscontrati, che verranno dati in input al processo di debug, con lo scopo di correggere tali anomalie, ed una serie di dati sugli indici di errore, che saranno analizzati in un modello di affidabilità, per determinare il grado di affidabilità previsto per l’applicazione.
Una prima classificazione di analisi dinamiche avviene in base all’approccio adottato: il “black box testing” o testing funzionale e il “white box testing” o testing strutturale.
Mentre il testing funzionale è fondato sull’analisi degli output generati dal sistema o dai suoi componenti in risposta ad input definiti sulla base della sola conoscenza dei requisiti di sistema specificati, il testing strutturale richiede un’approfondita conoscenza della struttura del software e del suo codice, a partire dalla quale vengono definiti dei casi di test, gli input ad essi associati ed i risultati attesi.

Il testing funzionale mette in evidenza il comportamento esterno del software, senza sapere cosa accade all’interno di esso, da qui appunto prende il nome di “black box” (scatola nera), alla quale viene passato un determinato input e ne viene estratto un certo output.
Questo tipo di test viene effettuato accedendo al software solamente tramite l’interfaccia utente, oppure tramite interfacce di comunicazione tra processi.
A causa della natura di tale tecnica appare evidente sin da subito che non si conosca la parte del codice che effettivamente si stia testando, con il relativo svantaggio di lasciare alcune parti di codice senza test e altre con test ridondanti, ma con il vantaggio di assicurare la qualità di tutte le funzionalità dell’applicativo in modo indipendente dall’implementazione. Un altro vantaggio del testing a scatola nera sta nel fatto che tale test può essere effettuato anche da persone esterne all’azienda.
Infatti, non sono necessari programmatori esperti e che conoscano gli aspetti interni del software da collaudare.

Pertanto, si possono trovare molti più collaudatori, senza dover investire nell’addestramento.
Tale vantaggio si manifesta in misura ancora maggiore se il software da testare, il codice sorgente e la relativa documentazione sono coperti da segreto industriale.
Il testing strutturale, invece, il software viene visto come una “white box” (scatola bianca), per contrapposizione alla tecnica a scatola nera.
In questa metodologia è richiesta una conoscenza approfondita del codice sorgente, degli algoritmi utilizzati e della struttura interna del software.
Tipicamente il testing strutturale viene eseguito per i test di singoli moduli e per i test delle singole unità in modo automatizzato, ovvero prevedendo procedure e casi di test che invocano procedure vere e proprie dell’applicazione e raccolgono dati durante la loro esecuzione.
I test a scatola bianca possono essere scritti nello stesso linguaggio di programmazione dell’applicativo, oppure con un linguaggio in grado di interfacciarsi con quest’ultimo.
L’obiettivo della selezione dei casi di test e dei dati di input è quello di causare l’esecuzione di specifici punti del software.
Le tecniche di testing strutturale sono in genere fondate sull’adozione di metodi di copertura di tali punti: istruzioni, procedure e porzioni di codice che compongono la struttura dei programmi.
Per copertura si intende la definizione di un insieme di casi di test, ed in particolare dati di input, in modo tale che tutti gli oggetti che compongono la struttura del programma applicativo siano attivati almeno una volta nell’esecuzione dei casi di test.

Il collaudo a scatola bianca, siccome richiede l’interfacciamento con le singole procedure, può essere effettuato solamente da un programmatore, anche se non necessariamente un membro del gruppo che ha sviluppato il software da collaudare.
Normalmente è effettuato comunque da un membro dell’organizzazione che sviluppa il software.
Un vantaggio del collaudo a scatola bianca è che permette di sondare dettagliatamente tutte le casistiche che possono presentarsi in modo facile ed efficiente grazie all’automazione.
Un altro vantaggio è che è più facile il debugging, cioè passare dal malfunzionamento alla correzione del difetto, in quanto la segnalazione del malfunzionamento normalmente indica il punto del codice e i valori delle variabili per cui il malfunzionamento si è manifestato.