Meny

Komplett guide för databastestning (varför, vad och hur man testar data)

database testing complete guide why

Prova Vårt Instrument För Att Eliminera Problem

En komplett guide till databastestning med praktiska tips och exempel:

Datorapplikationer är mer komplexa idag med tekniker som Android och även med massor av Smartphone-appar. Ju mer komplexa framändarna är, desto mer invecklade blir bakändarna.

Så det är desto viktigare att lära sig om DB-test och kunna validera databaser effektivt för att säkerställa säkerhets- och kvalitetsdatabaser.

I den här handledningen lär du dig allt om datatestning - varför, hur och vad ska du testa?

Guide för databastestning

Databasen är en av de oundvikliga delarna av ett program.

Det spelar ingen roll om det är ett webb-, skrivbords- eller mobil-, klientserver-, peer-to-peer-företag, företag eller enskilt företag; databasen krävs överallt i backend.

På samma sätt, oavsett om det är sjukvård, ekonomi, leasing, detaljhandel, postapplikation eller kontroll av ett rymdskepp; en databas är alltid i funktion bakom scenen.

När applikationens komplexitet ökar uppstår behovet av en starkare och säker databas. På samma sätt, för applikationer med hög transaktionsfrekvens ( Till exempel, Bank- eller finansieringsapplikation), är nödvändigheten av ett komplett DB-verktyg kopplat.

Numera har vi stora data som är stora och komplexa som de traditionella databaserna inte kan hantera.

Det finns flera Databasverktyg finns på marknaden Till exempel, MS-Access, MS SQL Server, SQL Server, Oracle, Oracle Financial, MySQL, PostgreSQL, DB2, Toad, Admirer, etc. Dessa verktyg varierar i kostnad, robusthet, funktioner och säkerhet. Var och en av de här har sina egna fördelar och nackdelar.

Vad du kommer att lära dig:

Varför testa databasen?

Nedan ser vi varför följande aspekter av en DB ska valideras:

Allt om databastestning

# 1) Datamappning

I mjukvarusystem går data ofta fram och tillbaka från användargränssnittet (användargränssnittet) till backend DB och vice versa. Så det här är några aspekter att titta på:

  • Kontrollera om fälten i UI / frontend-formerna kartläggs konsekvent med motsvarande fält i DB-tabellen. Denna kartläggningsinformation definieras vanligtvis i kravdokumenten.
  • När en viss åtgärd utförs i framänden av en applikation, anropas en motsvarande CRUD-åtgärd (Skapa, hämta, uppdatera och ta bort) i bakänden. En testare måste kontrollera om rätt åtgärd åberopas och om den åberopade åtgärden i sig är framgångsrik eller inte.

# 2) Validering av ACID-egenskaper

Atomicitet, konsistens, isolering och hållbarhet. Varje transaktion som en DB utför måste följa dessa fyra egenskaper.

DB ACID-egenskaper

  • Atomicitet betyder att en transaktion antingen misslyckas eller går igenom. Det betyder att även om en enda del av transaktionen misslyckas betyder det att hela transaktionen har misslyckats. Vanligtvis kallas detta 'allt-eller-ingenting' -regeln.
  • Konsistens : En transaktion resulterar alltid i ett giltigt tillstånd för DB
  • Isolering : Om det finns flera transaktioner och de utförs på en gång, ska resultatet / tillståndet för DB vara detsamma som om de utfördes efter varandra.
  • Varaktighet : När en transaktion är klar och begått, bör inga externa faktorer som strömavbrott eller krasch kunna ändra den

Föreslagen läsning = >> MySQL-transaktionshandledning

# 3) Dataintegritet

För någon av de CRUD-verksamhet bör de uppdaterade och senaste värdena / statusen för delad data visas på alla formulär och skärmar. Värdet ska inte uppdateras på en skärm och visa ett äldre värde på en annan.

När ansökan genomförs, slutanvändaren använder huvudsakligen de “CRUD” -åtgärder som underlättas av DB-verktyget .

C: Skapa - När användaren 'sparar' någon ny transaktion utförs 'Skapa' -åtgärd.
R: Hämta - När användaren 'Sök' eller 'Visa' någon sparad transaktion utförs 'Hämta' -åtgärd.
U: Uppdatering - När användaren redigerar eller modifierar en befintlig post utförs uppdateringen av DB.
D: Radera - När en användare ”tar bort” någon post från systemet utförs ”Radera” -funktionen för DB.

Varje databasåtgärd som utförs av slutanvändaren är alltid en av ovanstående fyra.

