Databasetest består af sortboks-test, hvidboks-test og ACID (atomicitet, konsistens, isolation og holdbarhed). I denne vejledning giver jeg dig definitioner, fremgangsmåder og eksempler.
Hvad er databasetest?
Databasetest eller backend-test eller datatest adskiller sig fra sin brugergrænseflademodpart ved slet ikke at beskæftige sig med systemsoftwarens visuelle grænseflade. Det primære fokus er at kontrollere, at alle interne processer kører korrekt og hurtigt, præcist og sikkert kan hente data.
Databasetest tester databasens skema, tabeller og triggere. Den udsætter databasen for belastning og kan omfatte kørsel af komplekse forespørgsler for grundigt at teste dens funktioner og reaktionsevne. Den tester også databasestyringssystemer (DBMS) såsom Oracle og SQL Server.
Relateret læsning: DE POSITIVE RESULTATER AF NEGATIV TESTNING
Hvad er et databaseskema?
Et databaseskema er en logisk struktur, der definerer organiseringen af og relationerne mellem data i en database. Det beskriver planen for, hvordan data lagres, tilgås og manipuleres i et DBMS. Skemaet beskriver datatyper, begrænsninger og relationer mellem databaseentiteter såsom tabeller, visninger, indekser og triggere.
Databaseskemaet er afgørende for at sikre dataenes integritet og konsistens i en database. Det giver udviklere og databaseadministratorer en ramme til at organisere og strukturere data på en meningsfuld måde. Det hjælper også med at sikre, at de data, der lagres i databasen, opfylder specifikke krav såsom datavalidering, datasikkerhed og datatilgængelighed. Organisationer kan bruge et databaseskema til at sikre organisering og optimering af deres databaser med henblik på effektiv datastyring, forbedring af forretningsdriften og bedre beslutningstagning.
Hvorfor er databasetest vigtigt?
Databasetest er vigtigt, fordi
- Nogle fejl kan kun findes gennem databasetest
- Visse brugsbetingelser kan kun testes i databasen
- Databasetest forbedrer stabilitet og sikkerhed
- Databasetest sikrer konsistens
Eksempel på en databasefunktion
Forestil dig, at du åbner en netbankapplikation på din telefon (eller faktisk åbner netbankappen på din telefon). Overfør nu et mindre pengebeløb fra din lønkonto til din opsparingskonto. Når du er færdig, så tænk over alle de ting, der skulle ske bag kulisserne i løbet af de få sekunder.
- Appen sendte transaktionsoplysningerne til databasen.
- Ingen af dine oplysninger (dvs. PENGE) gik tabt undervejs.
- Appen gik ikke ned eller kunne ikke fuldføre overførslen.
- Transaktionen blev gennemført sikkert.
- Dine penge ligger nu trygt på din opsparingskonto (tillykke!)
Alle disse funktioner foregår i databasen. Databasetestprocessen er vigtig, fordi systemet går helt i stå, hvis et databasesystem svigter alvorligt. Ingen oplysninger kan sendes, hentes, overføres eller sikres. Applikationen ser måske ud til at fungere på overfladen (du kan navigere mellem vinduer og gøre dig klar til at gennemføre transaktioner), men der sker ikke noget med reel betydning.
Alt ser fint ud på ydersiden, men internt er det en katastrofe.
Databasetest sikrer, at der ikke sker nogen katastrofe. Ingen brand, intet systemstop og ingen manglende penge. Det er i alles interesse, at der udføres databasetest. Derfor har jeg skrevet en omfattende vejledning, der kan hjælpe dig med at føle dig sikker på, at alt er blevet grundigt testet, når du er færdig.
Principper for databasetest
Ordet »principper« lyder måske mere som et spørgsmål om hvorfor end hvordan. Stol på mig, det er to vigtige, praktiske begreber.
- ACID-egenskaber
- Atomicitet
- Konsistens
- Isolation
- Holdbarhed
- Dataintegritet
Hvad er ACID-egenskaber?
Dette er den sikreste form for syre, du nogensinde kommer til at bruge. Du behøver ingen handsker; ACID-egenskaberne står for Atomicitet, Consistens, Isolation og Durabilitet. Hver eneste transaktion i databasetest skal opfylde disse principper.
En transaktion er en gruppe af opgaver. Selv en simpel transaktion fra den virkelige verden, såsom den bankoverførsel jeg nævnte tidligere, vil involvere flere underordnede opgaver. ACID-egenskaberne er der for at bekræfte, at hver transaktion gennemføres nøjagtigt, fuldstændigt og med integritet.
Have an account? Log In
ACID-egenskaber
- Atomicitet fastslår, at hver transaktion skal behandles som en atomar enhed. Uden molekylære termer betyder det, at enhver transaktion enten skal gennemføres fuldstændigt, eller også mislykkes den. Behandling af hver transaktion på denne måde undgår den rodede situation, hvor en pengeoverførsel kun gennemføres delvist. Det lyder stressende, ikke? Med atomicitet mislykkes hele transaktionen, hvis den er halvvejs gennemført, når noget går galt. Pengene tilbage. Ingen stress.
- Konsistens kræver, at databasen forbliver konsistent efter en transaktion. Ingen transaktion må påvirke andre data i databasen negativt. Når du indsætter penge på din bankkonto, hæves der ikke penge fra en andens konto.
- Isolation forhindrer, at strømme krydser hinanden. Det sikrer, at hver transaktion i tilfælde af flere samtidige transaktioner behandles, som om den var den eneste, der foregik i databasen. Ingen får deres oplysninger blandet sammen med andre personers oplysninger.
- Holdbarhed kræver, at databasen er tilstrækkeligt holdbar til at fastholde alle de seneste transaktioner, selv hvis der opstår en systemfejl. Igen er der praktiske grunde til at kræve en sådan holdbarhed af en database. Hvis du foretager en pengeoverførsel, og databasen går ned ti minutter senere, hvordan skulle du så vide, at du skal foretage overførslen igen? Så strenge krav forhindrer forvirring hos slutbrugerne.
Dataintegritet
Dataintegritet er praksissen med at kontrollere, at alle de seneste data er opdateret overalt. Der er fire individuelle dele, som tilsammen bekræfter, at dataene har integritet. For at opnå en høj grad af dataintegritet skal en QA-tester bekræfte, at:
- Dataene kan verificeres
- Dataene kan hentes
- Dataene er nøjagtige
- Dataene er komplette
Hvis dataene ikke opfylder disse fire krav, opfylder de sandsynligvis ikke standarden for dataintegritet. Værktøjer til datahåndtering kan hjælpe med dette, men i sidste ende er det op til dig at sikre den højeste datakvalitet.
Som Huw Price påpegede i episoden af QA Lead-podcasten med titlen Dine data sutter, bliver det stadig vigtigere at sikre, at dine systemer kører på data af høj kvalitet og med høj sikkerhed, i takt med at flere og flere virksomheder opbygger deres egne databanker.
Sprog til databasemanipulation
Et sprog til databasemanipulation (DML) er et programmeringssprog, der bruges til at manipulere data i et databasestyringssystem. DML bruges primært til at udføre opgaver såsom at indsætte, opdatere, slette og hente data fra en database. DML leverer grundlæggende et sæt kommandoer og funktioner, som gør det muligt for brugere at interagere med data i en database samt ændre eller hente disse data ud fra specifikke kriterier. DML er en vigtig del af ethvert databasesystem, fordi det giver brugerne mulighed for at udføre handlinger på data uden at forstå databasens underliggende struktur eller teknologi.
DML-kommandoer bruges typisk sammen med et sprog til databasedefinition (DDL), som bruges til at oprette og ændre databaseobjekter såsom tabeller, visninger og indekser. DDL og DML udgør kernekomponenterne i et databasesystem og gør det muligt for brugerne at oprette, ændre og manipulere data på en sikker, effektiv og pålidelig måde. Brugen af DML i databasehåndtering gør det muligt for organisationer at lagre, administrere og analysere store mængder data, hvilket gør det til et kritisk værktøj for virksomheder i nutidens datadrevne verden.
Typer af databasetest
Nu hvor vi har gennemgået to af kerneprincipperne inden for databasetest, kan vi gå videre til forskellige testtyper. Du har sandsynligvis hørt om nogle af disse tilgange før. Husk, at jeg sagde, at hvis du forstod QA-test, ville du uden problemer kunne få styr på databasetest. Her forklarer jeg, hvordan hvert af disse begreber anvendes på databasetest.
Der findes tre typer databasetest:
- Strukturel
- Funktionel
- Ikke-funktionel
Inden for disse tre typer databasetest findes der undertyper. Bare rolig, dem forklarer jeg også.
Strukturel test
Strukturel test validerer elementer i datalageret, som bruges til datalagring. Disse elementer er skjult for slutbrugerne og foregår helt i baggrunden. Databasetestere udfører disse test ved at skrive SQL-forespørgsler.
Test af datakortlægning
Kortlægning af datastrukturer er processen med at etablere forbindelser mellem to forskellige datamodeller. En test af datakortlægning, der også kaldes en skematest, validerer både frontenden og backenden. Den sikrer, at de to dele kommunikerer korrekt med hinanden.
Hvis du for eksempel udfylder en tilmeldingsformular på et websted, vil korrekt datakortlægning tage webformularen og overføre den til databasen. Dit navn, din e-mail og din adgangskode vil blive gemt, hvor de skal. Test af datakortlægning bekræfter, at processen fungerer.
Der findes flere værktøjer til datakortlægning, som en QA-tester arbejder med. En kort liste over værktøjer til datakortlægning omfatter:
Test af databasetabeller
Test af tabeller udfører flere kontroller af datakortlægningsstrukturen. Det kontrollerer, at felterne i brugerfladen og serverdelen er kompatible med hinanden. Det validerer længden af databasefelterne. Og det bekræfter, om der findes ikke-kortlagte databasetabeller eller kolonner, som du skal håndtere.
Validering af databaseserver
Servervalideringer sikrer, at serverkonfigurationen opfylder kravene. De sikrer også, at alle, der forsøger at få adgang til bestemte områder af databaseserveren, har den nødvendige autorisation. Dette er et vigtigt trin for at holde databasen sikker og beskyttet for dens brugere. Endelig sikrer servervalideringen, at serveren kan håndtere det maksimale antal transaktioner på én gang.
En servervalidering for en bankapp vil for eksempel kontrollere, at serveren kan håndtere den finansielle transaktion for et bestemt antal brugere, og at alle brugere kun kan få adgang til deres egne oplysninger.
Funktionel test
Vi skal nok få det sjove tilbage i funktionel test. Det lover vi. Funktionel test handler om at kontrollere, at databasen opfylder klientens specifikationer, og at slutbrugerens handlinger er i overensstemmelse med disse krav. Det betyder, at der er meget skuespil, hvor man foregiver at være slutbrugeren. Lyder det ikke sjovt? Jeg synes, det lyder sjovt.
Sortboks-test
Sortboks-test er en softwareteststrategi, hvor testeren ikke kender designet af det softwaresystem, der testes. Uden et indgående kendskab til softwarens design vil testeren gå til softwaren med forventninger, der svarer til slutbrugerens.
Sortboks-test udføres under databasetest, fordi den finder fejl i almindelige arbejdsgange, som slutbrugeren sandsynligvis vil støde på. Det er den ultimative testkørsel som slutbruger.
Vi gennemgik sortboks-test grundigt i vores guide til 9 typer softwaretest, som alle QA-analytikere bør kende.
Hvidboks-test
Hvidboks-test er den diametrale modsætning til sortboks-test. Ved hvidboks-test har QA-medarbejderen fuld forståelse af den interne struktur og det interne design af den software, der testes.
De går til testen som en inspektør. Hvidboks-test kaldes nogle gange gennemsigtig boks-test, fordi testeren observerer interaktionerne mellem enheder, mens softwaren testes. I modsætning til ved sortboks-test er en hvidboks-tester ikke nær så optaget af brugeroplevelsen.
Enhedstest
Enhedstest er en softwaretestteknik, der indebærer test af individuelle enheder eller komponenter i en applikation isoleret fra resten af systemet. Denne testtype bruges til at teste individuelle databaseobjekter såsom tabeller, visninger, lagrede procedurer og funktioner. Ved at teste disse objekter isoleret kan udviklere sikre, at hvert objekt fungerer efter hensigten.
Enhedstest for databaser indebærer typisk, at man skriver automatiserede tests, der udfører specifikke SQL-kommandoer mod et databaseobjekt eller -modul og kontrollerer, at de forventede resultater returneres. En enhedstest af en lagret procedure kan for eksempel indebære, at man sender et sæt inputparametre til proceduren og kontrollerer, at outputtet er korrekt. Ved at bruge enhedstest på denne måde kan udviklere sikre, at hvert databaseobjekt fungerer som forventet, og at ændringer i databaseskemaet eller applikationskoden ikke medfører utilsigtede konsekvenser eller fejl.
Ikke-funktionel test
Ikke-funktionel test bekymrer sig ikke det mindste om slutbrugeren. Ikke fordi slutbrugeren ikke er vigtig. De har blot andre ting at bekymre sig om. Ikke-funktionelle tests kontrollerer databasens ydeevne under belastning og stress og leder efter steder, hvor ydeevnen kan optimeres.
Belastningstest
Databasebelastningstest er en type ydelsestest af databaser, som kontrollerer, at brugerbelastning ikke vil have en dramatisk negativ indvirkning på databasens ydeevne. QA-testeren vil køre en række belastningsforespørgsler og køre dem igen og igen og igen for at simulere en aktiv brugerbase.
Stresstest
Stresstest er belastningstest, men mere intensiv. De vil ikke se, om databasen bliver langsommere; de vil se, hvor den kan bryde sammen. Det er langt mere destruktivt. Så det er jo sjovt.
Har du nogensinde spændt ventet på udgivelsen af et nyt videospil eller en ny telefon? Hvis du har, kender du måske til at indlæse webstedet eller åbne appen for at foretage dit køb og blive mødt af usædvanligt lange indlæsningsskærme, uventede fejlkoder og fejl ved behandlingen af dine oplysninger. Det er en database under pres.
Det adskiller sig fra belastningstest, fordi databasen udsættes for en pludselig og uventet stor mængde trafik.
More Articles
Automatiseret test af databaser
Automatiseret test af databaser er blevet mere populært i de senere år. Hvis databasen skulle testes manuelt, ville det tage for lang tid, kræve for mange mennesker og ganske enkelt koste for mange penge.
Der er mange måder at udføre automatiseret test på. Her er en liste over nogle værktøjer til databaseadministration, der tilbyder testfunktioner.
Liste over værktøjer til databaseadministration
Test af en database med API
En API (grænseflade til applikationsprogrammering) er et sæt protokoller og standarder, der gør det muligt for forskellige softwareapplikationer at kommunikere med hinanden. Ved databasetest kan en API oprette forbindelse til en database og udføre forskellige handlinger såsom indsættelse, opdatering, sletning og hentning af data.
Forholdet mellem en API og databasetest er, at API'er kan bruges til at automatisere og strømline testprocessen. Ved at bruge en API til at oprette forbindelse til en database kan testere automatisere opgaver som dataindsættelse, opdateringer og sletninger samt udføre forespørgsler for at hente data og validere resultater. Det kan reducere den tid og indsats, der kræves til manuel test, betydeligt og forbedre testresultaternes nøjagtighed og ensartethed.
Yderligere ressourcer
Efter at have læst denne artikel bør du forstå, hvordan man udfører databasetest. Det er naturligvis umuligt at dække absolut alt i én artikel. Her er to yderligere ressourcer, der måske kan hjælpe dig med at overvinde specifikke problemer.
- Sådan regressionstester du en relationsdatabase
- Sådan udfører du en ydelsestest af en SQL Server-instans
Hvad synes du?
Det kan føles som et stort ansvar at få til opgave at teste en database. Jeg er sikker på, at du kan klare det. Føler du dig mere sikker på din tilgang til databasetest? Fortæl mig det i kommentarerne!
