Menu

Test di convalida dei dati per ETL e progetti di migrazione dei dati

  • Principale
  • Altro
  • Test di convalida dei dati per ETL e progetti di migrazione dei dati

data validation tests

Prova Il Nostro Strumento Per Eliminare I Problemi

Questo tutorial descrive i progetti ETL e di migrazione dei dati e copre i controlli oi test di convalida dei dati per i progetti ETL / migrazione dei dati per una migliore qualità dei dati:

Questo articolo è rivolto ai tester di software che stanno lavorando a progetti ETL o di migrazione dei dati e sono interessati a concentrare i propri test solo sugli aspetti della qualità dei dati. Questi tipi di progetti hanno un enorme volume di dati che vengono archiviati nella memoria di origine e quindi vengono gestiti da una logica presente nel software e vengono spostati nella memoria di destinazione.

I test di convalida dei dati garantiscono che i dati presenti nei sistemi di destinazione finali siano validi, accurati, secondo i requisiti aziendali e adatti all'uso nel sistema di produzione live.

Convalida dei dati per ETL e progetti di migrazione dei dati

Il numero di aspetti della qualità dei dati che possono essere testati è enorme e questo elenco di seguito fornisce un'introduzione a questo argomento.

Cosa imparerai:

Che cos'è la convalida dei dati?

Convalida dei dati

In termini semplici, la convalida dei dati è l'atto di convalidare il fatto che i dati spostati come parte di ETL o processi di migrazione dei dati sono coerenti, accurati e completi nei sistemi live di produzione di destinazione per soddisfare i requisiti aziendali.

Esempio: L'indirizzo di uno studente nella tabella Studente era di 2000 caratteri nel sistema di origine. La convalida dei dati verifica se lo stesso identico valore risiede nel sistema di destinazione. Controlla se i dati sono stati troncati o se alcuni caratteri speciali vengono rimossi.

In questo articolo, discuteremo molti di questi controlli di convalida dei dati. Come tester per ETL o progetti di migrazione dei dati, aggiunge un enorme valore se scopriamo problemi di qualità dei dati che potrebbero essere propagati ai sistemi di destinazione e interrompere gli interi processi aziendali.

Perché convalidare i dati per i progetti ETL?

Nei progetti ETL, i dati vengono estratti dall'origine, elaborati applicando una logica nel software, trasformati e quindi caricati nella memoria di destinazione. In molti casi, la trasformazione viene eseguita per modificare i dati di origine in un formato più utilizzabile per i requisiti aziendali.

Qui, la convalida dei dati è necessaria per confermare che i dati caricati nel sistema di destinazione sono completi, accurati e non ci sono perdite di dati o discrepanze.

sistema di destinazione e origine

Esempio: Un'applicazione di e-commerce ha lavori ETL che prelevano tutti gli OrderIds contro ogni CustomerID dalla tabella Orders che somma il TotalDollarsSpend dal cliente e lo carica in una nuova tabella CustomerValue, contrassegnando ogni CustomerRating come cliente di valore alto / medio / basso su alcuni algoritmi complessi.

Un semplice test di convalida dei dati consiste nel verificare che CustomerRating sia calcolato correttamente.

Un altro test è verificare che TotalDollarSpend sia calcolato correttamente senza difetti nell'arrotondamento dei valori o overflow del valore massimo.

Perché convalidare i dati per i progetti di migrazione dei dati?

Nei progetti di migrazione dei dati, gli enormi volumi di dati archiviati nell'archivio di origine vengono migrati in diversi archivi di destinazione per molteplici motivi come l'aggiornamento dell'infrastruttura, la tecnologia obsoleta, l'ottimizzazione, ecc. Per esempio, le aziende potrebbero migrare il loro enorme data warehouse da sistemi legacy a soluzioni più nuove e più robuste su AWS o Azure.

