initializing the software regression test pool based on ... · initializing the software regression...

Initializing the Software Regression Test Pool based on the Functional Dependency and Test Case Dependency

T.R. Anand(1)

, Dr. B. Rosiline Jeetha(2)

(1) Research Scholar, PG and Research Department of Computer Science, Dr. N.G.P. Arts and Science College, Coimbatore (India)

E-mail: [email protected]

(2) Head, PG and Research Department of Computer Science,

Dr. N.G.P. Arts and Science College, Coimbatore (India) E-mail: [email protected]

ABSTRACT

Regression Testing Process makes use of a subset of existing test suite. Identifying the appropriate test cases for the Regression test process makes the succeeding test minimization and prioritization process much better. Thus Regression test selection influences much in Regression test optimization. Various test case selection techniques have been proposed towards various goals, and their effectiveness has been evaluated through various measures. The existing approaches use various techniques to select the test cases for the regression test so that they can yield high Earlier Fault Detection Rate and high Average Percentage of Fault Detection. Few existing works focus on selecting test cases based on the test case dependencies. The work proposed focus on regression test case selection based on the dependency structure with in the functional requirements along with the dependency between the test cases of the identified functionalities to reach high APFD and Earlier Fault Detection Rate. This work proposes a theoretical approach using a Modification Status Flag (MSF) to identify the functional requirements to be involved in the Regression Test Process. The dependency structures that exist within the identified functional requirements are also taken into account and thus the test cases are identified for the regression test process. The existence of dependency among the functional requirements and among the test cases is identified using the Functional Dependency Matrix (FDM) and Test case Dependency Matrix (TDM). The work also makes use of the Requirement Traceability Matrix (RTM) to identify the test cases mapped for each requirements. The proposed work aims with initializing the Regression Test Suite for the Regression Test Process by achieving maximum code coverage without compromising the quality of the software and the testing process.

Keywords: dependency structure, modification status flag, regression test case selection, regression test pool

1- INTRODUCTION

A modified software need to be ensured with quality. Regression Testing is a process of re-executing the test cases over the new version of the software to detect the occurrence of errors introduced in the previous tested version. Regression testing ensures that the modification made do not impact the previously working functionality of the software. Regression Testing shall not be done by re-executing all the test cases of the previous version, as it consumes cost and time. Regression Test Suite (RTS) should always be a collection of test cases from the test suite of the previous version. The selection of test cases for the regression test suite is based on any of the measures such as maximum fault coverage, execution time, severity, priority, etc. A regression test process is time consuming and need more effort, and thus it is highly expensive. Optimization techniques should be done on the entire Regression Test Process to minimize the cost and effort involved in the Regression Test Process without compromising the quality of the testing process and the software. A Regression Test Optimization involves with selecting the test cases, minimizing the selected test cases, and prioritizing the test cases. Test optimization aims to minimize the cost of the test process, earlier fault detection, etc.

International Journal of Pure and Applied MathematicsVolume 118 No. 9 2018, 123-136ISSN: 1311-8080 (printed version); ISSN: 1314-3395 (on-line version)url: http://www.ijpam.euSpecial Issue ijpam.eu

123

2- RELATED WORKS

Bharti Suri et al[1], made Regression test suite selection based on BCO and GA to achieve test suite minimization with the ability to cover all the faults in minimum time. Sumit Dahiya et al[2], presented a regression test selection by considering the changes in semantics of operations, i.e., the change in conditional statements, change in independent paths/unique paths, change in control flow and addition or deletion of any content from the existing functionality, using UML diagrams.

Rahul Chaudhary et al[3], proposed a heuristic Regression Test case Selection algorithm for multi-objective optimization using metaheuristics and TSP - Travelling Salesman Problem. Chhabi Rani Panigrahil [4]proposed a technique to select regression test cases by using improved precision slices. They constructed a control flow graph model and dependency model of an object-oriented program. They identified the infeasible paths and computed the definition-use (def-use) pairs only along the feasible paths. The affected nodes were determined by constructing the forward slices on the dependency model. The authors selected the test cases that cover the affected nodes in the dependency graph model for regression testing.

Annibale Panichella et al[5], proposed a Mutli Objective Genetic Algorithm named as DIVersity based Genetic Algorithm (DIV-GA) for multi-objective test case selection. The algorithm was based on the mechanisms of orthogonal design and orthogonal evolution which increase the diversity by injecting new orthogonal individuals during the search process. Zeeshan Anwar et al [6], comparatively analyzed MOGA, NSGA-II and MOPSO techniques and found that these are not safe for regression test suite optimization because the fault detection rate and requirement coverage gets reduced after optimization of Regression Test Suites.

