1. Mutation Testing Laraib Zahid & Mariam Arshad

2. What is Mutation Testing?  Fault-based Testing: directed towards “typical” faults that could occur in a program  Technique of running tests over deliberately broken versions (mutants)  Failing is the new passing—the mutant should break the tests  It is not new- the concept was introduced by Richard Lipton in 1970

3. Basic Idea  Take a program and test data generated for that program  Create a number of similar programs (mutants), each differing from the original in one small way, i.e., each possessing a fault e.g., replace addition operator by multiplication operator  The original test data are then run through the mutants  If test data detect all differences in mutants, then the mutants are said to be dead, and the test set is adequate

4. Basic Idea (II) O A mutant remains live either – because it is equivalent to the original program (functionally identical although syntactically different – called an equivalent mutant) or, – the test set is inadequate to kill the mutant O In the latter case, the test data need to be augmented (by adding one or more new test cases) to kill the live mutant O For the automated generation of mutants, we use mutation operators, that is predefined program modification rules

5. Example of Mutation Operators Delta’s represent syntactic modifications. In fact, each of them will be embedded in a different program version, a mutant.

6. Mutation Testing Types  Value Mutations: An attempt to change the values to detect errors in the programs. We usually change one value to a much larger value or one value to a much smaller value. The most common strategy is to change the constants.  Decision Mutations: The decisions/conditions are changed to check for the design errors. Typically, one changes the arithmetic operators to locate the defects and also we can consider mutating all relational operators and logical operators (AND, OR, NOT)  Statement Mutations: Changes done to the statements by deleting or duplicating the line which might arise when a developer is copy pasting the code from somewhere else.

7. Mutation Coverage  Complete coverage equals to killing all non- equivalent mutants (or random sample)  The amount of coverage is also called “mutation score”  We can see each mutant as a test requirement  The number of mutants depends on the definition of mutation operators and the syntax/structure of the software  Numbers of mutants tend to be large, even for small programs (hence random sampling)

8. Different Types of Mutants  Stillborn mutants: Syntactically incorrect, killed by compiler, e.g., x = a ++ b  Trivial mutants: Killed by almost any test case  Equivalent mutant: Always acts in the same behavior as the original program, e.g., x = a + b and x = a – (-b)  None of the above are interesting from a mutation testing perspective  Those mutants are interesting which behave differently than the original program, and we do not have test cases to identify them (to cover those specific changes)

9. Example of an Equivalent Mutant

10. Mutation Testing Process

11. Applications  Mutation operators and systems are also very useful for assessing the effectiveness of test strategies- they have been used in a number of case studies  Define a set of realistic mutation operators  Generate mutants (automatically)  Generate test cases according to alternative strategies  Assess the mutation score (percentage of mutants killed)  There are also works on  Mutation operators for module interfaces (aimed at integration testing)  Mutation operators on specifications: Petri-nets, state machines (aimed at system testing)

12. Mutation Testing Tools  Tools O MuClipse: perhaps the best tool out there O Jester: A Mutation Testing tool in Java (Open Source) O Pester: A Mutation Testing tool in Python (Open Source) O Nester: A Mutation Testing tool in C# (Open Source)

13. Advantages  powerful approach to attain high coverage of the source program  comprehensively test the mutant program.  brings a good level of error detection to the software developer  uncovers ambiguities in the source code  has the capacity to detect all the faults in the program  most reliable and stable system.

14. Disadvantages  extremely costly and time consuming  testing cannot be done without an automation tool.  large number of mutant programs may need to be tested against the original test suite  not at all applicable for black box testing.

15. Conclusions O It is not just a testing method; it is more of an analytical method. O Based on the set guidelines, the tester analyzes the results and implements the appropriate corrective measures. O there is no Pass/ Fail disposition if the output fails to meet the standard output as defined in the test cases. O Instead, adjustments are made to improve whatever was lacking. O It is an effective program for improving the quality of testing software but its widespread use is prevented by the difficulties encountered in using them.

16. References O http://www.guru99.com/mutation- testing.html http://www.guru99.com/mutation- testing.html O http://www.uio.no/studier/emner/matnat/if i/INF4290/v10/undervisningsmateriale/INF 4290-Mutest.pdf http://www.uio.no/studier/emner/matnat/if i/INF4290/v10/undervisningsmateriale/INF 4290-Mutest.pdf O http://www.slideshare.net/davidmus/an- introduction-to-mutation-testing- 14040556?qid=2656d999-5229-4d99- 83e0- 55361825562d&v=&b=&from_search=3 http://www.slideshare.net/davidmus/an- introduction-to-mutation-testing- 14040556?qid=2656d999-5229-4d99- 83e0- 55361825562d&v=&b=&from_search=3