Data validity testing:

Data validity testing: Testing the correctness and reasonableness of data.

Ex: Account no falling within range, numeric data being all digits, dates having valid months
Note: Data validity errors are more common and most difficult to detect.
Errors in data validity are caused by End user/ by who enters Ex: 13/25/2006
Data Integrity testing:
Date integrity is nothing but enforcing the business rules (facts/data) into database table is called data integrity
Types of Data Integrity :
Entity Integrity: can be achieved through Primary Key and Unique Key Constraints.
Should be tested: whether it is taking duplicate values, Whether it is taking null values.
Domain Integrity: can be achieved through Not null, Default, Check .
Should be tested: Whether it is taking default values even though if we won’t give, checking the values in the column. Ex: age column
should take < 60.
Referential Integrity: can be achieved through Foreign Key.
Should be tested : Checking Whether "child" rows are deleted or not when a parent row is deleted from parent table.
For performance related Testing in DB:
Indexes are used to increase the performance.
It is nothing but ordered list of values taken from one or more columns in the tables and organized in to b_tree structure
Need to test: whether we have created index on column for particular table or not.
What is Data ? And How it is Importance to the Organization
A collection of facts, Pieces of information from which conclusions may be drawn.
Ex: Resumes for managing the human Resources..!
What is Database..?
The Collection of Interrelated Data is called Data Base.
Relational Database Concepts
RDBMS= DBMS +Referential Integrity (It is achieved through Foreign Key).
Referential Integrity :The existence of a value in one dataset is dependent on the existence of the same value in another linked dataset
Ex: Oracle, Sqlserver, Mysql follow RDBMS model.
What is Database Testing ?
Testing an application’s interface with a relational database.
Interface: SQL is nothing but Interface Between RDBMS and application so it lets us to extract, combine, manipulate, and organize data
and many more….!
What should we Test in Data Base
Database testing basically include the following.
1)Data validity testing.
2)Data Integrity testing
3)Performance related to data base.
4)Testing of Procedure, triggers and functions.

1
Why back end testing is so important
A back end is the engine of any client/server system. If the back end malfunctions, it may
cause system deadlock, data corruption, data loss and bad performance. Many front ends
log on to a single SQL server. A bug in a back end may put serious impact on the whole
system. Too many bugs in a back end will cost tremendous resources to find and fix bugs
and delay the system developments.
It is very likely that many tests in a front end only hit a small portion of a back end. Many
bugs in a back end cannot be easily discovered without direct testing.
Why back end testing is so important
A back end is the engine of any client/server system. If the back end malfunctions, it may
cause system deadlock, data corruption, data loss and bad performance. Many front ends
log on to a single SQL server. A bug in a back end may put serious impact on the whole
system. Too many bugs in a back end will cost tremendous resources to find and fix bugs
and delay the system developments.

It is very likely that many tests in a front end only hit a small portion of a back end. Many
bugs in a back end cannot be easily discovered without direct testing.

Back end testing phases

There are several phases in back end testing. The first step is to acquire design
specifications for an SQL server. The second step is test specification design. The next step
is to implement the tests in this design with SQL code. The test specification design should
contain information concerning component testing (individual pieces of the system),
regression testing (previously known bugs), integration testing (several pieces of the system
put together), and then the entire system (which will include both front and back ends).

Component testing will be done early in the development cycle. Integration and system tests
(including interfaces to front ends and nightly processes) are performed after the component
tests pass. Regression testing will be performed continuously throughout the project until it
is finished. The back end usually does not have an independent beta test, as it only
exercised by the front end during the beta test period. The last step is to deliver users a
quality product

Back end test methodology

Back end test methodology has many things in common with front end testing and API
testing. Many test methods can be used for back end testing. Structural testing and
functional testing are more effective approaches in back end testing. They are overlapped in
some test cases. However, the two methods may discover different bugs. We strongly
recommend testers to do both types of testing. There are many other test methods that can
be applied to back end testing. We list a few below. For other test methods, please check
other test design references.
Structural testing
A back end can be broken down into a finite number of testable pieces based on a back
end’s structure. Tests will verify each and every object in a type of structure.
Functional testing
A back end can be broken down into a finite number of testable pieces based on

2
application’s functionality. The test focus is on functionality of input and output but not on the
implementation and structure. Different projects may have different ways to break down.
Boundary testing
Many columns have boundary conditions. For example, in a column for percentages, the
value cannot be less than zero and cannot be greater than 100%. We should find out these
types of boundary conditions and test them.

Stress testing
It involves subjecting a database to heavy loads. For incidence, many users heavily access
the same table that has a large number of records. To simulate this situation, we need to
start as many machines as possible and run the tests over and over.
STRUCTURAL BACK END TESTS
Although not all databases are the same, there are a set of test areas that will be covered in
all test specifications.

Based on structure, a SQL database can be divided into three categories: database
schema, stored procedures, and triggers. Schema includes database design, tables, table
columns, column types, keys, indices, defaults, and rules. Stored procedures are
constructed on the top of a SQL database. The front end talks to APIs in DLL. The APIs
communicate a SQL database through those stored procedures. Triggers are a kind of
stored procedures. They are the "last line of defense" to protect data when data is about to
be inserted, updated or deleted.

