Vejledning til databasetestning

GUI'en lægges normalt mest vægt på af test- og udviklingsteammedlemmerne, da den grafiske brugergrænseflade tilfældigvis er den mest synlige del af applikationen. Det, der dog også er vigtigt, er at validere de oplysninger, der er kernen i applikationen, også kaldet DATABASE.

Lad os overveje en bankapplikation, hvor en bruger foretager transaktioner. Nu fra Database Testing eller DB Testing synspunkt følgende, er tingene vigtige:

1. Applikationen gemmer transaktionsoplysningerne i applikationsdatabasen og viser dem korrekt til brugeren.
2. Ingen information går tabt i processen.
3. Ingen delvist udført eller afbrudt operationsinformation gemmes af applikationen.
4. Ingen uautoriseret person har tilladelse til at få adgang til brugerens oplysninger.

For at sikre alle disse ovennævnte mål skal vi bruge datavalidering eller datatestning.

Forskelle mellem test af brugergrænseflade og datatest

Test af brugergrænseflade	Database eller datatest
Denne type test er også kendt som Graphical User Interface testing eller Front-end Testing.	Denne type test er også kendt som Backend Testing eller datatest.
Denne type test beskæftiger sig hovedsageligt med alle de testbare elementer, der er åbne for brugeren for seertal og interaktion såsom formularer, præsentationer, grafer, menuer og rapporter osv. (oprettet gennem VB, VB.net, VC++, Delphi – Frontend-værktøjer)	Denne type test beskæftiger sig hovedsageligt med alle de testbare elementer, der generelt er skjult for brugeren til seertal. Disse omfatter interne processer og opbevaring som Assembly, DBMS som Oracle, SQL Server, MYSQL osv.
Denne type test inkluderer validering af tekstbokse vælg dropdowns kalendere og knapper Side navigation visning af billeder Udseende og fornemmelse af den overordnede applikation	Denne type test involverer validering af: skemaet database tabeller kolonner nøgler og indekser lagrede procedurer udløser validering af databaseservere validering af dataduplikering
Testeren skal have et grundigt kendskab til forretningskravene samt brugen af ​​udviklingsværktøjerne og brugen af ​​automatiseringsrammer og værktøjer.	For at kunne udføre backend-test, skal testeren have en stærk baggrund i databaseserveren og Structured Query Language-koncepter.

Typer af databasetestning

De 3 typer af databasetest er

1. Strukturel afprøvning
2. Funktionstest
3. Ikke-funktionel test

I denne selvstudie til databasetestning vil vi se på hver type og dens undertyper én efter én.

Hvad er skematestning?

Skema test i databasetestning validerer forskellige skemaformater forbundet med databasen og verificerer, om kortlægningsformaterne for tabeller/visninger/kolonner er kompatible med kortlægningsformater af brugergrænsefladen. Hovedformålet med skematest er at sikre, at skematilknytningen mellem front-end og back-end er ens. Således omtales det også som kortlægningstest.

Lad os diskutere de vigtigste kontrolpunkter for skematestning.

1. Validering af de forskellige skemaformater tilknyttet databaserne. Mange gange er tabellens kortlægningsformat muligvis ikke kompatibelt med det kortlægningsformat, der findes på applikationens brugergrænsefladeniveau.
2. Der er behov for verifikation i tilfælde af ikke-kortlagte tabeller/visninger/kolonner.
3. Der er også behov for at verificere, om heterogene databaser i et miljø er i overensstemmelse med den overordnede applikationskortlægning.

Lad os også se på nogle af de interessante databasetestværktøjer til validering af databaseskemaer.

• DBUnit der er integreret med Ant er meget velegnet til kortlægningstest.
• SQL Server giver testerne mulighed for at kontrollere og forespørge databasens skema ved at skrive simple forespørgsler og ikke gennem kode.

Hvis udviklerne f.eks. ønsker at ændre en tabelstruktur eller slette den, vil testeren gerne sikre, at alle de lagrede procedurer og visninger, der bruger denne tabel, er kompatible med den pågældende ændring. Et andet eksempel kunne være, at hvis testerne vil tjekke for skemaændringer mellem 2 databaser, kan de gøre det ved at bruge simple forespørgsler.

