2011

Aditi Technologies Pvt Ltd Data Base Testing 1.0a

DATA BASE TESTING

Draft Version of Data Base Testing

August 26, 2011

DATA BASE TESTING

Contents
DATA 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

DB Testing

Page 1

August 26, 2011

DATA BASE TESTING

DATA BASE TESTING

Verification 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 multiple related 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

DB Testing

Page 2

August 26, 2011

DATA BASE TESTING

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

DB Testing

Page 3

August 26, 2011

DATA BASE TESTING

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 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.) 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 rules Keys and indexes

Stored procedure tests

Individual procedure tests Integration tests of procedures

Trigger tests
DB Testing Page 4

August 26, 2011 Updating triggers Inserting triggers Deleting triggers

DATA BASE TESTING

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

DB Testing

Page 5

August 26, 2011 Test Stored Procedure

DATA BASE TESTING

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 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 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 DB Testing Page 6

August 26, 2011

DATA BASE TESTING

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

DB Testing

Page 7

August 26, 2011

DATA BASE TESTING

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 = <type>(SQL Server) Where <type> 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. DB Testing Page 8

August 26, 2011

DATA BASE TESTING

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

DB Testing

Page 9

August 26, 2011

DATA BASE TESTING

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: Tools
Category Description Examples Testing Tools simulate high usage tools for loads on your database, load testing enabling you to determine whether your system's architecture will stand up to your true production needs. AnyDbTest DBFit DBUnit NDbUnit OUnit for Oracle (being replaced soon by Qute) SQLUnit TSQLUnit (for testing T-SQL in MS SQL Server) Visual Studio Team Edition for Database Professionals includes testing capabilities XTUnit Empirix Mercury Interactive RadView Rational Suite Test Studio Web Performance Unit testing Tools which enable you to tools regression test your database.

Defective Installations and Configurations Database Security Issues Disaster Recovery Issues Creating a Test Server Distributed Data Issues Replication Issues Reliability and Capacity planning

DB Testing

Page 10

August 26, 2011

Test Data Generator

DATA BASE TESTING

Data Factory Datatect DTM Data Generator Turbo Data

Developers need test data against which to validate their systems. Test data generators can be particularly useful when you need large amounts of data, perhaps for stress and load testing.

References
http://msdn.microsoft.com/en-US/library/bb381703(v=VS.80).aspx

DB Testing

Page 11