Meny

Veiledning for testing av datavarehus med eksempler | ETL Testing Guide

  • Hoved
  • Annen
  • Veiledning for testing av datavarehus med eksempler | ETL Testing Guide

data warehouse testing tutorial with examples etl testing guide

Prøv Instrumentet Vårt For Å Eliminere Problemer

Denne opplæringen dekker mål og betydning for datalagertesting, ETL-testansvar, feil i DW og ETL-distribusjon i detalj:

I dette In-Depth Data Warehouse Training Series , så vi på Hva er ET L Prosess i datavarehus i detalj i vår forrige opplæring.

Denne opplæringen vil gi deg en forståelse av hvordan Data Warehouse Testing kan oppnås i en organisasjon. Du vil også bli kjent med målene for DW-testing, hvordan og hva slags testing kan utføres på backend, som alle er involvert i denne prosessen, DW-feil og ETL-distribusjon i detalj.

=> Sjekk ALLE opplæringsprogrammer for datalager her.

ETL-testing av datalager

Målgruppe

  • Data Warehouse / ETL utviklere og testere.
  • Database fagpersoner med grunnleggende kunnskap om databasekonsepter.
  • Databaseadministratorer / Big data-eksperter som ønsker å forstå Data Warehouse / ETL-konsepter.
  • Høgskoleutdannede / nybegynnere som leter etter datavarehusjobber.

Hva du vil lære:

Data Warehouse (ETL) Testing

Hva er betydningen av å teste Data Warehouse og Business Intelligence-systemer?

Testing spiller en avgjørende rolle for suksessen til et av de to ovennevnte systemene, ved å sikre korrekte data som bygger sluttbrukernes tro.

Generelt koster en feil funnet i de senere stadiene av programvarens utvikling livssyklus mer å fikse feilen. Denne situasjonen i DW kan forverres fordi feil data funnet på de senere stadiene kan ha blitt brukt i viktige forretningsbeslutninger på den tiden.

Dermed er løsningen i DW dyrere når det gjelder prosess, mennesker og teknologiske endringer. Du kan begynne DW-testen rett fra kravinnsamlingsfasen.

En kravsporbarhetsmatrise blir utarbeidet og gjennomgått, og dette kartlegger hovedsakelig DW-funksjonene med deres respektive forretningskrav. Sporbarhetsmatrisen fungerer som en inngang til DW-testplanen som er utarbeidet av testerne. Testplanen beskriver testene som skal utføres for å validere DW-systemet.

Den beskriver også hvilke typer tester som skal utføres på systemet. Etter at testplanen er klar vil alle detaljerte testtilfeller utarbeides for forskjellige DW-scenarier. Deretter blir alle testsakene utført og mangler blir logget.

Det er en standard i den operative verdenen som opprettholder forskjellige miljøer for utvikling, testing og produksjon. I DW-verdenen vil både utviklerne og testerne sørge for at utviklings- og testmiljøene er tilgjengelige med kopi av produksjonsdata før de starter arbeidet.

Dette kopieres for en liste over tabeller med begrenset eller full data avhengig av prosjektets behov, da produksjonsdataene er veldig store. Utviklerne utvikler koden sin i utviklerens miljø og leverer den til testerne.

Testerne vil teste koden som leveres i testmiljøene for å sikre om alle systemene fungerer. Da vil koden gå live i produksjonsmiljøene. DW-koden vedlikeholdes også i forskjellige versjoner basert på feilene som er løst i hver utgivelse. Vedlikehold av flere miljøer og kodeversjoner bidrar til å bygge et system av god kvalitet.

beste gratis anti spyware for pc

Test of Data Warehouse (ETL)

La oss ta en titt på Goals Of Data Warehouse Testing.

# 1) Datafullstendighet: Sørg for at alle data fra forskjellige kilder er lastet inn i et datavarehus. Testteamet validerer om alle DW-postene er lastet, mot kildedatabasen og flate filer ved å følge eksemplene på eksempler nedenfor.

  • Totalt antall poster som er lastet opp fra kildesystemet, skal samsvare med det totale antallet poster som er lastet inn i DW. Hvis det er en forskjell, kan du tenke på de avviste postene.
  • Sammenlign dataene som er lastet inn i hvert felt av DW med kildesystemets datafelt. Dette vil føre til eventuelle datafeil.

# 2) Datatransformasjon: Mens du laster opp kildedataene til datalageret, kan få felt lastes direkte med kildedataene, men få felt vil bli lastet med dataene som transformeres i henhold til forretningslogikken. Dette er den komplekse delen av testing av DW (ETL).

Nedenfor er eksempler på strategier for å teste dette:

  • Du kan teste ved å opprette og sammenligne data i regneark. Last kildetransformerte data og DW-data i regneark og gjør en sammenligning. Det skal ikke være noen uoverensstemmelse.
  • Testere bør skrive spørsmålene i henhold til transformasjonslogikken for å sammenligne DW-dataene med kildedataene. Spørringskjøring vil garantere at datavalidering for et av feltene ikke mangler.

# 3) Datakvalitet: Data warehouse (ETL) system må sikre kvaliteten på dataene som er lastet inn i det ved å avvise (eller) korrigere dataene.

DW kan avvise noen få av kildesystemdataene basert på logikk for forretningskrav. For eksempel, avvise en post hvis et bestemt felt har ikke-numeriske data. Alle avviste poster er lastet inn i avvisningstabellen for referanse.

Avviste data blir rapportert til klientene fordi det ikke er noen sjanse for å bli kjent med disse tapte dataene, da de ikke blir lastet inn i DW-systemet. DW kan riktig dataene ved å laste inn null i stedet for nullverdier etc.

# 4) Skalerbarhet og ytelse: Datalageret må sikre skalerbarheten til systemet med økende belastning. Med dette bør det ikke være noen forringelse i ytelsen mens spørringene utføres, med forventede resultater i bestemte tidsrammer. Dermed avdekker ytelsestesting eventuelle problemer og løser det før produksjonen.

Nedenfor er eksempler på strategier for ytelse og skalerbarhetstesting:

  • Gjør ytelsestesting ved å laste inn produksjonsvolum med data og sørg for at tidsrammer ikke blir savnet.
  • Valider ytelsen til hvert søk med massedata. Test ytelsen ved å bruke enkle og flere sammenføyninger.
  • Last dobbelt (eller) tredobbelt til datamengdene som forventes å beregne kapasiteten til systemet omtrent.
  • Test ved å kjøre jobber for alle de oppførte rapportene samtidig.

# 5) Integrasjonstesting: Datalageret skal utføre integrasjonstesting med andre oppstrøms- og nedstrømsapplikasjoner. Hvis det er mulig, er det bedre å kopiere produksjonsdataene til testmiljøet for integrasjonstesting.

Alle systemteamene bør være involvert i denne fasen for å bygge bro over hullene mens de forstår og tester alle systemene sammen.

# 6) Enhetstesting: Dette utføres av de enkelte utviklerne på deres leveranser. Utviklere vil utarbeide enhetstestscenarier basert på forståelse av kravene, kjøre enhetstestene og dokumentere resultatene. Dette hjelper utviklerne med å fikse eventuelle feil hvis de blir funnet, før de leverer koden til testteamet.

# 7) Regresjonstesting: Validerer at DW-systemet ikke fungerer feil etter å ha løst feil. Dette utføres mange ganger med hver nye kodeendring.

# 8) Testing av brukeraksept: Denne testen utføres av forretningsbrukere for å validere systemfunksjonaliteten. UAT-miljø er forskjellig fra QA-miljøet. Utskriften fra UAT innebærer at vi er klare til å flytte koden til produksjon.

hva du skal åpne xml-filer med

Fra perspektivet Data Warehouse og Business Intelligence kan forretningsbrukere validere ulike rapporter gjennom et brukergrensesnitt (UI). De kan validere rapportspesifikasjonene opp mot kravene, kan validere riktigheten av data i rapportene, kan validere hvor raskt systemet returnerer resultatene, etc.

DW Testing Flow Diagram:

Data Warehouse Testing Flow Diagram

Ansvar for testing av datalager

Nedenfor vises de forskjellige teamene som er involvert i å levere et vellykket DW-system:

  • Forretningsanalytikere: Samle alle forretningskravene til systemet og dokumenter dem for alles ønske.
  • Infrastrukturteam: Sett opp forskjellige miljøer etter behov for både utviklere og testere.
  • Utviklere: Utvikle ETL-kode i henhold til kravene og utføre enhetstester.
  • QA (kvalitetssikring) / testere: Utvikle testplan, testtilfeller osv. Identifiserer mangler i systemet ved å utføre testsakene. Utfør forskjellige testnivåer.
  • DBAer: DBA tar ansvar for å konvertere logiske ETL-databasescenarier til fysiske ETL-databasescenarier og involverer også i ytelsestesting.
  • Forretningsbrukere: Involver deg i testing av brukeraksept, kjør spørsmål og rapporter på DW-tabeller.

Feil i datalageret

Når du trekker ut, transformerer og laster (ETL) data fra flere kilder, er det sjanser for at du får dårlige data som kan avbryte de langvarige jobbene.

Følgende er hovedårsakene til feil i DW-systemet:

# 1) Brudd på forretningsregler (logiske feil): Logisk feil data bryter forretningsreglene. Slike data kan mest håndteres under transformasjons- eller lastefaser.

# 2) Brudd på dataregler (datafeil): Datafeil oppstår inne i DW-databasesystemet, som datatypefeil, databegrensningsfeil, etc.

ETL-distribusjon

Dette er fasen hvor all din innsats går live. Alle produksjonsstøttedokumentene bør utarbeides.

Dokumentasjonen vil fortelle andre om sekvensen av jobber som skal kjøres, feilsøkingsscenarier, opplæringsmateriell til DWs supportteam for å overvåke systemet etter distribusjon og til det administrative supportteamet for å utføre rapportene.

Konklusjon

Vi lærte om målene for datalagertesting, ETL-testansvar, feil i DW og ETL-distribusjon i detalj i denne veiledningen.

Vi håper du fikk en ide om hvordan detaljert testing kan gjøres i et Data Warehouse (ETL) -system.

=> Besøk her for å lære datalagring fra riper.

Anbefalt lesing

^