Linea guida: Dati del test
Questa linea guida è un'introduzione alla progettazione delle serie di dati del test.
Relazioni
Elementi correlati
Descrizione principale

Spiegazione

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:

Complessità

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

Ampiezza

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

Ambito

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

Architettura

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.

Instabilità / Isolamento

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.

Stato iniziale

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.

Aggiornamento dei dati

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.

Reinizializzazione dei dati

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.

Ripristino dei dati

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.

Inoltro dei dati

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