Il motivo principale di tali progetti è spostare i dati dal sistema di origine a un sistema di destinazione in modo tale che i dati nella destinazione siano altamente utilizzabili senza interruzioni o impatti negativi per l'azienda.

Anche in questo caso, la convalida dei dati è necessaria per confermare che i dati sulla sorgente sono gli stessi nella destinazione dopo il movimento.

Esempio: Supponiamo che per l'applicazione e-commerce, la tabella Ordini che aveva 200 milioni di righe sia stata migrata nel sistema di destinazione su Azure. Un semplice test di convalida dei dati serve a verificare che tutti i 200 milioni di righe di dati siano disponibili nel sistema di destinazione.

Un altro test potrebbe essere quello di confermare che i formati della data corrispondono tra il sistema di origine e quello di destinazione.

Ci sono vari aspetti che i tester possono testare in tali progetti come test funzionali, test delle prestazioni, test di sicurezza, infra test, test E2E, test di regressione, ecc.

Lettura consigliata => Test di migrazione dei dati , Esercitazione sul test del data warehouse di test ETL

In questo articolo, esamineremo solo l'aspetto dei dati dei test per i progetti ETL e migrazione.

Foglio di mappatura dei dati

Per cominciare, crea un foglio di mappatura dei dati per il tuo progetto di dati. La mappatura dei dati è il processo di corrispondenza delle entità tra le tabelle di origine e di destinazione. Inizia documentando tutte le tabelle e le loro entità nel sistema di origine in un foglio di calcolo. Documentare ora i valori corrispondenti per ciascuna di queste righe che dovrebbero corrispondere nelle tabelle di destinazione. Annotare le regole di trasformazione in una colonna separata, se presenti.

I fogli di mappatura dati contengono molte informazioni raccolte dai modelli di dati forniti da Data Architects. Inizialmente, i tester potrebbero creare una versione semplificata e aggiungere ulteriori informazioni man mano che procedono. Vedere l'esempio del foglio di mappatura dei dati di seguito- tabella padre

Scarica un modello da Foglio di mappatura dei dati semplificato

Test di convalida dei dati

# 1) Uniformità dei dati

Vengono condotti test di uniformità dei dati per verificare che il valore effettivo dell'entità abbia l'esatta corrispondenza in luoghi diversi. Abbiamo due tipi di test possibili qui:

(i) Controlli all'interno dello stesso schema:

  • L'entità dati potrebbe esistere in due tabelle all'interno dello stesso schema (sistema di origine o sistema di destinazione)
  • Esempio: Come puoi vedere nell'immagine sottostante, ProductID è presente nella tabella OrderDetails e Products. Esegui una verifica della corrispondenza esatta per ProductId presente nella tabella OrderDetails vs Products.

Foglio di mappatura dei dati semplificato 1

(ii) Controlli tra schemi:

  • L'entità di dati potrebbe essere migrata così com'è nello schema di destinazione, ovvero è presente nel sistema di origine e nel sistema di destinazione
  • Esempio: Come puoi vedere nell'immagine sopra, ProductID è presente nella tabella Products nel sistema di origine e nella tabella Products nel sistema di destinazione. Eseguire una verifica della corrispondenza esatta per ProductId nella tabella Products nel sistema di origine con ProductId nella tabella Products nel sistema di destinazione.

Nota: È meglio evidenziare (codice colore) entità di dati corrispondenti nel foglio Mappatura dati per una rapida consultazione.

# 2) Presenza di entità

In questo tipo di test, dobbiamo convalidare che tutte le entità (tabelle e campi) siano abbinate tra origine e destinazione. Ci sono due possibilità, un'entità potrebbe essere presente o assente secondo la progettazione del modello di dati.

(io) Convalida che tutte le tabelle (e colonne), che hanno una presenza corrispondente sia nell'origine che nella destinazione, corrispondano. Tiriamo un elenco di tutte le tabelle (e colonne) e facciamo un confronto di testo. Questo test di sanità mentale funziona solo se vengono utilizzati gli stessi nomi di entità.

