Menu

Gegevensvalidatietests voor ETL- en gegevensmigratieprojecten

  • Hoofd
  • Andere
  • Gegevensvalidatietests voor ETL- en gegevensmigratieprojecten

data validation tests

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Deze zelfstudie beschrijft ETL- en datamigratieprojecten en behandelt gegevensvalidatiecontroles of tests voor ETL- / datamigratieprojecten voor verbeterde gegevenskwaliteit:

Dit artikel is bedoeld voor softwaretesters die werken aan ETL- of datamigratieprojecten en die geïnteresseerd zijn om hun tests te concentreren op alleen de aspecten van datakwaliteit. Dit soort projecten hebben een enorme hoeveelheid gegevens die worden opgeslagen op de bronopslag en vervolgens worden bediend door een of andere logica die aanwezig is in de software en worden verplaatst naar de doelopslag.

Gegevensvalidatietests zorgen ervoor dat de gegevens die aanwezig zijn in de uiteindelijke doelsystemen geldig en nauwkeurig zijn volgens de zakelijke vereisten en goed zijn voor gebruik in het live productiesysteem.

Gegevensvalidatie voor ETL- en datamigratieprojecten

Het aantal datakwaliteitsaspecten dat kan worden getest is enorm en deze lijst hieronder geeft een inleiding op dit onderwerp.

Wat je leert:

Wat is gegevensvalidatie?

Gegevensvalidatie

In eenvoudige bewoordingen is gegevensvalidatie het valideren van het feit dat de gegevens die worden verplaatst als onderdeel van ETL- of datamigratietaken consistent, nauwkeurig en compleet zijn in de live-productiesystemen van de beoogde productie om aan de zakelijke vereisten te voldoen.

Voorbeeld: Het adres van een leerling in de leerlingentabel was 2000 tekens in het bronsysteem. Met gegevensvalidatie wordt gecontroleerd of exact dezelfde waarde in het doelsysteem aanwezig is. Het controleert of de gegevens zijn afgekapt of dat bepaalde speciale tekens zijn verwijderd.

In dit artikel zullen we veel van deze gegevensvalidatiecontroles bespreken. Als testers voor ETL- of datamigratieprojecten voegt het een enorme waarde toe als we problemen met de datakwaliteit ontdekken die kunnen worden verspreid naar de doelsystemen en de volledige bedrijfsprocessen kunnen verstoren.

Waarom gegevens valideren voor ETL-projecten?

In ETL-projecten worden gegevens uit de bron gehaald, bewerkt door enige logica in de software toe te passen, getransformeerd en vervolgens in de doelopslag geladen. In veel gevallen wordt de transformatie gedaan om de brongegevens te veranderen in een bruikbaarder formaat voor de zakelijke vereisten.

Hier is gegevensvalidatie vereist om te bevestigen dat de gegevens die in het doelsysteem worden geladen, volledig en nauwkeurig zijn en dat er geen gegevensverlies of discrepanties zijn.

doel- en bronsysteem

Voorbeeld: Een e-commercetoepassing heeft ETL-taken die alle OrdersIds voor elke CustomerID uit de Order-tabel halen, die de TotalDollarsSpend door de klant optelt, en deze laadt in een nieuwe CustomerValue-tabel, waarbij elke CustomerRating wordt gemarkeerd als High / Medium / Low-value klanten gebaseerd op een complex algoritme.

Een eenvoudige gegevensvalidatietest is om te zien of de CustomerRating correct wordt berekend.

Een andere test is om te verifiëren dat de TotalDollarSpend correct wordt berekend zonder defecten bij het afronden van de waarden of overflows van maximale waarden.

Waarom gegevens valideren voor datamigratieprojecten?

In datamigratieprojecten worden de enorme hoeveelheden gegevens die in de bronopslag zijn opgeslagen, gemigreerd naar verschillende doelopslag om verschillende redenen, zoals infrastructuurupgrade, verouderde technologie, optimalisatie, enz. Bijvoorbeeld, Bedrijven kunnen hun enorme datawarehouse migreren van legacysystemen naar nieuwere en robuustere oplossingen op AWS of Azure.

