Meni

Preskusi preverjanja veljavnosti podatkov za projekte ETL in selitve podatkov

  • Glavni
  • Drugo
  • Preskusi preverjanja veljavnosti podatkov za projekte ETL in selitve podatkov

data validation tests

Preizkusite Naš Instrument Za Odpravo Težav

Ta vadnica opisuje projekte ETL in selitve podatkov ter zajema preverjanja ali teste preverjanja veljavnosti podatkov za projekte ETL / migracije podatkov za izboljšano kakovost podatkov:

faza življenjskega cikla razvoja programske opreme

Ta članek je namenjen preizkuševalcem programske opreme, ki delajo na projektih ETL ali Data Migration in se želijo preizkusiti osredotočiti samo na vidike kakovosti podatkov. Te vrste projektov imajo ogromno podatkov, ki se shranijo v izvornem pomnilniku, nato pa jih upravlja neka logika, ki je prisotna v programski opremi, in se premaknejo v ciljno shrambo.

Preskusi za preverjanje veljavnosti podatkov zagotavljajo, da so podatki, ki so prisotni v končnih ciljnih sistemih, veljavni, natančni v skladu s poslovnimi zahtevami in primerni za uporabo v živih sistemih proizvodnje.

Validacija podatkov za projekte ETL in migracije podatkov

Število vidikov kakovosti podatkov, ki jih je mogoče preizkusiti, je ogromno, spodnji seznam pa predstavlja uvod v to temo.

Kaj se boste naučili:

Kaj je preverjanje veljavnosti podatkov?

Preverjanje podatkov

Preprosto povedano, validacija podatkov je potrditev dejstva, da so podatki, ki se premikajo kot del ETL ali opravil za selitev podatkov, dosledni, natančni in popolni v ciljnih produkcijskih sistemih v živo, da ustrezajo poslovnim zahtevam.

Primer: Naslov študenta v tabeli Študent je bil v izvornem sistemu 2000 znakov. Preverjanje podatkov preveri, ali je popolnoma enaka vrednost v ciljnem sistemu. Preveri, ali so bili podatki okrnjeni ali so odstranjeni nekateri posebni znaki.

V tem članku bomo razpravljali o številnih preverjanjih za preverjanje veljavnosti podatkov. Kot preizkuševalci za ETL ali projekte za prenos podatkov dodaja izjemno vrednost, če odkrijemo težave s kakovostjo podatkov, ki bi se lahko razširile na ciljne sisteme in motile celotne poslovne procese.

Zakaj validirati podatke za projekte ETL?

V projektih ETL se podatki izvlečejo iz vira, obdelajo z uporabo določene logike v programski opremi, se transformirajo in nato naložijo v ciljni pomnilnik. V mnogih primerih se preoblikovanje izvede tako, da se izvorni podatki spremenijo v uporabnejšo obliko za poslovne potrebe.

Tu je potrebna potrditev podatkov, da se potrdi, da so podatki, ki so naloženi v ciljni sistem, popolni, natančni in da ni nobenih izgub ali neskladnosti.

ciljni in izvorni sistem

Primer: Aplikacija za e-trgovanje ima opravila ETL, ki izberejo vsa ID-ja naročil glede na vsak ID stranke iz tabele Naročila, ki povzema TotalDollarsSpending, ki ga opravi kupec, in ga naloži v novo tabelo CustomerValue, pri čemer vsako stranko z oceno oceni kot stranko z visoko / srednjo / nizko vrednostjo. na nekem kompleksnem algoritmu.

Preprost preizkus preverjanja veljavnosti podatkov je namenjen ugotavljanju pravilnosti izračuna ocene stranke.

Drugi test je preveriti, ali je TotalDollarSpend pravilno izračunan brez napak pri zaokroževanju vrednosti ali preseganju največjih vrednosti.

Zakaj validirati podatke za projekte selitve podatkov?

V projektih Data Migration se ogromne količine podatkov, ki so shranjene v izvornem pomnilniku, iz več razlogov, kot so nadgradnja infrastrukture, zastarela tehnologija, optimizacija itd. Na primer, podjetja bi lahko svoje ogromno podatkovno skladišče preselila iz starejših sistemov v novejše in robustnejše rešitve na AWS ali Azure.

