Veiledning for databasetesting

GUI-en legges vanligvis mest vekt av test- og utviklingsteammedlemmene siden det grafiske brukergrensesnittet tilfeldigvis er den mest synlige delen av applikasjonen. Det som imidlertid også er viktig er å validere informasjonen som er hjertet i applikasjonen, også kalt DATABASE.

La oss vurdere en bankapplikasjon der en bruker foretar transaksjoner. Nå fra databasetesting eller DB-testing, er ting viktige:

1. Applikasjonen lagrer transaksjonsinformasjonen i applikasjonsdatabasen og viser dem riktig til brukeren.
2. Ingen informasjon går tapt i prosessen.
3. Ingen informasjon om delvis utført eller avbrutt operasjon lagres av applikasjonen.
4. Ingen uautoriserte personer har tilgang til brukerens informasjon.

For å sikre alle disse målene ovenfor, må vi bruke datavalidering eller datatesting.

Forskjeller mellom brukergrensesnitttesting og datatesting

Testing av brukergrensesnitt	Database eller datatesting
Denne typen testing er også kjent som Graphical User Interface-testing eller Front-end-testing.	Denne typen testing er også kjent som Backend-testing eller datatesting.
Denne typen testing omhandler hovedsakelig alle de testbare elementene som er åpne for brukeren for seerskare og interaksjon som skjemaer, presentasjoner, grafer, menyer og rapporter osv. (opprettet gjennom VB, VB.net, VC++, Delphi – grensesnittverktøy)	Denne typen testing omhandler hovedsakelig alle de testbare elementene som vanligvis er skjult for brukeren for seerskare. Disse inkluderer interne prosesser og lagring som Assembly, DBMS som Oracle, SQL Server, MYSQL, etc.
Denne typen testing inkluderer å validere tekstbokser velg rullegardinmenyene kalendere og knapper Sidenavigering visning av bilder Utseendet og følelsen av den generelle applikasjonen	Denne typen testing innebærer å validere: skjemaet databasetabeller kolonner nøkler og indekser utløser lagrede prosedyrer validering av databasetjenere validering av dataduplisering
Testeren må ha grundig kunnskap om forretningskravene samt bruken av utviklingsverktøyene og bruken av automatiseringsrammer og verktøy.	For å kunne utføre backend-testing, må testeren ha en sterk bakgrunn i databaseserveren og Structured Query Language-konsepter.

Typer databasetesting

De 3 typene databasetesting er

1. Strukturell testing
2. Funksjonell testing
3. Ikke-funksjonell testing

I denne veiledningen for databasetesting vil vi se nærmere på hver type og dens undertyper én etter én.

Hva er skjematesting?

Skjematesting i databasetesting validerer ulike skjemaformater knyttet til databasen og verifiserer om kartleggingsformatene til tabeller/visninger/kolonner er kompatible med kartleggingsformater for brukergrensesnitt. Hovedformålet med skjematesting er å sikre at skjematilordningen mellom front-end og back-end er like. Dermed omtales det også som kartleggingstesting.

La oss diskutere de viktigste sjekkpunktene for skjematesting.

1. Validering av de ulike skjemaformatene knyttet til databasene. Mange ganger er kartleggingsformatet til tabellen kanskje ikke kompatibelt med kartformatet som finnes på brukergrensesnittnivået til applikasjonen.
2. Det er behov for verifisering ved ikke-kartlagte tabeller/visninger/kolonner.
3. Det er også behov for å verifisere om heterogene databaser i et miljø stemmer overens med den generelle applikasjonskartleggingen.

La oss også se på noen av de interessante verktøyene for databasetesting for å validere databaseskjemaer.

• DBUnit som er integrert med Ant er meget godt egnet for kartleggingstesting.
• SQL Server lar testerne være i stand til å sjekke og spørre etter skjemaet til databasen ved å skrive enkle spørringer og ikke gjennom kode.

For eksempel, hvis utviklerne ønsker å endre en tabellstruktur eller slette den, vil testeren sikre at alle lagrede prosedyrer og visninger som bruker den tabellen er kompatible med den aktuelle endringen. Et annet eksempel kan være at hvis testerne ønsker å se etter skjemaendringer mellom 2 databaser, kan de gjøre det ved å bruke enkle spørringer.