A volte vengono utilizzati nomi di tabella diversi e quindi un confronto diretto potrebbe non funzionare. Potremmo dover mappare queste informazioni nel foglio di mappatura dei dati e convalidarlo per gli errori.

Un'altra possibilità è l'assenza di dati. Ci sono casi in cui il modello di dati richiede che una tabella nel sistema di origine (o colonna) non abbia una presenza corrispondente nel sistema di destinazione (o viceversa). Avere test per convalidare questo.

  • Esempio: Come puoi vedere nell'immagine sottostante, CustDemographic Table è presente nel sistema di destinazione e non nel sistema di origine.
  • Il campo CustomerType nella tabella Customers contiene dati solo nel sistema di origine e non nel sistema di destinazione.

dardo (precisione dei dati)

# 3) Precisione dei dati

Come suggerisce il nome, convalidiamo se i dati sono logicamente accurati. Esistono due categorie per questo tipo di test. Con questo, il tester può rilevare i problemi di qualità dei dati anche nel sistema di origine.

L

(Immagine fonte )

Nota: Eseguire questo test nel sistema di destinazione e controllare a ritroso nel sistema di origine eventuali difetti.

(i) Tipo non numerico: Sotto questa classificazione, verifichiamo l'accuratezza del contenuto non numerico. Esempi sono e-mail, codici PIN, telefono in un formato valido.

(ii) Analisi del dominio: In questo tipo di test, selezioniamo domini di dati e convalidiamo gli errori. Ci sono tre raggruppamenti per questo:

  • Basato sul valore: Qui creiamo un elenco di valori che possono verificarsi per un campo (colonna nella tabella). Quindi convalida se i valori delle colonne sono un sottoinsieme del nostro elenco.
    • Esempio: Verifica se la colonna Sesso contiene M o F.
  • Basato sulla gamma: Qui impostiamo l'intervallo minimo e massimo per valori di dati validi per una colonna, in base a ragionamenti logici o aziendali. Verifichiamo quindi se i valori della colonna rientrano in questo intervallo.
    • Esempio: Da 0 a 120 per Age.
  • File di riferimento : Qui il sistema utilizza un file di validità esterno.
    • Esempio: I codici paese sono validi, scelgono il valore corretto dal file di riferimento, i codici paese sono gli stessi tra QA e l'ambiente di produzione? Se il file di riferimento aveva un codice paese aggiornato, è giustamente aggiornato in DB?

# 4) Convalida dei metadati

Nella convalida dei metadati, convalidiamo che le definizioni del tipo di dati di tabella e colonna per la destinazione siano progettate correttamente e, una volta progettate, vengono eseguite secondo le specifiche di progettazione del modello di dati.

Ci sono due raggruppamenti qui:

subnet mask predefinita per la classe d

(i) Progettazione dei metadati: Il primo controllo è convalidare che il modello di dati sia progettato correttamente in base ai requisiti aziendali per le tabelle di destinazione. Gli architetti dei dati possono migrare le entità dello schema o possono apportare modifiche quando progettano il sistema di destinazione.

Il prossimo controllo dovrebbe essere quello di convalidare che gli script corretti siano stati creati utilizzando i modelli di dati.

Per ciascuna categoria di seguito, verifichiamo prima se i metadati definiti per il sistema di destinazione soddisfano i requisiti aziendali e, in secondo luogo, se le tabelle e le definizioni dei campi sono state create accuratamente.

