Computaris Top Testing Suite (Full Demonstration)

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.

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

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.


Computaris Top Testing Suite (Full Demonstration)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Ähnlich wie Computaris Top Testing Suite (Full Demonstration)

Ähnlich wie Computaris Top Testing Suite (Full Demonstration) (20)

Mehr von Computaris

Mehr von Computaris (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Computaris Top Testing Suite (Full Demonstration)