ETL-testveiledning

Hva 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, transformert for å samsvare med datavarehusskjemaet og lastet inn i varehusdatabasen. Mange varehus inneholder også data fra ikke-OLTP-systemer, for eksempel tekstfiler, eldre applikasjoner og regneark.

For eksempel kan en butikk ha separate avdelinger som salg, markedsføring og logistikk. Hver avdeling håndterer kundeinformasjon uavhengig, og måten hver enkelt lagrer disse dataene på er forskjellig. Salgsavdelingen kan lagre poster etter kundenavn, mens markedsføringsavdelingen bruker kunde-ID.

Hvis forretningsteam ønsker å gjennomgå hele kjøpshistorikken til en kunde på tvers av ulike markedsføringskampanjer, gjør de frakoblede dataene det veldig kjedelig. Løsningen er å bruke en Datavarehus å lagre informasjon fra ulike kilder i en enhetlig struktur ved hjelp av ETL. ETL kan transformere ulike datasett til en enhetlig struktur, slik at BI-verktøy senere kan utlede meningsfull innsikt og rapporter.

Følgende diagram viser ETL-testingsprosessflyten og kjernekonseptene du vil bruke gjennom hele denne veiledningen:

1) Eks.tract

• Extracrelevante data fra ett eller flere kildesystemer.

2) Forvandle

• Transformer data til DW-format (datavarehus).
• Byggenøkler: en nøkkel er ett eller flere dataattributter som unikt identifiserer en enhet. Ulike typer nøkler er primærnøkkel, alternativnøkkel, fremmednøkkel, sammensatt nøkkel og surrogatnøkkel. Datavarehuset eier disse nøklene og tillater aldri noen annen enhet å tildele dem.
• Rensing av data: etter at dataene er ekskluderttracEtter ted går den videre til neste fase med rengjøring og samsvar. Rensingen retter opp mangler og identifiserer feil. Samsvar løser konflikter mellom inkompatible datasett, slik at de kan brukes i et datalager for bedriften. Systemet oppretter også metadata som bidrar til å diagnostisere problemer med kildesystemet og forbedre datakvaliteten.

3) Last

• Last inn data i DW (datavarehuset).
• Bygg aggregater: et aggregat oppsummerer og lagrer data fra en faktatabell for å forbedre ytelsen til sluttbrukerforespørsler.

Hva er ETL-testing?

ETL-testing utføres for å sikre at dataene som lastes inn fra en kilde til en destinasjon, etter forretningstransformasjon, er nøyaktige. Det innebærer også verifisering av data på de ulike mellomstadiene mellom kilde og destinasjon. Fordi ETL står for Extract-Transform-Load, ETL-testing dekker hvert av disse tre stadiene og punktene der data krysser mellom dem.

Hvorfor er ETL-testing viktig?

Når du forstår hva ETL-testing er, er det neste spørsmålet hvorfor organisasjoner legger så mye arbeid i det. Forretningsbeslutninger er avhengige av data som er korrekte, fullstendige og pålitelige, så en enkelt transformasjonsfeil kan påvirke økonomiske rapporter, kundeanalyser og regulatoriske opplysninger.

Følgende punkter forklarer den praktiske verdien av sterk ETL-testing:

• Datanøyaktighet: Den bekrefter at verdier transformert av forretningsregler samsvarer med det dokumenterte kartetping spesifikasjoner, som forhindrer stille korrupsjon.
• Pålitelig rapportering: Dashboards og BI-verktøy er avhengige av lageret, så verifiserte ETL-pipelines beskytter alle nedstrømsrapporter og KPI-er.
• Overholdelse av regelverk: Bransjer som bank, helsevesen og forsikring må bevise at dataavstamning og integritet bevares fra ende til annen.
• Redusert omarbeid: Å fange opp feil i lavere miljøer unngår kostbare produksjonspåfyllinger, manuelle avstemminger og kundevendte feil.
• Ytelsessikring: ETL-testing måler lastevinduer, gjennomstrømning og flaskehalser, slik at lageret fortsetter å skaleres etter hvert som datavolumet vokser.

Med disse motivasjonene klare, går neste avsnitt gjennom den strukturerte prosessen som ETL-testere følger på virkelige prosjekter.

ETL testprosess

I likhet med andre testprosesser går ETL også gjennom forskjellige faser. De forskjellige fasene i ETL-testprosessen er som følger:

ETL-testing utføres i fem trinn:

1. Identifisere datakilder og krav
2. Datainnsamling
3. Implementer forretningslogikk og dimensjonsmodellering
4. Bygg og fyll ut data
5. Bygg rapporter