[7] Erik Rogstad et al. proposed a similarity-based test case selection approach for black box regression testing of database applications. Their experimental result showed that the combining similarity measurement with partition-based test case selection, by using similarity-based test case selection within each partition, provides improved fault detection rates over simpler solutions when specific conditions are met regarding the partitions. Siavash Mirarab et al [8], proposed a multi criteria non greedy optimization approach to solve size-constrained regression test case selection.

Bixin Li et al [9], proposed an approach to select test cases for regression testing of different versions of BPEL (Business Process Execution Language) composite services. Their proposed approach identify the changes by performing control flow analysis and by comparing the paths in a new version of composite service with those in the old one using a kind of eXtensible BPEL flow graph (XBFG). An optimal resource allocation model was proposed by Lian Yu et al[10], to select the test cases. A SVM approach has been proposed to classify the test cases, and applied P-measure and dynamic programming approaches to select the test cases from each of the categories to achieve high defect coverage within the limited time. The model has been built from test case data set by fully utilizing the test execution time with the highest ability of detecting defects.

Sahar Tahvili et al[11], proposed an approach for prioritized selection of test cases by using the Analytic Hierarchy Process (AHP) technique in a fuzzy environment. To get an optimum selection of the test cases Ming Huang et al [12], proposed an approach based on an improved genetic algorithm with improved genetic operators of selection, crossover and mutation. Zhiwei Xu et al [13], presented fuzzy expert system to select the test cases when the information of the source code is not available to the testers.

Indumathi C P et al [14], derived dependency structures among functions in a system and found the exact number of dependents of each function to achieve automated test case prioritization. Test cases with more dependents are assigned with high priority using graph coverage values. They found high rate of fault detection at the earlier by executing test cases with high priority, and thereby to fix the fault earlier.

Haidry proposed a technique[15] to find the total number of dependents for each test cases using DSP(Dependency Structure Prioritization) volume. Shin Yoo [16] used the Pareto efficient approach considering multiple objectives like code coverage, past fault-detection history and execution cost for

International Journal of Pure and Applied Mathematics Special Issue

124

test case selection. Their empirical results revealed that the greedy algorithms that perform well for single objective formulations are not always Pareto efficient in the multi-objective paradigm.

3- REGRESSION TEST OPTIMIZATION

Modification in a software leads to the increase in the size of the test suite and thus the cost of regression test process increases. It also leads to the chance of the occurrences of the new defects in the new version. Regression testing techniques addresses this problem to ensure defect free software. As stated earlier, Regression Testing involves in selecting the test cases from the existing test pool, minimizing the test cases based on certain criteria, and to prioritize them to achieve quality factors such as cost-consumption, earlier fault detection, and etc.

3-1 REGRESSION TEST CASE SELECTION

Retest-all, one of the Regression Test Technique, exercise the modified software with all the test cases of the previous version along with the test cases for the modification done. Retest-all is time-consuming and cost consuming process as it involves in testing the software with all the test cases.

Unlike Retest-all, Regression Test Case Selection involves in generating a subset of test cases from the existing set for the regression test process. This selection process is based on various criteria. The Regression Test Set also contains the test cases for the modified and/or new features. The objective of generating a sub set is to minimize the Regression Test Suite and thus to minimize the time and cost consumed by the Regression Test Process. The quality of the Testing process should not be sacrificed in generating the Regression Test Suite.

3- 2 REGRESSION TEST CASE PRIORITIZATION

Test case prioritization aims with ordering the test cases for test execution to reach measures such as increasing the rate of earlier fault detection, test execution time, cost of test execution, etc. In most cases, rate of earlier fault detection plays the highest objective of the Regression Test Case Prioritization Process. Several works has been proposed to prioritize the test cases for the Regression Test Process.

4- DEPENDENCY STRUCTURES

Functional dependencies occurs when a particular function, while execution, waits for the execution result or completeness of another function. Let F={F1, F2, F3,… F10} be the set of functional requirements of the System Under Test (SUT).

Figure 1 Functional Dependency – for a sample set of Functional Requirements, F


125

