The collateral coverage of data flow criteria when branch testing

Malevris, Nicos; Yates, Derek

doi:10.1016/j.infsof.2005.07.006

Cited by 25 publications

(13 citation statements)

References 17 publications

(24 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Additionally, guidelines for the application of mutation testing are also given, by measuring the ability of killing mutants utilising test paths. The reason behind the choice of candidate sets of paths as a measurement of the effort stems from the observation that infeasible paths greatly influence the effort associated with the testing process [6,7]. This is evident from the following experiments where a huge number of paths are analysed in order to find a small number of feasible paths, see Section 6.3 for a discussion on the influence of infeasible paths on the testing effort.…”

Section: The Methods Usedmentioning

confidence: 99%

“…All the selected units have no calls to other functions as these have been ''inlined'' in the units under test. The sample consists of programs written in various programming languages some of which have been referenced in the literature [21,6,43]. The units were selected based on their use in the literature, the observation that they contained certain important features such as: nesting, loop constructs, use of arrays and also many infeasible paths.…”

Section: Experimental Regimementioning

confidence: 99%

“…The one employed in the present study is based on selecting paths that the mutants lie on, and subsequently executing them with test data, thus utilising each one of the mutants in order to kill them. The drawbacks of such a strategy, as it has been reported in the literature, are attributed to the presence of infeasible paths [6,7]. The strategy adopted in this exercise, seeks to reduce the undesirable effects of infeasible paths during the testing process and hence reciprocally, also reduce the overall testing effort.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Mutation based test case generation via a path selection strategy

Papadakis

Malevris

2012

Information and Software Technology

View full text Add to dashboard Cite

a b s t r a c tContext: Generally, mutation analysis has been identified as a powerful testing method. Researchers have shown that its use as a testing criterion exercises quite thoroughly the system under test while it achieves to reveal more faults than standard structural testing criteria. Despite its potential, mutation fails to be adopted in a widespread practical use and its popularity falls significantly short when compared with other structural methods. This can be attributed to the lack of thorough studies dealing with the practical problems introduced by mutation and the assessment of the effort needed when applying it. Such an incident, masks the real cost involved preventing the development of easy and effective to use strategies to circumvent this problem. Objective: In this paper, a path selection strategy for selecting test cases able to effectively kill mutants when performing weak mutation testing is presented and analysed. Method: The testing effort is highly correlated with the number of attempts the tester makes in order to generate adequate test cases. Therefore, a significant influence on the efficiency associated with a test case generation strategy greatly depends on the number of candidate paths selected in order to achieve a predefined coverage goal. The effort can thus be related to the number of infeasible paths encountered during the test case generation process. Results: An experiment, investigating well over 55 million of program paths is conducted based on a strategy that alleviates the effects of infeasible paths. Strategy details, along with a prototype implementation are reported and analysed through the experimental results obtained by its employment to a set of program units. Conclusion:The results obtained suggest that the strategy used can play an important role in making the mutation testing method more appealing and practical.

show abstract

Section: The Methods Usedmentioning

confidence: 99%

Section: Experimental Regimementioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Mutation based test case generation via a path selection strategy

Papadakis

Malevris

2012

Information and Software Technology

View full text Add to dashboard Cite

show abstract

“…Much research has considered how to aid data flow testing. Some efforts use random testing combined with program slicing [41], while a few others use the collateral coverage relationship [47], [48] between branch/statement and data-flow criteria to generate data-flow test data. There is also work that applies search-based techniques [39], [49]- [51] to perform data flow testing.…”

Section: Threats To Validitymentioning

confidence: 99%

Combining Symbolic Execution and Model Checking for Data Flow Testing

Su¹,

Fu²,

Pu³

et al. 2015

2015 IEEE/ACM 37th IEEE International Conference on Software Engineering

View full text Add to dashboard Cite

Abstract-Data flow testing (DFT) focuses on the flow of data through a program. Despite its higher fault-detection ability over other structural testing techniques, practical DFT remains a significant challenge. This paper tackles this challenge by introducing a hybrid DFT framework: (1) The core of our framework is based on dynamic symbolic execution (DSE), enhanced with a novel guided path search to improve testing performance; and (2) we systematically cast the DFT problem as reachability checking in software model checking to complement our DSEbased approach, yielding a practical hybrid DFT technique that combines the two approaches' respective strengths. Evaluated on both open source and industrial programs, our DSE-based approach improves DFT performance by 60∼80% in terms of testing time compared with state-of-the-art search strategies, while our combined technique further reduces 40% testing time and improves data-flow coverage by 20% by eliminating infeasible test objectives. This combined approach also enables the crosschecking of each component for reliable and robust testing results.

show abstract

“…In most previous works they defined the testing complexity as the number of test cases required [35,22]. Some works try to compute the lower bound [7] of the test cases required, and other works try to provide better understanding on the testing criterion used to generate those test cases [23]. However, they do not focus on the effort to generate these test cases.…”

Section: Introductionmentioning

confidence: 99%

Estimating software testing complexity

Ferrer

Chicano

Alba

2013

Information and Software Technology

View full text Add to dashboard Cite

Context: Complexity measures provide us some information about software artifacts. A measure of the difficulty of testing a piece of code could be very useful to take control about the test phase. Objective: The aim in this paper is the definition of a new measure of the difficulty for a computer to generate test cases, we call it Branch Coverage Expectation (BCE). We also analyze the most common complexity measures and the most important features of a program. With this analysis we are trying to discover whether there exists a relationship between them and the code coverage of an automatically generated test suite. Method: The definition of this measure is based on a Markov model of the program. This model is used not only to compute the BCE, but also to provide an estimation of the number of test cases needed to reach a given coverage level in the program. In order to check our proposal, we perform a theoretical validation and we carry out an empirical validation study using 2600 test programs. Results: The results show that the previously existing measures are not so useful to estimate the difficulty of testing a program, because they are not highly correlated with the code coverage. Our proposed measure is much more correlated with the code coverage than the existing complexity measures. Conclusion: The high correlation of our measure with the code coverage suggests that the BCE measure is a very promising way of measuring the difficulty to automatically test a program. Our proposed measure is useful for predicting the behaviour of an automatic test case generator.

show abstract

The collateral coverage of data flow criteria when branch testing

Cited by 25 publications

References 17 publications

Mutation based test case generation via a path selection strategy

Mutation based test case generation via a path selection strategy

Combining Symbolic Execution and Model Checking for Data Flow Testing

Estimating software testing complexity

Contact Info

Product

Resources

About