Testovi provjere valjanosti podataka za ETL i projekte migracije podataka

data validation tests

Ovaj vodič opisuje ETL-ove i projekte migracije podataka i obuhvaća provjere ili testove provjere valjanosti podataka za ETL-ove / projekte migracije podataka za poboljšanu kvalitetu podataka:

Ovaj je članak namijenjen testerima softvera koji rade na ETL ili projektima Migracije podataka i zainteresirani su da svoja ispitivanja usredotoče samo na aspekte kvalitete podataka. Ove vrste projekata imaju ogromnu količinu podataka koji se pohranjuju u izvornu pohranu, a zatim se njima upravlja pomoću neke logike prisutne u softveru i premještaju se u ciljanu pohranu.

Testovi za provjeru valjanosti podataka osiguravaju da su podaci prisutni u konačnim ciljnim sustavima valjani, točni, u skladu s poslovnim zahtjevima i dobri za upotrebu u živom proizvodnom sustavu.

Broj aspekata kvalitete podataka koji se mogu testirati je ogroman i ovaj popis u nastavku daje uvod u ovu temu.

Što ćete naučiti:

• Što je provjera valjanosti podataka?
• Zašto provjeravati podatke za ETL projekte?
• Zašto provjeravati podatke za projekte migracije podataka?
  • List za mapiranje podataka
  • Testovi za provjeru valjanosti podataka
    • # 1) Ujednačenost podataka
    • # 2) Prisustvo entiteta
    • # 3) Točnost podataka
    • # 4) Provjera metapodataka
    • # 5) Integritet podataka
    • # 6) Kompletnost podataka
    • # 7) Transformacija podataka
    • # 8) Jedinstvenost podataka ili umnožavanje
    • # 9) Obavezno
    • # 10) Pravovremenost
    • # 11) Null podaci
    • # 12) Provjera dometa
    • # 13) Poslovna pravila
    • # 14) Zbirne funkcije
    • # 15) Skraćivanje i zaokruživanje podataka
    • # 16) Testovi kodiranja
    • # 17) Regresijski testovi
• Zaključak
  • Preporučena literatura

Što je provjera valjanosti podataka?

Jednostavno rečeno, provjera valjanosti podataka jest čin potvrde činjenice da su podaci koji se premještaju kao dio ETL-a ili poslova migracije podataka dosljedni, točni i cjeloviti u ciljanim produkcijskim aktivnim sustavima kako bi zadovoljili poslovne zahtjeve.

Primjer: Adresa studenta u tablici Student bila je 2000 znakova u izvornom sustavu. Provjera valjanosti podataka provjerava nalazi li se ista vrijednost u ciljnom sustavu. Provjerava jesu li podaci skraćeni ili su uklonjeni određeni posebni znakovi.

U ovom ćemo članku razgovarati o mnogim provjerama provjere valjanosti podataka. Kao testeri za ETL ili projekte migracije podataka, dodaje nam ogromnu vrijednost ako otkrijemo probleme s kvalitetom podataka koji bi se mogli proširiti na ciljne sustave i poremetiti cjelokupne poslovne procese.

Zašto provjeravati podatke za ETL projekte?

U ETL projektima podaci se izdvajaju iz izvora, obrađuje se primjenom neke logike u softveru, transformira i zatim učitava u ciljanu pohranu. U mnogim se slučajevima transformacija vrši radi promjene izvornih podataka u korisniji format za poslovne potrebe.

Ovdje je potrebna provjera valjanosti podataka kako bi se potvrdilo da su podaci koji se učitavaju u ciljni sustav potpuni, točni i da nema gubitka podataka ili odstupanja.

Primjer: Aplikacija za e-trgovinu ima ETL poslove koji biraju sve OrdersIds prema svakom ID-u kupca iz tablice Narudžbe koja sažima ukupni potrošeni iznos od kupca i učitava ga u novu tablicu CustomerValue, označavajući svakog kupca s ocjenom kao kupci visoke / srednje / male vrijednosti. na nekom složenom algoritmu.

Jednostavnim testom provjere valjanosti podataka utvrđuje se je li ocjena klijenta ispravno izračunata.

Drugi je test provjera da li je TotalDollarSpend ispravno izračunat bez nedostataka u zaokruživanju vrijednosti ili maksimalnih preljeva vrijednosti.

