Teste de validare a datelor pentru ETL și proiecte de migrare a datelor

data validation tests

Acest tutorial descrie proiectele ETL și migrarea datelor și acoperă verificările sau testele de validare a datelor pentru proiectele ETL / migrarea datelor pentru o calitate îmbunătățită a datelor:

Acest articol este destinat testerilor de software care lucrează la proiecte ETL sau de migrare a datelor și sunt interesați să își concentreze testele doar asupra aspectelor privind calitatea datelor. Aceste tipuri de proiecte au un volum imens de date care sunt stocate pe stocarea sursă și apoi sunt operate de o logică prezentă în software și sunt mutate în stocarea țintă.

Testele de validare a datelor asigură faptul că datele prezente în sistemele țintă finale sunt valide, exacte, conform cerințelor afacerii și bune pentru utilizare în sistemul de producție live.

Numărul aspectelor privind calitatea datelor care pot fi testate este imens și această listă de mai jos oferă o introducere la acest subiect.

Ce veți învăța:

• Ce este validarea datelor?
• De ce să validați datele pentru proiectele ETL?
• De ce să validăm datele pentru proiectele de migrare a datelor?
  • Foaie de cartografiere a datelor
  • Teste de validare a datelor
    • # 1) Uniformitatea datelor
    • # 2) Prezența entității
    • # 3) Precizia datelor
    • # 4) Validarea metadatelor
    • # 5) Integritatea datelor
    • # 6) Completitatea datelor
    • # 7) Transformarea datelor
    • # 8) Unicitatea sau duplicarea datelor
    • # 9) Obligatoriu
    • # 10) Actualitatea
    • # 11) Date nule
    • # 12) Verificarea autonomiei
    • # 13) Reguli de afaceri
    • # 14) Funcții agregate
    • # 15) Trunchierea și rotunjirea datelor
    • # 16) Teste de codificare
    • # 17) Teste de regresie
• Concluzie
  • Lectură recomandată

Ce este validarea datelor?

În termeni simpli, validarea datelor este actul de validare a faptului că datele care sunt mutate ca parte a ETL sau a joburilor de migrare a datelor sunt consistente, exacte și complete în sistemele live de producție țintă pentru a satisface cerințele afacerii.

Exemplu: Adresa unui student din tabelul Student a fost de 2000 de caractere în sistemul sursă. Validarea datelor verifică dacă exact aceeași valoare se află în sistemul țintă. Se verifică dacă datele au fost trunchiate sau dacă anumite caractere speciale sunt eliminate.

În acest articol, vom discuta multe dintre aceste verificări de validare a datelor. În calitate de testeri pentru proiecte ETL sau de migrare a datelor, adaugă o valoare extraordinară dacă descoperim probleme de calitate a datelor care ar putea fi propagate către sistemele țintă și perturbarea întregului proces de afaceri.

De ce să validați datele pentru proiectele ETL?

În proiectele ETL, datele sunt extrase din sursă, prelucrate prin aplicarea unor logici în software, transformate și apoi încărcate în spațiul de stocare țintă. În multe cazuri, transformarea se face pentru a schimba datele sursă într-un format mai utilizabil pentru cerințele afacerii.

Aici, validarea datelor este necesară pentru a confirma că datele încărcate în sistemul țintă sunt complete, exacte și că nu există pierderi de date sau discrepanțe.

Exemplu: O aplicație de comerț electronic are joburi ETL care selectează toate comenzile ID-uri pentru fiecare ID client din tabelul Comenzi, care rezumă TotalDollarsSpend de către client și îl încarcă într-un nou tabel CustomerValue, marcând fiecare client Evaluându-se ca clienți cu valoare ridicată / medie / scăzută pe un algoritm complex.

Testul simplu de validare a datelor constă în evaluarea corectă a evaluării clienților.

Un alt test este de a verifica dacă TotalDollarSpend este corect calculat, fără defecte la rotunjirea valorilor sau a depășirilor de valoare maximă.

De ce să validăm datele pentru proiectele de migrare a datelor?

