Menu

Datavalideringstest til ETL- og datamigrationsprojekter

  • Vigtigste
  • Andet
  • Datavalideringstest til ETL- og datamigrationsprojekter

data validation tests

Prøv Vores Instrument Til At Fjerne Problemer

Denne tutorial beskriver ETL- og datamigrationsprojekter og dækker datavalideringskontrol eller -tests for ETL / datamigrationsprojekter for forbedret datakvalitet:

Denne artikel er til softwaretestere, der arbejder med ETL- eller datamigrationsprojekter og er interesseret i at fokusere deres tests på netop datakvalitetsaspekterne. Disse typer projekter har en enorm mængde data, der lagres på kildelagring og derefter drives af en eller anden logik, der findes i softwaren, og flyttes til mållageret.

Datavalideringstest sikrer, at de data, der findes i de endelige målsystemer, er gyldige, nøjagtige i henhold til forretningskrav og gode til brug i det levende produktionssystem.

Datavalidering for ETL- og datamigrationsprojekter

Antallet af datakvalitetsaspekter, der kan testes, er enormt, og denne liste nedenfor giver en introduktion til dette emne.

Hvad du lærer:

Hvad er datavalidering?

Data validering

Enkelt sagt er datavalidering den handling, der validerer det faktum, at de data, der flyttes som en del af ETL- eller datamigrationsjob, er konsistente, nøjagtige og komplette i målproduktionens live-systemer for at tjene forretningskravene.

Eksempel: Adressen til en studerende i tabellen Studerende var 2000 tegn i kildesystemet. Datavalidering verificerer, om den nøjagtige samme værdi findes i målsystemet. Den kontrollerer, om dataene blev afkortet, eller om visse specialtegn fjernes.

I denne artikel vil vi diskutere mange af disse datavalideringskontrol. Som testere for ETL- eller datamigrationsprojekter tilføjer det en enorm værdi, hvis vi afdækker datakvalitetsproblemer, der kan blive spredt til målsystemerne og forstyrre hele forretningsprocesserne.

Hvorfor validere data til ETL-projekter?

I ETL-projekter ekstraheres data fra kilden, bearbejdes ved at anvende en vis logik i softwaren, transformeres og derefter indlæses i mållageret. I mange tilfælde sker transformationen for at ændre kildedataene til et mere brugbart format til forretningskravene.

Her kræves datavalidering for at bekræfte, at de data, der indlæses i målsystemet, er komplette, nøjagtige, og at der ikke er datatab eller uoverensstemmelser.

mål- og kildesystem

Eksempel: En e-handelsapplikation har ETL-job, der vælger alle OrdersIds mod hver CustomerID fra ordretabellen, som opsummerer TotalDollarsSpend af kunden og indlæser den i en ny CustomerValue-tabel, der markerer hver CustomerRating som kundebaseret med høj / medium / lav værdi. på en eller anden kompleks algoritme.

Enkel datavalideringstest er at se, at CustomerRating er beregnet korrekt.

En anden test er at verificere, at TotalDollarSpend med rette beregnes uden fejl i afrunding af værdierne eller maksimal værdioverløb.

Hvorfor validere data til datamigrationsprojekter?

I datamigrationsprojekter migreres de enorme datamængder, der er gemt i kildelageret, til forskellige mållagring af flere årsager som infrastrukturopgradering, forældet teknologi, optimering osv. For eksempel, virksomheder kan migrere deres enorme datalager fra ældre systemer til nyere og mere robuste løsninger på AWS eller Azure.

Det primære motiv for sådanne projekter er at flytte data fra kildesystemet til et målsystem, således at dataene i målet er meget anvendelige uden nogen forstyrrelse eller negativ indvirkning på virksomheden.

Også her kræves datavalidering for at bekræfte, at kildens data er de samme i mål efter bevægelsen.

Eksempel: Antag, at for e-handelsapplikationen blev ordretabellen, der havde 200 millioner rækker, migreret til målsystemet på Azure. Enkel datavalideringstest er at kontrollere, at alle 200 millioner rækker med data er tilgængelige i målsystemet.

En anden test kan være at bekræfte, at datoformaterne matcher mellem kilden og målsystemet.

Der er forskellige aspekter, som testere kan teste i sådanne projekter som funktionelle tests, performance tests, sikkerhedstests, infra tests, E2E tests, regressionstest osv.

