Scribd
Upload
105 views

DB Testing Basics

1. Database testing involves validating the structure, functions, and integrity of the database through activities like schema testing, stored procedure testing, trigger testing, and integration testing between requirements and schemas. 2. Functional database testing can be done by dividing the backend testing based on functions and checking data integrity, consistency, security, and performance. 3. Sample queries and a database trigger example are provided to demonstrate how database testing activities like schema validation, stored procedure testing, and data integrity checks can be performed.

Uploaded by

annamariale83
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
105 views

DB Testing Basics

1. Database testing involves validating the structure, functions, and integrity of the database through activities like schema testing, stored procedure testing, trigger testing, and integration testing between requirements and schemas. 2. Functional database testing can be done by dividing the backend testing based on functions and checking data integrity, consistency, security, and performance. 3. Sample queries and a database trigger example are provided to demonstrate how database testing activities like schema validation, stored procedure testing, and data integrity checks can be performed.

Uploaded by

annamariale83
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 22

PART1- FOR INTERNAL TRAINING

-Anna
 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?
 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 file

storage systems
- In case of interaction b/w DB & external systems are alone
considered
 UI application that has DB but the source is an external
system
 NO UI but only has DB
Application Types: Part 1
 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 checked

SO can this be concluded as DB TESTING?


Part 2
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 1 Part 2
 What happens if the insertion is on  The use of SQL/ ORACLE queries
two tables and that has unique field is just an assistance for functional
as a foreign key to other table? testing as long as we have
 But in UI, referenced field is set as provision for output in UI screen
optional or like data pulled from  But in case if the defect is not
other module? proved? Like request approval not
 The functional test cases are seen in Dashboard?
randomly covered for inputs to  For application not having UI
submit a request?

In this context what is missing?

OVERALL LEADS TO ISSUE IN TEST COVERAGE & inefficient debugging


capabilities
Use of DB model to analyze the different DB schema's to arrive at structural cases
for functional mapping in application functionalities, test data using boundary
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]
 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
 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 database
schema. 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, and
other elements.
• 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
• 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


• 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
• 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)
PART 1
 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


For Submit “Master”
table For Save
“Staging” table
Submit Save
Derive boundary conditions
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.
 Guidelines to perform each of the DB testing methods
 Simple queries – overview with examples
 Data warehouse & ETL concepts with basic test

scenarios understanding

You might also like