The Fig. 1 illustrates that the function F1 is dependent on the execution completeness of the other two functions F3 and F6. Similarly, F2 is dependent of the execution completeness of F3 and F4, F5 is dependent on the execution completeness of F2, F6 is dependent on the execution completeness of F7, F7 is dependent on the execution completeness of F4. The Fig. 1 also illustrates F8, F9, and F10 holds no dependency on other functional requirements.

Each of the functional requirements of software can be evaluated through one or more test cases. In other words, each of the functional requirements shall get mapped with one or more test cases. The below Fig. 2 illustrates that the Functional Requirement, F1, is to be evaluated based on the execution result of the test cases T1 and T2.

Similarly, F2 is to be evaluated with T3 and T4, and F3 is to be evaluated with T6, and F4 is to be evaluated with T8, and F5 is to be evaluated with T11, and F6 is to be evaluated with T14, and F7 is to be evaluated with T7, and F8 is to be evaluated with T16, and F9 is evaluated to be with T18 and T19, and F10 is to be evaluated with T20.

Figure 2 Test cases mapped with Functional Requirements

Dependencies may exist between test cases. Even though it is strongly recommended not to create dependencies between test cases, in certain scenarios it may happen for the testing team to create dependencies between the test cases. The result of one test case may influence the other test cases to run successfully. There are regularly adequate mean to work around the requirement for test case dependencies. The proposed approach also considers such test case dependencies into account.

The Fig. 3 states T4 depends on the successful completeness of T5. Similarly, T6 depends on T7, T8 depends on T9, and surprisingly T9 depends on T10, T11 depends on T12 and T13, T14 depends on T15, and T16 depends on T17.

By incorporating the dependency structure of test cases as in Fig. 3, the Fig. 2 shall be reformed in detail as Fig. 4 which illustrates the test cases mapped for the requirements. F2 has to be evaluated based on the test results of the test cases T3, T4 and T5. Similarly, F3 is mapped with T6 and T7, F4 is mapped with T8, T9 and T10, F5 is mapped with T11, T12 and T13, F6 is mapped with T14 and T15, F7 is


126

mapped with T7, and F8 is mapped with T16 and T17.

Figure 3 Test Suite with Test Cases showing dependencies

Figure 4 Test cases mapped with Functional Requirements


127

5- PROPOSED METHODOLOGY

5-1 SELECTION OF REGRESSION TEST CASES BASED ON FUNCTIONAL REQUIREMENT DEPENDNECY AND TEST CASE DEPENDENCY

Let F={F1, F2, F3,… F10} be the set of functional requirements. Populate a Functionality Dependency Matrix (FDM) for the functional requirements as illustrated in Fig. 1. By representing the row as i, and column as j, set (i,j) as 1, iff, Fi depends on Fj, where Fi, Fj ∈ F.

Similar to FDM, populate a Modification Status Flag (MSF) table for the functional requirements in F, in which each of the functional requirements Fi ∈ F is associated with a Modification Status Flag (MSF) value 1 if Fi is modified in the new version of the software, and with a flag value 0 if Fi has not undergone any changes in the new version.

Dependency occurs between functionalities, and hence whenever the Modification Status Flag (MSF) of any functional requirement, Fi is found to be set in the MSF table, the Functionality Dependency Matrix (FDM) is read to identify the dependent functionalities of Fi and is also considered for the current Regression Test Process along with Fi.

A Requirement Traceability Matrix (RTM) maps all the Functional Requirements with the set of test cases which have to be exercised to ensure defect free versions. For each Functional Requirement Fi in F, there exists one or more associated test cases of the Test Case Set T. A Test Case Dependency Matrix (TDM) matrix is also used which maps the dependency that occurs between test cases. Fig. 8 shows the test cases dependency for the Fig. 3.

The proposed approach of selection of test cases based on functional requirement dependency and test case dependency is:

Step 1: Identification of the participating functional requirements for the regression test process, based on their Modification Status Flag (MSF).

Step 2: Identification of the dependent functional requirements for each of the regression participating functional requirements whose MSF is set.

Step 3: Populating the Regression Test Pool with the test cases mapped for the identified functional requirements in step 1 and step 2.

(1) Identification of the participating functional requirements for the regression test process, based on their

Modification Status Flag (MSF)

Fig. 5 illustrates the Modification Status Flag (MSF) Table for the functional requirements in F. The Fig. 5 illustrates that F5 and F6 is been modified in the new version of the software. And so, F5 and F6 are the identified functional requirements which have to be tested in the current Regression Test Process.

