Menu

Testy ověření dat pro projekty ETL a migrace dat

  • Hlavní
  • Jiný
  • Testy ověření dat pro projekty ETL a migrace dat

data validation tests

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Tento výukový program popisuje projekty ETL a migrace dat a pokrývá kontroly nebo testy ověření dat pro projekty ETL / migrace dat pro vylepšenou kvalitu dat:

Tento článek je určen pro testery softwaru, kteří pracují na projektech ETL nebo migrace dat a mají zájem zaměřit své testy pouze na aspekty kvality dat. Tyto typy projektů mají obrovský objem dat, která jsou uložena na zdrojovém úložišti a poté jsou provozována nějakou logikou přítomnou v softwaru a jsou přesunuta do cílového úložiště.

Testy ověřování dat zajišťují, že data přítomná v konečných cílových systémech jsou platná, přesná podle obchodních požadavků a vhodná pro použití v živém produkčním systému.

Ověření dat pro projekty ETL a migrace dat

Počet aspektů kvality dat, které lze otestovat, je obrovský a tento seznam níže představuje úvod do tohoto tématu.

Co se naučíte:

Co je ověření dat?

Ověření dat

Jednoduše řečeno, ověření dat je akt ověřování skutečnosti, že data, která jsou přesunuta jako součást úloh ETL nebo migrace dat, jsou v cílových produkčních živých systémech konzistentní, přesná a úplná, aby sloužila obchodním požadavkům.

Příklad: Adresa studenta v tabulce Student byla ve zdrojovém systému 2 000 znaků. Ověření dat ověří, zda se v cílovém systému nachází přesně stejná hodnota. Kontroluje, zda byla data zkrácena nebo zda byly odstraněny určité speciální znaky.

V tomto článku probereme mnoho z těchto kontrol ověření dat. Jako testeři pro projekty ETL nebo migrace dat přidává obrovskou hodnotu, pokud odhalíme problémy s kvalitou dat, které by se mohly šířit do cílových systémů a narušit celé obchodní procesy.

Proč ověřovat data pro projekty ETL?

V projektech ETL jsou data extrahována ze zdroje, zpracována aplikací určité logiky v softwaru, transformována a poté načtena do cílového úložiště. V mnoha případech se transformace provádí za účelem změny zdrojových dat do použitelnějšího formátu pro obchodní požadavky.

Zde je vyžadováno ověření dat, aby se potvrdilo, že data načtená do cílového systému jsou úplná, přesná a nedochází ke ztrátě dat ani nesrovnalostem.

cílový a zdrojový systém

Příklad: Aplikace elektronického obchodování má úlohy ETL, které vybírají všechny OrdersIds proti každému ID zákazníka z tabulky Objednávky, která shrnuje TotalDollarsSpend od zákazníka, a načte ji do nové tabulky CustomerValue, přičemž každý Zákazník hodnotí jako Zákazníky s vysokou / střední / nízkou hodnotou na nějakém složitém algoritmu.

Jednoduchým testem ověření dat je zjistit, zda je CustomerRating správně vypočítán.

Dalším testem je ověření, že je TotalDollarSpend správně vypočítán bez vad zaokrouhlování hodnot nebo přetečení maximální hodnoty.

Proč ověřovat data pro projekty migrace dat?

V projektech migrace dat se obrovské objemy dat uložených ve zdrojovém úložišti migrují do různých cílových úložišť z několika důvodů, jako je upgrade infrastruktury, zastaralá technologie, optimalizace atd. Například, společnosti mohou migrovat své obrovské datové sklady ze starších systémů do novějších a robustnějších řešení na AWS nebo Azure.

Primárním motivem takových projektů je přesun dat ze zdrojového systému do cílového systému tak, aby data v cíli byla vysoce použitelná bez jakéhokoli narušení nebo negativního dopadu na podnikání.

Zde je opět vyžadováno ověření dat, aby se potvrdilo, že data na zdroji jsou po přesunu stejná v cíli.

Příklad: Předpokládejme, že pro aplikaci elektronického obchodování byla migrována tabulka objednávek, která měla 200 milionů řádků, do cílového systému v Azure. Jednoduchý test ověření dat spočívá v ověření, že v cílovém systému je k dispozici všech 200 milionů řádků dat.

Dalším testem může být potvrzení shody formátů data mezi zdrojovým a cílovým systémem.

Testery mohou v takových projektech testovat různé aspekty, jako jsou funkční testy, výkonnostní testy, bezpečnostní testy, infra testy, testy E2E, regresní testy atd.

