Menu

Testy overenia údajov pre projekty ETL a migrácie údajov

  • Hlavná
  • Iné
  • Testy overenia údajov pre projekty ETL a migrácie údajov

data validation tests

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Tento výukový program popisuje projekty ETL a migrácie údajov a pokrýva kontroly alebo testy overenia údajov pre projekty ETL / migrácie údajov na zlepšenie kvality údajov:

Tento článok je určený pre softvérových testerov, ktorí pracujú na projektoch ETL alebo migrácie údajov a majú záujem zamerať svoje testy iba na aspekty kvality údajov. Tieto typy projektov majú obrovský objem dát, ktoré sú uložené na zdrojovom úložisku, a potom sú prevádzkované logikou prítomnou v softvéri a sú presunuté do cieľového úložiska.

Testy overovania údajov zaisťujú, že údaje prítomné v konečných cieľových systémoch sú platné, presné, podľa obchodných požiadaviek a vhodné na použitie v živom produkčnom systéme.

Validácia údajov pre projekty ETL a migráciu údajov

Počet aspektov kvality údajov, ktoré je možné testovať, je obrovský a tento zoznam uvedený nižšie predstavuje úvod do tejto témy.

Čo sa dozviete:

Čo je to overenie údajov?

Overovanie dát

Jednoducho povedané, Validácia údajov je akt potvrdzujúci skutočnosť, že údaje, ktoré sa presúvajú ako súčasť úloh ETL alebo migrácie údajov, sú v cieľových produkčných živých systémoch konzistentné, presné a úplné, aby slúžili obchodným požiadavkám.

Príklad: Adresa študenta v tabuľke Student bola v zdrojovom systéme 2 000 znakov. Overením údajov sa overí, či sa v cieľovom systéme nachádza úplne rovnaká hodnota. Kontroluje, či boli údaje skrátené alebo či nie sú odstránené niektoré špeciálne znaky.

V tomto článku sa budeme zaoberať mnohými z týchto kontrol overenia údajov. Ako testeri pre projekty ETL alebo migrácie údajov dodáva obrovskú hodnotu, ak odhalíme problémy s kvalitou údajov, ktoré by sa mohli rozšíriť do cieľových systémov a narušiť celé obchodné procesy.

Prečo overovať údaje pre projekty ETL?

V projektoch ETL sa údaje extrahujú zo zdroja, na čom sa pracuje aplikáciou určitej logiky v softvéri, transformujú sa a potom sa načítajú do cieľového úložiska. V mnohých prípadoch sa transformácia vykonáva s cieľom zmeniť zdrojové údaje do použiteľnejšieho formátu pre obchodné požiadavky.

rozdiel medzi Java a C ++

Tu sa vyžaduje overenie údajov, aby sa potvrdilo, že údaje načítané do cieľového systému sú úplné, presné a nedochádza k ich strate ani nezrovnalostiam.

cieľový a zdrojový systém

Príklad: Aplikácia elektronického obchodu má úlohy ETL, ktoré vyberajú všetky OrdersIds oproti každému ID zákazníka z tabuľky Objednávky, ktorá sumarizuje hodnotu TotalDollarsSpend podľa zákazníka, a načíta ju do novej tabuľky CustomerValue, pričom každú zákaznícku hodnotenie hodnotí ako zákazníkov s vysokou / strednou / nízkou hodnotou na nejakom zložitom algoritme.

Jednoduchým testom overenia údajov je zistiť, či je hodnotenie zákazníka správne vypočítané.

Ďalším testom je overenie, či je TotalDollarSpend správne vypočítaný bez akýchkoľvek chýb pri zaokrúhľovaní hodnôt alebo maximálnych prekročení hodnoty.

Prečo overovať údaje pre projekty migrácie údajov?

V projektoch migrácie dát sa obrovské objemy dát, ktoré sú uložené v zdrojovom úložisku, migrujú do iného cieľového úložiska z viacerých dôvodov, ako je aktualizácia infraštruktúry, zastaraná technológia, optimalizácia atď. Napríklad, spoločnosti môžu migrovať svoj obrovský dátový sklad zo starších systémov na novšie a robustnejšie riešenia v AWS alebo Azure.

