Handledning för testning av databas (data).

Det grafiska användargränssnittet läggs vanligtvis mest tonvikt av test- och utvecklingsteammedlemmarna eftersom det grafiska användargränssnittet råkar vara den mest synliga delen av applikationen. Men det som också är viktigt är att validera den information som är kärnan i applikationen, alias DATABASE.

Låt oss överväga en bankapplikation där en användare gör transaktioner. Nu från Databas Testing eller DB Testing synvinkel följande, saker är viktiga:

1. Applikationen lagrar transaktionsinformationen i applikationsdatabasen och visar dem korrekt för användaren.
2. Ingen information går förlorad i processen.
3. Ingen information om delvis utförd eller avbruten operation sparas av applikationen.
4. Ingen obehörig person tillåts komma åt användarens information.

För att säkerställa alla dessa ovanstående mål måste vi använda datavalidering eller datatestning.

Skillnader mellan användargränssnittstestning och datatestning

Användargränssnittstestning	Databas eller Datatestning
Denna typ av testning är också känd som grafisk användargränssnittstestning eller frontendtestning.	Denna typ av testning är också känd som Backend Testing eller datatestning.
Denna typ av testning handlar främst om alla testbara objekt som är öppna för användaren för visning och interaktion som Formulär, Presentation, Grafer, Menyer och Rapporter, etc. (skapade genom VB, VB.net, VC++, Delphi – gränssnittsverktyg)	Denna typ av testning handlar främst om alla testbara objekt som i allmänhet är dolda för användaren för visning. Dessa inkluderar interna processer och lagring som Assembly, DBMS som Oracle, SQL Server, MYSQL, etc.
Denna typ av testning inkluderar validering av textrutor välj rullgardinsmenyer kalendrar och knappar Sidnavigering visning av bilder Utseende och känsla för den övergripande applikationen	Denna typ av testning innebär att validera: schemat databastabeller kolonner nycklar och index lagrade procedurer utlöser databasservervalideringar validerar dataduplicering
Testaren måste vara grundlig kunnig om affärskraven samt användningen av utvecklingsverktygen och användningen av automationsramverk och -verktyg.	För att kunna utföra backend-testning måste testaren ha en stark bakgrund i databasservern och Structured Query Language-koncept.

Typer av databastestning

De tre typerna av databastestning är

1. Strukturell provning
2. funktions~~POS=TRUNC
3. Icke-funktionell testning

I den här självstudien för databastestning kommer vi att undersöka varje typ och dess undertyper en efter en.

Vad är Schema Testing?

Schematestning i databastestning validerar olika schemaformat associerade med databasen och verifierar om mappningsformaten för tabeller/vyer/kolumner är kompatibla med mappningsformat för användargränssnitt. Huvudsyftet med schematestning är att säkerställa att schemamappningen mellan front-end och back-end är likartad. Således kallas det också för kartläggningstestning.

Låt oss diskutera de viktigaste kontrollpunkterna för schematestning.

1. Validering av de olika schemaformaten som är kopplade till databaserna. Många gånger kanske tabellens mappningsformat inte är kompatibelt med det mappningsformat som finns på applikationens användargränssnittsnivå.
2. Det finns ett behov av verifiering vid omappade tabeller/vyer/kolumner.
3. Det finns också ett behov av att verifiera om heterogena databaser i en miljö överensstämmer med den övergripande applikationskartläggningen.

Låt oss också titta på några av de intressanta verktygen för databastestning för att validera databasscheman.

• DBUnit som är integrerat med Ant lämpar sig mycket väl för kartläggningstestning.
• SQL Server gör att testarna kan kontrollera och fråga schemat för databasen genom att skriva enkla frågor och inte genom kod.

Till exempel, om utvecklarna vill ändra en tabellstruktur eller ta bort den, vill testaren se till att alla lagrade procedurer och vyer som använder den tabellen är kompatibla med den specifika ändringen. Ett annat exempel kan vara att om testarna vill kontrollera schemaändringar mellan 2 databaser, kan de göra det genom att använda enkla frågor.