Primarni motiv takšnih projektov je premakniti podatke iz izvornega sistema v ciljni sistem, tako da so podatki v cilju zelo uporabni brez motenj ali negativnega vpliva na poslovanje.

Tudi tu je potrebna potrditev podatkov, da se potrdi, da so podatki v viru enaki v cilju po premiku.

Primer: Denimo, da je bila za aplikacijo e-poslovanja tabela Naročila z 200 milijoni vrstic preseljena v sistem Target v Azure. Preprost test za preverjanje veljavnosti podatkov je preveriti, ali je v ciljnem sistemu na voljo vseh 200 milijonov vrstic podatkov.

Drug preizkus bi lahko bil potrditev, da se formati datumov ujemajo med izvornim in ciljnim sistemom.

Obstajajo različni vidiki, ki jih lahko preizkuševalci preizkusijo v takšnih projektih, kot so funkcionalni testi, testi učinkovitosti, varnostni testi, infra testi, testi E2E, regresijski testi itd.

Priporočeno branje => Testiranje selitve podatkov , Vadnica za testiranje skladišča podatkov ETL

V tem članku bomo obravnavali samo podatkovni vidik testov za projekte ETL in migracije.

List za preslikavo podatkov

Za začetek ustvarite list za preslikavo podatkov za svoj podatkovni projekt. Preslikava podatkov je postopek ujemanja entitet med izvorno in ciljno tabelo. Začnite z dokumentiranjem vseh tabel in njihovih entitet v izvornem sistemu v preglednico. Zdaj dokumentirajte ustrezne vrednosti za vsako od teh vrstic, za katere se pričakuje, da se bodo ujemale v ciljnih tabelah. Zapišite si pravila preoblikovanja v poseben stolpec, če obstaja.

Listi za preslikavo podatkov vsebujejo veliko informacij, izbranih iz podatkovnih modelov, ki jih nudijo Data Architects. Sprva so preizkuševalci lahko ustvarili poenostavljeno različico in lahko dodajajo več informacij, ko nadaljujejo. Oglejte si primer lista za preslikavo podatkov spodaj - nadrejena tabela

model življenjskega cikla v programskem inženirstvu

Prenesite predlogo iz Poenostavljen list za preslikavo podatkov

Preskusi preverjanja veljavnosti podatkov

# 1) Enotnost podatkov

Preskusi enotnosti podatkov se izvajajo, da se preveri, ali se dejanska vrednost entitete natančno ujema na različnih mestih. Tu imamo na voljo dve vrsti testov:

(i) Pregledi v isti shemi:

  • Podatkovna enota lahko obstaja v dveh tabelah znotraj iste sheme (bodisi izvorni sistem bodisi ciljni sistem)
  • Primer: Kot lahko vidite na spodnji sliki, je ProductID prisoten v tabeli OrderDetails in Products. Naredite natančno preverjanje ujemanja ProductId, ki je prisoten v tabeli OrderDetails vs Products.

Poenostavljen list za preslikavo podatkov1

(ii) Pregledi v shemah:

  • Podatkovna enota se lahko preseli takšna, kakršna je, v ciljno shemo, tj. Prisotna je v izvornem sistemu in ciljnem sistemu
  • Primer: Kot lahko vidite na zgornji sliki, je ProductID prisoten v tabeli Products v izvornem sistemu in tabeli Products v ciljnem sistemu. Naredite natančno preverjanje ujemanja za tabelo ProductId v izdelkih v izvornem sistemu in ProductId v tabeli Products v ciljnem sistemu.

Opomba: Najbolje je, da na listu za preslikavo podatkov označite (barvno kodo) ujemajoče se podatkovne enote za hitro sklicevanje.

# 2) Prisotnost entitete

Pri tej vrsti preizkusa moramo potrditi, da se vse entitete (tabele in polja) ujemajo med virom in ciljem. Obstajata dve možnosti, entiteta je lahko navzoča ali odsotna v skladu z zasnovo podatkovnega modela.

