Menu

Komplet guide til databasetest (hvorfor, hvad og hvordan man tester data)

database testing complete guide why

Prøv Vores Instrument Til At Fjerne Problemer

En komplet guide til databasetest med praktiske tip og eksempler:

Computerapplikationer er mere komplekse i disse dage med teknologier som Android og også med masser af Smartphone-apps. Jo mere komplekse frontendene er, jo mere indviklede bliver bagenderne.

Så det er så meget desto vigtigere at lære om DB-test og være i stand til at validere databaser effektivt for at sikre sikkerheds- og kvalitetsdatabaser.

I denne vejledning lærer du alt om datatest - hvorfor, hvordan og hvad skal man teste?

Guide til databasetestning

Databasen er en af ​​de uundgåelige dele af en softwareapplikation.

Det betyder ikke noget, om det er en web-, desktop- eller mobil-, klientserver-, peer-to-peer-, virksomheds- eller individuel virksomhed; Databasen kræves overalt i backend.

Tilsvarende uanset om det er sundhedspleje, økonomi, leasing, detailhandel, postapplikation eller kontrol af et rumskib; en database er altid i aktion bag scenen.

Efterhånden som applikationens kompleksitet øges, opstår behovet for en stærkere og sikker database. På samme måde for applikationer med en høj frekvens af transaktioner ( For eksempel, Bank- eller finansieringsapplikation), er nødvendigheden af ​​et fuldt udstyret DB Tool koblet sammen.

I dag har vi store data, der er store og komplekse, som de traditionelle databaser ikke kan håndtere dem.

Der er flere Databaseværktøjer er tilgængelige på markedet For eksempel, MS-Access, MS SQL Server, SQL Server, Oracle, Oracle Financial, MySQL, PostgreSQL, DB2, Toad, Admirer osv. Disse værktøjer varierer i omkostninger, robusthed, funktioner og sikkerhed. Hver af disse har sine egne fordele og ulemper.

Hvad du lærer:

Hvorfor teste database?

Nedenfor ser vi, hvorfor følgende aspekter af en DB skal valideres:

Alt om databasetest

# 1) Datakortlægning

I softwaresystemer bevæger data sig ofte frem og tilbage fra brugergrænsefladen (brugergrænsefladen) til backend DB og omvendt. Så dette er nogle aspekter at se på:

  • Kontroller, om felterne i UI / frontend-formularer er kortlagt konsekvent med de tilsvarende felter i DB-tabellen. Denne kortlægningsinformation er typisk defineret i kravsdokumenterne.
  • Hver gang en bestemt handling udføres i frontenden af ​​en applikation, påkræves en tilsvarende CRUD-handling (Opret, Hent, Opdater og Slet) i bagenden. En tester bliver nødt til at kontrollere, om den rigtige handling påberåbes, og om den påkaldte handling i sig selv er vellykket eller ej.

# 2) Validering af ACID-egenskaber

Atomicitet, konsistens, isolation og holdbarhed. Hver transaktion, en DB udfører, skal overholde disse fire egenskaber.

DB ACID egenskaber

  • Atomicitet betyder, at en transaktion enten fejler eller gennemføres. Dette betyder, at selvom en enkelt del af transaktionen mislykkes, betyder det, at hele transaktionen er mislykket. Normalt kaldes dette 'alt-eller-intet' -reglen.
  • Konsistens : En transaktion vil altid resultere i en gyldig tilstand for DB
  • Isolation : Hvis der er flere transaktioner, og de udføres på én gang, skal DB / DB's resultat / tilstand være det samme som hvis de blev udført efter hinanden.
  • Holdbarhed : Når en transaktion er gennemført og begået, bør ingen eksterne faktorer som strømtab eller nedbrud være i stand til at ændre den

Foreslået læsning = >> MySQL-transaktionsvejledning

# 3) Dataintegritet

For nogen af ​​de CRUD-operationer , skal de opdaterede og seneste værdier / status for delte data vises på alle formularer og skærme. Værdien bør ikke opdateres på en skærm og vise en ældre værdi på en anden.

Når ansøgningen er under eksekvering, slutbruger bruger hovedsagelig 'CRUD'-operationer, som DB-værktøjet letter .

C: Opret - Når brugeren 'Gemmer' enhver ny transaktion, udføres 'Opret' handling.
R: Hent - Når brugeren 'Søg' eller 'Vis' en gemt transaktion, udføres 'Hent' -operationen.
U: Opdatering - Når brugeren redigerer eller ændrer en eksisterende post, udføres DB-opdateringen.
D: Slet - Når en bruger 'Fjern' en post fra systemet, udføres 'Slet' -handling af DB.

Enhver databasehandling udført af slutbrugeren er altid en af ​​de ovennævnte fire.

Så udform dine DB-testsager på en måde, så de inkluderer kontrol af dataene på alle de steder, det ser ud til at se, om de konsekvent er de samme.

Test af dataintegritet

# 4) Forretningsregeloverensstemmelse

Mere kompleksitet i databaser betyder mere komplicerede komponenter som relationelle begrænsninger, udløsere, lagrede procedurer osv. Så testere bliver nødt til at komme med passende SQL-forespørgsler for at validere disse komplekse objekter.

Hvad skal man teste (Tjekliste til databasetest)

# 1) Transaktioner

Når du tester transaktioner, er det vigtigt at sikre, at de opfylder ACID-egenskaberne.

Dette er de almindeligt anvendte udsagn:

  • BEGYN TRANSAKTION TRANSAKTION #
  • SLUT TRANSAKTION TRANSAKTION #

Tilbagekaldelseserklæringen sikrer, at databasen forbliver i en konsistent tilstand.

  • RULBACK TRANSAKTION #

Når disse udsagn er udført, skal du bruge et valg for at sikre, at ændringerne er reflekteret.

  • VÆLG * FRA TABLENAVN

# 2) Databaseskemaer

