Database Testing

Table of Contents

INTRODUCTION..................................................................................................3
PRE REQUISITES.................................................................................................3
WHAT TO TEST?.................................................................................................3
TYPES OF DB TESTING..................................................................................................................4
BASIC OPERATIONS IN DATABASE TESTING..............................................................................................4
TESTING SPS.............................................................................................................................4
POSITIVE SCENARIOS.....................................................................................................................5
NEGATIVE SCENARIOS ...................................................................................................................5
TESTING TABLES.........................................................................................................................5
TESTING PROCESS........................................................................................................................5
TESTING FUNCTIONS.....................................................................................................................6
TESTING TRIGGERS.......................................................................................................................6
TESTING VIEWS..........................................................................................................................6
TESTING SQL JOBS.....................................................................................................................6
TESTING REPLICATION...................................................................................................................6
TESTING DATABASE BACKUP............................................................................................................7
SQL CODE COVERAGE FOR SPS......................................................................................................7
PERFORMANCE TESTING.................................................................................................................7
SECURITY TESTING.......................................................................................................................7
DATABASE TESTING PROJECT WITH VSTS DETAILS...............................................8
CREATING DATABASE TEST PROJECT...................................................................................................8
FOLLOWING TEST CONDITIONS WILL BE USED...........................................................................................8
TYPICAL SAMPLE TEST SCENARIO......................................................................................................12
BEST PRACTICES..............................................................................................15
Introduction
There are several reasons why we need to develop a comprehensive testing
strategy for your RDBMS:

1. Data is an important corporate asset. Data is backbone of application.

Without the data, there will be no commercial/business application.
Sometimes it will be very secured data. E.g.: Defense, banking and
finance etc..
2. Mission-critical business functionality is implemented in RDBMSs. In
most of the critical applications, business functionality will be implemented in
the database.
3. Current approaches aren't sufficient. There are several test tools and
approaches, but most of them are retired for new SQL releases.
4. Testing provides the concrete feedback required to identify defects.
Testing of database applications is crucial for ensuring high software quality
as undetected faults can result in unrecoverable data corruption.

Pre requisites
The person who is going to test should have permissions to connect to
required database server and database to execute automated tests. One should
have permissions to execute related SPs or operations on tables.

Configuration file will be used for connection strings, test data documents
path and sheet names etc..

What to test?
Following diagram shows all database objects which are to be tested.

Performance
& Security Tables
Stored
Procedures

Views
Functions DB

Triggers

Jobs

Data Backup
Replication Code
Coverage
Types of DB testing
1.Using Test project with database tests in Visual Studio Team Systems

2. Using normal test project with CSharp code along with ADO.net objects

3. There are also some tools like TSQLUnit, Empirix, RadView, SQLUnit, DBFit
and NDbUnit etc..

Note: First two are very easy and most proffered.

Basic operations in database testing

Insert, update, delete, select

Insert: Inserting data into table(s) with the SQL Queries or executing SP can
be done.

Update/Edit: Updating the data in table(s) with the SQL Queries or

executing SP can be done.

If it is required to update the data manually, transaction should be used.

Once required data is updated, transaction should be committed, else it should
be aborted.

Delete: Deleting the data from table(s) with the SQL Queries or executing
SP can be done.

If it is required to delete the data manually, transaction should be used. Once

required data is deleted, transaction should be committed, else it should be
aborted.

Select: Selecting the data from table(s) with the SQL Queries or executing
SP can be done.

If SP is executed, the result set can be single or multiple.

If query is executed, it returns only single result set. Wherever it is possible,

use no lock hint on table, it will give better performance.

Note 1: If queries are used in any of above operations, these should be

optimized

Note 2: All test data should be deleted after testing

Testing SPs
In general, Stored procedure can be used for any operation like
Insert/Update/Select/Delete or some business functions etc..
 Stored procedures should be tested for functionality(business rules) in all
possible positive and negative scenarios.

Positive scenarios
Passing all required parameters with valid values with valid range of data,
data type.

If parameter is not mandatory, null value can be passed.

Negative scenarios
Passing values with invalid data range(Boundary) as business rule
perspective

Passing null values for mandatory values

