Nulla ha maggiore influenza sulla capacità dei team del progetto di garantire la soddisfazione degli stakeholder nei
confronti del software, che la disponibilità di una chiara specifica delle aspettative dei suddetti stakeholder. Con o
senza una buona serie di specifiche dei requisiti, gli scenari di test sono un artefatto che aiuta a riflettere le
aspettative degli stakeholder, consentendo di verificarle e convalidarle.
Quando è disponibile una serie utile di requisiti, il team del test dovrà pianificare i test che convalideranno tali
requisiti in modo appropriato. Tenere presente che la convalida del software rispetto ai requisiti potrebbe essere
eseguita in modo differente a seconda del tipo di requisito. Ad esempio, l'esecuzione del software per convalidare i
relativi requisiti funzionali e delle prestazioni potrebbe avvenire per mezzo di un tester che utilizzi tecniche di
test automatizzate, mentre la verifica di un requisito della configurazione come lo spegnimento del sistema del
computer host dovrebbe essere eseguita utilizzando tecniche manuali.
Dal momento che non è detto che sia possibile verificare (o che si sia responsabili) tutti i requisiti, è importante
incentrarsi sui requisiti più appropriati o critici per l'ambito dell'impegno di lavoro corrente. I requisiti scelti
per la verifica saranno una proporzione tra costo, rischio e necessità di verificare il requisito e saranno limitati
dall'ambito dell'iterazione corrente.
Sebbene i requisiti siano una fonte importante da cui è possibile far derivare i test, non sono l'unica. Infatti, in
molti casi non saranno sufficienti per fornire una base completa da cui sviluppare i test. E' inoltre opportuno
considerare gli scenari di test basati su fonti di informazioni come rischi, vincoli, tecnologie, richieste di modifica
(difetti), errori e così via.
Consultare Concetto: Proposte di test per ulteriori informazioni sulle modalità per generare
proposte da cui far derivare i test.
L'identificazione degli scenari di test è utile per diverse ragioni.
-
Gli scenari di test possono essere utilizzati come base su cui progettare e implementare i test reali. Il tempo
impiegato per considerare lo scenario di test consente di comprendere meglio i requisiti di progettazione e di
implementazione e ha il potenziale di far risparmiare tempo nelle attività di progettazione e di implementazione.
-
Alcuni test sono particolarmente complessi o dettagliati. I test di questo tipo ottengono vantaggi da una
considerazione attenta e anticipata prima di avviare l'implementazione del test e gli scenari di test e gli
artefatti di progettazione del test sono ottimi tool per l'esplorazione di tali considerazioni.
-
La complessità della verifica è, generalmente, considerata proporzionale al numero di test. Si ottiene più
sicurezza nel processo del test stesso quando la complessità potenziale della verifica può essere pensata in base
al numero di scenari di test identificati.
-
Una misura della completezza dell'impegno del test si basa sul monitoraggio della copertura rispetto ad una serie
di elementi motivante. La creazione di report della copertura può essere basata su misure come il numero di scenari
di test identificati e il numero di test implementati e/o eseguiti o la quantità di impegno rispetto ad ogni
scenario di test.
-
La scala e la complessità di impegno del test è, in un certo modo, proporzionale al numero di scenari di test. Con
un partizionamento degli scenari di test, l'impegno di test può essere considerato attentamente a un livello di
granularità più preciso.
-
I tipi di sviluppo e progettazione di test e le risorse necessarie sono in parte regolati dal numero e dalla
complessità degli scenari di test.
Tuttavia, esistono alcune questioni che vale la pena considerare relativamente agli scenari di test:
-
Non tutti i test sono sufficientemente complessi per garantire il sovraccarico di creazione di un artefatto di test
che è necessario esaminare e gestire: il test è talmente semplice che una descrizione testuale breve è sufficiente
per comunicare quanto richiesto. In alcuni casi, la maggior parte di scenari di test potrebbe rientrare nella
categoria. Il tempo impiegato per documentare un vasto numero di scenari di test semplici potrebbe togliere altro
tempo ad attività di verifica più importanti.
-
Alcune delle proposte di test iniziali vengono, in seguito, invalidate da un certo punto di vista. Ciò significa
che alcuni degli scenari di test inizialmente basati su tali proposte verranno abbandonati. Tale realtà indica che
qualsiasi lavoro eseguito per documentare gli scenari di test in dettaglio potrebbe essere poi abbandonato e i
report di copertura basati sugli scenari di test dovranno tenere conto di tale situazione. Come tale, potrebbe
essere meglio basare la creazione di report di copertura dei test su questioni di livello superiore rispetto agli
scenari di test e trattare tali scenari come artefatti interni del team del test, utilizzati secondo le necessità.
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. Un metodo euristico di identificazione degli scenari di test inizia con le
seguenti operazioni:
-
dimostrazione che il requisito è stato ottenuto (scenario di test positivo)
-
dimostrazione che il requisito viene ottenuto solo alle condizioni desiderate, indicato come test negativo.
Tale scenario di test rispecchia dati o condizioni impreviste, anomale o inaccettabili a cui potrebbe essere
soggetto il software.
Gli scenari di test per la verifica funzionale derivano dai casi d'uso dell'obiettivo del test (consultare Prodotto di lavoro: Caso d'uso). Si consiglia di sviluppare gli
scenari di test per ogni scenario di casi d'uso. Tali scenari vengono identificati tramite la descrizione dei percorsi,
attraverso il caso d'uso, che attraversano i flussi alternativi e di base iniziano per terminare attraverso il caso
d'uso.
Nel seguente diagramma, ad esempio, ogni percorso differente attraverso un caso d'uso che riflette i flussi alternativi
e di base viene rappresentato con le frecce. Il flusso di base, rappresentato dalla linea retta nera è il percorso più
semplice attraverso il caso d'uso. Ogni flusso alternativo inizia con il flusso di base e, quindi, in base a una
specifica condizione, viene eseguito il flusso alternativo. E' possibile che i flussi alternativi si ricongiungano al
flusso di base (flusso alternativo 1 e 3), abbiano origine da un altro flusso alternativo (flusso alternativo 2) o
terminino il caso d'uso senza ritornare a un flusso (flussi alternativi 2 e 4).
Flussi di eventi di esempio per un caso d'uso
Dopo ogni possibile percorso attraverso il caso d'uso nel diagramma precedente, è possibile identificare i differenti
scenari dei casi d'uso. A partire con il flusso di base e, combinando tale flusso con flussi alternativi, è possibile
identificare i seguenti scenari dei casi d'uso:
Scenario 1
|
Flusso di base
|
|
|
|
Scenario 2
|
Flusso di base
|
Flusso alternativo 1
|
|
|
Scenario 3
|
Flusso di base
|
Flusso alternativo 1
|
Flusso alternativo 2
|
|
Scenario 4
|
Flusso di base
|
Flusso alternativo 3
|
|
|
Scenario 5
|
Flusso di base
|
Flusso alternativo 3
|
Flusso alternativo 1
|
|
Scenario 6
|
Flusso di base
|
Flusso alternativo 3
|
Flusso alternativo 1
|
Flusso alternativo 2
|
Scenario 7
|
Flusso di base
|
Flusso alternativo 4
|
|
|
Scenario 8
|
Flusso di base
|
Flusso alternativo 3
|
Flusso alternativo 4
|
|
Nota: per semplicità, gli scenari 5, 6 e 8 descrivono solo una singola esecuzione del loop indicato dal
flusso alternativo 3.
La derivazione degli scenari di test per ogni scenario viene eseguita identificando la condizione specifica che causerà
l'esecuzione di tale specifico scenario del caso d'uso.
Ad esempio, si supponga che il caso d'uso descritto nel suddetto diagramma indichi quanto segue per il flusso
alternativo 3:
"Questo flusso di eventi si verifica se l'importo di dollari immesso nella precedente fase 2, "Immettere importo da
prelevare", è superiore al saldo di conto corrente. Il sistema visualizza un messaggio di avvertenza e quindi si
ritorna al flusso di base della fase 2 "Immettere importo da prelevare", in cui il cliente della banca può immettere un
nuovo importo da prelevare."
Con queste informazioni, è possibile iniziare a identificare gli scenari di test necessari per eseguire il flusso
alternativo 3:
ID scenario di test
|
Scenario
|
Condizione
|
Risultato previsto
|
ST x
|
Scenario 4
|
Fase 2 - Importo del prelievo > Saldo del conto
|
Ricongiungere il flusso di base alla fase 2
|
ST y
|
Scenario 4
|
Fase 2 - Importo del prelievo < Saldo del conto
|
Non esegue il flusso alternativo 3, acquisisce il flusso di base
|
ST z
|
Scenario 4
|
Fase 2 - Importo del prelievo = Saldo del conto
|
Non esegue il flusso alternativo 3, acquisisce il flusso di base
|
Nota: gli scenari di test mostrati sono molto semplicistici, perché non sono state fornite altre informazioni.
In realtà, gli scenari di test sono raramente così semplici.
Di seguito viene fornito un esempio più realistico di derivazione degli scenari di test dai casi d'uso:
Esempio:
Attori e casi d'uso in uno sportello automatico.
La seguente tabella contiene il flusso di base e alcuni flussi alternativi per il caso d'uso Prelievo di contanti nel
diagramma precedente:
Flusso di base
|
Questo caso d'uso inizia con lo sportello automatico nello stato di Pronto.
-
Inizio del prelievo - il cliente inserisce la carta nel lettore dello sportello
automatico
-
Verifica della carta - lo sportello automatico legge il codice del conto dalla striscia
magnetica sulla carta e controlla se è possibile accettarla.
-
Immissione del codice PIN - lo sportello automatico richiede il codice PIN del cliente (4
cifre)
-
Verifica PIN e codice del conto - Il PIN e il codice del conto vengono verificati per
determinare se il conto è valido e e se il PIN immesso è corretto per il conto. Per tale
flusso, il conto è valido e il PIN associato ad esso è corretto.
-
Opzioni dello sportello automatico - Lo sportello automatico visualizza le differenti
alternative disponibili in questo sportello automatico. In questo flusso, il cliente
della banca seleziona sempre "Prelievo di contanti".
-
Immissione dell'importo - Lo sportello automatico richiede l'importo da prelevare. Per questo
flusso, il cliente seleziona un importo prestabilito ($10, $20, $50 o $100).
-
Autorizzazione - Lo sportello automatico avvia il processo di verifica con il sistema bancario
inviando l'ID carta, il PIN, l'importo e le informazioni sul conto come transazione. Per
questo flusso, il sistema bancario è online e risponde con l'autorizzazione a completare il
prelievo di contanti con successo e aggiorna il saldo del conto di conseguenza.
-
Distribuzione - Il denaro viene distribuito.
-
Restituzione carta - La carta viene restituita.
-
Ricevuta - La ricevuta viene stampata e fornita. Lo sportello automatico aggiorna, di
conseguenza, il log interno.
Il caso d'uso termina con lo sportello automatico nello stato di Pronto.
|
Flusso alternativo 1 - Carta non valida
|
Nella fase 2 del flusso di base - Verifica della carta, se la carta non è valida, viene espulsa con un
messaggio appropriato.
|
Flusso alternativo 2 - Sportello automatico privo di contanti
|
Nella fase 5 del flusso di base - Opzioni dello sportello automatico, se tale sportello ha esaurito i
contanti, l'opzione "Prelievo di contanti" non sarà disponibile.
|
Flusso alternativo 3 - Fondi insufficienti nello sportello automatico
|
Nella fase 6 del flusso di base - Immissione dell'importo, se lo sportello automatico contiene fondi
insufficienti per fornire l'importo richiesto, verrà visualizzato un messaggio apposito e si ritornerà
alla fase 6 del flusso di base - Immissione dell'importo.
|
Flusso alternativo 4 - PIN non corretto
|
Nella fase 4 del flusso di base - Verifica del conto e del PIN, il cliente dispone di tre tentativi per
immettere il PIN corretto.
Se viene immesso un PIN corretto, lo sportello automatico visualizza il messaggio apposito e, se sono
rimasti ancora dei tentativi, questo flusso riporta il flusso di base alla fase 3 - Immissione del
PIN.
Se, nel tentativo finale il numero PIN immesso non è corretto, la carta viene trattenuta, lo sportello
automatico ritorna allo stato di Pronto e questo caso d'uso termina.
|
Flusso alternativo 5 - Conto inesistente
|
Nella fase 4 del flusso di base - Verifica del conto e del PIN, se il sistema bancario restituisce un
codice che indica che il conto è inesistente o non consente di effettuare prelievi, lo sportello
automatico visualizza l'apposito messaggio e riporta alla fase 9 del flusso di base - Restituzione
carta.
|
Flusso alternativo 6 - Fondi insufficienti nel conto
|
Nella fase 7 del flusso di base - Autorizzazione, il sistema bancario restituisce un codice che
indica che il saldo del conto è inferiore all'importo immesso nella fase 6 del flusso di base -
Immissione dell'importo, lo sportello automatico visualizza l'apposito messaggio e riporta alla fase 6
del flusso di base - Immissione dell'importo.
|
Flusso alternativo 7 - Raggiunto l'importo massimo di prelievo giornaliero
|
Nella fase 6 del flusso di base - Autorizzazione, il sistema bancario restituisce un codice che indica
che, compresa questa richiesta di prelievo, il cliente ha o supererà l'importo massimo consentito in un
periodo di 24 ore, lo sportello automatico visualizza l'apposito messaggio e riporta alla fase 6 del
flusso di base - Immissione dell'importo.
|
Flusso alternativo x - Errore di log
|
Se, nella fase 10 del flusso di base - Ricevuta, non è possibile aggiornare il log, lo sportello
automatico entra nella "modalità sicura" in cui tutte le funzioni vengono sospese. Viene inviato un
avviso apposito al sistema bancario, per indicare che lo sportello automatico ha sospeso l'operazione.
|
Flusso alternativo y - Uscita
|
Il cliente può, in qualsiasi momento, decidere di terminare la transazione (uscire). La transazione
viene arrestata e la carta espulsa.
|
Flusso alternativo x - "Tilt"
|
Lo sportello automatico contiene diversi sensori che monitorano differenti funzioni, come
l'alimentazione, la pressione esercitata sulle varie porte e ingressi e i rilevatori di
movimento. Se, in qualsiasi momento, viene attivato un sensore, viene inviato un segnale di
avviso alla Polizia e lo sportello automatico entra nella "modalità sicura" in cui tutte le funzioni
vengono sospese fino all'esecuzione delle apposite azioni di riavvio / reinizializzazione.
|
Nella prima iterazione, secondo il piano di iterazione, occorre verificare che il caso d'uso Prelievo di contanti
sia stato implementato correttamente. L'intero caso d'uso non è ancora stato implementato, sono stati implementati
solo i seguenti flussi:
-
Flusso di base - Prelievo di un importo presente ($10, $20, $50, $100)
-
Flusso alternativo 2 - Sportello automatico privo di contanti
-
Flusso alternativo 3 - Fondi insufficienti nello sportello automatico
-
Flusso alternativo 4 - PIN non corretto
-
Flusso alternativo 5 - Conto inesistente / Tipo di conto non corretto
-
Flusso alternativo 6 - Fondi insufficienti nel conto
I seguenti scenari possono derivare da questo caso d'uso:
Scenario 1 - Prelievo di contanti completato correttamente
|
Flusso di base
|
|
Scenario 2 - Sportello automatico privo di contanti
|
Flusso di base
|
Flusso alternativo 2
|
Scenario 3 - Fondi insufficienti nello sportello automatico
|
Flusso di base
|
Flusso alternativo 3
|
Scenario 4 - PIN non corretto (rimasti dei tentativi)
|
Flusso di base
|
Flusso alternativo 4
|
Scenario 5 - PIN non corretto (non è rimasto alcun tentativo)
|
Flusso di base
|
Flusso alternativo 4
|
Scenario 6 - Conto inesistente / Tipo di conto non corretto
|
Flusso di base
|
Flusso alternativo 5
|
Scenario 7 - Saldo del conto insufficiente
|
Flusso di base
|
Flusso alternativo 6
|
Nota: per semplicità, i loop nei flussi alternativi 3 e 6 (Scenari 3 e 7) e le combinazioni di loop non sono
state incluse nella suddetta tabella.
Per ognuno di questi scenari, occorre identificare gli scenari di test. E' possibile identificare e gestire tali
scenari utilizzando tabelle di decisione o matrici. Un formato comune viene mostrato di seguito, in cui ogni riga
rappresenta uno scenario di test singolo e le colonne identificano le relative informazioni. In questo esempio,
per ogni scenario di test, esiste un ID, una condizione (o descrizione), tutti gli elementi di dati che partecipano a
tale scenario (come input o già presenti nel database) e il risultato previsto.
Per iniziare a sviluppare la matrice, iniziare con l'identificare quali elementi di dati sono richiesti per eseguire
gli scenari dei casi d'uso. Quindi, per ogni scenario, identificare almeno uno scenario di test che contenga la
condizione appropriata per eseguire lo scenario. Ad esempio, nella matrice seguente, V (valido) viene utilizzato per
indicare che questa condizione deve essere VALIDA per eseguire il flusso di base e I (non valido - "invalid") per
indicare la condizione che richiamerà il flusso alternativo desiderato. Nella seguente tabella, n/a indica che
questa condizione non è applicabile allo scenario di test.
N. ID ST
|
Scenario / Condizione
|
PIN
|
N. conto
|
Importo immesso
(importo scelto)
|
Importo nel conto
|
Importo nello sportello automatico
|
Risultato previsto
|
PC1.
|
Scenario 1 - Prelievo di contanti completato correttamente
|
V
|
V
|
V
|
V
|
V
|
Prelievo di contanti completato correttamente.
|
PC2.
|
Scenario 2 - Sportello automatico privo di contanti
|
V
|
V
|
V
|
V
|
I
|
Opzione Prelievo di contanti non disponibile, fine del caso d'uso
|
PC3.
|
Scenario 3 - Fondi insufficienti nello sportello automatico
|
V
|
V
|
V
|
V
|
I
|
Messaggio di avvertenza, ritornare alla fase 6 del flusso di base - Immissione dell'importo
|
PC4.
|
Scenario 4 - PIN non corretto (> rimasto 1 tentativo)
|
I
|
V
|
n/a
|
V
|
V
|
Messaggio di avvertenza, ritornare alla fase 4 del flusso di base - Immissione del PIN
|
PC5.
|
Scenario 4 - PIN non corretto (= rimasto 1 tentativo)
|
I
|
V
|
n/a
|
V
|
V
|
Messaggio di avvertenza, ritornare alla fase 4 del flusso di base - Immissione del PIN
|
PC6.
|
Scenario 4 - PIN non corretto (rimasti = 0 tentativi)
|
I
|
V
|
n/a
|
V
|
V
|
Messaggio di avvertenza, carta trattenuta, fine del caso d'uso
|
Nella suddetta matrice, i sei scenari di test eseguono i quattro scenari. Per il flusso di base, lo scenario di test
PC1 è noto come caso di test positivo. Esso esegue il percorso del flusso di base attraverso il caso d'uso, senza
alcuna deviazione. Una verifica esauriente del flusso di base deve includere scenari di test negativi per assicurare
che il flusso di base venga acquisito solo quando le condizioni sono corrette. Questi scenari di test negativi sono
rappresentati dagli scenari di test PC2 - 6 (la cella ingrigita indica la condizione necessaria per eseguire i flussi
alternativi). Mentre PC2 - 6 sono scenari di test negativi per il flusso di base, sono scenari di test positivi
per i flussi alternativi 2 - 4 ed è presente almeno uno scenario di test negativo per ognuno di tali flussi alternativi
(PC1 - Flusso di base).
Lo Scenario 4 è un esempio di come la presenza di uno scenario di test positivo e di uno negativo per scenario non sia
sufficiente. Per testare lo Scenario 4 - PIN non corretto, sono necessari almeno tre scenari di test positivi (per
richiamare lo Scenario 4):
-
Viene immesso un PIN non corretto, rimangono ancora tre tentativi e questo flusso alternativo riporta alla fase 3
del flusso di base - Immissione PIN)
-
Viene immesso un PIN non corretto, non rimane più alcun tentativo e questo flusso alternativo trattiene la carta e
termina il caso d'uso.
-
il PIN CORRETTO viene immesso quando non rimangono più tentativi disponibili. Questo flusso alternativo
riconduce il flusso di base alla fase 5 - Immissione dell'importo.
Tenere presente che, nella suddetta matrice, non viene immesso alcun valore reale per le condizioni (dati). Un
vantaggio della creazione della matrice dello scenario di test in questo modo è la semplicità di visualizzazione delle
condizioni che si stanno testando. E' inoltre estremamente semplice determinare se sono stati identificati sufficienti
scenari di test, poiché occorre esaminare solo V e I (o, come in questo caso, le celle ingrigite). Esaminando la
suddetta tabella, esistono diverse condizioni per cui non è presente alcuna cella ingrigita, quindi mancano alcuni
scenari di test, ad esempio per lo Scenario 6 - Conto inesistente o Tipo di conto non corretto e per lo Scenario 7 -
Saldo del conto insufficiente.
Una volta identificati gli scenari di test, sarebbe opportuno esaminarli e convalidarli per assicurare accuratezza,
idoneità e per eliminare scenari di test duplicati, equivalenti o ridondanti. Consultare Concetto: Elenco di proposte di test per ulteriori dettagli. Per ulteriori
informazioni, consultare anche la sezione Definizione dei dati del test per gli
scenari di test.
N. ID ST
|
Scenario / Condizione
|
PIN
|
N. conto
|
Importo immesso
(importo scelto)
|
Importo nel conto
|
Importo nello sportello automatico
|
Risultato previsto
|
PC1.
|
Scenario 1 - Prelievo di contanti completato correttamente
|
4987
|
809 - 498
|
50.00
|
500.00
|
2,000
|
Prelievo di contanti completato correttamente. Saldo del conto aggiornato a 450.00
|
PC2.
|
Scenario 2 - Sportello automatico privo di contanti
|
4987
|
809 - 498
|
100.00
|
500.00
|
0.00
|
Opzione Prelievo di contanti non disponibile, fine del caso d'uso
|
PC3.
|
Scenario 3 - Fondi insufficienti nello sportello automatico
|
4987
|
809 - 498
|
100.00
|
500.00
|
70.00
|
Messaggio di avvertenza, ritornare alla fase 6 del flusso di base - Immissione dell'importo
|
PC4.
|
Scenario 4 - PIN non corretto (> rimasto 1 tentativo)
|
4978
|
809 - 498
|
n/a
|
500.00
|
2,000
|
Messaggio di avvertenza, ritornare alla fase 4 del flusso di base - Immissione del PIN
|
PC5.
|
Scenario 4 - PIN non corretto (= rimasto 1 tentativo)
|
4978
|
809 - 498
|
n/a
|
500.00
|
2,000
|
Messaggio di avvertenza, ritornare alla fase 4 del flusso di base - Immissione del PIN
|
PC6.
|
Scenario 4 - PIN non corretto (rimasti = 0 tentativi)
|
4978
|
809 - 498
|
n/a
|
500.00
|
2,000
|
Messaggio di avvertenza, carta trattenuta, fine del caso d'uso
|
I suddetti scenari di test sono solo una parte degli scenari necessari per verificare il caso d'uso Prelievo di
contanti per questa iterazione. Altri scenari di test necessari includono:
-
Scenario 6 - Conto inesistente o Tipo di conto non corretto: conto non trovato o non disponibile
-
Scenario 6 - Conto inesistente o Tipo di conto non corretto: il conto non consente prelievi
-
Scenario 7 - Saldo del conto insufficiente: importo richiesto superiore all'importo presente nel conto.
Nelle iterazioni future, quando vengono implementati altri flussi, gli scenari di test saranno necessari per:
-
Carte non valide (la carta viene indicata come persa, rubata, proveniente da una banca non accettata, contenente
una striscia danneggiata, ecc.)
-
Impossibilità di leggere la carta (il lettore della carta è inceppato, non in linea o malfunzionante)
-
Il conto è chiuso, congelato o non disponibile
-
L'importo presente nello sportello automatico è insufficiente o non in grado di creare l'importo richiesto
(differente da PC3, in cui l'importo è insufficiente, ma non del tutto)
-
Incapacità di contattare il sistema bancario per l'approvazione
-
La rete bancaria è scollegata o si è verificato un errore di alimentazione nel corso della transazione
Durante l'identificazione degli scenari di test funzionali, verificare quanto segue:
-
sono stati identificati scenari di test sufficienti, positivi e negativi, per ogni scenario dei casi d'uso
-
gli scenari di test utilizzano qualsiasi regola di business implementata dai casi d'uso, verificando che esistono
scenari di test all'interno, all'esterno e sul valore / condizione di business per la regola di business
-
gli scenari di test utilizzano qualsiasi sequenza di eventi o azioni, come quelli identificati nei diagrammi di
sequenza nel modello di progettazione o nelle condizioni e stati degli oggetti dell'interfaccia utente.
-
gli scenari di test utilizzano qualsiasi requisito speciale definito per il caso d'uso, come le prestazioni minime
e massime, talvolta combinati con i volumi di dati o i carichi massimo/minimo durante l'esecuzione dei casi d'uso.
Per ulteriori informazioni, consultare la sezione Definizione dei dati del test
per gli scenari di test.
Non tutti i requisiti per un obiettivo del test verranno riflettuti negli artefatti dei requisiti funzionali come le
specifiche dei casi d'uso. I requisiti non funzionali, come le prestazioni, la sicurezza e l'accesso e i requisiti di
configurazione specificano ulteriori funzionalità o caratteristiche dell'obiettivo del test e, spesso, vengono
documentati separatamente rispetto ai requisiti funzionali. La specifica supplementare è una delle fonti primarie per
la derivazione degli scenari di test per questi requisiti aggiuntivi.
Di seguito vengono descritte linee guida per la derivazione dei suddetti scenari di test aggiuntivi:
L'input primario per gli scenari di test delle prestazioni sono le specifiche supplementari che contengono i requisiti
non funzionali (consultare Prodotto di lavoro: Specifiche supplementari) . Utilizzare le
seguenti linee guida in caso di derivazione degli scenari di test per i test delle prestazioni:
-
verificare che sia stato identificato almeno uno scenario di test per ogni istruzione nella specifica
supplementare, che indichi un criterio delle prestazioni. I criteri delle prestazioni vengono generalmente espressi
come tempo per transazione, numero di transazioni/utenti o percentuali.
-
verificare che sia stato identificato almeno uno scenario di test per ogni caso d'uso critico. I casi d'uso critici
sono quelli identificati nelle suddette istruzioni e/o nel documento di analisi del carico di lavoro, che devono
essere valutati in base alle misurazioni delle prestazioni (consultare Prodotto di lavoro: Documento di analisi del carico di lavoro).
Come avviene con gli scenari di test per i test funzionali, generalmente esisteranno più scenari di test per requisito
o scenario di utilizzo. E' frequente definire più scenari di test, ad esempio uno al di sotto del valore di soglia
delle prestazioni (frequenza media di transazioni), un altro al valore di soglia (frequenza elevata di transazioni) e
un terzo superiore al valore di soglia (frequenza di transazioni di picco).
Oltre ai suddetti criteri delle prestazioni, accertarsi di identificare le condizioni specifiche che incidono sui tempi
di risposta, inclusi:
-
Dimensione del database - quanti record esistono?
-
Carico di lavoro - modelli di transazioni:
-
tipo, numero e frequenza di azioni utente contemporanee,
-
tipo, numero, frequenza e durata di transazioni eseguite contemporaneamente
-
Caratteristiche dell'ambiente (configurazione hardware, netware, software)
Una pratica comune è l'acquisizione degli scenari di test per test delle prestazioni in matrici tabulari simili a
quelle utilizzate per i test delle funzioni.
Per ulteriori dettagli, consultare la sezione Definizione dei dati del test per
gli scenari di test.
Di seguito vengono riportati alcuni esempi per i differenti tipi di test delle prestazioni:
Per il test del carico:
N. ID ST
|
Carico di lavoro
|
Condizione
|
Risultato previsto
|
PCW1.
|
1
(sportello automatico singolo)
|
Transazione di prelievo completa
|
Transazione completa (sincronizzazione non dipendente dall'attore) < 20 secondi
|
PCW2.
|
2
(1.000 sportelli automatici contemporanei)
|
Transazione di prelievo completa
|
Transazione completa (sincronizzazione non dipendente dall'attore) < 30 secondi
|
PCW3.
|
3
(10.000 sportelli automatici contemporanei)
|
Transazione di prelievo completa
|
Transazione completa (sincronizzazione non dipendente dall'attore) < 50 secondi
|
Per il test della resistenza:
N. ID ST
|
Carico di lavoro
|
Condizione
|
Risultato previsto
|
SCW1.
|
2
(1.000 sportelli automatici contemporanei)
|
Blocco database - 2 sportelli automatici richiedono lo stesso conto
|
Richieste dello sportello automatico in coda
|
SCW2.
|
2
(1.000 sportelli automatici contemporanei)
|
La comunicazione del sistema bancario non è disponibile
|
La transazione è in coda o è scaduta
|
SCW3.
|
2
(1.000 sportelli automatici contemporanei)
|
La comunicazione del sistema bancario viene terminata durante la transazione
|
Viene visualizzato un messaggio di avvertenza
|
Gli attori e i casi d'uso descrivono l'interazione tra gli utenti esterni del sistema e le azioni eseguite dal sistema
per fornire un valore a un particolare attore. I sistemi complessi contengono diversi attori ed è importante sviluppare
gli scenari di test per accertarsi che solo gli attori specificati per eseguire i casi d'uso possano farlo. Ciò vale
soprattutto se vi sono differenze nel flusso di eventi del caso d'uso basato sul tipo di attore.
Ad esempio, nei casi d'uso dello sportello automatico, è possibile eseguire un differente flusso di eventi per l'attore
"Cliente della banca" se la carta e il conto di tale cliente deriva dalla banca proprietaria dello sportello automatico
rispetto al "Cliente della banca" che utilizza una carta (e un conto) di una banca concorrente o tenta di utilizzare
una carta non consentita.
Attenersi alle stesse linee guida indicate in precedenza per gli scenari di test funzionali.
Per ulteriori informazioni, consultare la sezione Definizione dei dati del test
per gli scenari di test.
Scenari di test di esempio per la sicurezza e l'accesso:
N. ID ST
|
Condizione
|
Carta
(V indica carta valida)
|
Lettore carta
(V indica corretto funzionamento del lettore)
|
Rete della banca
|
Risultato previsto
|
ACW1.
|
Nella rete della banca
|
V
|
V
|
V
|
Tutti i casi d'uso disponibili
|
ACW2.
|
Esterna alla rete della banca
|
V
|
V
|
I
|
Solo caso d'uso del ritiro di contanti
|
ACW3.
|
Carta illeggibile
|
I
|
V
|
V
|
Messaggio di avvertenza, carta espulsa
|
ACW4.
|
Carta indicata come rubata
|
I
|
V
|
V
|
Messaggio di avvertenza, carta trattenuta
|
ACW5.
|
Carta scaduta
|
I
|
V
|
V
|
Messaggio di avvertenza, carta trattenuta
|
In sistemi distribuiti tipici, potrebbero esistere diverse combinazioni consentite di hardware e software supportate.
Si consiglia di eseguire la verifica per verificare che l'obiettivo del test funzioni o venga eseguito in modo corretto
in diverse configurazioni, come ad esempio con differenti sistemi operativi, browser o velocità di CPU. Inoltre, è
necessario che la verifica comprenda combinazioni di componenti per rilevare i difetti provenienti da interazioni dei
diversi componenti, ad esempio, assicurando che la versione di DLL installata da un'applicazione non vada in conflitto
con le versioni delle stesse DLL previste da un'altra applicazione.
Per ricavare gli scenari di test per la verifica della configurazione, utilizzare le seguenti linee guida:
-
verificare che esista almeno uno scenario di test che identifichi ogni configurazione critica. E' possibile farlo
identificando le configurazioni hardware e software per l'ambiente dell'obiettivo del test e dando la priorità alle
configurazioni, accertandosi che le più comuni vengano testate per prime, compresi:
-
Supporto della stampante
-
Connessioni di rete - LAN e WAN
-
Configurazioni del server - driver e hardware del server
-
Altro software installato sul desktop e/o sui server
-
Versioni software per tutto il software installato
-
verificare che esista almeno uno scenario di test per ogni configurazione che potrebbe presentare dei problemi. Tra
questi:
-
Hardware con le prestazioni peggiori.
-
Software co-esistente che presenti una cronologia di problemi di compatibilità.
-
Client che accedono al server tramite la connessione LAN/WAN più lenta
-
Risorse insufficienti (velocità CPU lenta, spazio disco, risoluzione o memoria minimi, ecc.)
La verifica dell'installazione è utile per controllare che sia possibile installare l'obiettivo del test in tutti gli
scenari di installazione possibili. Tali scenari potrebbero includere la prima installazione dell'obiettivo del test o
l'installazione di una versione o build più recente (su una macchina contenente la versione precedente). La verifica
dell'installazione dovrebbe anche controllare che l'obiettivo del test venga eseguito in modo corretto nel caso di
condizioni anomale, ad esempio lo spazio disco insufficiente.
Gli scenari di test dovrebbero includere gli scenari di installazione per il software, compresi:
-
Supporti di distribuzione, ad esempio, minidischi, CD-ROM o server di file.
-
Nuova installazione.
-
Installazione completa.
-
Installazioni personalizzate.
-
Installazioni di aggiornamento.
I programmi di installazione per il software server-client dispongono di una serie di scenari di test specializzati. A
differenza dei sistemi basati su host, il programma di installazione è generalmente diviso tra il server e il client.
Quindi, è importante che la verifica dell'installazione esegua l'installazione di tutti i componenti dell'obiettivo del
test, compresi client, livelli intermedi e server.
Idealmente, si dovrebbe rilevare tutto l'input necessario per ricavare gli scenari di test negli artefatti Modello del
caso d'uso, Modello di progettazione, e Specifica supplementare. E', tuttavia, abbastanza frequente che, a questo
punto, sia necessario completare ciò che viene presentato qui.
Tra gli esempi:
-
Scenari di test per test operativi (per verificare che il software funzioni quando viene utilizzato per molto tempo
tra gli errori).
-
Scenari di test che esaminano i colli di bottiglia delle prestazioni, le capacità di volume del sistema o
verifichino la resistenza agli errori dell'obiettivo del test.
Nella maggior parte dei casi, si rileveranno tali scenari di test creando varianti o aggregati degli scenari di test
ricavati da quelli identificati in precedenza.
La verifica di accettazione di un prodotto è l'azione di test conclusiva prima della distribuzione del software.
L'obiettivo della verifica di accettazione è controllare che il software sia pronto e possa essere utilizzato dagli
utenti per eseguire le funzioni e le attività per le quali è stato creato il software. Tale verifica include, spesso,
più dell'esecuzione del software per verificare che sia pronto; essa comprende tutti i prodotti di lavoro del prodotto
forniti al/ai cliente(i), come ad esempio l'addestramento, la documentazione e la creazione di pacchetti.
La derivazione degli scenari di test per i prodotti di lavoro software viene eseguita nel modo descritto nelle
precedenti sezioni. A seconda del grado e della formalità del test di accettazione del prodotto, gli scenari di test
saranno gli stessi o saranno simili a quelli identificati in precedenza, (formali) o a una sottoserie (informali).
Indipendentemente dalla complessità dei suddetti scenari, l'accordo sui criteri di accettazione del prodotto e degli
scenari di test dovrebbe essere raggiunto prima che la verifica del prodotto venga implementata ed eseguita.
La valutazione dei prodotti di lavoro non software varia enormemente a seconda del prodotto di lavoro che si sta
valutando. Fare riferimento a ogni elenco di controllo e linea guida relativa al prodotto di lavoro non software, per
informazioni relative a cosa e a come valutare.
La verifica di regressione confronta due build o versioni dello stesso obiettivo del test e identifica le differenze
come potenziali difetti. Essa presuppone, poi, che una nuova versione dovrebbe avere le stesse funzionalità della
precedente e assicura che non siano stati inseriti dei difetti come risultato delle modifiche.
Idealmente, sarebbe bene utilizzare tutti gli scenari di test in un'iterazione come scenari di test nelle iterazioni
successive. Si consiglia di utilizzare le seguenti linee guida per identificare, progettare e implementare gli scenari
di test che aumentano al massimo il valore del riutilizzo e della verifica di regressione, riducendo al minimo la
gestione:
-
Accertarsi che lo scenario di test identifichi solo gli elementi di dati critici (quelli necessari per
creare/supportare la condizione che si sta testando)
-
Accertarsi che ogni scenario di test descriva o rappresenti una serie di input o sequenza di eventi univoca che dia
come risultato una funzionalità univoca da parte dell'obiettivo del test
-
Eliminare gli scenari di test equivalenti o ridondanti
-
Raggruppare gli scenari di test con lo stesso stato iniziale dell'obiettivo del test e con lo stesso stato dei dati
del test
Una volta discussi e approvati gli scenari di test, è possibile identificare in dettaglio i reali valori di dati (ad
esempio nella matrice di implementazione dello scenario di test) e creare gli artefatti dei dati del test.
Per ulteriori informazioni relative alla definizione e alla gestione dei dati del test, consultare Linea guida: Dati del test.
|