Et databaseskema er intet andet end en formel definition af, hvordan dataene skal organiseres inde i en DB. For at teste det:

  • Identificer kravene baseret på, som databasen fungerer. Prøvekrav:
    • Primære nøgler, der skal oprettes, før andre felter oprettes.
    • Udenlandske nøgler skal indekseres fuldstændigt for nem hentning og søgning.
    • Feltnavne, der starter eller slutter med bestemte tegn.
    • Felter med en begrænsning, som bestemte værdier kan eller ikke kan indsættes.
  • Brug en af ​​følgende metoder alt efter relevansen:
    • SQL-forespørgsel DESC for at validere skemaet.
    • Regulære udtryk til validering af navnene på de enkelte felter og deres værdier
    • Værktøjer som SchemaCrawler

      • # 3) Udløsere

      Når en bestemt begivenhed finder sted på et bestemt bord, kan et stykke kode (en trigger) automatisk instrueres til at blive udført.

      For eksempel, en ny studerende sluttede sig til en skole. Den studerende tager 2 klasser: matematik og naturfag. Den studerende føjes til 'studenttabellen'. En udløser kan føje den studerende til de tilsvarende emnetabeller, når han først er føjet til elevtabellen.

      Den almindelige metode til at teste er at udføre SQL-forespørgslen indlejret i udløseren uafhængigt først og registrere resultatet. Følg dette op med at udføre udløseren som helhed. Sammenlign resultaterne.

      Disse testes i både sort-boks og hvid-boks testfasen.

      hvordan man laver en række strenge
      • Test af hvid boks : Stubs og drivere bruges til at indsætte eller opdatere eller slette data, der ville resultere i, at udløseren kaldes på. Grundideen er bare at teste DB alene, selv før integrationen med frontend (UI) er foretaget.
      • Test af sort boks :

      til) Siden brugergrænsefladen og DB er integration nu tilgængelig; vi kan indsætte / slette / opdatere data fra frontenden på en måde, som udløseren påberåbes. Derefter kan Select-sætninger bruges til at hente DB-dataene for at se, om Trigger lykkedes med at udføre den tilsigtede operation.

      b) Den anden måde at teste dette på er ved direkte at indlæse de data, der vil påkalde udløseren, og se om det fungerer som beregnet.

      # 4) Lagrede procedurer

      Lagrede procedurer svarer mere eller mindre til brugerdefinerede funktioner. Disse kan påberåbes af erklæringer om opkaldsprocedure / udfør procedurer, og output er normalt i form af resultatsæt.

      Disse er gemt i RDBMS og er tilgængelige til applikationer.

      Disse testes også under:

      • Hvid boks test: Stubs bruges til at påberåbe de lagrede procedurer, og derefter valideres resultaterne i forhold til de forventede værdier.
      • Test af sort boks: Udfør en operation fra applikationens frontende (UI) og kontroller for udførelsen af ​​den lagrede procedure og dens resultater.

      # 5) Feltbegrænsninger

      Standardværdien, den unikke værdi og den udenlandske nøgle:

      • Udfør en front-end-operation, der udøver tilstandsdatabaseobjektet
      • Valider resultaterne med en SQL-forespørgsel.

      Det er ret simpelt at kontrollere standardværdien for et bestemt felt. Det er en del af validering af forretningsregler. Du kan gøre det manuelt, eller du kan bruge værktøjer som QTP. Manuelt kan du udføre en handling, der tilføjer anden værdi end standardværdien af ​​feltet fra frontenden og ser, om det resulterer i en fejl.

      Følgende er en eksempel på en VBScript-kode:

      Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match)

      Resultatet af ovenstående kode er sandt, hvis standardværdien findes, eller falsk, hvis den ikke gør det.

      Kontrol af den unikke værdi kan gøres nøjagtigt som vi gjorde for standardværdierne. Prøv at indtaste værdier fra brugergrænsefladen, der overtræder denne regel, og se om der vises en fejl.

      Automation VB Script-kode kan være:

      Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match)

      TilFremmed nøglebegrænsning validering bruge data indlæser, der direkte input data, der overtræder begrænsningen og se, om applikationen begrænser dem eller ej. Sammen med backend-datalæsningen skal du også udføre frontend-UI-operationerne på en måde, der overtræder begrænsningerne og ser, om den relevante fejl vises.

      Datatestaktiviteter

      Databasetester bør fokusere på følgende testaktiviteter:

      # 1) Sørg for datakortlægning:

      Data Mapping er et af nøgleaspekterne i databasen, og det bør testes nøje af hver softwaretester.

      Sørg for, at kortlægningen mellem forskellige former eller skærme af AUT og dens DB ikke kun er nøjagtig, men også i henhold til designdokumenterne (SRS / BRS) eller koden. Dybest set skal du validere kortlægningen mellem hvert frontend-felt med dets tilsvarende backend-databasefelt.

      For alle CRUD-operationer skal du kontrollere, at de respektive tabeller og poster opdateres, når brugeren klikker på 'Gem', 'Opdater', 'Søg' eller 'Slet' fra GUI for applikationen.

      Hvad du skal kontrollere:

      • Tabelkortlægning, kolonnekortlægning og datatypekortlægning.
      • Opslag af datakortlægning.
      • Korrekt CRUD-handling påberåbes for hver brugerhandling ved brugergrænsefladen.
      • CRUD-operation er vellykket.

      # 2) Sørg for ACID-egenskaber ved transaktioner:

      ACID-egenskaber ved DB-transaktioner henviser til ' TIL tomicitet ',' C onsistens ',' jeg solation 'og' D urabilitet '. Korrekt test af disse fire egenskaber skal udføres under databasetestaktiviteten. Du skal kontrollere, at hver enkelt transaktion tilfredsstiller databasens ACID-egenskaber.

      ACID egenskaber

      Lad os tage et simpelt eksempel gennem nedenstående SQL-kode:

      CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));

      ACID-testtabellen har to kolonner - A & B. Der er en integritetsbegrænsning, at summen af ​​værdier i A og B altid skal være 100.

      Atomicitetstest vil sikre, at enhver transaktion, der udføres på denne tabel, er alt eller ingen, dvs. ingen poster opdateres, hvis et trin i transaktionen mislykkes.

      Konsistens test vil sikre, at når værdien i kolonne A eller B opdateres, forbliver summen altid 100. Det tillader ikke indsættelse / sletning / opdatering i A eller B, hvis den samlede sum er andet end 100.

      Isolationstest vil sikre, at hvis to transaktioner sker på samme tid og forsøger at ændre dataene i ACID-testtabellen, så udføres disse traktioner isoleret.

      Holdbarhedstest vil sikre, at når en transaktion over denne tabel er begået, vil den forblive sådan, selv i tilfælde af strømsvigt, nedbrud eller fejl.

      Dette område kræver mere streng, grundig og skarp test, hvis din applikation bruger den distribuerede database.

      # 3) Sikre dataintegritet

      Overvej, at forskellige moduler (dvs. skærme eller formularer) til anvendelse bruger de samme data på forskellige måder og udfører alle CRUD-operationer på dataene.

      I så fald skal du sørge for, at den nyeste datatilstand afspejles overalt. Systemet skal vise de opdaterede og nyeste værdier eller status for sådanne delte data på alle formularer og skærme. Dette kaldes som dataintegritet.

      af

      Testcases til validering af databasedataintegritet:

      • Kontroller, om alle udløsere er på plads for at opdatere poster i referencetabellen.
      • Kontroller, om der findes forkerte / ugyldige data i hovedkolonnerne i hver tabel.
      • Prøv at indsætte forkerte data i tabellerne og observer, om der opstår fejl.
      • Kontroller, hvad der sker, hvis du prøver at indsætte et barn, før du indsætter en forælder (prøv at lege med primære og udenlandske nøgler).
      • Test om der opstår en fejl, hvis du sletter en post, der stadig refereres til af data i en hvilken som helst anden tabel.
      • Kontroller, om replikerede servere og databaser er synkroniseret.

      # 4) Sørg for nøjagtigheden af ​​de implementerede forretningsregler:

      I dag er databaser ikke kun beregnet til at gemme posterne. Faktisk er databaser blevet udviklet til ekstremt kraftfulde værktøjer, der giver rigelig støtte til udviklerne til at implementere forretningslogikken på DB-niveau.

      Nogle enkle eksempler på effektive funktioner er 'Referential Integrity', relationelle begrænsninger, udløsere og lagrede procedurer.

      Så ved hjælp af disse og mange andre funktioner, der tilbydes af DB'er, implementerer udviklere forretningslogikken på DB-niveau. Testeren skal sikre, at den implementerede forretningslogik er korrekt og fungerer nøjagtigt.

      Ovenstående punkter beskriver de fire vigtigste 'Hvad skal' ved test af DB. Lad os nu gå videre til 'How To' -delen.

      Sådan tester du databasen (trin-for-trin proces)

      Den generelle database til testprocesstest er ikke meget forskellig fra andre applikationer.

      Følgende er kernetrinene:

      Trin 1) Forbered miljøet
      Trin 2) Kør en test
      Trin # 3) Kontroller testresultatet
      Trin # 4) Valider efter de forventede resultater
      Trin # 5) Rapporter resultaterne til de respektive interessenter

      Databasetestproces

      Normalt bruges SQL-forespørgsler til at udvikle testene. Den mest anvendte kommando er 'Vælg'.

      Vælg * hvorfra

      Udover Select har SQL 3 vigtige typer kommandoer:

      1. DDL: Datadefinitionssprog
      2. DML: Data manipulation sprog
      3. DCL: Datastyringssprog

      Lad os se syntaksen for de mest anvendte udsagn.

      Datadefinitionssprog Bruger CREATE, ALTER, RENAME, DROP og TRUNCATE til at håndtere tabeller (og indekser).

      Data Manipulation sprog Inkluderer udsagn for at tilføje, opdatere og slette poster.

      Datakontrolsprog: Beskæftiger sig med at give brugerne tilladelse til manipulation og adgang til dataene. Tilskud og tilbagekaldelse er de to anvendte udsagn.

      Tilskudsyntaks:
      Vælg / opdater tilskud
      På


      Til ;

      Tilbagekald syntaks:
      Genkald valg / opdatering
      på


      fra;

      Nogle praktiske tip

      # 1) Skriv selv forespørgsler:

      For at teste databasen nøjagtigt skal testeren have meget godt kendskab til SQL- og DML-udsagn (Data Manipulation Language). Testeren skal også kende AUT's interne DB-struktur.

      Du kan kombinere GUI og dataverifikation i respektive tabeller for bedre dækning. Hvis du bruger SQL-serveren, kan du bruge SQL Query Analyzer til at skrive forespørgsler, udføre dem og hente resultater.

      Dette er den bedste og robuste måde at teste en database på, når applikationen er af et lille eller medium niveau af kompleksitet.

      Hvis applikationen er meget kompleks, kan det være svært eller umuligt for testeren at skrive alle de krævede SQL-forespørgsler. Ved komplekse forespørgsler tager du hjælp fra udvikleren. Jeg anbefaler altid denne metode, da den giver dig tillid til test og også forbedrer dine SQL-færdigheder.

      # 2) Overhold dataene i hver tabel:

      Du kan udføre dataverificering ved hjælp af resultaterne af CRUD-operationer. Dette kan gøres manuelt ved hjælp af applikationsgrænsefladen, når du kender databaseintegrationen. Men dette kan være en kedelig og besværlig opgave, når der er enorme data i forskellige databasetabeller.

      Til manuel datatestning skal databasetesteren have et godt kendskab til databasetabellens struktur.

      # 3) Få forespørgsler fra udviklerne:

      Dette er den enkleste måde at teste databasen på. Udfør enhver CRUD-operation fra GUI, og kontroller dens virkninger ved at udføre de respektive SQL-forespørgsler, der er opnået fra udvikleren. Det kræver hverken et godt kendskab til SQL eller kræver et godt kendskab til applikationens DB-struktur.

      Men denne metode skal bruges med forsigtighed. Hvad hvis forespørgslen fra udvikleren er semantisk forkert eller ikke opfylder brugerens krav korrekt? Processen vil simpelthen ikke validere data.

      # 4) Benyt dig af databaseautomatiseringstestværktøjer:

      Der er flere værktøjer til rådighed til datatestprocessen. Du skal vælge det rigtige værktøj efter dine behov og udnytte det bedst muligt.

      => Her er listen over de TOP DB-testværktøjer, du skal kontrollere

      Konklusion

      Med alle disse funktioner, faktorer og processer til test i en database er der et stigende behov for, at testere er teknisk dygtige i de vigtigste databasekoncepter. På trods af nogle af de negative overbevisninger om, at test af en database skaber nye flaskehalse og er en masse ekstra udgifter - dette er et område af test, der tiltrækker betydelig opmærksomhed og efterspørgsel.

      Foreslået læsning = >> Hvad er databasesikkerhedstest

      Jeg håber, at denne vejledning har hjulpet med at fokusere på, hvorfor det er sådan, og har også givet dig de grundlæggende detaljer om, hvad der går i at teste en database.

      Fortæl os venligst din feedback, og del også dine personlige oplevelser, hvis du arbejder på DB-test.

      Anbefalet læsning

      ^