Databasetabell, kolonnetesting

La oss se nærmere på ulike kontroller for database- og kolonnetesting.

1. Om tilordningen av databasefeltene og -kolonnene i backend er kompatibel med disse tilordningene i front-end?
2. Validering av lengden og navnekonvensjonen til databasefeltene og -kolonnene som spesifisert av kravene.
3. Validering av tilstedeværelsen av ubrukte/ikke-tilordnede databasetabeller/kolonner.
4. Validering av kompatibiliteten til

• data-type
• feltlengder

av backend-databasekolonnene med kolonnene til de som er tilstede i frontenden av applikasjonen.

5. Hvorvidt databasefeltene lar brukeren gi ønsket brukerinndata som kreves av dokumentene for forretningskravspesifikasjonene.

Testing av nøkler og indekser

Viktige kontroller for nøkler og indekser –

1. Sjekk om nødvendig

• Primærnøkkel
• Foreign Key

begrensninger er opprettet på de nødvendige tabellene.

2. Sjekk om referansene for fremmednøkler er gyldige.
3. Sjekk om datatypen til primærnøkkelen og de tilsvarende fremmednøklene er de samme i de to tabellene.
4. Sjekk om de nødvendige navnekonvensjonene er fulgt for alle nøklene og indeksene.
5. Sjekk størrelsen og lengden på de nødvendige feltene og indeksene.
6. Om det er nødvendig

• Clustered indekser
• Ikke Clustered indekser

har blitt opprettet på de nødvendige tabellene som spesifisert av forretningskravene.

Testing av lagrede prosedyrer

Viktige tester for å sjekke lagrede prosedyrer er:

1. Hvorvidt utviklingsteamet tok i bruk de nødvendige, A) kodingsstandardkonvensjonene, og B) unntaks- og feilhåndtering. For alle de lagrede prosedyrene for alle modulene for applikasjonen som testes.
2. Om utviklingsteamet dekket alle forholdene/løkkene ved å bruke de nødvendige inndataene til applikasjonen som testes?
3. Om utviklingsteamet brukte TRIM-operasjonen riktig når data hentes fra de nødvendige tabellene i databasen?
4. Om manuell utførelse av den lagrede prosedyren gir sluttbrukeren det nødvendige resultatet?
5. Om manuell kjøring av den lagrede prosedyren sikrer at tabellfeltene oppdateres slik det kreves av applikasjonen som testes?
6. Om utførelsen av de lagrede prosedyrene muliggjør implisitt påkalling av de nødvendige triggerne?
7. Validering av tilstedeværelsen av ubrukte lagrede prosedyrer.
8. Validering for Tillat null-tilstand som kan gjøres på databasenivå.
9. Validering av det faktum at alle lagrede prosedyrer og funksjoner har blitt utført med suksess når databasen som testes er tom.
10. Validering av den generelle integrasjonen av de lagrede prosedyremodulene i henhold til kravene til applikasjonen som testes.

Noen av de nyttige databasetestingsverktøyene for å teste lagrede prosedyrer er LINQ, SP Testverktøy etc.

Triggertesting

1. Om de nødvendige kodekonvensjonene har blitt fulgt under kodingsfasen av triggerne?
2. Sjekk om utløserne som er utført for de respektive DML-transaksjonene har oppfylt de nødvendige betingelsene.
3. Om utløseren oppdaterer dataene riktig når de er utført?
4. Validering av den nødvendige Oppdatering/Sett inn/Slett utløser funksjonalitet i området til applikasjonen som testes.

Databaseservervalideringer

1. Sjekk databaseserverkonfigurasjonene som spesifisert av forretningskravene.
2. Sjekk autorisasjonen til den nødvendige brukeren til å utføre bare de handlingsnivåene som kreves av applikasjonen.
3. Sjekk at databaseserveren er i stand til å imøtekomme behovene til det maksimalt tillatte antallet brukertransaksjoner som spesifisert i forretningskravspesifikasjonene.

Funksjonell databasetesting

