8/6/2019 DB Testing Basics

1/22

PART1- FOR INTERNAL TRAINING

-Anna

8/6/2019 DB Testing Basics

2/22

` Given a application, what activities are termed as DB testing?

` What are the different application types in the context of DB

Testing?` What is the impact if we do/ not do a DB Testing?

` What testing type this DB testing falls under?

8/6/2019 DB Testing Basics

3/22

Based on the responsesBased on the responses -->>Sucessisive slides can be aSucessisive slides can be a

training, insight or a refreshertraining, insight or a refresher

8/6/2019 DB Testing Basics

4/22

UI application that has DB for its storage

- Complexity of storage? [simple tables?]

UI application that has no dedicated DB

UI application that has DB and also some other filestorage systems

- In case of interaction b/w DB & external systems are alone

considered

UI application that has DB but the source is an externalsystem

NO UI but only has DB

8/6/2019 DB Testing Basics

5/22

Application Types:` UI application that has no dedicated DB

` UI application that has DB for its storage

Unknowingly DB testing are executed from functional

test cases.. How?` Check if the application form is submitted successfully - Here DB insert operation

are checked

` Check if the modified form is submitted successfully Here DB update operation is

checked

` Check if the form is deleted successfully Here DB delete operation is checkedSO can this be concluded as DB TESTING?

Part 1

8/6/2019 DB Testing Basics

6/22

Actions claimed:Use of SQL/ORACLE queries & cross verify with UI output

Use of SQL/ ORACLE queries & confirm the inputs for testing [ex: to know if there

are already defined workflow for a specific functionality]

Use SQL/ ORACLE queries & confirm

SO can this be concluded as DB TESTING?

Part 2

8/6/2019 DB Testing Basics

7/22

Part 1

` What happens if the insertion is on

two tables and that has unique field

as a foreign key to other table?

But in UI, referenced field is set as

optional or like data pulled from

other module?

The functional test cases are

randomly covered for inputs to

submit a request?

Part 2` The use of SQL/ ORACLE queries

is just an assistance for functional

testing as long as we have

provision for output in UI screen But in case if the defect is not

proved? Like request approval not

seen in Dashboard?

For application not having UI

In this context what is missing?

OVERALL LEADS TO ISSUE IN TEST COVERAGE & inefficient debugging

capabilities

8/6/2019 DB Testing Basics

8/22

Use of DB model to analyze the different DB

schema's to arrive at structural cases for functional

mapping in application functionalities, test data usingboundary conditions, performance & security

scenarios and also to use DB as a mock up UI in the

context of providing inputs or verifying outputs/sub

outputs, incase of restrictions in application UI

non-availability*[Data warehouse, ETL concepts]

8/6/2019 DB Testing Basics

9/22

STRUCTURAL BACK END TESTING

DB schema Testing

Stored Procedures Test

Trigger Test

Integration tests like conflict between Requirements & schema, schema & triggers etc.,

Server Set up scripts

FUNCTIONAL BACK END TESTING

Test Functions & features by dividing back end on functions basis

Check data integrity and consistency

Login & User security

Stress Testing

8/6/2019 DB Testing Basics

10/22

Structure described in a formal language and refers

to the organization of data to create a blueprint of

how a database will be constructed (divided into

database tables).

The states of a created conceptual schema are

transformed into an explicit mapping, the databaseschema. This describes how real world entities are

modelled in the database

In a relational database, the schema defines the

tables, fields, relationships, views, indexes,

packages, procedures, functions, queues, triggers,

types, sequences, materialized views, synonyms,

database links, directories, Java, XML schemas, andother elements.

8/6/2019 DB Testing Basics

11/22

View consists of a stored query accessible as a virtual table composed of the result set of a

query.

View does not form part of the physical schema:

Dynamic, virtual table computed or collated from data in the database. Changing the data in

a table alters the data shown in subsequent invocations of the view

Ex: Sum, Average

8/6/2019 DB Testing Basics

12/22

Stored procedure is executable code that is associated with, and generally stored in, the

database.

Stored procedures usually collect and customize common operations, like inserting a details

of records into a relation, gathering statistical information about usage patterns, or

encapsulating complex business logic and calculations.

Frequently they are used as an application programming interface (API) for security or

simplicity

Ex: update of details of recurring records for same logic

8/6/2019 DB Testing Basics

13/22

A database index is a data structure that improves the speed of data retrieval operations on

a database table at the cost of slower writes and increased storage space.

Indexes can be created using one or more columns of a database table, providing the basis

for both rapid random lookups and efficient access of ordered records.

Types Non-clustered/ Clustered Index

8/6/2019 DB Testing Basics

14/22

Database trigger is procedural code that is automatically executed in response to certain

events on a particular table or view in a database.

The trigger is mostly used for keeping the integrity of the information on the database

Ex:prevent changes (e.g. prevent an invoice from being changed after it's been mailed out)

log changes (e.g. keep a copy of the old data)audit changes (e.g. keep a log of the users and roles involved in changes)

8/6/2019 DB Testing Basics

15/22

PART 1

DERIVE STRUCTURAL TEST CASES FROM APPLICATIONDERIVE STRUCTURAL TEST CASES FROM APPLICATIONDATABASEDATABASE

8/6/2019 DB Testing Basics

16/22

` Pre-system engagements in terms of Schema review

` Post system engagements by increasing test coverage

from schema items

` Use of queries to prove or debug a defect

Only Sample demonstration is focussed

8/6/2019 DB Testing Basics

17/22

For Submit Master

table For Save

Staging table

8/6/2019 DB Testing Basics

18/22

SaveSubmit

8/6/2019 DB Testing Basics

19/22

8/6/2019 DB Testing Basics

20/22

Derive boundary conditions

8/6/2019 DB Testing Basics

21/22

create or replace

TRIGGER UPDATE_USER_BY_CONTACT_TRG

AFTER UPDATE

ON ADM_CONTACT_MST

FOR EACH ROW

BEGIN

IF :NEW.FIRST_NAME :OLD.FIRST_NAME OR :NEW.MIDDLE_NAME :OLD.MIDDLE_NAME

OR :NEW.LAST_NAME :OLD.LAST_NAME OR :NEW.EMAIL_ID :OLD.EMAIL_ID OR :NEW.PHONE1 :OLD.PHONE1

THEN

UPDATE ENT_USER_MST SET FIRST_NAME = :NEW.FIRST_NAME, MIDDLE_NAME = :NEW.MIDDLE_NAME,

LAST_NAME = :NEW.LAST_NAME, EMAIL_ID = :NEW.EMAIL_ID, PHONE_NO = :NEW.PHONE1

WHERE CONTACT_ID = :OLD.CONTACT_ID;

END IF;

END;

This Trigger here will be Triggered , when ever the contact is modified.

So that the modified changes in the Contacts Master table will be reflected in the User master

table. Providing data integrity between the two modules both in the front end and as well in

the back end.

8/6/2019 DB Testing Basics

22/22

` Guidelines to perform each of the DB testing methods

` Simple queries overview with examples

` Data warehouse & ETL concepts with basic test

scenarios understanding