În proiectele de migrare a datelor, volumele uriașe de date stocate în stocarea sursă sunt migrate către stocarea țintă diferită din mai multe motive, cum ar fi actualizarea infrastructurii, tehnologia învechită, optimizarea etc. De exemplu, companiile ar putea migra imensul lor depozit de date de la sisteme vechi la soluții mai noi și mai robuste pe AWS sau Azure.

Motivul principal pentru astfel de proiecte este mutarea datelor din sistemul sursă într-un sistem țintă, astfel încât datele din țintă să fie extrem de utilizabile fără nicio întrerupere sau impact negativ asupra afacerii.

Din nou, este necesară validarea datelor pentru a confirma că datele de pe sursă sunt aceleași în țintă după mișcare.

Exemplu: Să presupunem că pentru aplicația de comerț electronic, tabelul Comenzi care avea 200 de milioane de rânduri a fost migrat la sistemul țintă pe Azure. Testul simplu de validare a datelor este de a verifica dacă toate cele 200 de milioane de rânduri de date sunt disponibile în sistemul țintă.

Un alt test ar putea fi confirmarea faptului că formatele de date se potrivesc între sistemul sursă și sistemul țintă.

Există diferite aspecte pe care testerii le pot testa în astfel de proiecte, cum ar fi teste funcționale, teste de performanță, teste de securitate, infra teste, teste E2E, teste de regresie etc.

Lectură recomandată => Testarea migrării datelor , Tutorial de testare a depozitului de date ETL

În acest articol, ne vom uita doar la aspectul de date al testelor pentru proiectele ETL & Migration.

Foaie de cartografiere a datelor

Pentru început, creați o foaie de mapare a datelor pentru proiectul dvs. de date. Maparea datelor este procesul de potrivire a entităților între tabelele sursă și țintă. Începeți cu documentarea tuturor tabelelor și a entităților acestora din sistemul sursă într-o foaie de calcul. Acum documentați valorile corespunzătoare pentru fiecare dintre aceste rânduri care se așteaptă să se potrivească în tabelele țintă. Notați regulile de transformare într-o coloană separată, dacă există.

Fișele de mapare a datelor conțin o mulțime de informații culese din modelele de date furnizate de Data Architects. Inițial, testerii ar putea crea o versiune simplificată și pot adăuga mai multe informații pe măsură ce continuă. Vedeți exemplul de foaie de mapare a datelor de mai jos-

Descărcați un șablon de la Foaie de cartografiere a datelor simplificată

Teste de validare a datelor

# 1) Uniformitatea datelor

Se efectuează teste de uniformitate a datelor pentru a verifica dacă valoarea reală a entității are potrivirea exactă în diferite locuri. Aici sunt posibile două tipuri de teste:

(i) Verificări în cadrul aceleiași scheme:

• Entitatea de date ar putea exista în două tabele din aceeași schemă (fie sistem sursă, fie sistem țintă)
• Exemplu: După cum puteți vedea în imaginea de mai jos, ID-ul produsului este prezent în tabelul Detalii comenzi și produse. Efectuați o verificare exactă a potrivirii pentru ProductId prezent în tabelul OrderDetails vs Products.

(ii) Verificări între scheme:

• Entitatea de date ar putea fi migrată ca atare în schema țintă, adică este prezentă în sistemul sursă, precum și în sistemul țintă
• Exemplu: După cum puteți vedea în imaginea de mai sus, ProductID este prezent în tabelul Produse din sistemul sursă și tabelul Produse din sistemul țintă. Efectuați o verificare exactă a potrivirii pentru ProductId în tabelul Produse din sistemul sursă cu ProductId în tabelul Produse din sistemul țintă.

Notă: Cel mai bine este să evidențiați (codul culorilor) entitățile de date care se potrivesc în foaia de mapare a datelor pentru referință rapidă.

# 2) Prezența entității

În acest tip de test, trebuie să validăm faptul că toate entitățile (tabele și câmpuri) sunt potrivite între sursă și țintă. Există două posibilități, o entitate ar putea fi prezentă sau absentă conform proiectului modelului de date.

