Data Base Testing - 1.0a

8/13/2019 Data Base Testing - 1.0a

1/12

2011

Aditi Technologies Pvt Ltd

Data Base Testing 1.0a

DATA BASE TESTINGDraft Version of Data Base Testing


2/12

August 26, 2011 DATA BASE TESTING

DB Testing Page 1

ContentsDATA BASE TESTING ...................................................................................................................................... 2

Database Testing brief .............................................................................................................................. 3

Why Database or back end testing is so important .............................................................................. 3

Differences between back end testing and front end testing .............................................................. 3

Back end test methodology .................................................................................................................. 3

Structural testing: ................................................................................................................................. 3

Functional testing: ................................................................................................................................ 3

Boundary testing: .................................................................................................................................. 3

Stress testing: ........................................................................................................................................ 4

Test a Database via a front end ............................................................................................................ 4

Entry Criteria ............................................................................................................................................. 4

Test Objects .............................................................................................................................................. 4

Tasks .......................................................................................................................................................... 5

Test Environment Preparation .............................................................................................................. 5

Test a Table ........................................................................................................................................... 5

Test Stored Procedure .......................................................................................................................... 6

Test Triggers .......................................................................................................................................... 6

Automation ........................................................................................................................................... 7

Roles & Responsibilities ............................................................................................................................ 7

Deliverables............................................................................................................................................... 8

Exit Criteria ................................................................................................................................................ 8

Appendix ................................................................................................................................................... 7

SQL Queries most used in DB Testing ................................................................................................... 8

Common defects in SQL databases ....................................................................................................... 9

Administration issues for database testing ........................................................................................ 10

Tools .................................................................................................................................................... 10

References .............................................................................................................................................. 11


3/12


DB Testing Page 2

DATA BASE TESTINGVerification of Database,

Data integrity

o The complete data belonging to each entity should be stored in the database.

Depending on the database design, the data may be present in a single table or multiplerelated tables. Parent-child relationships should exist in the data. There should not be

any missing data.

Correctness of the data stored in the database

o The data should be present in the correct table and correct field within the table.

Correctness and completeness of data migration (in case some or all the original data has come

from another source)

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3034837&SiteID=1

Functionality and performance of user objects e.g. functions, procedures, triggers, jobs

o Perform API testing on the user objects to test them.

Database performance (query execution times, throughput etc.) and locking problems

o Identify the main queries (or procedures) that are used in the application and time them

with sample data. Locking problems may become apparent when multiple inserts/

updates are being made to the same entity simultaneously.

Data security

o Check if any data that should be encrypted e.g. passwords, credit card numbers is in

plain text or not. The database should not have the default passwords. Even application

accounts should have passwords that are complex and not easily guessed.

Database fields (if they meet the specifications e.g. width, data type etc. as given in the design

documentation/ data dictionary etc.)

Normalization level

Compliance of user objects code to coding guidelines
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3034837&SiteID=1http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3034837&SiteID=1http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3034837&SiteID=1


4/12


DB Testing Page 3

Database Testing brief

Why Database or 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. A bug in a back end may put serious impacton 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 has several advantages: The

back end is no longer a "black box" to testers. We have full control of test coverage and depth. Many

bugs can be effectively found and fixed in the early development stage.

Differences between back end testing and front end testing

It is not easier to understand and verify a back end than a front end because a front end usually has

friendly and intuitive user interfaces.

A back end has its own objects, such as, tables, stored procedures and triggers. Data integrity and

protection is critical. Performance and multi-user support are big issues. Slowness in operation can be

vital to the projects future. There are no sufficient tools for back end testing. SQL language is mainly a

testing tool. However, there are a large number of test tools available for front end testing.

To be able to do back end testing, a tester must have strong background in Database and SQL language.

It is relatively difficult to find testers who understand both Database server and SQL testing.

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

Structural testing:

A back end can be broken down into a finite number of testable pieces based on a back ends 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 applications

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.


5/12


DB Testing Page 4

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.

Test a Database via a front end

Sometimes back end bugs can be found by front end testing, try to do the following things while testing

a backend via front-end

Make queries from a front end and issuethe 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.)

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

Entry Criteria

Relational Database Design fundamentals

SQL fundamentals

RDBMS administration knowledge

Automation Scripting knowledge

Test Objects