Testing Tables
Primary keys, foreign keys, nullability, default values, data types will be
tested.

Note: Testing should not be done for SQL behavior.

E.g.: Insertion with passing values which will break foreign/primary key
relationship

This is SQL behavior.

Testing Process
An excel document with multiple sheets will be used to have these values
according to FSD(Functional Specification Document).This will be done
manually.

Later, query will be executed on database and compare with the excel
values.

Check the following sample test data document.

ElectronicAddressDat Important
a.xls queries.docx

Logic: Data from Excel document will be loaded in to one dataset object.
Query will be used to fetch the actual data from database and kept into
another dataset object. Comparing these two datasets will give the result.

Testing for table data(Data Inspection):

Total number of records will be checked or data can be compared with the
excel/XML data document.
Testing Functions
Before testing the function, both input and output should be known to QA.

Pass input and cross verify the output.

Functionality should be tested with both positive and negative scenarios.

Testing Triggers
Invoke the trigger using related operation insert/delete/update on particular
table and check the trigger functionality. If trigger inserts the data into any
history table, then check the data in that table.

Testing Views
View should be tested whether it holds the required columns from required
tables.

This is similar to testing table. Here, data type, length, nullability should be
checked.

Testing SQL Jobs

In general, SQL Jobs will be linked to stored procedure(s).

Initiate the job either manually or through CSharp code and test the
functionality.

Sample CSharp code to invoke job with ADO object:

//Executes the job 'ReportJob_spMSWidePrivacyPermissionSnapshotUpsert'

string sqlQuery = "Exec msdb.dbo.sp_start_job @job_name =

'ReportJob_spMSWidePrivacyPermissionSnapshotUpsert'";

//Executes above query with generic method

ExecuteQuery(sqlQuery, "MDMElectronicAddressODSConnString");

Check the job history whether jobs are executed as scheduled and successful.

Note: Jobs will take some time to execute. Execution time depends on
functionality and data.

Testing Replication
Replication is meant for transferring the data from one data source to other
data source. In most of the cases, it would be snap shot(one way) replication.

1) Insert the data in publisher(server+ database +table) and check the data
in subscriber based on latency.
 This depends on many parameters like agent is not running at publisher/
subscriber or subscriber is down etc..

2)Update the existing data in publisher and check it in subscriber, same

should be reflected in subscriber.

3)Delete the existing data in publisher and check it in subscriber, same

should be deleted from subscriber.

Testing Database Backup

In general, full or differential backups will be done with linking to job and
scheduling.

Check the job history whether backups are done as scheduled.

Check the files, if file backups are used.

SQL Code Coverage for SPs

Officially there are no specific tools for SQL Code coverage for SQL 2008.

Some SPs and tables are required to trace SQL code coverage. One SP should
be executed in the first test case and other SP should be executed in the last test
case of SP which testing is required.

In general, all SPs should be covered at least 85%.

Performance Testing
This will be required when there are high volumes of data and many
transactions takes place in the application.

Within specified time, data should be deleted, inserted, updated, replicated,

backup or fetched by considering following factors.

A) There should be no data loss.

B) Expected(Correct) data should be fetched to the UI, if it is queried

C) All required databases and servers should be up and running

D) This testing will be done with different combinations.

E.g.: Inserting +Updating, Running Jobs+ Inserting, Running Jobs+ Updating ,

Running Jobs+Replication+update etc..

Security Testing
This ensures that only authenticated user can access the specified database
and server and executes operations based on login/user permissions.
 Sometimes, passwords will be encrypted in the database.

Database Testing Project with VSTS Details

Creating Database Test Project
1. Create a normal test project.

2. Right click on project and new test of type "Database Unit Test"

3.Give Test name

4.Give database server and database details when it is prompted

5.Design window will be opened to enter test scripts

6.Pre-Test and Post-Test scripts can be added in design window by choosing

respective value in the dropdown which is at top right in design window.

Following test conditions will be used

Empty ResultSet: This condition will be used to test empty result set. If
empty result set is expected in the output, this condition should be used.

It associates with two properties apart from name of test condition.

A)Enabled: This should be true, if it is to be used in testing. Otherwise it

would be false.

