Testing Database Changes

Company

LOGO

Testing Database ChangesMD SAZED MONSUR

AGENDA

1. Introduction

3. STRUCTURAL BACK END TESTS

4. FUNCTIONAL BACK END TESTS

5. Batch Jobs

6. OTHER TEST ISSUES

2. Methodology

WHY BACK END TEST IS SO IMPORTANT

IF THE BACK END MALFUNCTIONS, IT MAY CAUSE • SYSTEM DEADLOCK• DATA CORRUPTION• DATA LOSS• BAD PERFORMANCE

FULL CONTROL OF TEST COVERAGE AND DEPTH. WHEN BACK END BUGS ARE FIXED, THE SYSTEM QUALITY IS

DRAMATICALLY INCREASED.

WHAT WE TEST IN DATABASE

DATABASE TESTING, BASICALLY, INCLUDES THE FOLLOWING:

• DATA ACCURACY & VALIDITY (FIELD SIZE VALIDATION)• DATA INTEGRITY (CHECK CONSTRAINTS, INSERT, DELETE, UPDATE)• DATABASE OBJECTS (STORED PROCEDURES, VIEWS, TABLES)• DATA MIGRATION (IMPORT, EXPORT)• DATA TRANSACTION CONSISTENCY AND CONCURRENCY (STATES &

LOCKS) • PERFORMANCE RELATED TO DATABASE (INDICES, NUMBER OF

TRIGGERS AND PROCEDURES)• SECURITY RELATED TO DATABASE - DATA ACCESSING

( UNAUTHORIZED ACCESS)

StoredProc

TablesViews

TriggerUserDefinedDataType

DATABASE TESTING

WHAT TO TEST IN

Methodology

Structural Functional Boundary

Broken down into a finite number of testable pieces based on aback end’s structure.

Stress

Broken down into a finite number of testable pieces based on aback application’s functionality

e.g. in a column for percentages,the value cannot be less than zero and cannot be greater than 100%.

e.g. many users heavilyaccess the same table that has a large number of records.

STRUCTURAL BACK END TESTS

Database Schema

• DATABASES AND DEVICES• TABLES, COLUMNS, COLUMN TYPES,

DEFAULTS, AND RULES• KEYS AND INDEXES

Stored Procedure• INDIVIDUAL PROCEDURE TESTS• INTEGRATION TESTS OF PROCEDURES

Triggers• UPDATE TRIGGERS, INSERT TRIGGERS,

DELETE TRIGGERS

View• INDIVIDUAL VIEWS• INTEGRATION OF TABLES• ENCRYPTED VIEWS.

User Defined data

FUNCTIONAL BACK END TESTS

DIVIDING BACK END INTO FUNCTIONALITIES

CHECKING DATA INTEGRITY AND CONSISTENCY

LOGIN AND USER SECURITY

STRESS TESTING

TEST BACK END VIA FRONT END

DATABASE SCHEMA TESTING

Databases and devices

• DATABASE NAMES• DATA DEVICE, LOG DEVICE AND DUMP DEVICE• ENOUGH SPACE ALLOCATED FOR EACH DATABASE• DATABASE OPTION SETTING (I.E. TRUNC. OPTION)


Tables, columns, column types, defaults, and rules

