Linea guida: Piano del test
Un piano del testo deve comprendere requisiti, rischi, priorità, strategia e criteri di completamento. Questa linea guida descrive in dettaglio lo scopo di un piano del test e il relativo contenuto.
Relazioni
Elementi correlati
Descrizione principale

Panoramica

Lo scopo del piano del test è comunicare l'intento delle attività di verifica. E' importante creare tale documento prima possibile. Si consiglia di generare questo artefatto all'inizio di una delle prime iterazioni della fase di elaborazione. Potrebbe essere una buona idea sviluppare il piano del test in modo iterativo, aggiungendo le sezioni non appena le informazioni sono disponibili.

Prestare attenzione nel comunicare in modo chiaro l'ambito della verifica, il requisito del test, le strategie di test e le esigenze di risorse. Queste informazioni identificano lo scopo e i boundary dell'impegno del test, gli elementi che verranno testati, le modalità del test e le risorse necessarie per la verifica. Se si forniscono queste informazioni in modo chiaro, sarà più semplice eseguire l'analisi, il feedback e l'approvazione dell'impegno del test.

All'inizio del progetto, si consiglia di creare un piano di test che identifica la verifica generale prevista per il progetto, indicata come "Piano principale di test". Dal momento che ogni iterazione è pianificata, viene creato un "Piano del test di iterazione" più preciso (o diversi piani di test, organizzati per tipo di test), contenenti solo i dati (requisiti per il test, strategie di test, risorse, ecc.) che appartiene all'iterazione. In alternativa, è possibile queste informazioni nel Piano di iterazione, se tale operazione non rende il piano di iterazione troppo difficile da gestire o utilizzare. 

Di seguito vengono riportate alcune delle linee guida che consentono una migliore identificazione e comunicazione dei requisiti, dei rischi, delle priorità e delle strategie del test.

Identificazione dei requisiti di test

I requisiti del test identificano quali elementi verranno testati. Sono l'obiettivo specifico di un test. Esistono alcune regole generali da applicare in caso di derivazione dei requisiti del test:

  • Il requisito del test deve essere una funzionalità osservabile e misurabile. Se non è possibile osservare o misurare tale requisito, è possibile valutarlo per determinare se il requisito è stato soddisfatto.
  • Non esiste una relazione diretta tra ogni caso d'uso o requisito supplementare di un sistema e un requisito per il test. I casi d'uso spesso presenteranno più requisiti per test, mentre altri requisiti supplementari deriveranno uno o più requisiti per test e altri non ne deriveranno alcuno (ad esempio i requisiti di marketing o di creazione pacchetti).

I requisiti per il test possono derivare da origini differenti, compresi casi d'uso, modelli dei casi d'uso, specifiche supplementari, requisiti di progettazione, casi di business, interviste con utenti e il documento di architettura software. Tutti questi requisiti dovrebbero essere esaminati per acquisire informazioni utilizzate per identificare i requisiti del test.

Requisiti per i test funzionali

I requisiti funzionali per il test, come il nome implica, derivano dalle descrizioni delle funzionalità dell'obiettivo del test. Ogni caso d'uso dovrebbe utilizzare, come minimo, un requisito per il test. Un elenco di requisiti per test più dettagliato include almeno un requisito per test per ogni flusso di casi d'uso degli eventi.

Requisiti per i test delle prestazioni

I requisiti delle prestazioni per i test derivano dalle funzionalità di prestazioni specificate dell'obiettivo del test. Generalmente, le prestazioni sono indicate come una misura del tempo di risposta e/o dell'utilizzo di risorse, calcolata in varie condizioni, compresi

  • differenti carichi di lavori e/o condizioni di sistema
  • differenti casi d'uso
  • differenti configurazioni

I requisiti per le prestazioni sono descritti nelle specifiche supplementari. Esaminare tali materiali, prestando particolare attenzione alle istruzioni che includono quanto segue:

  • istruzioni temporali, ad esempio tempo di risposta o profili di sincronizzazione
  • istruzioni che indicano che devono verificarsi diversi eventi o casi d'uso in un periodo di tempo specificato
  • istruzioni che confrontano la funzionalità di una voce rispetto a un'altra
  • istruzioni che confrontano la funzionalità dell'applicazione su una configurazione rispetto a un'altra
  • affidabilità operativa (MTTF o mean time to failure) in un periodo di tempo
  • configurazioni o vincoli

