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