ETL-testveiledning

Hva er ETL-testing?

ETL-testing gjøres for å sikre at dataene som er lastet fra en kilde til destinasjonen etter forretningstransformasjon er nøyaktige. Det innebærer også verifisering av data på ulike mellomstadier som brukes mellom kilde og destinasjon. ETL står for Extract-Transform-Load.

Testing av datavarehus

Testing av datavarehus er en testmetode der dataene inne i et datavarehus testes for integritet, pålitelighet, nøyaktighet og konsistens for å overholde selskapets datarammeverk. Hovedformålet med datavarehustesting er å sikre at de integrerte dataene inne i datavarehuset er pålitelige nok til at en bedrift kan ta beslutninger om.

Hva er ETL?

ETL står for Extract-Transform-Load og det er en prosess for hvordan data lastes fra kildesystemet til datavarehuset. Data trekkes ut fra en OLTP-database, transformeres for å matche datavarehusskjemaet og lastes inn i datavarehusdatabasen. Mange datavarehus inneholder også data fra ikke-OLTP-systemer som tekstfiler, eldre systemer og regneark.

La oss se hvordan det fungerer

For eksempel er det en butikk som har forskjellige avdelinger som salg, markedsføring, logistikk osv. Hver av dem håndterer kundeinformasjonen uavhengig, og måten de lagrer disse dataene på er ganske forskjellig. Salgsavdelingen har lagret den etter kundens navn, mens markedsavdelingen har lagret den etter kunde-ID.

Nå hvis de ønsker å sjekke historien til kunden og vil vite hva de forskjellige produktene han/hun kjøpte på grunn av forskjellige markedsføringskampanjer; det ville vært veldig kjedelig.

Løsningen er å bruke en Datavarehus å lagre informasjon fra ulike kilder i en enhetlig struktur ved hjelp av ETL. ETL kan transformere forskjellige datasett til en enhetlig struktur.Later bruke BI-verktøy for å utlede meningsfull innsikt og rapporter fra disse dataene.

Følgende diagram i denne opplæringen for ETL-testing gir deg VEIKARTET for prosessflyten for ETL-testing og ulike ETL-testkonsepter:

1) Uttrekk

Trekk ut relevante data

2) Forvandle

Transformer data til DW (Data Warehouse) format
Byggnøkler – En nøkkel er ett eller flere dataattributter som unikt identifiserer en enhet. Diverse typer nøkler er primærnøkkel, alternativnøkkel, fremmednøkkel, sammensatt nøkkel, surrogatnøkkel. Datavarehuset eier disse nøklene og lar aldri noen annen enhet tildele dem.
Rensing av data: Etter at dataene er trukket ut, vil de gå inn i neste fase, med rengjøring og samsvar med data. Rengjøring gjør utelatelsen i dataene i tillegg til å identifisere og rette feilene. Overensstemmelse betyr å løse konfliktene mellom disse dataene som er inkompatible, slik at de kan brukes i et bedriftsdatavarehus. I tillegg til disse lager dette systemet metadata som brukes til å diagnostisere kildesystemproblemer og forbedrer datakvaliteten.

3) Last

Last inn data i DW (Data Warehouse)
Bygg aggregater – Å lage et aggregat er å oppsummere og lagre data som er tilgjengelig i faktatabell for å forbedre ytelsen til sluttbrukerspørringer.

ETL testprosess

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

ETL-testing utføres i fem trinn

Identifisere datakilder og krav
Datainnsamling
Implementer forretningslogikk og dimensjonsmodellering
Bygg og fyll ut data
Bygg rapporter

Typer ETL-testing

Produksjonsvalideringstesting
Testprosess: "Tabellbalansering" eller "produksjonsavstemming" denne typen ETL-testing utføres på data når de flyttes inn i produksjonssystemer. For å støtte forretningsbeslutningen din, må dataene i produksjonssystemene dine være i riktig rekkefølge. Informatikk Datavalideringsalternativet gir ETL-testingsautomatiserings- og administrasjonsfunksjoner for å sikre at produksjonssystemene ikke kompromitteres av dataene.
Kilde til Target Testing (valideringstesting)
Testprosess: En slik type testing utføres for å validere om de transformerte dataverdiene er de forventede dataverdiene.
Søknad Upgrades
Testprosess: En slik type ETL-testing kan genereres automatisk, og sparer betydelig testutviklingstid. Denne typen testing sjekker om dataene som trekkes ut fra en eldre applikasjon eller depot er nøyaktig de samme som dataene i et depot eller en ny applikasjon.
Metadatatesting
Testprosess: Metadatatesting inkluderer testing av datatypesjekk, datalengdesjekk og indeks/begrensningssjekk.
Testing av datafullstendighet
Testprosess: For å verifisere at alle de forventede dataene er lastet inn i målet fra kilden, utføres datafullstendighetstesting. Noen av testene som kan kjøres er å sammenligne og validere tellinger, aggregater og faktiske data mellom kilden og målet for kolonner med enkel transformasjon eller ingen transformasjon.
Datanøyaktighetstesting
Testprosess: Denne testingen er gjort for å sikre at dataene lastes inn og transformeres nøyaktig som forventet.
Testing av datatransformasjon
Testprosess: Testing av datatransformasjon gjøres da det i mange tilfeller ikke kan oppnås ved å skrive én kilde SQL spørre og sammenligne utdataene med målet. Det kan hende at flere SQL-spørringer må kjøres for hver rad for å bekrefte transformasjonsreglene.
Datakvalitetstesting
Testprosess:
Datakvalitetstester inkluderer syntaks- og referansetester. For å unngå feil på grunn av dato eller ordrenummer under forretningsprosessen, utføres datakvalitetstesting.