Zašto provjeravati podatke za projekte migracije podataka?

U projektima migracije podataka, ogromne količine podataka pohranjene u izvornoj pohrani migriraju se u različite ciljne pohrane iz više razloga kao što su nadogradnja infrastrukture, zastarjela tehnologija, optimizacija itd. Na primjer, tvrtke bi mogle premjestiti svoje veliko skladište podataka iz naslijeđenih sustava u nova i robusnija rješenja na AWS-u ili Azureu.

Primarni motiv za takve projekte je premještanje podataka iz izvornog sustava u ciljni sustav tako da su podaci u cilju vrlo korisni bez ikakvih smetnji ili negativnog utjecaja na poslovanje.

I ovdje je potrebna provjera valjanosti podataka kako bi se potvrdilo da su podaci na izvoru isti u cilju nakon kretanja.

Primjer: Pretpostavimo da je za aplikaciju e-trgovine tablica Narudžbe koja je imala 200 milijuna redaka migrirana u sustav Target na Azureu. Jednostavan test provjere valjanosti podataka je provjera svih 200 milijuna redaka podataka dostupnih u ciljnom sustavu.

gdje mogu besplatno gledati anime

Drugi test mogao bi biti potvrda da se formati datuma podudaraju između izvornog i ciljnog sustava.

Postoje različiti aspekti koje testeri mogu testirati u takvim projektima kao što su funkcionalni testovi, testovi performansi, sigurnosni testovi, infra testovi, E2E testovi, regresijski testovi itd.

Preporučena literatura => Ispitivanje migracije podataka , Vodič za ispitivanje skladišta podataka ETL-a

U ovom ćemo članku razmotriti samo podatkovni aspekt testova za ETL i migracijske projekte.

List za mapiranje podataka

Za početak izradite list mapiranja podataka za svoj projekt podataka. Mapiranje podataka postupak je podudaranja entiteta između izvorne i ciljne tablice. Započnite s dokumentiranjem svih tablica i njihovih entiteta u izvornom sustavu u proračunsku tablicu. Sada dokumentirajte odgovarajuće vrijednosti za svaki od ovih redaka za koje se očekuje da se podudaraju u ciljnim tablicama. Zabilježite pravila transformacije u zasebni stupac ako postoje.

Listovi za mapiranje podataka sadrže puno informacija odabranih iz podatkovnih modela koje pružaju Data Architects. U početku su testeri mogli stvoriti pojednostavljenu verziju i tijekom postupka mogu dodavati više informacija. Pogledajte primjer Liste za mapiranje podataka ispod -

Preuzmite predložak s Pojednostavljeni list za mapiranje podataka

Testovi za provjeru valjanosti podataka

# 1) Ujednačenost podataka

Ispitivanja uniformnosti podataka provode se kako bi se potvrdilo da li se stvarna vrijednost entiteta točno podudara na različitim mjestima. Ovdje su moguće dvije vrste testova:

(i) Provjere unutar iste sheme:

• Entitet podataka mogao bi postojati u dvije tablice unutar iste sheme (bilo izvorni sustav ili ciljni sustav)
• Primjer: Kao što možete vidjeti na donjoj slici, ProductID je prisutan u tablici Pojedinosti narudžbe i Proizvodi. Napravite točnu provjeru podudaranja za ProductId koji je prisutan u tablici OrderDetails vs Products.

(ii) Provjere u shemama:

• Entitet podataka mogao bi se migrirati kakav jest u ciljanu shemu, tj. Prisutan je u izvornom sustavu kao i ciljnom sustavu
• Primjer: Kao što možete vidjeti na gornjoj slici, ProductID je prisutan u tablici Proizvodi u izvornom sustavu i tablici Proizvodi u ciljnom sustavu. Napravite točnu provjeru podudaranja za ProductId u tablici Proizvodi u izvornom sustavu s ProductId u tablici Products u ciljnom sustavu.

Bilješka: Najbolje je istaknuti (kôd u boji) odgovarajuće cjeline podataka u listu Mapiranje podataka za brzu referencu.

# 2) Prisustvo entiteta

