DataBase Testing

Objectives
What is DB Testing ? Testing at the Data Access Layer Scope of DB Testing Need for Testing DB Objects Common Problems that affect the Application Testing Application Vs DB Testing contd..

Objectives
Should Testers Know Databases Testing the Performance of the Database Data Integrity Understanding E/R Model Identifying defects in E/R Diagrams Case Studies on E/R Diagrams Writing Test Cases to Test Databases

What is Database Testing

Database Testing includes Testing for Data Integrity , Data Validity , Data manipulation. Database Objects can be tables, views , stored procedures , indexes etc Time taken for Retrieval of Records from the Database Time for Query Execution

Layers in a Application
Client Layer Is responsible for the presentation of data, receiving user events and controlling the user interface. Application Layer - Business-objects that implement the business rules "live" here, and are available to the client-tier Data Layer : This tier is responsible for data storage

Application Types
Single Tier Architecture
Client & Business Logic & Data Storage are all wrapped together

2 Tier Architecture
Business Logic and Data Storage are together and the Client is a separate layer

3 or the N tier Architecture

Client , the Business Logic and the Datastorage are kept separately

3 or N Tier Architecture

Client Layer

Business Logic Layer

Database Layer

Testing Should Include

Testing the Front End / GUI / Client Layer Testing the Business Logic Layer Testing the Database
Reviewing E/R Diagrams Reviewing the Database Designs Reviewing the Tables, views , stored procedures etc

Why Test Database Objects

Data is stored in the tables Stored Procedures will handle the Insertion , deletion & Updation & Retrieval of Information from the Database No Testing/Improper testing will result in missing critical application functionality

GUI Vs Database Testing

Traditionally all the data testing is done at the GUI Level Corruption of data can occur at any layer We must present verification of application correctness as data travels through the system.

Problems if Database Testing is Ignored

Data corruption
Occurs due to poor design

Redundant data
Hidden duplicate records (same customer added twice with different primary keys).

Inconsistent data
Data records added to the same database through multiple applications can add inconsistent data.

Redundant validation
Validating business rules on the db, as well as the client, can cause conflicts if theyre not well-coordinated

Why Should Test Professional know DBMS

Inadequate knowledge of Relational db design fundamentals leads to logic errors and very common bugs in systems Basic normalization principles can and should be tested but isnt -- because most testers have no idea what that is Effective DB testers should be able to uncover design problems quickly

Data Integrity
Data Integrity Ensures the Consistency and correctness of Data stored in a Database Maintenance of data values according to data model and data type. For example, to maintain integrity, numeric columns will not accept alphabetic data.

Normalisation

It's the process of efficiently organizing data in a database.

The database community has developed a series of guidelines for ensuring that databases are normalized. These are referred to as normal forms

Goals of Normalisation
There are two goals of the normalization process Eliminate redundant data Storing Related Data in a Table

Normalisation
First Normal Form Second Normal Form Third Normal Form Boyce Codd Normal Form

Normalisation
In the First Normal Form Every Cell should contain a single value. Eliminate redundant data (for example, storing the same data in more than one table) Create separate tables for each group of related data and identify each row with a unique column (the primary key).

Normalisation
Emp Code Dept
E101 Systems

ProjCode
P1, P2 , P3

Hours
12,14,16

E102

Finance

P2,P3

14,16

Normalisation
In the Second Normal Form Meet all the requirements of the first normal form. And Every attribute in the row is functionally dependent upon the whole key and not part of the key

Functional Dependany
Given a table R, Attribute A is functionally dependant on attribute B if each value of A is associated precisely with one value of B Eg. In the Employee Table against every EmpCode there will only one Name so Name is functionally dependant on EmpCode

Normalisation
ECode E101 E305 ProjCode P27 P27 Dept Systems Finance Hours 90 10

E508
E101

P51
P51

Admin
Systems

101
101

E101

P20

Systems

60

Normalisation
The Above Table is in the First Normal Form. The Above table will lead to the following problems : Insertion dept of a particular employee cannot be inserted untill the employee is assigned a project

Normalisation
Updation :If an employee is transferred from one department to another the changes have to be made n number of times in the table Deletion : When the Project is over and the record deleted we will loose information about the department for that employee

