TTCN-3 Bibliography
TTCN-3 Bibliography |
|
 |
 |
 |
|
Singh, V. P. 2007, October 29–30, Using a TTCN-3 middleware in TTCN-3 based testing. Unpublished paper presented at ETSI TTCN-3 User Conference 2007 Asia, Beijing (China). Added by: Deleted user (06/08/2008, 14:08) Last edited by: Deleted user (13/08/2008, 14:57) |
| Resource type: Conference Paper BibTeX citation key: Singh View all bibliographic details  |
Categories: General Creators: Singh Publisher: Beihang University, ETSI (Beijing (China)) Collection: ETSI TTCN-3 User Conference 2007 Asia |
Views: 53/2405
|
| Abstract |
|
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 |