(i) Validați că toate tabelele (și coloanele), care au o prezență corespunzătoare atât în ​​sursă, cât și în țintă, se potrivesc. Tragem o listă cu toate tabelele (și coloanele) și comparăm textul. Acest test de sănătate funcționează numai dacă sunt utilizate aceleași nume de entități.

Uneori se folosesc nume de tabele diferite și, prin urmare, o comparație directă ar putea să nu funcționeze. Este posibil să trebuiască să mapăm aceste informații în foaia de mapare a datelor și să le validăm pentru eșecuri.

O altă posibilitate este absența datelor. Există cazuri în care modelul de date necesită ca un tabel din sistemul sursă (sau coloană) să nu aibă o prezență corespunzătoare în sistemul țintă (sau invers). Faceți teste pentru a valida acest lucru.

• Exemplu: După cum puteți vedea în imaginea de mai jos, CustDemographic Table este prezent în sistemul țintă și nu în sistemul sursă.
• Câmpul CustomerType din tabelul Clienți are date numai în sistemul sursă și nu în sistemul țintă.

# 3) Precizia datelor

După cum sugerează și numele, validăm dacă datele sunt corecte din punct de vedere logic. Există două categorii pentru acest tip de test. Cu aceasta, testerul poate surprinde problemele legate de calitatea datelor chiar și în sistemul sursă.

(imagine sursă )

Notă: Rulați acest test în sistemul țintă și verificați înapoi în sistemul sursă pentru eventuale defecte.

(i) Tipul nenumeric: În cadrul acestei clasificări, verificăm acuratețea conținutului nenumeric. Exemple sunt e-mailuri, coduri PIN, telefon într-un format valid.

(ii) Analiza domeniului: În acest tip de test, alegem domeniile de date și le validăm pentru erori. Există trei grupări pentru aceasta:

• Pe baza valorii: Aici creăm o listă de valori care pot apărea pentru un câmp (coloană din tabel). Apoi validați dacă valorile coloanei sunt un subset al listei noastre.
  • Exemplu: Verificați dacă coloana Sex conține fie M, fie F.
• Pe baza domeniului: Aici stabilim intervalul minim și maxim pentru valorile de date valide pentru o coloană, pe baza unui raționament logic sau de afaceri. Apoi validăm dacă valorile coloanei se încadrează în acest interval.
  • Exemplu: De la 0 la 120 pentru vârstă.
• Fișier de referință : Aici sistemul folosește un fișier de validitate extern.
  • Exemplu: Codurile de țară sunt valabile, aleg valoarea corectă din fișierul de referință, codurile de țară sunt aceleași între QA și mediul de producție? Dacă fișierul de referință a avut un cod de țară actualizat, este corect actualizat în DB?

# 4) Validarea metadatelor

În validarea metadatelor, validăm că definițiile tipului de date Tabel și Coloană pentru țintă sunt proiectate corect și, odată proiectate, sunt executate conform specificațiilor de proiectare a modelului de date.

Există două grupări aici:

aplicație gratuită de descărcare mp3 pentru telefonul Android

(i) Proiectarea metadatelor: Prima verificare este de a valida dacă modelul de date este proiectat corect conform cerințelor de afaceri pentru tabelele țintă. Arhitecții de date pot migra entități de schemă sau pot face modificări atunci când proiectează sistemul țintă.

Următoarea verificare ar trebui să fie pentru a valida faptul că scripturile potrivite au fost create folosind modelele de date.

Pentru fiecare categorie de mai jos, verificăm mai întâi dacă metadatele definite pentru sistemul țintă îndeplinesc cerința comercială și, în al doilea rând, dacă tabelele și definițiile câmpului au fost create cu precizie.

Câteva dintre verificările metadatelor sunt prezentate mai jos:

• Verificarea tipului de date: Exemplu: Vânzările totale vor funcționa corect cu tipul Decimal (8, 16 sau 20 octeți) sau Dublu?
• Verificarea lungimii datelor : Exemplu: Lungimea datelor pentru câmpul Adresă va fi suficientă cu 500 de caractere? S-ar putea să fie un caz în care migrarea datelor se face pe măsură ce noua geografie se adaugă la companie. Adresele noii geografii ar putea avea un format extrem de lung, iar respectarea lungimii inițiale ar putea greși un caz de utilizare.
• Verificare index: Exemplu: S-a făcut indexarea pentru coloana OrderId din sistemul țintă? Ce se întâmplă dacă s-a întâmplat o fuziune de companii, care necesită migrarea datelor, iar tabelul Comenzi crește de 100 de ori în sistemul țintă?
• Verificarea metadatelor în medii: În cadrul acestei verificări verificați dacă metadatele se potrivesc între testul QA și mediul de producție. Testele ar putea trece în mediul QA, dar nu în alte medii.

(ii) Schimbarea deltei: Aceste teste descoperă defectele care apar atunci când proiectul este în desfășurare și la jumătatea drumului, există modificări ale metadatelor sistemului sursă și nu au fost implementate în sistemele țintă.

Exemplu: Un nou câmp CSI (Customer Satisfaction Index) a fost adăugat la tabela Client din sursă, dar nu a reușit să fie introdus în sistemul țintă.

# 5) Integritatea datelor

Aici, validăm în principal constrângerile de integritate, cum ar fi cheia externă, referința cheii principale, unic, implicit etc.

(imagine sursă )

Pentru cheile străine, trebuie să verificăm dacă există înregistrări orfane în tabelul copil în care cheia externă utilizată nu este prezentă în tabelul părinte.

Exemplu: Tabelul Clienți are CustomerID, care este o cheie principală. Tabelul de comenzi are CustomerID ca cheie externă. Tabelul de comenzi ar putea avea un CustomerID care nu se află în tabelul Clienți. Trebuie să avem teste pentru a descoperi astfel de încălcări ale constrângerilor de integritate. Tabelul de mapare a datelor vă va oferi claritate asupra tabelelor care au aceste constrângeri.

Notă: Rulați acest test în sistemul țintă și reveniți la sistemul sursă dacă există defecte.

# 6) Completitatea datelor

Acestea sunt teste de sănătate care descoperă numărul de înregistrări sau rânduri lipsă între tabela sursă și țintă și pot fi rulate frecvent odată automatizate.

Există două tipuri de teste:

(i) Număr de înregistrări: Aici, comparăm numărul total de înregistrări pentru potrivirea tabelelor între sistemul sursă și sistemul țintă. Aceasta este o verificare rapidă a sănătății pentru a verifica post rularea jobului ETL sau Migration. Avem un defect dacă numărările nu se potrivesc.

Uneori, există înregistrări respinse în timpul executării lucrărilor. Unele dintre acestea pot fi valabile. Dar, în calitate de tester, facem un argument pentru acest lucru.

(ii) Profilarea datelor coloanelor: Acest tip de test de sănătate este valoros atunci când numărul de înregistrări este imens. Aici, creăm seturi logice de date care reduc numărul de înregistrări și apoi facem o comparație între sursă și țintă.

• Unde este posibil, filtrați toate valorile unice dintr-o coloană, de exemplu, ProductID s-ar putea să apară de mai multe ori în tabelul OrderDetails. Alegeți o listă unică pentru ProductID atât din tabelele țintă, cât și din tabelele sursă și validați. Acest lucru reduce numărul de înregistrări și accelerează testele de sănătate.
• La fel ca testele de mai sus, putem alege, de asemenea, toate coloanele majore și putem verifica dacă KPI-urile (lungimea minimă, maximă, medie, maximă sau minimă etc.) se potrivesc între tabelul țintă și sursa. Exemplu: Luați valori medii, minime și maxime din coloana Preț din OrderDetails și comparați aceste valori între tabelele țintă și sursă pentru nepotriviri.
• O altă verificare poate fi făcută pentru valorile Nule. Alegeți coloane importante și filtrați o listă de rânduri în care coloana conține valori nule. Comparați aceste rânduri între sistemele țintă și sursă pentru nepotrivire.

# 7) Transformarea datelor

