Business Intelligence (BI)-testning med testcases

⚡ Smart opsummering

Business Intelligence-testning verificerer staging-dataene, ETL-processen og de BI-rapporter, som beslutninger er baseret på. Det bekræfter, at data bevæger sig korrekt fra kilde til mål, og at alle tal, der vises i en rapport, kan stoles på.

🧪 Tre lag: Staging-data, ETL-transformationen og den endelige rapport kræver hver deres egne testscenarier.
🔄 ETL-fokus: Bekræft kortping, datatyper, nøglegenerering, transformationsregler og fravær af afkortning eller duplikering.
📊 Rapportfokus: Kontroller formatering, decimalpræcision, håndtering af blankværdier og søgeadfærd.
🔢 Afstemning: Rækkeantallet mellem kilde, staging og mål skal stemme overens, når filterreglerne er anvendt.
⚠️ Ordrespørgsmål: En fejl i staging forårsager fejl på alle senere stadier, så test pipelinen i rækkefølge.
🎯 Ultimativt mål: Datatroværdighed, således at en forretningsbeslutning truffet ud fra en rapport træffes på baggrund af nøjagtige tal.

Læs mere

Hvad er BI-test?

Business Intelligence (BI) er processen med at indsamle, rense, analysere, integrere og dele data for at udlede brugbar indsigt, der driver forretningsvækst. Business Intelligence Testing eller BI-testning verificerer staging-data, ETL-processen, BI-rapporter og sikrer, at implementeringen er korrekt. BI-testning sikrer dataenes troværdighed og nøjagtigheden af de indsigter, der stammer fra BI-processen.

Du kan lære mere om ETL/Business Intelligence i denne tutorial

BI-testprocessen

BI-testning følger formen af selve datapipelinen. Hvert trin skal bestås, før det næste er værd at teste, fordi en defekt opstrøms dukker op igen som en falsk fejl nedstrøms.

Kravanalyse: Fastlæg hvilke forretningsspørgsmål rapporterne skal besvare, og hvilke kildesystemer indeholder dataene. Tvetydighed her bliver senere til en utestbar rapport.
Validering af kildedata: Profilér kilden: rækkeantal, datatyper, null-rater og dubletter. Du kan ikke validere en transformation mod en kilde, du ikke har målt.
Validering af stadieinddeling: Bekræft eksentract landede fuldstændigt, med afstemningsantal, der matcher kilden efter filterregler er anvendt.
ETL og transformationstestning: Bekræft hvert kortping og forretningsregel, herunder afledte kolonner, aggregeringer og generering af surrogatnøgler.
Datavarehus og kubetestning. Kontroller integriteten af dimensioner og faktatabeller, langsomt skiftende dimensionshåndtering og aggregeringsnøjagtighed på alle niveauer i hierarkiet.
Test af rapporter og dashboards: Sammenlign rapporttal med lageret, derefter med kilden, og tjek filtre, detaljevisninger og sikkerhedsroller.
Ydelses- og regressionstest: Mål indlæsningsvinduets varighed og rapporter svartid, og kør derefter pakken igen efter hver pipelineændring.

Forsoning er rygraden i hele processen: På hvert trin skal antallet og summen af nøgletal være tractilbage til kilden. En rapport, der ser korrekt ud, men ikke kan afstemmes, testes ikke, kun inspiceres.

Typer af BI-testning

Scenarierne i denne vejledning falder i seks anerkendte kategorier. Navngivningen hjælper en testplan med at dække hele overfladen i stedet for kun de dele, der er lette at kontrollere.

Type	Hvad det validerer	Typisk teknik
Data fuldstændighed	Alle forventede rekorder ankom	Afstemning af rækkeantal mellem kilde og mål
Datatransformation	Forretningsregler anvendt korrekt	Sammenlign transformeret output med manuelt beregnede forventede værdier
Datakvalitet	Værdierne er gyldige, unikke og inden for intervallet	Nul-, duplikat-, format- og referentiel integritetskontrol
Metadatatestning	Datatyper, længder og begrænsninger matcher specifikationen	Skemasammenligning mellem kilde og mål
Rapport test	Figurer, formatering og detaljedetaljer er korrekte	Krydstjek rapportens output mod lagerforespørgslen
Sikkerhedsprøvning	Brugere ser kun de data, som deres rolle tillader	Kør identiske rapporter under forskellige rollelegitimationsoplysninger

Valget af BI værktøj påvirker, hvordan hver type udføres, men ikke hvilke typer der er nødvendige. Sikkerhedstest er den, der oftest springes over, og den dyreste at overse, fordi en sikkerhedsfejl på rækkeniveau eksponerer data på tværs af forretningsenheder uden at producere nogen synlig fejl.

BI-testningstestcases og scenarier

Scenarierne nedenfor gælder for næsten alle BI-projekter. Gruppér dem efter den fase i pipelinen, de validerer, og kør dem i den rækkefølge, da en fejl i staging vil forårsage fejl i alle senere faser.

ETL-verifikationstestscenarier

