Load Testing
Traffic load testing is an important part of any test effort. Many times, I have found problems such as memory leaks and other resource failures that can be extremely difficult to find as part of normal testing. Compilers, development tools and design methodologies have greatly improved but resource leakage and conflicts still occur. Load testing is one of the best ways of identifying such defects.
When I was just getting started, personal computers of the day had just a single CPU. However, the Hicom PBX had many processors. At the time, memory leaks were not uncommon but were only one type of problem encountered when multiple CPU's ran concurrently on a system. Technically, circuit switching was regarded as a sequential task based system. In reality, many of the same issues of concurrancy faced by modern multithreaded languages such as java had to be tested against and load testing was at the time, the best way of accomplishing this.
Ameritech bulk traffic generator. A nearly standard piece of equipment in any circuit switched communications test laboratory
Load testing requires a certain minimum product stability. Therefore, it generally isn't practical to attempt such testing until later in the verification phase of the product development cycle.
A key aspect of traffic generation is repeatability. Another key is to cover as many scenarios as possible. One thing I've noticed over the years is that emphasis tends to be placed on absolute load volume with the same tests being run day after day. This is only of limited value because, if the system ran well last night and nothing changed today, it will run the same calls again tonight without incident.
At Siemens, load testing was done using a variety of off the shelf bulk traffic generators such as made by Ameritec, in-house developed voice and data traffic generators as well as other test equipment which could be programed to repeatedly execute a script or batch of scripts. Analog equivalents of protocol analyzers such as Sage instruments were also capable of repeatedly executing tests.
As is generally the case, nothing is best at everything. Off the shelf traffic generators generally couldn't verify voice paths, all they could do was place and answer calls. Siemens had proprietary equipment that could verify voice paths but it tended to be inflexible and couldn't generate the volume of traffic as off the shelf bulk call generators were capable of. Protocol analyzers could also be set up to place precisely timed calls back and forth to each other but couldn't generate a high volume of traffic.
Instruments such as the Sage box could repeat tests and even send test tones but not in high volume. Administration and maintenance scripts could operate in batch mode to place different type loading on the system. Perl scripts were used to read and parse terminal response and depending on the response, execute diferent batch files containing administrative commands.
The potential existed in late stages of projects prior to field trials to do intelligent load testing. A comprehensive load test team will generally require engineers and equipment from multiple groups. Scheduling the different people and equipment always seemed difficult due to the opportunity cost of what they wouldn't be doing while concentrating on load testing.
On the one or two occasions I can recall such effort being undertaken, team camaraderie was wonderful and results excellent but the difficulty of coordinating so many resources from different groups during project "crunch times" seemed to work against this becoming an established activity.
