Donald Knuth is many times referred to as one of the fathers of computer science. He is also known as a stickler when it comes to bugs in his code (and in his books. He sends checks to readers who find errors in his books!). Anticipating the unexpected is one of his techniques. Think the way Knuth does when you write your test cases. Be mean and nasty!
My test programs are intended to break the system, to push it to its extreme limits, to pile complication on complication, in ways that the system programmer never consciously anticipated. To prepare such test data, I get into the meanest, nastiest frame of mind that I can manage, and I write the cruelest code I can think of; then I turn around and embed that in even nastier constructions that are almost obscene.
Think diabolically! Think of every possible thing a user could possibly do with your system to demolish the software. You need to make sure your program is robust – in that it can properly respond in the face of erroneous user input. This type of testing is called robustness testing, whereby test cases are chosen outside the domain to test robustness to unexpected, erroneous input, and is included in defensive testing which includes tests under both normal and abnormal conditions. Look at every input. Does the program respond “gracefully” to these error conditions?
My test programs are intended to break the system, to push it to its extreme limits, to pile complication on complication, in ways that the system programmer never consciously anticipated. To prepare such test data, I get into the meanest, nastiest frame of mind that I can manage, and I write the cruelest code I can think of; then I turn around and embed that in even nastier constructions that are almost obscene.
Think diabolically! Think of every possible thing a user could possibly do with your system to demolish the software. You need to make sure your program is robust – in that it can properly respond in the face of erroneous user input. This type of testing is called robustness testing, whereby test cases are chosen outside the domain to test robustness to unexpected, erroneous input, and is included in defensive testing which includes tests under both normal and abnormal conditions. Look at every input. Does the program respond “gracefully” to these error conditions?
- Can any form of input to the program cause division by zero? Get creative!
- What if the input type is wrong? (You’re expecting an integer, they input a float. You’re expecting a character, you get an integer.)
- What if the customer takes an illogical path through your functionality?
- What if mandatory fields are not entered?
- What if the program is aborted abruptly or input or output devices are unplugged?
No comments:
Post a Comment