Di seguito vengono forniti alcuni controlli dei metadati:

  • Controllo del tipo di dati: Esempio: Total Sales funzionerà correttamente con il tipo Decimal (8, 16 o 20 byte) o Double?
  • Controllo lunghezza dati : Esempio: La lunghezza dei dati per il campo Indirizzo sarà sufficiente con 500 caratteri? Potrebbe essere un caso in cui la migrazione dei dati viene eseguita mentre la nuova area geografica viene aggiunta all'azienda. Gli indirizzi della nuova area geografica potrebbero avere un formato eccessivamente lungo e il mantenimento della lunghezza originale potrebbe causare errori in un caso d'uso.
  • Controllo dell'indice: Esempio: Viene eseguita l'indicizzazione per la colonna OrderId nel sistema di destinazione? Cosa succede se si verifica una fusione di aziende, che richiede la migrazione dei dati e la tabella Ordini cresce di 100 volte di dimensioni nel sistema di destinazione?
  • Controllo dei metadati negli ambienti: Sotto questo controllo, verifica che i metadati corrispondano tra il test QA e l'ambiente di produzione. I test potrebbero passare nell'ambiente QA ma fallire in altri ambienti.

(ii) Modifica del delta: Questi test rivelano i difetti che si verificano quando il progetto è in corso ea metà strada ci sono modifiche ai metadati del sistema di origine e non sono state implementate nei sistemi di destinazione.

Esempio: Il nuovo campo CSI (Indice di soddisfazione del cliente) è stato aggiunto alla tabella Cliente nell'origine ma non è stato possibile impostarlo sul sistema di destinazione.

# 5) Integrità dei dati

Qui, convalidiamo principalmente i vincoli di integrità come Chiave esterna, Riferimento chiave primaria, Unico, Predefinito, ecc.

tabella padre

(Immagine fonte )

Per le chiavi esterne, dobbiamo controllare se ci sono record orfani nella tabella figlia in cui la chiave esterna utilizzata non è presente nella tabella padre.

Controllo della completezza dei dati

Esempio: La tabella dei clienti ha CustomerID che è una chiave primaria. La tabella degli ordini ha CustomerID come chiave esterna. La tabella degli ordini potrebbe avere un ID cliente che non si trova nella tabella dei clienti. Abbiamo bisogno di test per scoprire tali violazioni dei vincoli di integrità. La tabella Data Mapping ti darà chiarezza su quali tabelle hanno questi vincoli.

Nota: Eseguire questo test nel sistema di destinazione e controllare a ritroso nel sistema di origine se sono presenti difetti.

# 6) Completezza dei dati

Si tratta di test di integrità che rivelano i conteggi di record o righe mancanti tra la tabella di origine e di destinazione e possono essere eseguiti frequentemente una volta automatizzati.

Esistono due tipi di test:

(i) Conteggio record: Qui, confrontiamo il conteggio totale dei record per le tabelle corrispondenti tra il sistema di origine e quello di destinazione. Si tratta di un rapido controllo di integrità per verificare la post-esecuzione del lavoro ETL o di migrazione. Abbiamo un difetto se i conteggi non corrispondono.

A volte ci sono record rifiutati durante l'esecuzione del lavoro. Alcuni di questi potrebbero essere validi. Ma come tester, ne facciamo un esempio.

(ii) Profilazione dati colonna: Questo tipo di test di sanità mentale è utile quando i conteggi dei record sono enormi. Qui creiamo set logici di dati che riducono il conteggio dei record e quindi eseguiamo un confronto tra origine e destinazione.

  • Dove possibile, filtra tutti i valori univoci in una colonna, per esempio, ProductID potrebbe verificarsi più volte nella tabella OrderDetails. Scegli un elenco univoco per ProductID dalle tabelle di destinazione e di origine e convalida. Ciò riduce notevolmente il numero di conteggi di record e accelera i test di sanità mentale.
  • Come i test precedenti, possiamo anche scegliere tutte le colonne principali e controllare se i KPI (lunghezza minima, massima, media, massima o minima, ecc.) Corrispondono tra la tabella di destinazione e di origine. Esempio: Prendi i valori medio, minimo e massimo dalla colonna Prezzo in OrderDetails e confronta questi valori tra le tabelle di destinazione e di origine per le mancate corrispondenze.
  • È possibile eseguire un altro controllo per i valori Null. Scegli le colonne importanti e filtra un elenco di righe in cui la colonna contiene valori Null. Confronta queste righe tra i sistemi di destinazione e di origine per la mancata corrispondenza.