Figure 5 Modification Status Flag

(2) Identification of the dependent functional requirements for each of the regression participating functional

requirements whose MSF is set


128

Figure 6 Functional Dependency Matrix

Fig. 6 illustrates the Functional Dependency Matrix (FDM) for the functional requirements in F. In Fig. 5, the Modification Status Flag table, F5 and F6 are set, and hence the Functional Dependency Matrix (FDM), in Fig. 6, is read to find the dependent functional requirements of F5 and F6. F5 depends on F2 and surprisingly F2 depends on F3 and F4. Similarly F6 depends on F7 and F7 depends on F4. Thus, the functional requirements F5, F2, F3, F4, F6, and F7 are identified for the Regression Test Process.

Figure 7 Requirement Traceability Matrix

(3) Populating the Regression Test Pool with the test cases mapped for the identified functional requirement

From Fig. 5, the Modification Status Flag (MSF) table, and Fig. 6, the Requirement Dependency Matrix (FDM), the functional requirements F5, F2, F3, F4, F6, and F7 are identified for the Regression Test Process. The next step in this approach is to initialize the Regression Test Pool with the test cases mapped for the identified functional requirements. Fig. 7 illustrates the Requirement Traceability Matrix (RTM) for the functional requirements in F, and is read to identify the test cases mapped for the identified functional requirements. For each identified test cases, if not exist in the Regression Test Pool, the Test Case Dependency Matrix (TDM) is read to identify its dependent test cases, and if any, such dependent test cases is also considered for the Regression Test Pool and the read continues for the identified dependent test cases to identify its dependent test cases, if any. The read continues until the identified dependent test cases shows no dependency.


129

Figure 8 Test Case Dependency Matrix for Fig. 3

From the Requirement Traceability Matrix (RTM) in Fig. 7, the test case T11 is mapped with F5. Now the Test Case Dependency Matrix (TDM), in Fig. 8, is read to identify the dependent test cases of T11. T12 and T13 are identified as the dependent test cases. T12 and T13 further show no dependency, and thus the Regression Test Pool is added with the test cases T11, T12 and T13.

In case of F2, the test cases T3 and T4 are mapped. Now the Test Case Dependency Matrix (TDM), in Fig. 8, is read to identify the dependent test cases of T3. T3 shows no dependency on other test cases, and thus T3 alone is added to the Regression Test Pool along which is already populated with T11, T12 and T13. Similarly, the Test Case Dependency Matrix (TDM) is read to identify the dependent test cases of T4. T4 shows dependency over T5 and T5 further show no dependency. Now the test cases T4 along with T5 are added to the Regression Test Pool which is already populated with T11, T12, T13 and T3.

In case of F3, the test case T6 is mapped. The Test Case Dependency Matrix (TDM) is read to identify its dependent test cases, and T7 is identified as the dependent test case. T7 further shows no dependency, and thus the Regression Test Pool is populated with the test cases T6 and T7 along with T11, T12, T13, T3, T4 and T5.

In case of F4, the test case T8 is mapped, and T9 is identified as the dependent test case. T9 further shows dependency on T10 and no further dependencies, and thus the Regression Test Pool is added with the test cases T8, T9 and T10 along with T11, T12, T13, T3, T4 and T5, T6, and T7.

In case of F6, the test case T14 is mapped, and T15 is identified as the dependent test case. T15 further shows no dependency thus the Regression Test Pool is added with the test cases T14 and T15 along with T11, T12, T13, T3, T4, T5, T6, T7, T8, T9 and T10. In case of F7, the test case T7 is mapped. T7 exists in the Regression Test Pool and so the Test Case Dependency Matrix in not read.


130

5-2 PSEUDOCODE FOR THE PROPOSED APPROACH

The pseudo code for initializing the Regression Test Pool (RTP) with test cases based on the functional requirements dependency and test case dependency.

Input:

F={F1, F2, F3,… Fn} – set of functional requirements

T={T1,T2,T3,…Tn} – set of test cases

Modification Status Flag (MSF) Table

Functional Dependency Matrix (FDM)

Requirement Traceability Matrix (RTM)

Test case Dependency Matrix (TDM)

Output:

RT pool initialized with test cases of modified functional requirements and its dependent requirements

Begin

For each Fi in F with MSF 1

Read the FDM to identify its dependents

For each identified dependents

Continue to identify the next level dependents.

End

For each identified dependents