Med tanke på prosessen på overordnet nivå, la oss se på de spesifikke testtypene som passer inn i denne livssyklusen.

Typer ETL-testing

1. Produksjonsvalideringstesting
   Testprosess: Denne typen ETL-testing, også kalt «tabellbalansering» eller «produksjonsavstemming», utføres på data når de flyttes inn i produksjonssystemer. For å støtte forretningsbeslutninger må produksjonsdata være i riktig rekkefølge. Informatikk Data Validation Option tilbyr automatisering og administrasjon av ETL-testing, slik at produksjonssystemer ikke kompromitteres av dårlige data.
2. Kilde til Target Testing (valideringstesting)
   Testprosess: Denne typen testing validerer om de transformerte dataverdiene samsvarer med de forventede målverdiene.
3. Søknad Upgrades
   Testprosess: Denne typen ETL-testing kan genereres automatisk, noe som sparer betydelig tid for testutvikling. Den sjekker om data eks.tracdata fra et eldre program eller arkiv samsvarer med dataene i et nytt program eller arkiv.
4. Metadatatesting
   Testprosess: Metadatatesting inkluderer datatypekontroller, datalengdekontroller og indeks- eller begrensningskontroller.
5. Testing av datafullstendighet
   Testprosess: Datafullstendighetstesting bekrefter at alle forventede data lastes inn fra kilden til målet. Vanlige tester inkluderer sammenligning og validering av antall poster, aggregeringer og faktiske data mellom kilde- og målkolonner når transformasjonen er enkel eller fraværende.
6. Datanøyaktighetstesting
   Testprosess: Denne testingen sikrer at dataene lastes inn og transformeres nøyaktig som forventet.
7. Testing av datatransformasjon
   Testprosess: Transformasjon av testdata kan ofte ikke oppnås med én enkelt kilde SQL spørring og en sammenligning av utdata. Det kan være nødvendig med flere SQL-spørringer for hver rad for å bekrefte transformasjonsreglene.
8. Datakvalitetstesting
   Testprosess:

   Datakvalitetstester inkluderer syntakstester og referansetester. De forhindrer feil i forretningsprosesser forårsaket av feil datoer eller ordrenumre.

   Syntakstester rapporterer ugyldige data basert på ugyldige tegn, tegnmønstre og feil rekkefølge for store eller små bokstaver.

   Referansetester sjekker dataene mot datamodellen. For eksempel: Kunde-ID.

   Testing av datakvalitet inkluderer også tallkontroller, datokontroller, presisjonskontroller, datakontroller og nullkontroller.

9. Inkrementell ETL-testing
   Testprosess: Denne testingen kontrollerer dataintegriteten til gamle og nye data ved å legge til nye data. Trinnvis testing bekrefter at innsettinger og oppdateringer behandles som forventet under den trinnvise ETL-prosessen.
10. GUI/navigasjonstesting
    Testprosess: Denne testingen sjekker navigasjons- og GUI-aspektene ved frontend-rapportene.

Hvordan lage ETL-testcase

ETL-testing er et konsept som kan brukes på forskjellige verktøy og databaser i informasjonshåndteringsbransjen. Målet med ETL-testing er å sikre at dataene som lastes inn fra en kilde til en destinasjon etter forretningstransformasjon, er nøyaktige. Det innebærer også verifisering av data på de ulike mellomstadiene mellom kilde og destinasjon.

Når en ETL-tester utfører ETL-testing, brukes alltid to dokumenter:

1. ETL-kartping ark: Et ETL-kartping Arket inneholder all informasjon om kilde- og måltabeller, inkludert hver kolonne og oppslaget i referansetabeller. ETL-testere må være komfortable med SQL-spørringer fordi ETL-testing kan innebære å skrive store spørringer med flere sammenføyninger for å validere data på ethvert trinn. ETL-kartping Regneark gir betydelig hjelp når du skriver spørringer for dataverifisering.
2. DB-skjema for kilde og mål: Den bør oppbevares lett tilgjengelig for å bekrefte eventuelle detaljer på kartet.ping ark.

ETL-testscenarier og testtilfeller

1. kartping dokumentvalidering
   Test tilfeller: Bekreft om den tilsvarende ETL-informasjonen er oppgitt i kartetping dok. En endringslogg bør føres i hvert kartping dok.
2. Validering
   Test tilfeller:

   1) Valider kilde- og måltabellstrukturen mot det tilsvarende kartetping dok.
   2) Kildedatatypen og måldatatypen skal være den samme.
   3) Lengden på datatypene i både kilde og mål bør være lik.
   4) Bekreft at datafelttyper og -formater er spesifisert.
   5) Lengden på kildedatatypen skal ikke være kortere enn lengden på måldatatypen.
   6) Valider navnene på kolonnene i tabellen mot kartetping dok.

