Database Testing

What is Database Testing?

Over the years, various complex systems have been broken down to specific layers (user
interface, business or application layer, data access layer, database layer). To effectively
test the application, all the layers need to be tested for what bugs and issues they can
introduce into the system. Testing judges what component is responsible for problem and
who can fix the problem?
In a way, database testing includes testing all components
related with database component. A database application has a data access layer which is
the code written to manipulate and perform actions on the database. Most database
applications are subject to constant change; for instance, business processes are re-
engineered, authorization rules are changed, components are replaced by other more
powerful components, or optimizations are added in order to achieve better performance
for a growing number of users and data. The more complex an application becomes, the
more frequently the application and its configuration must be changed. Database Testing
is testing at the data access layer, the point at which your application communicates with
the database. It is testing the integrity between the database application and its data stores
(Stored Procedures, Views, and Tables). The databases and data stores used by the
application present a multi-layered system in and of itself. Accessing multiple data stores
– has become an integral piece of most applications and it is currently not being tested
sufficiently in many organizations.

Web Client Internet Web Server

Multiple Data Stores:
Administrative Oracle, SQL Server,
Application DB2
Intranet Client
Computer

Database testing is a process working with data that's stored in the database. Database
testing, basically, includes the following:-

1. Data Accuracy & Validity (Field size validation)

2. Data Integrity (Check constraints, insert, delete, update)
3. Database Objects (Stored Procedures, Views, Tables)
4. Data Migration (Import, Export)
5. Data Transaction Consistency and Concurrency (States & Locks)
6. Performance related to database (Indices, number of triggers and procedures)
7. Security related to database - Data Accessing ( unauthorized access)
There are many aspects to the correctness of a database system, including the following:

1. Does the application program behave as specified?

2. Does the database schema correctly reflect the organization of the real world data
being modeled?
3. Are security and privacy protected appropriately?
4. Are the data in the database accurate?
5. Does the DBMS perform all insertions, deletions, and updates of the data correctly?

Data integrity includes checking constraints. Various constraints that need to be checked
are uniqueness constraint, not-Null constraint, composite key constraint and semantic
constraint.
Several issues must be considered when checking the database constraints:-
• Checking that tables that should not have changed did not change and checking that
tables that should have changed did change.
• Checking that tables changed in correct way, according to constraints generated and
supplied by tester.
• Checking that new state satisfies the relevant constraints, including those specified
by the tester as well as those defined in the schema and application.

Transaction consistency has two aspects: when run in isolation, it should remain
consistent and the relation between old and new state should satisfy the requirements of
the transaction's specification. Data Consistency includes both internal and external
validations of essential data fields. Internal checks involve data type checking and ensure
that columns are of correct types. External checks involve validation or relational
integrity to whether duplicate data are being loaded from different files. Transaction
concurrency- the DBMS employs sophisticated mechanisms to assure that transactions
satisfy the ACID properties - Atomicity, Consistency, Isolation, and Durability - an
application can still have concurrency related faults if the application programmer
erroneously placed queries in separate transactions when they should have been executed
as a unit. There are issues with application programs written in embedded SQL, where
multiple clients executing an application program concurrently can have their own host
variable. Consistency constraints are violated if more than one instance tries to modify
the same data element concurrently. To avoid interference from other instances, related
operations should be grouped into a transaction. To improve efficiency, operations on
different tables could be performed concurrently. Concurrency problem that occurs when
data are manipulated across multiple database transactions is termed offline concurrency
problem. Stored procedure or application using the stored procedure should not be left in
an unknown situation. It is necessary to implement error-handling mechanism in stored
procedures, where in every system thrown error messages will be taken care off. The
tester should go through the requirement, as to why the particular stored procedure is
written for and check whether all the required indexes, joins, updates, deletions are
correct comparing with the tables mentions in the Stored Procedure. Moreover, he has to
ensure whether the Stored Procedure follows the standard format like comments, updated
by, etc.
How to test database?

Testing of Database applications requires various tasks:

1. Database schema parsing for extracting information.
2. Test database generation.
3. Test cases generation.
4. Validation of state and output of test cases.

Most methods for generating test databases only consider the database schema or
generate random data for a given statistical distribution. However, these generated
databases are inadequate to cover many critical execution paths of the application. It is
because these generated test databases never take the embedded SQL queries of the
database application into account. Consequently, there is a gap between the generated test
databases and the queries of the application during test: this leads to the fact that many
queries of the application get no (meaningful) results from the generated databases and
thus many execution paths of the application cannot be tested. In order to test the critical
execution paths of a database application in a meaningful way, a test database generator
that considers both the database schema and the queries of the database application
during data generation should be used.

Tools used for database testing

• CompuWare DevPartnerDB
• Scandiasoft DBValidator
• DbUnit SourceForge (also has many db schema comparator tools)
• Dtm-db- stress
• IBM Rational Functional Tester 6.1
• Open STA
• MbUnit
• DBMonster is a tool that generates random test data and puts it into SQL
Database. It helps to test how an application can deal with large database.
• HTDGen – It generates meaningful test databases for database applications. This
database generator considers both the database schema and the queries of the
database application during data generation.
• HTTrace – It executes database applications testing efficiently, run regression tests
on database applications.
• HTPar – It run tests in parallel.
• Agenda – A (test) Generator for Database Applications.
• Dbfill and Data factory
• Genie – database generation

Thanks,
Kapil Samadhiya