data warehouse testing tutorial with examples etl testing guide
Denne vejledning dækker mål og betydning af datalagertest, ETL-testansvar, fejl i DW og ETL-implementering i detaljer:
I denne Dybdegående datalageruddannelsesserie , vi kiggede på Hvad er ET L Process i datavarehus i detaljer i vores tidligere vejledning.
Denne tutorial giver dig en forståelse af, hvordan Data Warehouse Testing kan udføres i en organisation. Du får også at vide om målene med DW-test, hvordan og hvilken type test der kan udføres i backend, som alle er involveret i denne proces, DW-fejl og ETL-implementering i detaljer.
=> Tjek ALLE datavarehåndbøger her.
Målgruppe
- Data Warehouse / ETL-udviklere og testere.
- Databaseprofessionelle med grundlæggende viden om databasekoncepter.
- Databaseadministratorer / Big data-eksperter, der ønsker at forstå Data Warehouse / ETL-koncepter.
- College kandidater / Freshers, der leder efter Data Warehouse job.
Hvad du lærer:
Test af datalager (ETL)
Hvad er betydningen af at teste Data Warehouse og Business Intelligence-systemer?
Test spiller en afgørende rolle for succesen med et af de to ovennævnte systemer ved at sikre rigtigheden af data, der bygger slutbrugernes tro.
Generelt koster en fejl, der findes i de senere stadier af softwareudviklingens livscyklus, mere at afhjælpe denne mangel. Denne situation i DW kan forværres, fordi de forkerte data, der blev fundet på de senere stadier, muligvis var blevet brugt i vigtige forretningsbeslutninger på det tidspunkt.
Således er fixen i DW dyrere med hensyn til proces, mennesker og teknologiske ændringer. Du kan begynde DW-testen lige fra kravindsamlingsfasen.
En kravsporbarhedsmatrix udarbejdes og gennemgås, og dette kortlægger hovedsageligt DW-funktionerne med deres respektive forretningskrav. Sporbarhedsmatrixen fungerer som et input til DW-testplanen, der udarbejdes af testerne. Testplanen beskriver de tests, der skal udføres for at validere DW-systemet.
Den beskriver også de typer test, der skal udføres på systemet. Når testplanen er klar, vil alle de detaljerede testcases blive forberedt til forskellige DW-scenarier. Derefter vil alle testsagerne blive udført, og mangler bliver logget.
Der er en standard i den operationelle verden, der opretholder forskellige miljøer til udvikling, test og produktion. I DW-verdenen vil både udviklerne og testerne sørge for, at udviklings- og testmiljøerne er tilgængelige med replika af produktionsdata, inden de starter deres arbejde.
Dette kopieres til en liste over tabeller med begrænsede eller fulde data afhængigt af projektets behov, da produktionsdataene er virkelig store. Udviklerne udvikler deres kode i udviklerens miljø og leverer den til testerne.
Testerne tester den kode, der leveres i testmiljøerne for at sikre, at alle systemerne fungerer. Derefter vil koden blive vist live i produktionsmiljøerne. DW-koden vedligeholdes også i forskellige versioner baseret på de fejl, der er rettet i hver udgivelse. Vedligeholdelse af flere miljøer og kodeversioner hjælper med at opbygge et system af god kvalitet.
bedste mp3-afspiller downloader til android
Test af datalager (ETL) test
Lad os se på Goals Of Data Warehouse Testing.
# 1) Datafuldstændighed: Sørg for, at alle data fra forskellige kilder indlæses i et datavarehus. Testteamet validerer, hvis alle DW-poster er indlæst mod kildedatabasen og flade filer ved at følge nedenstående eksempelstrategier.
- Det samlede antal poster, der uploades fra kildesystemet, skal matche det samlede antal poster, der er indlæst i DW. Hvis der er en forskel, kan du tænke på de afviste poster.
- Sammenlign de data, der er indlæst i hvert felt i DW, med kildesystemets datafelter. Dette bringer eventuelle datafejl frem.
# 2) Datatransformation: Mens uploade kildedataene til datalageret, kan få felter indlæses direkte med kildedataene, men få felter vil blive indlæst med de data, der transformeres i henhold til forretningslogikken. Dette er den komplekse del af testning af DW (ETL).
Nedenfor er eksempler på strategier for at teste dette:
- Du kan teste ved at oprette og sammenligne data i regneark. Indlæs kildetransformerede data og DW-data i regneark, og foretag en sammenligning. Der bør ikke være nogen uoverensstemmelse.
- Testere skal skrive forespørgslerne i henhold til transformationslogikken for at sammenligne DW-dataene med kildedataene. Forespørgsel udførelse vil garantere, at datavalidering for et af felterne ikke mangler.
# 3) Datakvalitet: Data warehouse (ETL) system skal sikre kvaliteten af de data, der er indlæst i det, ved at afvise (eller) korrigere dataene.
DW kan afvise et par af kildesystemdataene baseret på forretningskravslogikken. For eksempel, afvis en post, hvis et bestemt felt har ikke-numeriske data. Alle de afviste poster indlæses i afvisningstabellen til reference.
De afviste data rapporteres til klienterne, fordi der ikke er nogen chance for at få kendskab til disse mistede data, da de ikke indlæses i DW-systemet. DW kan korrekt dataene ved at indlæse nul i stedet for nulværdier osv.
# 4) Skalerbarhed og ydeevne: Datalager skal sikre systemets skalerbarhed med stigende belastning. Med dette bør der ikke være nogen forringelse af ydeevnen under udførelsen af forespørgslerne med forventede resultater i bestemte tidsrammer. Dermed afdækker performance testing eventuelle problemer og løser det inden produktionen.
Nedenfor er eksempler på strategier til præstation og skalerbarhedstest:
- Udfør præstationsafprøvningen ved at indlæse produktionsvolumener med data og sørg for, at tidsrammerne ikke går glip af.
- Valider udførelsen af hver forespørgsel med massedata. Test præstationen ved hjælp af enkle sammenføjninger og flere sammenføjninger.
- Indlæs dobbelt (eller) tredobbelt til de datamængder, der forventes at beregne systemets kapacitet omtrent.
- Test ved at køre job for alle de anførte rapporter på samme tid.
# 5) Integrationstest: Datalager skal udføre integrationstestning med andre opstrøms- og nedstrømsapplikationer. Hvis det er muligt, er det bedre at kopiere produktionsdataene til testmiljøet til Integration Testing.
Alle systemteam bør være involveret i denne fase for at bygge bro over hullerne, mens de forstår og tester alle systemerne sammen.
# 6) Enhedstest: Dette udføres af de enkelte udviklere på deres leverancer. Udviklere vil forberede enhedstestscenarier baseret på deres forståelse af kravene, køre enhedstestene og dokumentere resultaterne. Dette hjælper udviklerne med at rette eventuelle fejl, hvis de findes, inden de leverer koden til testteamet.
# 7) Regressionstest: Validerer, at DW-systemet ikke fungerer efter at have rettet eventuelle fejl. Dette udføres mange gange med hver nye kodeændring.
# 8) Test af brugeraccept: Denne test udføres af forretningsbrugere for at validere systemfunktionalitet. UAT-miljø er forskelligt fra QA-miljøet. Afmeldingen fra UAT betyder, at vi er klar til at flytte koden til produktion.
hvad er implementeringsfasen i sdlc
Fra datavarehus- og Business Intelligence-systemperspektivet kan forretningsbrugere validere forskellige rapporter via et brugergrænseflade (UI). De kan validere rapportspecifikationerne i forhold til kravene, kan validere rigtigheden af data i rapporterne, kan validere hvor hurtigt systemet returnerer resultaterne osv.
DW-testflowdiagram:
Ansvar for test af datalager
Nedenfor er de forskellige hold involveret i at levere et vellykket DW-system:
- Forretningsanalytikere: Saml alle forretningskravene til systemet, og dokumenter dem efter alles præference.
- Infrastrukturteam: Opret forskellige miljøer efter behov for både udviklere og testere.
- Udviklere: Udvikl ETL-kode i henhold til kravene og udfør enhedstest.
- QA (kvalitetssikring) / testere: Udvikle testplan, testsager osv. Identificerer mangler i systemet ved at udføre testsagerne. Udfør forskellige testniveauer.
- DBA'er: DBA'er tager sig af konvertering af logiske ETL-databasescenarier til fysiske ETL-databasescenarier og involverer også i præstationstest.
- Forretningsbrugere: Inddrag i test af brugeraccept, kør forespørgsler og rapporter på DW-tabeller.
Fejl i datalager
Når du udpakker, transformerer og indlæser (ETL) data fra flere kilder, er der chancer for, at du får dårlige data, der kan afbryde de langvarige job.
Følgende er hovedårsagerne til fejl i DW-systemet:
# 1) Overtrædelser af forretningsregler (logiske fejl): Logisk forkerte data overtræder forretningsreglerne. Sådanne data kan mest håndteres under transformation eller indlæsningsfaser.
# 2) Overtrædelser af dataregler (datafejl): Datafejl forekommer inde i DW-databasesystemet som datatypefejl, databegrænsningsfejl osv.
ETL-implementering
Dette er den fase, hvor al din indsats går live. Alle produktionsstøttedokumenter skal udarbejdes.
Dokumentationen fortæller andre om rækkefølgen af job, der skal køres, scenarier for gendannelsesfejl, træningsmateriale til DW-supportteamene til at overvåge systemet efter implementering og til det administrative supportteam til at udføre rapporterne.
Konklusion
Vi lærte om målene for datavarehustestning, ETL-testansvar, fejl i DW og ETL-implementering i detaljer i denne vejledning.
Vi håber, du har en idé om, hvordan detaljeret test kan udføres i et Data Warehouse (ETL) -system.
=> Besøg her for at lære datalagring fra bunden.
Anbefalet læsning
- ETL Testing Tutorial Data Warehouse Testing Tutorial (En komplet guide)
- Volume Testing Tutorial: Eksempler og Volume Testing Tools
- ETL Testing Interview Spørgsmål og svar
- Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
- Funktionel testning mod ikke-funktionel testning
- Parvis test eller test af selvstudier med værktøjer og eksempler
- Top 10 ETL-testværktøjer i 2021
- Sådan udføres datadrevet test i SoapUI Pro - SoapUI Tutorial # 14