Si consiglia di derivare almeno un requisito per test per ogni istruzione nella specifica che rifletta le informazioni indicate in precedenza.

Requisiti per i test di affidabilità

I requisiti di affidabilità per i test derivano da diverse origini, generalmente descritte in Specifiche supplementari, Linee guida dell'interfaccia utente, di progettazione e di programmazione.

Esaminare questi prodotti di lavoro e prestare particolare attenzione alle istruzioni che includono quanto segue:

  • istruzioni di affidabilità o resistenza all'errore, errori di runtime (ad esempio perdite di memoria)
  • istruzioni che indicano la struttura e l'integrità del codice (compatibilità con lingua e sintassi)
  • istruzioni relative all'utilizzo delle risorse

Si consiglia di derivare almeno un requisito per test da ogni istruzione nei prodotti di lavoro che rifletta le informazioni indicate in precedenza.

Una verifica corretta richiede che l'impegno del test bilanci correttamente fattori come rischi e vincoli delle risorse. A tale scopo, si consiglia di dare priorità all'impegno del test in modo che i componenti o i casi d'uso più importanti, significativi o rischiosi vengano testati per primi. Per fare ciò, una valutazione e un profilo operativo vengono eseguiti e utilizzati come basi per stabilire la priorità di test.

Le seguenti sezioni descrivono come determinare la priorità di test.

Valutazione del rischio e scelta delle priorità di test

L'identificazione dei requisiti per il test è solo una parte dell'identificazione degli elementi che verranno testati. Occorre inoltre eseguire un'organizzazione, secondo priorità, di tali elementi e scegliere l'ordine in cui verranno testati. Tale fase viene eseguita per varie ragioni, incluse le seguenti:

  • verificare che gli impegni del test siano incentrati sui requisiti più appropriati per il test
  • verificare che i requisiti più critici, significativi o rischiosi per il test siano testati prima possibile
  • verificare che qualsiasi dipendenza, come la sequenza o i dati, venga testata

Occorre seguire tre fasi per valutare il rischio e stabilire le priorità di test:

Le linee guida per ognuna di tali fasi vengono fornite di seguito:

Valutazione del rischio

Per stabilire la priorità per il test, occorre innanzitutto valutare il rischio. I casi d'uso o i componenti che comportano il rischio maggiore a causa di un errore o che hanno un'elevata probabilità di errore dovrebbero essere testati per primi.

Iniziare a identificare e descrivere gli indicatori di impatto del rischio che verranno utilizzati, ad esempio:

  • H - (high) rischio elevato, non tollerabile. Esposizione esterna grave. L'azienda subirà ingenti perdite finanziarie ed economiche o perdita di reputazione irreversibile.
  • M - rischio medio, tollerabile ma non auspicabile. Esposizione esterna minima, l'azienda potrebbe subire perdite finanziarie, ma con passività o perdita di reputazione limitata.
  • L - (low) rischio basso, tollerabile. Esposizione minima o non esterna, l'azienda subirà scarse perdite finanziarie o passività inesistente. Reputazione dell'azienda immutata.

Dopo avere identificato gli indicatori di impatto del rischio, elencare ogni caso d'uso o componente nell'obiettivo del test. Per ogni caso d'uso o componente nell'elenco, identificare un indicatore e giustificare il valore selezionato, in una breve spiegazione.

E' possibile utilizzare tre prospettive per valutare il rischio:

  • Effetto - l'impatto o la conseguenza di un caso d'uso specificato (requisito, ecc.) in errore
  • Causa - inizia con un risultato indesiderabile causato dall'errore di un caso d'uso ed esamina le possibili cause
  • Probabilità - la probabilità di un errore di un caso d'uso.