Syntakstester: Den vil rapportere skitne data, basert på ugyldige tegn, tegnmønster, feil rekkefølge med store eller små bokstaver osv.

Referansetester: Den vil sjekke dataene i henhold til datamodellen. For eksempel: Kunde-ID

Datakvalitetstesting inkluderer tallsjekk, datosjekk, presisjonssjekk, datasjekk, nullsjekk osv.
Inkrementell ETL-testing
Testprosess: Denne testingen er gjort for å sjekke dataintegriteten til gamle og nye data med tillegg av nye data. Inkrementell testing verifiserer at innleggene og oppdateringene blir behandlet som forventet under inkrementell ETL-prosess.
GUI/navigasjonstesting
Testprosess: Denne testen gjøres for å sjekke navigasjons- eller GUI-aspektene til grensesnittrapportene.

Hvordan lage ETL-testcase

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

Når du utfører ETL-testing, er det to dokumenter som alltid vil bli brukt av en ETL-tester

ETL-kartleggingsark:Et ETL-kartleggingsark inneholder all informasjon om kilde- og måltabeller, inkludert hver eneste kolonne og deres oppslag i referansetabeller. En ETL-tester må være komfortabel med SQL-spørringer, da ETL-testing kan innebære å skrive store spørringer med flere sammenføyninger for å validere data på alle stadier av ETL. ETL-kartleggingsark gir en betydelig hjelp når du skriver spørringer for dataverifisering.
DB-skjema for kilde, Target: Den bør være tilgjengelig for å verifisere eventuelle detaljer i kartleggingsark.

ETL-testscenarier og testtilfeller

Kartleggingsdokumentvalidering
Test tilfeller: Bekreft kartleggingsdokumentet om tilsvarende ETL-informasjon er gitt eller ikke. Endringslogg bør opprettholdes i hvert kartleggingsdokument.
Validering
Test tilfeller:
1) Valider kilde- og måltabellstrukturen mot tilhørende tilordningsdokument.
2) Kildedatatypen og måldatatypen bør være den samme
3) Lengden på datatypene i både kilde og mål skal 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 navnet på kolonnene i tabellen mot tilordningsdokumentet.
Begrensningsvalidering
Test tilfeller: Sørg for at begrensningene er definert for spesifikk tabell som forventet
Problemer med datakonsistens
Test tilfeller:
1) Datatypen og lengden for et bestemt attributt kan variere i filer eller tabeller, selv om den semantiske definisjonen er den samme.
2) Misbruk av integritetsbegrensninger
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) Sjekkdataene skal ikke avkortes i kolonnen i måltabellene
5) Sjekk grenseverdianalyse
6) Sammenligner unike verdier for nøkkelfelt mellom data lastet inn i WH og kildedata
Korrekthetsproblemer
Test tilfeller:
1) Data som er feilstavet eller unøyaktig registrert
2) Null, ikke-unike eller data utenfor rekkevidde
Transformation
Test tilfeller: Transformation
Datakvalitet
Test tilfeller:
1) Nummersjekk: Må nummersjekkes og valideres
2) Datokontroll: De må følge datoformatet, og det skal være likt på tvers av alle poster
3) Presisjonskontroll
4) Datakontroll
5) Nullsjekk
Null validering
Test tilfeller: Bekreft nullverdiene, der "Not Null" er spesifisert for en bestemt kolonne.
Duplikatsjekk
Test tilfeller:
1) Må validere den unike nøkkelen, primærnøkkelen og eventuelle andre kolonner som er unike i henhold til forretningskravene, hvis det finnes dupliserte rader.
2) Sjekk om det finnes dupliserte verdier i en kolonne som trekker ut fra flere kolonner i kildekoden og kombinerer dem til én kolonne.
3) I henhold til klientens krav må det sikres at det ikke oppstår duplikater i kombinasjon med flere kolonner innenfor målet.
Validering av dato
Test tilfeller: Datoverdier bruker mange områder i ETL-utvikling for
1) Å vite datoen for opprettelsen av raden
2) Identifiser aktive poster i henhold til ETL-utviklingsperspektivet
3) Identifiser aktive poster i henhold til forretningskravperspektivet
4) Noen ganger genereres oppdateringer og innlegg basert på datoverdiene.
Fullfør datavalidering
Test tilfeller:
1) Å validere hele datasettet i kilde- og måltabellen minus en spørring i en beste løsning
2) Vi må finne kilde minus mål og mål minus kilde
3) Hvis minus-spørringen returnerer en verdi, bør disse betraktes som rader som ikke samsvarer
4) Trenger å matche rader mellom kilde og mål ved hjelp av intersect-setning
5) Antallet som returneres av intersect skal samsvare med individuelle antall i kilde- og måltabellene
6) Hvis minus spørreresultatet for rader og antall skjæringspunkt er mindre enn kildeantall eller måltabell, kan vi anse at det finnes dupliserte rader.
Datarenshet
Test tilfeller: Unødvendige kolonner bør slettes før du laster inn i oppstillingsområdet.

