home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / software / 3333 < prev    next >
Encoding:
Text File  |  1992-08-31  |  1.7 KB  |  46 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!cs.utexas.edu!milano!cactus.org!wiley
  3. From: wiley@cactus.org (Mark S. Wiley)
  4. Subject: Re: Testing Complex Systems
  5. Message-ID: <1992Aug31.222254.19432@cactus.org>
  6. Organization: Capital Area Central Texas UNIX Society, Austin, Tx
  7. References: <1992Aug31.135414.5265@linus.mitre.org>
  8. Date: Mon, 31 Aug 1992 22:22:54 GMT
  9. Lines: 35
  10.  
  11. In article <1992Aug31.135414.5265@linus.mitre.org> troyer@mitre.org (Tom Royer) writes:
  12. >Given a real-time, embedded, distributed, asynchronous (and all those other
  13. >adjectives that imply complex and difficult) system, how does one go about
  14. >testing the resulting software product to make sure that it really works?
  15.  
  16. Unfortunately, you cannot use testing to make sure the system works, you
  17. can only prove that it processes the test data correctly when the system
  18. is in a particular state.  This will most likely expose some problems in
  19. the system, which can then be fixed, but you still havn't proved the
  20. system works.
  21.  
  22. >
  23. >Functional requirements testing is, of course, necessary, but probing the
  24. >system for the presence (or absence) of race conditions, deadlocks and other
  25. >timing related problems is much, much more.
  26.  
  27. Your best bet is to spend enough time reviewing the system requirements,
  28. design, and code.  For best results, each review should be help as a
  29. particular stage completes, and all outstanding questions should be
  30. resolved before the next stage of the system development begins.
  31. >
  32. >Is it possible to establish a general approach (algorithm?) to testing
  33. >such a system?
  34. >
  35. >If you had to teach novice software engineers how to test such a system,
  36. >what would you tell them?
  37. >
  38. >--
  39. >Tom Royer
  40. >
  41.  
  42.  
  43. -- 
  44. Mark S. Wiley
  45. mark.wiley@cactus.org
  46.