home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / software / 4400 < prev    next >
Encoding:
Text File  |  1992-11-19  |  3.5 KB  |  75 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!cs.uiuc.edu!marick
  3. From: marick@cs.uiuc.edu (Brian Marick)
  4. Subject: Re: Test Completion Criteria
  5. Message-ID: <Bxyzuz.G2r@cs.uiuc.edu>
  6. Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
  7. References: <1efq9dINN5ps@griffin.orpington.sgp.slb.com>
  8. Date: Thu, 19 Nov 1992 15:47:22 GMT
  9. Lines: 64
  10.  
  11. monteiro@edda.nl (Francisco Monteiro,207) writes:
  12.  
  13. > One of the most difficult question to answer when testing a program is
  14. > determining when to stop, since there is no way of knowing if the
  15. > error just detected is the last remaining error. What criteria is the
  16. > common for industry, as the ones i know of are both meaningless and
  17. > counterproductive.
  18.  
  19. They're all meaningless, mostly, but that doesn't mean they're
  20. counterproductive.  
  21.  
  22. 1. Most common?  Probably estimated completion times based on past
  23. experience with similar projects and similar people.  Seems terribly
  24. imprecise, but can work well.  Read Scott MacGregor's postings - he
  25. has good things to say on this and related topics.
  26.  
  27. 2. Also common?  Path-based coverage measures.  80% or 85% branch
  28. coverage is a typical stopping criterion.  These measures are
  29. meaningless without context.  Both I and a novice tester can reach 95%
  30. coverage, but I guarantee my tests will be better, because I know a
  31. lot more about test design.  I use coverage as a stopping criterion,
  32. but the actual percentages are of only passing interest.  Rather, I
  33. look carefully at each branch (etc.) that I missed, ask why my test
  34. design missed it, asked what else "nearby" my test design missed, and
  35. make a judgement about whether I need more tests (almost always
  36. deciding that I do).
  37.  
  38. 3. Fault-based coverage measures, most particularly mutation coverage,
  39. can guarantee the absence of certain kinds of faults in your program
  40. (modulo the chance of your making a mistake detecting equivalent
  41. mutants).  Mutation testing is somewhat expensive, and it doesn't
  42. offer guarantees about all other kinds of faults in your program.  In
  43. particular, I don't know of any studies about how well a
  44. mutation-complete test suite detects faults of omission (to my mind
  45. the most important class of faults).
  46.  
  47. 4. Statistical testing does offer a stopping criterion: stop when the
  48. predicted mean-time-to-failure reaches a threshold.  The problem is
  49. that the prediction is relative to a particular input distribution.
  50. Capturing an input distribution is hard.  Dealing with different users
  51. with different input distributions is hard.  I've been hearing that
  52. statistical testing / reliability people are now fiercely grappling
  53. with these issues, and I'm optimistic that they'll improve the state
  54. of the practice.
  55.  
  56. 5. Given requirements or specifications in a rigorous format, you can
  57. generate a set of tests by (for example) cause-effect testing rules.
  58. Implement those tests, and you're done.  But the sufficiency of the
  59. generation procedure is certainly open to question.  
  60.  
  61. 6. You can seed "representative" errors and stop only when your tests
  62. have detected all seeded errors.  However, like mutation testing, the
  63. kinds of errors you can practically seed are only a smallish subset of
  64. the total kinds of errors.  Also, seeded errors are not necessarily as
  65. hard (or as easy) to detect as native errors.  (At least one study has
  66. found that they're not.)
  67.  
  68. So:  no hard and fast stopping criteria.  A lot of life is like that.
  69.  
  70. Brian Marick, marick@cs.uiuc.edu, testing!marick@uunet.uu.net
  71. Testing Foundations:  Consulting, Training, Tools.
  72. Freeware test coverage tool:  see cs.uiuc.edu:pub/testing/GCT.README
  73.  
  74.  
  75.