Meny

Datavalideringstester för ETL- och datamigrationsprojekt

  • Huvud
  • Övrig
  • Datavalideringstester för ETL- och datamigrationsprojekt

data validation tests

Prova Vårt Instrument För Att Eliminera Problem

Denna handledning beskriver ETL- och datamigrationsprojekt och täcker datavalideringskontroller eller tester för ETL / datamigrationsprojekt för förbättrad datakvalitet:

Den här artikeln är för programvarutestare som arbetar med ETL- eller datamigrationsprojekt och är intresserade av att fokusera sina tester på bara datakvalitetsaspekterna. Dessa typer av projekt har en enorm datamängd som lagras på källagring och sedan drivs av någon logik som finns i programvaran och flyttas till mållagringen.

Datavalideringstester säkerställer att de data som finns i slutliga målsystem är giltiga, korrekta enligt företagets krav och bra för användning i det levande produktionssystemet.

Datavalidering för ETL- och datamigrationsprojekt

Antalet datakvalitetsaspekter som kan testas är enormt och listan nedan ger en introduktion till detta ämne.

Vad du kommer att lära dig:

Vad är datavalidering?

Datavalidering

Enkelt uttryckt är datavalidering att validera det faktum att de data som flyttas som en del av ETL- eller datamigrationsjobb är konsekventa, korrekta och fullständiga i målproduktionens levande system för att tillgodose affärsbehovet.

Exempel: Adressen till en elev i tabellen Student var 2000 tecken i källsystemet. Datavalidering verifierar om exakt samma värde finns i målsystemet. Den kontrollerar om data trunkeras eller om vissa specialtecken tas bort.

I den här artikeln kommer vi att diskutera många av dessa datavalideringskontroller. Som testare för ETL- eller datamigrationsprojekt ger det ett enormt värde om vi avslöjar datakvalitetsproblem som kan spridas till målsystemen och störa hela affärsprocesserna.

Varför validera data för ETL-projekt?

I ETL-projekt extraheras data från källan, bearbetas genom att tillämpa lite logik i programvaran, transformeras och sedan laddas in i mållagringen. I många fall görs omvandlingen för att ändra källdata till ett mer användbart format för företagets krav.

Här krävs datavalidering för att bekräfta att data som laddas in i målsystemet är fullständiga, korrekta och det inte finns någon dataförlust eller avvikelser.

mål- och källsystem

Exempel: En e-handelsapplikation har ETL-jobb som plockar alla OrdersIds mot varje CustomerID från Order-tabellen som sammanfattar TotalDollarsSpend av kunden och laddar den i en ny CustomerValue-tabell och markerar varje CustomerRating som kundbaserat med hög / medel / lågt värde. på någon komplex algoritm.

Enkelt datavalideringstest är att se att CustomerRating beräknas korrekt.

Ett annat test är att verifiera att TotalDollarSpend beräknas med rätta utan några defekter i avrundning av värdena eller maximalt överflöd.

Varför validera data för datamigrationsprojekt?

I datamigrationsprojekt migreras de enorma datamängderna som lagras i källminnet till olika mållagringar av flera skäl som infrastrukturuppgradering, föråldrad teknik, optimering etc. Till exempel, företag kan migrera sitt enorma datalager från äldre system till nyare och mer robusta lösningar på AWS eller Azure.

Det primära motivet för sådana projekt är att flytta data från källsystemet till ett målsystem så att data i målet är mycket användbara utan störningar eller negativ påverkan på verksamheten.

Även här krävs datavalidering för att bekräfta att källans data är densamma i målet efter rörelsen.

Exempel: Antag att för e-handelsapplikationen migrerades ordertabellen med 200 miljoner rader till målsystemet på Azure. Enkelt datavalideringstest är att verifiera att alla 200 miljoner rader med data är tillgängliga i målsystemet.

Ett annat test kan vara att bekräfta att datumformaten matchar mellan källan och målsystemet.

Det finns olika aspekter som testare kan testa i sådana projekt som funktionella tester, prestandatester, säkerhetstester, infra-tester, E2E-tester, regressionstester etc.