(jaz) Potrdite, da se ujemajo vse tabele (in stolpci), ki so ustrezno prisotne tako v viru kot v cilju. Izvlečemo seznam vseh tabel (in stolpcev) in naredimo primerjavo besedila. Ta preizkus zdrave razumnosti deluje samo, če se v istem imenu uporabljajo enaka imena entitet.

Včasih se uporabljajo različna imena tabel, zato neposredna primerjava morda ne bo delovala. Morda bomo morali te podatke preslikati v list za preslikavo podatkov in jih potrditi glede napak.

Druga možnost je odsotnost podatkov. Obstajajo primeri, ko podatkovni model zahteva, da tabela v izvornem sistemu (ali stolpcu) ni ustrezno prisotna v ciljnem sistemu (ali obratno). Pripravite teste za potrditev tega.

  • Primer: Kot lahko vidite na spodnji sliki, je tabela CustDemographic prisotna v ciljnem sistemu in ne v izvornem sistemu.
  • Polje CustomerType v tabeli Kupci vsebuje podatke samo v izvornem sistemu in ne v ciljnem sistemu.

puščica (natančnost podatkov)

# 3) Natančnost podatkov

Kot že ime pove, preverimo, ali so podatki logično točni. Za to vrsto preizkusa obstajata dve kategoriji. S tem lahko preizkuševalnik zazna težave s kakovostjo podatkov tudi v izvornem sistemu.

Celovitost podatkov

(slika vir )

Opomba: Zaženite ta test v ciljnem sistemu in preverite morebitne napake v izvornem sistemu.

(i) Numerenčni tip: V skladu s to klasifikacijo preverjamo točnost nenumerične vsebine. Primeri so E-pošta, PIN kode, Telefon v veljavni obliki.

(ii) Analiza domene: Pri tej vrsti preizkusa izberemo domene podatkov in preverimo napake. Za to obstajajo tri skupine:

  • Na podlagi vrednosti: Tu ustvarimo seznam vrednosti, ki se lahko pojavijo za polje (stolpec v tabeli). Nato preverite, ali so vrednosti stolpcev podmnožica našega seznama.
    • Primer: Preverite, ali stolpec Spol vsebuje M ali F.
  • Glede na domet: Tu nastavimo najnižji in največji obseg veljavnih podatkovnih vrednosti za stolpec na podlagi logičnega ali poslovnega sklepanja. Nato preverimo, ali so vrednosti stolpcev znotraj tega obsega.
    • Primer: 0 do 120 za starost.
  • Referenčna datoteka : Tu sistem uporablja zunanjo datoteko veljavnosti.
    • Primer: Ali veljajo kode držav, ali iz referenčne datoteke izberejo pravo vrednost, ali so kode držav enake med QA in produkcijskim okoljem? Če je bila v referenčni datoteki posodobljena koda države, ali je v DB pravilno posodobljena?

# 4) Validacija metapodatkov

Pri preverjanju metapodatkov potrdimo, da so definicije podatkovnega tipa tabele in stolpca za cilj pravilno oblikovane in se po izdelavi izvedejo v skladu s specifikacijami zasnove podatkovnega modela.

Tu sta dve skupini:

(i) Oblikovanje metapodatkov: Najprej preverimo, ali je podatkovni model pravilno zasnovan v skladu s poslovnimi zahtevami za ciljne tabele. Podatkovni arhitekti lahko preselijo entitete sheme ali pa lahko spremenijo načrtovanje ciljnega sistema.

Naslednje preverjanje mora biti preverjanje, ali so bili z uporabo podatkovnih modelov ustvarjeni pravi skripti.

Za vsako spodnjo kategorijo najprej preverimo, ali metapodatki, opredeljeni za ciljni sistem, ustrezajo poslovnim zahtevam in drugič, ali so bile tabele in definicije polj ustvarjene natančno.