Identify the mapped test cases from RTM

For each identified test cases

Identify its dependent test cases and add in the Regression Test Pool

End

End

End

End

The proposed approach thus populate the Regression Test Pool with the test cases T11, T12, T13, T3, T4, T5, T6, T7, T8, T9,T10, T14 and T15. These identified test cases will provide more coverage factors as the modified requirements are tested along with its dependent requirements.

6- ANALYSIS AND DISCUSSION

In this paper the proposed work is analyzed based on assumed LoC count and the coverage criteria of each functional functional requirements as in the Fig. 1. Table 1 shows the LoC of the functional requirements, F={F1, F2, F3,… F10}. The value of LoC ranges from 1000 to 6800. Table 1 also shows the percentage of LoC of each functional requirement with respect to the total LoC. The code coverage percentage of the functional requirements, as per Table 1, ranges from 3.29% to 22.37%. Figure 9 illustrates the graphical representation of the code coverage percentage. The x-axis represents the functional requirements in F, and y-axis represents the percentage of code coverage.


131

Req, Func. # LoC % of LoC

F1 3500 11.51

F2 2500 8.22

F3 3750 12.34

F4 1500 4.93

F5 2250 7.40

F6 2300 7.57

F7 4500 14.80

F8 6800 22.37

F9 1000 3.29

F10 2300 7.57

Table 1 LoC of the functional requirements

Figure 9 Percentage of Statement Coverage of the functional requirements

Table 1 is used to analyze the percentage of code coverage by the Regression Test Suite initialized through requirement functional dependency and its test case dependencies. Table 2 shows the % of statement coverage by all the identified test cases of the proposed approach. The table also shows the identified functional requirements and its dependents, the test cases and its dependents mapped for the identified functional requirements as per the Figures 5,6,7 and 8, and the number of LoC covered by each identified test cases. Table 3 shows the % of statement coverage by the test cases identified by the existing approach based on test case dependency. Table 3 also shows the identified test cases and its dependents along with the number of LoC covered by each identified test cases. The % of statement coverage present in Table 2 and 3 represents the maximum percentage of statement coverage that shall be obtained based on the total LoC.

The % of statement coverage is calculated by,

Percentage of Statement Coverage = 𝐿𝑜𝐶( 𝑇𝑖 ,𝐹𝑗 ) / LoC(SUT)

Where as, Ti stands for test case for the functional requirement for the Regression Test Process, and Fi stands for the functional requirement identified for the Regression Test Process.


132

The % of coverage criteria is calculated as 14.97% for the existing approach and 55.26% for the proposed approach. Figure 10 shows the graphical representation of the comparative analysis of the percentage of statement coverage between the existing approach and the proposed approach.

Proposed Approach based on Req. Func. Dependency and Test Case Dependency

Participating Req. Func. for Regression Test

Participating Test Cases for Regression Test

LoC covered by the Regression Test Suite

% of Statement Coverage

F2 T3,T4,T5 1750+500+250

55.26

F3 T6,T7 2500+1250

F4 T8,T9,T10 850+450+250

F5 T11,T12,T13 1200+800+250

F6 T14,T15 1850+450

F7 T7 4500

Table 2 Percentage of Statement Coverage by the identified test cases through the proposed approach

Existing Approach based on Test Case Dependency

Participating Req. Func. for Regression Test

Participating Test Cases for Regression Test

LoC covered by the Regression Test Suite

% of Statement Coverage

F5 T11,T12,T13 1200+800+250 14.97

F6 T14,T15 1850+450

Table 3 Percentage of Statement Coverage by the identified test cases through the existing approach

Figure 10 Proposed approach Vs Existing Approach


133

7- CONCLUSION

The results discussed are based on the dependency between the functional requirements, the dependency between their mapped test cases, and its related assumed data represented in the Fig. 5,6,7, and 8, and Table 1. Based on the Modification Status Flag (MSF) table in Fig. 5, the Functional Dependency Matrix (FDM) in Fig. 6, the Requirement Traceability Matrix (RTM) in Fig. 7, and the Test case Dependency Matrix in Fig. 8, the proposed approach identifies the functional requirements to be involved in the Regression Test Process as {F5, F2, F3, F4, F6, and F7 }, and the test cases mapped for these identified functional requirements are {T11, T12, T13, T3, T4, T5, T6, T7, T8, T9,T10, T14 and T15}. The results discussed in the previous section illustrates that the test cases identified by the proposed approach for the regression test yields more code coverage(55.26%) in the System Under Test (SUT) than the existing approach (14.97%). More % of code coverage in turn has the high probability of Earlier Fault Detection Rate and high Average Percentage of Fault Detection.