Databasetabel, kolonnetest

Lad os se nærmere på forskellige kontroller til database- og kolonnetest.

1. Om kortlægningen af ​​databasefelterne og -kolonnerne i backend er kompatibel med disse tilknytninger i frontend?
2. Validering af længden og navnekonventionen for databasefelterne og -kolonnerne som specificeret af kravene.
3. Validering af tilstedeværelsen af ​​ubrugte/utilknyttede databasetabeller/kolonner.
4. Validering af kompatibiliteten af

• datatype
• feltlængder

af back-end-databasekolonnerne med dem, der er til stede i forenden af ​​applikationen.

5. Om databasefelterne giver brugeren mulighed for at give de ønskede brugerinput som krævet af forretningskravspecifikationsdokumenterne.

Test af nøgler og indekser

Vigtige kontroller for nøgler og indekser –

1. Kontroller, om den nødvendige

• Primærnøgle
• Fremmed nøgle

der er oprettet begrænsninger på de påkrævede tabeller.

2. Kontroller, om referencerne for fremmednøgler er gyldige.
3. Kontroller, om datatypen for den primære nøgle og de tilsvarende fremmednøgler er ens i de to tabeller.
4. Kontroller, om de påkrævede navnekonventioner er blevet fulgt for alle nøgler og indekser.
5. Tjek størrelsen og længden af ​​de påkrævede felter og indekser.
6. Om det påkrævede

• Clustered indekser
• Ikke Clustered indekser

er blevet oprettet på de påkrævede tabeller som specificeret af forretningskravene.

Test af lagrede procedurer

Vigtige tests for at kontrollere lagrede procedurer er:

1. Om udviklingsteamet overtog de påkrævede, A) kodningsstandardkonventioner og B) undtagelses- og fejlhåndtering. For alle de lagrede procedurer for alle moduler til den applikation, der testes.
2. Om udviklingsteamet dækkede alle betingelserne/sløjferne ved at anvende de nødvendige inputdata til applikationen under test?
3. Om udviklingsteamet anvendte TRIM-operationen korrekt, hver gang data hentes fra de påkrævede tabeller i databasen?
4. Om den manuelle udførelse af den lagrede procedure giver slutbrugeren det ønskede resultat?
5. Om den manuelle udførelse af den lagrede procedure sikrer, at tabelfelterne opdateres som krævet af den applikation, der testes?
6. Om udførelsen af ​​de lagrede procedurer muliggør implicit påberåbelse af de nødvendige triggere?
7. Validering af tilstedeværelsen af ​​ubrugte lagrede procedurer.
8. Validering for Tillad null-tilstand, som kan udføres på databaseniveau.
9. Validering af det faktum, at alle de lagrede procedurer og funktioner er blevet udført med succes, når databasen under test er tom.
10. Validering af den overordnede integration af de lagrede proceduremoduler i henhold til kravene til den applikation, der testes.

Nogle af de nyttige databasetestværktøjer til at teste lagrede procedurer er LINQ, SP Testværktøj osv.

Trigger test

1. Om de påkrævede kodningskonventioner er blevet fulgt under kodningsfasen af ​​triggerne?
2. Kontroller, om de udførte triggere for de respektive DML-transaktioner har opfyldt de påkrævede betingelser.
3. Om triggeren opdaterer dataene korrekt, når de er blevet udført?
4. Validering af den påkrævede opdatering/indsæt/slet udløser funktionalitet i den applikation, der testes.

Databaseservervalideringer

1. Kontroller databaseserverens konfigurationer som specificeret af forretningskravene.
2. Kontroller godkendelsen af ​​den påkrævede bruger til kun at udføre de handlingsniveauer, der kræves af applikationen.
3. Tjek, at databaseserveren er i stand til at imødekomme behovene for det maksimalt tilladte antal brugertransaktioner som specificeret i forretningskravspecifikationerne.

Funktionel databasetest

Funktionel databasetest er en type databasetest, der bruges til at validere de funktionelle krav til en database fra slutbrugerens perspektiv. Hovedformålet med funktionel databasetest er at teste, om de transaktioner og operationer, der udføres af slutbrugerne, som er relateret til databasen, fungerer som forventet eller ej.