Databastabell, kolumntestning

Låt oss titta på olika kontroller för databas- och kolumntestning.

1. Huruvida mappningen av databasfälten och kolumnerna i backend är kompatibel med dessa mappningar i front-end?
2. Validering av längden och namnkonventionen för databasfälten och -kolumnerna enligt kraven.
3. Validering av förekomsten av oanvända/omappade databastabeller/kolumner.
4. Validering av kompatibiliteten för

• data typ
• fältlängder

av backend-databasens kolumner med kolumnerna för de som finns i programmets front-end.

5. Huruvida databasfälten tillåter användaren att tillhandahålla önskade användarindata enligt kravspecifikationsdokumenten.

Test av nycklar och index

Viktiga kontroller för nycklar och index –

1. Kontrollera om det krävs

• Primärnyckel
• Främmande nyckel

begränsningar har skapats på de tabeller som krävs.

2. Kontrollera om referenserna för främmande nycklar är giltiga.
3. Kontrollera om datatypen för primärnyckeln och motsvarande främmande nycklar är samma i de två tabellerna.
4. Kontrollera om de nödvändiga namnkonventionerna har följts för alla nycklar och index.
5. Kontrollera storleken och längden på de obligatoriska fälten och indexen.
6. Om det krävs

• Clustered index
• Ej Clustered index

har skapats på de tabeller som krävs enligt affärskraven.

Testning av lagrade procedurer

Viktiga tester för att kontrollera lagrade procedurer är:

1. Huruvida utvecklingsteamet antog de nödvändiga, A) kodningsstandardkonventioner och B) undantags- och felhantering. För alla lagrade procedurer för alla moduler för applikationen som testas.
2. Om utvecklingsteamet täckte alla villkor/slingor genom att applicera nödvändiga indata till applikationen som testades?
3. Huruvida utvecklingsteamet tillämpade TRIM-operationen korrekt när data hämtas från de nödvändiga tabellerna i databasen?
4. Om manuell exekvering av den lagrade proceduren ger slutanvändaren det önskade resultatet?
5. Huruvida den manuella exekveringen av den lagrade proceduren säkerställer att tabellfälten uppdateras som krävs av applikationen som testas?
6. Om exekveringen av de lagrade procedurerna möjliggör implicit anrop av de nödvändiga utlösare?
7. Validering av förekomsten av oanvända lagrade procedurer.
8. Validering för Tillåt Null-villkor som kan göras på databasnivå.
9. Validering av det faktum att alla lagrade procedurer och funktioner har utförts framgångsrikt när databasen som testas är tom.
10. Validering av den övergripande integrationen av de lagrade procedurmodulerna enligt kraven för den applikation som testas.

Några av de användbara databastestverktygen för att testa lagrade procedurer är LINQ, SP-testverktyg etc.

Triggertestning

1. Om de erforderliga kodningskonventionerna har följts under kodningsfasen av triggers?
2. Kontrollera om de utlösare som körs för respektive DML-transaktioner har uppfyllt de villkor som krävs.
3. Om utlösaren uppdaterar data korrekt när de har exekveras?
4. Validering av den erforderliga uppdateringen/infoga/radera utlöser funktionalitet i applikationen som testas.

Valideringar av databasserver

1. Kontrollera databasserverns konfigurationer enligt affärskraven.
2. Kontrollera behörigheten för den begärda användaren att endast utföra de nivåer av åtgärder som krävs av applikationen.
3. Kontrollera att databasservern kan tillgodose behoven för det maximalt tillåtna antalet användartransaktioner enligt specifikationerna för affärskrav.

Funktionell databastestning