3. Begrensningsvalidering
   Test tilfeller: Sørg for at begrensninger er definert for den spesifikke tabellen som forventet.
4. Problemer med datakonsistens
   Test tilfeller:

   1) Datatypen og lengden for et bestemt attributt kan variere på tvers av filer eller tabeller, selv når den semantiske definisjonen er den samme.
   2) Misbruk av integritetsbegrensninger.

5. Fullstendighetsproblemer
   Test tilfeller:

   1) Sørg for at alle forventede data er lastet inn i måltabellen.
   2) Sammenlign antall poster mellom kilde og mål.
   3) Sjekk om det finnes avviste poster.
   4) Sjekk at dataene ikke er avkortet i kolonnene i måltabellene.
   5) Sjekk grenseverdianalysen.
   6) Sammenlign unike verdier for nøkkelfelt mellom data lastet inn i lageret og kildedataene.

6. Korrekthetsproblemer
   Test tilfeller:

   1) Data som er feilstavet eller unøyaktig registrert.
   2) Null, ikke-unike eller data utenfor rekkevidde.

7. Transformation
   Test tilfeller: Valider at alle forretningsregler og transformasjonslogikk i kartetping dokumentet brukes riktig på kildedataene før det lander i målet.
8. Datakvalitet
   Test tilfeller:

   1) Nummersjekk: valider numeriske formater og verdier.
   2) Datokontroll: datoer må følge et enkelt format og være konsistente på tvers av poster.
   3) Presisjonskontroll.
   4) Datakontroll.
   5) Nullsjekk.

9. Null validering
   Test tilfeller: Bekreft nullverdiene der «Ikke null» er angitt for en bestemt kolonne.
10. Duplikatsjekk
    Test tilfeller:

    1) Valider den unike nøkkelen, primærnøkkelen og eventuelle andre kolonner som skal være unike i henhold til forretningskrav for å bekrefte at det ikke finnes dupliserte rader.
    2) Sjekk om det finnes dupliserte verdier i noen kolonne, f.eks.trachentet fra flere kildekolonner og kombinert til én kolonne.
    3) I henhold til klientens krav, sørg for at det ikke finnes duplikater i en kombinasjon av flere kolonner i målet.

11. Validering av dato
    Test tilfeller: Datoverdier brukes i mange områder av ETL-utvikling:

    1) Å vite datoen for opprettelsen av raden.
    2) Identifiser aktive poster fra ETL-utviklingsperspektivet.
    3) Identifiser aktive poster fra et forretningskravperspektiv.
    4) Noen ganger genereres oppdateringer og innlegg basert på datoverdiene.

12. Fullfør datavalidering
    Test tilfeller:

    1) Valider hele datasettet i kilde- og måltabellene ved å bruke en minusspørring som den beste løsningen.
    2) Du må utføre kilde minus mål og mål minus kilde.
    3) Hvis minusspørringen returnerer en verdi, bør disse radene anses som uoverensstemmelser.
    4) Finn samsvar mellom rader mellom kilde og mål ved hjelp av en intersect-setning.
    5) Antallet som returneres av intersect skal samsvare med de individuelle antallet i kilde- og måltabellene.
    6) Hvis en minusspørring returnerer rader og skjæringspunktantallet er mindre enn kilde- eller målantallet, finnes det dupliserte rader.

13. Datarenshet
    Test tilfeller: Unødvendige kolonner bør slettes før du laster inn i oppstillingsområdet.

Typer ETL-feil

Selv med sterke testtilfeller kan ETL-pipelines feile på forskjellige måter. Bildet nedenfor oppsummerer feilkategoriene du bør se etter, og tabellen som følger beskriver hver enkelt.

Type feil	Tekniske beskrivelser
Brukergrensesnittfeil/kosmetikkfeil	• Relatert til applikasjonens grafiske brukergrensesnitt • Skriftstil, skriftstørrelse, farger, justering, stavefeil, navigasjon og så videre
Boundary Value Analysis (BVA) relatert feil	• Minimums- og maksimumsverdier
Equivalence Class Partitioning (ECP) relatert feil	• Gyldig og ugyldig type
Inndata-/utdatafeil	• Gyldige verdier godtas ikke • Ugyldige verdier akseptert
Beregningsfeil	• Matematiske feil • Endelig utdata er feil
Last inn tilstandsfeil	• Tillater ikke flere brukere • Tillater ikke kundens forventede belastning
Race Condition bugs	• Systemkrasj og henger seg opp • Systemet kan ikke kjøre klientplattformer
Versjonskontrollfeil	• Ingen logomatching • Ingen versjonsinformasjon tilgjengelig • Forekommer vanligvis i Regresjonstesting
H/W-feil	• Enheten svarer ikke på applikasjonen
Hjelpekildefeil	• Feil i hjelpedokumenter

