Mutation analysis using mutant schemata
ISSTA '93 Proceedings of the 1993 ACM SIGSOFT international symposium on Software testing and analysis
Reducing the cost of mutation testing: an empirical study
Journal of Systems and Software
Software error analysis: a real case study involving real faults and mutations
ISSTA '96 Proceedings of the 1996 ACM SIGSOFT international symposium on Software testing and analysis
An experimental determination of sufficient mutant operators
ACM Transactions on Software Engineering and Methodology (TOSEM)
Quantitative Analysis of Faults and Failures in a Complex Software System
IEEE Transactions on Software Engineering
MSR '05 Proceedings of the 2005 international workshop on Mining software repositories
Predicting fault-prone components in a java legacy system
Proceedings of the 2006 ACM/IEEE international symposium on Empirical software engineering
Using Mutation Analysis for Assessing and Comparing Testing Coverage Criteria
IEEE Transactions on Software Engineering
Weak Mutation Testing and Completeness of Test Sets
IEEE Transactions on Software Engineering
Sufficient mutation operators for measuring test effectiveness
Proceedings of the 30th international conference on Software engineering
Is operator-based mutant selection superior to random mutant selection?
Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 1
Proceedings of the 2012 International Symposium on Software Testing and Analysis
Hi-index | 0.00 |
Mutation testing can be used to measure test suite quality in two ways: by treating the kill score as a quality metric, or by treating each surviving, non-equivalent mutant as an indicator of an inadequacy in the test suite. The first technique relies on the assumption that the mutation score is highly correlated with the suite's real fault detection rate, which is not well supported by the literature. The second technique relies only on the weaker assumption that the "interesting" mutants (i.e., the ones that indicate an inadequacy in the suite) are in the set of surviving mutants. Using the second technique also makes improving the suite straightforward. Unfortunately, mutation testing has a performance problem. At least part of the test suite must be run on every mutant, meaning mutation testing can be too slow for practical use. Previous work has addressed this by reducing the number of mutants to evaluate in various ways, including selecting a random subset of them. However, reducing the set of mutants by random reduction is suboptimal for developers using the second technique described above, since random reduction will eliminate many of the interesting mutants. We propose a new reduction method that supports the use of the second technique by reducing the set of mutants to those generated by altering files that have contained many faults in the past. We performed a pilot study that suggests that this reduction method preferentially chooses mutants that will survive mutation testing; that is, it preserves a greater number of interesting mutants than random reduction does.