• ALL TABLE NAMES• COLUMN NAMES FOR EACH TABLE• COLUMN TYPES FOR EACH TABLE (INT, TINYINT, VARCHAR, CHAR, TEXT,

DATETIME. SPECIALLYTHE 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• WHETHER A RULE IS BOUND TO CORRECT TABLE COLUMNS• WHETHER ACCESS PRIVILEGES ARE GRANTED TO CORRECT GROUPS


Keys and indexes

• PRIMARY KEY FOR EACH TABLE• FOREIGN KEYS• COLUMN DATA TYPES BETWEEN A FOREIGN KEY COLUMN AND A COLUMN IN

OTHER TABLE• INDICES, CLUSTERED OR NONCLUSTERED; UNIQUE OR NOT UNIQUE

STORED PROCEDURE TESTS

Individual procedure tests

• STORED PROCEDURE NAME• PARAMETER NAMES, PARAMETER TYPES AND THE NUMBER OF

PARAMETERS• THE DATA TYPE OF EACH OF THE ARGUMENTS BEING PASSED• THE ORDER OF THE ARGUMENTS BEING PASSED

Outputs:

• THE DATA TYPE OF THE RETURN VALUE• 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

Tips

• ONE CHALLENGE IS THAT SOME STORED PROC VERY LONG WITH COMPLEX BUSINESS LOGIC. IT IS RECOMMEND BREAKING THEM INTO SUBROUTINES AND MAKING THEM AS SMALL AS POSSIBLE. IT MAKES IT EASIER TO TEST, AND EASIER TO MAINTAIN.

• MAKE THE SUBROUTINE’S WRITE OPERATION TO READ OPERATION TO OBSERVE THE CHANGES THAT ARE GOING TO EFFECT FINALLY.

• YOU CAN WRITE TEST CASES TO TEST STORED PROCEDURE BUT DON’T WRITE 50 LINE TEST SCRIPT FOR A 10 LINE PIECE OF CODE.


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


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

TRIGGER TESTS

Updating triggers

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

TRIGGER TESTS

Inserting triggers

• 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’T)

TRIGGER TESTS

Deleting triggers

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

View

• A VIEW IS A "VIRTUAL TABLE". IT IS NOT LIKE A SIMPLE TABLE, BUT IS A VIRTUAL TABLE WHICH CONTAINS COLUMNS AND DATA FROM DIFFERENT TABLES.

• IT SHOWS ONLY THOSE DATA WHICH ARE ALREADY MENTIONED IN THE QUERY DURING THE CREATION OF THE VIEW.

View

Use of a View

• VIEWS ARE USED AS SECURITY MECHANISMS IN DATABASES.• BECAUSE IT RESTRICTS THE USER FROM VIEWING CERTAIN COLUMN AND

ROWS.• VIEWS DISPLAY ONLY THOSE DATA WHICH ARE MENTIONED IN THE QUERY,

SO IT SHOWS ONLY DATA WHICH IS RETURNED BY THE QUERY THAT IS DEFINED AT THE TIME OF CREATION OF THE VIEW.

• THE REST OF THE DATA IS TOTALLY ABSTRACT FROM THE END USER.• ALONG WITH SECURITY, ANOTHER ADVANTAGE OF VIEWS IS DATA

ABSTRACTION BECAUSE THE END USER IS NOT AWARE OF ALL THE DATA IN A TABLE.

Different types of Views

• THERE ARE TWO DIFFERENT TYPES OF VIEWS:• SYSTEM VIEWS

• INFORMATION SCHEMA VIEW• CATALOG VIEW• DYNAMIC MANAGEMENT VIEW (DMV)

• USER DEFINED VIEWS• SIMPLE VIEW• COMPLEX VIEW

Demo View

Testing View

• A VIEW CAN BE CREATED ONLY IN THE CURRENT DATABASE.• THE CREATE VIEW MUST BE THE FIRST STATEMENT IN A QUERY BATCH.• A VIEW CAN HAVE A MAXIMUM OF 1,024 COLUMNS.• KEYS AND INDEXES• ALL THE DATABASE OBJECTS REFERENCED ANYWHERE IN THE

STATEMENT EXIST AND THAT THEY ARE VALID IN THE CONTEXT OF THE STATEMENT

• DATA MODIFICATION STATEMENTS DO NOT VIOLATE ANY DATA INTEGRITY RULES.

• A CHECK THAT FAILS RETURNS AN ERROR MESSAGE. • IF THE NEW TABLE OR VIEW STRUCTURE CHANGES, THE VIEW MUST BE

DROPPED AND RE-CREATED.• CHECK IF THE VIEW IS ENCRYPTED.

ENCRYPTING VIEWS

THE “WITH ENCRYPTION” OPTION ENCRYPTS THE VIEWS BY WHICH IT WILL NOT BE VISIBLE VIA SP_HELPTEXT SO IN CASE OF STRICT REQUIREMENTS WHERE THE CONTENTS OF THE VIEW DON’T NEED TO BE EXPOSED THIS OPTION FREEZES THE VIEW.