Rekommenderad läsning => Test av datamigrering , ETL Testing Data Warehouse Testing Tutorial

I den här artikeln tittar vi bara på dataaspekten av tester för ETL & Migration-projekt.

Datamappningsblad

Till att börja med skapar du ett datakartningsblad för ditt dataprojekt. Datamappning är processen för att matcha enheter mellan käll- och måltabellerna. Börja med att dokumentera alla tabeller och deras enheter i källsystemet i ett kalkylark. Dokumentera nu motsvarande värden för var och en av dessa rader som förväntas matcha i måltabellerna. Anteckna omvandlingsreglerna i en separat kolumn om någon.

Datamappningsark innehåller mycket information som hämtats från datamodeller från Data Architects. Inledningsvis kan testare skapa en förenklad version och kan lägga till mer information när de fortsätter. Se exemplet med datakartningsblad nedan- överordnat bord

Ladda ner en mall från Förenklat datablad för kartläggning av data

Datavalideringstester

# 1) Datainformitet

Datainformeringstester utförs för att verifiera att enhetens verkliga värde har exakt matchning på olika platser. Vi har två typer av tester möjliga här:

(i) Kontroller inom samma schema:

  • Dataenheten kan finnas i två tabeller inom samma schema (antingen källsystem eller målsystem)
  • Exempel: Som du kan se i bilden nedan finns ProductID i tabellen OrderDetails och Products. Gör en exakt matchningsverifiering för ProductId i tabellen OrderDetails vs Products.

Förenklat datakartningsblad 1

(ii) Kontroller över scheman:

  • Dataenheten kan migreras som den är till målschemat, dvs den finns i källsystemet såväl som målsystemet
  • Exempel: Som du kan se i bilden ovan finns ProductID i tabellen Produkter i källsystemet och Produkter i målsystemet. Gör en exakt matchningsverifiering för ProductId i Products-tabellen i källsystemet till ProductId i Products-tabellen i målsystemet.

Notera: Det är bäst att markera (färgkod) matchande dataenheter i databladet Mapping för snabb referens.

# 2) Enhetens närvaro

I denna typ av test måste vi verifiera att alla enheter (tabeller och fält) matchas mellan källa och mål. Det finns två möjligheter, en enhet kan vara närvarande eller frånvarande enligt datamodelldesignen.

(i) Verifiera att alla tabeller (och kolumner), som har en motsvarande närvaro i både källa och mål, matchar. Vi tar en lista över alla tabeller (och kolumner) och jämför en text. Detta sanity-test fungerar bara om samma enhetsnamn används överallt.

Ibland används olika tabellnamn och därför fungerar en direkt jämförelse kanske inte. Vi kan behöva kartlägga denna information i databladet Mapping och validera den för fel.

En annan möjlighet är frånvaron av data. Det finns fall där datamodellen kräver att en tabell i källsystemet (eller kolumnen) inte har en motsvarande närvaro i målsystemet (eller vice versa). Har test för att validera detta.

  • Exempel: Som du kan se i bilden nedan finns CustDemographic Table i målsystemet och inte i källsystemet.
  • Kundtypfältet i kundtabellen har endast data i källsystemet och inte i målsystemet.

dart (datanoggrannhet)

# 3) Datanoggrannhet

Som namnet antyder validerar vi om uppgifterna är logiskt korrekta. Det finns två kategorier för denna typ av test. Med detta kan testaren fånga datakvalitetsproblemen även i källsystemet.

Dataintegritet

(bild källa )

Notera: Kör detta test i målsystemet och backcheck i källsystemet för eventuella defekter.

(i) Icke-numerisk typ: Under denna klassificering verifierar vi noggrannheten i det icke-numeriska innehållet. Exempel är e-post, pinkoder, telefon i giltigt format.