Anbefalet læsning => Test af datamigration , ETL Testing Tutorial Data Warehouse Testing Tutorial

I denne artikel vil vi kun se på data-aspektet af test til ETL & Migration-projekter.

Datakortingsark

Til at begynde med skal du oprette et datakorteark til dit dataprojekt. Datakortlægning er processen med at matche enheder mellem kilde- og måltabellerne. Start med at dokumentere alle tabellerne og deres enheder i kildesystemet i et regneark. Dokumenter nu de tilsvarende værdier for hver af disse rækker, som forventes at matche i måltabellerne. Noter transformeringsreglerne i en separat kolonne, hvis nogen.

Datakort ark indeholder en masse information plukket fra datamodeller leveret af Data Architects. Oprindeligt kunne testere oprette en forenklet version og kan tilføje flere oplysninger, når de fortsætter. Se eksemplet på datakortark nedenfor- overordnet bord

Download en skabelon fra Forenklet datakortark

Datavalideringstest

# 1) Data ensartethed

Data ensartethedstest udføres for at kontrollere, at enhedens faktiske værdi har det nøjagtige match forskellige steder. Vi har to typer tests mulige her:

(i) Kontrol inden for samme skema:

  • Dataenheden findes muligvis i to tabeller inden for det samme skema (enten kildesystem eller målsystem)
  • Eksempel: Som du kan se i nedenstående billede er ProductID til stede i tabellen OrderDetails og Products. Foretag en nøjagtig matchningsbekræftelse for ProductId til stede i tabellen OrderDetails vs Products.

Forenklet datakortark 1

(ii) Kontrol på tværs af skemaer:

  • Dataenheden kan migreres som den er i målskemaet, dvs. den er til stede i kildesystemet såvel som målsystemet
  • Eksempel: Som du kan se i ovenstående billede, er ProductID til stede i tabellen Produkter i kildesystemet og Produkter-tabellen i målsystemet. Foretag en nøjagtig matchning af ProductId i Products-tabellen i kildesystemet til ProductId i Products-tabellen i målsystemet.

Bemærk: Det er bedst at fremhæve (farvekode) matchende dataenheder i datakortearket til hurtig reference.

# 2) Enhedstilstedeværelse

I denne type test skal vi validere, at alle enhederne (tabeller og felter) matches mellem kilde og mål. Der er to muligheder, en enhed kan være til stede eller fraværende i henhold til datamodeldesignet.

(jeg) Bekræft, at alle tabeller (og kolonner), som har en tilsvarende tilstedeværelse i både kilde og mål, stemmer overens. Vi trækker en liste over alle tabeller (og kolonner) og sammenligner en tekst. Denne fornuftstest fungerer kun, hvis de samme enhedsnavne bruges på tværs.

Nogle gange bruges forskellige tabelnavne, og en direkte sammenligning fungerer muligvis ikke. Vi bliver muligvis nødt til at kortlægge disse oplysninger i datakortearket og validere dem for fejl.

En anden mulighed er fraværet af data. Der er tilfælde, hvor datamodellen kræver, at en tabel i kildesystemet (eller kolonnen) ikke har en tilsvarende tilstedeværelse i målsystemet (eller omvendt). Har test for at validere dette.

  • Eksempel: Som du kan se i nedenstående billede, er CustDemographic Table til stede i målsystemet og ikke i kildesystemet.
  • CustomerType-feltet i tabellen Kunder har kun data i kildesystemet og ikke i målsystemet.

dart (datanøjagtighed)

# 3) Datanøjagtighed

Som navnet antyder, validerer vi, hvis dataene er logisk korrekte. Der er to kategorier for denne type test. Med dette kan testeren fange datakvalitetsproblemer selv i kildesystemet.

Dataintegritet

(billede kilde )

Bemærk: Kør denne test i målsystemet, og kontroller i kildesystemet for eventuelle fejl.

(i) Ikke-numerisk type: Under denne klassificering verificerer vi nøjagtigheden af ​​det ikke-numeriske indhold. Eksempler er e-mails, pinkoder, telefon i et gyldigt format.

