Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcdc!hpislx!hplvli!boyne
From: boyne@hplvli.HP.COM (Art Boyne)
Newsgroups: comp.lang.c
Subject: Re: Re: How do I get random #s?
Message-ID: <340008@hplvli.HP.COM>
Date: 17 Feb 89 14:35:57 GMT
References: <510@jhereg.Jhereg.MN.ORG>
Organization: Loveland Inst. Div
Lines: 29

albaugh@dms.UUCP (Mike Albaugh) writes:

>From article <5260010@hplsla.HP.COM>, by jima@hplsla.HP.COM (Jim Adcock):
>> For example, we frequently use random numbers to test software,
>> using the random numbers to choose from the various commands that
>> our software implements, with randomly selected parameters,
>> in random order.  Its very nice to use this technique to 
>> find software bugs, fix the bugs, then re-run the random command
>> generator software with the same seed as a regression test.
>> Can't do this with a combined hardware/software scheme.
>
>	I would think that a better approach would be to generate the
>whole stream ahead of time (with timings info as to _when_ commands
>are entered), or to log it (again with timestamps) as it is generated.
>Then a hardware, software, or "thousand monkeys" (software test group
>of "naive users") method can be used at will, and re-play for regression
>testing would be a snap.

Sorry, Mike, but I agree with the original poster (Jim Adccock), and NOT
because I happen to work for the same company (different division, though).
Having a set of pre-defined commands with timing is necessary, and allows
you to test most corner cases, but random command/parameter combinations DO
catch a lot of "Gee, I never would have tried THAT" type bugs.  And sending
those commands at random time intervals, especially things like Device Clear
over IEEE-488 (GP-IB), is a good way to catch races and unprotected critical
code sections.  Using a fixed starting random number seed make the test
repeatable.

Art Boyne, boyne@hplvla.hp.com