Business Intelligence (BI)-testning med testfall
Thomas Hamilton
⚡ Smart sammanfattning
Business Intelligence-testning verifierar stagingdata, ETL-processen och de BI-rapporter som besluten baseras på. Det bekräftar att data flyttas korrekt från källa till mål och att varje siffra i en rapport kan litas på.
Vad är BI-testning?
Business Intelligence (BI) är processen att samla in, rensa, analysera, integrera och dela data för att få fram handlingsbara insikter som driver affärstillväxt. Business Intelligence-testning eller BI-testning verifierar stagingdata, ETL-processen, BI-rapporter och säkerställer att implementeringen är korrekt. BI-testning säkerställer dataens trovärdighet och noggrannheten hos de insikter som härrör från BI-processen.
Du kan lära dig mer om ETL/Business Intelligence i detta handledning
BI-testprocessen
BI-testning följer formen på själva datapipelinen. Varje steg måste passera innan nästa är värt att testa, eftersom en defekt uppströms återkommer som ett falskt fel nedströms.
- Kravanalys: Fastställ vilka affärsfrågor rapporterna måste besvara och vilka källsystem som innehåller informationen. Oklarheter här blir senare en otestbar rapport.
- Validering av källdata: Profilera källan: radantal, datatyper, nullfrekvenser och dubbletter. Du kan inte validera en transformation mot en källa du inte har mätt.
- Validering av staging: Bekräfta exettract landade fullständigt, med avstämningsantal som matchar källan efter att filterregler har tillämpats.
- ETL- och transformationstestning: Verifiera varje kartaping och affärsregler, inklusive härledda kolumner, aggregeringar och generering av surrogatnycklar.
- Datalager och kubtestning. Kontrollera integriteten hos dimensioner och faktatabeller, långsamt föränderlig dimensionshantering och aggregeringsnoggrannhet på varje nivå i hierarkin.
- Rapport- och dashboardtestning: Jämför rapportsiffror mot lagret, sedan mot källan och kontrollera filter, detaljnivåer och säkerhetsroller.
- Prestanda- och regressionstestning: Mät laddningsfönstrets varaktighet och rapportera svarstiden, kör sedan programsviten igen efter varje pipeline-ändring.
Försoning är ryggraden i hela processen: I varje steg måste antalet och summan av nyckeltalen tracåtergå till källan. En rapport som ser korrekt ut men inte kan stämmas av testas inte, utan inspekteras bara.
Typer av BI-testning
Scenarierna i den här handledningen delas in i sex erkända kategorier. Att namnge dem hjälper en testplan att täcka hela ytan snarare än bara de delar som är lätta att kontrollera.
| Typ | Vad det validerar | Typisk teknik |
|---|---|---|
| Datafullständighet | Varje förväntad skiva anlände | Avstämning av radantal mellan källa och mål |
| Datatransformation | Affärsregler tillämpade korrekt | Jämför transformerad utdata med manuellt beräknade förväntade värden |
| Datakvalitet | Värdena är giltiga, unika och inom intervallet | Null-, duplicera-, format- och referensintegritetskontroller |
| Metadatatestning | Datatyper, längder och begränsningar matchar specifikationen | Schemajämförelse mellan källa och mål |
| Rapportera testning | Figurer, formatering och detaljnivåer är korrekta | Kontrollera rapportutdata mot lagerfrågan |
| Säkerhetstest | Användare ser bara de data som deras roll tillåter | Kör identiska rapporter under olika rolluppgifter |
Valet av BI-verktyg påverkar hur varje typ exekveras, men inte vilka typer som behövs. Säkerhetstestning är den som oftast hoppas över och den som är mest kostsam att missa, eftersom en säkerhetsdefekt på radnivå exponerar data över olika affärsenheter utan att producera något synligt fel.
BI-testning Testfall och scenarier
Scenarierna nedan gäller för nästan alla BI-projekt. Gruppera dem efter det steg i pipelinen de validerar och kör dem i den ordningen, eftersom ett fel i staging kommer att orsaka fel i varje senare steg.
ETL-verifieringstestscenarier
- Verifiera att data är korrekt mappad från källa till målsystem
- Kontrollera att alla tabeller och deras fält är kopierade från källa till mål
- Kontrollera att nycklar som konfigurerats för att genereras automatiskt skapas korrekt i målsystemet
- Kontrollera att nollfält inte är ifyllda
- Kontrollera att data varken är förvanskade eller trunkerade
- Kontrollera att datatyp och format i målsystemet är som förväntat
- Kontrollera att det inte finns någon dubblering av data i målsystemet
- Kontrollera att transformationer tillämpas korrekt
- Verifiera att precisionen för data i numeriska fält är korrekt
- Kontrollera att undantagshanteringen är robust
Scenarier för datatest i mellanlagring
- Avstämningskontroll - antalet poster mellan STG-tabellerna (staging) och måltabellerna är samma efter tillämpning av filterregler
- Infoga en post som inte är inläst i måltabellen för given tangentkombination
- Skicka om poster som redan finns i måltabellerna och bekräfta att de inte laddas två gånger
- Uppdatera en post för en nyckel när värdekolumner ändrades vid day_02-laddningar
- Ta bort posterna logiskt i måltabellerna
- Värden som laddas av processtabeller
- Värden laddade av referenstabeller
Testscenarier för datainläsning
- Kontrollera om mål- och källdatabasen är väl sammankopplade och det inte finns några åtkomstproblem.
- För full last, kontrollera trunkeringsalternativet och se till att det fungerar bra.
- När du laddar data, kontrollera prestanda för sessionen
- Kontrollera om det finns icke-fatala fel.
- Verifiera att du kan misslyckas med den anropande överordnade uppgiften om den underordnade uppgiften misslyckas.
- Kontrollera att loggarna är uppdaterade
- Verifiera kartanping och arbetsflöde parametrarna är korrekt konfigurerade
- Kontrollera att antalet tabeller i käll- och målsystem är detsamma
- Jämför attributen från stegtabellerna med måltabellernas attribut. De ska matchas.
Testscenarier för BI-rapporter
- Visa datum och tid
- Decimalprecision för nyckeltal
- På en given sida visas antalet rader och kolumner
- Fria egenskaper i rapporten
- Hur tomma värden visas för både egenskaper och nyckeltal
- Huruvida den karakteristiska sökningen fungerar på nyckel, på text eller på båda, enligt specifikationerna.
- Om textsökning är skiftlägeskänslig, och om det uppfyller kravet
Utmaningar inom BI-testning
- Datavolym. Lagerhållplatser innehåller hundratals miljoner rader, så en uttömmande jämförelse är omöjlig. Testning bygger på avstämningstotaler plus riktat urval av gräns- och högriskposter.
- Heterogena källor. Ett enda lager kan hämta referenser från relationsdatabaser, platta filer, API:er och äldre system, vart och ett med sin egen kodning, datumformat och null-konvention.
- Inget synligt fel. En felaktig siffra i en rapport leder inte till ett fel. Den leder helt enkelt till ett dåligt beslut, vilket gör avstämning till den enda tillförlitliga detekteringsmetoden.
- Ständigt bytande källor. En schemaändring i ett uppströmssystem bryter tyst en kartapingMetadatatestning måste köras enligt ett schema, inte bara vid lanseringstillfället.
- Långsamt skiftande dimensioner. Historisk noggrannhet kräver att en post som är giltig förra året fortfarande redovisar förra årets värde, vilket är svårt att testa och lätt att få fel.
- Miljöparitet. Testmiljöer innehåller sällan data i produktionsskala, så problem med laddningsfönster och prestanda för frågor uppstår först efter att de lanserats.
Den gemensamma nämnaren är att BI-defekter är tysta. Alla ovanstående åtgärder fungerar genom att skapa en signal där systemet självt inte producerar någon.
