Computaris Top Testing Suite (Full Demonstration)

Computaris TOP Testing Suite – Full Demonstration Video v1.0 – Narration Text

At The Core

At the heart of Computaris TOP Testing Suite is JMeter – a

Java-based testing framework – providing the logic for

defining, managing and handling test plans. Various plug-ins

enable testing a full range of standard Telecom protocols.

Other protocols can be added as required. All systems under

test can be automatically and dynamically tested as black

boxes using a convenient graphical user interface enabling

operators to work out any test scenario, varying from very

simple to most complex.


Testing A Telecom Framework

TOP Testing Suite is a suite of testing tools providing

operators enhanced capabilities to comprehensively test

end-to-end telecom services. The suite can be used to

thoroughly test the communication path between originating

and terminating mobile devices all the way down to the

subscriber databases of a Telecom operator. TOP Testing

Suite can simulate CORBA network traffic originating from for

example Billing & Charging systems, Diameter traffic

originating from Service Control Points and CAMEL messages

from Mobile Switching Centers. This video will show you

how to apply CORBA and Diameter samplers for testing a

billing and charging server, a subscription manager, a rating

engine, an account manager and an offline billing server.


Test Plan - Flow Chart DEMO

The test plan works out a prepaid and a postpaid scenario

using CORBA and Diameter samplers. First the subscriber

IMSI is fetched from the CSV file. Based on the received IMSI

number subscriber information is fetched from the

subscription manager. For a prepaid subscriber a rate event is

issued to the rating engine to fetch the subscriber’s initial

balance from the account manager. To check whether the

balance is sufficiently high for using the requested service a

Diameter session with the online billing and charging server is

set up. As a last step of the prepaid scenario the subscriber’s

final balance is fetched from the account manager. For a

postpaid subscriber the postpaid scenario will be executed in

which the offline billing server will be updated with a call

detail record. Finally a brief status report will be written to an

output file.


Add Configuration Elements

To shorten the demonstration all elements of the final test

plan have already been prepared on the workbench from

where they will be successively added to the test plan. The

first element moved to the test plan is added as a child; the

subsequent other elements are inserted directly after the

child element. Elements can be simply added by dragging and

dropping them from the workbench onto the test plan. The

CORBA configuration element contains reference information

about the CORBA server under test and is contained in four

IDL files defining the account manager, the billing server, the

rating engine and the subscription manager. IDL files can be

added by clicking the file open icon. However all required IDL

files have already been added so there is no need for adding

more. For the configuration of the Diameter plug-in three

values are most important: the hostname or IP address of the

Diameter peer server under test, its port number, and the

local port number. A counter element is used for serving the

Diameter protocol and its value will be used further on in the

test plan for calculation of the Diameter session IDs. The last

configuration element defines the name of the external CSV

data file, the internal variables TOP uses for containing the

data, and the type of delimiter used for separation of the

data. As you can see the CSV file used for the test comprises

the IMSI numbers of five subscribers and for each of them an

event ID.


Fetch Subscriber Data

First a thread group is added to contain all elements of the

test plan. The first element added to the thread group is a

logical controller comprising two dummy samplers. The first

dummy sampler is used in case the test plan is configured to

load the subscriber data from an external CSV file. The

sampler defines two variables to store the data. The first

variable copies the IMSI number, the second variable stores

the event ID. The relation between the two variables and the

contents of the CSV file is defined in the CSV Data

Configuration element that we have defined earlier. The

second dummy sampler is used when the test plan is

configured to load the subscriber data from user defined

variables. The first variable contains the IMSI number. The

second one contains the event ID. Their values are defined at

test plan level using three user defined variables. The first

one is a Boolean variable to determine whether or not to load

the data from an external CSV file. A second variable contains

the event ID and a third one is used to hold the IMSI number.

Their values are internally made available to all threads at the

start of a test run.


Fetch Subscriber Info


Fetch Subscriber Info

To fetch the subscriber info from the subscription manager a

CORBA Sampler is applied. The sampler stores the subscriber

info, the MSISDN number, the prepaid flag and the tariff ID as

subscriber information in separate variables. The CORBA

sampler uses an IDL file describing the interface with the

subscription manager. From this file we choose the module,

the interface and the CORBA method for accessing the

subscription manager.

The value of the IMSI input variable can be entered manually

but in this demo we copy the value from an external CSV file

using the IMSI variable that we have defined earlier. The