The proposed approach identifies the functional requirements to be tested in the current Regression Test Cycle. The identified test cases shall cover the modified functional requirements without missing its dependent functional requirements, and thus can yield more test coverage on the product to be tested. This approach shall be extended as multi-criteria approach by considering the other quality yield factors for the minimization of Regression Test Pool.

REFERENCES

[1] B. Suri and S. Singhal, “Evolved Regression Test Suite Selection using BCO and GA and Empirical Comparison with ACO,” CSI Trans. ICT, vol. 3, no. 2–4, pp. 143–154, 2015.

[2] S. Dahiya, R. K. Bhatia, and D. ,Rattan, “Regression Test Selection using Class, Sequence and Activity Diagrams,” IET Softw., vol. 10, no. 3, pp. 72–80, 2016.

[3] R. Chaudhary, “Regression Test Case Selection for Multi- Objective Optimization using Metaheuristics,” Int. J. Information Technology and Computer Science, March, pp. 50–56, 2015.

[4] C. R. Panigrahi and R. Mall, “Regression Test Size Reduction Using Improved Precision Slices,” Innov. Syst. Softw. Eng., vol. 12, no. 2, pp. 153–159, 2015.

[5] A. Panichella, R. Oliveto, M. Di Penta, and A. De Lucia, “Improving Multi-Objective Test Case Selection by Injecting Diversity in Genetic Algorithms,” IEEE Trans. Softw. Eng., vol. 41, no. 4, pp. 358–383, 2015.

[6] Z. Anwar and A. Ahsan, “Comparative Analysis of MOGA , NSGA-II and MOPSO for Regression Test Suite Optimization,” Int. J. Softw. Eng., vol. 7, no. 1, pp. 41–56, 2014.

[7] E. Rogstad, L. Briand, and R. Torkar, “Test Case Selection for Black-Box Regression Testing of Database Applications,” Inf. Softw. Technol., vol. 55, no. 10, pp. 1781–1795, 2013.

[8] S. Mirarab, S. Akhlaghi, and L. Tahvildari, “Size-Constrained Regression Test Case Selection Using Multicriteria Optimization,” IEEE Trans. Softw. Eng., vol. 38, no. 4, pp. 936–956, 2012.

[9] B. Li, D. Qiu, H. Leung, and D. Wang, “Automatic Test Case Selection for Regression Testing of Composite Service Based on Extensible BPEL FLOW graph,” J. Syst. Softw., vol. 85, no. 6, pp. 1300–1324, 2012.

[10] L. Yu, L. Xu, and W. Tsai, “Time-Constrained Test Selection for Regression Testing,” Springer, pp. 221–232, 2010.

[11] S. Tahvili, M. Saadatmand, and M. Bohlin, “Multi-Criteria Test Case Prioritization using Fuzzy Analytic Hierarchy Process,” ICSEA 2015: The Tenth International Conference on Software Engineering Advances, pp. 290–296, 2015.


134

[12] M. Huang, S. Technology, S. Guo, X. Liang, S. Technology, and X. Jiao, “Research on Regression Test Case Selection Based on Improved Genetic Algorithm,” 3rd Int. Conf. on Computer Science and Network Technology, pp. 256–259, 2013.

[13] T. M. Khoshgoftaar, “Application of Fuzzy Expert System in Test Case Selection for System Regression Test,” IRI -2005 IEEE Int. Conf. Inf. Reuse Integr. Conf, 2005., pp. 120–125, 2005.

[14] C. P. Indumathi and K. Selvamani, “Test Cases Prioritization using Open Dependency Structure Algorithm,” Procedia Comput. Sci., vol. 48, pp. 250–255, 2015.

[15] S. Haidry and T. Miller, “Using Dependency Structures for Prioritization of Functional Test Suites,” IEEE Trans. Softw. Eng., vol. 39, no. 2, pp. 258–275, 2013.

[16] S. Yoo and M. Harman, “Pareto Efficient Multi-Objective Test Case Selection,” Proc. 2007 Int. Symp. Softw. Test. Anal. - ISSTA ’07, p. 140, 2007.


135

initializing the software regression test pool based on ... · initializing the software regression...

Documents