Het belangrijkste motief voor dergelijke projecten is om gegevens van het bronsysteem naar een doelsysteem te verplaatsen, zodat de gegevens in het doel zeer bruikbaar zijn zonder enige verstoring of negatieve impact op het bedrijf.

Ook hier is gegevensvalidatie vereist om te bevestigen dat de gegevens op de bron na de verplaatsing hetzelfde zijn in het doel.

Voorbeeld: Stel dat voor de e-commercetoepassing de tabel Orders met 200 miljoen rijen werd gemigreerd naar het doelsysteem op Azure. Een eenvoudige gegevensvalidatietest is om te verifiëren dat alle 200 miljoen rijen gegevens beschikbaar zijn in het doelsysteem.

Een andere test zou kunnen zijn om te bevestigen dat de datumnotaties overeenkomen tussen het bron- en doelsysteem.

Er zijn verschillende aspecten die testers kunnen testen in dergelijke projecten, zoals functionele tests, prestatietests, beveiligingstests, infrastests, E2E-tests, regressietests, enz.

Aanbevolen literatuur => Testen van gegevensmigratie ​ ETL-testen Tutorial datawarehouse-testen

In dit artikel kijken we alleen naar het data-aspect van tests voor ETL & Migratieprojecten.

Gegevenskaartblad

Maak om te beginnen een datamapping-blad voor uw dataproject. Gegevenstoewijzing is het proces van het matchen van entiteiten tussen de bron- en doeltabellen. Begin met het documenteren van alle tabellen en hun entiteiten in het bronsysteem in een spreadsheet. Documenteer nu de overeenkomstige waarden voor elk van deze rijen die naar verwachting overeenkomen in de doeltabellen. Noteer de transformatieregels in een aparte kolom, indien aanwezig.

Datamapping-sheets bevatten veel informatie die is geplukt uit datamodellen van Data Architects. Aanvankelijk konden testers een vereenvoudigde versie maken en gaandeweg meer informatie toevoegen. Zie het voorbeeld van het Data Mapping Sheet hieronder- bovenliggende tafel

Download een sjabloon van Vereenvoudigd Data Mapping Sheet

Gegevensvalidatietests

# 1) Gegevensuniformiteit

Er worden gegevensuniformiteitstests uitgevoerd om te verifiëren dat de werkelijke waarde van de entiteit op verschillende plaatsen exact overeenkomt. We hebben hier twee soorten tests mogelijk:

(i) Controles binnen hetzelfde schema:

  • De gegevensentiteit kan bestaan ​​in twee tabellen binnen hetzelfde schema (bronsysteem of doelsysteem)
  • Voorbeeld: Zoals u in de onderstaande afbeelding kunt zien, is ProductID aanwezig in de tabel OrderDetails en Products. Voer een exacte matchverificatie uit voor ProductId dat aanwezig is in de tabel OrderDetails vs Products.

Vereenvoudigd blad voor gegevensmapping 1

(ii) Controles tussen schema's:

  • De gegevensentiteit kan as-is gemigreerd naar het doelschema, d.w.z. het is aanwezig in het bronsysteem en het doelsysteem
  • Voorbeeld: Zoals u in de bovenstaande afbeelding kunt zien, is ProductID aanwezig in de tabel Producten in het bronsysteem en de tabel Producten in het doelsysteem. Voer een exacte matchverificatie uit voor ProductId in de tabel Producten in het bronsysteem naar ProductId in de tabel Producten in het doelsysteem.

Notitie: Het is het beste om (kleurcode) overeenkomende data-entiteiten te markeren in het Data Mapping-blad voor snelle referentie.

# 2) Aanwezigheid van entiteiten

Bij dit type test moeten we valideren dat alle entiteiten (tabellen en velden) overeenkomen tussen bron en doel. Er zijn twee mogelijkheden: een entiteit kan aanwezig of afwezig zijn volgens het gegevensmodelontwerp.

(ik) Valideer dat alle tabellen (en kolommen), die een overeenkomstige aanwezigheid hebben in zowel bron als doel, overeenkomen. We halen een lijst met alle tabellen (en kolommen) en doen een tekstvergelijking. Deze gezondheidstest werkt alleen als dezelfde entiteitsnamen overal worden gebruikt.