Funktionell databastestning är en typ av databastestning som används för att validera funktionskraven för en databas ur slutanvändarens perspektiv. Huvudmålet med funktionell databastestning är att testa om de transaktioner och operationer som utförs av slutanvändarna som är relaterade till databasen fungerar som förväntat eller inte.

Följande är de grundläggande villkoren som måste iakttas för databasvalidering.

• Om fältet är obligatoriskt samtidigt som NULL-värden tillåts i det fältet?
• Om längden på varje fält är tillräckligt stor?
• Om alla liknande fält har samma namn över tabellerna?
• Finns det några beräknade fält i databasen?

Denna speciella process är valideringen av fältmappningarna från slutanvändarens synvinkel. I det här speciella scenariot skulle testaren utföra en operation på databasnivå och sedan navigera till det relevanta användargränssnittsobjektet för att observera och validera om de korrekta fältvalideringarna har utförts eller inte.

Vice versa-villkoret där den första operationen utförs av testaren vid användargränssnittet och sedan samma valideras från baksidan bör också göras.

Kontrollera dataintegritet och konsistens

Följande kontroller är viktiga

1. Om uppgifterna är logiskt välorganiserade?
2. Huruvida data som lagras i tabellerna är korrekta och i enlighet med affärskraven?
3. Finns det några onödiga data i applikationen som testas?
4. Huruvida data har lagrats enligt kravet med avseende på data som har uppdaterats från användargränssnittet?
5. Om TRIM-operationerna utfördes på data innan data infogades i databasen som testas?
6. Om transaktionerna har utförts enligt affärskravsspecifikationerna och om resultatet är korrekt eller inte?
7. Huruvida data har begåtts korrekt om transaktionen har genomförts framgångsrikt?
8. Huruvida data har rullats tillbaka framgångsrikt om transaktionen inte har genomförts framgångsrikt av slutanvändaren?
9. Huruvida data har backats om transaktionen inte har genomförts framgångsrikt och flera heterogena databaser har varit inblandade i transaktionen i fråga?
10. Om alla transaktioner har utförts genom att använda de nödvändiga designprocedurerna som specificeras av systemets affärskrav?

Inloggning och användarsäkerhet

Valideringen av inloggningen och användarsäkerhetsuppgifterna måste ta hänsyn till följande saker.

1. Huruvida applikationen hindrar användaren från att gå vidare i applikationen i händelse av en

• ogiltigt användarnamn men giltigt lösenord
• giltigt användarnamn men ogiltigt lösenord.
• ogiltigt användarnamn och ogiltigt lösenord.

2. Om användaren endast får utföra de specifika operationer som specificeras av affärskraven?
3. Om uppgifterna är säkrade från obehörig åtkomst?
4. Om det finns olika användarroller skapade med olika behörigheter?
5. Om alla användare har nödvändiga nivåer av åtkomst till den angivna databasen som krävs av affärsspecifikationerna?
6. Kontrollera att känslig data som lösenord, kreditkortsnummer är krypterade och inte lagras som vanlig text i databasen. Det är en god praxis att se till att alla konton ska ha lösenord som är komplexa och inte lätta att gissa.

Icke-funktionell testning

Icke-funktionell testning i samband med databastestning kan kategoriseras i olika kategorier som krävs av affärskraven. Dessa kan vara belastningstestning, stresstestning, Säkerhetstestning, Användbarhetstestningoch Test av kompatibilitet, och så vidare. Belastningstestningen, såväl som stresstestningen, som kan grupperas under spektrumet Performance Testing tjänar två specifika syften när det kommer till rollen som icke-funktionell testning.

Riskkvantifiering– Kvantifiering av risker hjälper intressenterna att fastställa de olika kraven på systemets svarstid under erforderliga belastningsnivåer. Detta är den ursprungliga avsikten med någon kvalitetssäkring uppgift. Vi måste notera att belastningstester inte minskar risken direkt, utan genom processerna för riskidentifiering och riskkvantifiering, presenterar korrigerande möjligheter och en drivkraft för sanering som kommer att minska risken.

