On Mon, 25 Oct 2004 09:03:20 EDT, David Brodbeck said: > This has been a basic pet peeve of mine for years -- even before web > browsers came on the scene. How many times have you seen a word processor > crash due to an unfortunate sequence of commands or opening a corrupted > file, for example? I think that kind of behavior is just unacceptable. > Software should be able to deal with any input that's thrown at it. Two quotes come to mind: "A program designed for inputs from people is usually stressed beyond breaking point by computer-generated inputs. -- Dennis Ritchie Yes, "should be able to deal with anything" *is* a laudable goal. On the other hand, there's a (presumed) requirement that the software actually *SHIP* sometime before the thermal death of the universe - which means that the person who has to make the decision on when/whether to ship has to decide whether the ship date should be slipped *another* 3 months just because some automated test program found that the package will crash if it gets requests from a prime number of dolphins (the ceteans, not the football players) in the same 4-second interval. Tough call - since *you* only know about it because some pseudo-random tester found it, it's probably not easily found - and you *do* need to ship this quarter or not make payroll. *NOW* what do you do? And if *that* judgment call was too easy, here's the second quote: "Testing can prove the presence of bugs, but not their absence" -- E. Dijkstra How do you actually prove a program bug-free? Remember - the automated tester might not catch the prime-of-ceteans bug because *that* software's designer never thought to cover that case (which is in itself a bug in THAT program), so now you need to cover *all* the corner cases you can think of: Prime numbers of ceteans, prime numbers of octopi, composite numbers of each, and attacks by chipmunks armed with RFI wands that corrupt packet checksums. Oh, and you're not allowed to forget to test for a case. ;) (If you think this is easy - read the entire end-user and administrator documentation for a recent release of Apache. Try to itemize *all* the things that could possibly go wrong. Then, once your brain turns to mush and you can't think of any new ones, look over all the security-critical bugs that Apache *has* had, and see if your list would have caught *every* *single* *one*.)
Attachment:
pgpg1lhIiK0wP.pgp
Description: PGP signature