ETL test vejledning

Hvad er ETL?

ETL står for Extract-Transform-Load, og den beskriver, hvordan data flyttes fra et kildesystem til et datalager. Data er ekstrachentet fra en OLTP-database, transformeret til at matche data warehouse-skemaet og indlæst i warehouse-databasen. Mange warehouses inkorporerer også data fra ikke-OLTP-systemer såsom tekstfiler, ældre applikationer og regneark.

For eksempel kan en detailbutik have separate afdelinger såsom salg, marketing og logistik. Hver afdeling håndterer kundeoplysninger uafhængigt, og den måde, hvorpå hver enkelt opbevarer disse data, er forskellig. Salgsafdelingen kan opbevare poster efter kundenavn, mens marketingafdelingen bruger kunde-ID.

Hvis forretningsteams ønsker at gennemgå en kundes fulde købshistorik på tværs af forskellige marketingkampagner, gør de usammenhængende data det meget besværligt. Løsningen er at bruge en datawarehouse at gemme information fra forskellige kilder i en ensartet struktur ved hjælp af ETL. ETL kan omdanne forskellige datasæt til en samlet struktur, så BI-værktøjer senere kan udlede meningsfuld indsigt og rapporter.

Følgende diagram viser ETL-testprocesflowet og de kernekoncepter, du vil bruge i hele denne vejledning:

1) Eks.tract

• Extracrelevante data fra et eller flere kildesystemer.

2) Transformér

• Transformer data til DW (Data Warehouse) format.
• Byggenøgler: En nøgle er en eller flere dataattributter, der entydigt identificerer en enhed. Forskellige typer af nøgler er primærnøgle, alternativnøgle, fremmednøgle, sammensatnøgle og surrogatnøgle. Datalageret ejer disse nøgler og tillader aldrig nogen anden enhed at tildele dem.
• Rensning af data: efter dataene er blevet fjernettracNår den er blevet opdateret, går den videre til den næste fase med rensning og tilpasning. Rensning retter mangler og identificerer fejl. Tilpasning løser konflikter mellem inkompatible datasæt, så de kan bruges i et virksomhedsdatalager. Systemet opretter også metadata, der hjælper med at diagnosticere problemer med kildesystemet og forbedre datakvaliteten.

3) Indlæs

• Indlæs data i DW'en (datalageret).
• Opbyg aggregater: et aggregat opsummerer og lagrer data fra en faktatabel for at forbedre ydeevnen af ​​slutbrugerforespørgsler.

Hvad er ETL-testning?

ETL-testning udføres for at sikre, at data, der indlæses fra en kilde til en destination efter forretningstransformation, er nøjagtige. Det involverer også verifikation af data på de forskellige mellemtrin mellem kilde og destination. Fordi ETL står for Extract-Transform-Load, ETL-testning dækker hvert af disse tre stadier og de punkter, hvor data krydser mellem dem.

Hvorfor er ETL-testning vigtig?

Når du forstår, hvad ETL-testning er, er det næste spørgsmål, hvorfor organisationer investerer så meget energi i det. Forretningsbeslutninger er afhængige af data, der er korrekte, komplette og troværdige, så en enkelt transformationsfejl kan påvirke finansielle rapporter, kundeanalyser og lovgivningsmæssige oplysninger.

Følgende punkter forklarer den praktiske værdi af stærk ETL-testning:

• Datanøjagtighed: Det bekræfter, at værdier, der er transformeret af forretningsregler, matcher det dokumenterede kortping specifikationer, hvilket forhindrer stille korruption.
• Pålidelig rapportering: Dashboards og BI-værktøjer afhænger af lageret, så verificerede ETL-pipelines beskytter alle downstream-rapporter og KPI'er.
• Overholdelse af lovgivningen: Brancher som bankvæsen, sundhedsvæsen og forsikring skal bevise, at dataafstamning og -integritet bevares fra start til slut.
• Reduceret omarbejde: Ved at opdage fejl i lavere miljøer undgår man dyre produktionsgenindlæsninger, manuelle afstemninger og kundevendte fejl.
• Ydelsessikring: ETL-testning måler indlæsningsvinduer, gennemløb og flaskehalse, så lageret fortsætter med at skalere i takt med at datamængden vokser.

Med disse motivationer klare, gennemgår næste afsnit den strukturerede proces, som ETL-testere følger på virkelige projekter.

ETL testproces

Ligesom andre testprocesser gennemgår ETL også forskellige faser. De forskellige faser i ETL-testprocessen er som følger:

ETL-testning udføres i fem faser:

1. Identifikation af datakilder og krav
2. Dataopsamling
3. Implementer forretningslogik og dimensionsmodellering
4. Opbyg og udfyld data
5. Opbyg rapporter