Doporučené čtení => Testování migrace dat , Výukový program pro testování datového skladu ETL

V tomto článku se podíváme pouze na datový aspekt testů pro projekty ETL a migrace.

List mapování dat

Nejprve vytvořte list Data Mapping pro svůj datový projekt. Mapování dat je proces porovnávání entit mezi zdrojovou a cílovou tabulkou. Začněte dokumentováním všech tabulek a jejich entit ve zdrojovém systému v tabulce. Nyní zdokumentujte odpovídající hodnoty pro každý z těchto řádků, u nichž se očekává, že se shodují v cílových tabulkách. Poznamenejte si pravidla transformace do samostatného sloupce, pokud existují.

Listy mapování dat obsahují spoustu informací vybraných z datových modelů poskytnutých Data Architects. Zpočátku mohli testeři vytvořit zjednodušenou verzi a během postupu mohli přidávat další informace. Níže naleznete příklad listu mapování dat - nadřazená tabulka

Stáhněte si šablonu z Zjednodušený list pro mapování dat

Zkoušky ověření dat

# 1) Jednotnost dat

Testy uniformity dat se provádějí za účelem ověření, že skutečná hodnota entity má přesnou shodu na různých místech. Zde máme možné dva typy testů:

i) Kontroly ve stejném schématu:

  • Datová entita může existovat ve dvou tabulkách ve stejném schématu (zdrojový nebo cílový systém)
  • Příklad: Jak můžete vidět na následujícím obrázku, ProductID je přítomen v tabulce OrderDetails and Products. Proveďte přesné ověření shody pro ProductId v tabulce OrderDetails vs Products.

List se zjednodušeným mapováním dat 1

ii) Kontroly napříč schématy:

  • Datová entita může být migrována tak, jak je, do cílového schématu, tj. Je přítomna ve zdrojovém systému i v cílovém systému
  • Příklad: Jak vidíte na výše uvedeném obrázku, ProductID je přítomen v tabulce Products ve zdrojovém systému a tabulce Products v cílovém systému. Proveďte přesné ověření shody pro ProductId v tabulce Products ve zdrojovém systému s ProductId v tabulce Products v cílovém systému.

Poznámka: Nejlepší je zvýraznit (barevný kód) odpovídající datové entity v listu Mapování dat pro rychlou referenci.

# 2) Přítomnost entity

V tomto typu testu musíme ověřit, že všechny entity (tabulky a pole) jsou porovnány mezi zdrojem a cílem. Existují dvě možnosti, entita může být přítomna nebo chybí podle návrhu datového modelu.

(i) Ověřte, že všechny tabulky (a sloupce), které mají odpovídající přítomnost ve zdroji i cíli, se shodují. Vytáhneme seznam všech tabulek (a sloupců) a porovnáme text. Tento test zdravého rozumu funguje, pouze pokud se používají stejné názvy entit.

Někdy se používají různé názvy tabulek, a proto nemusí přímé srovnání fungovat. Možná budeme muset tyto informace namapovat v listu Mapování dat a ověřit je pro selhání.

Další možností je absence údajů. Existují případy, kdy datový model vyžaduje, aby tabulka ve zdrojovém systému (nebo sloupci) neměla odpovídající přítomnost v cílovém systému (nebo naopak). Nechte testy ověřit.

  • Příklad: Jak můžete vidět na následujícím obrázku, tabulka CustDemographic je přítomna v cílovém systému, nikoli ve zdrojovém systému.
  • Pole CustomerType v tabulce Zákazníci obsahuje data pouze ve zdrojovém systému, nikoli v cílovém systému.

dart (přesnost dat)

# 3) Přesnost dat

Jak název napovídá, ověřujeme, zda jsou data logicky přesná. Pro tento typ testu existují dvě kategorie. Díky tomu může tester zachytit problémy s kvalitou dat i ve zdrojovém systému.

Integrita dat

(obraz zdroj )

Poznámka: Spusťte tento test v cílovém systému a zkontrolujte zdrojový systém, zda neobsahuje nějaké vady.

i) Numerický typ: Podle této klasifikace ověřujeme přesnost nečíselného obsahu. Příklady jsou e-maily, PIN kódy, telefon v platném formátu.

