The “Million Monkeys” approach to testing is the equivalent of handing your system to a bunch of monkeys, letting them bash on the handset for a while, and then seeing what happens. You hope that their random behavior will exercise some path that your carefully planned tests failed to hit. You can discover interesting bugs this way, before giving your product to actual monkeys customers. The biggest drawback of this strategy is that, because of the random nature, when an error occurs, it may be hard to reproduce.
We can do Million Monkeys testing with a simple call script.
The script takes a line assignment from the command line. It then enters a loop. Each time through the loop, it randomly decides to either wait for a call or make a call.
If it is making a call, it dials one of the other lines at random, waits for tones (or a busy signal) from the callee, echoes back the tones, and hangs up.
When it waits for a call, it waits for 30 seconds for ringing. If no ringing occurs, it goes back into the loop to decide whether to make a call or wait for another call. If there is ringing, it answers, plays a series of DTMF tones, waits for the tones to be echoed back by the caller, and hangs up.
We can run four instances of this simple script, one for each line on our most basic call generator, and let it exercise a variety of call pairings, busy and non-busy lines, etc. If we make sure that our logging is sensible, we can use the logs in case of failure (e.g. crashes) to try to perform the last several calls that may have led to the error.
Related posts:
