Scribd
Upload
11 views

Database testing project

The document outlines a group project focused on database testing, detailing the phases of structural testing for schema integrity, ACID properties testing, and data generation and mapping. It emphasizes the importance of ensuring data integrity, schema validation, and performance optimization while providing examples of common schema issues and test cases. Additionally, it discusses relationships between tables and the generation of test data to validate referential integrity and prevent orphaned records.

Uploaded by

andrewlite.sr
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
11 views

Database testing project

The document outlines a group project focused on database testing, detailing the phases of structural testing for schema integrity, ACID properties testing, and data generation and mapping. It emphasizes the importance of ensuring data integrity, schema validation, and performance optimization while providing examples of common schema issues and test cases. Additionally, it discusses relationships between tables and the generation of test data to validate referential integrity and prevent orphaned records.

Uploaded by

andrewlite.sr
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 19

DATABASE TESTING

GROUP PROJECT
GROUP D
Andrew Lite Suresh Rajan (C0917416)
Deepa Sree Kothandan Rajan (C0907986)
Praharsha Manda (C0917433)

Phase 1: Structural Database Testing for Schema Integrity:


1. Assess the Principles and Goals of Structural Database Testing:
Structural database testing is a critical process in database management that
focuses on verifying the integrity and correctness of the database schema.
This type of testing ensures that the database structure adheres to the
defined requirements and can handle data accurately and efficiently.

Importance of Structural Database Testing:


1. Data Integrity and Consistency:
 Ensures that data stored in the database is accurate and reliable.
 Prevents data corruption by validating data types, constraints, and
relationships.
2. Schema Validation:
 Confirms that the database schema is designed correctly according
to the specifications.
 Detects and prevents common schema issues such as incorrect
data types, missing constraints, and broken relationships.
3. Performance Optimization:
 Identifies and resolves performance bottlenecks related to database
structure.
 Ensures that indexes and other performance-related components
are correctly implemented.
4. Compliance and Standards:
 Ensures that the database schema complies with industry
standards and best practices.
 Helps in maintaining regulatory compliance by enforcing data
integrity rules.
5. Error Prevention:
 Detects potential issues early in the development process, reducing
the risk of errors in production.
 Prevents common problems such as orphaned records, duplicate
entries, and invalid data.
By conducting thorough structural database testing, organizations can ensure
that their databases are robust, reliable, and capable of supporting their
applications effectively. This testing is essential for maintaining the overall
health and performance of the database system.
Goals of Structural Database Testing:
 Ensure data integrity and consistency.
 Validate schema design against requirements.

Prevent common schema issues such as:


 Data Type Mismatches: Incorrect data types can lead to data
corruption.
 Missing Constraints: Lack of constraints can result in invalid data
entries.
 Referential Integrity Issues: Broken relationships between
tables.
Examples of Common Schema Issues:
 A column intended to store dates is defined as a string, leading to
invalid date entries.
 A foreign key constraint is missing, allowing orphaned records.

Investigating techniques for Testing Database Schema Integrity:


Creating new users Table:

Creating new orders table:


Validate Datatypes:

Validate NOT NULL Constraints:


Below columns listed has the NOT NULL constraints
Created a Trigger where you can’t enter age < 18:

Created a stored procedure:

Test Cases for Columns:


1. Test Case: Validate Data Type and NOT NULL Constraint
 Scenario: Insert a user with a valid age and email.
 Expected Result: The record is inserted successfully.

2. Test Case: Validate Unique Constraint


 Scenario: Insert a user with a duplicate email.
 Expected Result: The insertion fails due to the unique constraint on the
email column.

Test case for Triggers:


1. Test Case: Age Constraint Trigger
 Scenario: Insert a user under the age of 18.
 Expected Result: The insertion fails with an error message.
Phase 2: ACID Properties Testing for Databases:
Atomicity: Ensures that a transaction is either fully completed or fully rolled
back.
Example: Transferring $100 from Account A to Account B; if any part of the
transaction fails, the system will roll back to its initial state.

Consistency: Guarantees that a transaction leaves the database in a valid


state, maintaining all defined rules.
Example: Enforcing constraints like primary keys or foreign keys during
transactions ensures consistent data states.

Isolation: Ensures that concurrent transactions do not interfere with each


other.
Example: A user updating a record will not impact another user reading the
same record simultaneously.

Durability: Once a transaction is committed, it is permanently recorded,


even in the event of a system crash.
Example: After committing a record insertion, the data remains safe despite
a server shutdown.

Trying to create mockup data:


Creating users table:
Now, converting the mockup data into insert statements and running:
Performing few transactions:
Scenario: Transfer a user’s IP address to another user. The transaction
should either complete entirely or not at all.

Validated that transaction has been completed:


Demonstrate Ways to Prevent ACID Violations:

Atomicity Violation:
Improper code and transaction failed:

Without proper rollback, the database state is inconsistent

Revised code:
Adding an EXCEPTION block ensures the transaction is rolled back in case of
an error, maintaining consistency and statement processed:
Test Cases for Transactions and Data Consistency checks:
Test Case 1: Basic Transaction Rollback
Objective: Validate that a rollback undoes partial changes.
Steps:
Start a transaction (BEGIN or SET TRANSACTION).
Insert a record into the table.
Roll back the transaction.
Verify that the record was not inserted by querying the table.
Phase 3: Data Generation and Data Mapping for Database Testing

One-to-one relationship:
A one-to-one relationship exists when each row in Table A is linked to only
one row in Table B, and vice versa.

A customer can have only one detailed profile (address and phone number).

Customers Table:
CustomerDetails table

One-to-many relationship:
A one-to-many relationship exists when a single row in Table A can be
associated with multiple rows in Table B, but each row in Table B is
associated with only one row in Table A.
A customer can place multiple orders, but each order belongs to only one
customer.

Customers table:

Orders table:
Alice placed 2 orders but, Bob placed 1 order in orders table

Many-to-many relationships:
A many-to-many relationship exists when multiple rows in Table A can be
associated with multiple rows in Table B, and vice versa. This relationship is
typically implemented using a junction table.

An order can contain multiple products, and a product can appear in multiple
orders.

Orders Table:

Products Table:
OrderDetails table:

The many-to-many relationship between Orders and Products is accomplished


using the OrderDetails table as a junction table. This table links each order
with multiple products and stores the quantity of each product in the order.
As a result, a single product can appear in multiple orders, and a single order
can contain multiple products, thus establishing a many-to-many relationship.

Generated test data using test scripts for the following table:

Customers table:
Orders table:

Products table:
Checking for orphaned records (no valid customer or product):

No orphaned records found

Check if there are any orders with no corresponding product:


Check for Referential Integrity:
Ensure all CustomerID values in the Orders table are valid:

Ensure all ProductID values in the Orders table are valid:

You might also like