(ii) Domänanalys: I denna typ av test väljer vi datadomäner och validerar för fel. Det finns tre grupperingar för detta:

  • Baserat på värde: Här skapar vi en lista över värden som kan förekomma för ett fält (kolumn i tabellen). Validera sedan om kolumnvärdena är en delmängd av vår lista.
    • Exempel: Kontrollera om kolumnen Kön innehåller antingen M eller F.
  • Baserat på räckvidd: Här ställer vi in ​​minimi- och maxintervall för giltiga datavärden för en kolumn, baserat på logiskt eller affärsmässigt resonemang. Vi validerar sedan om kolumnvärdena faller inom detta intervall.
    • Exempel: 0 till 120 för ålder.
  • Referensfil : Här använder systemet en extern giltighetsfil.
    • Exempel: Är landskoder giltiga, väljer de rätt värde från referensfilen, är landskoder samma mellan QA och produktionsmiljön? Om en landskod uppdaterades i referensfilen, uppdateras den med rätta i DB?

# 4) Validering av metadata

I validering av metadata validerar vi att datatypsdefinitionerna för tabell och kolumn för målet är korrekt utformade, och när de en gång har designats körs de enligt specifikationerna för datamodellens design.

Det finns två grupperingar här:

hur man gör en ddos-attack

(i) Metadata design: Den första kontrollen är att verifiera att datamodellen är korrekt utformad enligt affärskraven för måltabellerna. Dataarkitekter kan migrera schemaenheter eller kan göra ändringar när de utformar målsystemet.

Nästa kontroll bör vara att validera att rätt skript skapades med hjälp av datamodellerna.

För varje kategori nedan kontrollerar vi först om metadata som definierats för målsystemet uppfyller affärsbehovet och för det andra om tabellerna och fältdefinitionerna skapades korrekt.

Några av metadatakontrollerna ges nedan:

  • Kontroll av datatyp: Exempel: Fungerar den totala försäljningen korrekt med decimal (8, 16 eller 20 byte) eller dubbel typ?
  • Datalängdskontroll : Exempel: Kommer datalängden för adressfältet att vara tillräcklig med 500 tecken? Det kan vara ett fall där datamigrering sker när ny geografi läggs till företaget. Adresserna till den nya geografin kan ha ett extremt långt format och att hålla sig till den ursprungliga längden kan göra fel på ett användningsfall.
  • Indexkontroll: Exempel: Går det indexering för OrderId-kolumnen i målsystemet? Vad händer om en sammanslagning av företag hände, vilket kräver datamigrering och ordertabellen växer 100 gånger i målsystemet?
  • Metadata Kontroll över miljöer: Kontrollera under denna kontroll att metadata matchar mellan QA-testet och produktionsmiljön. Tester kan passera i QA-miljön men misslyckas i andra miljöer.

(ii) Delta-förändring: Dessa tester avslöjar brister som uppstår när projektet pågår och halvvägs finns förändringar i källsystemets metadata och implementerades inte i målsystem.

Exempel: Nytt fält CSI (kundnöjdhetsindex) lades till kundtabellen i källan men kunde inte göras till målsystemet.

# 5) Dataintegritet

Här validerar vi främst integritetsbegränsningarna som främmande nyckel, primär nyckelreferens, unik, standard, etc.

överordnat bord

(bild källa )

För utländska nycklar måste vi kontrollera om det finns föräldralösa poster i underordnade tabellen där den främmande nyckeln som används inte finns i modertabellen.

Datakontroll

Exempel: Kundtabellen har CustomerID som är en primär nyckel. Beställningstabellen har CustomerID som en utländsk nyckel. Beställningstabellen kan ha ett kund-ID som inte finns i tabellen Kunder. Vi måste göra tester för att avslöja sådana kränkningar av integritetsbegränsningar. Datamappningstabellen ger dig tydlighet i vilka tabeller som har dessa begränsningar.

Notera: Kör detta test i målsystemet och backcheck i källsystemet om det finns defekter.

# 6) Fullständighet av uppgifter

Dessa är sanity-tester som avslöjar saknade poster eller radantal mellan källa och måltabell och kan köras ofta när de automatiseras.

Det finns två typer av tester:

(i) Antal poster: Här jämför vi det totala antalet poster för matchande tabeller mellan källan och målsystemet. Det här är en snabb sanitetskontroll för att verifiera posten som körs av ETL- eller migreringsjobbet. Vi har en defekt om räkningarna inte stämmer överens.

