OpenTTCN/Knowledge base/OpenTTCN Test System Openness
From OpenTTCN
Home | Developer's corner | Knowledge base | Working documents | Documentation | OpenTTCN IDE | Tutorials | Training | How do I | Frequently asked questions | Technical support |
Contents |
OpenTTCN Test System Openness
Introduction
The TTCN-3 standard suite defines TTCN-3 test system conceptually as a "set of interacting entities where each entity corresponds to a particular aspect of functionality in a test system implementation". In other words a TTCN-3 test system is a collection of interacting components with specific roles. Effectively this means that the TTCN-3 standard strongly encourages modular design where the test system is assembled from a set of separate components.
The ultimate goal of the Test System Openness initiative is to guarantee the best possible user experience for the end-users of OpenTTCN-powered test systems by allowing them to freely combine separate components into complete test system configurations. However, even though a TTCN-3 test system is always modular in its heart, the choices made by test system manufacturer will still have an effect on the practical reusability of the entities.
This article focuses on the practical questions in creating truly reusable test systems with the OpenTTCN tester toolchain.
Test Management Openness principle
In this context, the test management consists of the TCI-TM (controlling the execution) and TCI-TL (logging) entities. In other words, test management is the user interface that the end user eventually sees. Each user has their own preferences and mindset. Some people prefer UNIX-like command line interface while some prefer clicking buttons in a neat graphical user interface. Also, different tasks demand different methods: A graphical user interface, regardless of how powerful, is not very suitable for automated nightly runs, and a graphical interface that incorporates visual elements to the log display is much more handy for finding errors.
This is where the test management openness principle comes into play. OpenTTCN provides both text-mode and graphical user interfaces and also encourages test system vendors to develop their own. However we believe that there simply is no "one size fits all" user interface for test management and that the end-user should have the option to select the preferred tool.
On practical level, requirements to satisfy the test management openness principle are:
- Test system can be started in mode where its own test management application is not active, and the test system allows use of alternative test management application such as "tester run" command
- Test system vendor can facilitate easy switching between test management applications by using OpenTTCN standardized parameter value file format based on TTCN-3 core notation when storing and reading module parameter values.
Test Adapter Openness Principle
Test adapters (SUT adapter, Platform adapter, Coding and Decoding) should be implemented so that they can be attached to different test sessions. On practical level, requirements to satisfy the test adapter openness principle are:
- Test system can be instructed to registers all the TTCN-3 adapters it provides to testing session of user selected name. OpenTTCN has chosen a command line parameter of format "-s server_ip:port:sessionname" to be used in its own adapters such as the Robo loopback adapter.
Current status of the Test System Openness
OpenTTCN Tester, Publisher, and Runtime version 3 contains limited support for facilitating the openness principles and their proper function relies on test system vendor's good will on implementing well behaving applications.