Testing av datavarehus

Testing av datavarehus er en testmetode der dataene i et datalager testes for integritet, pålitelighet, nøyaktighet og konsistens for å overholde selskapets datarammeverk. Hovedformålet med datalagertesting er å sikre at de integrerte dataene i lageret er pålitelige nok til at selskapet kan ta beslutninger på grunnlag av disse. Mens ETL-testing fokuserer på dataflyt, dekker datalagertesting det bredere lagrings- og rapporteringslaget som ETL til slutt mater.

Forskjellen mellom databasetesting og ETL-testing

Selv om begge fagområdene jobber med strukturerte data, svarer de på forskjellige spørsmål. Tabellen nedenfor fremhever den praktiske kontrasten:

ETL-testing	Databasetesting
Verifiserer om data flyttes som forventet.	Hovedmålet er å sjekke om dataene følger reglene og standardene som er definert i datamodellen.
Verifiserer om antallene i kilden og målet samsvarer, og at dataene som er transformert er som forventet.	Verifiserer at det ikke finnes noen foreldreløse poster, og at relasjoner mellom fremmed-primærnøkkel opprettholdes.
Verifiserer at utenlandske primærnøkkelrelasjoner bevares under ETL-en.	Verifiserer at det ikke finnes overflødige tabeller og at databasen er optimalt normalisert.
Verifiserer duplisering i lastede data.	Verifiserer om data mangler i kolonner der det er nødvendig.

Ytelsestesting i ETL

Ytelsestesting i ETL er en testteknikk som sikrer at et ETL-system kan håndtere belastningen fra flere brukere og transaksjoner. Hovedmålet med ETL Ytelsestesting er å optimalisere og forbedre øktytelsen ved å identifisere og eliminere ytelsesflaskehalser. Kilde- og måldatabasene, kartpings, økter og selve systemet kan alle inneholde flaskehalser.

Et av de beste verktøyene som brukes til ytelsestesting og -justering er Informatica.

Ansvar for en ETL-tester

Hovedansvaret til en ETL-tester er delt inn i tre kategorier:

• Scenebord / SFS eller MFS
• Forretningstransformasjonslogikk brukt
• Target Tabell lasting fra scenefil eller tabell etter bruk av en transformasjon

Noen av de daglige oppgavene til en ETL-tester er:

• Test ETL-programvare
• Testkomponenter i ETL-datavarehuset
• Utfør datadrevne backend-tester
• Lag, design og utfør test tilfeller, testplaner og testseler
• Identifiser problemer og gi løsninger på potensielle problemer
• Godkjenne krav og designspesifikasjoner
• Valider dataoverføringer og test flate filer
• Skriv SQL-spørringer for ulike scenarier, for eksempel teltester

Automatisering av ETL-testing

Den generelle metodikken for ETL-testing er å bruke SQL-skripting eller visuell «gjennomgang» av data. Disse tilnærmingene er tidkrevende, feilutsatte og gir sjelden fullstendige resultater. testdekningFor å akselerere gjennomføringen, forbedre dekningen, redusere kostnader og forbedre defekt deteksjon i produksjons- og utviklingsmiljøer, automatisering er et presserende behov. Et slikt verktøy er Informatica.

Moderne team blander også tradisjonell automatisering med AI-assisterte hjelpere som foreslår transformasjonstester, genererer syntetiske kildedata og flagger skjemaavvik, noe som frigjør testere til å fokusere på kompleks forretningslogikk i stedet for repeterende skriptvedlikehold.

Beste praksis for ETL-testing

1. Sørg for at dataene transformeres riktig.
2. Uten datatap eller avkorting bør projiserte data lastes inn i datalageret.
3. Sørg for at ETL-applikasjonen avviser ugyldige data på riktig måte, erstatter dem med standardverdier der det er aktuelt, og rapporterer dem.
4. Bekreft at data lastes inn i lageret innenfor foreskrevne og forventede tidsrammer for å validere skalerbarhet og ytelse.
5. Alle metoder bør ha passende enhetstester uavhengig av synlighet.
6. For å måle effektiviteten deres, bør alle enhetstester bruke passende dekningsteknikker.
7. Streb etter én påstand per testtilfelle.
8. Opprett enhetstester som retter seg mot unntak.

Sjekk ut - ETL Testing Intervju Spørsmål og Svar

Spørsmål og svar