Ibland avvisas poster under jobbet. Vissa av dessa kan vara giltiga. Men som testare gör vi en argumentation för detta.

(ii) Kolumndata profilering: Denna typ av sanity-test är värdefull när rekordräkningarna är enorma. Här skapar vi logiska uppsättningar data som minskar postantalet och gör sedan en jämförelse mellan källa och mål.

  • Om möjligt, filtrera alla unika värden i en kolumn, till exempel, ProductID kan förekomma flera gånger i OrderDetails-tabellen. Välj en unik lista för ProductID från både mål- och källtabeller och validera. Detta minskar antalet rekordräkningar kraftigt och påskyndar sanity-test.
  • Liksom ovanstående tester kan vi också välja alla huvudkolumner och kontrollera om KPI (minimum, maximum, genomsnitt, maximal eller minsta längd etc.) matchar mellan mål och källtabell. Exempel: Ta genomsnittliga, lägsta och högsta värden från kolumnen Pris i OrderDetails och jämför dessa värden mellan mål- och källtabeller för obalanser.
  • En annan kontroll kan göras för nollvärden. Välj viktiga kolumner och filtrera bort en lista med rader där kolumnen innehåller nollvärden. Jämför dessa rader mellan mål- och källsystem för ojämnhet.

Tidslinjer

# 7) Datatransformation

Dessa tester utgör kärnproven i projektet. Granska kravdokumentet för att förstå transformationskraven. Förbered testdata i källsystemen för att återspegla olika transformationsscenarier. Dessa har många tester och bör behandlas i detalj under ETL-testämnen.

Nedan följer en kortfattad lista över tester som omfattas av detta:

(i) Transformation:

  • Exempel: ETL-kod kan ha logik för att avvisa ogiltiga data. Kontrollera dessa mot kraven.
  • ETL-kod kan också innehålla logik för att automatiskt generera vissa nycklar som surrogatnycklar. Vi måste göra tester för att verifiera riktigheten (teknisk och logisk) av dessa.
  • Validera korrektheten av att gå med eller dela upp fältvärden efter att ett ETL- eller migreringsjobb är gjort.
  • Har tester för att verifiera referensintegritetskontroller. Till exempel, en typ av defekt kan vara ProductId som används i beställningstabellen finns inte i överordnade tabellprodukter. Har ett test för att verifiera hur föräldralösa poster beter sig under ett ETL-jobb.
  • Ibland infogas saknade data med ETL-koden. Kontrollera riktigheten av dessa.
  • ETL- eller migrationsskript har ibland logik för att korrigera data. Verifiera datakorrigering fungerar.
  • Kontrollera om ogiltiga / avvisade / felaktiga data rapporteras till användarna.
  • Skapa ett kalkylblad med scenarier för indata och förväntade resultat och validera dessa med företagskunden.

(ii) Kantfall: Kontrollera att transformationslogik håller bra vid gränserna.

  • Exempel: Vad händer när TotalSales med värdet 1 biljoner körs genom ett ETL-jobb? Fungerar mål till slut? Identifiera fält som potentiellt kan ha stora värden och kör tester med dessa stora värden. De bör innehålla numeriska och icke-numeriska värden.
  • För datumfält, inklusive hela förväntat datumintervall - skottår, 28/29 dagar för februari. 30, 31 dagar för andra månader.

# 8) Data Unikhet eller duplicering

I den här typen av test, identifiera kolumner som ska ha unika värden enligt datamodellen. Ta också hänsyn till affärslogik för att rensa bort sådan data. Kör tester för att verifiera om de är unika i systemet. Nästa körningstest för att identifiera de faktiska dubbletterna.

  • Exempel: Filtrera efter dubblettdata och kontrollera om den är äkta. Till exempel, Anställdberoende post innehåller samma syskondata två gånger.
  • Användarens telefonnummer ska vara unikt i systemet (affärsbehov).
  • Affärskravet säger att en kombination av ProductID och ProductName i Products-tabellen ska vara unik eftersom ProductName kan dupliceras.