Nekaj ​​preverjanj metapodatkov je navedenih spodaj:

  • Preverjanje podatkovne vrste: Primer: Ali bo skupna prodaja pravilno delovala z decimalnim (8, 16 ali 20 bajtov) ali dvojnim tipom?
  • Preverjanje dolžine podatkov : Primer: Ali bo dolžina podatkov za polje Naslov zadoščala s 500 znaki? Morda gre za prenos podatkov, ko se podjetju dodaja nova geografija. Naslovi nove geografije imajo lahko izredno dolgo obliko in če se držite prvotne dolžine, lahko pride do napake v primeru uporabe.
  • Preverjanje indeksa: Primer: Ali je v ciljnem sistemu opravljeno indeksiranje stolpca OrderId? Kaj pa, če bi se zgodila združitev podjetij, ki bi zahtevala migracijo podatkov in bi tabela Naročila v ciljnem sistemu postala 100-krat večja?
  • Preverjanje metapodatkov v različnih okoljih: Pri tem preverjanju preverite, ali se metapodatki ujemajo med preskusom kakovosti in produkcijskim okoljem. Preskusi se lahko opravijo v okolju za preverjanje kakovosti, v drugih pa ne.

(ii) Sprememba delte: Ti preskusi odkrijejo napake, ki nastanejo, ko je projekt v teku in na sredini pride do sprememb metapodatkov izvornega sistema in niso bili implementirani v ciljne sisteme.

Primer: Novo polje CSI (indeks zadovoljstva strank) je bilo dodano v tabelo strank v viru, vendar ni uspelo v ciljni sistem.

# 5) Celovitost podatkov

Tu v glavnem preverjamo omejitve integritete, kot so tuji ključ, referenca primarnega ključa, enolično, privzeto itd.

nadrejena tabela

(slika vir )

Za tuje ključe moramo preveriti, ali so v podrejeni tabeli osiroteli zapisi, pri katerih uporabljeni tuji ključ ni v nadrejeni tabeli.

Preverjanje popolnosti podatkov

Primer: Tabela kupcev ima ID stranke, ki je primarni ključ. Tabela naročil ima CustomerID kot tuji ključ. Tabela naročil ima lahko ID stranke, ki je ni v tabeli Kupci. Za odkrivanje takšnih kršitev integritete moramo opraviti teste. Tabela preslikav podatkov vam bo dala jasnost glede tabel, ki imajo te omejitve.

Opomba: Zaženite ta test v ciljnem sistemu in preverite v izvornem sistemu, če obstajajo napake.

# 6) Popolnost podatkov

To so preizkusi razumnosti, ki odkrijejo manjkajoče število zapisov ali vrstic med izvorno in ciljno tabelo in jih je mogoče samodejno izvajati po avtomatizaciji.

Obstajata dve vrsti testov:

(i) Število zapisov: Tu primerjamo skupno število zapisov za ujemajoče se tabele med izvornim in ciljnim sistemom. To je hiter pregled stanja, da se preveri, ali se opravilo ETL ali migracije opravi po objavi. Če se štetje ne ujema, imamo napako.

Med izvajanjem opravila so včasih zavrnjeni zapisi. Nekatere od teh so lahko veljavne. Toda kot preizkuševalec za to poudarimo.

(ii) Profiliranje podatkov stolpcev: Ta vrsta preizkusa zdravja je dragocena, če je število zapisov ogromno. Tu ustvarimo logične nabore podatkov, ki zmanjšajo število zapisov in nato primerjamo izvor in cilj.

  • Kjer je to mogoče, v stolpcu filtrirajte vse enolične vrednosti, na primer, ProductID se lahko v tabeli OrderDetails pojavlja večkrat. Izberite edinstven seznam za ProductID tako iz ciljne kot iz izvorne tabele in potrdite. To močno zmanjša število zapisov in pospeši preizkuse zdravja.
  • Tako kot zgornji testi lahko tudi mi izberemo vse glavne stolpce in preverimo, ali se KPI (najmanjša, največja, povprečna, največja ali najmanjša dolžina itd.) Ujemajo med ciljno in izvorno tabelo. Primer: V stolpcu Cena v OrderDetails vzemite povprečne, najmanjše in največje vrednosti in primerjajte te vrednosti med ciljnimi in izvornimi tabelami za neujemanja.
  • Za Null vrednosti je mogoče še enkrat preveriti. Izberite pomembne stolpce in filtrirajte seznam vrstic, kjer stolpec vsebuje vrednosti Null. Primerjajte te vrstice med ciljnim in izvornim sistemom za neusklajenost.

Časovni trakovi

# 7) Preoblikovanje podatkov

Ti testi tvorijo osrednje teste projekta. Preglejte dokument z zahtevami, da boste razumeli zahteve za preoblikovanje. Pripravite testne podatke v izvornih sistemih, da bodo odražali različne scenarije transformacije. Ti imajo številne teste in bi jih morali podrobno zajeti v temah testiranja ETL.

Spodaj je kratek seznam testov, zajetih v tem:

(i) Preoblikovanje:

  • Primer: Koda ETL ima lahko logiko za zavrnitev neveljavnih podatkov. Preverite jih glede na zahteve.
  • Koda ETL lahko vsebuje tudi logiko za samodejno generiranje nekaterih ključev, kot so nadomestni ključi. Za preverjanje pravilnosti (tehnične in logične) le-teh moramo opraviti teste.
  • Potrdite pravilnost združevanja ali delitve vrednosti polj po opravljenem opravilu ETL ali selitvi.
  • Pripravite teste za preverjanje referenčnih preverjanj integritete Na primer, vrsta napake bi lahko bila ProductId, uporabljena v tabeli Naročila, ni prisotna v nadrejeni tabeli Products. Pripravite test, da preverite, kako se obnašajo osiroteli zapisi med delom ETL.
  • Včasih se manjkajoči podatki vstavijo s kodo ETL. Preverite pravilnost le-teh.
  • Skripti ETL ali migracije imajo včasih logiko za popravljanje podatkov. Preverite, ali deluje popravek podatkov.
  • Preverite, ali so uporabnikom prijavljeni neveljavni / zavrnjeni / napačni podatki.
  • Ustvarite preglednico scenarijev vhodnih podatkov in pričakovanih rezultatov ter jih potrdite s poslovnim kupcem.

(ii) Primeri robov: Preverite, ali logika transformacije dobro drži meje.

  • Primer: Kaj se zgodi, ko se TotalSales z vrednostjo 1 bilijona zažene skozi opravilo ETL? Ali primeri od konca do konca delujejo? Ugotovite polja, ki imajo lahko velike vrednosti, in zaženite teste s temi velikimi vrednostmi. Vključevati morajo številske in neštevilske vrednosti.
  • Za datumska polja, vključno s celotnim obsegom pričakovanih datumov - prestopna leta, 28/29 dni za februar. 30, 31 dni za ostale mesece.

# 8) Edinstvenost ali podvajanje podatkov

V tej vrsti preizkusa določite stolpce, ki bi morali imeti enolične vrednosti glede na podatkovni model. Upoštevajte tudi poslovno logiko, da takšne podatke izločite. Zaženite teste, da preverite, ali so v sistemu edinstveni. Naslednji zaženite teste za prepoznavanje dejanskih dvojnikov.

  • Primer: Filtrirajte za podvojene podatke in preverite, ali so verodostojni. Na primer, Zapis o zaposlenem dvakrat vsebuje iste podatke o sorojencu.
  • Uporabniška telefonska številka mora biti v sistemu edinstvena (poslovna zahteva).
  • Poslovna zahteva pravi, da mora biti kombinacija ProductID in ProductName v tabeli Products edinstvena, saj je ProductName lahko dvojnik.

# 9) Obvezno

Pri tej vrsti preizkusa določite vsa polja, označena kot Obvezna, in preverite, ali imajo obvezna polja vrednosti. Če so s poljem v DB povezane privzete vrednosti, preverite, ali je pravilno zapolnjeno, če podatkov ni.

  • Primer: Če BillDate ni vnesen, je CurrentDate BillDate.

# 10) Pravočasnost

Vedno dokumentirajte teste, ki potrjujejo, da delate s podatki iz dogovorjenih rokov.

