database testing complete guide why
En komplett guide til databasetesting med praktiske tips og eksempler:
Dataprogrammer er mer komplekse i disse dager med teknologier som Android og også med mange smarttelefonapps. Jo mer komplekse frontendene er, desto mer intrikate blir bakendene.
Så det er desto viktigere å lære om DB-testing og kunne validere databaser effektivt for å sikre sikkerhets- og kvalitetsdatabaser.
I denne opplæringen lærer du alt om datatesting - hvorfor, hvordan og hva du skal teste?
Databasen er en av de uunngåelige delene av et program.
Det spiller ingen rolle om det er en web, stasjonær eller mobil, klient-server, peer-to-peer, bedrift eller individuell virksomhet; databasen kreves overalt i backend.
Tilsvarende, enten det er helsevesen, økonomi, leasing, detaljhandel, postapplikasjon eller kontroll av et romskip; en database er alltid i aksjon bak scenen.
Når applikasjonens kompleksitet øker, dukker behovet for en sterkere og sikker database opp. På samme måte, for applikasjoner med høy transaksjonsfrekvens ( For eksempel, Bank- eller finansieringsapplikasjon), er nødvendigheten av et fullt utstyrt DB Tool koblet sammen.
I dag har vi store data som er store og komplekse som de tradisjonelle databasene ikke kan håndtere.
Det er flere Databaseverktøy er tilgjengelig i markedet For eksempel, MS-Access, MS SQL Server, SQL Server, Oracle, Oracle Financial, MySQL, PostgreSQL, DB2, Toad, Admirer, etc. Disse verktøyene varierer i pris, robusthet, funksjoner og sikkerhet. Hver av disse har sine egne fordeler og ulemper.
Hva du vil lære:
- Hvorfor teste databasen?
- Hva du skal teste (sjekkliste for databasetesting)
- Hvordan teste databasen (trinnvis prosess)
Hvorfor teste databasen?
Nedenfor ser vi hvorfor følgende aspekter av en DB skal valideres:
# 1) Datakartlegging
I programvaresystemer går data ofte frem og tilbake fra brukergrensesnittet (brukergrensesnitt) til backend DB og omvendt. Så dette er noen aspekter å se etter:
- Sjekk om feltene i UI / frontend-skjemaene er kartlagt konsekvent med de tilsvarende feltene i DB-tabellen. Vanligvis er denne kartinformasjonen definert i kravdokumentene.
- Hver gang en bestemt handling utføres i frontenden av et program, blir en tilsvarende CRUD-handling (Opprett, hent, oppdater og slett) påkalt i bakenden. En tester må sjekke om riktig handling påberopes, og om den påkalte handlingen i seg selv er vellykket eller ikke.
# 2) Validering av syreegenskaper
Atomisitet, konsistens, isolasjon og holdbarhet. Hver transaksjon en DB utfører, må overholde disse fire egenskapene.
- Atomisitet betyr at en transaksjon enten mislykkes eller går gjennom. Dette betyr at selv om en enkelt del av transaksjonen mislykkes, betyr det at hele transaksjonen har mislyktes. Vanligvis kalles dette 'alt-eller-ingenting' -regelen.
- Konsistens : En transaksjon vil alltid føre til at DB er gyldig
- Isolering : Hvis det er flere transaksjoner, og de blir utført samtidig, skal DB / resultatet være det samme som om de ble utført etter hverandre.
- Varighet : Når en transaksjon er gjort og begått, skal ingen eksterne faktorer som strømbrudd eller krasj kunne endre den
Foreslått lesing = >> MySQL Transaction Tutorial
# 3) Dataintegritet
For noen av de CRUD-operasjoner , de oppdaterte og siste verdiene / statusen for delte data skal vises på alle skjemaene og skjermbildene. Verdien skal ikke oppdateres på ett skjermbilde og vise en eldre verdi på en annen.
Når søknaden er under utførelse, vil sluttbruker bruker hovedsakelig ‘CRUD’-operasjonene som tilrettelegges av DB Tool .
C: Opprett - Når brukeren 'Lagrer' en hvilken som helst ny transaksjon, utføres 'Opprett'.
R: Hent - Når brukeren 'Søk' eller 'Vis' en hvilken som helst lagret transaksjon, utføres 'Hent' -operasjonen.
U: Oppdatering - Når brukeren 'Rediger' eller 'Endrer' en eksisterende post, utføres 'Oppdater' -operasjonen til DB.
D: Slett - Når en bruker 'Fjern' en hvilken som helst post fra systemet, utføres 'Slett' -operasjonen av DB.
Enhver databaseoperasjon utført av sluttbrukeren er alltid en av de ovennevnte fire.
Så utform DB-testtilfellene dine på en måte som inkluderer å sjekke dataene på alle stedene det ser ut for å se om det er konsekvent det samme.
# 4) Overensstemmelse med forretningsregler
Mer kompleksitet i databaser betyr mer kompliserte komponenter som relasjonelle begrensninger, utløsere, lagrede prosedyrer osv. Så testere må komme med passende SQL-spørsmål for å validere disse komplekse objektene.
Hva du skal teste (sjekkliste for databasetesting)
# 1) Transaksjoner
Når du tester transaksjoner er det viktig å sørge for at de tilfredsstiller syreegenskapene.
Dette er utsagnene som ofte brukes:
- BEGIN TRANSAKSJON TRANSAKSJON #
- SLUTT TRANSAKSJON TRANSAKSJON #
Tilbakemeldingsuttalelsen sørger for at databasen forblir i en konsistent tilstand.
- RULBACK TRANSAKSJON #
Etter at disse utsagnene er utført, bruker du Select for å sikre at endringene har blitt reflektert.
- VELG * FRA TABLENAVN
# 2) Databaseskjemaer
Et databaseskema er ikke annet enn en formell definisjon av hvordan dataene skal organiseres i en DB. For å teste det:
- Identifiser kravene som baseres på databasen. Eksempel Krav:
- Primære nøkler som skal opprettes før andre felt opprettes.
- Utenlandske nøkler skal være helt indeksert for enkel gjenfinning og søk.
- Feltnavn som begynner eller slutter med bestemte tegn.
- Felt med en begrensning på at visse verdier kan eller ikke kan settes inn.
- Bruk en av følgende metoder i henhold til relevansen:
- SQL-spørring DESC
for å validere skjemaet.
- Vanlige uttrykk for å validere navnene på de enkelte feltene og deres verdier
- Verktøy som SchemaCrawler
# 3) Utløsere
Når en bestemt hendelse finner sted på et bestemt bord, kan et stykke kode (en utløser) automatisk instrueres til å utføres.
For eksempel, en ny student ble med på en skole. Studenten tar to klasser: matematikk og naturfag. Studenten legges til 'studenttabellen'. En utløser kan legge studenten til de tilsvarende emnetabellene når han er lagt til studenttabellen.
Den vanlige metoden for å teste er å utføre SQL-spørringen innebygd i utløseren uavhengig først og registrere resultatet. Følg dette opp med å utføre utløseren som helhet. Sammenlign resultatene.
Disse testes i både Black-box og White-box testfasen.
test nettstedet mitt i forskjellige nettlesere
- Testing av hvit boks : Stubber og drivere brukes til å sette inn eller oppdatere eller slette data som vil føre til at utløseren blir påkalt. Den grunnleggende ideen er å bare teste DB alene, selv før integrasjonen med frontenderen (UI) er gjort.
- Black box testing :
til) Siden brukergrensesnittet og DB er integrasjon nå tilgjengelig; vi kan sette inn / slette / oppdatere data fra frontenden på en måte som utløseren blir påkalt. Etter det kan Select-setninger brukes til å hente DB-dataene for å se om utløseren var vellykket i å utføre den tiltenkte operasjonen.
b) Den andre måten å teste dette på er å laste direkte inn dataene som vil påkalle utløseren og se om den fungerer som forutsatt.
# 4) Lagrede prosedyrer
Lagrede prosedyrer ligner mer eller mindre på brukerdefinerte funksjoner. Disse kan påkalles av uttalelser om anropsprosedyre / utfør prosedyre, og utdataene er vanligvis i form av resultatsett.
Disse er lagret i RDBMS og er tilgjengelige for applikasjoner.
Disse testes også under:
- Testing av hvit boks: Stubber brukes til å påkalle de lagrede prosedyrene, og deretter blir resultatene validert mot forventede verdier.
- Black box testing: Utfør en operasjon fra frontenden (UI) av applikasjonen og sjekk for utførelsen av den lagrede prosedyren og dens resultater.
# 5) Feltbegrensninger
Standardverdien, unik verdi og utenlandsk nøkkel:
- Utfør en front-end-operasjon som utøver tilstanden til databaseobjektet
- Valider resultatene med en SQL-spørring.
Det er ganske enkelt å sjekke standardverdien for et bestemt felt. Det er en del av validering av forretningsregler. Du kan gjøre det manuelt, eller du kan bruke verktøy som QTP. Manuelt kan du utføre en handling som vil legge til andre verdier enn standardverdien for feltet fra frontenden og se om det resulterer i en feil.
Følgende er en eksempel på 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 av koden ovenfor er sant hvis standardverdien eksisterer, eller usann hvis den ikke gjør det.
Kontroll av den unike verdien kan gjøres nøyaktig slik vi gjorde for standardverdiene. Prøv å angi verdier fra brukergrensesnittet som bryter denne regelen, og se om det vises en feil.
Automasjon 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) ForUtenlandsk nøkkelbegrensningsvalidering bruker datalaster som direkte legger inn data som bryter begrensningen og ser om applikasjonen begrenser dem eller ikke. I tillegg til datainnlastingen på baksiden, må du også utføre front-UI-operasjonene på en måte som vil bryte begrensningene og se om den aktuelle feilen vises.
Data Testing Aktiviteter
Database Tester bør fokusere på følgende testaktiviteter:
# 1) Sørg for datakarting:
Data Mapping er en av nøkkelaspektene i databasen, og den bør testes grundig av alle programvaretester.
Forsikre deg om at kartleggingen mellom forskjellige skjemaer eller skjermer til AUT og dens DB ikke bare er nøyaktig, men også i henhold til designdokumentene (SRS / BRS) eller koden. I utgangspunktet må du validere kartleggingen mellom hvert frontend-felt med tilhørende backend-databasefelt.
For alle CRUD-operasjoner, må du kontrollere at respektive tabeller og poster er oppdatert når brukeren klikker 'Lagre', 'Oppdater', 'Søk' eller 'Slett' fra GUI for applikasjonen.
Hva du trenger for å bekrefte:
- Tabellkartlegging, kolonnekartlegging og datatypekartlegging.
- Slå opp datakartlegging.
- Riktig CRUD-operasjon påkalles for hver brukerhandling ved brukergrensesnittet.
- CRUD-operasjon er vellykket.
# 2) Sørg for ACID-egenskaper for transaksjoner:
ACID-egenskaper for DB-transaksjoner refererer til TIL tomisitet ’,‘ C onsistens ’,‘ Jeg solation ’og‘ D urabilitet ’. Riktig testing av disse fire egenskapene må gjøres under databasetestaktiviteten. Du må bekrefte at hver enkelt transaksjon tilfredsstiller ACID-egenskapene til databasen.
La oss ta et enkelt eksempel gjennom SQL-koden nedenfor:
CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));ACID-testtabellen vil ha to kolonner - A & B. Det er en integritetsbegrensning at summen av verdiene i A og B alltid skal være 100.
Atomicitetstest vil sikre at alle transaksjoner utført på denne tabellen er alt eller ingen, dvs. ingen poster oppdateres hvis noen trinn i transaksjonen mislykkes.
Konsistensprøve vil sikre at når verdien i kolonne A eller B oppdateres, forblir summen alltid 100. Det tillater ikke innsetting / sletting / oppdatering i A eller B hvis den totale summen er noe annet enn 100.
Isolasjonstest vil sikre at hvis to transaksjoner skjer samtidig og prøver å endre dataene i ACID-testtabellen, kjøres disse trekkene isolert.
Holdbarhetstest vil sikre at når en transaksjon over denne tabellen er begått, vil den forbli slik, selv i tilfelle strømbrudd, krasj eller feil.
Dette området krever mer grundige, grundige og ivrige tester hvis søknaden din bruker den distribuerte databasen.
# 3) Sikre dataintegritet
Tenk på at forskjellige moduler (dvs. skjermer eller former) for applikasjon bruker de samme dataene på forskjellige måter og utfører alle CRUD-operasjonene på dataene.
I så fall må du sørge for at den nyeste datatilstanden gjenspeiles overalt. Systemet må vise de oppdaterte og siste verdiene eller statusen til slike delte data på alle skjemaene og skjermbildene. Dette kalles som dataintegritet.
Test tilfeller for validering av databasedataintegritet:
- Sjekk om alle utløserne er på plass for å oppdatere referansetabelloppføringer.
- Sjekk om det er feil / ugyldige data i hovedkolonnene i hver tabell.
- Prøv å sette inn feil data i tabellene og se om det oppstår feil.
- Sjekk hva som skjer hvis du prøver å sette inn et barn før du setter inn foreldrene (prøv å leke med primære og utenlandske nøkler).
- Test om feil oppstår hvis du sletter en post som fremdeles refereres til av data i en hvilken som helst annen tabell.
- Sjekk om replikerte servere og databaser er synkronisert.
# 4) Forsikre deg om at implementerte forretningsregler er nøyaktige:
I dag er databaser ikke bare ment å lagre postene. Faktisk har databaser blitt utviklet til ekstremt kraftige verktøy som gir rikelig støtte til utviklerne for å implementere forretningslogikken på DB-nivå.
Noen enkle eksempler på kraftige funksjoner er 'Referential Integrity', Relational constraints, Triggers og lagrede prosedyrer.
Så ved hjelp av disse og mange andre funksjoner som tilbys av DB-er, implementerer utviklere forretningslogikken på DB-nivå. Testeren må sørge for at den implementerte forretningslogikken er korrekt og fungerer nøyaktig.
Ovennevnte punkter beskriver de fire viktigste ‘What To’ for å teste DB. Nå, la oss gå videre til 'How To' -delen.
Hvordan teste databasen (trinnvis prosess)
Den generelle testprosess-testdatabasen er ikke veldig forskjellig fra andre applikasjoner.
Følgende er kjernetrinnene:
Trinn 1) Forbered miljøet
Steg 2) Kjør en test
Trinn 3) Sjekk testresultatet
Trinn 4) Valider i henhold til forventede resultater
Trinn 5) Rapporter funnene til de respektive interessentene
Vanligvis brukes SQL-spørsmål til å utvikle testene. Den mest brukte kommandoen er 'Velg'.
Velg * hvorfra
Bortsett fra Select har SQL tre viktige typer kommandoer:
- DDL: Datadefinisjonsspråk
- DML: Datamanipuleringsspråk
- DCL: Datakontrollspråk
La oss se syntaksen for de mest brukte utsagnene.
Data Definisjon språk Bruker CREATE, ALTER, RENAME, DROP og TRUNCATE til å håndtere tabeller (og indekser).
Data Manipulation språk Inkluderer uttalelser for å legge til, oppdatere og slette poster.
Datakontrollspråk: Avtaler med å gi autorisasjon til brukere for manipulering og tilgang til dataene. Grant and Revoke er de to uttalelsene som brukes.
Gi syntaks:
Gi / velg tilskudd
På
Til ;Opphev syntaksen:
Opphev valg / oppdatering
på
fra;Noen praktiske tips
# 1) Skriv spørsmål selv:
For å teste databasen nøyaktig, bør testeren ha veldig god kunnskap om SQL- og DML-utsagn (Data Manipulation Language). Testeren bør også kjenne den interne DB-strukturen til AUT.
Du kan kombinere GUI og dataverifisering i respektive tabeller for bedre dekning. Hvis du bruker SQL-serveren, kan du bruke SQL Query Analyzer til å skrive spørsmål, utføre dem og hente resultater.
Dette er den beste og robuste måten å teste en database på når applikasjonen er av liten eller middels grad av kompleksitet.
Hvis applikasjonen er veldig kompleks, kan det være vanskelig eller umulig for testeren å skrive alle nødvendige SQL-spørsmål. For komplekse spørsmål tar du hjelp fra utvikleren. Jeg anbefaler alltid denne metoden da den gir deg tillit til testing og også forbedrer SQL-ferdighetene dine.
# 2) Observer dataene i hver tabell:
Du kan utføre dataverifisering ved hjelp av resultatene av CRUD-operasjoner. Dette kan gjøres manuelt ved å bruke applikasjonsgrensesnitt når du kjenner til databaseintegrasjonen. Men dette kan være en kjedelig og tungvint oppgave når det er enorme data i forskjellige databasetabeller.
For manuell datatesting må databasetesteren ha god kunnskap om databasetabellstruktur.
# 3) Få spørsmål fra utviklerne:
Dette er den enkleste måten å teste databasen på. Utfør en CRUD-operasjon fra GUI og verifiser dens innvirkning ved å utføre de respektive SQL-spørringene som er hentet fra utvikleren. Det krever verken god kunnskap om SQL eller krever god kunnskap om applikasjonens DB-struktur.
Men denne metoden må brukes med forsiktighet. Hva om spørringen fra utvikleren er semantisk feil eller ikke oppfyller brukerens krav riktig? Prosessen mislykkes ganske enkelt i å validere data.
# 4) Bruk verktøy for databaseautomatiseringstesting:
Det er flere verktøy tilgjengelig for datatestprosessen. Du bør velge riktig verktøy etter dine behov og utnytte det best.
=> Her er listen over TOP DB-testverktøy du bør sjekke
Konklusjon
Med alle disse funksjonene, faktorene og prosessene for å teste på en database, er det et økende behov for at testerne skal være teknisk dyktige i de viktigste databasekonseptene. Til tross for noen av de negative overbevisningene om at testing av en database skaper nye flaskehalser og er mye ekstrautgifter - dette er et testmiljø som vekker betydelig oppmerksomhet og etterspørsel.
Foreslått lesing = >> Hva er testing av databasesikkerhet
Jeg håper denne opplæringen har bidratt til å fokusere på hvorfor det er slik, og har også gitt deg de grunnleggende detaljene om hva som går ut i å teste en database.
Fortell oss tilbakemeldingene dine, og del også dine personlige erfaringer hvis du jobber med DB-testing.
Anbefalt lesing
- Databasetesting med JMeter
- 40+ beste databasetestverktøy - populære datatestløsninger
- En enkel tilnærming for XML til databasetesting
- ETL Testing Tutorial Data Warehouse Testing Tutorial (En komplett guide)
- Data Migration Testing Tutorial: A Complete Guide
- Topp 10 databasedesignverktøy for å bygge komplekse datamodeller
- Data Warehouse Testing Tutorial med eksempler | ETL Testing Guide
- Hvordan teste Oracle Database
^
- SQL-spørring DESC