# 9) Obligatoriskt

I den här typen av test, identifiera alla fält markerade som obligatoriska och validera om obligatoriska fält har värden. Om det finns standardvärden associerade med ett fält i DB, kontrollera om det fylls korrekt när data inte finns där.

  • Exempel: Om BillDate inte anges är CurrentDate BillDate.

# 10) Aktualitet

Dokumentera alltid test som verifierar att du arbetar med data från de överenskomna tidslinjerna.

  • Exempel: ProductDiscount uppdaterades för 15 dagar tillbaka och affärsdomän anger att ProductDiscount ändras var sjunde dag. Det betyder att dina tester inte görs med rätt rabattvärden.
  • En förutsägbar analysrapport för kundnöjdhetsindexet skulle fungera med de senaste 1-veckodata, vilket var en säljfrämjande vecka på Walmart. Men ETL-jobbet var utformat för att köras med en frekvens på 15 dagar. Detta är en stor defekt som testare kan upptäcka.

# 11) Nulldata

I denna typ av test fokuserar vi på giltigheten av nolldata och verifiering av att den viktiga kolumnen inte kan vara noll.

  • Exempel: Filtrera bort alla nolldata och validera om noll är tillåtet.
  • Om det finns viktiga kolumner för affärsbeslut, se till att nollor inte finns.

# 12) Räckviddskontroll

Dataenhet där intervall är affärsmässigt meningsfullt bör testas.

  • Exempel: Orderkvantitet per faktura får inte vara mer än 5 000 i programvarukategorin.
  • Ålder bör inte vara mer än 120.

# 13) Affärsregler

Dokumentera alla affärskrav för fält och kör tester för samma.

  • Exempel: Resurser med ålder under 20 år är inte stödberättigande. Datavalideringskontroller krävs om denna regel tillämpas på data.
  • Uppsägningsdatumet ska vara ogiltigt om anställdas aktiva status är sann / avliden.
  • FROM-data bör vara mindre än TO Date.
  • Gör inköpsbelopp på artikelnivå till belopp på ordernivå

# 14) Aggregerade funktioner

Aggregerade funktioner är inbyggda i databasens funktionalitet. Dokumentera alla aggregat i källsystemet och kontrollera om aggregatanvändning ger samma värden i målsystemet (summa, max, min, räkning).

Ganska ofta skiljer sig verktygen på källsystemet från målsystemet. Kontrollera om båda verktygen kör aggregerade funktioner på samma sätt.

# 15) Datatrunkning och avrundning

I dessa typer av tester identifierar vi fält med avkortning och avrundningslogik som rör verksamheten. Vi dokumenterar sedan och får signoff på trunkerings- och avrundningslogiken med produktägare och testar dem med produktionsrepresentantdata.

# 16) Kodningstester

Validera om det finns kodade värden i källsystemet och verifiera om uppgifterna är korrekt fyllda efter ETL- eller datamigrationsjobbet i målsystemet.

  • Exempel: Dubbelbyte-tecken för FirstName på kinesiska accepterades i källsystemet som kodades. Verifiera beteendet för detta fält när du flyttar till målsystemet.
  • Lösenordsfältet kodades och migrerades. Se till att de fungerar bra efter migreringen.

# 17) Regressionstest

Detta är ett grundläggande testkoncept där testare kör alla sina kritiska testfallssviter som genereras med hjälp av ovanstående checklista efter en ändring till käll- eller målsystem.

Slutsats

Så vi har sett att datavalidering är ett intressant område att utforska för dataintensiva projekt och utgör de viktigaste testerna. Datamappningsarket är en kritisk artefakt som testare måste bibehålla för att uppnå framgång med dessa tester. De kan behålla flera versioner med färghöjdpunkter för att bilda ingångar för någon av testerna ovan.

Försiktighet bör iakttas för att upprätthålla deltaändringar över olika versioner.

Vi ber läsarna att dela med sig av andra delar av testet som de har stött på under sitt arbete till förmån för testmiljön.

Rekommenderad läsning

^