ii) Analýza domény: V tomto typu testu vybereme domény dat a ověříme chyby. Existují tři seskupení:

  • Na základě hodnoty: Zde vytvoříme seznam hodnot, které se mohou u pole vyskytnout (sloupec v tabulce). Poté ověřte, zda jsou hodnoty sloupců podmnožinou našeho seznamu.
    • Příklad: Ověřte, zda sloupec Pohlaví obsahuje M nebo F.
  • Na základě rozsahu: Zde nastavíme minimální a maximální rozsah platných datových hodnot pro sloupec na základě logického nebo obchodního uvažování. Poté ověříme, zda hodnoty sloupců spadají do tohoto rozsahu.
    • Příklad: 0 až 120 pro věk.
  • Referenční soubor : Zde systém používá externí soubor platnosti.
    • Příklad: Jsou kódy zemí platné, vybírají správnou hodnotu z referenčního souboru, jsou kódy zemí stejné mezi QA a produkčním prostředím? Pokud byl v referenčním souboru aktualizován kód země, je v databázi správně aktualizován?

# 4) Ověření metadat

Při ověřování metadat ověřujeme, že definice datových typů Table a Column pro cíl jsou správně navrženy a po navržení jsou provedeny podle specifikací návrhu datového modelu.

Zde jsou dvě seskupení:

i) Návrh metadat: První kontrolou je ověřit, zda je datový model správně navržen podle obchodních požadavků na cílové tabulky. Datoví architekti mohou při návrhu cílového systému migrovat entity schématu nebo provádět úpravy.

Další kontrolou by mělo být ověření, že byly pomocí datových modelů vytvořeny správné skripty.

U každé níže uvedené kategorie nejprve ověříme, zda metadata definovaná pro cílový systém splňují obchodní požadavky, a zadruhé, pokud byly tabulky a definice polí vytvořeny přesně.

Níže uvádíme několik kontrol metadat:

  • Kontrola datového typu: Příklad: Bude celkový prodej fungovat správně s desetinným (8, 16 nebo 20 bajty) nebo dvojitým typem?
  • Kontrola délky dat : Příklad: Bude délka dat pro pole Adresa dostatečná pro 500 znaků? Může se jednat o případ, kdy se migrace dat provádí, když se do společnosti přidává nová geografie. Adresy nové geografie mohou mít mimořádně dlouhý formát a při dodržení původní délky může dojít k chybě případu použití.
  • Kontrola rejstříku: Příklad: Provádí se v cílovém systému pro sloupec OrderId indexování? Co když došlo ke sloučení společností, které vyžaduje migraci dat a tabulka objednávek se v cílovém systému zvětší stokrát?
  • Kontrola metadat napříč prostředími: V rámci této kontroly ověřte, zda se metadata shodují mezi testem QA a produkčním prostředím. Testy mohou projít prostředím QA, ale selhat v jiných prostředích.

ii) Změna Delta: Tyto testy odhalí vady, které vzniknou, když projekt probíhá a v polovině cesty dochází ke změnám v metadatech zdrojového systému a nebyl implementován v cílových systémech.

Příklad: Nové pole CSI (index zákaznické spokojenosti) bylo přidáno do tabulky zákazníků ve zdroji, ale nepodařilo se jej provést v cílovém systému.

# 5) Integrita dat

Zde ověřujeme hlavně omezení integrity, jako je cizí klíč, odkaz na primární klíč, jedinečný, výchozí atd.

nadřazená tabulka

(obraz zdroj )

U cizích klíčů musíme zkontrolovat, zda v podřízené tabulce nejsou osiřelé záznamy, kde použitý cizí klíč není v nadřazené tabulce.

Kontrola úplnosti údajů

Příklad: Tabulka Zákazníci má CustomerID, což je primární klíč. Tabulka objednávek má CustomerID jako cizí klíč. Tabulka objednávek může mít ID zákazníka, které není v tabulce Zákazníci. Musíme podstoupit testy, abychom odhalili taková porušení omezení integrity. Tabulka Data Mapping vám dá jasnost o tom, jaké tabulky mají tato omezení.

Poznámka: Spusťte tento test v cílovém systému a v případě závad proveďte kontrolu ve zdrojovém systému.

# 6) Úplnost údajů

Jedná se o testy zdravého rozumu, které odhalují chybějící počty záznamů nebo řádků mezi zdrojovou a cílovou tabulkou a lze je často spustit automaticky.

jak otevřít jar soubory s Java Windows 10

Existují dva typy testů:

(i) Počet záznamů: Zde porovnáváme celkový počet záznamů pro odpovídající tabulky mezi zdrojovým a cílovým systémem. Toto je rychlá kontrola zdravého rozumu k ověření následného spuštění úlohy ETL nebo migrace. Máme vadu, pokud se počty neshodují.