Med den overordnede proces i tankerne, lad os se på de specifikke testtyper, der passer ind i denne livscyklus.

Typer af ETL-testning

1. Produktionsvalideringstest
   Testproces: Denne type ETL-testning, også kaldet "tabelbalancering" eller "produktionsafstemning", udføres på data, når de overføres til produktionssystemer. For at understøtte forretningsbeslutninger skal produktionsdata være i den korrekte rækkefølge. computer Data Validation Option giver automatisering og administration af ETL-test, så produktionssystemer ikke kompromitteres af forkerte data.
2. Kilde til Target Test (valideringstest)
   Testproces: Denne type testning validerer, om de transformerede dataværdier stemmer overens med de forventede målværdier.
3. Anvendelse Upgrades
   Testproces: Denne type ETL-testning kan genereres automatisk, hvilket sparer betydelig testudviklingstid. Den kontrollerer, om data eks.tracdata fra en ældre applikation eller et arkiv matcher dataene i en ny applikation eller et nyt arkiv.
4. Metadata test
   Testproces: Metadatatestning omfatter datatypekontroller, datalængdekontroller og indeks- eller begrænsningskontroller.
5. Test af datafuldstændighed
   Testproces: Datafuldstændighedstest verificerer, at alle forventede data indlæses fra kilden til målet. Almindelige tests omfatter sammenligning og validering af postantal, aggregater og faktiske data mellem kilde- og målkolonner, når transformationen er enkel eller mangler.
6. Test af datanøjagtighed
   Testproces: Denne testning sikrer, at dataene indlæses og transformeres nøjagtigt som forventet.
7. Test af datatransformation
   Testproces: Transformation af testdata kan ofte ikke opnås med en enkelt kilde SQL forespørgsel og en outputsammenligning. Flere SQL-forespørgsler kan være nødvendige for hver række for at verificere transformationsreglerne.
8. Test af datakvalitet
   Testproces:

   Datakvalitetstest omfatter syntakstest og referencetest. De forhindrer fejl i forretningsprocesser forårsaget af forkerte datoer eller ordrenumre.

   Syntakstests rapporterer ukorrekte data baseret på ugyldige tegn, tegnmønstre og forkert rækkefølge af store eller små bogstaver.

   Referencetests kontrollerer dataene i forhold til datamodellen. For eksempel: Kunde-ID.

   Datakvalitetstest omfatter også taltjek, datotjek, præcisionstjek, datatjek og nultjek.

9. Inkrementel ETL-test
   Testproces: Denne test kontrollerer dataintegriteten af ​​gamle og nye data med tilføjelse af nye data. Trinvis testning verificerer, at indsættelser og opdateringer behandles som forventet under den trinvise ETL-proces.
10. GUI/navigationstest
    Testproces: Denne test kontrollerer navigations- og GUI-aspekterne af frontend-rapporterne.

Sådan opretter du ETL-testcase

ETL-testning er et koncept, der kan anvendes på forskellige værktøjer og databaser i informationsstyringsbranchen. Formålet med ETL-testning er at sikre, at data, der indlæses fra en kilde til en destination efter en forretningstransformation, er nøjagtige. Det involverer også verifikation af data på de forskellige mellemtrin mellem kilde og destination.

Når en ETL-tester udfører ETL-testning, bruger han altid to dokumenter:

1. ETL-kortping ark: Et ETL-kortping Arket indeholder alle oplysninger om kilde- og destinationstabeller, inklusive hver kolonne og dens opslag i referencetabeller. ETL-testere skal være fortrolige med SQL-forespørgsler, fordi ETL-testning kan involvere at skrive store forespørgsler med flere joins for at validere data på ethvert tidspunkt. ETL-kortping Sheets giver betydelig hjælp, når man skriver forespørgsler til dataverifikation.
2. DB-skema for kilde og mål: Den bør opbevares ved hånden for at verificere eventuelle detaljer på kortet.ping ark.

ETL testscenarier og testcases

1. Kortping dokumentvalidering
   Testtilfælde: Bekræft, om de tilsvarende ETL-oplysninger er angivet på kortetping dok. Der bør føres en ændringslog i hvert kortping dok.
2. Validering
   Testtilfælde:

   1) Valider kilde- og måltabelstrukturen mod det tilsvarende kortping dok.
   2) Kildedatatypen og måldatatypen skal være den samme.
   3) Længden af ​​datatyper i både kilde og mål skal være den samme.
   4) Bekræft at datafelttyper og -formater er angivet.
   5) Kildedatatypens længde må ikke være kortere end måldatatypens længde.
   6) Valider navnene på kolonnerne i tabellen mod kortetping dok.

