Databasetesting - Database testing

Databasetesting består vanligvis av en lagdelt prosess, inkludert brukergrensesnittlaget (UI), forretningslaget, datatilgangslaget og selve databasen. UI-laget håndterer grensesnittdesignen til databasen, mens virksomhetslaget inneholder databaser som støtter forretningsstrategier .

Formål

Databaser , innsamling av sammenkoblede filer på en server, lagring av informasjon, kan ikke håndtere samme type data, dvs. databaser kan være heterogene . Som et resultat av mange typer implementering og integrasjon feil kan forekomme i store databasesystemer, noe som negativt påvirker systemets ytelse, pålitelighet, konsistens og sikkerhet. Derfor er det viktig å teste for å oppnå et databasesystem som tilfredsstiller ACID- egenskapene (Atomicitet, Konsistens, Isolering og Holdbarhet) til et databasesystem .

Et av de mest kritiske lagene er datatilgangslaget, som håndterer databaser direkte under kommunikasjonsprosessen. Databasetesting foregår hovedsakelig ved dette laget og involverer teststrategier som kvalitetskontroll og kvalitetssikring av produktdatabasene. Testing på disse forskjellige lagene brukes ofte for å opprettholde konsistensen av databasesystemer, som oftest ses i følgende eksempler:

  • Data er kritiske fra et forretningsmessig synspunkt. Bedrifter som Google eller Symantec , som er tilknyttet datalagring , må ha et holdbart og konsistent databasesystem. Hvis databaseoperasjoner som innsetting, sletting og oppdatering utføres uten å teste databasen for konsistens først, risikerer selskapet en krasj av hele systemet.
  • Noen selskaper har forskjellige typer databaser, og også forskjellige mål og oppdrag. For å oppnå et nivå av funksjonalitet for å nå nevnte mål, må de teste databasesystemet sitt.
  • Den nåværende tilnærmingen til testing er kanskje ikke tilstrekkelig der utviklere formelt tester databasene. Denne tilnærmingen er imidlertid ikke tilstrekkelig effektiv siden databaseutviklere sannsynligvis vil bremse testprosessen på grunn av kommunikasjonshull. Et eget team for databasetesting virker å anbefale.
  • Databasetesting handler hovedsakelig om å finne feil i databasene for å eliminere dem. Dette vil forbedre kvaliteten på databasen eller det nettbaserte systemet.
  • Databasetesting bør skille seg fra strategier for å håndtere andre problemer som databasekrasj, ødelagte innsettinger, slettinger eller oppdateringer. Her er database refactoring en evolusjonær teknikk som kan gjelde.

Typer av tester og prosesser

Image
Svart boks og hvit boks testing i databasetest

Figuren indikerer testområdene som er involvert i forskjellige databasetestmetoder, for eksempel svart-boks-testing og hvit-boks-testing .

Svart boks

Black-box testing innebærer testing av grensesnitt og integrering av databasen, som inkluderer:

  1. Kartlegging av data (inkludert metadata )
  2. Bekreft innkommende data
  3. Bekrefte utgående data fra søkefunksjoner
  4. Ulike teknikker som Cause effect graphing technique, ekvivalenspartisjonering og grenseverdianalyse .

Ved hjelp av disse teknikkene kan databasens funksjonalitet testes grundig.

Fordeler og ulemper ved black box testing inkluderer: Generering av testsaker i black box testing er ganske enkelt. Generasjonen deres er helt uavhengig av programvareutvikling og kan gjøres i et tidlig utviklingsstadium. Som en konsekvens har programmereren bedre kunnskap om hvordan man designer databaseapplikasjonen og bruker kortere tid på feilsøking. Kostnadene for utvikling av blackbox-testtilfeller er lavere enn utviklingen av white box-testtilfeller. Den største ulempen med black box testing er at det er ukjent hvor mye av programmet som testes. Dessuten kan visse feil ikke oppdages.

Hvitboks

