Databastestning - Database testing
Datatabstestning består vanligtvis av en skiktad process, inklusive användargränssnittslagret (UI), affärslager, dataåtkomstlagret och själva databasen. UI-lagret hanterar gränssnittsdesignen för databasen, medan affärslaget innehåller databaser som stöder affärsstrategier .
Syften
Databaser , insamling av sammankopplade filer på en server, lagring av information, hanterar kanske inte samma typ av data, dvs databaser kan vara heterogena . Som ett resultat av många olika typer av genomförande och integration fel kan förekomma i stora databassystem, vilket negativt påverkar systemets prestanda, tillförlitlighet, konsekvens och säkerhet. Därför är det viktigt att testa för att erhålla ett databassystem som uppfyller ACID- egenskaperna (Atomicitet, konsistens, isolering och hållbarhet) i ett databashanteringssystem .
Ett av de mest kritiska skikten är dataåtkomstskiktet, som hanterar databaser direkt under kommunikationsprocessen. Databastestning sker huvudsakligen i detta lager och involverar teststrategier som kvalitetskontroll och kvalitetssäkring av produktdatabaserna. Testning vid dessa olika lager används ofta för att upprätthålla enhetlighet i databassystem, vilket ofta ses i följande exempel:
- Data är kritisk ur affärssynpunkt. Företag som Google eller Symantec , som är kopplade till datalagring , måste ha ett hållbart och konsekvent databassystem. Om databasåtgärder som infoga, ta bort och uppdatera utförs utan att testa databasen för konsistens först riskerar företaget att hela systemet kraschar.
- Vissa företag har olika typer av databaser och även olika mål och uppdrag. För att uppnå en nivå av funktionalitet för att nå målen måste de testa sitt databassystem.
- Det nuvarande testmetoden kanske inte är tillräcklig för att utvecklare formellt testar databaserna. Detta tillvägagångssätt är dock inte tillräckligt effektivt eftersom databasutvecklare sannolikt kommer att sakta ner testprocessen på grund av kommunikationsbrister. Ett separat testteam för databaser verkar lämpligt.
- Databastestning handlar främst om att hitta fel i databaserna för att eliminera dem. Detta kommer att förbättra kvaliteten på databasen eller det webbaserade systemet.
- Databastestning bör särskiljas från strategier för att hantera andra problem som databaskrascher, trasiga insättningar, raderingar eller uppdateringar. Här är databasrefactoring en evolutionsteknik som kan tillämpas.
Typer av testningar och processer
Figuren indikerar de testområden som är involverade under olika databasprovningsmetoder, till exempel svartboxtestning och vitbokstestning .
Svart låda
Black-box-test innefattar testning av gränssnitt och integrering av databasen, som inkluderar:
- Kartläggning av data (inklusive metadata )
- Verifierar inkommande data
- Verifiera utgående data från frågefunktioner
- Olika tekniker som Cause effect graphing-teknik, ekvivalenspartitionering och gränsvärdesanalys .
Med hjälp av dessa tekniker kan databasens funktionalitet testas noggrant.
Fördelar och nackdelar med black box-test inkluderar: Generering av testfall i black box-test är ganska enkelt. Deras generation är helt oberoende av mjukvaruutveckling och kan göras i ett tidigt utvecklingsstadium. Som en konsekvens har programmeraren bättre kunskap om hur man utformar databasapplikationen och använder mindre tid för felsökning. Kostnaden för utveckling av Black Box-testfall är lägre än utvecklingen av White Box-testfall. Den största nackdelen med att testa svarta lådor är att det är okänt hur mycket av programmet som testas. Vissa fel kan inte heller upptäckas.
Vit låda
White-box-testning handlar främst om den interna strukturen i databasen. Specifikationsinformationen är dold för användaren.
- Det involverar testning av databasutlösare och logiska vyer som kommer att stödja databaserefakturering .
- Den utför modultestning av databasfunktioner, utlösare, vyer, SQL- frågor etc.
- Det validerar databastabeller, datamodeller, databasschema etc.
- Det kontrollerar reglerna för referensintegritet .
- Det väljer standardtabellvärden för att kontrollera databasens konsistens.
- De tekniker som används vid testning av vita rutor är tillståndstäckning, beslutstäckning, uttalandestäckning, cyklomatisk komplexitet .
Den största fördelen med vitlåda-testning vid databasprovning är att kodfel upptäcks, så interna fel i databasen kan elimineras. Begränsningen av White Box-testning är att SQL-uttalanden inte täcks.
WHODATE-metoden
Medan testfall skapas för databastestning måste semantiken för SQL-uttalandet återspeglas i testfallet. För detta ändamål används en teknik som kallas WHite bOx Database Application Technique "(WHODATE)". Som visas i figuren omvandlas SQL-uttalanden oberoende till GPL-uttalanden, följt av traditionell vitlåda-testning för att generera testfall som inkluderar SQL-semantik.
Fyra etapper
- Ställ in fixturen
- Provkörning
- Resultatverifiering
- Riva ner
En uppsättning fixtur beskriver det ursprungliga tillståndet för databasen innan testet går in. Efter inställning av fixturer testas databasbeteende för definierade testfall. Beroende på resultatet ändras testfall antingen eller hålls som de är. "Riv ned" -stadiet antingen resulterar i att testet avslutas eller fortsätter med andra testfall.
För framgångsrik databasprovning körs följande arbetsflöde som körs av varje enskilt test:
- Rensa upp databasen: Om de testbara uppgifterna redan finns i databasen måste databasen tömmas.
- Ställ in Fixture: Ett verktyg som PHPUnit kommer sedan att iterera över fixturer och göra insättningar i databasen.
- Kör test, verifiera utfallet och sedan riva ner: Efter att ha återställt databasen för att tömma och listat fixturerna körs testet och utdata verifieras. Om produktionen är som förväntat följer nedrivningsprocessen, annars upprepas testningen.
Grundläggande tekniker
- SQL Query Analyzer är ett användbart verktyg när du använder Microsoft SQL Server .
- En vanligt förekommande funktion
create_input_dialog["label"], används för att validera utdata med användaringångar. - Utformningen av formulär för automatiserad databasprovning, formulär front-end och back-end, är till hjälp för databasunderhållsarbetare.
- Data lasttest :
- För dataladdningstest krävs kunskap om källdatabas och destinationsdatabas.
- Arbetare kontrollerar kompatibiliteten mellan källdatabasen och destinationsdatabasen med DTS- paketet.
- När källdatabasen uppdateras ska arbetarna se till att jämföra den med måldatabasen.
- Databasbelastningstester mäter databasserverns kapacitet att hantera frågor såväl som svarstiden för databasservern och klienten.
- I databastestning övervägs ofta frågor som atomicitet, konsistens, isolering, hållbarhet, integritet, utförande av utlösare och återställning.
- Installationen för databastestning är kostsam och komplex att underhålla eftersom databassystem förändras ständigt med förväntade insättnings-, radera- och uppdateringsåtgärder.
- Extra omkostnader är inblandade för att bestämma tillståndet för databastransaktionerna.
- Efter rengöring av databasen måste nya testfall utformas.
- En SQL-generator behövs för att omvandla SQL-uttalanden för att inkludera SQL-semantiken i databas-testfall.
Se även
Referenser
-
Ambler, Scott W. (2006). "Databastestning: Hur regressionstestar en relationsdatabas" . Agiledata.org . Hämtad 4 december 2011 . Extern länk i
|publisher=( hjälp ) CS1 maint: avskräckt parameter ( länk ) - Zeichick, Alan; et al. (14 augusti 1989). Hur vi testade integrerade programvarupaket . InfoWorld . Hämtad 4 december 2011 . CS1 maint: avskräckt parameter ( länk )
externa länkar
- Kapitel 8. Databastestning från PHPUnit Manual
- Skapa datauppsättningar för att testa relationsdatabaser
- SQL-testtäckning
- Acolyte Framework för att håna JDBC för uthållighetstestning