CORBA sampler is appended with a delay timer inserting a

pause after execution of the sampler.


Rate Event


Rate Event

Rating is the first step of the prepaid scenario. The Rate Event

CORBA sampler is therefore the first sampler of the If Prepaid

Controller group. The IDL file describing the CORBA interface

of the rating engine contains a method called Rate Event

which is used to send the event ID and the tariff ID to the

rating engine. The rating engine replies by returning the price

of the requested event. The price is stored in a dedicated

variable. Directly after the rate event sampler a timer is

appended establishing a time delay immediately after

execution of the sampler. The time delay is defined as a user

defined variable which value can be manually entered at test

plan level.


Fetch Initial Balance


Fetch Initial Balance

To fetch the initial balance from the account manager a

CORBA sampler is applied. The IDL file describing the CORBA

interface of the account manager contains a method called

Get Account Info which is used to send the MSISDN number

to the account manager in exchange for the account

information and the initial balance. The received account

information and initial balance are stored in dedicated

variables. After the data exchange with the account manager

a time delay is applied.


Prepare Diameter Sessions

To prepare a diameter session two variables are used; a

variable to contain the Session ID and another one to contain

the event time stamp.

The session ID is comprised of the originating host name, a

time stamp and a unique sequence number derived from the

counter that we have defined earlier as one of the

configuration elements.

The session ID is used as the first AVP in all diameter requests

to indicate that subsequent requests belong to the same

charging session.

The event time stamp uniquely identifies the occurrence in

time of an event.


Send Initial CCR


Send Initial CCR

To check if the subscriber’s account balance is sufficiently

high for using the requested service an initial CCR message is

send to the billing and charging server in exchange for a CCA

message containing the result of the interrogation.

To interrogate the billing and charging server a Diameter

sampler is used. The message type to be exchanged is

selected from the message drop down box; here we choose

the credit control request message type. Using TOP Testing

Suite Diameter samplers can be freely configured by adding

new attribute-value-pairs as children or siblings.

To demonstrate the ease of adding AVPs a new AVP will be

added as a sibling. Simply right click on an existing AVP and

select add sibling from the context menu. The type of AVP

can be chosen from a drop up box. AVPs can be manually

given a value from the value field. Some types of AVP’s have

predefined values which can be chosen from the Possible

Values drop up box. New values are accepted by clicking on

any of the AVPs.

The result of the interrogation with the billing and charging

server is stored in the Result Code variable. The Diameter

sampler is appended with a timer delay which value can be

manually entered from the corresponding user defined

variable.


Reusing Variable Values

Values received or created by any of the samplers can be

reused at any place elsewhere in the test plan. For example

the MSISDN number which was fetched from the subscription

manager using a CORBA sampler, and stored in a dedicated

variable using the fetch subscriber info CORBA sampler, is

reused by a Diameter sampler as an input value to the billing

and charging server.

Another example is the price variable received by the Rate

Event CORBA sampler which is reused in the same Diameter

sampler as part of the Unit Value AVP.


Termination CCR


Termination CCR

Two Diameter samplers are applied for issuing termination

messages.

The first CCR termination sampler is contained in an IF

controller which is used to check if the subscriber’s balance is

sufficiently high.

The Diameter sampler is configured to send a termination

CCR message with used service unit to the billing and

charging server in case the subscriber’s balance has been

proven to be sufficient. The used service unit contains the

price as received from the rating engine. The sampler stores

the result code of the termination message exchange in a

separate variable making it available for usage elsewhere in

the test plan. The sampler is appended with a timer delay.

The second Diameter sampler is contained in another IF

controller and is executed in case the subscriber’s balance is

not sufficient. This Diameter sampler is configured to send a

termination CCR without used service unit to the billing and

charging server.


Fetch Final Balance and Check Result


Fetch Final Balance and Check Result

To fetch the subscriber’s final balance from the account

manager a CORBA sampler is applied. The received CORBA

data is stored in two variables; a variable for storing the Final

Account Information and a variable for storing the

subscriber’s final balance.

The last sampler of the prepaid flow is a Bean Shell sampler

which is used to perform a final check on the results using

JavaScript. The script can contain any of the variables that

have been defined earlier in the test plan. The sample code

here reuses the variables for the Initial Balance, the Final

Balance and the Price.

The checked result is OK if the expected final balance equals

the fetched final balance.

At the end of the prepaid scenario the status results are

written as a text string to a variable which contents will be