V průběhu úlohy jsou občas zamítnuté záznamy. Některé z nich mohou být platné. Ale jako tester si k tomu dáváme záležet.

ii) Profilování údajů sloupců: Tento typ testu příčetnosti je cenný, když je počet záznamů obrovský. Zde vytváříme logické sady dat, která snižují počet záznamů, a poté provedeme srovnání mezi zdrojem a cílem.

  • Je-li to možné, vyfiltrujte všechny jedinečné hodnoty ve sloupci, například, ProductID se může v tabulce OrderDetails vyskytovat několikrát. Vyberte jedinečný seznam pro ProductID z cílové i zdrojové tabulky a ověřte. To výrazně snižuje počet záznamů a zrychluje testy zdravého rozumu.
  • Stejně jako výše uvedené testy můžeme také vybrat všechny hlavní sloupce a zkontrolovat, zda se KPI (minimální, maximální, průměrná, maximální nebo minimální délka atd.) Shodují mezi cílovou a zdrojovou tabulkou. Příklad: Vezměte průměrné, minimální a maximální hodnoty ze sloupce Cena v OrderDetails a porovnejte tyto hodnoty mezi cílovou a zdrojovou tabulkou pro neshody.
  • Lze provést další kontrolu hodnot Null. Vyberte důležité sloupce a odfiltrujte seznam řádků, kde sloupec obsahuje hodnoty Null. Porovnejte tyto řádky mezi cílovým a zdrojovým systémem kvůli nesouladu.

Časové osy

# 7) Transformace dat

Tyto testy tvoří základní testy projektu. Projděte si dokument s požadavky, abyste pochopili požadavky na transformaci. Připravte testovací data ve zdrojových systémech tak, aby odrážely různé scénáře transformace. Ty mají velké množství testů a měly by být podrobně popsány v tématech testování ETL.

Níže je uveden stručný seznam testů, na které se vztahuje toto:

i) Transformace:

  • Příklad: Kód ETL může mít logiku pro odmítnutí neplatných dat. Ověřte je podle požadavků.
  • Kód ETL může také obsahovat logiku pro automatické generování určitých klíčů, jako jsou náhradní klíče. Musíme mít testy, abychom ověřili jejich správnost (technickou a logickou).
  • Ověřte správnost spojení nebo rozdělení hodnot pole po provedení ETL nebo dokončení migrace.
  • Nechte testy ověřit kontroly referenční integrity. Například, typ vady může být ProductId použitý v tabulce Objednávky, není přítomen v nadřazené tabulce Produkty. Nechte test ověřit, jak se osamocené záznamy chovají během úlohy ETL.
  • Někdy se chybějící data vloží pomocí kódu ETL. Ověřte jejich správnost.
  • Skripty ETL nebo Migration někdy mají logiku pro opravu dat. Ověření opravy dat funguje.
  • Ověřte, zda jsou uživatelům nahlášena neplatná / odmítnutá / chybná data.
  • Vytvořte tabulku scénářů vstupních údajů a očekávaných výsledků a ověřte je u obchodního zákazníka.

ii) Případy Edge: Ověřte, že transformační logika dobře drží na hranici.

  • Příklad: Co se stane, když je prostřednictvím úlohy ETL spuštěn TotalSales s hodnotou 1 bilion? Fungují případy od začátku do konce? Identifikujte pole, která mohou mít potenciálně velké hodnoty, a spusťte testy s těmito velkými hodnotami. Měly by zahrnovat číselné a nečíselné hodnoty.
  • Pro pole s datem, včetně celého očekávaného rozsahu dat - přestupné roky, 28/29 dní pro únor. 30, 31 dní pro ostatní měsíce.

# 8) Jedinečnost dat nebo duplikace

V tomto typu testu identifikujte sloupce, které by měly mít jedinečné hodnoty podle datového modelu. Vezměte v úvahu také obchodní logiku vyřazení těchto dat. Spuštěním testů ověřte, zda jsou v systému jedinečné. Dále spusťte testy k identifikaci skutečných duplikátů.

  • Příklad: Filtrujte duplicitní data a ověřte, zda jsou autentická. Například, Záznam závislý na zaměstnanci obsahuje dvakrát stejná data sourozence.
  • Telefonní číslo uživatele by mělo být v systému jedinečné (obchodní požadavek).
  • Obchodní požadavek říká, že kombinace ProductID a ProductName v tabulce Products by měla být jedinečná, protože ProductName lze duplikovat.