Primárnym motívom takýchto projektov je presun údajov zo zdrojového systému do cieľového systému tak, aby boli údaje v cieľovom prostredí vysoko použiteľné bez akéhokoľvek narušenia alebo negatívneho dopadu na podnikanie.

Aj tu je potrebné overenie údajov, aby sa potvrdilo, že údaje o zdroji sú po premiestnení rovnaké v cieľovom objeme.

Príklad: Predpokladajme, že pre aplikáciu elektronického obchodu bola tabuľka Objednávky, ktorá mala 200 miliónov riadkov, migrovaná do cieľového systému v Azure. Jednoduchým testom overenia údajov je overenie, či je v cieľovom systéme k dispozícii všetkých 200 miliónov riadkov údajov.

Ďalším testom by mohlo byť potvrdenie, že formáty dátumu sa zhodujú medzi zdrojovým a cieľovým systémom.

Existuje niekoľko aspektov, ktoré môžu testeri testovať v projektoch, ako sú funkčné testy, testy výkonu, testy bezpečnosti, infra testy, testy E2E, regresné testy atď.

Odporúčané čítanie => Testovanie migrácie údajov , Výukový program pre testovanie dátových skladov ETL

V tomto článku sa pozrieme iba na dátový aspekt testov pre projekty ETL a migrácie.

List mapovania údajov

Najprv vytvorte hárok Data Mapping pre svoj dátový projekt. Mapovanie údajov je proces párovania entít medzi zdrojovou a cieľovou tabuľkou. Začnite dokumentovaním všetkých tabuliek a ich entít v zdrojovom systéme v tabuľke. Teraz zdokumentujte zodpovedajúce hodnoty pre každý z týchto riadkov, ktoré sa majú zhodovať v cieľových tabuľkách. Pravidlá transformácie si zapíšte do samostatného stĺpca, ak existujú.

Listy na mapovanie údajov obsahujú veľa informácií získaných z dátových modelov poskytnutých Data Architects. Skúšobníci mohli spočiatku vytvárať zjednodušenú verziu a počas postupu mohli pridávať ďalšie informácie. Pozrite si príklad tabuľky s mapovaním údajov nižšie - rodičovská tabuľka

Stiahnite si šablónu z Hárok so zjednodušeným mapovaním údajov

Testy overenia údajov

# 1) Jednotnosť údajov

Vykonávajú sa testy uniformity údajov, aby sa overilo, či sa skutočná hodnota entity presne zhoduje na rôznych miestach. Tu sú možné dva typy testov:

i) Kontroly v rámci tej istej schémy:

  • Dátová entita môže existovať v dvoch tabuľkách v rámci tej istej schémy (zdrojový alebo cieľový systém)
  • Príklad: Ako môžete vidieť na nasledujúcom obrázku, ID produktu je uvedené v tabuľke OrderDetails and Products. Vykonajte presné overenie zhody pre ProductId v tabuľke OrderDetails vs Products.

List so zjednodušeným mapovaním údajov

ii) Kontroly vo všetkých schémach:

  • Dátová entita sa môže migrovať ako taká do cieľovej schémy, t. J. Je prítomná v zdrojovom aj cieľovom systéme.
  • Príklad: Ako vidíte na vyššie uvedenom obrázku, ID produktu sa nachádza v tabuľke Products v zdrojovom systéme a v tabuľke Products v cieľovom systéme. Presné overenie zhody pre tabuľku ProductId v produkte v zdrojovom systéme s tabuľkou ProductId v produkte v cieľovom systéme.

Poznámka: Najlepšie je zvýrazniť (farebný kód) zodpovedajúce dátové entity v hárku Mapovanie údajov pre rýchlu orientáciu.

# 2) Prítomnosť entity

V tomto type testu musíme overiť, či sa všetky entity (tabuľky a polia) zhodujú medzi zdrojom a cieľom. Existujú dve možnosti, entita môže byť podľa návrhu dátového modelu prítomná alebo neprítomná.

i) Overte, či sa všetky tabuľky (a stĺpce), ktoré majú zodpovedajúcu prítomnosť v zdroji aj v cieľovej skupine, zhodujú. Vytiahneme zoznam všetkých tabuliek (a stĺpcov) a porovnáme text. Tento test zdravého rozumu funguje, iba ak sa vo všetkých názvoch entít používajú rovnaké názvy.