3. Begrænsningsvalidering
   Testtilfælde: Sørg for, at begrænsninger er defineret for den specifikke tabel som forventet.
4. Problemer med datakonsistens
   Testtilfælde:

   1) Datatypen og længden for en bestemt attribut kan variere på tværs af filer eller tabeller, selv når den semantiske definition er den samme.
   2) Misbrug af integritetsbegrænsninger.

5. Fuldstændighedsproblemer
   Testtilfælde:

   1) Sørg for, at alle forventede data er indlæst i måltabellen.
   2) Sammenlign antallet af poster mellem kilde og mål.
   3) Tjek for eventuelle afviste optegnelser.
   4) Kontroller, at data ikke er afkortet i kolonnerne i måltabellerne.
   5) Kontroller randværdianalysen.
   6) Sammenlign unikke værdier af nøglefelter mellem data indlæst i lageret og kildedataene.

6. Korrekthedsproblemer
   Testtilfælde:

   1) Data, der er stavet forkert eller registreret unøjagtigt.
   2) Nul-, ikke-unikke eller data uden for intervallet.

7. Transformation
   Testtilfælde: Valider at alle forretningsregler og transformationslogik i kortetping dokumentet anvendes korrekt på kildedataene, før det lander i målet.
8. Datakvalitet
   Testtilfælde:

   1) Nummerkontrol: valider numeriske formater og værdier.
   2) Datokontrol: Datoer skal følge et enkelt format og være ensartede på tværs af poster.
   3) Præcisionskontrol.
   4) Datatjek.
   5) Nulkontrol.

9. Nul validering
   Testtilfælde: Bekræft null-værdierne, hvor "Ikke nul" er angivet for en bestemt kolonne.
10. Duplikatcheck
    Testtilfælde:

    1) Valider den unikke nøgle, primære nøgle og enhver anden kolonne, der skal være unik i henhold til forretningskrav, for at bekræfte, at der ikke er nogen dubletter af rækker.
    2) Tjek om der findes dubletter i nogen kolonne, f.eks.tracfra flere kildekolonner og kombineret i én kolonne.
    3) Sørg for, at der ikke findes dubletter i en kombination af flere kolonner i målet, i henhold til klientens krav.

11. Datovalidering
    Testtilfælde: Datoværdier bruges i mange områder af ETL-udvikling:

    1) At kende rækkens oprettelsesdato.
    2) Identificer aktive poster fra ETL-udviklingsperspektivet.
    3) Identificer aktive poster ud fra et forretningskravsperspektiv.
    4) Nogle gange genereres der opdateringer og indsættelser baseret på datoværdierne.

12. Fuldstændig datavalidering
    Testtilfælde:

    1) Valider det komplette datasæt i kilde- og måltabellerne ved hjælp af en minusforespørgsel som den bedste løsning.
    2) Du skal udføre kilde minus mål og mål minus kilde.
    3) Hvis minus-forespørgslen returnerer en værdi, skal disse rækker betragtes som uoverensstemmelser.
    4) Match rækker mellem kilde og mål ved hjælp af en intersect-sætning.
    5) Det antal, der returneres af intersect, skal matche de individuelle antal i kilde- og måltabellerne.
    6) Hvis en minusforespørgsel returnerer rækker, og antallet af skæringspunkter er mindre end antallet af kilde- eller målrækker, findes der duplikerede rækker.

13. Data renhed
    Testtilfælde: Unødvendige kolonner skal slettes, før de indlæses i mellemrumsområdet.

Typer af ETL-fejl

Selv med stærke testtilfælde kan ETL-pipelines fejle på forskellige måder. Billedet nedenfor opsummerer de fejlkategorier, du skal være opmærksom på, og tabellen nedenfor beskriver hver enkelt.

Type af fejl	Beskrivelse
Brugergrænsefladefejl/kosmetiske fejl	• Relateret til applikationens brugergrænseflade • Skrifttype, skriftstørrelse, farver, justering, stavefejl, navigation og så videre
Boundary Value Analysis (BVA) relateret fejl	• Minimums- og maksimumsværdier
Equivalence Class Partitioning (ECP) relateret fejl	• Gyldig og ugyldig type
Input/output fejl	• Gyldige værdier accepteres ikke • Ugyldige værdier accepteret
Beregningsfejl	• Matematiske fejl • Det endelige output er forkert
Indlæs tilstandsfejl	• Tillader ikke flere brugere • Tillader ikke kundens forventede belastning
Race Condition fejl	• Systemnedbrud og hængning • Systemet kan ikke køre klientplatforme
Fejl i versionskontrol	• Ingen logomatchning • Ingen versionsoplysninger tilgængelige • Forekommer normalt i Regressionstest
H/W fejl	• Enheden svarer ikke på applikationen
Hjælp Kilde fejl	• Fejl i hjælpedokumenter

