Regression Testing of Object-Oriented Software based on Program Slicing

Abstract

As software undergoes evolution through a series of changes, it is necessary to validate these changes through regression testing. Regression testing becomes convenient if we can identify the program parts that are likely to be affected by the changes made to the programs as part of maintenance activity. We propose a change impact analysis mechanism as an application of slicing. A new slicing method is proposed to decompose a Java program into affected packages, classes, methods and statements identified with respect to the modification made in the program. The decomposition is based on the hierarchical characteristic of Java programs. We have proposed a suitable intermediate representation for Java programs that shows all the possible dependences among the program parts. This intermediate representation is used to perform the necessary change impact analysis using our proposed slicing technique and identify the program parts that are possibly affected by the change made to the program. The packages, classes, methods, and statements thus affected are identified by traversing the intermediate graph, first in the forward direction and then in the backward direction. Based on the change impact analysis results, we propose a regression test selection approach to select a subset of the existing test suite. The proposed approach maps the decomposed slice (comprising of the affected program parts) with the coverage information of the existing test suite to select the appropriate test cases for regression testing. All the selected test cases in the new test suite are better suited for regression testing of the modified program as they execute the affected program parts and thus have a high probability of revealing the associated faults. The regression test case selection approach promises to reduce the size of regression test suite. However, sometimes the selected test suite can still appear enormous, and strict timing constraints can hinder execution of all the test cases in the reduced test suite. Hence, it is essential to minimize the test suite. In a scenario of constrained time and budget, it is difficult for the testers to know how many minimum test cases to choose and still ensure acceptable software quality. So, we introduce novel approaches to minimize the test suite as an integer linear programming problem with optimal results. Existing research on software metrics have proven cohesion metrics as good indicator of fault-proneness. But, none of these proposed metrics are based on change impact analysis. We propose a changebased cohesion measure to compute the cohesiveness of the affected program parts. These cohesion values form the minimization criteria for minimizing the test suite. We formulate an integer linear programming model based on the cohesion values to optimize the test suite and get optimal results. Software testers always face the dilemma of enhancing the possibility of fault detection. Regression test case prioritization promises to detect the faults early in the retesting process. Thus, finding an optimal order of execution of the selected regression test cases will maximize the error detection rates at less time and cost. We propose a novel approach to identify a prioritized order of test cases in a given regression selected test suite that has a high chance of fault exposing capability. It is very likely that some test cases execute some program parts that are more prone to errors and have a greater possibility of detecting more errors early during the testing process. We identify the fault-proneness of the affected program parts by finding their coupling values. We propose to compute a new coupling metric for the affected program parts, named affected change coupling, based on which the test cases are prioritized. Our analysis shows that the test cases executing the affected program parts with high affected change coupling have a higher potential of revealing faults early than other test cases in the test suite. Testing becomes convenient if we identify the changes that require rigorous retesting instead of laying equal focus to retest all the changes. Thus, next we propose an approach to save the effort and cost of retesting by identifying and quantifying the impact of crosscutting changes on other parts of the program. We propose some metrics in this regard that are useful to the testers to take early decision on what to test more and what to test less.