How to Get More Complete Test Coverage

We recently added a simple feature that makes it easier to achieve more thorough coverage automatically.

On the RCG, the config file that maps a physical port to the named port you use in a script is called portmap.conf. You can have multiple mappings configured in the file, each with a unique name. And you can choose between which portmap is active when you launch a test suite. In our upcoming release, you can list multiple portmaps on the command line.

You can run a custom test suite to be run with various port combinations — kick off an three hour long test suite with ten different portmaps on Friday evening and not have to worry about relaunching the test, touching config files, or changing cables every few hours over the weekend.

Click here to read this article…

Customizing the Test Suites on the Rimay Call Generator

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:

Click here to read this article…

Why Do Experts Plan For Failure?

The goal of testing is finding failures, right?

Then we should plan for the inevitable failure and make sure we are going to gather as much information as possible. When you are armed with all the right info, you will be able to find the root cause and develop a fix quickly and easily. Otherwise testers and developers wind up in an endless cycle of “can you retest it and capture X?” Half the battle — usually more than half — is simply reproducing the problem and figuring out what is really broken.

We’ve built a great feature into the RCG-4001. It captures, for every test:

Click here to read this article…

Quick Fix for CID Test Failure

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:

Click here to read this article…

Tunable Call Delays on the Rimay Call Generator

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…

Click here to read this article…

Troubleshooting Telephony Failures

When a telephony call feature is failing, there are several possible categories of causes. The early stages of troubleshooting should try to eliminate some of these broad categories as causes (or find the cause along the way, whichever happens first).

Click here to read this article…

How to Write Test Scripts for Speed Dial 8

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.

Click here to read this article…

Step Outside the Call Generator to Force More Failures

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.

Click here to read this article…

Induce Failures by Varying the DTMF Pulse Width

Looking for ideas to find bugs? Configure your call generator to run your entire test suite with DTMF tones near the minimum width.

Click here to read this article…

Use a Call Generator for Robustness Testing

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.

Click here to read this article…

Articles