Home > Archive > Software Testing > September 2005 > Mutation testing?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
|
| navin.del@gmail.com 2005-09-22, 4:00 am |
| In my openion Mutaion testing is a white box testing ...
Here we test the same teste cases with diffrent mutants ..
such as Constant replacement , Arithmatic operators replacement ,
retional operators replacement and go to lebel replace ment ..
here we check that after this changes(replacements ) , only mutation
fails and rest programe is working as earlier ..then it is ok ..
for ex - if there is a statment c=x+y-l/j
so we will check it to replace + insted of - , and x instedof c etc.
hope u get it ..
regards ..
naveen
| |
|
| I've heard of "weak mutation" testing in the context of determining
test coverage.
If I recall correctly, the idea is that if the code says something like
if (a<=b){
foo;
}else{
bar;
}
then, in order to satisfy the 'weak mutation' coverage criterion, you
need to include these test cases:
- a is 'epsilon' less than b
- a equals b
(and it would be a good idea to have
- a is significantly less than b
- a is significantly greater than b
just on principle.)
Note that by 'epsilon' here, I mean a generalized epsilon-like thing.
If a and b are integers, then 'epsilon' is 1. If a and b are doubles,
then 'epsilon' is the traditional epsilon of approx 2.22e-16. And so
forth.
Looking carefully at the results of these two cases will help you
ensure that the developer should not have intended to say
if (a<b){
foo;
}else{
bar;
}
or
if (a==b){
foo;
}else{
bar;
}
Now, extrapolating from this definition of 'weak mutation', presumably
'(strong) mutation' means writing test cases that would expose whether
the developer should have intended any of a number of different wacky
'mutations' of the given source code.
For example, we might write tests that would have had different results
in a number of crazy scenarios:
- if the developer had typed aa instead of a, bb instead of b, etc. (if
those similar variable names exist).
- if the developer had typed b<=a instead of a<=b
- if the developer had typed
if (a<=b){
foo;
}
bar;
etc. etc. etc. we could go forever like this.
As you can probably tell, reading between the lines, I don't think this
"strong" form of mutation testing is good bang for the buck. You're
probably better off establishing some code style guidelines to prevent
the most common problems in your language (for example the classic =
vs. == problem in C), and then doing good solid code review to get the
same result that would otherwise take a major amount of test writing to
achieve.
As always when I wade into a question that involves the definition or
common usage of a term, I'm dead certain that there will be other
opinions or "authoritative" sources about what the term means, so use
my input with caution.
--JMike
| |
|
| On Wed, 21 Sep 2005 ahamadk1@gmail.com wrote:
> Hi,
> What is Mutation testing?
Mutation testing is when you make slight modifications to a program being
tested. The modifications would be a small, syntactic change.
Originally, this technique was conceived as a way to evaluate a set of
tests. It is now used as a technique for testing the application as well.
The underlying assumption is that by injecting a program with a small
mutant and writing a test case to find it, more complex, real faults will
be found.
--
Send e-mail to: darrell dot grainger at utoronto dot ca
| |
|
|
| xtremetester 2005-09-26, 7:05 pm |
| Mutation testing. A testing strategy where small variations to a
program are inserted (a mutant), followed by execution of an existing
test suite. If the test suite detects the mutant, the mutant is
'retired.' If undetected, the test suite must be revised. [R. V.
Binder, 1999]
See more in Software testing vocabulary
on http://www.geocities.com/xtremetest...Dictionary.html
|
|
|
|
|