Linea del tempo

# 7) Trasformazione dei dati

Questi test costituiscono i test principali del progetto. Esaminare il documento dei requisiti per comprendere i requisiti di trasformazione. Preparare i dati di test nei sistemi di origine per riflettere diversi scenari di trasformazione. Questi hanno una moltitudine di test e dovrebbero essere trattati in dettaglio negli argomenti dei test ETL.

Di seguito è riportato un elenco conciso di test coperti da questo:

(i) Trasformazione:

  • Esempio: Il codice ETL potrebbe avere una logica per rifiutare dati non validi. Verificare questi rispetto ai requisiti.
  • Il codice ETL potrebbe anche contenere la logica per generare automaticamente determinate chiavi come le chiavi surrogate. Abbiamo bisogno di test per verificare la correttezza (tecnica e logica) di questi.
  • Convalidare la correttezza dell'unione o della divisione dei valori dei campi dopo che un lavoro ETL o di migrazione è stato eseguito.
  • Avere test per verificare i controlli di integrità referenziale. Per esempio, un tipo di difetto potrebbe essere ProductId utilizzato nella tabella Orders non è presente nella tabella padre Products. Eseguire un test per verificare come si comportano i record orfani durante un lavoro ETL.
  • A volte, i dati mancanti vengono inseriti utilizzando il codice ETL. Verificare la correttezza di questi.
  • Gli script ETL o di migrazione a volte hanno una logica per correggere i dati. Verificare che la correzione dei dati funzioni.
  • Verificare se vengono segnalati agli utenti dati non validi / rifiutati / errati.
  • Creare un foglio di calcolo di scenari di dati di input e risultati attesi e convalidarli con il cliente aziendale.

(ii) casi limite: Verificare che la logica di trasformazione sia valida ai confini.

  • Esempio: Cosa succede quando TotalSales con un valore di 1 trilione viene eseguito tramite un lavoro ETL? I casi end-to-end funzionano? Identificare i campi che possono potenzialmente avere valori elevati ed eseguire test con questi valori elevati. Dovrebbero includere valori numerici e non numerici.
  • Per i campi data, compreso l'intero intervallo di date previste: anni bisestili, 28/29 giorni per febbraio. 30, 31 giorni per gli altri mesi.

# 8) Unicità o duplicazione dei dati

In questo tipo di test, identificare le colonne che dovrebbero avere valori univoci secondo il modello di dati. Inoltre, prendi in considerazione la logica aziendale per eliminare tali dati. Eseguire test per verificare se sono univoci nel sistema. Eseguire i test successivi per identificare i duplicati effettivi.

  • Esempio: Filtra i dati duplicati e verifica se sono autentici. Per esempio, Il record dipendente del dipendente contiene due volte gli stessi dati di pari livello.
  • Il numero di telefono dell'utente deve essere univoco nel sistema (requisito aziendale).
  • Il requisito aziendale dice che una combinazione di ProductID e ProductName nella tabella Products deve essere univoca poiché ProductName può essere duplicato.

# 9) Obbligatorio

In questo tipo di test, identificare tutti i campi contrassegnati come Obbligatori e convalidare se i campi obbligatori hanno valori. Se sono presenti valori predefiniti associati a un campo nel DB, verificare che sia popolato correttamente quando i dati non sono presenti.

  • Esempio: Se BillDate non viene immesso, CurrentDate è BillDate.

# 10) Tempestività