Soms worden verschillende tabelnamen gebruikt en daarom werkt een directe vergelijking mogelijk niet. Mogelijk moeten we deze informatie in het Data Mapping-blad in kaart brengen en valideren op fouten.

Een andere mogelijkheid is het ontbreken van gegevens. Er zijn gevallen waarin het datamodel vereist dat een tabel in het bronsysteem (of kolom) niet overeenkomstig aanwezig is in het doelsysteem (of vice versa). Laat tests uitvoeren om dit te valideren.

  • Voorbeeld: Zoals u in de onderstaande afbeelding kunt zien, is CustDemographic Table aanwezig in het doelsysteem en niet in het bronsysteem.
  • Het veld CustomerType in de tabel Klanten bevat alleen gegevens in het bronsysteem en niet in het doelsysteem.

dart (gegevensnauwkeurigheid)

# 3) Gegevensnauwkeurigheid

Zoals de naam doet vermoeden, valideren we of de gegevens logisch correct zijn. Er zijn twee categorieën voor dit type test. Hiermee kan de tester de datakwaliteitsproblemen zelfs in het bronsysteem opvangen.

Data-integriteit

(beeld bron ​

Notitie: Voer deze test uit in het doelsysteem en controleer in het bronsysteem op eventuele defecten.

(i) Niet-numeriek type: Onder deze classificatie verifiëren we de juistheid van de niet-numerieke inhoud. Voorbeelden zijn e-mails, pincodes, telefoon in een geldig formaat.

(ii) Domeinanalyse: Bij dit type test kiezen we gegevensdomeinen en valideren we op fouten. Hiervoor zijn er drie groepen:

  • Gebaseerd op waarde: Hier maken we een lijst met waarden die voor een veld kunnen voorkomen (kolom in de tabel). Controleer vervolgens of de kolomwaarden een subset van onze lijst zijn.
    • Voorbeeld: Controleer of de kolom Geslacht ofwel M of F bevat.
  • Gebaseerd op bereik: Hier stellen we minimum en maximum bereik in voor geldige datawaarden voor een kolom, op basis van logische of zakelijke redeneringen. We valideren vervolgens of de kolomwaarden binnen dit bereik vallen.
    • Voorbeeld: 0 tot 120 voor leeftijd.
  • Referentiebestand : Hier gebruikt het systeem een ​​extern validiteitsbestand.
    • Voorbeeld: Zijn landcodes geldig, kiezen ze de juiste waarde uit het referentiebestand, zijn landcodes hetzelfde tussen QA en de productieomgeving? Als het referentiebestand een update van een landcode had, is het dan terecht bijgewerkt in DB?

# 4) Metadata-validatie

Bij Metadata-validatie valideren we dat de tabel- en kolomdatatypedefinities voor het doel correct zijn ontworpen, en eenmaal ontworpen, worden ze uitgevoerd volgens de ontwerpspecificaties van het datamodel.

Er zijn hier twee groepen:

verschil tussen port forward en port trigger

(i) Metadata-ontwerp: De eerste controle is om te valideren dat het datamodel correct is ontworpen volgens de zakelijke vereisten voor de doeltabellen. Gegevensarchitecten kunnen schema-entiteiten migreren of kunnen wijzigingen aanbrengen bij het ontwerpen van het doelsysteem.

De volgende controle zou moeten zijn om te valideren dat de juiste scripts zijn gemaakt met behulp van de datamodellen.

Voor elke onderstaande categorie verifiëren we eerst of de metadata die voor het doelsysteem zijn gedefinieerd, voldoen aan de zakelijke vereisten en ten tweede of de tabellen en velddefinities correct zijn gemaakt.

Enkele van de metadatacontroles worden hieronder gegeven:

  • Gegevenstype controleren: Voorbeeld: Werkt Total Sales correct met decimaal (8, 16 of 20 bytes) of dubbel type?
  • Controle gegevenslengte ​ Voorbeeld: Is de datalengte voor het adresveld voldoende met 500 tekens? Het kan een geval zijn waarin datamigratie wordt uitgevoerd naarmate er nieuwe geografie aan het bedrijf wordt toegevoegd. De adressen van de nieuwe geografie kunnen een buitengewoon lang formaat hebben en het vasthouden aan de oorspronkelijke lengte kan een use-case veroorzaken.
  • Indexcontrole: Voorbeeld: Wordt er geïndexeerd voor de OrderId-kolom in het doelsysteem? Wat als er een fusie van bedrijven plaatsvindt, waardoor datamigratie nodig is en de ordertabel 100 keer groter wordt in het doelsysteem?
  • Metagegevenscontrole in verschillende omgevingen: Controleer onder deze controle of de metagegevens overeenkomen tussen de QA-test en de productieomgeving. Tests kunnen slagen in de QA-omgeving, maar mislukken in andere omgevingen.

(ii) Delta-verandering: Deze tests brengen defecten aan het licht die optreden wanneer het project wordt uitgevoerd en halverwege zijn er wijzigingen in de metadata van het bronsysteem die niet zijn geïmplementeerd in doelsystemen.

Voorbeeld: Nieuw veld CSI (Customer Satisfaction Index) is toegevoegd aan de klantentabel in de bron, maar kan niet worden gemaakt in het doelsysteem.

# 5) Gegevensintegriteit

Hier valideren we voornamelijk de integriteitsbeperkingen zoals Foreign key, Primary key reference, Unique, Default, etc.

bovenliggende tafel

(beeld bron ​

Voor externe sleutels moeten we controleren of er weesrecords in de onderliggende tabel staan ​​waar de gebruikte externe sleutel niet aanwezig is in de bovenliggende tabel.

Controle op volledigheid van gegevens

Voorbeeld: De klantentabel heeft CustomerID, een primaire sleutel. De besteltabel heeft CustomerID als een externe sleutel. De besteltabel heeft mogelijk een CustomerID die niet in de tabel Klanten staat. We hebben tests nodig om dergelijke schendingen van integriteitsbeperkingen aan het licht te brengen. De Data Mapping-tabel geeft u duidelijkheid over welke tabellen deze beperkingen hebben.

Notitie: Voer deze test uit in het doelsysteem en controleer in het bronsysteem of er defecten zijn.

# 6) Gegevensvolledigheid

Dit zijn gezondheidstests die ontbrekende records of rijen tellen tussen de bron- en doeltabel blootleggen en die na automatisering vaak kunnen worden uitgevoerd.

Er zijn twee soorten tests:

(i) Aantal records: Hier vergelijken we het totale aantal records voor het matchen van tabellen tussen bron- en doelsysteem. Dit is een snelle gezondheidscontrole om te controleren of de ETL- of migratietaak is uitgevoerd. We hebben een defect als de tellingen niet overeenkomen.

Soms worden er afgewezen records tijdens het uitvoeren van een taak. Sommige hiervan zijn mogelijk geldig. Maar als tester maken we hier een case-point voor.

(ii) Profilering van kolomgegevens: Dit type geestelijke gezondheidstest is waardevol wanneer het aantal records enorm is. Hier maken we logische gegevenssets die het aantal records verminderen en maken we vervolgens een vergelijking tussen de bron en het doel.

  • Filter waar mogelijk alle unieke waarden in een kolom, bijvoorbeeld, ProductID komt mogelijk meerdere keren voor in de tabel OrderDetails. Kies een unieke lijst voor ProductID uit zowel doel- als brontabellen en valideer. Dit vermindert het aantal records aanzienlijk en versnelt gezondheidstests.
  • Net als de bovenstaande tests kunnen we ook alle hoofdkolommen kiezen en controleren of de KPI's (minimum, maximum, gemiddelde, maximum of minimum lengte, enz.) Overeenkomen tussen doel- en brontabel. Voorbeeld: Neem gemiddelde, minimum- en maximumwaarden uit de kolom Prijs in OrderDetails en vergelijk deze waarden tussen doel- en brontabellen voor mismatches.
  • Een andere controle kan worden gedaan voor Null-waarden. Kies belangrijke kolommen en filter een lijst met rijen uit waarin de kolom Null-waarden bevat. Vergelijk deze rijen tussen het doel- en bronsysteem voor de mismatch.

Tijdlijnen

# 7) Gegevenstransformatie

Deze tests vormen de kerntests van het project. Bekijk het document met vereisten om de transformatievereisten te begrijpen. Bereid testgegevens voor in de bronsystemen om verschillende transformatiescenario's weer te geven. Deze hebben een groot aantal tests en moeten in detail worden behandeld onder ETL-testonderwerpen.

Hieronder vindt u een beknopte lijst met tests die hieronder vallen:

(i) Transformatie:

  • Voorbeeld: ETL-code kan logica hebben om ongeldige gegevens te weigeren. Verifieer deze aan de hand van de vereisten.
  • ETL-code kan ook logica bevatten om automatisch bepaalde sleutels te genereren, zoals surrogaatsleutels. We hebben tests nodig om de juistheid (technisch en logisch) hiervan te verifiëren.
  • Valideer de juistheid van het samenvoegen of splitsen van veldwaarden nadat een ETL- of migratietaak is voltooid.
  • Zorg voor tests om referentiële integriteitscontroles te verifiëren. Bijvoorbeeld, een type defect kan ProductId zijn dat wordt gebruikt in de tabel Bestellingen, is niet aanwezig in de bovenliggende tabel Producten. Laat een test uitvoeren om te controleren hoe de weesrecords zich gedragen tijdens een ETL-taak.
  • Soms worden ontbrekende gegevens ingevoegd met behulp van de ETL-code. Controleer de juistheid hiervan.
  • ETL- of migratiescripts hebben soms logica om gegevens te corrigeren. Controleer of gegevenscorrectie werkt.
  • Controleer of ongeldige / afgewezen / foutieve gegevens aan gebruikers worden gerapporteerd.
  • Maak een spreadsheet met scenario's van invoergegevens en verwachte resultaten en valideer deze met de zakelijke klant.

(ii) Edge-gevallen: Controleer of de transformatielogica goed is voor de grenzen.

  • Voorbeeld: Wat gebeurt er als TotalSales met een waarde van 1 biljoen een ETL-taak doorloopt? Werkt de end-to-end-zaak? Identificeer velden die mogelijk grote waarden kunnen hebben en voer tests uit met deze grote waarden. Ze moeten numerieke en niet-numerieke waarden bevatten.
  • Voor datumvelden, inclusief het volledige bereik van verwachte datums - schrikkeljaren, 28/29 dagen voor februari. 30, 31 dagen voor andere maanden.

# 8) Uniciteit of duplicatie van gegevens

Identificeer bij dit type test kolommen die unieke waarden moeten hebben volgens het gegevensmodel. Houd ook rekening met de bedrijfslogica om dergelijke gegevens te verwijderen. Voer tests uit om te controleren of ze uniek zijn in het systeem. Voer vervolgens tests uit om de daadwerkelijke duplicaten te identificeren.

  • Voorbeeld: Filter op dubbele gegevens en controleer of deze authentiek zijn. Bijvoorbeeld, Een werknemerafhankelijk record bevat twee keer dezelfde gegevens op hetzelfde niveau.
  • Het telefoonnummer van de gebruiker moet uniek zijn in het systeem (zakelijke vereisten).
  • De zakelijke vereiste zegt dat een combinatie van ProductID en ProductName in de tabel Producten uniek moet zijn, aangezien Productnaam duplicaat kan zijn.

# 9) Verplicht

Identificeer bij dit type test alle velden die zijn gemarkeerd als Verplicht en valideer of verplichte velden waarden hebben. Als er standaardwaarden zijn gekoppeld aan een veld in DB, controleer dan of het correct is ingevuld als er geen gegevens zijn.

  • Voorbeeld: Als BillDate niet is ingevoerd, is CurrentDate de BillDate.

# 10) Tijdigheid

Documenteer altijd tests die verifiëren dat u werkt met gegevens uit de afgesproken tijdlijnen.

  • Voorbeeld: ProductDiscount is 15 dagen geleden bijgewerkt en in het bedrijfsdomein wordt ProductDiscount elke zeven dagen gewijzigd. Dit betekent dat uw tests niet worden uitgevoerd met de juiste kortingswaarden.
  • Een voorspellend analyserapport voor de klanttevredenheidsindex moest werken met de gegevens van de laatste week, wat een verkooppromotieweek was bij Walmart. Maar de ETL-taak was ontworpen om met een frequentie van 15 dagen te worden uitgevoerd. Dit is een groot defect dat testers kunnen ontdekken.

# 11) Null-gegevens

Bij dit type test richten we ons op de geldigheid van null-gegevens en verificatie dat de belangrijke kolom niet null kan zijn.

  • Voorbeeld: Filter alle null-gegevens en valideer of null is toegestaan.
  • Als er belangrijke kolommen zijn voor zakelijke beslissingen, zorg er dan voor dat null-waarden niet aanwezig zijn.

# 12) Bereikcontrole

Gegevensentiteit waar bereiken zakelijk zinvol zijn, moeten worden getest.

  • Voorbeeld: De bestelhoeveelheid per factuur mag niet meer zijn dan 5K in de softwarecategorie.
  • De leeftijd mag niet hoger zijn dan 120.

# 13) Bedrijfsregels

Documenteer alle zakelijke vereisten voor velden en voer tests uit voor hetzelfde.

  • Voorbeeld: Middelen met een leeftijd jonger dan 20 jaar komen niet in aanmerking. Controles van gegevensvalidatie zijn vereist als deze regel op de gegevens wordt toegepast.
  • De beëindigingsdatum moet null zijn als de status Werknemer actief is Waar / Overleden.
  • FROM-gegevens moeten kleiner zijn dan TO-datum.
  • Voeg inkoopbedragen op artikelniveau toe aan bedragen op orderniveau

# 14) Geaggregeerde functies

Geaggregeerde functies zijn ingebouwd in de functionaliteit van de database. Documenteer alle aggregaten in het bronsysteem en controleer of het geaggregeerde gebruik dezelfde waarden oplevert in het doelsysteem (som, max, min, aantal).

Vaak verschillen de tools op het bronsysteem van het doelsysteem. Controleer of beide tools aggregatiefuncties op dezelfde manier uitvoeren.

# 15) Afkappen en afronden van gegevens

Bij dit soort tests identificeren we velden met afkappings- en afrondingslogica met betrekking tot het bedrijf. Vervolgens documenteren we de afkortings- en afrondingslogica met producteigenaren en testen we ze met productievertegenwoordige gegevens.

# 16) Coderingstests

Controleer of er gecodeerde waarden zijn in het bronsysteem en controleer of de gegevens correct zijn ingevuld door de ETL- of gegevensmigratietaak in het doelsysteem te plaatsen.

  • Voorbeeld: Dubbelbyte tekens voor voornaam in het Chinees werden geaccepteerd in het bronsysteem dat werd gecodeerd. Controleer het gedrag van dit veld wanneer het naar het doelsysteem wordt verplaatst.
  • Het wachtwoordveld is gecodeerd en gemigreerd. Zorg ervoor dat ze na de migratie goed werken.

# 17) Regressietests

Dit is een basistestconcept waarbij testers al hun kritieke testcase-suite uitvoeren die is gegenereerd met behulp van de bovenstaande checklist en een wijziging in het bron- of doelsysteem plaatsen.

Gevolgtrekking

We hebben dus gezien dat datavalidatie een interessant gebied is om te verkennen voor data-intensieve projecten en dat het de belangrijkste tests vormt. Het datamapping-blad is een cruciaal artefact dat testers moeten behouden om succes te behalen met deze tests. Ze kunnen meerdere versies met kleuraccenten onderhouden om input te vormen voor een van de bovenstaande tests.

Er moet voor worden gezorgd dat de deltawijzigingen tussen versies behouden blijven.

We vragen lezers om andere delen van de test die ze tijdens hun werk zijn tegengekomen te delen, ten voordele van de testgemeenschap.

Aanbevolen literatuur

^