vprašanja in odgovori s testerja za zagotavljanje kakovosti

  • Primer: ProductDiscount je bil posodobljen petnajst dni nazaj in stanje poslovne domene ProductDiscount se spreminja vsakih sedem dni. To pomeni, da se testi ne izvajajo s pravimi vrednostmi popustov.
  • Poročilo o napovedni analitiki za indeks zadovoljstva kupcev naj bi delovalo z zadnjimi enotedenskimi podatki, ki so bili teden pospeševanja prodaje pri Walmartu. Toda delo ETL je bilo zasnovano tako, da se izvaja s frekvenco 15 dni. To je glavna napaka, ki jo preizkuševalci lahko odkrijejo.

# 11) Nični podatki

Pri tej vrsti preizkusa se osredotočamo na veljavnost ničnih podatkov in preverjanje, da pomemben stolpec ne more biti nič.

  • Primer: Filtrirajte vse nične podatke in preverite, če je null dovoljeno.
  • Če obstajajo pomembni stolpci za poslovne odločitve, se prepričajte, da ni nuj.

# 12) Preverjanje dosega

Podatkovno entiteto, pri kateri so obsegi poslovno smiselni, je treba preizkusiti.

  • Primer: Količina naročila na račun v kategoriji programske opreme ne sme presegati 5K.
  • Starost ne sme biti večja od 120 let.

# 13) Poslovna pravila

Dokumentirajte vse poslovne zahteve za polja in za njih zaženite teste.

  • Primer: Viri, mlajši od 20 let, niso upravičeni. Če se to pravilo uporablja za podatke, so potrebna preverjanja veljavnosti podatkov.
  • Datum prenehanja mora biti ničen, če je status Employee Active status True / pokojni.
  • Podatki FROM morajo biti manjši od TO Date.
  • Zneske za nakup na ravni artiklov seštejte na zneske na ravni naročila

# 14) Združene funkcije

Skupne funkcije so vgrajene v funkcionalnost baze podatkov. Dokumentirajte vse agregate v izvornem sistemu in preverite, ali daje agregatna uporaba enake vrednosti v ciljnem sistemu (sum, max, min, count).

Pogosto se orodja v izvornem sistemu razlikujejo od ciljnega sistema. Preverite, ali obe orodji izvajata agregatne funkcije na enak način.

# 15) Presekanje in zaokroževanje podatkov

Pri tovrstnih preizkusih identificiramo polja z logiko obrezovanja in zaokroževanja, ki zadevajo poslovanje. Nato z lastniki izdelkov dokumentiramo in dobimo podpis za logiko obrezovanja in zaokroževanja ter jih preizkusimo s predstavitvenimi podatki proizvodnje.

# 16) Preizkusi kodiranja

Preverite, ali so v izvornem sistemu kodirane vrednosti, in preverite, ali so podatki pravilno zasedeni, po opravku ETL ali opravilu za selitev podatkov v ciljni sistem.

  • Primer: Dvobajtni znaki za FirstName v kitajščini so bili sprejeti v izvornem sistemu, ki je bil kodiran. Preverite vedenje tega polja, ko je premaknjeno v ciljni sistem.
  • Polje Geslo je bilo kodirano in preseljeno. Poskrbite, da bodo po prehodu dobro delovale.

# 17) Regresijski testi

To je osnovni koncept testiranja, pri katerem preizkuševalci zaženejo vse svoje kritične pakete testnih primerov, ustvarjene z uporabo zgornjega kontrolnega seznama, ob spremembi v izvornem ali ciljnem sistemu.

Zaključek

Tako smo videli, da je preverjanje podatkov zanimivo področje za raziskovanje podatkovno intenzivnih projektov in tvori najpomembnejše teste. List za preslikavo podatkov je kritičen artefakt, ki ga morajo preizkuševalci vzdrževati, da bi s temi preskusi dosegli uspeh. Lahko vzdržujejo več različic z barvnimi poudarki, da tvorijo vhodne podatke za katerega koli od zgornjih testov.

Paziti je treba, da se med različicami ohranijo spremembe delte.

Bralce prosimo, da delijo druga področja testa, na katera so naleteli med svojim delom v korist skupnosti preizkuševalcev.

Priporočeno branje

^