ALTER VIEW Bill_V WITH ENCRYPTION AS SELECT C.FName ,C.LNme,P.ProductDesc,B.DateOfBooking ,P.Price ,B.QTY,(B.QTY*P.Price) AS TotalAmountPayable FROM dbo.BOOKING B INNER JOIN dbo.PRODUCTS P ON B.ProductID=P.ProductID INNER JOIN dbo.Customer C ON B.CustID=C.CustID;

User Defined

FUNCTIONAL BACK END TESTS

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

DATA INTEGRITY AND CONSISTENCY

• 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

BATCH JOBS

BY BATCH JOB, WE MEAN BATCH JOBS FOR WINDOWS NT, DOS OR OS/2. LIST OF TEST CASES FILE TRANSFER BATCH JOB:

• DESTINATION PATH AND SOURCE PATH• ALL VARIABLES IN A BATCH JOB MUST BE RESOLVED• (I.E. IF %LOG% IS USED, THE “LOG” MUST BE DEFINED SOMEWHERE

EITHER IN THE SAME FILE• OR IN OTHER SYSTEM SETUP UTILITY.)• MAKE SURE SOURCE FILES AND THEIR NAMES ARE CORRECT AS

SPECIFIED.• MAKE SURE DESTINATION FILES AND THEIR NAMES ARE CORRECT AS

SPECIFIED.• VERIFY IF ANY ERROR LEVEL IS CHECKED AFTER EACH FILE COPY.• ERROR MESSAGES MUST BE LOGGED. FATAL ERRORS MUST BE SENT TO

OPERATORS OR• TESTERS. VERIFY THE DATABASE HAS THE BULK COPY OPTION SET TO

TRUE BEFORE A BATCH JOB IS• EXECUTED• GET ESTIMATE OF TOTAL BATCH EXECUTION TIME. MAKE SURE IT FITS

THE TIME WINDOW• (SPECIALLY THE WORST CASE)

OTHER TEST ISSUES

TIPS:• NO PROGRAM IS BUG FREE. • THE BREAK-PROGRAM ATTITUDE IS HIGHLY RECOMMENDED.• ALWAYS ASK YOURSELVES IF ANY TEST CASE IS MISSING AND IF OUR

TEST SPECIFICATIONS ARE COMPLETE.• WHEN YOU DESIGN TEST SPECIFICATION, THINK ABOUT VALID CASES,

INVALID CASES AND BOUNDARY CASES• EFFECTIVE TEST METHODOLOGY IS NEITHER UNIQUE NOR UNIVERSAL.

FEEL FREE TO DISCUSS THE TEST PLAN, TEST SPECIFICATIONS AND TEST DATA WITH OTHER TESTERS.

• WHEN TESTING, YOU SHOULD PRETEND TO BE DIFFERENT LEVELS OF USERS. AS “POWER” USERS, YOU CAN TEST ADVANCED FEATURES HEAVILY. AS NOVICES, YOU CAN DO “STUPID” THINGS, I.E. TURN OFF THE MACHINE IN THE MIDDLE OF A TRANSACTION.

• IF YOU SUSPECT ANY RESULT OR MESSAGE, GO AHEAD AND TRACK IT DOWN. YOU MAY HAVE FOUND A “BIG” BUG.

• IF A TEST IS LIKELY TO BE REPEATED LATER, AUTOMATE IT.

Useful queries

• CHECK FOR DATA DEVICES AND LOG DEVICES:• SP_HELPDB <DATABASE_NAME> E.G. sp_helpdb SBPRO

• CHECK FOR SPACE USED:• sp_spaceused customer_featured_item

Useful queries

• GET INFORMATION ABOUT AN OBJECT IN A DATABASE:• SP_HELP customer_basket_threshold

Useful queries

• FIND OUT EXISTENCE OF SQL OBJECTS BY TYPE:

<TYPE> CAN BE• U ------- USER TABLE• V ------- VIEW• P ------- STORED PROCEDURE• TR ------ TRIGGER• E.g. select * from sysobjects where type = ‘V’

Documents

Testing Database Changes