U ovoj vrsti testa moramo potvrditi da se svi entiteti (tablice i polja) podudaraju između izvora i cilja. Postoje dvije mogućnosti, entitet može biti prisutan ili odsutan prema dizajnu podatkovnog modela.

(i) Potvrdite da se sve tablice (i stupci), koje imaju odgovarajuću prisutnost i u izvoru i u cilju, podudaraju. Povlačimo popis svih tablica (i stupaca) i uspoređujemo tekst. Ovaj test ispravnosti funkcionira samo ako se koriste ista imena entiteta.

Ponekad se koriste različiti nazivi tablica pa izravna usporedba možda neće raditi. Morali bismo ove podatke morati preslikati u list Mapiranje podataka i potvrditi zbog pogrešaka.

Druga mogućnost je nepostojanje podataka. Postoje slučajevi kada model podataka zahtijeva da tablica u izvornom sustavu (ili stupcu) nema odgovarajuću prisutnost u ciljnom sustavu (ili obrnuto). Imajte testove da to potvrdite.

• Primjer: Kao što možete vidjeti na donjoj slici, CustDemographic Table je prisutan u ciljnom sustavu, a ne u izvornom sustavu.
• Polje CustomerType u tablici Kupci sadrži podatke samo u izvornom sustavu, a ne u ciljnom sustavu.

# 3) Točnost podataka

Kao što i samo ime govori, provjeravamo jesu li podaci logički točni. Postoje dvije kategorije za ovu vrstu testa. Ovim tester može uhvatiti probleme s kvalitetom podataka čak i u izvornom sustavu.

operativni sustavi koji pokreću Windows programe

(slika izvor )

Bilješka: Pokrenite ovaj test u ciljanom sustavu i provjerite ima li nedostataka u izvornom sustavu.

(i) Nenumerički tip: Prema ovoj klasifikaciji provjeravamo točnost nenumeričkog sadržaja. Primjeri su E-pošta, Pin kodovi, Telefon u važećem formatu.

(ii) Analiza domene: U ovoj vrsti testa odabiremo domene podataka i provjeravamo ima li pogrešaka. Postoje tri skupine za to:

• Na temelju vrijednosti: Ovdje stvaramo popis vrijednosti koje se mogu pojaviti za polje (stupac u tablici). Zatim provjerite jesu li vrijednosti stupaca podskup našeg popisa.
  • Primjer: Provjerite sadrži li stupac Spol M ili F.
• Na temelju dometa: Ovdje postavljamo minimalni i maksimalni raspon za valjane vrijednosti podataka za stupac, na temelju logičkog ili poslovnog obrazloženja. Zatim provjeravamo jesu li vrijednosti stupaca unutar ovog raspona.
  • Primjer: 0 do 120 za dob.
• Referentna datoteka : Ovdje sustav koristi vanjsku datoteku valjanosti.
  • Primjer: Jesu li kodovi država valjani, odabiru li pravu vrijednost iz referentne datoteke, jesu li kodovi zemalja isti između osiguranja kvalitete i proizvodnog okruženja? Ako je referentnoj datoteci ažuriran pozivni broj države, je li ispravno ažuriran u DB-u?

# 4) Provjera metapodataka

U provjeri valjanosti metapodataka potvrđujemo da su definicije tipa podataka tablice i stupca za cilj ispravno dizajnirane, a nakon izrade izvršavaju se prema specifikacijama dizajna podatkovnog modela.

Ovdje postoje dvije skupine:

(i) Dizajn metapodataka: Prva provjera je provjera valjanosti modela podataka u skladu s poslovnim zahtjevima za ciljne tablice. Arhitekti podataka mogu migrirati entitete sheme ili mogu napraviti izmjene kada dizajniraju ciljni sustav.

Sljedeća provjera trebala bi biti provjera valjanosti izrade ispravnih skripti pomoću podatkovnih modela.

Za svaku donju kategoriju prvo provjeravamo ispunjavaju li metapodaci definirani za ciljni sustav poslovni zahtjev, a drugo, jesu li tabele i definicije polja stvorene točno.

U nastavku je dato nekoliko provjera metapodataka:

• Provjera vrste podataka: Primjer: Hoće li ukupna prodaja ispravno raditi s decimalnim (8, 16 ili 20 bajtova) ili dvostrukim tipom?
• Provjera duljine podataka : Primjer: Hoće li duljina podataka za polje Adresa biti dovoljna za 500 znakova? To bi mogao biti slučaj kada se migracija podataka vrši kad se nova geografija doda u tvrtku. Adrese nove geografije mogu imati izuzetno dugačak format, a pridržavanje izvorne duljine može pogrešiti u slučaju upotrebe.
• Provjera indeksa: Primjer: Je li izvršeno indeksiranje stupca OrderId u ciljnom sustavu? Što ako se dogodi spajanje tvrtki koje zahtijevaju migraciju podataka i tablica Narudžbe u ciljnom sustavu postane 100 puta veća?
• Provjera metapodataka u različitim okruženjima: Pod ovom provjerom provjerite poklapaju li se metapodaci između QA testa i proizvodnog okruženja. Ispitivanja mogu proći u QA okruženju, ali u drugim okruženjima neće uspjeti.

(ii) Delta promjena: Ovi testovi otkrivaju nedostatke koji nastaju kada je projekt u tijeku i usred izmjena u metapodacima izvornog sustava i koji nisu implementirani u ciljane sustave.

Primjer: Novo polje CSI (indeks zadovoljstva kupaca) dodano je u tablicu kupaca u izvoru, ali nije uspjelo ući u ciljni sustav.

# 5) Integritet podataka

Ovdje uglavnom validiramo ograničenja integriteta poput stranog ključa, reference primarnog ključa, jedinstvenog, zadanog itd.

(slika izvor )

Za strane ključeve moramo provjeriti postoje li u podređenoj tablici sirotići zapisi u kojima korišteni strani ključ nije prisutan u nadređenoj tablici.

Primjer: Tablica kupaca ima CustomerID koji je Primarni ključ. Tabela narudžbi ima CustomerID kao strani ključ. Tablica narudžbi možda ima ID kupca koji nije u tablici Kupci. Moramo imati testove kako bismo otkrili takva kršenja ograničenja integriteta. Tablica mapiranja podataka pružit će vam jasnost u tome koje tablice imaju ta ograničenja.

Bilješka: Pokrenite ovaj test u ciljanom sustavu i provjerite u izvornom sustavu ako postoje nedostaci.

# 6) Kompletnost podataka

Ovo su testovi ispravnosti koji otkrivaju nedostajući broj zapisa ili redova između izvorne i ciljne tablice i mogu se često pokretati nakon što se automatiziraju.

Postoje dvije vrste testova:

(i) Broj zapisa: Ovdje uspoređujemo ukupan broj zapisa za podudaranje tablica između izvornog i ciljnog sustava. Ovo je brza provjera ispravnosti stanja kako bi se potvrdilo pokretanje ETL-a ili zadatka migracije. Imamo nedostatak ako se brojanje ne podudara.

Tijekom izvođenja posla ponekad se odbiju zapisi. Neke od njih mogu biti valjane. Ali kao tester, za to navodimo konkretne primjere.

(ii) Profiliranje podataka u stupcu: Ova vrsta provjere zdrave razumnosti dragocjena je kad je broj zapisa ogroman. Ovdje stvaramo logičke skupove podataka koji smanjuju broj zapisa, a zatim uspoređujemo izvor i cilj.

• Gdje je to moguće, filtrirajte sve jedinstvene vrijednosti u stupac, na primjer, ProductID se može pojaviti više puta u tablici OrderDetails. Odaberite jedinstveni popis ProductID iz ciljane i izvorne tablice i provjerite. To jako smanjuje broj brojeva zapisa i ubrzava testove ispravnosti.
• Kao i gornji testovi, također možemo odabrati sve glavne stupce i provjeriti podudaraju li se KPI (minimalna, maksimalna, prosječna, maksimalna ili minimalna duljina itd.) Između ciljne i izvorne tablice. Primjer: Uzmite prosječne, minimalne i maksimalne vrijednosti iz stupca Cijena u OrderDetails i usporedite te vrijednosti između ciljnih i izvornih tablica radi nepodudaranja.
• Još jedna provjera može se izvršiti za Null vrijednosti. Odaberite važne stupce i filtrirajte popis redaka u kojima stupac sadrži null vrijednosti. Usporedite ove retke između ciljnog i izvornog sustava radi neusklađenosti.

