home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / software / 3328 < prev    next >
Encoding:
Internet Message Format  |  1992-08-31  |  1.5 KB
  1. Path: sparky!uunet!icd.ab.com!iccgcc.decnet.ab.com!kambic
  2. From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
  3. Newsgroups: comp.software-eng
  4. Subject: Re: Testing Complex Systems
  5. Message-ID: <1992Aug31.152326.8770@iccgcc.decnet.ab.com>
  6. Date: 31 Aug 92 15:23:26 EST
  7. References: <1992Aug31.135414.5265@linus.mitre.org>
  8. Lines: 28
  9.  
  10. In article <1992Aug31.135414.5265@linus.mitre.org>, troyer@mitre.org (Tom Royer) writes:
  11. > Given a real-time, embedded, distributed, asynchronous (and all those other
  12. > adjectives that imply complex and difficult) system, how does one go about
  13. > testing the resulting software product to make sure that it really works?
  14. > 
  15. > Functional requirements testing is, of course, necessary, but probing the
  16. > system for the presence (or absence) of race conditions, deadlocks and other
  17. > timing related problems is much, much more.
  18. > 
  19. > Is it possible to establish a general approach (algorithm?) to testing
  20. > such a system?
  21. > 
  22. > If you had to teach novice software engineers how to test such a system,
  23. > what would you tell them?
  24.  
  25. Gee, such a nice theoretical problem with no practical implications.
  26.  
  27. Seriously though, I don't think that you can treat this subject in a vacuum. 
  28. In order to begin the discussion, do you have some assumptions about the level
  29. of documentation?  What are the "generalized" risk levels of each of the
  30. strange adjectives that you noted above?  What do we "know" about the process
  31. of development? 
  32.  
  33. Here goes a long thread.
  34.  
  35. George Kambic
  36. sd
  37.  
  38.