home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / software / 5067 < prev    next >
Encoding:
Text File  |  1992-12-21  |  2.2 KB  |  63 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!cs.uiuc.edu!marick
  3. From: marick@cs.uiuc.edu (Brian Marick)
  4. Subject: Re: Value of High Code Coverage Metrics in Testing - Request for Opinion
  5. Message-ID: <BzGut2.1wE@cs.uiuc.edu>
  6. Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
  7. References: <1992Dec14.072812.13689@syacus.acus.oz.au>
  8. Date: Fri, 18 Dec 1992 17:48:38 GMT
  9. Lines: 52
  10.  
  11. I have little to add to the previous answers to this question.  I'd
  12. like to reinforce a couple of points:  
  13.  
  14. - 100% coverage is possible for many programs.  The problem is far
  15. more often test implementation than test design.  A lot of times, a
  16. little test support code in the program can make those implementation
  17. problems tractable.
  18.  
  19. - Coverage is bad at finding the most important class of bugs, faults
  20. of omission.  These are bugs that are fixed by adding code, like the 
  21. following IF:
  22.  
  23.     if (c != 0)
  24.         a = b / c;
  25.  
  26. Designing tests around coverage is not helpful in finding faults
  27. of omission and may be harmful (because it focuses your attention in
  28. the wrong place).  Don't do it.  Design your tests elsewise, then use
  29. coverage as an indirect measure of their quality.
  30.  
  31. - Partial coverage goals (be they 60% or 85% or whatever) are
  32. dangerous.  Given an easy, measurable goal (reach X% coverage) that's
  33. only indirectly related to the true goal (find all the bugs), it's
  34. incredibly easy to blindly achieve the easy goal at the expense of the
  35. true one.  You start with a list of uncovered branches and just go
  36. down the list, writing the easiest possible tests that force them,
  37. until you've hit the required percentage.  Those easy tests are
  38. probably bad.
  39.  
  40. - Other types of coverage besides branch are useful.  In situations
  41. where I would use branch coverage, I use three other types:  loop,
  42. relational, and multicondition.  See the GCT documentation (info
  43. below) for more.
  44.  
  45.  
  46. I've previously posted a description of how I used a coverage tool to
  47. test itself.  I won't post it again, but I'll mail it to anyone who
  48. missed it the first time.
  49.  
  50. Brian Marick, marick@cs.uiuc.edu, testing!marick@uunet.uu.net
  51. Testing Foundations:  Consulting, Training, Tools.
  52. Freeware test coverage tool:  see cs.uiuc.edu:pub/testing/GCT.README
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.