contained by an external text file, showing a separate status

line for each prepaid subscriber.


Store CDR Data in Billing Server


Store CDR Data in Billing Server

To write a call data record to the offline billing server a

CORBA Sampler is applied. For the configuration of the

CORBA sampler the IDL file describing the billing server is

used.

From this file we use the store CDR method to transfer the

values of four variables to the offline billing server; the

MSISDN number of the originator, the destination number of

the terminating device, the event ID triggered by the

originator, and the time stamp of the event. The postpaid

scenario is also appended with a timer delay.

And just as for the prepaid scenario the postpaid results are

written to an external text file to contain a separate status

line for each postpaid subscriber.


Add Listeners

TOP Testing Suite provides various listeners which are used

for gathering information during a test run. Depending on

your needs you can choose the appropriate set of listeners

allowing you to view the test results in several formats. For

this demonstration we have used six listeners; to respectively

view the CORBA test results in tabular format, all results in

the form of a tree or a table, a summary report briefly

presenting significant statistics, and two different listeners

dedicated to the Diameter results.


Test Run in Simulator Environment

With the number of threads set to five, choosing start from

the run menu triggers the execution of the test plan. The test

results are immediately displayed in the test environment

simulator. The generated test results can also be monitored

online from any of the listeners. Here we choose to view the

results from the CORBA Results Table listener. The simulator

shows the successive results generated by the CORBA and

Diameter samplers as received from the subscription

manager, the rating engine, the account manager and the

online and offline billing and charging servers. Consulting the

listeners we can view details about all performed CORBA and

Diameter message exchanges.


View CORBA Results

After a test run the test results are directly available from the

listeners. In this demonstration the CORBA results are taken

from the CORBA Results Table listener. This listener provides

for each CORBA sample the sample number, the time stamp,

the status of the message exchange and the name of the

corresponding sampler. Clicking on a sample displays details

about the CORBA request and response messages, such as

the module, the interface and the method used for making a

request - and the names and values of the parameters that

were involved in the message exchange.


View Diameter Results

To trace the Diameter results we have used two dedicated

listeners.

The Diameter Messages listener shows details about all

Diameter messages that were exchanged during the test run

starting with the initial CER request and answer messages for

setting up a Diameter session, followed by the 12 initial CCR

and termination messages of the prepaid message flow. You

can view information about the exchanged Diameter

attribute-value-pairs by expanding the message tree.

The Diameter View Results listener provides an alternative

view on the same Diameter messages, but focuses on the

messages of the Diameter samplers that were actually

involved in the execution of the test plan. For each Diameter

sampler the contents of the exchanged request and response

messages can be viewed from separate tabs. For example the

used service unit that was issued in a CCR termination

message can be viewed. By expanding the tree you can view

for example the contents of the USU that was exchanged in

one of the termination messages.


View Results Overview

Three extra listeners have been added to the test plan

each of them giving an alternative view on the test results.

The Summary Report listener displays a tabular overview

with statistical information about the network traffic

generated by each test element, such as the number of

samples, the average, minimum, maximum and standard

deviation of the values exchanged, the throughput in

messages per time unit, the number of kilo bytes per

second and the average number of bytes exchanged.

The View Results in Table listener shows a chronological

and brief statistical list of test elements that were

executed during the test run. For each element details

about the generated traffic are available from separate

columns.

As opposed to the previous listeners the View Results Tree

listener provides a view on the contents of the messages.

For each sample the contents of the request and response

messages are displayed on two separate tabs. A third tab

shows statistics about the sampler result. Depending on

your preference the response data can be viewed in

different formats: as plain text, as HTML, as XML or in

Javascript Object Notation (JSON).


View Results Overview

And finally the results of the test run are written to an

external text file showing the results of the five threads. The

file contains a status line for each subscriber displaying the

processed IMSI and MSISDN numbers, and the result of the

performed test.


Conclusion

TOP Testing Suite’s key features are its scalability, extensibility

and usability. Its technical features make it a robust, cost-

effective, convenient and user friendly telecom testing

solution that can be deployed at any stage of the product

development and deployment process. Computaris TOP

Testing Suite shifts control to the operator making it a

beneficial tool for the CSP community. Likewise, the suite

offers software houses and telecom vendors an efficient, agile

and profitable tool to easily and comprehensively test a wide

range of telecom protocols.

Technology

Computaris Top Testing Suite (Full Demonstration)