V. P. Singh, "Using a TTCN-3 middleware in TTCN-3 based testing," ETSI TTCN-3 User Conference 2007 Asia: Beijing (China), Oct. 29-30, 2007.
Added by: Deleted user (06 Aug 2008 14:08:58 Europe/Berlin) Last edited by: Deleted user (13 Aug 2008 14:57:45 Europe/Berlin)
|Resource type: Conference Paper
BibTeX citation key: Singh
View all bibliographic details
Publisher: Beihang University, ETSI (Beijing (China))
Collection: ETSI TTCN-3 User Conference 2007 Asia
Views index: %
Popularity index: 1.25%
TTCN-3 has undoubtedly proven itself as a very efficient language that can aid testing. It’s being widely used for all types of black box testing for reactive and distributed systems.
The primary aim of any test system design is to make testing efficient, economical and simple. But as the complexity of the system under test increases so does the complexity of the test system.
For example if one has to test a 3G network element, he has to deal with scores of messages, that deal with a massive data structures, different behaviours, different functionalities etc.
If you are using a TTCN-3 based test system, all this would mean hundreds of templates with a very complex data structures, a pile of PTC’s having there own behaviours, every testcase dealing with scores of incoming and outgoing messages.
To handle all this every time the tester writes a script, he/she has to declare and define the whole data structure, create different PTC’s, implement there behaviours, handle different default behaviours, etc.
Now think about having a middleware where you hide all the complexities that have become a nightmare for the testers and provide them a set of APIs that they would use to write a TTCN-3 test script.
If the tester wants to create a component and connect it to all other components, he can use a simple API to do the same.
If he populates a template, he can use a default template and just fill in the values of different information elements in that default template instead of defining the whole data structure from scratch.
If he has to create a component and connect it to all other components, he can call a simple user friendly API instead of worrying about the syntax of the doing all of this. If he has to send or receive a particular message, he just calls an API without getting bothered about the actual logic behind actual send or receive (match the incoming template, handling erroneous scenarios etc.)
In this presentation I’ll be talking about a middleware which will be a library of functions written in TTCN-3 that would implement algorithms to handle the common behavior of the test system. The middleware simplifies the task of the scripter massively in converting a test MSC into executable TTCN-3 scripts and helps him focusing on the correct translation of the test specification instead of spending time on implementing the test execution logic.
Added by: Deleted user Last edited by: Deleted user