Fault-based testing is an approach where the designed test data is used to demonstrate the absence of a set of prespecified faults, typically being frequently occurring faults. Mutation testing is a fault-based testing technique used to inject faults into an existing program, i.e., a variation of the original program and see if the test suite is sensitive enough to detect common faults. Aspect-Oriented Programming (AOP) provides new modularization of software systems by encapsulating crosscutting concerns. AspectJ, a language designed to support AOP uses abstractions like pointcuts, advice, and aspects to achieve AOP's primary functionality. Developers tend to write pointcut expressions with incorrect strength, thereby selecting additional events than intended to or leaving out necessary events. This incorrect strength causes aspects, the set of crosscutting concerns, to fail. Hence there is a need to test the pointcuts for their strength. Mutation testing of pointcuts includes two steps: creating effective mutants (variations) of a pointcut expression and testing these mutants using the designed test data. The number of mutants for a pointcut expression is usually large due to the usage of wildcards. It is tedious to manually identify effective mutants that are of appropriate strength and resemble closely the original pointcut expression. Our framework automatically generates mutants for a pointcut expression and identifies mutants that resemble closely the original expression. Then the developers could use the test data for the woven classes against these mutants to perform mutation testing.

Improving test cases automatically is a nonlinear optimization problem. To solve this problem, we've developed a bacteriologic algorithm, adapted from genetic algorithms that can generate and optimize a set of test cases. A .NET component that parses C# source files illustrates our algorithm.

Available soon...

Available soon...

The level of confidence in a software component is often linked to the quality of its test cases. This quality can in turn be evaluated with mutation analysis: faults are injected into the software component (making mutants of it) to check the proportion of mutants detected (‘killed’) by the test cases. But while the generation of a set of basic test cases is easy, improving its quality may require prohibitive effort. This paper focuses on the issue of automating the test optimization. The application of genetic algorithms would appear to be an interesting way of tackling it. The optimization problem is modelled as follows: a test case can be considered as a predator while a mutant program is analogous to a prey. The aim of the selection process is to generate test cases able to kill as many mutants as possible, starting from an initial set of predators, which is the test cases set provided by the programmer. To overcome disappointing experimentation results, on .Net components and unit Eiffel classes, a slight variation on this idea is studied, no longer at the ‘animal’ level (lions killing zebras, say) but at the bacteriological level. The bacteriological level indeed better reflects the test case optimization issue: it mainly differs from the genetic one by the introduction of a memorization function and the suppression of the crossover operator. The purpose of this paper is to explain how the genetic algorithms have been adapted to fit with the issue of test optimization. The resulting algorithm differs so much from genetic algorithms that it has been given another name: bacteriological algorithm.

Kuhn, followed by Tsuchiya and Kikuno, have developed a hierarchy of relationships among several common types of faults (such as variable and expression faults) for specification-based testing by studying the corresponding fault detection conditions. Their analytical results can help explain the relative effectiveness of various fault-based testing techniques previously proposed in the literature. This article extends and complements their studies by analyzing the relationships between variable and literal faults, and among literal, operator, term, and expression faults. Our analysis is more comprehensive and produces a richer set of findings that interpret previous empirical results, can be applied to the design and evaluation of test methods, and inform the way that test cases should be prioritized for earlier detection of faults. Although this work originated from the detection of faults related to specifications, our results are equally applicable to program-based predicate testing that involves logic expressions.

Available soon...

Available soon...

Available soon...

Available soon...