# 7) Transformacija podataka

Ovi testovi tvore temeljne testove projekta. Pregledajte dokument sa zahtjevima kako biste razumjeli zahtjeve za transformacijom. Pripremite test podatke u izvornim sustavima kako bi odražavali različite scenarije transformacije. Oni imaju mnoštvo testova i trebali bi biti detaljno obrađeni u ETL temama ispitivanja.

Ispod je sažeti popis testova obuhvaćenih ovim:

(i) Transformacija:

• Primjer: ETL kôd možda ima logiku odbijanja nevaljanih podataka. Provjerite ih prema zahtjevima.
• ETL kôd također može sadržavati logiku za automatsko generiranje određenih ključeva poput surogatnih ključeva. Moramo imati testove da bismo provjerili ispravnost (tehničku i logičku) istih.
• Provjerite ispravnost spajanja ili razdvajanja vrijednosti polja nakon završetka ETL-a ili migracije.
• Imati testove za provjeru referentnih provjera integriteta. Na primjer, vrsta kvara može biti ProductId koji se koristi u tablici Narudžbe nije prisutan u nadređenoj tablici Products. Zatražite test kako biste provjerili kako se evidencije o siročadima ponašaju tijekom ETL posla.
• Ponekad se podaci koji nedostaju ubacuju pomoću ETL koda. Provjerite ispravnost istih.
• ETL ili migracijske skripte ponekad imaju logiku za ispravljanje podataka. Provjerite rade li ispravke podataka.
• Provjerite prijavljuju li se korisnici nevaljanim / odbijenim / pogrešnim podacima.
• Stvorite proračunsku tablicu scenarija ulaznih podataka i očekivanih rezultata i potvrdite ih kod poslovnog kupca.

(ii) Rubni slučajevi: Potvrdite da se logika transformacije dobro drži na granicama.

• Primjer: Što se događa kada se TotalSales u vrijednosti od 1 bilijuna provede kroz ETL posao? Djeluju li slučajevi od kraja do kraja? Prepoznajte polja koja potencijalno mogu imati velike vrijednosti i pokrenite testove s tim velikim vrijednostima. Oni bi trebali sadržavati numeričke i nenumeričke vrijednosti.
• Za datumska polja, uključujući cijeli raspon očekivanih datuma - prijestupne godine, 28/29 dana za veljaču. 30, 31 dan za ostale mjesece.

# 8) Jedinstvenost podataka ili umnožavanje

U ovoj vrsti testa identificirajte stupce koji bi trebali imati jedinstvene vrijednosti prema podatkovnom modelu. Također, uzmite u obzir poslovnu logiku da iskoristite takve podatke. Pokrenite testove da biste provjerili jesu li jedinstveni u sustavu. Sljedeće pokretanje testova za utvrđivanje stvarnih duplikata.

• Primjer: Filtrirajte dvostruke podatke i provjerite jesu li autentični. Na primjer, Zapis o zaposleniku koji sadrži dva puta iste podatke o braći i sestrama.
• Korisnički telefonski broj trebao bi biti jedinstven u sustavu (poslovni zahtjev).
• Poslovni zahtjev kaže da kombinacija ProductID i ProductName u tablici Products mora biti jedinstvena jer ProductName može biti duplikat.

# 9) Obavezno

U ovoj vrsti testa identificirajte sva polja označena kao Obavezna i provjerite imaju li obvezna polja vrijednosti. Ako postoje zadane vrijednosti povezane s poljem u DB-u, provjerite je li ispravno popunjeno kad podataka nema.

• Primjer: Ako BillDate nije unet, tada je CurrentDate BillDate.

# 10) Pravovremenost

Uvijek dokumentirajte testove koji potvrđuju da radite s podacima iz dogovorenih rokova.

koje je moje korisničko ime i lozinka za usmjerivač

• Primjer: ProductDiscount ažuriran je unatrag 15 dana, a ProductDiscount se mijenja svakih sedam dana. To znači da se vaši testovi ne rade s pravim vrijednostima popusta.
• Izvješće s prediktivnom analitikom za indeks zadovoljstva kupaca trebalo je raditi s posljednjim podacima od jednog tjedna, a to je bio tjedan promocije prodaje u Walmartu. Ali posao ETL-a dizajniran je za rad u frekvenciji od 15 dana. Ovo je glavni nedostatak koji testeri mogu otkriti.

