Testing the Oracle Database

During the testing phase, you test the application and Oracle database to make sure that the:

Migrated data is complete and accurate
Applications function in the same way as the source database
Oracle database producing the same results as the source database
Applications and Oracle database meet the operational and performance requirements

You may already have a collection of unit tests and system tests from the original application that you can use to test the Oracle database. You should run these tests in the same way that you ran tests against the source database. However, regardless of added features, you should ensure that the application connects to the Oracle database and that the SQL statements it issues produces the correct results.

Note:

The tests that you run against the application vary depending on the scope of the application. Oracle recommends that you thoroughly test each SQL statement that is changed in the application. You should also test the system to make sure that the application functions the same way as in the third-party database.

Testing Methodology

Many constraints shape the style and amount of testing that you perform on a database. Testing can contain one or all of the following:

Simple data validation
Full life cycle of testing addressing individual unit tests
System and acceptance testing

You should follow a strategy for testing that suits your organization and circumstances. Your strategy should define the process by which you test the migrated application and Oracle database. A typical test method is the V-model, which is a staged approach where each feature of the database creation is mirrored with a testing phase.

Figure: V-model with a Database Migration shows an example of the V-model with a database migration scenario:

V-model with a Database Migration

Description of "V-model with a Database Migration"

There are several types of tests that you use during the migration process. During the testing stage, you go through several cycles of testing to enhance the quality of the database. The test cases you use should make sure that any issues encountered in a previous version of the Oracle database are not introduced again.

For example, if you have to make changes to the migrated schema based on test results, you may need to create a new version of the Oracle database schema. In practice, you use SQL Developer to create a base-line Oracle schema at the start of testing, and then edit this schema as you progress with testing.

Note:

Oracle recommends that you track issues that you find during a testing cycle in an issue tracking system. Track these issues against the version of the database or application that you are testing.

Testing the Oracle Database

Use the test cases to verify that the Oracle database provides the same business logic results as the source database.

Note:

Oracle recommends that you define completion criteria so that you can determine the success of the migration.

This procedure explains one way of testing the migrated database. Other methods are available and may be more appropriate to your business requirements.

To test the Oracle database:

Create a controlled version of the migrated database.

Oracle recommends that you keep the database migration scripts in a source control system.
Design a set of test cases that you can use to test the Oracle database from unit to system level. The test cases should:
1. Ensure the following:
  - All the users in the source database have migrated successfully
  - Privileges and grants for users are correct
  - Tables have the correct structure, defaults are functioning correctly, and errors did not occur during mapping or generation
2. Validate that the data migrated successfully by doing the following:
  - Comparing the number of rows in the Oracle database with those in the source database
  - Calculating the sum of numerical columns in the Oracle database and compare with those in the source database
3. Ensure that the following applies to constraints:
  - You cannot enter duplicate primary keys
  - Foreign keys prevent you from entering inconsistent data
  - Check constraints prevent you from entering invalid data
4. Check that indexes and sequences are created successfully.
5. Ensure that views migrated successfully by doing the following:
  - Comparing the number of rows in the Oracle database with those in the source database
  - Calculating the sum of numerical columns in the Oracle database and compare with those in the source database
6. Ensure that triggers, procedures, and functions are migrated successfully. Check that the correct values are returned for triggers and functions.
Run the test cases against the migrated database.
Create a report that evaluates the test case results.

These reports allow you to evaluate the data to qualify the errors, file problem reports, and provide a customer with a controlled version of the database.
If the tests pass, go to step 7.

If all tests in the test cases pass or contain acceptable errors, the test passes. If acceptable errors occur, document them in an error report that you can use for audit purposes.
If the test cases fail:
1. Identify the cause of the error.
2. Identify the test cases needed to check the errors.
3. Log an issue on the controlled version of the migrated database code in the problem report.
4. Add the test case and a description of the problem to the incident tracking system of your organization, which could be a spreadsheet or bug reporting system. Aside from the test case, the incident log should include the following:
  - Provide a clear, concise description of the incident encountered
  - Provide a complete description of the environment, such as platform and source control version
  - Attach the output of the test, if useful
  - Indicate the frequency and predictability of the incident
  - Provide a sequence of events leading to the incident
  - Describe the effect on the current test, diagnostic steps taken, and results noted
  - Describe the persistent after effect, if any
5. Attempt to fix the errors.
6. Return to step 1.
Identify acceptance tests that you can use to make sure the Oracle database is an acceptable quality level.

Guidelines for Creating Tests

You may already have a collection of unit tests and system tests from the original application that you can use to test the Oracle database. However, if you do not have any unit or system tests, you need to create them. When creating test cases, use the following guidelines:

Plan, specify, and execute the test cases, recording the results of the tests.

The amount of testing you perform is proportional to the time and resources that are available for the migration project. Typically, the testing phase in a migration project can take anywhere from 40% to 60% of the effort for the entire project.
Identify the components that you are testing, the approach to the test design and the test completion criteria.
Define each test case so that it is reproducible.

A test that is not reproducible is not acceptable for issue tracking or for an audit process.
Divide the source database into functions and procedures and create a test case for each function or procedure. In the test case, state what you are going to test, define the testing criteria, and describe the expected results.
Record the expected result of each test case.
Verify that the actual results meet the expected results for each test.
Define test cases that produce negative results as well as those that you expect a positive result.

Example of a Unit Test Case

The following displays a sample unit test plan for Windows:

Name Jane Harrison

Module Table Test Emp

Date test completed 23 May 2007

Coverage log file location mwb\database\TableTestEmp

Description This unit test tests that the emp table was migrated successfully.

Reviewed by John Smith

Task ID Task Description Expected Result Verified (Yes/No)

Task ID	Task Description	Expected Result	Verified (Yes/No)
1	Run the following on the source database for each table: `select count() from emp` Run the following on the destination database for each table: `select count() from emp`	On the source database, the count() produces a number. In this case, the number is the number of rows in each table. On the destination database, the count() number corresponds to the number of rows in the new Oracle table.	Yes The number of rows in each table is the same in the source and destination databases.
2	Run the following on the source database for each table: `select sum(salary) from emp` Run the following on the destination database for each table: `select sum(salary) from emp`	On the source database, sum(salary) produces a check sum for the sum of the data in each table. On the destination database, sum(salary) corresponds to the sum of the salary in the emp table.	Yes The sum for each table is the same in the source and destination databases.

Run the following on the source database for each table:

select count(*) from emp

Run the following on the destination database for each table:

select count(*) from emp

On the source database, the count(*) produces a number. In this case, the number is the number of rows in each table.

On the destination database, the count(*) number corresponds to the number of rows in the new Oracle table.

Yes

The number of rows in each table is the same in the source and destination databases.

Run the following on the source database for each table:

select sum(salary) from emp

Run the following on the destination database for each table:

select sum(salary) from emp

On the source database, sum(salary) produces a check sum for the sum of the data in each table.

On the destination database, sum(salary) corresponds to the sum of the salary in the emp table.

Yes

The sum for each table is the same in the source and destination databases.