Nell'attività di progettazione del test, sono stati identificati e descritti due artefatti importanti: gli script di
test e gli scenari di test. Senza i dati del test, non è possibile implementare ed eseguire questi due artefatti. Essi
sono esclusivamente descrizioni di condizioni, scenari e percorsi senza valori concreti che li identifichino in modo
conciso. I dati del test, sebbene non siano un artefatto in se stessi, hanno un impatto significativo sul successo o
sul fallimento di un test. Non è possibile implementare ed eseguire una verifica senza tali dati, poiché sono necessari
per quanto segue:
-
input per creare una condizione
-
output per valutare un requisito
-
supporto (una pre-condizione al test)
Perciò, l'identificazione dei valori è uno sforzo importante che viene fatto quando gli scenari di test vengono
identificati (consultare Prodotto
di lavoro: Scenario di test e Linea guida: Scenario
di test).
Vi sono quattro attributi dei dati del test che occorre utilizzare durante l'identificazione dei dati del test reali:
-
complessità - il volume o la quantità di dati nei dati del test
-
ampiezza - il grado di variazione nei dati del test
-
ambito - la pertinenza dei dati del test all'obiettivo del test
-
architettura - la struttura fisica dei dati del test
Ognuna di queste caratteristiche viene discussa in maggiore dettaglio nelle sezioni seguenti:
La complessità è il volume o la quantità di dati utilizzati nella verifica. E' una considerazione importante perché una
quantità di dati troppo ridotta potrebbe non rispecchiare le condizioni della vita reale, mentre un numero troppo
elevato di dati è difficile da gestire. Idealmente, la verifica dovrebbe iniziare con una serie ridotta di dati che
supporti gli scenari di test critici (generalmente gli scenari di test positivi). Man mano che si acquista sicurezza
durante la verifica, sarebbe opportuno aumentare i dati del test finché la complessità dei dati non sia rappresentativa
dell'ambiente distribuito (o appropriata e attuabile).
L'ampiezza si riferisce al grado in cui i valori dei dati del test cambiano. E' possibile aumentare la complessità dei
dati del test creando ulteriori record. Anche se questa è spesso un'ottima soluzione, non verifica le variazioni reali
che ci si aspetterebbe di notare nei dati reali. Senza tali variazioni nei dati del test, è possibile che non si riesca
a identificare i difetti (dopo tutto, non tutti i prelievi da un ATM sono di $50.00). Quindi, i valori dei dati del
test dovrebbero rispecchiare i valori di dati presenti nell'ambiente distribuito, ad esempio un prelievo di $10.00 o di
$120.00. Inoltre, i dati dei test dovrebbero rispecchiare le informazioni del mondo reale, come ad esempio:
-
Nomi che includono titoli, valori numerici, punteggiatura e suffissi:
-
Dr. James Bandlin, Ms. Susan Smith e Rev. Joseph P. Mayers
-
James Johnson III, Steven Wilshire 3rd e Charles James Ellsworth, Esq.
-
Ellen Jones-Smythe, Brian P. Tellstor
-
Indirizzi suddivisi in più righe, ad esempio:
-
6500 Broadway Street
Suite 175
-
1550 Broadway
Floor 17
Mailstop 75A
-
Codici di avviamento postale, di nazioni e città e numeri di telefono reali e con corrispondenze
-
Lexington, MA, USA + 01 781 676 2400
-
Kista, Sweden +46 8 56 62 82 00
-
Paris, France +33 1 30 12 09 50
I valori dei dati del test possono essere una rappresentazione fisica o statistica dei dati reali per ottenere
un'ampiezza sufficiente. Entrambi i metodi sono validi e consigliati.
Per creare dati di test basati su una rappresentazione fisica dei dati distribuiti, identificare i valori consentiti (o
gli intervalli) per ogni elemento di dati nel database distribuito e verificare che, per ogni elemento di dati, almeno
un record nei dati del test contenga ogni valore consentito.
Per esempio:
|
Numero di conto (intervallo)
|
Codice PIN
(numero intero)
|
Saldo del conto
(numero decimale)
|
Tipo di conto
(stringa)
|
(S) 0812 0000 0000 a
0812 9999 9999
© 0829 0000 0000 a
0829 9999 9999
(X) 0799 0000 0000 a
0799 9999 9999
|
0000 - 9999
|
da -999,999.99 a 999,999.99
|
S, C, X
|
record 1
|
0812 0837 0293
|
8493
|
-3,123.84
|
S
|
record 2
|
0812 6493 8355
|
3558
|
8,438.53
|
S
|
record 3
|
0829 7483 0462
|
0352
|
673.00
|
C
|
record 4
|
0799 4896 1893
|
4896
|
493,498.49
|
X
|
La suddetta matrice contiene il numero minimo di record che rappresentano fisicamente i valori di dati accettabili. Per
il numero di contro, esiste un record per ognuno dei tre intervalli, tutti i codici PIN rientrano nell'intervallo
specificato, esistono differenti saldi di conto, incluso uno negativo, e sono presenti record per ogni tipo di conto
differente. La suddetta matrice è costituita dai dati minimi e si consiglia di fare in modo che i valori di dati
rientrino nei limiti di ogni intervallo oltre che nell'intervallo stesso (consultare Linee guida: Scenario
di test).
Il vantaggio della rappresentazione fisica è che i dati del test sono limitati in dimensione, gestibili e incentrati e
proiettati sui valori accettabili. Lo svantaggio, tuttavia, è che i dati effettivi del mondo reale non sono del tutto
casuali. I dati reali tendono ad avere profili statici che potrebbero influenzare le prestazioni, le quali, in caso di
utilizzo di una rappresentazione fisica, non verrebbero osservate.
La rappresentazione statistica dei dati del test è costituita da dati che rispecchiano un campionario statistico (delle
stesse percentuali) dei dati di produzione. Ad esempio, utilizzando gli stessi elementi di dati precedenti, se si
analizza il database di produzione e si rileva quanto segue:
-
Numero totale di record: 294.031
-
Numero totale di conti di tipo S: 141.135 (48 % del totale)
-
Numero totale di conti di tipo C: 144.075 (49 %)
-
Numero totale di conti di tipo X: 8.821 (3 %)
-
Numeri di conto e codici PIN vengono distribuiti in modo uniforme
i dati del test, basati su un campionario statistico includerebbero 294 record (confrontati con i quattro descritti in
precedenza):
|
Dati del test (allo .1 percento della produzione)
|
Numero di record
|
Percentuale
|
Numero totale di record
|
294
|
100
|
Numeri di conto
(S) 0812 0000 0000 a
0812 9999 9999
|
141
|
48
|
Numeri di conto
© 0829 0000 0000 a
0829 9999 9999
|
144
|
49
|
Numeri di conto
(X) 0799 0000 0000 a
0799 9999 9999
|
9
|
3
|
La suddetta matrice verifica solo i tipi di conto. Nello sviluppo di dati del test basati su una rappresentazione
statistica, verrebbero inclusi gli elementi di dati significativi. Nell'esempio precedente, ciò includerebbe i saldi di
conto reali.
Uno svantaggio della rappresentazione statistica è che potrebbe non riflettere la gamma completa di valori accettabili.
Generalmente, si utilizzano entrambi i metodi di identificazione dati del test per verificare che tali dati verifichino
tutte le problematiche relative a popolazione / prestazioni e valori.
L'ampiezza dei dati del test è rilevante sia per i dati del test utilizzati come input che per quelli utilizzati per
supportare la verifica (nei dati pre-esistenti).
L'ambito è la pertinenza dei dati del test all'obiettivo del test ed è correlato alla complessità e all'ampiezza. La
presenza di un numero elevato di dati non significa che siano quelli giusti. Come avviene con l'ampiezza dei dati del
test, occorre verificare che tali dati siano pertinenti all'obiettivo del test, ossia che esistano dati del test che
supportino l'obiettivo del test specifico.
Ad esempio, nella seguente matrice, i primi quattro record di dati del test verificano i valori accettabili per ogni
elemento di dati. Tuttavia, non esistono record per valutare i saldi negativi per i conti di tipo C e X. Quindi,
sebbene questi dati del test includono correttamente un saldo negativo (ampiezza valida), i dati seguenti sarebbero
insufficienti, nel relativo ambito, per supportare qualsiasi verifica che utilizza saldi di conto negativi per ogni
tipo di conto. L'espansione di tali dati per includere ulteriori record, compresi saldi negativi per ogni tipo di conto
differente, potrebbe essere necessaria per risolvere questa svista.
|
Numero di conto (intervallo)
|
Codice PIN
(numero intero)
|
Saldo del conto
(numero decimale)
|
Tipo di conto
(stringa)
|
(S) 0812 0000 0000 a
0812 9999 9999
© 0829 0000 0000 a
0829 9999 9999
(X) 0799 0000 0000 a
0799 9999 9999
|
0000 - 9999
|
da -999,999.99 a 999,999.99
|
S, C, X
|
record 1
|
0812 0837 0293
|
8493
|
-3,123.84
|
S
|
record 2
|
0812 6493 8355
|
3558
|
8,438.53
|
S
|
record 3
|
0829 7483 0462
|
0352
|
673.00
|
C
|
record 4
|
0799 4896 1893
|
4896
|
493,498.49
|
X
|
Nuovo record 1
|
0829 3491 4927
|
0352
|
-995,498.34
|
C
|
Nuovo record 2
|
0799 6578 9436
|
4896
|
-64,913.87
|
X
|
L'ambito dei dati del test è rilevante sia per i dati del test utilizzati come input che per quelli utilizzati per
supportare la verifica (nei dati pre-esistenti).
La struttura fisica dei dati del test è pertinente solo per dati pre-esistenti utilizzati dall'obiettivo del test per
supportare la verifica, ad esempio una database dell'applicazione o una tabella di regole.
La verifica non viene eseguita una volta e terminata. Viene ripetuta all'interno e tra le iterazioni. Per eseguire la
verifica in modo coerente, certo ed efficace, si consiglia di riportare i dati del test allo stato iniziale, precedente
all'esecuzione del test. Ciò vale soprattutto quando occorre automatizzare la verifica.
Quindi, per assicurare integrità, sicurezza ed efficienza della verifica, è importante che i dati del test siano liberi
da tutte le influenze esterne e che lo stato sia noto all'inizio, durante e alla fine dell'esecuzione del test. Per
raggiungere tale obiettivo del test, occorre verificare due questioni:
Ognuna di tali problematiche influenza le modalità di gestione del database di test, di progettazione del modello di
test e di interazione con altri ruoli.
E' possibile che i dati del test diventino instabili per le seguenti ragioni:
-
le influenze correlate esterne al test modificano i dati
-
i tester non conoscono i dati utilizzati dagli altri
Per mantenere la sicurezza e l'integrità della verifica, si consiglia di controllare ampiamente i dati del test e di
isolarli da tali influenze. Le strategie che assicurano l'isolamento dei dati includono:
-
ambienti di test separati - i tester hanno il proprio ambiente di test, fisicamente separato da altri. I tester non
condividono nulla, ossia, hanno il proprio obiettivo di test e i propri dati. Ciò può essere ottenuto, ad esempio,
fornendo ad ogni tester, un PC personale.
-
istanze di base separate dei dati del test - i tester hanno la propria istanza di dati, isolata da tutte le altre
influenze. L'ambiente fisico e, probabilmente, anche l'obiettivo del test vengono condivisi, ma con ogni tester che
dispone della propria istanza di dati, il rischio di contaminazione è minimo.
-
partizionamento database / dati del test - tutti i tester condividono il database e sono a conoscenza dei dati
utilizzati da altri (ed evitano di utilizzare i dati di altri tester). Ad esempio, è possibile che un tester
utilizzi i record 0 - 99 e un altro utilizzi i record 100 - 199 o che qualcuno utilizzi clienti con cognomi Aa -
Kz, mentre un altro tester utilizzi pazienti il cui nome inizia per La - Zz.
L'altra problematica da risolvere inerente all'architettura dei dati del test è lo stato iniziale di tali dati
all'inizio dell'esecuzione del test. Ciò è particolarmente frequente quando si utilizza l'automazione del test. Così
come l'obiettivo del test deve iniziare l'esecuzione del test in uno stato noto e desiderato, lo stesso avviene per i
dati del test. Ciò contribuisce alla ripetitività e sicurezza che ogni esecuzione di test sia uguale alla precedente.
Per risolvere tale problematica, vengono generalmente utilizzate quattro strategie:
-
aggiornamento dei dati
-
reinizializzazione dei dati
-
ripristino dei dati
-
inoltro dei dati
Ognuna viene descritta in maniera dettagliata nelle sezioni seguenti.
Il metodo utilizzato dipenderà da diversi fattori, comprese le caratteristiche fisiche del database, la competenza
tecnica dei tester, la disponibilità di ruoli esterni al test e l'obiettivo del test.
Il metodo più consigliabile di restituzione dei dati del test allo stato iniziale è l'aggiornamento dei dati. Tale
metodo include la creazione di una copia del database nel proprio stato iniziale e della relativa memorizzazione. Al
completamento dell'esecuzione del test (o prima dell'esecuzione del test) la copia archiviata del database del test
viene copiata nell'ambiente di test per essere utilizzata. Ciò assicura che lo stato iniziale dei dati del test sia lo
stesso all'inizio di ogni esecuzione di test.
Un vantaggio di tale metodo è che i dati possono essere archiviati in sette stati iniziali differenti. Ad esempio, è
possibile archiviarli nello stato "fine del giorno", "fine della settimana", "fine del mese", ecc. In questo modo, al
tester viene fornito un metodo di aggiornamento rapido dei dati a uno stato specificato per supportare un test, ad
esempio la verifica dei casi d'uso della fine del mese.
Se non è possibile aggiornare i dati, il successivo metodo migliore è il ripristino dei dati al loro stato iniziale,
tramite mezzi programmatici. La reinizializzazione dei dati si affida a tool e casi d'uso speciali per riportare i dati
del test ai valori iniziali.
Prestare attenzione nel verificare che tutti i dati, le relazioni e i valori chiave vengano riportati ai relativi
valori iniziali, per evitare di introdurre errori nei dati.
Un vantaggio di tale metodo è che può supportare la verifica dei valori non validi nel database. In condizioni normali
i valori di dati non validi verrebbero catturati e l'accesso ai dati non permesso (ad esempio, tramite una regola nel
client). Tuttavia, un altro attore potrebbe influenzare i dati (ad esempio un aggiornamento elettronico da un altro
sistema). La verifica deve controllare che i dati non validi vengano identificati e gestiti nel modo appropriato,
indipendentemente da come sono stati introdotti.
Un semplice metodo per riportare i dati allo stato iniziale è "invertire le modifiche" apportate durante il test.
Questo metodo si affida all'utilizzo dell'obiettivo del test per immettere voci di inversione, ossia, per aggiungere
record / valori che sono stati eliminati, annullando le modifiche dei record / valori modificati ed eliminando i dati
aggiunti.
Esistono, tuttavia, dei rischi associati a questo metodo, tra cui:
-
è necessario invertire tutte le azioni, non solo alcune
-
si affida ai casi d'uso nell'obiettivo del test (che devono essere testati per verificare la funzionalità corretta
prima di poter essere utilizzati per il ripristino dei dati).
-
chiavi database, indici e punti potrebbero non essere ripristinati (per dimenticanza o per impossibilità)
Se questo è l'unico metodo disponibile nel proprio ambiente di test, evitare l'utilizzo di chiavi del database, indici
e puntatori come destinazioni primarie per la verifica. Ossia, ad esempio, utilizzare il campo Nome paziente per
stabilire se il paziente è stato aggiunto al database anziché utilizzare un numero ID del paziente generato dal
sistema.
L'inoltro dei dati è il metodo meno sconsigliato di verifica dello stato iniziale dei dati del test. Infatti, non
risolve realmente la questione. Al contrario, lo stato dei dati al completamento dell'esecuzione del test diventa il
nuovo stato iniziale dei dati del test. Generalmente, questo richiede la modifica dei dati del test utilizzati per
l'input e / o dei dati del test e degli scenari di test utilizzati per la valutazione dei risultati.
Esistono alcune istanze in cui ciò è necessario, ad esempio alla fine del mese. Se non esiste alcun archivio di dati,
esattamente prima della fine del mese, occorre eseguire i dati e gli script di test di ogni giorno e settimana per
"inoltrare" i dati allo stato necessario per il test dell'elaborazione di fine mese.
Tra i rischi associati con questo metodo vanno annoverati:
-
chiavi database, indici e punti non possono essere ripristinati (e non possono essere utilizzati per la verifica)
-
i dati sono in cambiamento costante
-
richiede un ulteriore impegno per certificare la verifica dei risultati
|