Divide-by-Zero Exception Raising via Branch Coverage

Bhattacharya, Neelesh; Sakti, Abdelilah; Antoniol, Giuliano; Guéhéneuc, Yann‐Gaël; Pesant, Gilles

doi:10.1007/978-3-642-23716-4_19

Cited by 7 publications

(5 citation statements)

References 13 publications

(30 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…It is also possible to represent arithmetic errors such as division by zero faults as branches in the source code, such that traditional SBST metrics such as the branch distance can optimize towards these errors [8]. In this paper, we also add new branches to the code that represent error conditions; however, in real-world software the number of such conditions may be so large that it becomes an issue of scalability for the traditional approach of targeting one branch at a time.…”

Section: Sbst and Automated Oraclesmentioning

confidence: 99%

“…This has for example been done for division by zero errors [8] or null pointer exceptions [38]. In the following, we describe several transformations implemented in the EVOSUITE tool; some transformations are similar to the additional constraints that are added to DSE when applying Active Property Checking [23] (division by zero, array bounds, null pointer dereference).…”

Section: Testability Transformationmentioning

confidence: 99%

See 1 more Smart Citation

1600 faults in 100 projects: automatically finding faults while achieving high coverage with EvoSuite

Fraser

Arcuri

2013

Empir Software Eng

View full text Add to dashboard Cite

Automated unit test generation techniques traditionally follow one of two goals: Either they try to find violations of automated oracles (e.g., assertions, contracts, undeclared exceptions), or they aim to produce representative test suites (e.g., satisfying branch coverage) such that a developer can manually add test oracles. Search-based testing (SBST) has delivered promising results when it comes to achieving coverage, yet the use in conjunction with automated oracles has hardly been explored, and is generally hampered as SBST does not scale well when there are too many testing targets. In this paper we present a search-based approach to handle both objectives at the same time, implemented in the EVOSUITE tool. An empirical study applying EVOSUITE on 100 randomly selected open source software projects (the SF100 corpus) reveals that SBST has the unique advantage of being well suited to perform both traditional goals at the same time -efficiently triggering faults, while producing representative test sets for any chosen coverage criterion. In our study, EVOSUITE detected twice as many failures in terms of undeclared exceptions as a traditional random testing approach, witnessing thousands of real faults in the 100 open source projects. Two out of every five classes with undeclared exceptions have actual faults, but these are buried within many failures that are caused by implicit preconditions. This "noise" can be interpreted as either a call for further research in improving automated oracles -or to make tools like EVOSUITE an integral part of software development to enforce clean program interfaces.

show abstract

Section: Sbst and Automated Oraclesmentioning

confidence: 99%

Section: Testability Transformationmentioning

confidence: 99%

1600 faults in 100 projects: automatically finding faults while achieving high coverage with EvoSuite

Fraser

Arcuri

2013

Empir Software Eng

View full text Add to dashboard Cite

show abstract

“…There have been attempts to make such implicit error conditions explicit to allow test generation tools to cover these cases (e.g., [2,10]), Pex also makes these branches explicit [12], and SAGE includes such conditions in the properties it checks for [6]. If the test generation tool does not already have treatment of error conditions hard coded, these can easily be represented as path condition augmentation rules.…”

Section: Error Conditionsmentioning

confidence: 98%

“…To apply the existing techniques to different target criteria, a common approach is to transform these other criteria to branch coverage problems. This has for example been done for division by zero errors [2], null pointer exceptions [10], mutation testing [14], or boundary value analysis and logical coverage criteria [9]. Here, additional test objectives are explicitly included in the program code in terms of new branch instructions, such that existing tools that are already good at achieving branch coverage can be reused.…”

Section: Introductionmentioning

confidence: 98%

Augmented dynamic symbolic execution

Jamrozik

Tillmann

Halleux

2012

Proceedings of the 27th IEEE/ACM International Conference on Automated Software Engineering

View full text Add to dashboard Cite

Dynamic symbolic execution (DSE) can efficiently explore all simple paths through a program, reliably determining whether there are any program crashes or violations of assertions or code contracts. However, if such automated oracles do not exist, the traditional approach is to present the developer a small and representative set of tests in order to let him/her determine their correctness. Customer feedback on Microsoft's Pex tool revealed that users expect different values and also more values than those produced by Pex, which threatens the applicability of DSE in a scenario without automated oracles. Indeed, even though all paths might be covered by DSE, the resulting tests are usually not sensitive enough to make a good regression test suite. In this paper, we present augmented dynamic symbolic execution, which aims to produce representative test sets by augmenting path conditions with additional conditions that enforce target criteria such as boundary or mutation adequacy, or logical coverage criteria.

show abstract

“…Bhattacharya et al presented a novel testability transformation to generate test input data to raise divide-by-zero exceptions in software systems [39]. Their testability transformation is based on both approach level and branch distance.…”

Section: Test Data Generation With Faults Detectionmentioning

confidence: 99%

Generating test data for both paths coverage and faults detection using genetic algorithms: multi-path case

Zhang

Gong

2014

Front. Comput. Sci.

View full text Add to dashboard Cite

Generating test data that can expose the faults of the program is an important issue in software testing. Although previous methods of covering path can generate test data to traverse target path, the test data generated by these methods are difficult in detecting some low-probabilistic faults that lie on the covered paths. We present a method of generating test data for covering multiple paths to detect faults in this study. First, we transform the problem of covering multiple paths and detecting faults into a multi-objective optimization problem with constraint, and construct a mathematical model for it. Then, we give a strategy of solving the model based on a weighted genetic algorithm. Finally, we apply our method to several real-world programs, and compare it with several methods. The experimental results confirm that the proposed method can more efficiently generate test data that not only traverse the target paths but also detect faults lying in them than other methods.

show abstract

Divide-by-Zero Exception Raising via Branch Coverage

Cited by 7 publications

References 13 publications

1600 faults in 100 projects: automatically finding faults while achieving high coverage with EvoSuite

1600 faults in 100 projects: automatically finding faults while achieving high coverage with EvoSuite

Augmented dynamic symbolic execution

Generating test data for both paths coverage and faults detection using genetic algorithms: multi-path case

Contact Info

Product

Resources

About