home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / software / 4951 < prev    next >
Encoding:
Text File  |  1992-12-14  |  1.5 KB  |  38 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!noc.near.net!mv!jlc!john
  3. From: john@jlc.mv.com (John Leslie)
  4. Subject: Re: Value of High Code Coverage Metrics in Testing
  5. Message-ID: <1992Dec14.200333.5592@jlc.mv.com>
  6. Organization: John Leslie Consulting, Milford NH
  7. References: <1992Dec14.072812.13689@syacus.acus.oz.au> <ssimmons.724336081@convex.convex.com>
  8. Date: Mon, 14 Dec 1992 20:03:33 GMT
  9. Lines: 27
  10.  
  11. paulb@syacus.acus.oz.au (Paul Bandler) writes:
  12.  
  13. > One of the metrics I have been asked to measure is the 'Branch Flow
  14. > Analysis' (BFA) percentage achieved during unit and system testing.
  15. > i.e. How much of the potential paths through the code is actually
  16. > excersized during these testing phases.
  17. >
  18. > 1)  Do people think that this is a valuable metric?
  19. > 2)  Is it a cost effective excersize to get engineers to achieve a particular
  20. >     %BFA as a completion criteria?
  21. > 3)  What is a realistic %BFA to aim for?
  22.  
  23.    1) Yes; 2) Yes; 3) 100%.
  24.  
  25.    Totally untested code should not be let out the door.  If a particular
  26. branch of the code cannot be tested, it deserves to be removed.
  27.  
  28.    OTOH, maybe you're proposing to enumerate all branches and count the 
  29. combinations of them which have been tested.  This idea is quite useless.
  30. In a modern object-oriented GUI system, the number of possible combinations
  31. exceeds the capacity of today's computers to count.
  32.  
  33.    There is a middle ground, wherein each branch would be tested in each
  34. "state" of the system.  This sounds very promising to me, but I haven't yet 
  35. seen it done in practice.
  36.  
  37. John Leslie <john@jlc.mv.com>
  38.