Datavalideringstester for ETL- og datamigrasjonsprosjekter

data validation tests

Denne veiledningen beskriver ETL- og datamigrasjonsprosjekter og dekker datavalideringskontroller eller tester for ETL / datamigrasjonsprosjekter for forbedret datakvalitet:

Denne artikkelen er for programvaretestere som jobber med ETL- eller datamigrasjonsprosjekter og er interessert i å fokusere testene sine bare på aspektene for datakvalitet. Disse typer prosjekter har et enormt volum av data som lagres på kildelagring og deretter blir operert av noen logikk som er tilstede i programvaren og blir flyttet til mållagringen.

Datavalideringstester sikrer at dataene som er tilstede i endelige målsystemer er gyldige, nøyaktige, i henhold til forretningskrav og gode for bruk i live produksjonssystem.

Antall datakvalitetsaspekter som kan testes er enormt, og denne listen nedenfor gir en introduksjon til dette emnet.

Hva du vil lære:

• Hva er datavalidering?
• Hvorfor validere data for ETL-prosjekter?
• Hvorfor validere data for datamigrasjonsprosjekter?
  • Datakartingsark
  • Datavalideringstester
    • # 1) Datainformitet
    • # 2) Enhetstilstedeværelse
    • # 3) Datanøyaktighet
    • # 4) Validering av metadata
    • # 5) Dataintegritet
    • # 6) Datafullstendighet
    • # 7) Datatransformasjon
    • # 8) Dataenhet eller duplisering
    • # 9) Obligatorisk
    • # 10) Rettighet
    • # 11) Nulldata
    • # 12) Rekkevidde
    • # 13) Forretningsregler
    • # 14) Samlede funksjoner
    • # 15) Datakutt og avrunding
    • # 16) Kodingstester
    • # 17) Regresjonstester
• Konklusjon
  • Anbefalt lesing

Hva er datavalidering?

Enkelt sagt er datavalidering å validere det faktum at dataene som blir flyttet som en del av ETL- eller datamigrasjonsjobber, er konsistente, nøyaktige og komplette i målproduksjonens live-systemer for å betjene forretningskravene.

Eksempel: Adressen til en student i Student-tabellen var 2000 tegn i kildesystemet. Datavalidering verifiserer om nøyaktig samme verdi ligger i målsystemet. Den sjekker om dataene ble avkortet, eller om visse spesialtegn fjernes.

I denne artikkelen vil vi diskutere mange av disse datavalideringskontrollene. Som testere for ETL- eller datamigreringsprosjekter, tilfører det enorm verdi hvis vi avdekker datakvalitetsproblemer som kan forplante seg til målsystemene og forstyrre hele forretningsprosessene.

Hvorfor validere data for ETL-prosjekter?

I ETL-prosjekter blir data hentet fra kilden, bearbeidet ved å bruke litt logikk i programvaren, transformert og deretter lastet inn i mållagringen. I mange tilfeller er transformasjonen gjort for å endre kildedataene til et mer brukbart format for forretningskravene.

Her kreves datavalidering for å bekrefte at dataene som er lastet inn i målsystemet er fullstendige, nøyaktige og at det ikke er tap av data eller avvik.

Eksempel: En e-handelsapplikasjon har ETL-jobber som plukker alle OrdersIds mot hver CustomerID fra Order-tabellen, som oppsummerer TotalDollarsSpend av kunden, og laster den inn i en ny CustomerValue-tabell, og markerer hver CustomerRating som kundebasert med høy / middels / lav verdi. på en eller annen kompleks algoritme.

Enkel datavalideringstest er å se at CustomerRating er korrekt beregnet.

En annen test er å verifisere at TotalDollarSpend er riktig beregnet uten mangler i avrunding av verdiene eller maksimal verdioverløp.

Hvorfor validere data for datamigrasjonsprosjekter?

I datamigrasjonsprosjekter blir de store datamengdene som er lagret i kildelagringen migrert til forskjellige mållagringer av flere grunner som infrastrukturoppgradering, foreldet teknologi, optimalisering osv. For eksempel, selskaper kan migrere sitt enorme datalager fra eldre systemer til nyere og mer robuste løsninger på AWS eller Azure.

Det primære motivet for slike prosjekter er å flytte data fra kildesystemet til et målsystem slik at dataene i målet er svært brukbare uten forstyrrelser eller negativ innvirkning på virksomheten.

Også her er datavalidering nødvendig for å bekrefte at dataene på kilden er de samme i målet etter bevegelsen.

Eksempel: Anta at for e-handelsapplikasjonen ble ordretabellen som hadde 200 millioner rader overført til målsystemet på Azure. Enkel datavalideringstest er å verifisere at alle 200 millioner rader med data er tilgjengelige i målsystemet.

En annen test kan være å bekrefte at datoformatene samsvarer mellom kilden og målsystemet.

Det er forskjellige aspekter som testere kan teste i slike prosjekter som funksjonelle tester, ytelsestester, sikkerhetstester, infra tester, E2E tester, regresjonstester, etc.

Anbefalt lesing => Testing av datamigrering , ETL Testing Data Warehouse Testing Tutorial

