A Regression Test Selection Technique Applied to Legacy Systems

Abstract

<p>Software testing is a necessary step in both the software production chain and during future maintenance. Testing can be performed using many different techniques. It is much easier to test a piece of software during the original development process, rather than after the system has been deployed and in use for many years. However, testing must be performed whenever software is altered. How should testing be performed on legacy software? The answer to this question is the focus of this thesis.</p> <p>Regression testing is performed on software during its maintenance stage. Usually it is done after changes have been made to the software or its environment. The concept of regression testing does not assume the existence of a test suite for the software. It might be the case that test cases have to be created from the scratch. However, when software with a huge existing test suite is under consideration, then it is not always a good idea to run the whole test suite in order to perform regression testing. This might be too expensive both in time and human effort. This problem motivate the concept of regression test selection, which tells us that by using certain selection criteria it is possible to select a subset of an existing test suite and run that subset on the software instead.</p> <p>Our project involves reducing the burden of regression testing for a legacy system that is built on top of the Oracle E-Business Suite and Oracle database. The changes are made through patches that are sent by Oracle. Most of the time, patches do not introduce big changes to the E-Business Suite. Also, it is likely that the legacy software application uses a relatively small portion of Oracle's Enterprise Resource Planning (ERP) system. In this case, it is crucial to be able to select a subset of the test suite for regression testing. Running the whole test suite can be very costly, and is almost always not necessary.</p> <p>The approach we adopted relies on building the access dependency graph of the whole system first. An access dependency graph is a control flow graph but with fields and methods of classes as nodes. Then, after identifying which places in the Oracle E-Business Suite changed after patching, the inverse calling paths are built with changed places as starting points and functions in the customer's application as end points. Now, when affected functions have been identified, it should be possible to select a subset of the existing test suite which will exercise functions that have been directly or indirectly changed by the patch, and which will not include tests that are not impacted by the changes to the software system embodied in the patch. We also demonstrate that the selection technique proposed in this work is safe (does not miss tests that should be included). This gives us some confidence about the applicability of the algorithm.</p>