Non vi è niente che ha un effetto maggiore sulla soddisfazione dell'utente nei confronti del software di una vista
chiara delle proprie aspettative in modo che sia possibile verificarle e convalidarle. Gli scenari di test rispecchiano
i requisiti che occorre verificare. La verifica di tali requisiti, tuttavia, può essere effettuata in modo differente e
tramite tester differenti. Ad esempio, l'esecuzione del software per verificare funzione e prestazioni può essere
effettuata tramite un tester che utilizzi tecniche di test automatizzate; la sequenza di spegnimento di un sistema di
computer può essere eseguita tramite osservazione e test manuali, mentre le vendite e le azioni di mercato (requisiti
del prodotto) verranno eseguite tramite misurazione del prodotto e delle vendite competitive.
Dal momento che non è detto che sia possibile verificare (o che si sia responsabili) tutti i requisiti, è importante
per il successo del progetto selezionare i requisiti più appropriati o critici per il test. I requisiti scelti per la
verifica saranno una proporzione tra costo, rischio e necessità di verificare il requisito.
L'identificazione degli scenari di test è importante per diverse ragioni.
-
Gli scenari di test costituiscono la base su cui progettare e sviluppare gli script di test.
-
La complessità della verifica è proporzionale al numero di scenari di test. Una maggiore fiducia nella qualità del
prodotto e nel processo di test si ottiene quando aumenta il numero di scenari di test, poiché ogni scenario di
test rispecchia uno scenario, una condizione o un flusso differente attraverso il prodotto.
-
Una misura principale della completezza del test è la copertura basata sui requisiti, in base al numero di scenari
di test identificati, implementati e/o eseguiti. Un'istruzione del tipo "il 95% dei test critici è stato eseguito e
verificato" è più significativa rispetto a "Siamo al 95% dei test".
-
La scala di impegno del test è proporzionale al numero di scenari di test. Con un'interruzione intelligente degli
scenari di test, la sincronizzazione delle fasi di riuscita del ciclo di test può essere calcolata in modo più
preciso.
-
I tipi di sviluppo e progettazione di test e le risorse necessarie sono ampiamente regolati dagli scenari di test.
Gli scenari di test vengono spesso suddivisi in categorie o classificati per tipo o requisito di test per il test a cui
sono associati e varieranno di conseguenza. La pratica è sviluppare almeno due scenari di test per ogni requisito del
test:
-
Uno scenario di test dimostrerà che il requisito è stato raggiunto. Questo è uno scenario di test positivo.
-
Un altro scenario di test, che rispecchia dei dati o una condizione imprevista, anomala e inaccettabile per
dimostrare che il requisito viene ottenuto solo alla condizione desiderata e che viene indicato come caso di test
negativo.
la verifica dell'unità richiede sia la struttura interna dell'unità che le caratteristiche della sua funzionalità. La
verifica della struttura interna richiede una conoscenza delle modalità di implementazione dell'unità e i test
basati su tale conoscenza sono noti come test di white-box. La verifica delle caratteristiche di funzionalità di
un'unità sono incentrati sulle funzionalità esterne osservabili dell'unità senza conoscenza o riguardo per
l'implementazione. I test basati su questo approccio vengono indicati come test di black-box. Le derivazioni degli
scenari di test basate su entrambi gli approcci vengono descritte di seguito.
In teoria, si consiglia di testare ogni possibile percorso attraverso il codice. Il raggiungimento di tale obiettivo,
in tutte le unità estremamente semplici, non è pratico o è pressoché impossibile. Come minimo, si consiglia di
sperimentare ogni percorso DD (decision-to-decision) almeno una volta, con il risultato di eseguire le
istruzioni almeno una volta. In genere, una decisione è un'istruzione di tipo if, mentre un percorso DD è un percorso
tra due decisioni.
Per ottenere questo livello di copertura test, si consiglia di scegliere i dati del test in modo che ogni decisione
venga valutata in tutti i modi possibili. Verso la fine, gli scenari di test dovrebbero verificare quanto segue:
-
ogni espressione Booleana viene valutata come true e false. Ad esempio, l'espressione (a<3) OR
(b>4) restituisce come risultato quattro combinazioni di true/false
-
Ogni loop infinito viene utilizzato almeno zero volte, una volta e più volte.
Utilizzare tool di copertura del codice per identificare il codice non esercitato dal test di tipo white box.
Contemporaneamente al test di tipo white-box è necessario effettuare il test di affidabilità.
Esempio:
Presupporre l'esecuzione di un test della struttura su un membro della funzione nella classe Serie di numeri
interi. Il test, con l'aiuto di una ricerca binaria, controllerà se la serie contiene un numero intero specificato.
La funzione del membro e il relativo diagramma di flusso corrispondente. Le frecce tratteggiate illustrano in che modo
utilizzare due scenari di test per eseguire tutte le istruzioni almeno una volta.
In teoria, per eseguire un test completo di un'operazione, lo scenario di test dovrebbe attraversare tutte le
combinazioni di instradamenti nel codice. Nel membro, esistono tre instradamenti alternativi all'interno del
loop while. Lo scenario di test può attraversare il loop diverse volte o nessuna. In tal caso, verrà rilevato un
solo instradamento attraverso il codice. Se attraversa il loop una sola volta, verranno rilevati tre instradamenti. Se
lo attraversa due volte, ne verranno rilevati sei e così via. Quindi, il numero totale di instradamenti sarà
1+3+6+12+24+48+..., che in pratica è un numero ingestibile di combinazioni di instradamenti. Ecco perché è necessario
scegliere una sottoserie di tutti gli instradamenti. In questo esempio, è possibile utilizzare due scenari di test per
eseguire tutte le istruzioni. In uno scenario di test, si potrebbe scegliere Serie di numeri interi =
{1,5,7,8,11} e t = 3 come dati del test. Nell'altro scenario di test, si potrebbe scegliere
Serie di numeri interi = {1,5,7,8,11} e t = 8 .
Consultare Tecnica: Test dell'unità per ulteriori informazioni.
Test di black-box
Lo scopo di un test di black-box è verificare la funzionalità specifica dell'unità senza esaminare il modo in
cui l'unità implementa tale funzionalità. I test di tipo black-box si focalizzano e si basano sull'input e l'output
dell'unità.
Il partizionamento dell'equivalenza è una tecnica per la riduzione del numero necessario di test. Per ogni
operazione, si consiglia di identificare le classi di equivalenza degli argomenti e gli stati degli oggetti. Una
classe di equivalenza è una serie di valori per cui si suppone che un oggetto si comporti in modo simile. Ad
esempio, una Serie ha tre classi equivalenti: vuota, alcuni elementi e piena.
Utilizzare tool di copertura del codice per identificare il codice non esercitato dal test di tipo white box.
Contemporaneamente al test di tipo black-box è necessario effettuare il test di affidabilità.
Le due sottosezioni successive descrivono come identificare gli scenari di test selezionando i dati del test per
specifici argomenti.
Scenari di test basati su argomenti di input
Un argomento di input è l'argomento utilizzato da un'operazione. Si consiglia di creare gli scenari di test
utilizzando gli argomenti di input per ogni operazione, per ognuna delle seguenti condizioni di input:
-
Valori normali da ogni classe di equivalenze.
-
Valori sul boundary di ogni classe di equivalenze.
-
Valori esterni alle classi di equivalenze.
-
Valori non validi.
Trattare sempre lo stato di un oggetto come argomento di input. Se, ad esempio, si testa un'operazione di
aggiunta su un oggetto Serie, occorre testare l'aggiunta con valori provenienti da tutte le classi
di equivalenze Serie, ossia con una Serie completa, con alcuni elementi in Serie e con una
Serie vuota.
Scenari di test basati su argomenti di output
Un argomento di output è un argomento che indica il cambiamento di un'operazione. Un argomento può essere di
output e di input. Selezionare l'input in modo che si ottenga l'output secondo ognuno dei seguenti elementi.
-
Valori normali da ogni classe di equivalenze.
-
Valori sul boundary per ogni classe di equivalenze.
-
Valori esterni alle classi di equivalenze.
-
Valori non validi.
Trattare sempre lo stato di un oggetto come argomento di output. Se, ad esempio, si testa un'operazione di
rimozione su un Elenco, occorre scegliere i valori di input in modo che Elenco sia pieno, contenga
qualche elemento e sia vuoto dopo l'esecuzione dell'operazione (testare con valori provenienti da tutte le relative
classi di equivalenza).
Se l'oggetto è controllato dallo stato (reagisce in modo differente a seconda del proprio stato), si consiglia di
utilizzare una matrice di stato come quella nella seguente figura.
Una matrice di stato per la verifica. E' possibile testare tutte le combinazioni di stato e le emissioni sulla base di
questa matrice.
Consultare Tecnica: Test dell'unità per ulteriori informazioni.
|