1. DataBase Testing

2. Objectives What is DB Testing ? Testing at the Data Access Layer Scope of DB Testing Need for Testing DB Objects Common Problems that affect the Application Testing Application Vs DB Testing contd..

3. Objectives Should Testers Know Databases Testing the Performance of the Database Data Integrity Understanding E/R Model Identifying defects in E/R Diagrams Case Studies on E/R Diagrams Writing Test Cases to Test Databases

4. Database Testing includes Testing for Data Integrity, Data Validity, Data manipulation. Database Objects can be tables, views, stored procedures, indexes etc Time taken for Retrieval of Records from the Database Time for Query Execution What is Database Testing

5. Client Layer – Is responsible for the presentation of data, receiving user events and controlling the user interface. Application Layer - Business-objects that implement the business rules "live" here, and are available to the client-tier Data Layer : This tier is responsible for data storage Layers in a Application

6. Single Tier Architecture –Client & Business Logic & Data Storage are all wrapped together 2 Tier Architecture –Business Logic and Data Storage are together and the Client is a separate layer 3 or the N tier Architecture –Client, the Business Logic and the Datastorage are kept separately Application Types

7. Client Layer Business Logic Layer Database Layer 3 or N Tier Architecture

8. Testing the Front End / GUI / Client Layer Testing the Business Logic Layer Testing the Database –Reviewing E/R Diagrams –Reviewing the Database Designs –Reviewing the Tables, views, stored procedures etc Testing Should Include

9. Data is stored in the tables Stored Procedures will handle the Insertion, deletion & Updation & Retrieval of Information from the Database No Testing/Improper testing will result in missing critical application functionality Why Test Database Objects

10. Traditionally all the data testing is done at the GUI Level Corruption of data can occur at any layer We must present verification of application correctness as data travels through the system. GUI Vs Database Testing

11. Data corruption –Occurs due to poor design Redundant data –Hidden duplicate records (same customer added twice with different primary keys). Inconsistent data –Data records added to the same database through multiple applications can add inconsistent data. Redundant validation –Validating business rules on the db, as well as the client, can cause conflicts if –they’re not well-coordinated Problems if Database Testing is Ignored

12. Inadequate knowledge of Relational db design fundamentals leads to logic errors and very common bugs in systems Basic normalization principles can and should be tested but isn’t -- because most testers have no idea what that is Effective DB testers should be able to uncover design problems quickly Why Should Test Professional know DBMS

13. Data Integrity Ensures the Consistency and correctness of Data stored in a Database Maintenance of data values according to data model and data type. For example, to maintain integrity, numeric columns will not accept alphabetic data. Data Integrity

14. It's the process of efficiently organizing data in a database. The database community has developed a series of guidelines for ensuring that databases are normalized. These are referred to as normal forms Normalisation

15. Goals of Normalisation There are two goals of the normalization process Eliminate redundant data Storing Related Data in a Table

16. First Normal Form Second Normal Form Third Normal Form Boyce Codd Normal Form Normalisation

17. In the First Normal Form  Every Cell should contain a single value.  Eliminate redundant data (for example, storing the same data in more than one table)  Create separate tables for each group of related data and identify each row with a unique column (the primary key). Normalisation

18. Emp CodeDeptProjCodeHours E101SystemsP1, P2, P3 12,14,16 E102FinanceP2,P314,16

19. In the Second Normal Form  Meet all the requirements of the first normal form.  And Every attribute in the row is functionally dependent upon the whole key and not part of the key Normalisation

20. Functional Dependany Given a table R, Attribute A is functionally dependant on attribute B if each value of A is associated precisely with one value of B Eg. In the Employee Table against every EmpCode there will only one Name so Name is functionally dependant on EmpCode

21. Normalisation ECodeProjCodeDeptHours E101P27Systems90 E305P27Finance10 E508P51Admin101 E101P51Systems101 E101P20Systems60

22. Normalisation The Above Table is in the First Normal Form. The Above table will lead to the following problems : Insertion – dept of a particular employee cannot be inserted untill the employee is assigned a project

23. Normalisation Updation :If an employee is transferred from one department to another the changes have to be made n number of times in the table Deletion : When the Project is over and the record deleted we will loose information about the department for that employee

