home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / software / 3339 < prev    next >
Encoding:
Text File  |  1992-09-01  |  3.4 KB  |  69 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!sdd.hp.com!ux1.cso.uiuc.edu!m.cs.uiuc.edu!marick
  3. From: marick@m.cs.uiuc.edu (Brian Marick)
  4. Subject: Re: Testing Complex Systems
  5. Message-ID: <1992Sep1.195925.29101@m.cs.uiuc.edu>
  6. Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
  7. References: <1992Aug31.135414.5265@linus.mitre.org>
  8. Date: Tue, 1 Sep 1992 19:59:25 GMT
  9. Lines: 58
  10.  
  11.  
  12. If you want to test for locking bugs (deadlocks, races, etc.) in an
  13. existing system, here is an effective procedure that's reasonably
  14. cheap.  Other people's comments about attacking the problem at the
  15. design level of course also apply.  Especially important is adding
  16. testing support to the system.
  17.  
  18. 1.  Enlist the active support of a senior developer, someone who knows
  19. the system well and helped develop it.  Have them tell you the areas
  20. of the system that are likely to be buggy.  If you have a bug history,
  21. use that too.  You are looking for chunks of code to target.
  22.  
  23. 2.  You will need a stress driver, one that can run many copies of a
  24. particular test in parallel.  Spend some effort designing a prototype.
  25. Don't get so wrapped up in that that you never get around to writing
  26. tests.  Your testing experience will certainly cause major revisions
  27. to the driver, no matter how good a design you think you have.
  28.  
  29. 3.  Find a workload that roughly approximates "normal use" of the
  30. system.  It doesn't have to match normal use exactly - even if such a
  31. thing were possible - but it should exercise all the major parts of
  32. the system.  For UNIX, MUSBUS/KENBUS aren't bad, though they have some
  33. holes.
  34.  
  35. 4.  Take your list of shakiest system components.  Pick the top few.
  36. Test them in order of severity:  in which ones will a crash or hang do
  37. the most harm to a customer?
  38.  
  39. 5.  If you test your system through use (easy to do with the UNIX
  40. kernel, harder with embedded systems), winnow the list by measuring
  41. what normal use does (see below).  Don't write special tests that
  42. present the same system load as 15 programmers writing code.
  43.  
  44. 6.  For each component, write a test that exercises it.  You are most
  45. concerned with the main paths through the component.  If you are not
  46. experienced in the use and internals of the system, the senior
  47. developer will be invaluable in helping you write sensible tests (that
  48. exercise the component well).  
  49.  
  50. 7.  Run N copies of the test alongside the background workload.
  51. The tests target the component you chose; the background workload will
  52. help find bugs that are interactions between that component and the
  53. rest of the system.   Be careful not to make N so large that the
  54. system thrashes; this concentrates the stress in too-small an area,
  55. often not the area you're concerned with, and tends to find
  56. "unrealistic" bugs (though not so much as you'd think).
  57.  
  58. 8.  Measure what your tests do.  For this type of testing, a good
  59. approximate measure is how often routines in the component of interest
  60. are entered while another processor/thread is already in them.  (See
  61. my .signature for a tool that measures this.)  Don't be surprised when
  62. your tests don't stress what you think they're stressing, when they
  63. get bottlenecked in some other part of the system.  You can also use
  64. coverage to tune the resources you devote to a test.
  65.  
  66. Brian Marick, marick@cs.uiuc.edu, uiucdcs!marick, marick@testing.com (pending)
  67. Testing Foundations:  Consulting, Training, Tools.
  68. Freeware test coverage tool:  see cs.uiuc.edu:pub/testing/GCT.README
  69.