Test af datavarehus

Test af datavarehus er en testmetode, hvor dataene i et datawarehouse testes for integritet, pålidelighed, nøjagtighed og konsistens for at overholde virksomhedens datarammeværk. Hovedformålet med datawarehouse-testning er at sikre, at de integrerede data i warehouset er pålidelige nok til, at virksomheden kan træffe beslutninger på baggrund af dem. Mens ETL-testning fokuserer på dataflytning, dækker Datawarehouse-testning det bredere lagrings- og rapporteringslag, som ETL i sidste ende forsyner.

Forskellen mellem databasetest og ETL test

Selvom begge discipliner arbejder med strukturerede data, besvarer de forskellige spørgsmål. Tabellen nedenfor fremhæver den praktiske kontrast:

ETL test	Database test
Bekræfter, om data flyttes som forventet.	Det primære mål er at kontrollere, om dataene følger de regler og standarder, der er defineret i datamodellen.
Verificerer, om antallet i kilden og målet stemmer overens, og at de transformerede data er som forventet.	Bekræfter, at der ikke er nogen forældreløse poster, og at relationer mellem fremmed og primær nøgle opretholdes.
Verificerer, at relationer mellem fremmede primære nøgler bevares under ETL'en.	Bekræfter, at der ikke er nogen redundante tabeller, og at databasen er optimalt normaliseret.
Verificerer for duplikering i indlæste data.	Kontrollerer, om der mangler data i kolonner, hvor det er nødvendigt.

Ydelsestest i ETL

Ydelsestest i ETL er en testteknik, der sikrer, at et ETL-system kan håndtere belastningen fra flere brugere og transaktioner. Det primære mål med ETL Test af ydeevne er at optimere og forbedre sessionsydelsen ved at identificere og eliminere flaskehalse i ydeevnen. Kilde- og måldatabaserne, kortpings, sessioner og selve systemet kan alle indeholde flaskehalse.

Et af de bedste værktøjer, der bruges til performancetest og -tuning, er Informatica.

Ansvar for en ETL Tester

En ETL-tester har hovedansvaret for at være opdelt i tre kategorier:

• Scenebord / SFS eller MFS
• Forretningstransformationslogik anvendt
• Target Tabelindlæsning fra stagefil eller tabel efter anvendelse af en transformation

Nogle af de daglige opgaver for en ETL-tester er:

• Test ETL software
• Testkomponenter i ETL-datalageret
• Udfør backend-datadrevne tests
• Skab, design og udfør test tilfælde, testplaner og testudstyr
• Identificer problemer og giv løsninger på potentielle problemer
• Godkend krav og designspecifikationer
• Valider dataoverførsler og test flade filer
• Skriv SQL-forespørgsler til forskellige scenarier, såsom tælletests

Automatisering af ETL-test

Den generelle metode til ETL-testning er at bruge SQL-scripting eller visuel "øjenanalyse" af data. Disse tilgange er tidskrævende, fejlbehæftede og giver sjældent komplette resultater. test dækningFor at fremskynde udførelsen, forbedre dækningen, reducere omkostningerne og forbedre defekt detektion i produktions- og udviklingsmiljøer, automatisering er et vigtigt behov. Et sådant værktøj er Informatica.

Moderne teams blander også traditionel automatisering med AI-assisterede hjælpere, der foreslår transformationstests, genererer syntetiske kildedata og markerer skemaafvigelser, hvilket frigør testere til at fokusere på kompleks forretningslogik i stedet for gentagen scriptvedligeholdelse.

Bedste praksis for ETL-testning

1. Sørg for, at dataene transformeres korrekt.
2. Projicerede data bør indlæses i datalageret uden datatab eller afkortning.
3. Sørg for, at ETL-applikationen afviser ugyldige data på korrekt vis, erstatter dem med standardværdier, hvor det er relevant, og rapporterer dem.
4. Bekræft, at data indlæses i lageret inden for de foreskrevne og forventede tidsrammer for at validere skalerbarhed og ydeevne.
5. Alle metoder bør have passende enhedstests uanset synlighed.
6. For at måle deres effektivitet bør alle enhedstests anvende passende dækningsteknikker.
7. Stræb efter én påstand per testcase.
8. Opret enhedstest der er rettet mod undtagelser.

Kasse - ETL Test Interview Spørgsmål & Svar

Ofte Stillede Spørgsmål