Så utforma dina DB-testfall på ett sätt att inkludera kontroll av data på alla platser som det verkar för att se om det är konsekvent detsamma.

Dataintegritetstest

# 4) Överensstämmelse med affärsregler

Mer komplexitet i databaser betyder mer komplicerade komponenter som relationsbegränsningar, utlösare, lagrade procedurer osv. Så testare måste komma med lämpliga SQL-frågor för att validera dessa komplexa objekt.

Vad ska man testa (checklista för databastestning)

# 1) Transaktioner

När du testar transaktioner är det viktigt att se till att de uppfyller ACID-egenskaperna.

Dessa är de uttalanden som ofta används:

  • BÖRJA TRANSAKTION TRANSAKTION #
  • SLUTTRANSAKTION TRANSAKTION #

Rollback-uttalandet säkerställer att databasen förblir i ett konsekvent tillstånd.

  • ROLLBACK TRANSAKTION #

När dessa uttalanden har utförts, använd en Välj för att se till att ändringarna har återspeglats.

  • VÄLJ * FRÅN TABLNAMN

# 2) Databasscheman

Ett databasschema är inget annat än en formell definition av hur data ska organiseras i en DB. För att testa det:

  • Identifiera kraven baserade på vilka databasen fungerar. Provkrav:
    • Primära nycklar som ska skapas innan andra fält skapas.
    • Utländska nycklar bör vara helt indexerade för enkel hämtning och sökning.
    • Fältnamn som börjar eller slutar med vissa tecken.
    • Fält med en begränsning att vissa värden kan eller inte kan infogas.
  • Använd en av följande metoder beroende på relevans:
    • SQL-fråga DESC för att validera schemat.
    • Vanliga uttryck för att validera namnen på de enskilda fälten och deras värden
    • Verktyg som SchemaCrawler

      • # 3) Utlösare

      När en viss händelse äger rum på ett visst bord kan en kod (en trigger) automatiskt instrueras att köras.

      Till exempel, en ny elev gick med i en skola. Studenten tar två lektioner: matematik och naturvetenskap. Studenten läggs till i 'studenttabellen'. En utlösare kan lägga till eleven i motsvarande ämnesbord när han läggs till i studenttabellen.

      Den vanliga metoden för att testa är att exekvera SQL-frågan inbäddad i utlösaren självständigt först och spela in resultatet. Följ upp detta med att utföra Trigger som helhet. Jämför resultaten.

      Dessa testas i både Black-box och White-box testfaserna.

      qa analytiker intervju frågor och svar
      • Vitlåda testning : Stubbar och drivrutiner används för att infoga eller uppdatera eller ta bort data som kan leda till att utlösaren åberopas. Grundidén är att bara testa DB ensam innan integrationen med gränssnittet (UI) görs.
      • Black box-testning :

      till) Sedan användargränssnittet och DB är integration nu tillgänglig; vi kan infoga / ta bort / uppdatera data från fronten på ett sätt som utlösaren anropas. Därefter kan Select-uttalanden användas för att hämta DB-data för att se om Trigger lyckades utföra den avsedda åtgärden.

      b) Det andra sättet att testa detta är att direkt ladda in data som skulle anropa utlösaren och se om det fungerar som avsett.

      # 4) Lagrade procedurer

      Lagrade procedurer liknar mer eller mindre användardefinierade funktioner. Dessa kan åberopas av uttalanden om anropsprocedur / utför procedur och utdata är vanligtvis i form av resultatuppsättningar.

      Dessa lagras i RDBMS och är tillgängliga för applikationer.

      Dessa testas också under:

      • Vitlåda testning: Stubbar används för att åberopa de lagrade procedurerna och sedan valideras resultaten mot de förväntade värdena.
      • Black box-testning: Utför en operation från applikationens front (UI) och kontrollera om den lagrade proceduren har genomförts och dess resultat.

      # 5) Fältbegränsningar

      Standardvärdet, unikt värde och främmande nyckel:

      • Utför en front-end-operation som utövar databasobjektets tillstånd
      • Validera resultaten med en SQL-fråga.

      Att kontrollera standardvärdet för ett visst fält är ganska enkelt. Det är en del av validering av affärsregler. Du kan göra det manuellt eller så kan du använda verktyg som QTP. Manuellt kan du utföra en åtgärd som adderar ett annat värde än standardvärdet för fältet från fronten och ser om det resulterar i ett fel.

      Följande är ett exempel på VBScript-kod:

      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 ovanstående kod är sant om standardvärdet finns eller falskt om det inte gör det.

      Kontroll av det unika värdet kan göras precis som vi gjorde för standardvärdena. Försök att ange värden från användargränssnittet som bryter mot denna regel och se om ett fel visas.

      Automation VB Script-kod kan vara:

      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)

      FörFrämmande nyckelbegränsning validering använda dataladdningar som direkt matar in data som bryter mot begränsningen och se om programmet begränsar dem eller inte. Tillsammans med backend-datalastningen, utför även front-UI-operationerna på ett sätt som bryter mot begränsningarna och ser om det aktuella felet visas.

      Aktiviteter för datatestning

      Databastestare bör fokusera på följande testaktiviteter:

      # 1) Säkerställ datakartning:

      Data Mapping är en av de viktigaste aspekterna i databasen och den bör testas noggrant av varje programvarutestare.

      Se till att kartläggningen mellan olika former eller skärmar för AUT och dess DB inte bara är korrekt utan också enligt designdokument (SRS / BRS) eller kod. I grund och botten måste du validera kartläggningen mellan varje front-end-fält med motsvarande backend-databasfält.

      För alla CRUD-operationer, kontrollera att respektive tabeller och poster uppdateras när användaren klickar på 'Spara', 'Uppdatera', 'Sök' eller 'Radera' från applikationsgränssnittet.

      Vad du behöver verifiera:

      • Tabellmappning, kolumnmappning och mappning av datatyp.
      • Sökning av datakartläggning.
      • Korrekt CRUD-operation åberopas för varje användaråtgärd vid användargränssnittet.
      • CRUD-operation är framgångsrik.

      # 2) Säkerställ ACID-egenskaper för transaktioner:

      ACID-egenskaper för DB-transaktioner hänvisar till ” TILL tomicitet ',' C onsistens ',' Jag solation 'och' D urabilitet ”. Korrekt testning av dessa fyra egenskaper måste göras under databastestaktiviteten. Du måste verifiera att varje enskild transaktion uppfyller ACID-egenskaperna i databasen.

      ACID-egenskaper

      Låt oss ta ett enkelt exempel genom nedanstående SQL-kod:

      CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));

      ACID-testtabellen kommer att ha två kolumner - A & B. Det finns en integritetsbegränsning att summan av värden i A och B alltid ska vara 100.

      Atomicitetstest säkerställer att alla transaktioner som utförs i denna tabell är helt eller inga, dvs. inga poster uppdateras om något av transaktionens misslyckanden misslyckas.

      Konsistensprov säkerställer att när värdet i kolumn A eller B uppdateras förblir summan alltid 100. Det tillåter inte införande / radering / uppdatering i A eller B om den totala summan är något annat än 100.

      Isoleringstest kommer att se till att om två transaktioner sker samtidigt och försöker ändra data i ACID-testtabellen, körs dessa dragningar isolerat.

      Hållbarhetstest kommer att se till att när en transaktion över denna tabell har begåtts, kommer den att förbli så, även vid strömavbrott, kraschar eller fel.

      Detta område kräver mer noggranna, noggranna och skarpare tester om din ansökan använder den distribuerade databasen.

      # 3) Säkerställ dataintegritet

      Tänk på att olika moduler (dvs skärmar eller former) av applikationer använder samma data på olika sätt och utför alla CRUD-operationer på data.

      Kontrollera i så fall att det senaste datatillståndet återspeglas överallt. Systemet måste visa de uppdaterade och senaste värdena eller statusen för sådan delad data på alla formulär och skärmar. Detta kallas för dataintegritet.

      av

      Testfall för validering av databasdataintegritet:

      • Kontrollera om alla utlösare är på plats för att uppdatera referensbordsposter.
      • Kontrollera om det finns felaktiga / ogiltiga data i huvudkolumnerna i varje tabell.
      • Försök att infoga fel data i tabeller och observera om något fel inträffar.
      • Kontrollera vad som händer om du försöker sätta in ett barn innan du sätter i föräldern (försök att leka med primära och främmande nycklar).
      • Testa om något fel inträffar om du tar bort en post som fortfarande refereras till av data i någon annan tabell.
      • Kontrollera om replikerade servrar och databaser är synkroniserade.

      # 4) Se till att de implementerade affärsreglerna är korrekta:

      Idag är databaser inte endast avsedda att lagra posterna. Faktum är att databaser har utvecklats till extremt kraftfulla verktyg som ger gott om stöd för utvecklarna för att implementera affärslogiken på DB-nivå.

      Några enkla exempel på kraftfulla funktioner är ”Referential Integrity”, Relational constraints, Triggers och lagrade procedurer.

      Så med hjälp av dessa och många andra funktioner som erbjuds av DB: er implementerar utvecklarna affärslogiken på DB-nivå. Testaren måste se till att den implementerade affärslogiken är korrekt och fungerar korrekt.

      Ovanstående punkter beskriver de fyra viktigaste ”What To” för att testa DB. Nu ska vi gå vidare till 'How To' -delen.

      Hur man testar databasen (steg-för-steg-process)

      Den allmänna testprocessens testdatabas skiljer sig inte särskilt från någon annan applikation.

      Följande är kärnstegen:

      Steg 1) Förbered miljön
      Steg 2) Kör ett test
      Steg 3) Kontrollera testresultatet
      Steg 4) Validera enligt förväntade resultat
      Steg # 5) Rapportera resultaten till respektive intressent

      Process för databastestning

      Vanligtvis används SQL-frågor för att utveckla testerna. Det vanligaste kommandot är ”Välj”.

      Välj * varifrån

      Förutom Select har SQL tre viktiga typer av kommandon:

      1. DDL: Datadefinitionsspråk
      2. DML: Datamanipuleringsspråk
      3. DCL: Datakontrollspråk

      Låt oss se syntaxen för de mest använda uttalandena.

      Data Definition språk Använder CREATE, ALTER, RENAME, DROP och TRUNCATE för att hantera tabeller (och index).

      Datahanteringsspråk Inkluderar uttalanden för att lägga till, uppdatera och ta bort poster.

      Datakontrollspråk: Avser att ge behörighet till användare för manipulation och åtkomst till data. Grant and Revoke är de två påståenden som används.

      Bevilja syntax:
      Bevilja / uppdatera bidrag
      På


      Till;

      Återkalla syntax:
      Återkalla val / uppdatering
      på


      från;

      Några praktiska tips

      # 1) Skriv frågor själv:

      För att testa databasen korrekt bör testaren ha mycket god kunskap om SQL- och DML-uttalanden (Data Manipulation Language). Testaren bör också känna till den interna DB-strukturen för AUT.

      Du kan kombinera GUI och dataverifiering i respektive tabeller för bättre täckning. Om du använder SQL-servern kan du använda SQL Query Analyzer för att skriva frågor, köra dem och hämta resultat.

      Detta är det bästa och robusta sättet att testa en databas när applikationen är av liten eller medelstor nivå av komplexitet.

      Om applikationen är mycket komplex kan det vara svårt eller omöjligt för testaren att skriva alla SQL-frågor som krävs. För komplexa frågor tar du hjälp från utvecklaren. Jag rekommenderar alltid den här metoden eftersom den ger dig förtroende för testning och också förbättrar dina SQL-färdigheter.

      # 2) Observera data i varje tabell:

      Du kan utföra dataverifiering med hjälp av resultaten av CRUD-operationer. Detta kan göras manuellt med hjälp av applikationsgränssnittet när du känner till databasintegrationen. Men det kan vara en tråkig och besvärlig uppgift när det finns enorma data i olika databastabeller.

      För manuell datatestning måste databastestaren ha god kunskap om databastabellstruktur.

      # 3) Få frågor från utvecklarna:

      Detta är det enklaste sättet att testa databasen. Utför alla CRUD-operationer från GUI och verifiera dess effekter genom att utföra respektive SQL-frågor som erhållits från utvecklaren. Det kräver varken god kunskap om SQL eller kräver god kunskap om applikationens DB-struktur.

      Men den här metoden måste användas med försiktighet. Vad händer om frågan från utvecklaren är semantiskt felaktig eller inte uppfyller användarens krav korrekt? Processen kan helt enkelt inte validera data.

      # 4) Använd testverktyg för databasautomatisering:

      Det finns flera verktyg tillgängliga för datatestprocessen. Du bör välja rätt verktyg enligt dina behov och utnyttja det på bästa sätt.

      => Här är listan över de TOP DB-testverktygen du bör kontrollera

      Slutsats

      Med alla dessa funktioner, faktorer och processer för att testa i en databas, finns det en ökande efterfrågan för testarna att vara tekniskt kunniga i de viktigaste databaskoncepten. Trots några av de negativa övertygelserna om att testa en databas skapar nya flaskhalsar och är mycket extra utgifter - detta är ett testmiljö som väcker betydande uppmärksamhet och efterfrågan.

      Föreslagen läsning = >> Vad är databas säkerhetstestning

      Jag hoppas att denna handledning har hjälpt till att fokusera på varför det är så och har också gett dig de grundläggande detaljerna om vad som går att testa en databas.

      Låt oss veta din feedback och dela även dina personliga erfarenheter om du arbetar med DB-testning.

      Rekommenderad läsning

      ^