# 11) Null podaci

U ovoj vrsti testa usredotočujemo se na valjanost null podataka i provjeru da važan stupac ne može biti null.

• Primjer: Filtrirajte sve null podatke i provjerite je li null dopušteno.
• Ako postoje važni stupci za poslovne odluke, pobrinite se da ne postoje nule.

# 12) Provjera dometa

Treba testirati podatkovni entitet u kojem rasponi imaju poslovni smisao.

• Primjer: Količina narudžbe po fakturi ne može biti veća od 5K u kategoriji softvera.
• Dob ne smije biti veća od 120 godina.

# 13) Poslovna pravila

Dokumentirajte sve poslovne zahtjeve za polja i pokrenite testove za iste.

• Primjer: Resursi mlađi od 20 godina nisu prihvatljivi. Provjere provjere valjanosti podataka potrebne su ako se ovo pravilo primijeni na podatke.
• Datum otkaza trebao bi biti ništavan ako je status zaposlenika Active istina / preminuo.
• OD podataka bi trebalo biti manje od TO Datum.
• Zbrojite iznose za kupnju na razini predmeta na iznose na razini narudžbe

# 14) Zbirne funkcije

Skupne funkcije ugrađene su u funkcionalnost baze podataka. Dokumentirajte sve agregate u izvornom sustavu i provjerite daje li agregatna upotreba iste vrijednosti u ciljnom sustavu (zbroj, maks, min, broj).

Često se alati na izvornom sustavu razlikuju od ciljnog sustava. Provjerite izvršavaju li oba alata agregatne funkcije na isti način.

# 15) Skraćivanje i zaokruživanje podataka

U ovim vrstama testova identificiramo polja s logikom skraćivanja i zaokruživanja koja se odnose na posao. Zatim dokumentiramo i dobivamo potpis na logiku skraćivanja i zaokruživanja s vlasnicima proizvoda i testiramo ih s reprezentativnim podacima proizvodnje.

# 16) Testovi kodiranja

Provjerite postoje li kodirane vrijednosti u izvornom sustavu i provjerite jesu li podaci ispravno popunjeni nakon ETL-a ili zadatka migracije podataka u ciljani sustav.

• Primjer: Dvobajtni znakovi za FirstName na kineskom prihvaćeni su u izvornom sustavu koji je kodiran. Provjerite ponašanje ovog polja kada se premjesti u ciljni sustav.
• Polje Lozinka je kodirano i migrirano. Osigurajte da rade dobro nakon migracije.

# 17) Regresijski testovi

Ovo je osnovni koncept testiranja gdje testeri pokreću sav svoj kritični paket slučajeva generiran pomoću gornjeg kontrolnog popisa nakon promjene u izvornom ili ciljnom sustavu.

Zaključak

Dakle, vidjeli smo da je provjera valjanosti podataka zanimljivo područje za istraživanje podataka koji zahtijevaju velike količine podataka i čini najvažnije testove. List za mapiranje podataka kritičan je artefakt koji testeri moraju održavati da bi postigli uspjeh s tim testovima. Mogu održavati više verzija s istaknutim bojama kako bi stvorili ulazne podatke za bilo koji od gore navedenih testova.

Treba voditi računa o održavanju delta promjena u različitim verzijama.

Tražimo od čitatelja da podijele i druga područja testa na koja su naišli tijekom svog rada u korist zajednice ispitivača.

Preporučena literatura

• Što je ETL (ekstrakt, transformacija, učitavanje) postupak u skladištu podataka?
• 15 najboljih ETL alata u 2021. godini (potpuni ažurirani popis)
• Kako izvesti ETL testiranje pomoću alata Informatica PowerCenter
• 10 najboljih alata za mapiranje podataka korisnih u ETL procesu (POPIS 2021)
• Top 10 ETL alata za testiranje 2021. godine
• Vodič za testiranje migracije podataka: cjelovit vodič
• 13 najboljih alata za migraciju podataka za potpunu cjelovitost podataka (2021 POPIS)
• Vodič za ispitivanje skladišta podataka ETL-a (cjelovit vodič)