Følgende er de grundlæggende betingelser, der skal overholdes for databasevalideringer.

• Om feltet er obligatorisk, mens det tillader NULL-værdier på det felt?
• Om længden af ​​hvert felt er af tilstrækkelig størrelse?
• Om alle lignende felter har de samme navne på tværs af tabeller?
• Om der er nogen beregnede felter til stede i databasen?

Denne særlige proces er valideringen af ​​feltkortlægningerne fra slutbrugerens synspunkt. I dette særlige scenarie vil testeren udføre en operation på databaseniveau og derefter navigere til det relevante brugergrænsefladeelement for at observere og validere, om de korrekte feltvalideringer er blevet udført eller ej.

Den omvendte betingelse, hvor den første operation udføres af testeren på brugergrænsefladen, og derefter det samme valideres fra bagenden, bør også udføres.

Kontrol af dataintegritet og konsistens

Følgende kontroller er vigtige

1. Om dataene er logisk velorganiserede?
2. Om dataene i tabellerne er korrekte og i overensstemmelse med forretningskravene?
3. Om der er unødvendige data i den applikation, der testes?
4. Om dataene er blevet lagret i henhold til kravet med hensyn til data, der er blevet opdateret fra brugergrænsefladen?
5. Om TRIM-operationerne udført på dataene før indsættelse af data i databasen under test?
6. Om transaktionerne er udført i henhold til forretningskravspecifikationerne, og om resultaterne er korrekte eller ej?
7. Om dataene er blevet korrekt begået, hvis transaktionen er blevet gennemført med succes?
8. Om dataene er blevet rullet tilbage med succes, hvis transaktionen ikke er blevet gennemført med succes af slutbrugeren?
9. Om dataene er blevet rullet tilbage, hvis transaktionen ikke er blevet gennemført med succes, og flere heterogene databaser har været involveret i den pågældende transaktion?
10. Om alle transaktioner er blevet udført ved at bruge de påkrævede designprocedurer som specificeret af systemets forretningskrav?

Login og brugersikkerhed

Valideringerne af login og brugersikkerhedslegitimationsoplysninger skal tage hensyn til følgende ting.

1. Om applikationen forhindrer brugeren i at gå videre i applikationen i tilfælde af en

• ugyldigt brugernavn men gyldig adgangskode
• gyldigt brugernavn, men ugyldig adgangskode.
• ugyldigt brugernavn og ugyldig adgangskode.

2. Om brugeren kun må udføre de specifikke operationer, som er specificeret af forretningskravene?
3. Om dataene er sikret mod uautoriseret adgang?
4. Om der er oprettet forskellige brugerroller med forskellige tilladelser?
5. Om alle brugerne har påkrævet adgangsniveauer til den angivne database som krævet af forretningsspecifikationerne?
6. Tjek, at følsomme data som adgangskoder, kreditkortnumre er krypteret og ikke gemt som almindelig tekst i databasen. Det er en god praksis at sikre, at alle konti skal have adgangskoder, der er komplekse og ikke lette at gætte.

Ikke-funktionel test

Ikke-funktionel test i forbindelse med databasetestning kan kategoriseres i forskellige kategorier som krævet af forretningskravene. Disse kan være belastningstest, stresstest, Sikkerhedstest, Usability Testingog Test af kompatibilitet, og så videre. Belastningstestningen såvel som stresstesten, som kan grupperes under spektret af Performance Testing, tjener to specifikke formål, når det kommer til rollen som ikke-funktionel test.

Risiko kvantificering– Kvantificering af risiko hjælper interessenterne med at fastslå de forskellige krav til systemets responstid under påkrævede belastningsniveauer. Dette er den oprindelige hensigt med enhver kvalitetssikring opgave. Vi er nødt til at bemærke, at belastningstestning ikke mindsker risikoen direkte, men gennem processerne med risikoidentifikation og risikokvantificering præsenterer korrigerende muligheder og en impuls til afhjælpning, der vil mindske risikoen.