Test objects that should be covered in database.

Schema

Stored Procedures

Triggers

Database schema testing

Databases and devices

Tables, columns, column types, defaults, and rulesKeys and indexes

Stored procedure tests

Individual procedure tests

Integration tests of procedures

Trigger tests


6/12


DB Testing Page 5

Updating triggers

Inserting triggers

Deleting triggers

Tasks

Test Environment Preparation

Accessing Permissions

In Progress

Test a Table

Verify Table name

Verify Column names

Verify Column types

Verify Column allows NULL or not

Verify Default definitions

Verify Access privileges are granted to correct groups

Verify Primary Key

Verify Candidate Keys

Verify Foreign Keys


7/12


DB Testing Page 6

Test Stored Procedure

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

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.

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

Test Triggers

Updating triggers


Make sure trigger name spelling is correct

See if a trigger is generated for a specific table column

Triggers 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


8/12


DB Testing Page 7

Inserting triggers


Make sure trigger name spelling


Triggers 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 doesnt)

Deleting triggers


Make sure trigger name spelling


Triggers 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 doesnt)

Automation

In Progress

Roles & Responsibilities

Test Manager

Test Lead

SDET

Sr Automation Engineer

Test Engineer

Sr Test Engineer


9/12


DB Testing Page 8

Deliverables

Test Environment details

DB Test Plan

Test Scenarios & Cases

Test Results

Exit Criteria

Appendix

SQL Queries most used in DB Testing

Querying the recent data

Select top 1 * from tablename order by date/time desc

Ex: Select top 1 * from employee order by joiningdate desc

Checking for the duplicate records

Select * from tablename group by keycolumn having count (*) > 1

Ex: Select * from employee group by empid having count (*) > 1

Find out the existence of objects

Select * from sysobjects where type = (SQL Server)

Where can be

U ------- User table

V ------- View

P ------- Stored procedure

TR ------ Trigger

Select * from User_Objects where Object_name like xxxxxx (Oracle)

How does one escape special characters when building SQL queries?

The LIKE keyword allows for string searches. The '_' wild card character is used to match exactly

one character; '%' is used to match zero or more occurrences of any characters. These

characters can be escaped in SQL.

Example:

SELECT name FROM emp WHERE id LIKE '%\_%' ESCAPE '\';

Use two quotes for every one displayed.


10/12


DB Testing Page 9

Example:

SELECT 'Franks''s Oracle site' FROM DUAL;

SELECT 'A ''quoted'' word.' FROM DUAL;

SELECT 'A ''''double quoted'''' word.' FROM DUAL;

How does one eliminate duplicates rows from a table?

Choose one of the following queries to identify or remove duplicate rows from a table leaving

only unique records in the table:

Method 1:

SQL> DELETE FROM table_name A WHERE ROWID > (SELECT min (rowid) FROM

table_name B WHERE A.key_values = B.key_values);

Method 2:

SQL> create table table_name2 as select distinct * from table_name1;

SQL> drop table_name1;

SQL> rename table_name2 to table_name1;

SQL> -- Remember to recreate all indexes, constraints, triggers, etc on table...

Method 3:

SQL> delete from my_table t1

SQL> where exists (select 'x' from my_table t2 where t2.key_value1 = t1.key_value1 and

t2.key_value2 = t1.key_value2

and t2.rowid > t1.rowid);

Common defects in SQL databases

Reasonableness of the data - If you regularly receive a certain amount of sales, an influx of rows

added to critical system tables well over the norm should raise a red flag. So should lack of records

on days that should have generated a regular amount of sales.

Data corruption- Data should be regularly QAd to find garbage data within columns

Redundant data - Hidden duplicate records (same customer added twice with different primary

keys). How many of us get multiple copies of newsletters? This annoys and loses customers.

Evidence of hacking- Plan test cases to uncover multiple similar records added on the same day.

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

inconsistent data. For example, if the customer application adds data with formatting applied to

columns such as phone numbers and e-mail, but the Admin application to the same data does not,

then the data can become inconsistent and not match properly with reports. A worse example is


11/12


DB Testing Page 10

required fields set at the customer application not being set at the Admin application leaving orphan

records or unintelligible data.

Evidence of hacking

o SQL Injection attacks

Malicious attempts to corrupt data

Serious attempts to reprise data for theft or embezzlement

