Databasetest - Database testing

Databasetestning består normalt af en lagdelt proces, herunder brugergrænsefladeslaget (UI), forretningslaget, dataadgangslaget og selve databasen. UI-laget beskæftiger sig med interface-design af databasen, mens business-laget inkluderer databaser, der understøtter forretningsstrategier .

Formål

Databaser , indsamling af sammenkoblede filer på en server, lagring af information, behandler muligvis ikke den samme type data, dvs. databaser kan være heterogene . Som et resultat, mange slags implementering og integration fejl kan forekomme i store databasesystemer, som har en negativ indflydelse på systemets ydeevne, pålidelighed, konsistens og sikkerhed. Det er således vigtigt at teste for at opnå et databasesystem, der tilfredsstiller ACID- egenskaberne (Atomicitet, konsistens, isolering og holdbarhed) i et databasesystem .

Et af de mest kritiske lag er dataadgangslaget, der beskæftiger sig med databaser direkte under kommunikationsprocessen. Databasetest finder hovedsageligt sted på dette lag og involverer teststrategier som kvalitetskontrol og kvalitetssikring af produktdatabaser. Testning ved disse forskellige lag bruges ofte til at opretholde konsistensen af ​​databasesystemer, mest set i de følgende eksempler:

  • Data er kritiske set fra et forretningssynspunkt. Virksomheder som Google eller Symantec , der er tilknyttet datalagring , skal have et holdbart og konsistent databasesystem. Hvis databasefunktioner såsom indsættelse, sletning og opdatering udføres uden først at teste databasen for konsistens, risikerer virksomheden et nedbrud af hele systemet.
  • Nogle virksomheder har forskellige typer databaser og også forskellige mål og missioner. For at opnå et niveau af funktionalitet for at nå de nævnte mål, skal de teste deres databasesystem.
  • Den nuværende testmetode er muligvis ikke tilstrækkelig, hvor udviklere formelt tester databaser. Denne tilgang er dog ikke tilstrækkelig effektiv, da databaseudviklere sandsynligvis vil bremse testprocessen på grund af kommunikationshuller. Et særskilt databasetesthold synes tilrådeligt.
  • Databasetest beskæftiger sig primært med at finde fejl i databaserne for at eliminere dem. Dette forbedrer kvaliteten af ​​databasen eller det webbaserede system.
  • Databasetest skal skelnes fra strategier til håndtering af andre problemer såsom databasekrascher, ødelagte indsættelser, sletninger eller opdateringer. Her er database refactoring en evolutionsteknik, der kan anvendes.

Typer af test og processer

Test af sort boks og hvid boks i databasetest

Figuren angiver de testområder, der er involveret i forskellige databasetestmetoder, såsom sort-boks-test og hvid-boks-test .

Sort kasse

Black-box test involverer test af grænseflader og integration af databasen, som inkluderer:

  1. Kortlægning af data (inklusive metadata )
  2. Bekræftelse af indgående data
  3. Bekræftelse af udgående data fra forespørgselfunktioner
  4. Forskellige teknikker såsom årsag effekt grafik teknik, ækvivalens partitionering og grænse-værdi analyse .

Ved hjælp af disse teknikker kan databasens funktionalitet testes grundigt.

Fordele og ulemper ved sort boks test inkluderer: Generering af test tilfælde i sort boks test er ret simpelt. Deres generation er helt uafhængig af softwareudvikling og kan gøres i et tidligt udviklingsstadium. Som en konsekvens har programmøren bedre viden om, hvordan man designer databaseapplikationen, og bruger mindre tid til fejlfinding. Omkostninger til udvikling af sorte boks test tilfælde er lavere end udviklingen af ​​hvide boks test sager. Den største ulempe ved test af black box er, at det er ukendt, hvor meget af programmet der testes. Visse fejl kan heller ikke detekteres.

Hvid boks