1. Database schema testing[This is the main DB Testing]

Test Coverage Criterion: “EACH AND EVERY ITEM IN SCHEMA MUST BE TESTED AT
LEAST ONCE”
1.1 Databases and devices
Verify the following things and find out the differences between specification and actual
databases
• Database names
• Data device, log device and dump device
• Enough space allocated for each database
• Database option setting (i.e. trunc. option)

1.2 Tables, columns, column types, defaults, and rules

Verify the following things and find out the differences between specification and actual
tables
• All table names
• Column names for each table
• Column types for each table (int, tinyint, varchar, char, text, datetime. specially the number
of characters for char and varchar)
• Whether a column allows NULL or not
• Default definitions
• Whether a default is bound to correct table columns
• Rule definitions

3
• Whether a rule is bound to correct table columns
• Whether access privileges are granted to correct groups

1.3 Keys and indexes,

Verify the following things and compare them with design specification
• Primary key for each table (every table should have a primary key)

• Foreign keys
• Column data types between a foreign key column and a column in other table
• Indices, clustered or nonclustered; unique or not unique

2. Stored procedure tests

Test Coverage Criterion: “EACH AND EVERY STORED PROCEDURE MUST BE TESTED
AT LEAST ONCE”
2.1 Individual procedure tests
Verify the following things and compare them with design specification
• Whether a stored procedure is installed in a database
• Stored procedure name
• Parameter names, parameter types and the number of parameters
Outputs:
• When output is zero (zero row affected)
• When some records are extracted
• Output contains many records
• What a stored procedure is supposed to do
• What a stored procedure is not supposed to do
• Write simple queries to see if a stored procedure populates right data
Parameters:
• Check parameters if they are required.
• Call stored procedures with valid data
• Call procedures with boundary data
• Make each parameter invalid a time and run a procedure

Return values:
• Whether a stored procedure returns values
• When a failure occurs, nonzero must be returned.
Error messages:
• Make stored procedure fail and cause every error message to occur at least once
• Find out any exception that doesn’t have a predefined error message
Others:
• Whether a stored procedure grants correct access privilege to a group/user
• See if a stored procedure hits any trigger error, index error, and rule error
• Look into a procedure code and make sure major branches are test covered.
2.2 Integration tests of procedures
• Group related stored procedures together. Call them in particular order
• If there are many sequences to call a group of procedures, find out equivalent classes and
run tests to cover every class.

4
• Make invalid calling sequence and run a group of stored procedures.
• Design several test sequences in which end users are likely to do business and do stress
tests
Trigger tests

Test Coverage Criterion: “EACH AND EVERY TRIGGER AND TRIGGER ERROR MUST
BE TESTED AT LEAST ONCE”
1. Updating triggers
Verify the following things and compare them with design specification

• Make sure trigger name spelling is correct

• See if a trigger is generated for a specific table column
• Trigger’s update validation
• Update a record with a valid data
• Update a record, a trigger prevents, with invalid data and cover every trigger error
• Update a record when it is still referenced by a row in other table
• Make sure rolling back transactions when a failure occurs
• Find out any case in which a trigger is not supposed to roll back transactions
2. Inserting triggers
Verify the following things and compare them with design specification

• Make sure trigger name spelling

