database testing. objectives what is db testing ? testing at the data access layer scope of db...

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

• 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

What is Database Testing

• 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

Layers in a Application

• 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

Application Types

Client LayerBusiness Logic

Layer Database Layer

3 or N Tier Architecture

• 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

Testing Should Include

• 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

Why Test Database Objects

• 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.

GUI Vs Database Testing

• Data corruption – Occurs due to poor design

• Redundant data – Hidden duplicate records (same customer addedtwice 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

– they’re not well-coordinated

Problems if Database Testing is Ignored

• 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 isn’t -- because most testers have no idea what that is

• Effective DB testers should be able to uncover design problems quickly

Why Should Test Professional know DBMS

• 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.

Data Integrity

• 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

Normalisation

Goals of Normalisation

• There are two goals of the normalization process

• Eliminate redundant data

• Storing Related Data in a Table

• 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

Normalisation

Emp Code Dept ProjCode Hours

E101 Systems P1, P2 , P3

12,14,16

E102 Finance P2,P3 14,16

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

Normalisation

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 ProjCode Dept Hours

E101 P27 Systems 90

E305 P27 Finance 10

E508 P51 Admin 101

E101 P51 Systems 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 Dept

E101 Systems

E305 Sales

E508 Admin

EMPLOYEEDEPT

Normalisation

PROJECT

Ecode ProjCode Hours

E101 P27 90

E101 P51 101

E101 P20 60

E305 P27 10

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

Normalisation

Ecode Dept DeptHead

E101 Systems E901

E305 Finance E906

E402 Sales E906

E508 Admin E908

E607 Finance E909

E608 Finance E909

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

Normalisation

Ecode Dept

E101 Systems

E305 Finance

E402 Sales

E508 Admin

E607 Finance

Employee

Normalisation

Dept DeptHead

Systems E901

Sales E906

Admin E908

Finance E909

Department

Denormalization is the process of

attempting to optimize the performance

of a database by adding redundant data

Denormalisation

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


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


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


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

Case Study

Data Factory : Quest SoftwareData generator tool and data manager for

database testingSQL Tuner : Embaradero Eases the complexity of writing high-

performance 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

http://www.embarcadero.com/products/sqltuner/index.html

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

http://www.datatect.com/

http://www.datatect.com/

– 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.

Database Test Tools

database testing. objectives what is db testing ? testing at the data access layer scope of db...

Documents