Aceste teste formează testele de bază ale proiectului. Consultați documentul de cerințe pentru a înțelege cerințele de transformare. Pregătiți datele de testare în sistemele sursă pentru a reflecta diferite scenarii de transformare. Acestea au o multitudine de teste și ar trebui să fie acoperite în detaliu în temele de testare ETL.

Mai jos este o listă concisă a testelor acoperite în acest sens:

(i) Transformare:

• Exemplu: Codul ETL ar putea avea logică pentru a respinge datele nevalide. Verificați-le în funcție de cerințe.
• Codul ETL poate conține, de asemenea, logică pentru a genera automat anumite chei, cum ar fi cheile surogate. Trebuie să avem teste pentru a verifica corectitudinea (tehnică și logică) a acestora.
• Validați corectitudinea asocierii sau împărțirii valorilor câmpului după ce s-a terminat o sarcină ETL sau Migrare.
• Faceți teste pentru a verifica verificările referențiale ale integrității. De exemplu, un tip de defect ar putea fi ProductId utilizat în tabelul Comenzi nu este prezent în produsele din tabelul părinte. Faceți un test pentru a verifica modul în care se comportă înregistrările orfane în timpul unui job ETL.
• Uneori, datele lipsă sunt inserate folosind codul ETL. Verificați corectitudinea acestora.
• Scripturile ETL sau Migration au uneori logică pentru corectarea datelor. Verificați funcționarea corectării datelor.
• Verificați dacă datele invalide / respinse / eronate sunt raportate utilizatorilor.
• Creați o foaie de calcul cu scenarii de date de intrare și rezultate așteptate și validați-le împreună cu clientul comercial.

(ii) Cazuri marginale: Verificați dacă logica transformării este bună la granițe.

• Exemplu: Ce se întâmplă când TotalSales cu o valoare de 1 trilion este rulat printr-un job ETL? Funcționează cazurile de la capăt la cap? Identificați câmpurile care pot avea valori mari și executați teste cu aceste valori mari. Acestea ar trebui să includă valori numerice și nenumerice.
• Pentru câmpurile de date, inclusiv întreaga gamă de date preconizate - an bisect, 28/29 zile pentru februarie. 30, 31 de zile pentru alte luni.

# 8) Unicitatea sau duplicarea datelor

În acest tip de test, identificați coloanele care ar trebui să aibă valori unice conform modelului de date. De asemenea, luați în considerare logica de afaceri pentru a elimina astfel de date. Rulați teste pentru a verifica dacă acestea sunt unice în sistem. Urmează testele pentru a identifica duplicatele reale.

• Exemplu: Filtrați datele duplicate și verificați dacă sunt autentice. De exemplu, Înregistrarea dependentă de angajați conține aceleași date despre frați de două ori.
• Numărul de telefon al utilizatorului ar trebui să fie unic în sistem (cerința comercială).
• Cerința de afaceri spune că o combinație de ProductID și ProductName în tabelul Products ar trebui să fie unică, deoarece ProductName poate fi duplicat.

# 9) Obligatoriu

În acest tip de test, identificați toate câmpurile marcate ca obligatorii și validați dacă câmpurile obligatorii au valori. Dacă există valori implicite asociate cu un câmp din DB, verificați dacă acesta este completat corect atunci când nu există date.

• Exemplu: Dacă BillDate nu este introdus, atunci CurrentDate este BillDate.

# 10) Actualitatea

Documentați întotdeauna testele care verifică dacă lucrați cu date din termenele convenite.

• Exemplu: ProductDiscount a fost actualizat cu 15 zile în urmă, iar domeniile de activitate au modificat ProductDiscount la fiecare șapte zile. Aceasta înseamnă că testele dvs. nu se fac cu valorile de reducere potrivite.
• Un raport de analiză predictivă pentru indicele de satisfacție a clienților trebuia să funcționeze cu datele din ultima săptămână, care a fost o săptămână de promovare a vânzărilor la Walmart. Dar jobul ETL a fost conceput pentru a rula la o frecvență de 15 zile. Acesta este un defect major pe care testerii îl pot descoperi.