(ii) Domæneanalyse: I denne type test vælger vi domæner med data og validerer for fejl. Der er tre grupperinger til dette:

  • Baseret på værdi: Her opretter vi en liste over værdier, der kan forekomme for et felt (kolonne i tabellen). Valider derefter, hvis kolonneværdierne er en delmængde af vores liste.
    • Eksempel: Kontroller, om kolonnen Køn indeholder enten M eller F.
  • Baseret på rækkevidde: Her indstiller vi minimum og maksimum for gyldige dataværdier for en kolonne, baseret på logisk eller forretningsmæssig ræsonnement. Vi validerer derefter, hvis kolonneværdierne falder inden for dette interval.
    • Eksempel: 0 til 120 for alder.
  • Referencefil : Her bruger systemet en ekstern gyldighedsfil.
    • Eksempel: Er landekoder gyldige, vælger de den rigtige værdi fra referencefilen, er landekoder de samme mellem QA og produktionsmiljøet? Hvis referencefilen havde en landekode opdateret, opdateres den med rette i DB?

# 4) Validering af metadata

I metadata-validering validerer vi, at tabel- og kolonnedatatypedefinitionerne for målet er korrekt designet, og når de først er designet, udføres de i henhold til datamodelens designspecifikationer.

Der er to grupperinger her:

hvad er sdlc-faser?

(i) Metadata design: Den første kontrol er at validere, at datamodellen er korrekt designet i henhold til forretningskravene til måltabellerne. Dataarkitekter kan migrere skemaenheder eller kan foretage ændringer, når de designer målsystemet.

Den næste kontrol skal være at validere, at de rigtige scripts blev oprettet ved hjælp af datamodellerne.

For hver kategori nedenfor kontrollerer vi først, om de metadata, der er defineret for målsystemet, opfylder forretningskravet og for det andet, om tabellerne og feltdefinitionerne blev oprettet nøjagtigt.

Et par af metadatakontrollerne er angivet nedenfor:

  • Datatypekontrol: Eksempel: Fungerer det samlede salg korrekt med decimal (8, 16 eller 20 byte) eller dobbelt type?
  • Datalængdekontrol : Eksempel: Vil datalængden for adressefeltet være tilstrækkelig med 500 tegn? Det kan være et tilfælde, hvor datamigrering udføres, når ny geografi føjes til virksomheden. Adresserne til den nye geografi kan have et meget langt format, og at holde sig til den oprindelige længde kan muligvis fejle en brugssag.
  • Indekskontrol: Eksempel: Er der foretaget indeksering for OrderId-kolonnen i målsystemet? Hvad hvis der skete en fusion af virksomheder, der krævede datamigrering, og ordretabellen vokser 100 gange i målsystemet?
  • Metadata tjekker på tværs af miljøer: Under denne kontrol skal du kontrollere, at metadata matcher mellem QA-testen og produktionsmiljøet. Test kan bestå i QA-miljøet, men mislykkes i andre miljøer.

(ii) Deltaændring: Disse tests afdækker mangler, der opstår, når projektet er i gang, og midtvejs er der ændringer i kildesystemets metadata og blev ikke implementeret i målsystemer.

Eksempel: Nyt felt CSI (kundetilfredshedsindeks) blev tilføjet til kundetabellen i kilden, men det blev ikke gjort til målsystemet.

# 5) Dataintegritet

Her validerer vi hovedsageligt integritetsbegrænsninger som fremmed nøgle, primær nøglehenvisning, unik, standard osv.

overordnet bord

(billede kilde )

For udenlandske nøgler skal vi kontrollere, om der er forældreløse poster i underordnet, hvor den anvendte fremmednøgle ikke er til stede i overordnet tabel.

Datafuldstændighedskontrol

Eksempel: Kundetabellen har CustomerID, som er en primær nøgle. Ordretabellen har CustomerID som en udenlandsk nøgle. Ordretabellen har muligvis et kunde-id, som ikke findes i tabellen Kunder. Vi skal have tests for at afdække sådanne krænkelser af integritetsbegrænsning. Tabellen Data Mapping giver dig klarhed over, hvilke tabeller der har disse begrænsninger.

Bemærk: Kør denne test i målsystemet, og kontroller igen i kildesystemet, hvis der er fejl.

# 6) Datafuldstændighed

Dette er fornuftstest, der afslører manglende post- eller rækkeoptællinger mellem kilde og måltabel og kan køres ofte, når de er automatiseret.

Der er to typer tests:

(i) Antal optagelser: Her sammenligner vi det samlede antal registreringer for matchende tabeller mellem kilde og målsystem. Dette er en hurtig hygiejnekontrol for at kontrollere posten, der kører for ETL- eller migrationsjobbet. Vi har en defekt, hvis optællingerne ikke stemmer overens.

Til tider er der afviste poster under jobkørslen. Nogle af disse kan være gyldige. Men som tester lægger vi vægt på dette.

(ii) Profilering af søjledata: Denne form for tilregnelighedstest er værdifuld, når optællinger er enorme. Her opretter vi logiske datasæt, der reducerer antallet af poster og derefter foretager en sammenligning mellem kilde og mål.

  • Når det er muligt, skal du filtrere alle unikke værdier i en kolonne, for eksempel, ProductID kan forekomme flere gange i OrderDetails-tabellen. Vælg en unik liste til ProductID fra både mål- og kildetabeller, og valider. Dette reducerer antallet af rekordtællinger stærkt og fremskynder sundhedstest.
  • Ligesom ovenstående tests kan vi også vælge alle de store kolonner og kontrollere, om KPI'er (minimum, maksimum, gennemsnit, maksimum eller minimum længde osv.) Matcher mellem mål og kildetabel. Eksempel: Tag gennemsnits-, minimums- og maksimumværdier fra kolonnen Pris i OrderDetails, og sammenlign disse værdier mellem mål- og kildetabeller for uoverensstemmelser.
  • En anden kontrol kan udføres for Null-værdier. Vælg vigtige kolonner, og filtrer en liste over rækker, hvor kolonnen indeholder Null-værdier. Sammenlign disse rækker mellem mål- og kildesystemerne for misforholdet.

Tidslinjer

# 7) Datatransformation

Disse tests udgør kernetestene i projektet. Gennemgå kravsdokumentet for at forstå transformationskravene. Forbered testdata i kildesystemerne, så de afspejler forskellige transformationsscenarier. Disse har en lang række tests og skal dækkes detaljeret under ETL-testemner.

Nedenfor er en kortfattet liste over test, der er omfattet af dette:

(i) Transformation:

  • Eksempel: ETL-kode kan have logik til at afvise ugyldige data. Kontroller disse mod kravene.
  • ETL-kode kan også indeholde logik til automatisk generering af bestemte nøgler som surrogatnøgler. Vi skal have test for at verificere rigtigheden (teknisk og logisk) af disse.
  • Validér rigtigheden af ​​sammenføjning eller opdeling af feltværdier, efter at et ETL- eller migrationsjob er udført.
  • Har test for at verificere henvisning til integritetskontrol. For eksempel, en type defekt kan være ProductId, der bruges i ordretabellen, findes ikke i overordnede tabelprodukter. Lav en test for at kontrollere, hvordan forældreløse poster opfører sig under et ETL-job.
  • Til tider indsættes manglende data ved hjælp af ETL-koden. Kontroller rigtigheden af ​​disse.
  • ETL- eller migrationsskripter har undertiden logik til at rette data. Bekræft datakorrektion fungerer.
  • Kontroller, om ugyldige / afviste / forkerte data rapporteres til brugerne.
  • Opret et regneark med scenarier med inputdata og forventede resultater, og valider disse med forretningskunden.

(ii) Kantsager: Kontroller, at transformationslogik holder godt ved grænserne.

  • Eksempel: Hvad sker der, når TotalSales med en værdi på 1 billioner køres gennem et ETL-job? Fungerer slut-til-slut-sager? Identificer felter, der potentielt kan have store værdier, og kør tests med disse store værdier. De skal indeholde numeriske og ikke-numeriske værdier.
  • For datofelter, inklusive hele forventet datointerval - skudår, 28/29 dage i februar. 30, 31 dage i andre måneder.

# 8) Data unikhed eller duplikering

I denne type test skal du identificere kolonner, der skal have unikke værdier i henhold til datamodellen. Tag også hensyn til forretningslogik for at udrydde sådanne data. Kør tests for at kontrollere, om de er unikke i systemet. Næste kør test for at identificere de faktiske duplikater.

  • Eksempel: Filtrer for duplikatdata, og kontroller, om de er autentiske. For eksempel, Medarbejderafhængig post indeholder de samme søskendata to gange.
  • Brugerens telefonnummer skal være entydigt i systemet (forretningskrav).
  • Forretningskravet siger, at en kombination af ProductID og ProductName i produkttabellen skal være unik, da ProductName kan duplikeres.