Selezionare una prospettiva, identificare un indicatore di impatto del rischio e giustificare la propria scelta. Non è necessario identificare un indicatore per ogni prospettiva di rischio. Tuttavia, se viene identificato un indicatore basso, tentare di valutare la voce da una prospettiva di rischio differente per assicurarsi che la voce sia realmente un rischio basso.

Di seguito vengono forniti ulteriori dettagli sulla valutazione del rischio da queste tre prospettive.

Effetto

Per valutare il rischio in base all'effetto, identificare una condizione, evento o azione e tentare di stabilire il relativo impatto. Domandarsi:

"Cosa succederebbe se ___________?"

Per esempio:

  • "Cosa succederebbe se, durante l'installazione del nuovo software, il sistema esaurisse lo spazio su disco?
  • "Cosa succederebbe se la connessione Internet venisse persa durante una transazione di ricerca?
  • "Cosa succederebbe se la connessione Internet venisse persa durante una transazione di acquisto?
  • "Cosa succederebbe se l'utente immettesse un valore imprevisto?

Di seguito viene riportata una matrice di giustificazione per queste voci:

Descrizione Fattore di mitigazione del rischio Giustificazione
Spazio disco insufficiente durante l'installazione H L'installazione del software fornisce al cliente la prima impressione del prodotto. Qualsiasi risultato indesiderabile, come quelli elencati di seguito, deteriora il sistema dell'utente, il software installato e comunica un'impressione negativa all'utente:
  • il software viene installato parzialmente (alcuni file, alcune voci di registro), rimanendo in una condizione instabile
  • l'installazione si ferma, lasciando il sistema in uno stato instabile
connessione persa durante una ricerca L Nessun danno risultante dalla connessione persa viene provocato ai dati o al database. E' certo che una connessione persa potrebbe comunicare un'impressione negativa all'utente.
connessione persa durante un acquisto H Qualsiasi connessione o transazione persa che comporta i risultati riportati di seguito è inaccettabile, perché aumenta i costi di sovraccarico e diminuisce i profitti:
  • database corrotto
  • ordine parziale
  • ordine o dati persi
  • ordini multipli (replicati)
Immesso valore imprevisto H Qualsiasi transazione che comporta i risultati riportati di seguito è inaccettabile:
  • database corrotto
  • dati imprecisi

Causa

La valutazione del rischio tramite la causa è opposta rispetto a quella tramite effetto. Iniziare a indicare una condizione o un evento indesiderabile e identificare la serie di eventi che potrebbero avere generato la condizione rilevata. Chiedersi:

"Come è potuto succedere che ___________?

Per esempio:

  • "Come è possibile che soltanto alcuni file siano sul sistema e che non siano state eseguite tutte le voci del registro?
  • "Come è possibile che una transazione non sia stata riflettuta correttamente nel database centrale?
  • "Come è possibile che l'istruzione del ciclo di fatturazione rifletta solo alcuni record nel database che soddisfano i criteri desiderati?"

Di seguito viene riportata una matrice di giustificazione per queste voci:

Descrizione Fattore di mitigazione del rischio Giustificazione
Voci di registro e file dell'applicazione mancanti H Rende l'applicazione (e potenzialmente il sistema) inutilizzabile. L'installazione è la prima vista dell'applicazione notata dall'utente. Se l'installazione ha esito negativo, per qualsiasi ragione, l'utente giudica il software in modo non favorevole.

Le possibili cause di questa condizione includono:

  • il processo di installazione non ha installato tutti i file né ha aggiornato il registro correttamente
  • il processo di installazione è stato arrestato a causa dell'intervento dell'utente (annullamento o uscita)
  • il processo di installazione è stato arrestato a causa dell'intervento del software / hardware (spazio disco insufficiente, configurazione non supportata, ecc.)
  • il processo di installazione è stato arrestato a causa di condizioni sconosciute
  • l'utente ha eliminato i file / le voci di registro

Delle suddette cause, soltanto l'ultima non può essere rilevata e gestita dal processo di installazione.

Ordine parziale H Gli ordini parziali non possono essere soddisfatti e provocano perdita di profitti e di clienti.