# 11) Date nule

În acest tip de test, ne concentrăm pe validitatea datelor nule și verificarea faptului că coloana importantă nu poate fi nulă.

• Exemplu: Filtrează toate datele nule și validează dacă este permisă nula.
• Dacă există coloane importante pentru deciziile de afaceri, asigurați-vă că valorile nule nu sunt prezente.

# 12) Verificarea autonomiei

Ar trebui testată entitatea de date în care intervalele au sens pentru afaceri.

• Exemplu: Cantitatea comenzii pe factură nu poate depăși 5K în categoria software.
• Vârsta nu trebuie să depășească 120 de ani.

# 13) Reguli de afaceri

Documentați orice cerințe comerciale pentru câmpuri și executați teste pentru acestea.

• Exemplu: Resursele cu vârsta mai mică de 20 de ani nu sunt eligibile. Verificările de validare a datelor sunt necesare dacă această regulă este aplicată datelor.
• Data încetării ar trebui să fie nulă dacă statutul activ al angajaților este adevărat / decedat.
• Datele FROM ar trebui să fie mai mici decât TO Date.
• Suma sumelor de achiziție la nivel de articol se ridică la sumele la nivel de comandă

# 14) Funcții agregate

Funcțiile agregate sunt integrate în funcționalitatea bazei de date. Documentați toate agregatele din sistemul sursă și verificați dacă utilizarea agregatului dă aceleași valori în sistemul țintă (sumă, maximă, minime, numărare).

Destul de des instrumentele din sistemul sursă sunt diferite de sistemul țintă. Verificați dacă ambele instrumente execută funcții agregate în același mod.

# 15) Trunchierea și rotunjirea datelor

În aceste tipuri de teste, identificăm câmpuri cu logică de tăiere și rotunjire a afacerii. Apoi, documentăm și obținem semnarea logicii de tăiere și rotunjire cu proprietarii de produse și le testăm cu date reprezentative de producție.

# 16) Teste de codificare

Validați dacă există valori codificate în sistemul sursă și verificați dacă datele sunt populate corect, postează ETL sau jobul de migrare a datelor în sistemul țintă.

• Exemplu: Caracterele cu octet dublu pentru FirstName în chineză au fost acceptate în sistemul sursă care a fost codificat. Verificați comportamentul acestui câmp atunci când este mutat în sistemul țintă.
• Câmpul Parolă a fost codificat și migrat. Asigurați-vă că funcționează bine după migrare.

# 17) Teste de regresie

Acesta este un concept de testare de bază în care testerii își execută întreaga suită de cazuri critice de testare generată folosind lista de verificare de mai sus, postează o modificare a sistemului sursă sau țintă.

Concluzie

Așadar, am văzut că validarea datelor este un domeniu interesant de explorat pentru proiecte cu intensitate de date și formează cele mai importante teste. Foaia de cartografiere a datelor este un artefact critic pe care testerii trebuie să îl mențină pentru a obține succesul cu aceste teste. Aceștia pot menține mai multe versiuni cu culori evidențiate pentru a forma intrări pentru oricare dintre testele de mai sus.

Ar trebui să aveți grijă să mențineți modificările delta între versiuni.

Solicităm cititorilor să împărtășească alte domenii ale testului pe care le-au întâlnit în timpul muncii lor în beneficiul comunității testerilor.

Lectură recomandată

• Ce este procesul ETL (Extract, Transform, Load) în Data Warehouse?
• Cele mai bune 15 instrumente ETL în 2021 (o listă completă actualizată)
• Cum se efectuează testarea ETL folosind instrumentul Informatica PowerCenter
• Cele mai bune 10 instrumente de cartografiere a datelor utile în procesul ETL (LISTA 2021)
• Top 10 instrumente de testare ETL în 2021
• Tutorial de testare a migrării datelor: un ghid complet
• Cele mai bune 13 instrumente de migrare a datelor pentru integritate completă a datelor (LISTA 2021)
• Tutorial de testare a depozitului de date ETL (ghid complet)