I denne artikkelen vil vi bare se på dataaspektet ved tester for ETL & Migration-prosjekter.

Datakartingsark

Til å begynne med lager du et datakartingsark for dataprosjektet ditt. Datakartlegging er prosessen med å matche enheter mellom kilde- og måltabellene. Begynn med å dokumentere alle tabellene og deres enheter i kildesystemet i et regneark. Dokumenter nå de tilsvarende verdiene for hver av disse radene som forventes å matche i måltabellene. Noter transformasjonsreglene i en egen kolonne, hvis noen.

Datakartark inneholder mye informasjon plukket fra datamodeller levert av Data Architects. I utgangspunktet kan testere lage en forenklet versjon og kan legge til mer informasjon når de fortsetter. Se eksemplet på datakartark nedenfor -

Last ned en mal fra Forenklet datakartark

Datavalideringstester

# 1) Datainformitet

Dataenhetstester utføres for å verifisere at den faktiske verdien til enheten har nøyaktig samsvar på forskjellige steder. Vi har to typer tester mulig her:

(i) Kontroller innenfor samme skjema:

• Dataenheten kan eksistere i to tabeller innen samme skjema (enten kildesystem eller målsystem)
• Eksempel: Som du kan se i bildet nedenfor, er ProductID til stede i tabellen OrderDetails and Products. Gjør en nøyaktig samsvarverifisering for ProductId til stede i tabellen OrderDetails vs Products.

(ii) Kontroller på tvers av skjemaer:

• Dataenheten kan migreres som den er i målskjemaet, dvs. den er tilstede i kildesystemet så vel som målsystemet
• Eksempel: Som du kan se i bildet over, er ProductID til stede i Products-tabellen i kildesystemet og Products-tabellen i målsystemet. Gjør en nøyaktig samsvarverifisering for ProductId i Products-tabellen i kildesystemet til ProductId i Products-tabellen i målsystemet.

Merk: Det er best å markere (fargekode) samsvarende dataenheter i datakartingsarket for rask referanse.

# 2) Enhetstilstedeværelse

I denne typen test må vi validere at alle enhetene (tabeller og felt) samsvarer mellom kilde og mål. Det er to muligheter, en enhet kan være til stede eller fraværende i henhold til datamodelldesignet.

(Jeg) Bekreft at alle tabellene (og kolonnene), som har en tilsvarende tilstedeværelse i både kilde og mål, stemmer overens. Vi trekker en liste over alle tabeller (og kolonner) og sammenligner tekst. Denne fornuftstesten fungerer bare hvis de samme enhetsnavnene brukes på tvers.

Noen ganger brukes forskjellige tabellnavn, og det kan derfor hende at en direkte sammenligning ikke fungerer. Vi må kanskje kartlegge denne informasjonen i datakartearket og validere den for feil.

En annen mulighet er fravær av data. Det er tilfeller der datamodellen krever at en tabell i kildesystemet (eller kolonnen) ikke har en tilsvarende tilstedeværelse i målsystemet (eller omvendt). Har tester for å validere dette.

• Eksempel: Som du kan se i bildet nedenfor, er CustDemographic Table tilstede i målsystemet og ikke i kildesystemet.
• CustomerType-feltet i kundetabellen har bare data i kildesystemet og ikke i målsystemet.

# 3) Datanøyaktighet

Som navnet antyder, validerer vi om dataene er logisk nøyaktige. Det er to kategorier for denne typen test. Med dette kan testeren fange problemene med datakvaliteten selv i kildesystemet.

(bilde kilde )

Merk: Kjør denne testen i målsystemet og kontroller om det er feil i kildesystemet.

(i) Ikke-numerisk type: Under denne klassifiseringen verifiserer vi nøyaktigheten av det ikke-numeriske innholdet. Eksempler er e-post, PIN-kode, telefon i gyldig format.

(ii) Domeneanalyse: I denne typen test velger vi domener med data og validerer for feil. Det er tre grupperinger for dette:

• Basert på verdi: Her lager vi en liste over verdier som kan oppstå for et felt (kolonne i tabellen). Valider deretter hvis kolonneverdiene er en delmengde av listen vår.
  • Eksempel: Kontroller om kjønnskolonnen inneholder enten M eller F.
• Basert på rekkevidde: Her setter vi minimums- og maksimumsområde for gyldige dataverdier for en kolonne, basert på logisk eller forretningsresonnement. Vi validerer deretter hvis kolonneverdiene faller innenfor dette området.
  • Eksempel: 0 til 120 for alder.
• Referansefil : Her bruker systemet en ekstern gyldighetsfil.
  • Eksempel: Er landskoder gyldige, velger de riktig verdi fra referansefilen, er landskoder like mellom QA og produksjonsmiljøet? Hvis referansefilen hadde oppdatert landskode, er den riktig oppdatert i DB?

# 4) Validering av metadata

I metadata-validering validerer vi at definisjonene for tabell- og kolonnedatatypen for målet er riktig designet, og når de er designet, blir de utført i henhold til datamodellens designspesifikasjoner.

Det er to grupperinger her: