Black Box Testing: Partizioni di equivalenza, Analisi dei valori di confine e tabella delle decisioni

Black Box Testing: Partizioni di equivalenza, Analisi dei valori di confine e tabella delle decisioni

Black Box testing

Nella strategia Black Box (Black Box Testing), detta anche data driven o input/output driven, il test-engineer identifica il sistema come una scatola chiusa di cui non conosce il contenuto, ma solamente le funzionalità esterne. Per la costruzione dei test ci si avvale solo delle specifiche fornite per il sistema, ignorando completamente come sia stato realizzato il sistema al suo interno.

Seguendo questo approccio, la ricerca di tutti gli errori presenti nel sistema, così come prevede il testing ottimale del software, implica un criterio di ricerca esaustiva di tutti i possibili input al programma. La ricerca esaustiva risulta però praticamente e teoricamente impossibile in quanto anche la sola esistenza nella specifica di un input numerico irrazionale, comporterebbe la necessità di verificare il comportamento del programma per tutti i possibili numeri irrazionali, soluzione palesemente non realizzabile.

Si comprende quindi come sia impossibile per un software anche banale soddisfare questo criterio ottimale, per cui la ricerca viene limitata ad un numero finito di valori che assicurano un certo grado di sicurezza. L’obiettivo sarà allora quello di ricercare un insieme finito ottimale di valori di input a cui sottoporre il sistema, ottimalità che sarà funzione del rapporto fra il numero di errori scoperti e dalla quantità di test applicati al sistema.

Black Box Testing - Partizioni di equivalenza, Analisi dei valori di confine e tabella delle decisioni

Analizziamo adesso una serie di tecniche che permettono di ricavare i valori di input con cui verificare il software.

Ricerca casuale

È la prima che viene in mente, ma è anche la meno produttiva; la ricerca dei valori di input a cui sottoporre il sistema è condotta secondo criteri di completa casualità. L’unica certezza in questo tipo di testing è l’impossibilità di valutare la bontà del processo di test, poiché non si è fatta alcuna ipotesi che accrediti la scelta di un valore rispetto ad un altro.

Se qualche errore viene rilevato, esso è frutto della fortuna di chi ha condotto il test e pertanto inaccettabile dal punto di vista dell’ingegneria del software; questa tecnica è pertanto da evitare accuratamente.

Partizioni di equivalenza

Per ovviare alla impossibilità di condurre un test esaustivo di tutti i possibili input al programma, per ciascun input viene identificato un insieme finito di classi di equivalenza. Una classe di equivalenza è un intervallo di valori di input che si suppone inducano un comportamento simile nel sistema.

In altre parole, se costruiamo un test prendendo un valore all’interno di una classe di equivalenza, possiamo ragionevolmente estendere il verdetto del test a tutti i valori compresi all’interno della classe di equivalenza. In questo modo si riesce a dominare la quantità di test case da sviluppare per la verifica di un input.

Le classi di equivalenza si dividono ulteriormente in due categorie, a seconda che la classe di equivalenza sia definita dentro o fuori del dominio di definizione dell’input a cui si riferisce; parleremo allora di valori di input validi (valid input classes) o di valori di input non validi (invalid input classes).

Il primo passo è dunque quello di individuare le classi di equivalenza su ciascun input del sistema. Questa operazione è fortemente legata all’esperienza del test-engineer, ma è possibile individuare una serie di linee guida cui fare riferimento durante tale ricerca:

– Se una condizione di input specifica un intervallo di valori, si devono individuare tre differenti classi di equivalenza: una classe di equivalenza che raggruppi i valori compresi nell’intervallo (valid input class) e due classi di equivalenza che raggruppino i valori all’esterno dell’intervallo, una a sinistra ed una a destra (invalid input class).
– Se una condizione di input specifica un insieme di valori, ciascuno dei quali provoca un comportamento diverso del sistema, sarà necessario individuare una classe di equivalenza valida ed una non valida per ciascun valore dell’insieme.
– Se una condizione di input specifica una situazione obbligata, come ad esempio succede quando il primo carattere di un identificatore è necessariamente una lettera, si definiscono una classe di equivalenza valida ed una sui valori non validi.
– Se i valori di una classe di equivalenza sono trattati in maniera difforme dal programma, la classe non è ben definita, per cui è necessario partizionare ulteriormente la classe in classi più piccole ed omogenee.

Sulla base di queste indicazioni si giunge ad identificare per ciascun input l’insieme delle classi di equivalenza a cui istanziare i test case per il sistema. Per ogni classe viene scelto un valore rappresentativo della classe.

