Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Relational DataBase Management Systems (RDBMS) Testing

Relational DataBase Management Systems (RDBMS) Testing

Ratings: (0)|Views: 620|Likes:
Published by Kapil Samadhiya
Good document to learn Database and Back End testing of any web based application.

Kapil Samadhiya
Good document to learn Database and Back End testing of any web based application.

Kapil Samadhiya

More info:

Published by: Kapil Samadhiya on Sep 14, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less





RDBMS Testing
often persist mission-critical data whichis updated by many applications and potentially thousands if not millions of end users.Furthermore, they implement important functionality in the form of database methods (storedprocedures, stored functions, and/or triggers) and database objects (e.g. Java or C# instances).The best way to ensure the continuing quality of these assets, at least from a technical point of view, you should have a full regression test suite which you can run on a regular basis. In thisarticle I argue for a fully automated, continuous regression testing based approach to databasetesting. Just as agile software developers take this approach to their application code, we shouldalso to the same for our databases.
Table of Contents
1. Why Test an RDBMS?
There are several reasons why you need to develop a comprehensive testing strategy for your RDBMS:1.
Data is an important corporate asset
. Doesn't it make sense to investthe effort required to validate the quality of data via effective testing?2.
Mission-critical business functionality is implemented in RDBMSs
.Shouldn't we be testing it?
Current approaches aren't sufficient
. The current state of the art in manyorganizations is for data professionals to control changes to the database schemas, for developers to visually inspect the database during construction, and to perform someform of formal testing during the test phase at the end of the lifecycle. Unfortunately,none of these approaches prove effective. Application developers will often go aroundtheir organization's data management group because they find them too difficult to workwith, too slow in the way they work, or sometimes they don't even know they should beworking together. The end result is that the teams don't follow the desired data qualityprocedures and as a result quality suffers. Although visual inspection of query results isa good start, as
 points out it you likely won't do it consistently nor willyou do it often enough. Testing late in the lifecycle is better than nothing, but as BarryBoehm noted in the early 80s it's 
 you find atthat point.
Support for evolutionary development
. Many
techniques, in particular  
, are predicated upon the idea that itmust be possible to determine if something in the database has been broken when achange has been made. The easiest way to do that is to simply run your regression testsuite.
2. What Should We Test?
indicates what you should consider testing when it comes to relational databases.The diagram is drawn from the point of view of a single database, the dashed linesindicate
, indicating that you need to consider threats both within thedatabase and at the interface to the database.
lists the issues which you shouldconsider testing for both internally within the database and at the interface to it. For details, read the article 
Figure 1. What to test.
Table 1. What to test in an RDBMS.Interface TestingInternal Testing
O/R mappings (including themeta data)
Incoming data values
Outgoing data values (fromqueries, ...)
Scaffolding code (e.g. triggers or updateable views)which support refactorings
Typical unit tests for your stored procedures,functions, and triggers
Existence tests for database schema elements(tables, procedures, ...)
Outgoing data values from views, stored procs, ...
View definitions
Default values for a column
Data invariants for a single column
Data invariants involving several columns
3. When Should We Test?
Agile software developers take a test-first approach to development where they write a testbefore you write just enough production code to fulfill that test. The steps of test firstdevelopment (TFD) are overviewed in the UML activity diagram of 
. The first step is toquickly add a test, basically just enough code to fail. Next you run your tests, often the completetest suite although for sake of speed you may decide to run only a subset, to ensure that the newtest does in fact fail. You then update your functional code to make it pass the new tests. Thefourth step is to run your tests again. If they fail you need to update your functional code andretest. Once the tests pass the next step is to start over. 
Figure 2. The Process of Test First Development (TFD).

Activity (18)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
Gajendra Singh liked this
abey134175 liked this
Ron Joyal liked this
Ting Zhang liked this
andi_firdaus_4 liked this
Hitesh Shah liked this
Murali Krishna liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->