24. Normalisation PK = Ecode + ProjCode The above table is in the First Normal Form we need to check if its in 2 nd Normal Form Hours is not functionally dependent on Ecode. Hours is not functionally dependent on ProjCode Hours is functionally dependent on Ecode+ProjCode

25. Normalisation Dept is functionally dependent on Ecode. Dept is not Functionally dependent on ProjCode Dept is functionally dependent on part of the key (Ecode+ProjCode) Therefore table is not in 2 N F Therefore Place Dept along with Ecode in a separate table

26. Normalisation EcodeDept E101Systems E305Sales E508Admin EMPLOYEEDEPT

27. Normalisation PROJECT EcodeProjCodeHours E101P2790 E101P51101 E101P2060 E305P2710

28. In the Third Normal Form  Meet all the requirements of the second normal form.  Remove columns that are not dependent upon the primary key.  In other words a relation is said to be in 3NF when every non key attribute is functionally dependent only on the Primary Key Normalisation

29. EcodeDeptDeptHead E101SystemsE901 E305FinanceE906 E402SalesE906 E508AdminE908 E607FinanceE909 E608FinanceE909

30.  The Primary Key is Ecode  Dept is functionally dependent on Ecode  DeptHead is functionally dependent on the primary Key Ecode.  All attributes are functionally dependent on the whole key Ecode Therefore Table is in 2NF  But DeptHead is functionally dependent on Dept. Normalisation

31.  The Primary Key is Ecode  Dept is functionally dependent on Ecode  DeptHead is functionally dependent on the primary Key Ecode.  All attributes are functionally dependent on the whole key Ecode Therefore Table is in 2NF  But DeptHead is functionally dependent on Dept. Normalisation

32. The table is not in the 3 NF because as per the third Normal Form every attribute should be functionally dependent only on the Primary Key. Identify and remove the attributes that are not functionally dependent on the primary key. Place them in a different table Normalisation

33. EcodeDept E101Systems E305Finance E402Sales E508Admin E607Finance Employee

34. Normalisation DeptDeptHead SystemsE901 SalesE906 AdminE908 FinanceE909 Department

35. Denormalization is the process of attempting to optimize the performance of a database by adding redundant data Denormalisation

36.  Validate the table naming conventions  Validate the column naming conventions  To check if the correct datatype is selected for a column  To check the consistency in datatypes for columns common across tables  To ensure the usage of correct field width What do we Test at the DB Level

37.  To ensure consistency in field width for columns common across tables  Existence of a primary key on a table  Existence of a foreign key on a table  Validity of check constraints  Validity of default constraints  Check for presence of indexes on a column What do we Test at the DB Level

38.  Check for Unique indexes  Existence of non-clustered indexes  Existence of clustered indexes  Note the time of execution of queries  Note the time of compilation of queries What do we Test at the DB Level

39.  Evaluate the query execution plan  Note the time of execution of stored procedures  Note the time of compilation of stored procedures  Evaluate the query execution plan  Denormalize the tables  Normalize the tables What do we Test at the DB Level

40. Write Review Cases for the following Table Structures (Check for Table Naming Conventions, DataType, Field Size, Keys,Constraints) Case Study

41. Data Factory : Quest Software Data generator tool and data manager for database testing SQL TunerSQL Tuner : Embaradero Eases the complexity of writing high- performance SQL code by providing built-in help for writing syntactically correct SQL, and by assisting in every aspect of complex tuning efforts. Database Test Tools

42. Datatect Datatect : Banner Software Generate a variety of realistic test data to RDBMS including Oracle, Sybase, SQL Server, and Informix DB Stress : DTM Utility for stress testing the server parts of information systems and applications, as well as DBMSs and servers themselves. Database Test Tools

43. Datatect Datatect : Banner Software Generate a variety of realistic test data to RDBMS including Oracle, Sybase, SQL Server, and Informix DB Stress : DTM Utility for stress testing the server parts of information systems and applications, as well as DBMSs and servers themselves. Database Test Tools

44. –Database Opensource Test Suite –The Database Opensource Test Suite (DOTS) is a set of test cases designed for the purpose of stress-testing database server systems in order to measure database server performance and reliability. Database Test Tools

45. –DBMonster –DBMonster is an application to generate random data for testing SQL database driven applications under heavy load. Database Test Tools