Niekedy sa používajú rôzne názvy tabuliek, a preto priame porovnanie nemusí fungovať. Možno budeme musieť tieto informácie namapovať v hárku Mapovanie údajov a overiť ich z hľadiska zlyhania.

Ďalšou možnosťou je absencia údajov. Existujú prípady, keď dátový model vyžaduje, aby tabuľka v zdrojovom systéme (alebo stĺpci) nemala zodpovedajúcu prítomnosť v cieľovom systéme (alebo naopak). Nechajte si testy potvrdiť.

  • Príklad: Ako môžete vidieť na nasledujúcom obrázku, CustDemographic Table je prítomný v cieľovom systéme a nie v zdrojovom systéme.
  • Pole CustomerType v tabuľke Zákazníci obsahuje údaje iba v zdrojovom systéme, nie v cieľovom systéme.

šípka (presnosť údajov)

# 3) Presnosť údajov

Ako naznačuje názov, overujeme, či sú údaje logicky presné. Pre tento typ testu existujú dve kategórie. Vďaka tomu môže tester zachytiť problémy s kvalitou údajov aj v zdrojovom systéme.

Integrita údajov

(obrázok zdroj )

Poznámka: Spustite tento test v cieľovom systéme a skontrolujte prípadné chyby v zdrojovom systéme.

i) Numerický typ: V rámci tejto klasifikácie overujeme presnosť nečíselného obsahu. Príklady sú e-maily, PIN kódy, telefón v platnom formáte.

ii) Analýza domény: V tomto type testu vyberáme domény údajov a overujeme chyby. Existujú tri zoskupenia:

  • Na základe hodnoty: Tu vytvoríme zoznam hodnôt, ktoré sa môžu pre pole vyskytnúť (stĺpec v tabuľke). Potom overte, či sú hodnoty stĺpcov podmnožinou nášho zoznamu.
    • Príklad: Skontrolujte, či stĺpec Pohlavie obsahuje buď M alebo F.
  • Na základe rozsahu: Tu nastavíme minimálny a maximálny rozsah pre platné hodnoty údajov pre stĺpec na základe logického alebo obchodného zdôvodnenia. Potom overíme, či hodnoty stĺpca spadajú do tohto rozsahu.
    • Príklad: 0 až 120 pre vek.
  • Referenčný súbor : Tu systém používa externý súbor platnosti.
    • Príklad: Sú kódy krajín platné, vyberajú správnu hodnotu z referenčného súboru, sú kódy krajín rovnaké medzi QA a produkčným prostredím? Ak bol v referenčnom súbore aktualizovaný kód krajiny, je aktualizovaný správne v databáze DB?

# 4) Overenie metadát

Pri overovaní metaúdajov overujeme, či sú definície dátových typov Tabuľka a Stĺpec pre cieľ správne navrhnuté a po navrhnutí sa vykonajú podľa špecifikácií návrhu dátového modelu.

Existujú dve zoskupenia:

i) Návrh metadát: Prvou kontrolou je overiť, či je dátový model správne navrhnutý podľa obchodných požiadaviek na cieľové tabuľky. Dátoví architekti môžu migrovať entity schémy alebo môžu vykonať úpravy, keď navrhujú cieľový systém.

Ďalšou kontrolou by malo byť overenie, či boli pomocou dátových modelov vytvorené správne skripty.

Pre každú kategóriu nižšie najskôr overíme, či metadáta definované pre cieľový systém vyhovujú obchodným požiadavkám, a za druhé, či boli tabuľky a definície polí vytvorené presne.

