If you can reproduce the bug by hand, you can script the call generator to force it. Even if it is hard to reproduce reliably, it may be easy to force it every time with the help of automation.
|
If you can reproduce the bug by hand, you can script the call generator to force it. Even if it is hard to reproduce reliably, it may be easy to force it every time with the help of automation. There are a huge number of possible test cases for even a relatively simple telephony feature when multiple interop combinations are involved. How do we manage all of this? The distinction between chaining and stacking is maybe too subtle but I think of them differently when planning tests. “Chaining” is what I call it when a test repeatedly invokes a single feature in a single call flow. 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. The most interesting tests poke at a couple of features at a time. For example, take Call Forward when Busy and Call Waiting. When CFB is active, does CW happen? If so, does caller D get forwarded when he calls A who is already talking to B and C in a CW call? Call Park is a Centrex-type feature. You can use Call Park to place an active call on hold and then resume the call from any other Centrex extension. Following the basic strategy for call tests I outlined previously… The basic strategy is fairly simple: figure out how the call flow should work, define the variations, and then code it. |
|
|
Copyright © 2012 Rimay Technologies, LLC - All Rights Reserved - Follow us |
|