Bekræft, at data er kortlagt korrekt fra kilde til målsystem
Bekræft, at alle tabeller og deres felter er kopieret fra kilde til mål
Kontroller, at nøgler, der er konfigureret til at blive automatisk genereret, er oprettet korrekt i målsystemet
Kontroller, at null-felter ikke er udfyldt
Bekræft, at data hverken er forvansket eller afkortet
Bekræft datatype og format i målsystemet er som forventet
Bekræft, at der ikke er dobbelt data i målsystemet
Bekræft, at transformationer er anvendt korrekt
Bekræft, at præcisionen af data i numeriske felter er nøjagtig
Bekræft, at undtagelseshåndteringen er robust

Scenarier for datatest i iscenesættelse

Afstemningstjek-rekordtælling mellem STG (iscenesættelse) tabellerne og måltabeller er den samme efter anvendelse af filterregler
Indsæt en post, som ikke er indlæst i måltabellen for en given tastekombination
Send poster, der allerede findes i måltabellerne, igen, og bekræft, at de ikke er indlæst to gange
Opdater en post for en nøgle, når værdikolonner ændres ved indlæsning af day_02
Slet posterne logisk i måltabellerne
Værdier indlæst af procestabeller
Værdier indlæst af referencetabeller

Testscenarier for dataindlæsning

Tjek, om mål- og kildedatabasen er godt forbundet, og der ikke er adgangsproblemer.
For en fuld belastning skal du kontrollere trunkeringsmuligheden og sikre, at den fungerer fint.
Mens du indlæser dataene, skal du kontrollere sessionens ydeevne
Tjek for ikke-fatale fejl.
Bekræft, at du kan mislykkes med den kaldende overordnede opgave, hvis den underordnede opgave mislykkes.
Kontroller, at loggene er opdateret
Bekræft kortping og workflow parametre er konfigureret nøjagtigt
Bekræft, at antallet af tabeller i kilde- og målsystemer er det samme
Sammenlign attributterne fra fasetabellerne med måltabellerne. De skal matches.

Testscenarier for BI-rapporter

Vis dato og klokkeslæt
Decimalpræcision for nøgletal
Vis antallet af rækker og kolonner på en given side
Gratis karakteristika i rapporten
Hvordan tomme værdier vises for både karakteristika og nøgletal
Om den karakteristiske søgning fungerer på nøgle, tekst eller begge dele, som angivet
Om tekstsøgning skelner mellem store og små bogstaver, og om det opfylder kravet

Udfordringer i BI-testning

Datavolumen. Lagre indeholder hundredvis af millioner af rækker, så en udtømmende sammenligning er umulig. Testning er afhængig af afstemningstotaler plus målrettet stikprøveudtagning af grænse- og højrisikoposter.
Heterogene kilder. Et enkelt lager kan trække på relationelle databaser, flade filer, API'er og ældre systemer, hver med sin egen kodning, datoformat og null-konvention.
Ingen synlig fejl. Et forkert tal i en rapport giver ikke anledning til en fejl. Det giver blot grundlag for en dårlig beslutning, hvilket gør afstemning til den eneste pålidelige detektionsmetode.
Konstant skiftende kilder. En skemaændring i et upstream-system afbryder lydløst et kortpingMetadatatestning skal køre efter en tidsplan, ikke kun på udgivelsestidspunktet.
Langsomt skiftende dimensioner. Historisk nøjagtighed kræver, at en registrering, der var gyldig sidste år, stadig rapporterer sidste års værdi, hvilket er vanskeligt at teste og let at tage fejl af.
Miljøparitet. Testmiljøer indeholder sjældent data i produktionsskala, så problemer med indlæsningsvinduer og forespørgselsydeevne dukker først op efter lancering.

Den fælles tråd er, at BI-fejl er tavse. Enhver afhjælpning ovenfor virker ved at skabe et signal, hvor systemet selv ikke producerer noget.

Ofte Stillede Spørgsmål

ETL-testning validerer, at data flyttes og transformeres korrekt fra kilde til mål. BI-testning er bredere: det omfatter ETL-validering plus lageret, kuberne og de rapporter, som virksomheden rent faktisk læser.

Gennem afstemning i stedet for række-for-række sammenligning. Match antal og kontroltotaler mellem faser, og udtag derefter stikprøvegrænseværdier, nuller, dubletter og de forretningsregler med højest risiko.

Fordi de ikke producerer nogen fejl. Et forkert tal gengives præcis som et korrekt tal, så fejlen dukker først op, når nogen sætter spørgsmålstegn ved tallet, ofte længe efter at der er truffet en beslutning om det.

AI-værktøjer profilerer kilde- og måldata for automatisk at registrere anomalier, afvigelser og skemaændringer og markere poster, hvis værdier falder uden for lærte fordelinger, før en rapport offentliggøres.

Ja. AI kan udlede fuldstændigheds-, unikheds- og referentielle kontroller fra et skema og foreslå transformationstests fra et kort.ping dokumenter. Valider hver regel i forhold til forretningsspecifikationen, før den køres.