Niektoré z kontrol metadát sú uvedené nižšie:

  • Kontrola dátového typu: Príklad: Bude celkový predaj fungovať správne s desatinnou (8, 16 alebo 20 bajtov) alebo dvojitým typom?
  • Kontrola dĺžky údajov : Príklad: Bude dĺžka údajov pre pole Adresa dostatočná na 500 znakov? Môže to byť prípad, keď sa migrácia údajov vykonáva tak, ako sa do spoločnosti pridáva nová geografia. Adresy novej geografie môžu mať mimoriadne dlhý formát a pri dodržaní pôvodnej dĺžky môže dôjsť k chybe použitia.
  • Kontrola indexu: Príklad: Vykonáva sa indexovanie pre stĺpec OrderId v cieľovom systéme? Čo ak by došlo k zlúčeniu spoločností, ktoré si vyžaduje migráciu údajov a tabuľka objednávok sa v cieľovom systéme rozrastie stokrát.
  • Kontrola metadát v rôznych prostrediach: V rámci tejto kontroly overte, či sa metadáta zhodujú medzi testom QA a produkčným prostredím. Testy môžu prejsť v prostredí QA, ale v iných prostrediach môžu zlyhať.

ii) Zmena delty: Tieto testy odhaľujú chyby, ktoré vzniknú pri prebiehajúcom projekte a v polovici procesu dôjde k zmenám v metadátach zdrojového systému a nebudú implementované v cieľových systémoch.

Príklad: Nové pole CSI (index spokojnosti zákazníkov) bolo pridané do tabuľky zákazníkov v zdroji, ale nepodarilo sa ho vykonať v cieľovom systéme.

# 5) Integrita údajov

Tu overujeme hlavne obmedzenia integrity ako Cudzí kľúč, Odkaz na primárny kľúč, Jedinečný, Predvolený atď.

rodičovská tabuľka

(obrázok zdroj )

Pokiaľ ide o cudzie kľúče, musíme skontrolovať, či v podradenej tabuľke nie sú osirelé záznamy, v ktorých sa použitý cudzí kľúč nenachádza v nadradenej tabuľke.

Kontrola úplnosti údajov

Príklad: Tabuľka Zákazníci má CustomerID, čo je primárny kľúč. V tabuľke objednávok je ako cudzí kľúč identifikátor zákazníka. Tabuľka objednávok môže mať ID zákazníka, ktorý sa nenachádza v tabuľke Zákazníci. Musíme podstúpiť testy, aby sme odhalili takéto porušenia obmedzenia integrity. Tabuľka Data Mapping vám poskytne prehľad o tom, ktoré tabuľky majú tieto obmedzenia.

Poznámka: Spustite tento test v cieľovom systéme a v prípade chýb skontrolujte zdrojový systém.

# 6) Úplnosť údajov

Jedná sa o testy zdravého rozumu, ktoré odhalia chýbajúce počty záznamov alebo riadkov medzi zdrojovou a cieľovou tabuľkou a je možné ich často spustiť, keď sa automatizuje.

Existujú dva typy testov:

i) počet záznamov: Tu porovnávame celkový počet záznamov o zhodujúcich sa tabuľkách medzi zdrojovým a cieľovým systémom. Toto je rýchla kontrola zdravého rozumu na overenie spustenia úlohy ETL alebo migrácie po spustení. Máme poruchu, ak sa počty nezhodujú.

Počas vykonávania úlohy sú občas odmietnuté záznamy. Niektoré z nich môžu byť platné. Ale ako tester robíme za tým príklad.

ii) Profilovanie údajov stĺpcov: Tento typ testu príčetnosti je cenný, keď je rekordný počet. Tu vytvoríme logické súbory údajov, ktoré znižujú počet záznamov, a potom vykonáme porovnanie medzi zdrojom a cieľom.

otestovať moje stránky v rôznych prehliadačoch
  • Ak je to možné, vyfiltrujte všetky jedinečné hodnoty v stĺpci, napríklad, ProductID sa môže v tabuľke OrderDetails vyskytovať viackrát. Vyberte jedinečný zoznam pre ProductID z cieľovej aj zdrojovej tabuľky a vykonajte validáciu. To výrazne znižuje počet záznamov a urýchľuje testy zdravého rozumu.
  • Rovnako ako vyššie uvedené testy, môžeme tiež vybrať všetky hlavné stĺpce a skontrolovať, či sa kľúčové ukazovatele výkonu (minimálna, maximálna, priemerná, maximálna alebo minimálna dĺžka atď.) Zhodujú medzi cieľovou a zdrojovou tabuľkou. Príklad: Vezmite priemerné, minimálne a maximálne hodnoty zo stĺpca Cena v OrderDetails a porovnajte tieto hodnoty medzi cieľovými a zdrojovými tabuľkami pre nezhody.
  • Ďalšiu kontrolu možno vykonať pre hodnoty Null. Vyberte dôležité stĺpce a odfiltrujte zoznam riadkov, kde stĺpec obsahuje hodnoty Null. Porovnajte tieto riadky medzi cieľovým a zdrojovým systémom kvôli nesúladu.