White-box-test handler primært om den interne struktur i databasen. Specifikationsoplysningerne er skjult for brugeren.

  1. Det involverer testning af databasetriggere og logiske synspunkter, som understøtter refactoring af database .
  2. Det udfører modultest af databasefunktioner, udløsere, visninger, SQL- forespørgsler osv.
  3. Det validerer databasetabeller, datamodeller, databaseskema osv.
  4. Det kontrollerer reglerne for henvisningens integritet .
  5. Det vælger standardtabelværdier for at kontrollere databaskonsistens.
  6. De teknikker, der anvendes i test af hvid boks, er tilstandsdækning, beslutningsdækning, udsagnsdækning , cyclomatisk kompleksitet .

Den største fordel ved testning af hvidboks i databasetestning er, at der registreres kodningsfejl, så interne fejl i databasen kan elimineres. Begrænsningen ved test af hvidboks er, at SQL-sætninger ikke er dækket.

WHODATE-tilgangen

WHODATE-tilgang til SQL-sætningstransformation

Mens der genereres testcases til databasetest, skal semantikken i SQL-sætningen afspejles i testcases. Til dette formål anvendes en teknik kaldet WHite bOx Database Application Technique "(WHODATE)". Som vist i figuren konverteres SQL-udsagn uafhængigt til GPL-sætninger efterfulgt af traditionel testning af hvid boks for at generere testsager, der inkluderer SQL-semantik.

Fire etaper

  • Indstil armatur
  • Test løb
  • Resultatbekræftelse
  • Rive ned

En sæt fixtur beskriver den oprindelige tilstand for databasen, inden den går ind i testen. Efter indstilling af inventar testes databaseadfærd for definerede testsager. Afhængigt af resultatet ændres testsagerne enten eller holdes som de er. "Riv ned" -stadiet resulterer enten i at afslutte test eller fortsætte med andre testsager.

For vellykket databasetest udføres almindeligvis følgende arbejdsgang, der udføres af hver enkelt test:

  1. Ryd op i databasen: Hvis de testbare data allerede findes i databasen, skal databasen tømmes.
  2. Konfigurer Fixture: Et værktøj som PHPUnit gentager derefter fixtures og udfører indsættelser i databasen.
  3. Kør test, verificer resultatet, og riv derefter ned: Efter at nulstille databasen til at være tømt og liste over inventar, køres testen og output bekræftes. Hvis output er som forventet, følger nedrivningsprocessen, ellers gentages test.

Grundlæggende teknikker

  • SQL Query Analyzer er et nyttigt værktøj, når du bruger Microsoft SQL Server .
  • En almindeligt anvendt funktion, create_input_dialog["label"] anvendes til at validere output med brugerindgange.
  • Udformningen af ​​formularer til automatisk databasetest, formular front-end og back-end, er nyttigt for databasevedligeholdelsesarbejdere.
  • Data, belastning test :
    • Til dataladningstest kræves viden om kildedatabase og destinationsdatabase.
    • Arbejdstagere kontrollerer kompatibiliteten mellem kildedatabase og destinationsdatabase ved hjælp af DTS- pakken.
    • Ved opdatering af kildedatabasen skal arbejdstagere sørge for at sammenligne den med måldatabasen.
    • Test af databasebelastning måler databaseserverens kapacitet til at håndtere forespørgsler såvel som responstid for databaseserver og klient.
  • I databasetestning overvejes ofte spørgsmål som atomicitet, konsistens, isolering, holdbarhed, integritet, udførelse af udløsere og gendannelse.
  1. Opsætningen til databasetest er dyr og kompleks at vedligeholde, fordi databasesystemer konstant ændres med forventede indsætnings-, sletnings- og opdateringsoperationer.
  2. Ekstra omkostninger er involveret for at bestemme tilstanden for databasetransaktionerne.
  3. Efter at have ryddet op i databasen skal nye testtilfælde designes.
  4. En SQL-generator er nødvendig for at omdanne SQL-sætninger for at inkludere SQL-semantikken i databasetesttilfælde.


Se også

Referencer

eksterne links