Multiple users added

o Denial of service attempts

Overloaded tables

Administration issues for database testing

Server-side management issues:

Defective Installations and Configurations

Database Security Issues

Disaster Recovery Issues

Creating a Test Server

Distributed Data Issues

Replication Issues

Reliability and Capacity planning

Tools

Category Description Examples

Unit testingtools

Tools which enable you toregression test yourdatabase.

AnyDbTest DBFit DBUnit NDbUnit

OUnit for Oracle (being replaced soon byQute)

SQLUnit TSQLUnit(for testing T-SQL in MS SQL

Server) Visual Studio Team Edition for Database

Professionalsincludes testing capabilities XTUnit

Testingtools forload testing

Tools simulate high usageloads on your database,enabling you to determinewhether your system'sarchitecture will stand up toyour true production needs.

Empirix Mercury Interactive RadView Rational Suite Test Studio Web Performance
http://www.anydbtest.com/http://www.anydbtest.com/http://gojko.net/fitnesse/dbfithttp://gojko.net/fitnesse/dbfithttp://www.dbunit.org/http://www.dbunit.org/http://www.ndbunit.org/http://www.ndbunit.org/http://www.ounit.com/http://www.ounit.com/http://www.unit-test.com/http://www.unit-test.com/http://sqlunit.sourceforge.net/http://sqlunit.sourceforge.net/http://tsqlunit.sourceforge.net/http://tsqlunit.sourceforge.net/http://msdn.microsoft.com/vstudio/teamsystem/products/dbpro/http://msdn.microsoft.com/vstudio/teamsystem/products/dbpro/http://msdn.microsoft.com/vstudio/teamsystem/products/dbpro/http://msdn.microsoft.com/vstudio/teamsystem/products/dbpro/http://msdn.microsoft.com/vstudio/teamsystem/products/dbpro/http://weblogs.asp.net/rosherove/archive/2004/10/05/238201.aspxhttp://weblogs.asp.net/rosherove/archive/2004/10/05/238201.aspxhttp://www.empirix.com/http://www.empirix.com/http://www.mercury.com/us/solutions/application-delivery/http://www.mercury.com/us/solutions/application-delivery/http://www.radview.com/http://www.radview.com/http://www-306.ibm.com/software/sw-bycategory/subcategory/SW730.htmlhttp://www-306.ibm.com/software/sw-bycategory/subcategory/SW730.htmlhttp://www.webperformanceinc.com/http://www.webperformanceinc.com/http://www.webperformanceinc.com/http://www-306.ibm.com/software/sw-bycategory/subcategory/SW730.htmlhttp://www.radview.com/http://www.mercury.com/us/solutions/application-delivery/http://www.empirix.com/http://weblogs.asp.net/rosherove/archive/2004/10/05/238201.aspxhttp://msdn.microsoft.com/vstudio/teamsystem/products/dbpro/http://msdn.microsoft.com/vstudio/teamsystem/products/dbpro/http://tsqlunit.sourceforge.net/http://sqlunit.sourceforge.net/http://www.unit-test.com/http://www.ounit.com/http://www.ndbunit.org/http://www.dbunit.org/http://gojko.net/fitnesse/dbfithttp://www.anydbtest.com/


12/12


DB Testing Page 11

Test DataGenerator

Developers need test dataagainst which to validate theirsystems. Test datagenerators can be particularlyuseful when you need largeamounts of data, perhaps for

stress and load testing.

Data Factory Datatect DTM Data Generator Turbo Data

References

http://msdn.microsoft.com/en-US/library/bb381703(v=VS.80).aspx
http://www.quest.com/datafactory/http://www.quest.com/datafactory/http://www.datatect.com/http://www.datatect.com/http://www.sqledit.com/dg/http://www.sqledit.com/dg/http://www.turbodata.ca/http://www.turbodata.ca/http://msdn.microsoft.com/en-US/library/bb381703(v=VS.80).aspxhttp://msdn.microsoft.com/en-US/library/bb381703(v=VS.80).aspxhttp://msdn.microsoft.com/en-US/library/bb381703(v=VS.80).aspxhttp://www.turbodata.ca/http://www.sqledit.com/dg/http://www.datatect.com/http://www.quest.com/datafactory/

Documents

Data Base Testing - 1.0a