Funksjonell databasetesting er en type databasetesting som brukes til å validere funksjonskravene til en database fra sluttbrukerens perspektiv. Hovedmålet med funksjonell databasetesting er å teste om transaksjonene og operasjonene utført av sluttbrukerne som er relatert til databasen fungerer som forventet eller ikke.

Følgende er de grunnleggende betingelsene som må overholdes for databasevalidering.

• Om feltet er obligatorisk mens du tillater NULL-verdier i det feltet?
• Om lengden på hvert felt er av tilstrekkelig størrelse?
• Om alle lignende felt har samme navn på tvers av tabeller?
• Om det er noen beregnede felt i databasen?

Denne spesielle prosessen er valideringen av felttilordningene fra sluttbrukerens synspunkt. I dette spesielle scenariet vil testeren utføre en operasjon på databasenivå og deretter navigere til det relevante brukergrensesnittelementet for å observere og validere om de riktige feltvalideringene har blitt utført eller ikke.

Den omvendte tilstanden der den første operasjonen utføres av testeren ved brukergrensesnittet, og deretter det samme valideres fra baksiden, bør også gjøres.

Sjekke dataintegritet og konsistens

Følgende kontroller er viktig

1. Om dataene er logisk godt organisert?
2. Om dataene som er lagret i tabellene er korrekte og i henhold til forretningskravene?
3. Om det finnes unødvendige data i applikasjonen som testes?
4. Om dataene er lagret i henhold til kravet med hensyn til data som er oppdatert fra brukergrensesnittet?
5. Om TRIM-operasjonene utført på dataene før data ble satt inn i databasen som testes?
6. Om transaksjonene er utført i henhold til forretningskravspesifikasjonene og om resultatene er korrekte eller ikke?
7. Hvorvidt dataene har blitt riktig forpliktet hvis transaksjonen er vellykket utført?
8. Om dataene har blitt rullet tilbake på en vellykket måte hvis transaksjonen ikke er utført av sluttbrukeren?
9. Om dataene har blitt rullet tilbake hvis transaksjonen ikke har blitt utført vellykket og flere heterogene databaser har vært involvert i den aktuelle transaksjonen?
10. Om alle transaksjonene har blitt utført ved å bruke de nødvendige designprosedyrene som spesifisert av systemets forretningskrav?

Innlogging og brukersikkerhet

Valideringen av påloggings- og brukersikkerhetslegitimasjonen må ta hensyn til følgende ting.

1. Om applikasjonen hindrer brukeren i å gå videre i applikasjonen i tilfelle en

• ugyldig brukernavn men gyldig passord
• gyldig brukernavn, men ugyldig passord.
• ugyldig brukernavn og ugyldig passord.

2. Om brukeren har lov til å utføre bare de spesifikke operasjonene som er spesifisert av forretningskravene?
3. Om dataene er sikret mot uautorisert tilgang?
4. Om det er opprettet ulike brukerroller med ulike tillatelser?
5. Om alle brukerne har nødvendige tilgangsnivåer på den spesifiserte databasen som kreves av forretningsspesifikasjonene?
6. Sjekk at sensitive data som passord, kredittkortnumre er kryptert og ikke lagret som ren tekst i databasen. Det er en god praksis å sikre at alle kontoer skal ha passord som er komplekse og som ikke er enkle å gjette.

Ikke-funksjonell testing

Ikke-funksjonell testing i sammenheng med databasetesting kan kategoriseres i ulike kategorier som kreves av forretningskravene. Disse kan være belastningstesting, stresstesting, Sikkerhetstesting, Brukervennlighetstestingog Test av kompatibilitet, og så videre. Belastningstestingen, så vel som stresstestingen, som kan grupperes under spekteret av ytelsestesting, tjener to spesifikke formål når det kommer til rollen som ikke-funksjonell testing.

Risiko kvantifisering– Kvantifisering av risiko hjelper interessentene til å fastslå de ulike systemenes responstidskrav under nødvendige belastningsnivåer. Dette er den opprinnelige intensjonen til enhver kvalitetssikring oppgave. Vi må merke oss at belastningstesting ikke reduserer risiko direkte, men gjennom prosessene med risikoidentifikasjon og risikokvantifisering presenterer korrigerende muligheter og en drivkraft for utbedring som vil redusere risiko.

