Database Testing Checklist

Basic Database Testing Checklist Generally, Generally, database operations involve the following activities: First-time activities (eg, the setup process): 1. It should Connect to the database server ser ver.. 2. It should be able to Create new databases. 3. It should be able to Create tables, defaults, and rules; populate default data. 4. It should be able to Compile stored procedures and triggers. After the setup process has completed successfully, successfully, using the database consists of the following activities: ■■ Connect to database. ■■ Execute SQL statements, stored procedures, and triggers. ■■ Disconnect from the database. The common types of errors uncovered in database activities include: ■■ Failures in connecting to the database. Several potential problems that cause this type of  failure include the following: ■■ Invalid user name, password, or both. ■■ User has inadequate privileges required for certain data activities, such as creating tables and stored procedures. ■■ Invalid or wrong DSN (The data source name (DSN) used in Microsoft ODBC technology is a reference to the collection of information used by the ODBC manager to connect an application to a particular ODBC database. A DSN can be stored in a file or a file DSN. A DSN can also be stored in a User/System registry or a machine DSN). see examples in following Figures:

Figure 14.22 ODBC data source administrator.

Figure 14.23 Configuration summary.

Figure 14.24 Data source test confirmation.

Figure 14.25 Invalid ID or password error message.

■■

Failure to connect to the server that has the needed file DSN.

Several potential problems that can cause failures in creating databases, tables, defaults, rules, stored procedures, and triggers, as well as failures in populating default data, include: ■■ Failure to create files. ■■ Inadequate storage required for creating databases and tables. ■■ Resource contention keeps one or more stored procedures or tables from being created. Some of the common errors in the instructions (stored procedures, triggers, etc.) include: ■■ The database is configured to be case-sensitive, but the code is not. ■■ Using reserved keywords in the SQL statement. For example: SELECT user FROM mytable. Since user is the reserved keyword, this can cause a problem. ■■ NULL is passed to a record field that does not allow NULL. ■■ Mishandling single quote (‘) in a s tring field. See Figure 14.15 for an example.

Figure 14.15 An SQL syntax error. ■■ Mishandling comma (,) in an integer field. See Figure 14.18 for an example.

Figure 14.18 Mishandling a comma (,). ■■ Mishandling wrong data type. For example, if a field such as employee_salary in a record expects an integer, but receives $500 instead, it will complain because 500 is an integer but $500 is not. See Figure below for more examples:

Figure 14.19 Wrong data type.

■■ ■■

A value is too large for the size of the field. A string is too long for the size of the field. See Figure 14.17 for an example.

Figure 14.17 The string is too long.

Time-out: The time it takes the database to complete executing the procedure is longer than the time-out value set in the script (e.g., ASP script). ■■ Invalid or misspelled field or column, table, or view name. ■■ Undefined field, table, or view name. ■■ Invalid or misspelled stored procedure name. ■■ Calling the wrong stored procedure. ■■ Missing keyword. An example would be the code written a s follows: ... create view student_view select * from student_tbl ... instead of  ... create view student_view as select * from student_tbl ... Notice that as was omitted. ■■

Missing left parenthesis. For example: INSERT INTO staff id, city, state, salary, name) VALUES(13, ‘Phoenix’, ‘AZ’, 33000, ‘Bill’) ■■