Documenta sempre i test che verificano che stai lavorando con i dati dalle tempistiche concordate.

  • Esempio: ProductDiscount è stato aggiornato 15 giorni fa e il dominio aziendale afferma che ProductDiscount cambia ogni sette giorni. Ciò significa che i tuoi test non vengono eseguiti con i giusti valori di sconto.
  • Un report di analisi predittiva per l'indice di soddisfazione del cliente avrebbe dovuto funzionare con i dati dell'ultima settimana, ovvero una settimana di promozione delle vendite presso Walmart. Ma il lavoro ETL è stato progettato per essere eseguito con una frequenza di 15 giorni. Questo è un grave difetto che i tester possono scoprire.

# 11) Dati nulli

In questo tipo di test, ci concentriamo sulla validità dei dati nulli e sulla verifica che la colonna importante non possa essere nulla.

  • Esempio: Filtra tutti i dati null e convalida se null è consentito.
  • Se sono presenti colonne importanti per le decisioni aziendali, assicurati che non siano presenti valori nulli.

# 12) Controllo della portata

L'entità di dati in cui gli intervalli hanno senso per il business dovrebbe essere testata.

  • Esempio: La quantità dell'ordine per fattura non può essere superiore a 5K nella categoria software.
  • L'età non dovrebbe essere superiore a 120.

# 13) Regole aziendali

Documentare eventuali requisiti aziendali per i campi ed eseguire test per lo stesso.

  • Esempio: Le risorse con età inferiore a 20 anni non sono ammissibili. Se questa regola viene applicata ai dati, sono necessari controlli di convalida dei dati.
  • La data di cessazione deve essere nulla se lo stato di dipendente attivo è Vero / Deceduto.
  • I dati FROM devono essere inferiori a TO Date.
  • Gli importi degli acquisti a livello di articolo si sommano agli importi a livello di ordine

# 14) Funzioni aggregate

Le funzioni aggregate sono integrate nella funzionalità del database. Documentare tutti gli aggregati nel sistema di origine e verificare se l'utilizzo aggregato fornisce gli stessi valori nel sistema di destinazione (sum, max, min, count).

Molto spesso gli strumenti sul sistema di origine sono diversi dal sistema di destinazione. Controlla se entrambi gli strumenti eseguono le funzioni di aggregazione nello stesso modo.

# 15) Troncamento e arrotondamento dei dati

In questi tipi di test, identifichiamo i campi con logica di troncamento e arrotondamento relativi al business. Quindi documentiamo e otteniamo l'approvazione sulla logica di troncamento e arrotondamento con i proprietari del prodotto e li testiamo con i dati rappresentativi della produzione.

# 16) Test di codifica

Convalidare se sono presenti valori codificati nel sistema di origine e verificare se i dati sono correttamente popolati dopo l'ETL o il lavoro di migrazione dei dati nel sistema di destinazione.

  • Esempio: I caratteri a doppio byte per FirstName in cinese sono stati accettati nel sistema di origine che è stato codificato. Verificare il comportamento di questo campo quando viene spostato nel sistema di destinazione.
  • Il campo Password è stato codificato e migrato. Assicurati che funzionino bene dopo la migrazione.

# 17) Test di regressione

Questo è un concetto di test di base in cui i tester eseguono tutta la loro suite di casi di test critici generata utilizzando l'elenco di controllo sopra riportato dopo una modifica al sistema di origine o di destinazione.

Conclusione

Quindi, abbiamo visto che la convalida dei dati è un'area interessante da esplorare per progetti ad alta intensità di dati e costituisce i test più importanti. Il foglio di mappatura dei dati è un artefatto fondamentale che i tester devono mantenere per ottenere il successo con questi test. Possono mantenere più versioni con evidenziazioni di colore per formare input per uno dei test sopra.

È necessario prestare attenzione per mantenere le modifiche delta tra le versioni.

Chiediamo ai lettori di condividere altre aree del test che hanno incontrato durante il loro lavoro a beneficio della comunità dei tester.

Lettura consigliata

^