B)ResultSet: This is result set number.

By default, it would be 1(i.e. first result set).If there are multiple result sets,
give exact result set number

Sample Scenario: If Test SQL script output expects two result sets and second
result as empty.

Properties window will be as shown below.

Execution Time: This condition will be used to test execution time.

 It associates with two properties apart from name of test condition.

A)Enabled: This should be true, if it is to be used in testing. Otherwise it

would be false.

B)Execution Time: SQL script Execution time. By default, it would be

00:00:30 (i.e. 30 seconds).

Sample Scenario: If Test SQL script is expected to be executed with in 1 hour.

Properties window will be as shown below.

Not Empty ResultSet: This condition will be used in testing, if result set is
expected in the output.

It associates with two properties apart from name of test condition.

A)Enabled: This should be true, if it is to be used in testing. Otherwise it

would be false.

B)ResultSet: This is result set number.

By default, it would be 1(i.e. first result set).If there are multiple result sets,
give exact result set number

Sample Scenario: If Test SQL script output returns two result sets. First result
set is empty and second result set is expected to have some records.

Properties window will be as shown below.

Row Count: This condition will be used to check number of records in the
given result set.
 It associates with three properties apart from name of test condition.

A)Enabled: This should be true, if it is to be used in testing. Otherwise it

would be false.

B)ResultSet: This is result set number.

By default, it would be 1(i.e. first result set).If there are multiple result sets,
give exact result set number

C)Row Count: Number of records in the specified result set

Sample Scenario: If Test SQL script output returns two result sets. First result
set is empty and second result set is expected to have 10 records.

Properties window will be as shown below.

Scalar Value: This condition is used to check individual field value in the
specified row number and result set.

It associates with six properties apart from name of test condition.

A)Enabled: This should be true, if it is to be used in testing. Otherwise it

would be false.

B)ResultSet: This is result set number.

By default, it would be 1(i.e. first result set).If there are multiple result sets,
give exact result set number

C)Column number: This will be number

D)Expected Value:

E)Null expected: This is Boolean value

F)Row number: This will be number

Note: This is mostly used for checking numeric or Boolean values. This is case
sensitive check for text values.
 Sample Scenario: If Test SQL script output returns two result sets. First result
set is empty and second result set is expected to have some records and 2nd row
and 2nd column should have value 100

Properties window will be as shown below.

Every test case can have "Pre-Test" and " Post-Test" scripts along with the
"Test" script.

Pre-Test: In general, this will be used to insert the test data or perform some
execution before testing.

Test: This will have actual test script.

If test case is on testing SP, then script with executing SPs will be used.

Post-Test: In general, this will be used to delete the test data or perform
some execution after testing.

Sample Scenario: If data is updated in table 'Employee' in test script, same

changes should be reverted in post test.

Sample screen is shown below with test conditions, design window,

properties window etc..
Typical sample test scenario
An output of one test case script is following 2 result sets.

First is empty result set.

Second result set is with 10 records with the following values.

2nd column in 2nd row is 100

2nd column in 3rd row is 200

1st column in 2nd row is null

This script should be executed within 30 seconds.

Following 7 test conditions should be used:

 1. Condition to check whether first result set is empty as shown below.

2. Condition to check whether second result set is not empty as shown below.

3. Condition to check second result set with 2nd column in 2nd row value for
100 as shown below.

4. Condition to check second result set with 2nd column in 3rd row value for
200 as shown below.
 5. Condition to check 1st column in 2nd row value for null as shown below.

6. Condition to check whether script is executed within 30 seconds as shown

below.
 7. Condition to check whether second result set has 10 records as shown
below.

Best Practices
1. Use optimized queries and hints wherever it is possible

2. Test in all possible scenarios(deleting, inserting, executing SPs and

business rules etc..)

3.Ensure deleting the test data once it is tested

4.Ensure stop/start SQL service(s), up/down the databases, invoke/revoke

permissions properly after testing is done manually

5.Handle exceptions carefully

6. Release objects properly if ADO.Net objects are used in the application

7.Ensure static data should be up to date to cross verification

8.Train people in testing

9. Pair with novices with people that have database testing experience

10.Preffer to work in source safe