Minimikrav på systemutrustning– Den minsta systemkonfiguration som gör att systemet kan uppfylla de formellt angivna prestationsförväntningarna från intressenterna. Så att främmande hårdvara, mjukvara och tillhörande ägandekostnader kan minimeras. Detta särskilda krav kan kategoriseras som det övergripande kravet på affärsoptimering.

Lasttestning

Syftet med varje belastningstest bör tydligt förstås och dokumenteras. Följande typer av konfigurationer är ett måste för belastningstestning.

1. De mest använda användartransaktionerna har potential att påverka prestandan för alla andra transaktioner om de inte är effektiva.
2. Minst en icke-redigerande användartransaktion bör inkluderas i den slutliga testsviten, så att utförandet av sådana transaktioner kan skiljas från andra mer komplexa transaktioner.
3. De viktigare transaktionerna som underlättar systemets kärnmål bör inkluderas, eftersom misslyckande under en belastning av dessa transaktioner per definition har störst effekt.
4. Minst en redigerbar transaktion bör inkluderas så att prestanda av sådana transaktioner kan skiljas från andra transaktioner.
5. Optimal svarstid under ett stort antal virtuella användare för alla potentiella krav.
6. Effektiva tider för hämtning av olika poster.

Viktiga lasttestverktyg är LoadRunner Professional, vinna löpare och JMeter.

Viktiga stresstestverktyg är LoadRunner Professional och JMeter.

De vanligaste problemen under databastestning

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

Lösning: Den övergripande processplaneringen och timingen bör organiseras så att inga tids- och kostnadsbaserade problem uppstår.

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

Lösning: En tidigare plan och metod för generering av testdata bör finnas till hands.

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: Underhåll av SQL-frågorna och deras kontinuerliga uppdatering är en betydande del av den övergripande testprocessen som bör vara en del av den övergripande testa strategi.

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 finnas en fin balans mellan kvalitet och övergripande projekttidsplan.

Myter eller missuppfattningar relaterade till databastestning

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

Verklighet: Effektiv och effektiv databastestning i mjukvarutestning ger långsiktig funktionell stabilitet till den övergripande applikationen så det är nödvändigt att lägga ner hårt arbete bakom det.

Database testing adds extra work bottleneck

Verklighet: Tvärtom, databastestning tillför mer värde till det övergripande arbetet genom att ta reda på dolda problem och därmed proaktivt hjälpa till att förbättra den övergripande applikationen.

Database testing slows down the overall development process

Verklighet: Betydande mängd databastestning bidrar till den övergripande förbättringen av kvaliteten för databasapplikationen.

Database testing could be excessively costly

Verklighet: Alla utgifter för databastestning är en långsiktig investering som leder till långsiktig stabilitet och robusthet i applikationen. Således utgifter för databastestning eller SQL Testning är nödvändig.

Best Practices

• Alla data inklusive metadata samt funktionsdata måste valideras enligt deras kartläggning av kravspecifikationsdokumenten.
• Verifiering av testdata som har skapats av/i samråd med utvecklingsteamet behöver valideras.
• Validering av utdata genom att använda både manuella och automationsprocedurer.
• Utplacering av olika tekniker såsom orsakseffektgrafteknik, ekvivalenspartitioneringsteknik och gränsvärdesanalysteknik för generering av nödvändiga testdataförhållanden.
• Valideringsreglerna för referensintegritet för de obligatoriska databastabellerna måste också valideras.
• Valet av standardtabellvärden för validering av databaskonsistens är ett mycket viktigt koncept Huruvida logghändelserna har lagts till framgångsrikt i databasen för alla nödvändiga inloggningshändelser
• Utförs schemalagda jobb i rätt tid?
• Ta snabb säkerhetskopiering av databasen.

Kolla också- Databastestning Intervjufrågor och svar