9.3 Code and application testing

 < Day Day Up > 



9.3 Code and application testing

The most important part of the testing process is to verify that each component of the system functions as it did before migrating. All components of RDBMS system including views, stored procedures, triggers, application components, and security systems should be verified whether they are working properly.

9.3.1 View sanity check

The next step after data migration testing is to check all migrated views. Once data is moved over, the views can be tested to make sure they are working in the same way as in the source database. Depending upon the view, different checking scenarios can be created. Basic views can be easily checked, by counting rows the views return, or comparing calculated values similarly to the tests done on regular tables. More complicated views need a little more thought on how they should be checked, however, all view should be at a minimum reviewed by executing queries against them. The views created with intention to modify data should also be tested for inserting, updating, and deleting.

9.3.2 PL/SQL to SQL PL object check

All stored procedures, user defined functions, and triggers should be unit tested individually before they are promoted for further testing. This means that after objects are migrated (either manually, with MTK, or some combination of that) they need to be checked to make sure they function properly. Basic problems can be discovered by running stored procedures through the Development Center. The Development Center is a powerful tool used to develop stored procedures, user defined functions, or structured types. Within the Development Center there are options to run selected procedures in debug mode (Figure 9-4).

click to expand
Figure 9-4: Development Center debug window.

The Development Center can be run from the command line by entering db2dc or starting from the Tools menu of any graphical administration tool provided with DB2. For more information about the Development Center, refer to IBM DB2 UDB Guide to GUI Tools for Administration and Development, SC09-4851.

9.3.3 Application code check

The scope of application testing depends on the migrated application. For systems that were designed to support many versions of databases, like SAP, Siebel, or PeopleSoft, the testing process is usually well defined by the vendors, and offered a as a paid service.

For self build applications, the testing process should be started with the application queries. All queries should be independently tested to ensure that they return the expected results. With the application queries successfully migrated, the surrounding client programs should be rebuilt, and then the application should be tested against the target database. Each module of the application and possibly each screen form should be run and checked for errors or improper functionality. All the supported by application connectivity interfaced should also be checked.

The very important issue is to document all the tests conditions, like what operations were performed, which application screens were opened, what input data was used for testing, and what was the result. For larger projects, the documenting part can become overwhelming, so usually specialized software is used for those cases. As mentioned earlier, by definition, the new application cannot be fully tested. In the migration project, the application testing is an iterative process of planning, designing the test cases, executing the test cases, and finally evaluating and analyzing the results.

Together with various functional testing, the application should be checked also against performance. Since there are many architectural differences between Oracle and DB2, some SQL operations might require further optimization. Observing the performance differences on early testing stages increases the chance to prepare more optimal code for the new environment.

Before going into production, the migrated database should be verified under high volume and loads. These tests should emulate the production environment, and can determine if further application or database tuning is necessary. The stress load can also reveal other hidden problems, like locking issues, which can be observed only in a production environment.

9.3.4 Security

Before going into production, security must be checked in detail. Oracle handles security quite differently than DB2, so it is not trivial to compare the user rights between the two systems. Oracle's grants to roles are resolved in DB2 with operating system groups or secondary authorization identifications. A list of Oracle user should be compared to equivalent DB2 operating system users. All of DB2's authorities should be verified to allow proper persons to connect to the database. Privileges for all database objects also should be verified. Another important issue is to check the identifications of the user who was used for binding stored procedures, because executor of the procedures inherit the binder privileges.

9.3.5 Tools for testing and problem trucking

The software testing process can be a very complex task. All the tests should be synchronized with the development life cycle, and be well documented. For large projects, it might be necessary to use supportive software to improve testing productivity. IBM Rational Suite® TestStudio® can be used for that purpose.

IBM Rational Suite TestStudio is a set of tools for testers and developers. It automates regression, functionality, and performance testing, and provides background runtime analysis for increased product reliability. Rational Suite TestStudio also includes tools for control, management, and reporting of all test activities, defect, and change tracking, software configuration management, and requirements management. Rational Suite TestStudio addresses everything from test process standardization to results analysis, requirement determination to impact analysis, and test automation to defect tracking and reporting.

For more information about testing products, go to the IBM Rational Web site:

http://www.ibm.com/software/rational



 < Day Day Up > 



Oracle to DB2 UDB Conversion Guide2003
Oracle to DB2 UDB Conversion Guide2003
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net