Le possibili cause includono:

  • Connessione Internet persa a causa dell'azione dell'utente (disconnessione del modem, spegnimento del PC, ecc.)
  • Connessione Internet persa a causa dell'IP
  • Connessione Internet persa a causa dell'azione dell'utente (disconnessione del modem, spegnimento dei server, ecc.)
Database / dati danneggiati H I dati danneggiati non possono essere tollerati per alcun motivo.

Le possibili cause includono:

  • Transazione che scrive al database non completata / non eseguita a causa dell'intervento dell'utente
  • Transazione che scrive al database non completata / non eseguita a causa della perdita della connessione Internet
  • L'utente immette dati non validi nella transazione
  • Programmi di utilità / metodi di accesso al database
  • Database non riempito correttamente (durante la creazione iniziale dell'istanza)
Ordini replicati H Gli ordini replicati aumentano il sovraccarico dell'azienda e diminuiscono i profitti tramite i costi associati alla spedizione, gestione e rifornimento.

Le possibili cause includono:

  • Transazione che scrive l'ordine al database replicata a causa dell'intervento dell'utente, l'utente ha immesso l'ordine due volte - nessuna conferma di immissione
  • Transazione che scrive l'ordine al database replicata non a causa dell'intervento dell'utente (processo di ripristino in seguito a connessione Internet persa, ripristino del database)
Dati non precisi per un ordine H Qualsiasi ordine che non è possibile completare o che comporta ulteriori costi aggiuntivi non è accettabile.

Le possibili cause includono:

  • Transazione dell'ordine non completata / non eseguita a causa dell'intervento dell'utente
  • Transazione dell'ordine non completata / non eseguita a causa della perdita della connessione Internet
  • L'utente immette dati non validi
Numero sbagliato di record rispecchiati nell'istruzione H Gli account e le decisioni di business accettabili dipendono dall'accuratezza di tali report.

Le possibili cause includono:

  • Criteri di selezione / ricerca non corretti
  • Istruzione SQL non corretta
  • Dati nel database danneggiati
  • Dati nel database non corretti

Probabilità

La valutazione del rischio in base alla probabilità consente di determinare il fallimento di un caso d'uso (o del componente che lo implementa). La probabilità si basa, generalmente, su fattori esterni tra cui:

  • Frequenza di fallimento
  • Tasso di cambiamento
  • Complessità
  • Origine / Originator

Tuttavia, è bene notare che, quando si utilizza questa prospettiva di rischio, gli indicatori di impatto del rischio sono correlati alla probabilità di un errore, non all'effetto o all'impatto che l'errore ha sull'organizzazione, come avviene per la valutazione del rischio tramite effetto e causa.

Le correlazioni tra questi fattori e la probabilità di un errore esiste, come viene indicato di seguito:

Fattore esterno Probabilità
Frequenza di rilevazione errori
La probabilità di un errore aumenta con l'aumentare della densità o della frequenza di rilevazione errori. I difetti tendono a raggrupparsi, quindi, man mano che la frequenza di rilevazione o il numero di difetti (densità) aumenta in un componente o in un caso d'uso, cresce anche la probabilità di rilevare un altro difetto. Occorre considerare anche la densità e la frequenza di rilevazione dei precedenti rilasci durante la valutazione del rischio utilizzando questo fattore, poiché le precedenti frequenze o densità elevate indicano un'elevata probabilità di ulteriori errori.
Tasso di cambiamento La probabilità di un errore aumenta con l'aumentare della frequenza di modifica nel componente o nel caso d'uso. Quindi, man mano che aumentano le modifiche, cresce anche la probabilità che siano presenti dei difetti. Ogni volta che si modifica il codice, vi è il rischio di inserire, al suo interno, un altro difetto.
Complessità La probabilità di un errore aumenta con l'aumentare del grado di complessità del componente o del caso d'uso.
Origine / Originator La conoscenza e l'esperienza dell'ubicazione in cui ha avuto origine il codice e del suo ideatore possono far aumentare o diminuire la probabilità di un errore.
L'uso di componenti di terze parti diminuisce generalmente la probabilità di errore. Tuttavia, ciò vale solo se il componente di terze parti è stato certificato (corrisponde ai requisiti, tramite test formale o esperienza).
La probabilità di errore, generalmente, diminuisce con la conoscenza e gli skill dell'implementatore. Tuttavia, tali fattori, tra cui l'utilizzo di nuovi tool, tecnologie o l'utilizzo di più ruoli potrebbe aumentare la probabilità di un errore anche da parte dei membri del team più esperto.



Per esempio:

  • Installazione del nuovo software
  • "Storicamente, sono stati rilevati molti difetti nei componenti utilizzati per implementare i casi d'uso 1, 10 e 12 e i nostri clienti hanno richiesto diverse modifiche nei casi d'uso 14 e 19".

Di seguito viene riportata una matrice di giustificazione per queste voci:

Descrizione Fattore di mitigazione del rischio Giustificazione
Installazione di un nuovo software H E' in corso la scrittura del programma di utilità dell'installazione.

Rende l'applicazione inutilizzabile. L'installazione è la prima vista dell'applicazione notata dall'utente. Se l'installazione ha esito negativo, per qualsiasi ragione, l'utente giudica il software in modo non favorevole.

Installazione di un nuovo software L Si sta utilizzando un programma di utilità dell'installazione commercialmente valido.

Sebbene l'installazione non riuscita rende l'applicazione inutilizzabile, il programma di utilità dell'installazione selezionato proviene da un fornitore che ha raggiunto la vetta del mercato con il suo prodotto e che sta nel business da più di quattro anni. La nostra valutazione in proposito indica che il prodotto soddisfa le nostre esigenze e che i clienti sono soddisfatti del prodotto, del fornitore e del livello di supporto e assistenza.

Densità dei difetti / frequenze di rilevazione errori elevate nei casi d'uso 1, 10 e 12. H A causa delle precedenti frequenze di rilevazione errori e densità di difetti elevate, i casi d'uso 1, 10 e 12 sono considerati a rischio elevato.
Modificare le richieste nei casi d'uso 14 e 19. H Un numero elevato di modifiche a questi casi d'uso aumentano la probabilità di inserire difetti nel codice.

Scelta del profilo operativo

La fase successiva di valutazione del rischio e scelta di una priorità di test serve per stabilire il profilo operativo dell'obiettivo del test.

Iniziare a identificare e descrivere gli indicatori di impatto del profilo operativo che verranno utilizzati, ad esempio:

  • H - utilizzato abbastanza frequentemente, molte volte in un periodo o da molti attori o casi d'uso.
  • M - utilizzato frequentemente, diverse volte in un periodo o da diversi attori o casi d'uso.
  • L - utilizzato raramente o solo da pochi attori o casi d'uso.

L'indicatore di profilo operativo selezionato deve essere utilizzato in base alla frequenza con cui viene eseguito un componente o un caso d'uso, compresi:

  • il numero di volte in cui UN attore (o caso d'uso) esegue il caso d'uso (o il componente) in un periodo di tempo specificato
  • Il numero di ATTORI (o casi d'uso) che eseguono il caso d'uso (o componente)

Generalmente, maggiore è il numero di volte in cui viene utilizzato un caso d'uso o un componente e maggiore è l'indicatore del profilo operativo.

Dopo avere identificato gli indicatori di impatto del profilo operativo, elencare ogni caso d'uso o componente nell'obiettivo del test. Determinare un indicatore del profilo operativo per ogni voce nell'elenco e una giustificazione per il valore dell'indicatore. Per questa valutazione, è possibile utilizzare le informazioni del documento di analisi del carico di lavoro (Consultare Prodotto di lavoro: Documento di analisi del carico di lavoro).

Esempi:

  • Installazione di un nuovo software
  • Ordine di prodotti dal catalogo online
  • Clienti che chiedono informazioni sul proprio ordine online dopo averlo effettuato
  • Finestra di dialogo di selezione dei prodotti
Descrizione Fattore del profilo operativo Giustificazione
Installazione di un nuovo software H Eseguito una sola volta (generalmente), ma da parte di molti utenti. Tuttavia, senza l'installazione, l'applicazione è inutilizzabile.
Ordine di prodotti dal catalogo H Questo è il caso d'uso più comune eseguito dagli utenti.
Clienti che richiedono informazioni sugli ordini L Pochi clienti richiedono informazioni sui propri ordini dopo averli effettuati
Finestra di dialogo di selezione dei prodotti H Questa finestra di dialogo viene utilizzata dai clienti per effettuare gli ordini e dagli impiegati di inventario per rifornire le merci.

Scelta della priorità di test

L'ultima fase di valutazione del rischio e scelta di una priorità di test serve per stabilire la priorità di test.

Iniziare a identificare e descrivere gli indicatori di impatto della priorità di test che verranno utilizzati, ad esempio:

  • H - deve essere testato
  • M - dovrebbe essere testato, ma verrà testato solo dopo avere testato tutte le voci H
  • L - potrebbe essere testato, ma solo dopo che sono state testate tutte le voci H e M

Dopo avere identificato gli indicatori di impatto della priorità di test, elencare ogni caso d'uso o componente nell'obiettivo del test. Determinare un indicatore della priorità di test per ogni voce nell'elenco e una giustificazione per il valore dell'indicatore. Di seguito vengono riportate alcune linee guida per determinare un indicatore della priorità di test.

Considerare quanto segue per determinare i suddetti indicatori per ogni voce:

  • il valore dell'indicatore di impatto del rischio identificato in precedenza
  • il valore dell'indicatore di impatto del profilo operativo identificato in precedenza
  • le descrizioni dell'attore (ha esperienza, è tollerante relativamente alle soluzioni alternative?, ecc.)
  • gli obblighi contrattuali (l'obiettivo del test sarà accettabile se non viene consegnato un caso d'uso o un componente?)

Le strategie per stabilire una priorità di test comprendono:

  • Utilizzare il valore del fattore valutato più elevato (rischio, profilo operativo, ecc.) per ogni voce, come priorità generale.
  • Identificare un fattore valutato come il più significativo (rischio, profilo operativo, altro) e utilizzare il valore di tale fattore come priorità.
  • Utilizzare una combinazione di fattori valutati per identificare la priorità.
  • Utilizzo di uno schema ponderato in cui vengono valutati i singoli fattori e i relativi valori e priorità calcolati in base al peso.

Esempi:

  • Installazione di un nuovo software
  • Ordine di prodotti dal catalogo online
  • Clienti che chiedono informazioni sul proprio ordine online dopo averlo effettuato
  • Finestra di dialogo di selezione dei prodotti

Priorità quando viene utilizzato il valore valutato più elevato per determinare la priorità:

Voce Rischio Profilo operativo Attore Contratto Priorità
Installazione di un nuovo software H H L H H
Ordine di prodotti dal catalogo H H H H H
Richieste del cliente L L L L L
Finestra di dialogo di selezione dei prodotti L H L L H

Priorità quando viene utilizzato il valore valutato più elevato per un fattore (Rischio) per determinare la priorità:

Voce Rischio Profilo operativo Attore Contratto Priorità
Installazione di un nuovo software H H L H H
Ordine di prodotti dal catalogo H H H H H
Richieste del cliente L L L L L
Finestra di dialogo di selezione dei prodotti L H L L L

Priorità quando viene utilizzato un valore ponderato per calcolare la priorità:

(Nota: nella matrice riportata di seguito, H = 5, M = 3 e L = 1. Un valore totale ponderato maggiore di 30 è una voce del test di priorità elevata, i valori compresi tra 20 e 30 inclusi sono una priorità media e i valori inferiori a 20 sono una priorità bassa).

Voce Rischio (x 3) Profilo operativo (x 2) Attore (x 1) Contratto (x 3) Valore ponderato Priorità
Installazione di un nuovo software 5 (15) 5 (10) 1 (1) 5 (15) 41 H (2)
Ordine di prodotti dal catalogo 5 (15) 5 (10) 5 (5) 5 (15) 45 H (1)
Richieste del cliente 1 (3) 1 (2) 1 (1) 1 (3) 9 L (4)
Finestra di dialogo di selezione dei prodotti 1 (3) 5 (10) 1 (1) 1 (3) 17 L (3)

Strategia di test

La strategia di test descrive gli obiettivi e l'approccio generale di un impegno di test specifico.

Una buona strategia di test dovrebbe includere quanto segue:

Tipo di test e obiettivo Inizio pagina

Indicare chiaramente il tipo di test implementato e il relativo obiettivo. Una dichiarazione esplicita di tali informazioni riduce al minimo la confusione e le incomprensioni (specialmente a causa del fatto che alcuni test si assomigliano). L'obiettivo dovrebbe indicare chiaramente perché si sta eseguendo il test.

Esempi:

"Test funzionale. Il test funzionale è incentrato sull'esecuzione dei seguenti casi d'uso implementati nell'obiettivo del test, dall'interfaccia utente."

"Test delle prestazioni. Il test delle prestazioni per il sistema sarà incentrato sulla misurazione del tempo di risposta per i casi d'uso 2, 4 e 8 - 10. Per tali test, verrà utilizzato un carico di lavoro di un attore, eseguendo questi casi d'uso senza alcun altro carico di lavoro sul sistema del test."

"Test di configurazione. La verifica della configurazione verrà implementata per identificare e valutare la funzionalità dell'obiettivo del test su tre differenti configurazioni, confrontando le caratteristiche delle prestazioni con la configurazione del punto di riferimento."

Fase del test

Indicare chiaramente la fase in cui verrà eseguito il test. Di seguito vengono identificate le fasi in cui vengono eseguiti i test comuni:

  Fase del test
Tipo di test Unità Integrazione Sistema Accettazione
Test funzionali

(Configurazione, Funzione, Installazione, Sicurezza, Volume)

X X X X
Test delle prestazioni

(profili delle prestazioni di singoli componenti)

X X (X)

facoltativo o quando i test delle prestazioni del sistema rilevano dei difetti

 
Test delle prestazioni

(Carico, Resistenza, Conflitto)

    X X
Affidabilità

(Integrità, Struttura)

X X (X)

facoltativo o quando altri test rilevano dei difetti

 

Tecnica

La tecnica dovrebbe descrivere in che modo verrà implementata ed eseguita la verifica. Includere gli elementi che verranno testati, le azioni principali da eseguire durante l'esecuzione del test e il/i metodo(i) utilizzati per valutare i risultati.

Esempio:

Test funzionale:

  • Per ogni flusso di casi d'uso degli eventi, verrà identificata una serie rappresentativa di transazioni, ognuna che rappresenta le azioni eseguite dall'attore quando viene eseguito il caso d'uso.
  • Per ogni transazione verranno sviluppati un minimo di due scenari di test; uno per rispecchiare la condizione positiva e uno per la condizione negativa (inaccettabile).
  • Nella prima iterazione, verranno testati i casi d'uso 1 - 4 e 12, nel seguente modo:
    • Caso d'uso 1:
      • Il Caso d'uso 1 inizia con l'attore già registrato nell'applicazione e che ha già aperto la finestra principale e termina quando l'utente ha specificato SALVA.
      • Ogni scenario di test verrà implementato ed eseguito utilizzando Rational Robot.
      • La verifica e la valutazione dell'esecuzione per ogni scenario di test verranno eseguite utilizzando i seguenti metodi:
        • L'esecuzione dello script di test (ogni script di test è stato eseguito correttamente e nel modo previsto?)
        • I metodi di verifica dati dell'oggetto o Window Existence (implementati negli script di test) verranno utilizzati per verificare che vengano visualizzate le finestre chiave e che vengano catturati / visualizzati i dati specificati dall'obiettivo del test durante l'esecuzione del test stesso.
        • Il database dell'obiettivo del test (utilizzando Microsoft Access) verrà esaminato prima del test e nuovamente dopo il test per verificare che le modifiche eseguite durante il test vengano riflettute in modo accurato nei dati.

Test delle prestazioni:

  • Per ogni caso d'uso, una serie di transazioni rappresentativa, identificata nel documento di analisi del carico di lavoro verrà implementata ed eseguita tramite Rational Suite PerformanceStudio (script vu) e Rational Robot (script GUI).
  • Almeno tre carichi di lavoro verranno riflettuti negli script di test e nelle pianificazioni di esecuzione dei test, compresi i seguenti:
    • Carico di lavoro con stress: 750 utenti (15 % responsabili, 50 % vendite, 35 % marketing)
    • Carico di lavoro di picco: 350 utenti (10 % responsabili, 60 % vendite, 30 % marketing)
    • Carico nominale: 150 utenti (2 % responsabili, 75% vendite, 23 % marketing)
  • Gli script di test utilizzati per eseguire ogni transazione includeranno i timer appropriati per catturare i tempi di risposta, ad esempio il tempo di transazione totale (come viene definito nel documento di analisi del carico di lavoro) e i tempi del processo o dell'attività di transazione chiave.
  • Gli script di test eseguiranno i carichi di lavoro per un'ora (a meno che non venga indicato diversamente dal documento di analisi del carico di lavoro).
  • La verifica e la valutazione dell'esecuzione per ogni scenario di test (di un carico di lavoro) includeranno:
    • L'esecuzione del test verrà monitorata utilizzando degli istogrammi di stato (per verificare che il test e i carichi di lavoro vengano eseguiti come previsto e desiderato)
    • L'esecuzione dello script di test (ogni script di test è stato eseguito correttamente e nel modo previsto?)
    • La cattura e la valutazione dei tempi di risposta identificati utilizzando i seguenti report:
      • Percentuale delle prestazioni
      • Tempo di risposta


Criteri di completamento

I criteri di completamento vengono indicati per due ragioni:

  • identificare la qualità del prodotto accettabile
  • identificare quando l'impegno del test è stato implementato correttamente

Una chiara istruzione dei criteri di completamento dovrebbe includere le seguenti voci:

  • funzione, funzionalità o condizione che si sta misurando
  • metodo di misurazione
  • criteri o grado di conformità alla misurazione

Esempio 1

  • Sono stati eseguiti tutti gli scenari di test pianificati
  • Tutti i difetti identificati sono stati verificati ed è stata trovata una soluzione concordata
  • Tutti gli scenari di test pianificati sono stati rieseguiti e tutti i difetti noti sono stati verificati come previsto e non è stato rilevato alcun nuovo difetto

Esempio 2

  • Sono stati eseguiti tutti gli scenari di test con priorità elevata.
  • Tutti i difetti identificati sono stati verificati ed è stata trovata una soluzione concordata.
  • Sono stati risolti tutti i difetti con severità 1 o 2 (stato = corretti o rinviati).
  • Tutti gli scenari di test con priorità elevata sono stati rieseguiti e tutti i difetti noti sono stati verificati come previsto e non è stato rilevato alcun nuovo difetto.

Esempio 3

  • Sono stati eseguiti tutti gli scenari di test pianificati.
  • Tutti i difetti identificati sono stati verificati ed è stata trovata una soluzione concordata.
  • Sono stati risolti tutti i difetti con severità 1 o 2 (stato = verificati o rinviati).
  • Tutti gli scenari di test con priorità elevata sono stati rieseguiti e tutti i difetti noti sono stati verificati come previsto e non è stato rilevato alcun nuovo difetto.

Considerazioni particolari

Questa sezione dovrebbe identificare le influenze o le dipendenze che potrebbero avere impatti o influenza sull'impegno di test descritto nella strategia di test. Le influenze potrebbero includere:

  • risorse umane (disponibilità o esigenza di risorse non di test per supporto / partecipazione al test)
  • vincoli (disponibilità o limitazioni di apparecchiature o esigenza / mancanza di apparecchiature speciali)
  • requisiti speciali, ad esempio la pianificazione del test o l'accesso ai sistemi

Esempi:

  • I database di test richiederanno il supporto di un progettista / amministratore di database per creare e aggiornare i dati.
  • La verifica delle prestazioni del sistema utilizzerà i server sulla rete esistente (che supporta il traffico esterno al test). Occorrerà pianificare tale verifica dopo alcune ore per accertarsi che non vi sia alcun traffico esterno al test sulla rete.
  • L'obiettivo del test deve sincronizzare il sistema precedente (o la sincronizzazione simulata) per l'esecuzione e l'implementazione di una verifica funzionale completa