I m looking for an article or some kind oa document that can explain me the methodologies of unit testing a database and what would be the exect path of strategy points to follow in database varification of a software or website
I believe that based on their past generosity the members of this forums will be happy to help you.
But I for one do not understand what you mean by the term "unit testing a database" -- it is way too broad, vague and amiguous, implying ignorance (which is OK, we have all been there) or lazy sloppy thinking (not so likely to arouse members' empathy and their desire to help).
I think it would be a good idea for you to re-word your request and spell out specifically what you are trying to do.
looking at the past generosity of the members of this forum i was also looking for a generous person but unfortunately or fortunately i bumped into u . Well if i make my question very brief and simple it would be the "I exactly want to no the main points to follow in varification of a database.
Plain and simple... Test the database to make sure it supports inserts, updates, and deletes. I know that's vague since a database should be able to support those three standard actions, so let me explain where the testing begins...
First, gather information about your users. How is the system being used? What are the most common transactions etc..
Second, figure out what levels of access to the database you have. For instance, do you have direct API access? Like SQLPlus or some other command line access? Can you easily see what the database is doing from the GUI? Can you write database testing scripts that can manipulate the API, GUI, or a combination of both?
Third, write out your testcases in simple 1 2 3 step patterns that focus on user -> system -> expected patterns. Organization is important.
Fourth, execute your testcases making sure you can manipulate the data in as many ways as you pre-defined.
As a generality, some of the following may be useful.... Make sure to test for boundary conditions and acceptable conditions. Also, try to work "transactions" into your testing. It's one thing to simply put a record in, but what are the downstream reactions to that? What happens when you delete an item in one table that's linked to another table? Usually when testing end to end, manipulating the data through the GUI is the most thorough.