I'm in the process of inserting defects into three pieces of software I've written - for the purpose of creating testing samples for the study. This process is a lot more painful that I would have anticipated. I expect it is due to being trained for so long at removing defects, not deliberately creating them. Every time I break something, I realize the cool test case that will fail because of it, and then I feel bad. Also, trying to create non-obvious errors, or defects that are a little more human than those created by my java mutator, is challenging. For example, consider a class constructor like the following:
public MyAccount(int account, int initialBalance)
{
m_accountNum=account;
m_balance=initialBalance;
}
The mutator would do something like this
public MyAccount(int account, int initialBalance)
{
m_accountNum=account;
m_balance=++initialBalance;
}
following its set of one-line operator rules. I think I a more 'human' error would be something like this:
public MyAccount(int account, int initialBalance)
{
m_accountNum=initialBalance;
m_balance=account;
}
or this:
public MyAccount(int account, int initialBalance)
{
m_accountNum=account;
}
All still valid java programs, but definitely erroneous, and certainly slips that an overworked developer could make. What sets them apart from some of the mutation bugs is that many of the mutation rules require more effort on the part of the developer, rather than less (ie. a ++ at the end of a variable manipulation command is more likely to be omitted than included by accident).
Subscribe to:
Post Comments (Atom)
1 comment:
good article, I am doing a bit on research about bug testing and i found also macrotesting to be very good source.
Thanks for your article
Regards,
Prem
Post a Comment