Normalisation
PK = Ecode + ProjCode The above table is in the First Normal Form we need to check if its in 2nd Normal Form Hours is not functionally dependent on Ecode. Hours is not functionally dependent on ProjCode Hours is functionally dependent on Ecode+ProjCode

Normalisation
Dept is functionally dependent on Ecode. Dept is not Functionally dependent on ProjCode Dept is functionally dependent on part of the key (Ecode+ProjCode) Therefore table is not in 2 N F Therefore Place Dept along with Ecode in a separate table

Normalisation
Ecode
E101 E305 E508
EMPLOYEEDEPT

Dept
Systems Sales Admin

Normalisation
PROJECT

Ecode E101 E101 E101 E305

ProjCode P27 P51 P20 P27

Hours 90 101 60 10

Normalisation
In the Third Normal Form Meet all the requirements of the second normal form. Remove columns that are not dependent upon the primary key. In other words a relation is said to be in 3NF when every non key attribute is functionally dependent only on the Primary Key

Normalisation
Ecode E101 E305 E402 Dept Systems Finance Sales DeptHead E901 E906 E906

E508
E607

Admin
Finance

E908
E909

E608

Finance

E909

Normalisation
The Primary Key is Ecode Dept is functionally dependent on Ecode DeptHead is functionally dependent on the primary Key Ecode. All attributes are functionally dependent on the whole key Ecode Therefore Table is in 2NF But DeptHead is functionally dependent on Dept .

Normalisation
The Primary Key is Ecode Dept is functionally dependent on Ecode DeptHead is functionally dependent on the primary Key Ecode. All attributes are functionally dependent on the whole key Ecode Therefore Table is in 2NF But DeptHead is functionally dependent on Dept .

Normalisation
The table is not in the 3 NF because as per the third Normal Form every attribute should be functionally dependent only on the Primary Key. Identify and remove the attributes that are not functionally dependent on the primary key. Place them in a different table

Normalisation
Employee

Ecode E101 E305

Dept Systems Finance

E402
E508 E607

Sales
Admin Finance

Normalisation
Department

Dept Systems Sales

DeptHead E901 E906

Admin
Finance

E908
E909

Denormalisation
Denormalization is the process of attempting to optimize the performance of a database by adding redundant data

What do we Test at the DB Level

Validate the table naming conventions Validate the column naming conventions To check if the correct datatype is selected for a column To check the consistency in datatypes for columns common across tables To ensure the usage of correct field width

What do we Test at the DB Level

To ensure consistency in field width for columns common across tables Existence of a primary key on a table Existence of a foreign key on a table Validity of check constraints Validity of default constraints Check for presence of indexes on a column

What do we Test at the DB Level

Check for Unique indexes Existence of non-clustered indexes Existence of clustered indexes Note the time of execution of queries Note the time of compilation of queries

What do we Test at the DB Level

Evaluate the query execution plan Note the time of execution of stored procedures Note the time of compilation of stored procedures Evaluate the query execution plan Denormalize the tables Normalize the tables

Case Study
Write Review Cases for the following Table Structures (Check for Table Naming Conventions, DataType, Field Size , Keys ,Constraints)

Database Test Tools

Data Factory : Quest Software Data generator tool and data manager for database testing SQL Tuner : Embaradero Eases the complexity of writing highperformance SQL code by providing built-in help for writing syntactically correct SQL, and by assisting in every aspect of complex tuning efforts.

Database Test Tools

Datatect : Banner Software Generate a variety of realistic test data to RDBMS including Oracle, Sybase, SQL Server, and Informix DB Stress : DTM Utility for stress testing the server parts of information systems and applications, as well as DBMSs and servers themselves.

Database Test Tools

Datatect : Banner Software Generate a variety of realistic test data to RDBMS including Oracle, Sybase, SQL Server, and Informix DB Stress : DTM Utility for stress testing the server parts of information systems and applications, as well as DBMSs and servers themselves.

Database Test Tools

Database Opensource Test Suite The Database Opensource Test Suite (DOTS) is a set of test cases designed for the purpose of stress-testing database server systems in order to measure database server performance and reliability.

Database Test Tools

DBMonster DBMonster is an application to generate random data for testing SQL database driven applications under heavy load.