It’s easy — almost trivial — to create a custom test suite on the RCG.
An RCG test suite is simply a python script that calls “main()” on a ScriptRunner object. Here’s a short example suite that will run two tests:
|
Our *67 script failed when run in an interop scenario for the first time. It was a pretty obvious failure — our expected CID string should have been all lowercase. No need to modify the script, just edit /etc/rimay/callgen.conf. Find this line: One tricky aspect of getting automated call testing to work properly across different switches and deployments is that different delays and timeouts are required in various places throughout the script library. This is even harder when targeting different international phone systems. For example, when we take a phone port off-hook, we sometimes have to be careful to avoid immediately performing operations on that port. It needs a slight delay when we’re on a VoIP system to give the RTP stream a chance to start. Otherwise if we slam it with DTMF right away we’ll lose a digit or two. On a pure POTS system, we can reduce the delay. Sprinkling these delays throughout the script libraries would be a nightmare… Speed dial 8 is a call feature that allows a subscriber to dial a number using a reduced number of dialed digits. Speed dial is generally a digit between 2 and 9 followed by “#” (pound or hash). Speed dial 8 numbers are usually set by dialing *74 and following the prompts. Let’s outline what the test scripts for speed dial 8 would look like. The bad news is that the bugs that are left are hard to find. Forcing external failures during call generator testing will help flush them out. Sometimes a feature is broken in a way that is not immediately detectable by the call generator. For instance, let’s say some call flow causes a memory leak in the switch. The call will work hundreds or thousands of times, but at some point the entire switch will stop working — and the cause won’t be obvious. You want your switch to crash and burn in your lab, not in the field. Let’s look at three types of robustness testing. 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… |
|
Copyright © 2012 Rimay Technologies, LLC - All Rights Reserved - Follow us |