Časové osi

# 7) Transformácia údajov

Tieto testy tvoria základné testy projektu. Skontrolujte dokument s požiadavkami, aby ste pochopili požiadavky na transformáciu. Pripravte testovacie údaje v zdrojových systémoch tak, aby odrážali rôzne transformačné scenáre. Tieto testy majú veľké množstvo testov a mali by byť podrobne popísané v témach testovania ETL.

Ďalej uvádzame stručný zoznam testov, na ktoré sa vzťahuje toto:

i) Transformácia:

  • Príklad: Kód ETL môže mať logiku odmietnutia neplatných údajov. Overte ich podľa požiadaviek.
  • Kód ETL môže obsahovať aj logiku na automatické generovanie určitých kľúčov, ako sú náhradné kľúče. Musíme mať testy na overenie ich správnosti (technickej a logickej).
  • Overte správnosť spojenia alebo rozdelenia hodnôt poľa po vykonaní úlohy ETL alebo migrácie.
  • Vykonajte testy na overenie kontrol referenčnej integrity. Napríklad, typom chyby môže byť ProductId použitý v tabuľke objednávok, ktorý sa nenachádza v nadradenej tabuľke Products. Vykonajte test na overenie toho, ako sa osirelé záznamy správajú počas úlohy ETL.
  • Chýbajúce údaje sa niekedy vkladajú pomocou kódu ETL. Overte ich správnosť.
  • Skripty ETL alebo Migration niekedy majú logiku na opravu údajov. Overte, či funguje oprava údajov.
  • Overte, či sú používateľom hlásené neplatné / zamietnuté / chybné údaje.
  • Vytvorte tabuľku scenárov vstupných údajov a očakávaných výsledkov a overte ich u obchodného zákazníka.

ii) Okrajové prípady: Overte, či logika transformácie dobre drží na hranici.

  • Príklad: Čo sa stane, keď sa prostredníctvom úlohy ETL spustí TotalSales s hodnotou 1 bilión? Fungujú prípady od začiatku do konca? Identifikujte polia, ktoré môžu mať potenciálne veľké hodnoty, a vykonajte testy s týmito veľkými hodnotami. Mali by obsahovať číselné a nečíselné hodnoty.
  • Pre polia s dátumom vrátane celého rozsahu očakávaných dátumov - priestupné roky, 28/29 dní pre február. 30, 31 dní pre ostatné mesiace.

# 8) Jedinečnosť údajov alebo duplikácia

V tomto type testu identifikujte stĺpce, ktoré by mali mať jedinečné hodnoty podľa dátového modelu. Zvážte tiež obchodnú logiku vyradenia takýchto údajov. Spustením testov overte, či sú v systéme jedinečné. Ďalej spustite testy na identifikáciu skutočných duplikátov.

  • Príklad: Filtrujte duplicitné údaje a overte, či sú autentické. Napríklad, Záznam závislý od zamestnanca obsahuje dvakrát rovnaké údaje o súrodencovi.
  • Telefónne číslo používateľa by malo byť v systéme jedinečné (obchodné požiadavky).
  • Obchodná požiadavka hovorí, že kombinácia ProductID a ProductName v tabuľke Products by mala byť jedinečná, pretože ProductName môže byť duplikát.

# 9) Povinné

V tomto type testu identifikujte všetky polia označené ako povinné a overte, či majú povinné polia hodnoty. Ak sú k poľu v databáze priradené predvolené hodnoty, overte, či je správne vyplnené, keď tam nie sú údaje.

  • Príklad: Ak BillDate nie je zadaný, potom CurrentDate je BillDate.

# 10) Včasnosť