• See if a trigger is generated for a specific table column
• Trigger’s insertion validation
• Insert a record with a valid data
• Insert a record, a trigger prevents, with invalid data and cover every trigger error
• Try to insert a record that already exists in a table
• Make sure rolling back transactions when an insertion failure occurs
• Find out any case in which a trigger should roll back transactions
• Find out any failure in which a trigger should not roll back transactions
• Conflicts between a trigger and a stored procedure/rules
(i.e. a column allows NULL while a trigger doesn’
3. Deleting triggers
Verify the following things and compare them with design specification
Make sure trigger name spelling
• See if a trigger is generated for a specific table column
• Trigger’s deletion validation
• Delete a record
• Delete a record when it is still referenced by a row in other table
• Every trigger error
• Try to delete a record that does not exists in a table
• Make sure rolling back transactions when a deletion fails
• Find out any case in which a trigger should roll back transactions
• Find out any failure in which a trigger should not roll back transactions
• Conflicts between a trigger and a stored procedure/rules
(i.e. a column allows NULL while a trigger doesn’t)

5
4. Integration tests of SQL server
Integration tests should be performed after the above component testing is done. It should
call stored procedures intensively to select, update, insert and delete records in different
tables and different sequences. The main purpose is to see any conflicts and incompatibility.
• Conflicts between schema and triggers
• Conflicts between stored procedures and schema
• Conflicts between stored procedures and triggers

5 Server setup scripts

Two cases must be tests: One is to set up databases from scratch and the other to set up
databases when they already exist. Below is the minimum list of areas:

• Is a setup batch job available to run without much operator’s assistance

(It is not acceptable if it requires an operator to run many batch jobs manually)
• Work environment the setup needs to run (DOS, NT)
• Environment variables (i.e. is %svr% defined?)
• Time it takes to set up
• Set up databases from scratch.
• Set up from existing databases
• Set up log and failure messages
• After setup, check for
Databases
Tables
Tables attachments (Keys, indexes, defaults, column names and column types)
Triggers
Stored procedures
Look up data
User access privileges

FUNCTIONAL BACK END TESTS

Functional tests more focus on functionality and features of a back end. Test cases can be
different from project to project. But many projects have things in common. The following
section discusses the common areas. We encourage testers to add project-specific test
cases in the functional test design.
How to divide back end on function basis

It is not a good idea to test a server database as a single entity at initial stage. We have to
divide it into functional modules. If we can not do the partition, either we do not know that
project deep enough or the design is not modulized well. How to divide a server database is
largely dependent on features of a particular project.

METHOD 1: We may ask ourselves what the features of a project are. For each major
feature, pick up portion of schema, triggers and stored procedures that implement the
function and make them into a functional group. Each group can be tested together. For

6
example, the Forecast LRS project had four services: forecast, product lite, reporting, and
system. This was the key for functional partitioning:

METHOD 2: If the border of functional groups in a back end is not obvious, we may watch
data flow and see where we can check the data: Start from the front end. When a service
has a request or saves data, some stored procedures will get called. The procedures will
update some tables. Those stored procedures will be the place to start testing and those
tables will be the place to check test results.
1. Test functions and features
Test Coverage Criterion: “EACH AND EVERY FUNCTION OR FEATURE MUST BE
TESTED AT LEAST ONCE”
The following areas should be tested:
• Every feature no matter major or minor
• For updating functions, make sure data is updated following application rules
• For insertion functions, make sure data is inserted following application rules
• For deletion functions, make sure data is deleted correctly
• Think about if those functions make any sense to us. Find out nonsense, invalid logic, and
any bugs.
• Check for malfunctioning
• Check for interoperations
• Error detection
• Error handling
• See if error messages are clear and right.
• Find out time-consuming features and provide suggestions to developers
Checking data integrity and consistency
This is a really important issue. If a project does not guarantee data integrity and
consistency, we have obligation to ask for redesign. We have to check the minimum things
below:

• Find out data protection mechanisms for a project and evaluate them to see if they are
secure
• Data validation before insertion, updating and deletion.
• Triggers must be in place to validate reference table records
• Check major columns in each table and see if any weird data exist. (Nonprintable
characters in name field, negative percentage, and negative number of PSS phone calls per
month, empty product and so on)
• Generate inconsistent data and insert them into relevant tables and see if any failure
occurs
• Try to insert a child data before inserting its parent’s data.
• Try to delete a record that is still referenced by data in other table
• If a data in a table is updated, check whether other relevant data is updated as well
• Make sure replicated servers or databases are on sync and contain consistent information

3. Login and user security

The following things need to be checked:

7
• Email validation
• SQL user login (user id, password, host name)
• NT server login
• Database access privilege (the sysusers table)
• Database security hierarchy
• Table access privilege (if ‘select’ is allowed.)
• Table data access control
• Training account (maybe no password is required)
There are more test cases here:
• Simulate front end login procedure and check if a user with correct login information can
login
• Simulate front end login procedure and check if a user with incorrect login information fail
to login
• Check concurrent logins (make many users login at the same time.)
• Try to login when a time-consuming query is running to see how long login will take to
succeed
• Check for any security-restrict functions and see they are working proper
See any data view restriction in place, such as, a user can see his data and the data of
people who report to him.
4. Stress Testing

We should do stress tests on major functionality. Get a list of major back end
functions/features for a project. Find out corresponding stored procedures and do the
following things:

Test Coverage Criterion: “EACH AND EVERY MAJOR FUNCTION OR FEATURE MUST
BE INCLUDED IN STRESS TESTING”

• Write test scripts to try those functions in random order but every function must be
addressed at least once in a full cycle.
• Run test scripts over and over for a reasonable period
• Make sure log execution results and errors.
• Analyze log files and look for any deadlock, failure out of memory, data corruption, or
nothing changed.
5. Test a back end via a front end
Sometimes back end bugs can be found by front end testing, specially data problem. The
following are minimum test cases:
• Make queries from a front end and issue the searches (It hits SELECT statements or query
procedures in a back end)
• Pick up an existing record, change values in some fields and save the record. (It involves
UPDATE statement or update stored procedures, update triggers.)
• Push FILE - NEW menu item or the NEW button in a front end window. Fill in information
and save the record. (It involves INSERT statements or insertion stored procedures,
deletion triggers.)
• Pick up an existing record, click on the DELETE or REMOVE button, and confirm the
deletion. (It involves DELETE statement or deletion stored procedures, deletion triggers.)

8
• Repeat the first three test cases with invalid data and see how the back end handles them.

benchmark testing

Test Coverage Criterion: “EACH AND EVERY FUNCTION OR FEATURE MUST BE

INCLUDED IN BENCHMARK TESTING”

When a system does not have data problems or user interface bugs, system performance
will get much attention. The bad system performance can be found in benchmark testing.
Four issues must be included:

• System level performance

• Major functionality (Pick up most-likely-used functions/features)
• Timing and statistics (M