La costruzione dei test case avviene raggruppando il maggior numero di classi valide in un unico test, fino a che ne vengono costruiti un numero sufficiente a ricoprire tutte le classi valide. Per ogni classe non valida viene invece istanziato un test in cui la classe considerata è l’unica non valida, per evitare che l’input di un’altra classe non valida possa mascherare gli effetti prodotti dalla classe sotto test.

Questa tecnica di testing presuppone quindi una conoscenza approfondita del dominio di definizione di ciascun input e delle condizioni che governano il comportamento del sistema, informazioni che sono racchiuse all’interno dei documenti di specifica dei requisiti

Analisi dei valori di confine

Questa tecnica, detta anche Boundary Value Analysis, si occupa di verificare il software prendendo in considerazione i valori limite degli intervalli di definizione degli input al sistema.

La motivazione alla base di questa scelta è legata alla frequenza con cui si riscontrano errori legati alle condizioni sugli estremi di un intervallo, si pensi per esempio ad un ciclo dipendente da un valore di input, oppure ad una condizione in cui si abbia una disuguaglianza stretta laddove sia viceversa definita una disuguaglianza lasca.

Gli estremi di ogni classe di equivalenza valida di ciascun input rappresenteranno quindi un test- case ognuno; si cercherà di minimizzare il numero di test case prodotti tramite l’associazione del maggior numero di estremi in ciascun test. Allo stesso modo si può procedere considerando le classi di equivalenza e l’analisi dei confini sui valori di output, risalendo poi agli input che li hanno generati; questa tecnica, sebbene sia più complessa, fornisce dei risultati di test migliori in quanto vengono analizzati tutti i possibili output del sistema, output che sono l’obiettivo del sistema.

L’analisi dei valori di confine prevede quindi una verifica dei valori potenzialmente tralasciati dalle classi di equivalenza, istanziando così un insieme di test case complementari all’insieme generato dall’analisi delle classi di equivalenza.

Grafi Causa-Effetto e tabella delle decisioni

Una debolezza riscontrabile nell’analisi dei confini e nelle partizioni di equivalenza consiste nella mancata analisi delle possibili combinazioni degli input al sistema. Può difatti accadere che un particolare errore non venga evidenziato dalle analisi precedenti poiché legato a una particolare combinazione di condizioni in input, come per esempio il contemporaneo azzeramento dei soli coefficienti di primo e secondo grado in un programma che calcoli le soluzioni di una equazione di secondo grado.

Verificare però tutte le possibili combinazioni di condizioni di input può portare alla creazione di un numero molto elevato di test case, molti dei quali possono non essere significativi per il sistema; i grafi Causa-Effetto (Cause-Effect graphing) offrono un metodo sistematico per selezionare in modo efficiente le condizioni in input da combinare.

Un grafo Causa-Effetto è una descrizione grafica formale nella quale vengono tradotte le specifiche del sistema, usualmente scritte in linguaggio naturale e quindi informali. I nodi del grafo rappresentano le cause e gli effetti identificati in una porzione del software, mentre gli archi rappresentano le relazioni logiche che legano le cause agli effetti. In questo modo è possibile descrivere gran parte delle relazioni che intercorrono fra cause ed effetti ed i vincoli relativi alle cause; sovente è necessario aggiungere anche dei vincoli fra effetti, per cui viene introdotto il vincolo di Mascheramento con lo scopo di descrivere tutte le situazioni in cui il verificarsi di un effetto rende impossibile il verificarsi di un altro effetto.

La costruzione metodica della tabella di decisione avviene secondo la seguente procedura:

1. Creare una riga per ogni effetto e causa del grafo.
2. Per ogni effetto, selezionare un effetto all’interno del grafo.
3. Risalire attraverso il grafo a tutte le combinazioni di cause che producono l’effetto selezionato.
4. Creare una colonna nella tabella di decisione per ogni combinazione di cause.
5. Per ogni combinazione determinare lo stato di tutti gli altri effetti e cause e riportarlo all’interno della tabella.

Sebbene i grafi Causa-Effetto ovvero la costruzione della tabella di decisione produca un insieme di test case molto efficace, normalmente non producono tutti i test case necessari alla fase di test di un sistema; i test prodotti dalla tabella di decisione devono essere affiancati dall’applicazione di test case che indaghino sulle condizioni ai confini dei domini di input o di output, costituendo così un insieme di test che può ritenersi ragionevolmente completo.

Precedente Software testing: Obiettivi e limiti del test software Successivo White Box Testing: Copertura delle istruzioni, decisioni e condizioni

Lascia un commento

*