Vždy zdokumentujte testy, ktoré overia, že pracujete s údajmi z dohodnutých časových harmonogramov.

  • Príklad: ProductDiscount bol aktualizovaný o 15 dní dozadu a stavy obchodnej domény ProductDiscount sa menia každých sedem dní. To znamená, že vaše testy sa nerobia so správnymi hodnotami zľavy.
  • Prediktívna analytická správa pre index spokojnosti zákazníkov mala pracovať s údajmi za posledný týždeň, čo bol týždeň podpory predaja v spoločnosti Walmart. Ale úloha ETL bola navrhnutá tak, aby bežala s frekvenciou 15 dní. Toto je hlavný nedostatok, ktorý môžu testéri odhaliť.

# 11) Nulové údaje

V tomto type testu sa zameriavame na platnosť nulových údajov a overenie, či dôležitý stĺpec nemôže byť nulový.

  • Príklad: Odfiltrujte všetky nulové údaje a overte, či je nulová hodnota povolená.
  • Ak existujú dôležité stĺpce pre obchodné rozhodnutia, uistite sa, že nie sú prítomné nuly.

# 12) Kontrola dosahu

Mala by sa testovať dátová entita, kde rozsahy majú obchodný zmysel.

  • Príklad: Objednávkové množstvo na jednu faktúru nemôže byť v kategórii softvéru väčšie ako 5 tis.
  • Vek by nemal byť vyšší ako 120 rokov.

# 13) Obchodné pravidlá

Zdokumentujte všetky obchodné požiadavky týkajúce sa polí a vykonajte rovnaké testy.

  • Príklad: Zdroje mladšie ako 20 rokov nie sú oprávnené. Ak sa toto pravidlo uplatňuje na údaje, vyžadujú sa kontroly platnosti údajov.
  • Dátum ukončenia by mal byť nulový, ak je stav Aktívny zamestnanec True / Deceased.
  • Údaje FROM by mali byť menšie ako TO Date.
  • Sumy nákupov na úrovni položky sa rovnajú sumám na úrovni objednávky

# 14) Súhrnné funkcie

Agregované funkcie sú zabudované do funkcionality databázy. Zdokumentujte všetky agregáty v zdrojovom systéme a overte, či použitie agregátov poskytuje rovnaké hodnoty v cieľovom systéme (súčet, max, min, počet).

Nástroje v zdrojovom systéme sa často líšia od cieľového systému. Skontrolujte, či obidva nástroje vykonávajú agregačné funkcie rovnakým spôsobom.

# 15) Skracovanie a zaokrúhľovanie údajov

V týchto typoch testov identifikujeme polia s logikou skrátenia a zaokrúhlenia týkajúce sa podniku. Potom zdokumentujeme a získame odhlásenie o logike skrátenia a zaokrúhlenia s vlastníkmi produktu a otestujeme ich s reprezentatívnymi údajmi výroby.

# 16) Testy kódovania

Overte, či sú v zdrojovom systéme zakódované hodnoty, a overte, či sú údaje správne vyplnené po zverejnení úlohy ETL alebo migrácie údajov do cieľového systému.

  • Príklad: V zdrojovom systéme, ktorý bol zakódovaný, boli prijaté dvojbajtové znaky pre meno First v čínštine. Overte správanie tohto poľa pri presune do cieľového systému.
  • Pole Heslo bolo zakódované a migrované. Zaistite, aby fungovali dobre po migrácii.

# 17) Regresné testy

Toto je základný koncept testovania, pri ktorom testeri spustia všetky svoje kritické sady testovacích prípadov vygenerované pomocou vyššie uvedeného kontrolného zoznamu po zmene zdrojového alebo cieľového systému.

Záver

Videli sme teda, že overovanie údajov je zaujímavou oblasťou, ktorú je potrebné preskúmať pri projektoch náročných na údaje, a tvorí najdôležitejšie testy. Hárok s mapovaním údajov je kritickým artefaktom, ktorý musia testéri udržiavať, aby dosiahli úspech v týchto testoch. Môžu udržiavať viac verzií s farebným zvýraznením, aby vytvorili vstupy pre ktorýkoľvek z vyššie uvedených testov.

Je potrebné dbať na zachovanie zmien delty vo všetkých verziách.

Žiadame čitateľov, aby zdieľali ďalšie oblasti testu, s ktorými sa počas svojej práce stretli v prospech komunity testerov.

Odporúčané čítanie

^