Minimumskrav til systemutstyr– Minimum systemkonfigurasjon som gjør at systemet kan møte de formelt uttalte ytelsesforventningene til interessentene. Slik at overflødig maskinvare, programvare og tilhørende eierkostnader kan minimeres. Dette spesielle kravet kan kategoriseres som det generelle kravet til forretningsoptimalisering.

Load Testing

Hensikten med enhver lasttest bør være klart forstått og dokumentert. Følgende typer konfigurasjoner er et must for lastetesting.

1. De mest brukte brukertransaksjonene har potensial til å påvirke ytelsen til alle de andre transaksjonene hvis de ikke er effektive.
2. Minst én ikke-redigerende brukertransaksjon bør inkluderes i den endelige testpakken, slik at ytelsen til slike transaksjoner kan skilles fra andre mer komplekse transaksjoner.
3. De viktigere transaksjonene som letter kjernemålene til systemet bør inkluderes, da feil under en belastning av disse transaksjonene per definisjon har størst innvirkning.
4. Minst én redigerbar transaksjon bør inkluderes slik at ytelse av slike transaksjoner kan skilles fra andre transaksjoner.
5. Optimal responstid under et stort antall virtuelle brukere for alle potensielle krav.
6. Effektive tider for henting av ulike poster.

Viktige lasttestingsverktøy er LoadRunner Professional, vinn løper og JMeter.

Viktige stresstestingsverktøy er LoadRunner Professional og JMeter.

De vanligste problemene som oppstår under databasetesting

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

Løsning: Den overordnede prosessplanleggingen og timingen bør organiseres slik at ingen tids- og kostnadsbaserte problemer oppstår.

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

Løsning: En forhåndsplan og metodikk for generering av testdata bør foreligge.

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.

Løsning: Vedlikehold av SQL-spørringene og deres kontinuerlige oppdatering er en betydelig del av den totale testprosessen som bør være en del av den generelle teststrategi.

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

Løsning: Det bør være en fin balanse mellom kvalitet og den totale varigheten av prosjektplanen.

Myter eller misoppfatninger knyttet til databasetesting

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

Virkelighet: Effektiv og effektiv databasetesting i programvaretesting gir langsiktig funksjonell stabilitet til den generelle applikasjonen, så det er nødvendig å legge ned hardt arbeid bak det.

Database testing adds extra work bottleneck

Virkelighet: Tvert imot, databasetesting gir mer verdi til det totale arbeidet ved å finne ut skjulte problemer og dermed proaktivt bidra til å forbedre den generelle applikasjonen.

Database testing slows down the overall development process

Virkelighet: Betydelig mengde databasetesting hjelper til med den generelle forbedringen av kvaliteten for databaseapplikasjonen.

Database testing could be excessively costly

Virkelighet: Eventuelle utgifter til databasetesting er en langsiktig investering som fører til langsiktig stabilitet og robusthet i applikasjonen. Dermed utgifter til databasetesting eller SQL Testing er nødvendig.

Beste praksis

• Alle data inkludert metadata så vel som funksjonelle data må valideres i henhold til deres kartlegging av kravspesifikasjonsdokumentene.
• Verifikasjon av testdata som er opprettet av / i samråd med utviklingsteamet må valideres.
• Validering av utdataene ved å bruke både manuelle så vel som automatiseringsprosedyrer.
• Utplassering av ulike teknikker som for eksempel årsaksvirkningsgrafteknikk, ekvivalenspartisjonsteknikk og grenseverdianalyseteknikk for generering av nødvendige testdatabetingelser.
• Valideringsreglene for referanseintegritet for de nødvendige databasetabellene må også valideres.
• Valget av standard tabellverdier for validering av databasekonsistens er et svært viktig konsept Hvorvidt logghendelsene har blitt lagt til i databasen for alle nødvendige påloggingshendelser
• Utføres planlagte jobber i tide?
• Ta rettidig sikkerhetskopiering av databasen.

Sjekk også- Databasetesting intervjuspørsmål og svar