Typer ETL-feil

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 -heng • Systemet kan ikke kjøre klientplattformer
Versjonskontrollfeil	• Ingen logomatching • Ingen versjonsinformasjon tilgjengelig • Dette skjer vanligvis i Regresjonstesting
H/W-feil	• Enheten svarer ikke på applikasjonen
Hjelpekildefeil	• Feil i hjelpedokumenter

Forskjellen mellom databasetesting og ETL-testing

ETL-testing	Databasetesting
Verifiserer om data flyttes som forventet	Hovedmålet er å sjekke om dataene følger reglene/standardene definert i datamodellen
Verifiserer om tellingene i kilden og målet samsvarer Verifiserer om de transformerte dataene er som forventet	Kontroller at det ikke er noen foreldreløse poster og utenlandsk-primær nøkkelrelasjoner opprettholdes
Verifiserer at de utenlandske primærnøkkelrelasjonene er bevart under ETL	Verifiserer at det ikke er overflødige tabeller og databasen er optimalt normalisert
Verifiserer for duplisering i innlastede data	Kontroller om data mangler i kolonner der det er nødvendig

Ansvar for en ETL-tester

Nøkkelansvaret til en ETL-tester er delt inn i tre kategorier

Scenebord/ SFS eller MFS
Forretningstransformasjonslogikk brukt
Target tabelllasting fra scenefil eller tabell etter bruk av en transformasjon.

Noen av ansvarsoppgavene til en ETL-tester er

Test ETL-programvare
Test komponenter av ETL datavarehus
Utfør backend-datadrevet test
Lag, design og utfør test tilfeller, testplaner og testsele
Identifiser problemet og gi løsninger på potensielle problemer
Godkjenne krav og designspesifikasjoner
Dataoverføringer og test flat fil
Skrive SQL-spørringer3 for ulike scenarier som telletest

Ytelsestesting i ETL

Ytelsestesting i ETL er en testteknikk for å sikre at et ETL-system kan håndtere belastning av flere brukere og transaksjoner. Det primære målet for ETL Ytelsestesting er å optimalisere og forbedre øktytelsen ved å identifisere og eliminere ytelsesflaskehalser. Kilde- og måldatabasene, tilordningene, øktene og systemet har muligens ytelsesflaskehalser.

Et av de beste verktøyene som brukes for ytelsestesting/innstilling er Informatica.

Automatisering av ETL-testing

Den generelle metodikken for ETL-testing er å bruke SQL-skripting eller gjøre "eyeballing" av data. Disse tilnærmingene til ETL-testing er tidkrevende, feilutsatte og gir sjelden komplette testdekning. For å akselerere, forbedre dekningen, redusere kostnader, forbedre Defekt deteksjonsrasjon av ETL-testing i produksjons- og utviklingsmiljøer, automatisering er timens behov. Et slikt verktøy er Informatica.

Beste praksis for ETL-testing

Sørg for at data transformeres riktig
Uten tap av data og avkorting bør projiserte data lastes inn i datavarehuset
Sørg for at ETL-applikasjonen på riktig måte avviser og erstatter med standardverdier og rapporterer ugyldige data
Må sikre at dataene lastes inn i datavarehuset innenfor foreskrevne og forventede tidsrammer for å bekrefte skalerbarhet og ytelse
Alle metoder bør ha passende enhetstester uavhengig av sikt
For å måle effektiviteten bør alle enhetstester bruke passende dekningsteknikker
Tilstrebe én påstand per testtilfelle
Opprett enhetstester som retter seg mot unntak

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