Hvitboks-testing omhandler hovedsakelig den interne strukturen i databasen. Spesifikasjonsdetaljene er skjult for brukeren.

  1. Det involverer testing av databaseutløsere og logiske visninger som skal støtte databaserefakturering .
  2. Den utfører modultesting av databasefunksjoner, utløsere, visninger, SQL- spørsmål etc.
  3. Den validerer databasetabeller, datamodeller, databaseskema etc.
  4. Den sjekker regler for referanseintegritet .
  5. Det velger standard tabellverdier for å kontrollere databasekonsistensen.
  6. Teknikkene som brukes i testbokser er tilstandsdekning, beslutningsdekning, utsagnsdekning , syklomatisk kompleksitet .

Hovedfordelen med testing av hvit boks i databasetesting er at kodingsfeil oppdages, slik at interne feil i databasen kan elimineres. Begrensningen med testing av hvit boks er at SQL-setninger ikke dekkes.

WHODATE-tilnærmingen

Image
WHODATE-tilnærming for transformasjon av SQL-setninger

Mens generere testsaker for databasetesting, må semantikken til SQL-setningen gjenspeiles i testsakene. For det formålet brukes en teknikk kalt WHite bOx Database Application Technique "(WHODATE)". Som vist i figuren blir SQL-setninger uavhengig konvertert til GPL-setninger, etterfulgt av tradisjonell test for hvit boks for å generere testsaker som inkluderer SQL-semantikk.

Fire trinn

  • Sett Fixture
  • Prøvekjøring
  • Resultatverifisering
  • Rive ned

En fast inventar beskriver den opprinnelige tilstanden til databasen før du går inn i testingen. Etter at du har satt inn inventar, blir databaseadferd testet for definerte testsaker. Avhengig av utfallet blir testtilfeller enten modifisert eller oppbevart som det er. "Riv ned" -fasen resulterer enten i å avslutte testingen eller fortsette med andre testsaker.

For vellykket databasetesting blir følgende arbeidsflyt utført av hver enkelt test ofte utført:

  1. Rydd opp i databasen: Hvis de testbare dataene allerede finnes i databasen, må databasen tømmes.
  2. Sett opp Fixture: Et verktøy som PHPUnit vil deretter iterere over inventar og gjøre innsettinger i databasen.
  3. Kjør test, verifiser utfallet og deretter rive ned: Etter at databasen er tilbakestilt til å tømmes og listen er oppført, kjøres testen og utdataene bekreftes. Hvis produksjonen er som forventet, følger nedrivingsprosessen, ellers gjentas testen.

Grunnleggende teknikker

  • SQL Query Analyzer er et nyttig verktøy når du bruker Microsoft SQL Server .
  • En ofte brukt funksjon create_input_dialog["label"] ,, brukes til å validere utdataene med brukerinnganger.
  • Utformingen av skjemaer for automatisert databasetesting, skjema front-end og back-end, er nyttig for databeholdsarbeidere.
  • Data lasttesting :
    • For testing av datalast kreves kunnskap om kildedatabase og destinasjonsdatabase.
    • Arbeidere sjekker kompatibiliteten mellom kildedatabase og destinasjonsdatabase ved hjelp av DTS- pakken.
    • Når du oppdaterer kildedatabasen, sørger arbeidstakere for å sammenligne den med måldatabasen.
    • Lastetesting av databaser måler kapasiteten til databaseserveren til å håndtere spørringer, samt responstiden til databaseserveren og klienten.
  • I databasetesting vurderes ofte spørsmål som atomicitet, konsistens, isolasjon, holdbarhet, integritet, utførelse av utløsere og gjenoppretting.
  1. Oppsettet for databasetesting er kostbart og komplisert å vedlikeholde fordi databasesystemer endres kontinuerlig med forventede innsettings-, slettings- og oppdateringsoperasjoner.
  2. Ekstra overhead er involvert for å bestemme tilstanden til databasetransaksjonene.
  3. Etter å ha ryddet opp i databasen, må nye testtilfeller utformes.
  4. En SQL-generator er nødvendig for å transformere SQL-setninger for å inkludere SQL-semantikken i databasetesttilfeller.


Se også

Referanser

Eksterne linker