Missing right parenthesis. For example: INSERT INTO staff (id, city, state, salary, name VALUES(13, ‘Phoenix’, ‘AZ’, 33000, ‘Bill’) ■■

Missing comma. For example: ... INSERT INTO staff (id, city, state, salary, name) VALUES(13, ‘Phoenix’, ‘AZ’, 33000 ‘Bill’) ■■

Missing keyword. Misspelled keyword. ■■ Missing opening or closing parenthesis before the keyword. ■■ Certain functions are disallowed, to be used with group by. For example, the following statement can cause error: ... group by count (last_name), first_name, age ... ■■ ■■

■■ ■■

Missing arguments for a function. Missing values. For example:

...  /* Create stored procedure that accepts parameters for inserting records */ CREATE PROCEDURE add_staff (@P1 INT, @P2 CHAR(20), @P3 CHAR(2) , @P4 INT, @P5 CHAR(20)) AS INSERT INTO staff  VALUES (@P1, @P2, @P3, @P4, @P5)  /* Inserting 3 records with created stored procedure */ add_staff 13, ‘Phoenix’, ‘AZ’, ‘Bill’  ... Insufficient privilege to grant permissions. ■■ Invisible invalid characters such as ESC. ■■ Errors in implementing COMMIT TRANSACTION and ROLLBACK TRANSACTION. The COMMIT TRANSACTION statement saves all work started since the beginning of the transaction. The ROLLBACK TRANSACTION statement cancels all the work done within the transaction. COMMIT and ROLLBACK errors cause partial data to be undesirably saved. ■■

Testing Triggers Triggers are executed when certain events such as INSERT, DELETE, and UPDATE are applied to table data. A trigger can call itself recursively or call other stored procedures. The testing objectives should include the following: ■■ Does the stored procedure or trigger meet the design objectives? ■■ For each conditional statement, does the handling of the condition execute properly? ■■ For each predefined input, does the procedure produce correctly expected outputs? ■■ Have all input cases identified in the equivalence class and boundary condition partitioning process been executed (either by walk-through, executing the stored procedure, or calling the stored procedure from other procedures)? ■■ For each possible error condition, does the procedure detect such condition? ■■ Is the handling of each detected error reasonable?

Testing Stored Procedures Every Stored Procedure is to be tested s eparately for its functionality (Based on se parate functions it performs)Stored Procedures need to be broken up into Action items based on Functions and then Each action item needs to be tested separately as the results of complete stored procedure ■■ Execution may differ from the results obtained by partial execution. This also helps in validating the modularity of code. ■■ In the case of stored procedures, to come up with test cases one can consider the following: ■■

     

 

No. of arguments passed Data Type of each of the arguments being passed Order of the arguments being passed Return value Data type of the return value Based on these we can write both positive & negative test cases, consider a simple eg of a stored procedure taking 2 numbers as input and returning the sum of the 2 numbers Security – Tables can only be accessible through Stored Procedures. Performance of SP (it should be fast).

Preparation for Database Testing To prepare for database testing, generate a list of database tables, stored procedures, triggers, defaults, rules, and so on. This will help to have a good handle on the scope of testing required for database testing. Figure 14.20 illustrates a list of stored procedures in a Microsoft SQL 7.0 database. 1. Generate data schemata for tables. Anal yzing the schema will help to determine: ■■ Can a certain field value be NULL? ■■ What are the allowed or disallowed values? ■■ What are the constraints? (look for any constraints defined in a database) ■■ Is the value dependent upon values in another table? ■■ Will the values of this field be in the lookup table? ■■ What are the user-defined data types? ■■ What are the primary and foreign key relationships among tables? ■■ Are there any Orphan objects? There should not be any Orphan objects. ■■ Is Indexing done for every table? There should exist an index fiel d in every table with sufficient length defined. ■■ There should not be redundancy in tables.(No duplicate of data) ■■ scalability – it should be able to store the data inserted ■■ performance – it should respond to the queries. Figure 14.21 shows a screen shot of a table design that lists all the column names, data types, lengths, and so on, of a Microsoft SQL 7.0 database table.

Figure 14.20 A list of stored procedures.

Figure 14.21 Table design view. 2. At a high level, analyze how the stored procedures, tr iggers, defaults, and rules work. This will help to determine: ■■ What is the primary function of each s tored procedure and trigger? Does it read data and produce outputs, write data, or both? Pay particular at tention to procedures that have keywords such as INSERT, DELETE, and UPDATE, because they might have effects on data integrity. ■■ What are the accepted parameters? ■■ What are the returned values? ■■ When is a stored procedure called, and by whom? ■■ When is a trigger fired? 3. Determine what the configuration management process is? That is how the new tables, stored procedures, triggers, and such are integrated in each build. In other words, Determine how stored procedures are added, removed, or updated? This will help to determine the effects on testing.