# 9) Obligatorisk

I denne type test skal du identificere alle felter markeret som obligatorisk og validere, hvis obligatoriske felter har værdier. Hvis der er standardværdier tilknyttet et felt i DB, skal du kontrollere, om det er udfyldt korrekt, når data ikke er der.

  • Eksempel: Hvis BillDate ikke er indtastet, er CurrentDate BillDate.

# 10) Aktualitet

Dokumenter altid test, der bekræfter, at du arbejder med data fra de aftalte tidslinjer.

  • Eksempel: ProductDiscount blev opdateret 15 dage tilbage, og forretningsdomæne angiver ProductDiscount-ændringer hver syvende dag. Dette betyder, at dine tests ikke udføres med de rigtige rabatværdier.
  • En forudsigende analyserapport for kundetilfredshedsindekset skulle fungere med de sidste 1-ugers data, som var en salgsfremmende uge hos Walmart. Men ETL-jobbet blev designet til at køre med en hyppighed på 15 dage. Dette er en stor fejl, som testere kan afdække.

# 11) Nul data

I denne type test fokuserer vi på gyldigheden af ​​nulldata og verifikation af, at den vigtige kolonne ikke kan være nul.

  • Eksempel: Filtrer alle nulldata ud og valider, hvis nul er tilladt.
  • Hvis der er vigtige kolonner til forretningsbeslutninger, skal du sørge for, at nuller ikke er til stede.

# 12) Range Check

Dataenhed, hvor områder giver forretningsmæssig mening, bør testes.

  • Eksempel: Ordremængde pr. Faktura kan ikke være mere end 5K i softwarekategorien.
  • Alder bør ikke være mere end 120.

# 13) Forretningsregler

Dokumenter eventuelle forretningskrav til felter og kør tests for det samme.

  • Eksempel: Ressourcer med en alder under 20 år er ikke støtteberettigede. Datavalideringskontrol er påkrævet, hvis denne regel anvendes på dataene.
  • Opsigelsesdatoen skal være nul, hvis status for medarbejderaktiv er sand / død.
  • FROM-data skal være mindre end TO Date.
  • Foretag købsbeløb på vareniveau til beløb på ordreniveau

# 14) Samlede funktioner

Samlede funktioner er indbygget i databasens funktionalitet. Dokumenter alle aggregater i kildesystemet, og kontroller, om samlet brug giver de samme værdier i målsystemet (sum, max, min, count).

Ofte er værktøjerne på kildesystemet forskellige fra målsystemet. Kontroller, om begge værktøjer udfører samlede funktioner på samme måde.

# 15) Datafkorting & afrunding

I disse typer af tests identificerer vi felter med trunkering og afrundingslogik vedrørende virksomheden. Derefter dokumenterer og får afmelding af trunkerings- og afrundingslogikken med produktejere og tester dem med produktionsrepræsentantdata.

# 16) Kodningstest

Valider, hvis der er kodede værdier i kildesystemet, og kontroller, om dataene er korrekt udfyldt, efter ETL- eller datamigrationsjobbet i målsystemet.

  • Eksempel: Dobbeltbyte-tegn til FirstName på kinesisk blev accepteret i kildesystemet, der var kodet. Kontroller opførslen i dette felt, når det flyttes til målsystemet.
  • Password-feltet blev kodet og migreret. Sørg for, at de fungerer fint efter migrering.

# 17) Regressionstest

Dette er et grundlæggende testkoncept, hvor testere kører al deres kritiske testcase-suite, der er genereret ved hjælp af ovenstående tjekliste, efter en ændring til kilde- eller målsystemet.

Konklusion

Så vi har set, at datavalidering er et interessant område at udforske til dataintensive projekter og udgør de vigtigste tests. Datakortarket er en kritisk artefakt, som testere skal vedligeholde for at opnå succes med disse tests. De kan vedligeholde flere versioner med farvehøjdepunkter for at danne input til nogen af ​​testene ovenfor.

Der skal udvises omhu for at opretholde deltaændringerne på tværs af versioner.

Vi beder læsere om at dele andre områder af testen, som de er stødt på under deres arbejde, til gavn for testersamfundet.

Anbefalet læsning

^