# 9) Povinné

V tomto typu testu identifikujte všechna pole označená jako povinná a ověřte, zda povinná pole mají hodnoty. Pokud existují výchozí hodnoty spojené s polem v DB, ověřte, zda je správně vyplněno, když tam data nejsou.

  • Příklad: Pokud není zadán BillDate, pak CurrentDate je BillDate.

# 10) Včasnost

Vždy dokumentujte testy, které ověří, že pracujete s daty z dohodnutých časových os.

  • Příklad: ProductDiscount byl aktualizován o 15 dní zpět a stavy obchodní domény ProductDiscount se mění každých sedm dní. To znamená, že se vaše testy neprovádějí se správnými hodnotami slevy.
  • Prediktivní analytická zpráva pro index spokojenosti zákazníků měla pracovat s údaji za poslední 1 týden, což byl týden podpory prodeje ve společnosti Walmart. Úloha ETL však byla navržena tak, aby běžela s frekvencí 15 dní. Toto je hlavní vada, kterou mohou testeři odhalit.

# 11) Nulová data

V tomto typu testu se zaměříme na platnost nulových dat a ověření, že důležitý sloupec nemůže mít hodnotu null.

  • Příklad: Odfiltrujte všechna nulová data a ověřte, zda je null povolena.
  • Pokud existují důležité sloupce pro obchodní rozhodnutí, ujistěte se, že nejsou přítomny nuly.

# 12) Kontrola dosahu

Měla by být testována datová entita, kde rozsahy mají obchodní smysl.

  • Příklad: Množství objednávky na fakturu nesmí být v kategorii softwaru vyšší než 5 tis.
  • Věk by neměl být větší než 120.

# 13) Obchodní pravidla

Zdokumentujte všechny obchodní požadavky pro pole a spusťte testy stejných.

  • Příklad: Zdroje mladší 20 let nejsou způsobilé. Pokud se toto pravidlo použije na data, jsou vyžadovány kontroly ověření dat.
  • Datum ukončení by mělo být nulové, pokud je stav Aktivní zaměstnanec True / Deceased.
  • FROM data by měla být menší než TO Date.
  • Součet částek nákupu na úrovni položky se rovná částkám na úrovni objednávky

# 14) Souhrnné funkce

Agregační funkce jsou zabudovány do funkcí databáze. Zdokumentujte všechny agregáty ve zdrojovém systému a ověřte, zda použití agregace poskytuje stejné hodnoty v cílovém systému (součet, max, min, počet).

Poměrně často se nástroje ve zdrojovém systému liší od cílového systému. Zkontrolujte, zda oba nástroje provádějí agregační funkce stejným způsobem.

# 15) Zkrácení a zaokrouhlování dat

V těchto typech testů identifikujeme pole s logikou zkrácení a zaokrouhlení týkající se podnikání. Poté dokumentujeme a dostáváme signoff o logice zkrácení a zaokrouhlování s vlastníky produktů a testujeme je s reprezentativními údaji o produkci.

# 16) Testování kódování

Ověřte, zda jsou ve zdrojovém systému zakódované hodnoty, a ověřte, zda jsou data správně naplněna po odeslání úlohy ETL nebo migrace dat do cílového systému.

  • Příklad: Ve zdrojovém systému, který byl zakódován, byly přijaty dvoubajtové znaky pro FirstName v čínštině. Ověřte chování tohoto pole při přesunu do cílového systému.
  • Pole Heslo bylo zakódováno a migrováno. Zajistěte, aby fungovaly dobře po migraci.

# 17) Regresní testy

Toto je základní koncept testování, kde testeři spouštějí všechny své kritické sady testovacích případů vygenerované pomocí výše uvedeného kontrolního seznamu po změně zdrojového nebo cílového systému.

Závěr

Viděli jsme tedy, že ověřování dat je zajímavou oblastí, kterou je třeba prozkoumat u datově náročných projektů, a tvoří nejdůležitější testy. List mapování dat je kritickým artefaktem, který musí testeři udržovat, aby dosáhli úspěchu s těmito testy. Mohou udržovat více verzí s barevnými zvýrazněními, aby vytvořily vstupy pro některý z výše uvedených testů.

Je třeba věnovat pozornost zachování delta změn napříč verzemi.

Žádáme čtenáře, aby sdíleli další oblasti testu, se kterými se během své práce setkali ve prospěch komunity testerů.

Doporučené čtení

^