Linea guida: Scenario di test
Questa linea guida spiega come identificare e progettare il software del test.
Relazioni
Descrizione principale

Spiegazione

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.

Derivazione degli scenari di test dai casi d'uso

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).

Diagramma descritto nella figura.

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:

Diagramma descritto nella figura.

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.
  1. Inizio del prelievo - il cliente inserisce la carta nel lettore dello sportello automatico
  2. Verifica della carta - lo sportello automatico legge il codice del conto dalla striscia magnetica sulla carta   e controlla se è possibile accettarla.
  3. Immissione del codice PIN - lo sportello automatico richiede il codice PIN del cliente (4 cifre)
  4. 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.
  5. 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".
  6. 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).
  7. 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.
  8. Distribuzione - Il denaro viene distribuito.
  9. Restituzione carta - La carta viene restituita.
  10. 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) 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) 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) 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.

Derivazione degli scenari di test dalle specifiche supplementari

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:

Derivazione degli scenari di test per i test delle prestazioni

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

Derivazione degli scenari di test per i test di sicurezza/ di accesso

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

Derivazione degli scenari di test per i test di configurazione

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.)

Derivazione degli scenari di test per i test di installazione

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.

Derivazione degli scenari di test per altri test non funzionali

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.

Derivazione degli scenari di test per i test di accettazione

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.

Creazione di scenari di test di verifica per i test di regressione

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

Definizione dei dati del test per gli scenari di 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.