Minimumskrav til systemudstyr– Den mindste systemkonfiguration, der vil gøre det muligt for systemet at opfylde de formelt angivne præstationsforventninger fra interessenterne. Så uvedkommende hardware, software og de tilhørende omkostninger ved ejerskab kan minimeres. Dette særlige krav kan kategoriseres som det overordnede krav til forretningsoptimering.

Load Testing

Formålet med enhver belastningstest skal klart forstås og dokumenteres. Følgende typer konfigurationer er et must for belastningstest.

1. De hyppigst anvendte brugertransaktioner har potentiale til at påvirke udførelsen af ​​alle de andre transaktioner, hvis de ikke er effektive.
2. Mindst én ikke-redigerende brugertransaktion bør inkluderes i den endelige testpakke, så udførelsen af ​​sådanne transaktioner kan adskilles fra andre mere komplekse transaktioner.
3. De vigtigere transaktioner, der letter systemets kernemål, bør inkluderes, da fejl under en belastning af disse transaktioner pr. definition har den største indvirkning.
4. Mindst én redigerbar transaktion skal inkluderes, så ydeevne af sådanne transaktioner kan adskilles fra andre transaktioner.
5. Optimal responstid under et stort antal virtuelle brugere til alle de potentielle krav.
6. Effektive tidspunkter for hentning af diverse poster.

Vigtige belastningstestværktøjer er LoadRunner Professional, vinde løber og JMeter.

Vigtige stresstestværktøjer er LoadRunner Professional og JMeter.

Mest almindeligt forekommende problemer under databasetest

A significant amount of overhead could be involved to determine the state of the database transactions

Opløsning: Den overordnede procesplanlægning og timing bør tilrettelægges, så der ikke opstår tids- og omkostningsbaserede problemer.

New test data have to be designed after cleaning up of the old test data.

Opløsning: En forudgående plan og metode til generering af testdata bør være ved hånden.

An SQL generator is required to transform SQL validators in order to ensure the SQL queries are apt for handling the required database test cases.

Opløsning: Vedligeholdelse af SQL-forespørgsler og deres løbende opdatering er en væsentlig del af den samlede testproces, som bør være en del af den samlede teststrategi.

The above mentioned prerequisite ensure that the set-up of the database testing procedure could be costly as well as time consuming.

Opløsning: Der bør være en fin balance mellem kvalitet og den overordnede projekttidsplans varighed.

Myter eller misforståelser relateret til databasetestning

Database Testing requires plenty of expertise and it is a very tedious job

Virkelighed: Effektiv og effektiv databasetest i softwaretest giver langsigtet funktionel stabilitet til den overordnede applikation, så det er nødvendigt at lægge hårdt arbejde bag sig.

Database testing adds extra work bottleneck

Virkelighed: Tværtimod tilfører databasetest mere værdi til det samlede arbejde ved at finde frem til skjulte problemer og dermed proaktivt være med til at forbedre den samlede applikation.

Database testing slows down the overall development process

Virkelighed: En betydelig mængde af databasetestning hjælper med den overordnede forbedring af kvaliteten af ​​databaseapplikationen.

Database testing could be excessively costly

Virkelighed: Enhver udgift til databasetest er en langsigtet investering, som fører til langsigtet stabilitet og robusthed af applikationen. Således udgifter til Databasetest eller SQL Test er nødvendigt.

Bedste Praksis

• Alle data inklusive metadata samt funktionelle data skal valideres i henhold til deres kortlægning af kravspecifikationsdokumenterne.
• Verifikation af testdata som er oprettet af / i samråd med udviklingsteamet skal valideres.
• Validering af outputdata ved at bruge både manuelle såvel som automatiseringsprocedurer.
• Implementering af forskellige teknikker såsom årsagsvirkningsgrafteknikken, ækvivalenspartitioneringsteknik og grænseværdianalyseteknik til generering af nødvendige testdatabetingelser.
• Valideringsreglerne for referenceintegritet for de påkrævede databasetabeller skal også valideres.
• Valget af standardtabelværdier til validering af databasekonsistens er et meget vigtigt koncept, om loghændelserne er blevet tilføjet i databasen for alle nødvendige loginhændelser
• Udføres planlagte opgaver rettidigt?
• Tag rettidig backup af databasen.

Tjek også- Database Test Interview Spørgsmål & Svar