![]() |
![]() |
![]() |
![]() |
![]() |
The TTCN Language
TTCN (Tree and Tabular Combined Notation, ISO/IEC 9646-3) is a language standardized by ISO for the specification of tests for real-time and communicating systems. TTCN has been developed within the framework of standardized conformance testing (ISO/ IEC 9646).
With TTCN a test suite is specified. A test suite is a collection of various test cases together with all the declarations and components it needs. Each test case is described as an event tree. In this tree, behaviors such as "First, we send A, then either B or C is received; if it was B we will send D..." are described. Concurrent TTCN allows several event trees to run concurrently.
TTCN is abstract in the sense of being test system independent. This means that a test suite in TTCN for one application (e.g. protocol, system, etc.) can be used in any test environment for that application.
The use of TTCN has increased tremendously during the last few years. This has been augmented by the significant amount of test suites released by various standardization bodies. TTCN is not only used in standardization work. The language is very suitable for all kinds of functional testing for real-time and communicating systems. This has led to a wide usage throughout the industry.
The specifications of the messages being sent and received can be defined using either the native form of TTCN or by using ASN.1 (Abstract Syntax Notation One).
Theoretical Model
A TTCN specification describes an abstract test suite (ATS) that is independent of test system, hardware and software. The ATS defines the test of the implementation under test (IUT), which is treated in a black box model, i.e. only its exterior interface is of concern. The IUT is stimulated by sequences of test events and its response is inspected.
A TTCN abstract test suite can be transformed into an executable test suite (ETS) using the TTCN Suite. This ETS is downloaded into the test system (the system performing the test).
The test system performs the test by executing the ETS against the system under test (SUT) which contains the implementation under test. During execution the ETS will report any errors and log events for on-line or post-test evaluation.
TTCN Specification Structure
A TTCN specification is similar to a Pascal or C program. (Being cleaner and more comprehensive, TTCN is easier to learn.) Just like Pascal and C, TTCN requires type and data declarations and it uses concepts like modules and subroutines. Since TTCN is designed for testing, it contains test specific concepts such as:
- Powerful pattern matching constructs for complex data structures using both TTCN and ASN.1.
- Verdicts and preliminary verdicts to define the outcome of test cases.
- Possibilities to handle alternative outcomes in a test case.
- Pre-ambles and post-ambles to show how to compose test cases.
- The "modules" concept supporting multi-user test development.
- The "modules" concept supporting the re-use of test components and data structures.
- Constructs for parallel test component execution including synchronization primitives.
A TTCN specification has a standardized layout that produces comprehensive and unambiguous paper printouts. This greatly improves clarity and readability. A test suite is divided into the following four major parts:
- The overview part, containing a table of contents and a description of the test suite. Its purpose is mainly to document the test suite to increase clarity and readability.
- The declarations part, declaring all messages, variables, timers, data structures and black box interface towards the Implementation Under Test.
- The constraints part, assigning values and creating constraints for inspection of responses from the implementation under test.
- The dynamic part, containing all test cases, test steps and default tables with test events and verdicts, i.e. it describes the actual execution behavior of the test suite.
Test Suite Dynamic Structure
The dynamic part of a TTCN abstract test suite is created in a hierarchical and nested manner. The building blocks are test groups, test cases, test steps and test events. There are no limitations as to how many test groups may be contained in a test suite, how many test events may be contained in a test step, etc.
- Test event: The smallest, indivisible unit of a test suite. Typically, it corresponds to a signal, interrupt, message, data or timer expiration.
- Test step: A grouping of test events, similar to a subroutine or procedure in other programming languages.
- Test case: The main fundamental building block in a test suite. A test case tests a particular feature or function in the implementation under test (IUT). A test case has an identified test purpose and it assigns a verdict that depends on the outcome of the test case.
- Test group: A grouping of test cases. It might for example be convenient to group all test cases concerning connection establishment, and to put all test cases concerning transport into a separate test group.
- Test suite dynamic part: The highest level, encompassing all test components and serving as the root of the tree. A test suite can range from a large number of test groups and test cases to a single test event contained in a test case.
Communication Mechanisms
TTCN uses the concepts of points of control and observation (PCOs), abstract service primitives (ASPs) and protocol data units (PDUs) in order to create an abstract interface towards the implementation under test (IUT). A PCO is a point in the abstract interface where the IUT can be stimulated and its responses can be inspected. An ASP or a PDU is either a stimuli or a response that carries information, i.e. parameters and data.
Each PCO has two first in first out queues for temporary storage of ASPs and PDUs: One queue for send and one queue for receive. These queues are infinite, i.e. they can store any number of ASPs and PDUs.
Event Trees, Constraints and Verdicts
TTCN uses event trees with test events to express the behavior of test steps and test cases.
All the leaves in the event tree are assigned a verdict that can be PASS, FAIL or INCONCLUSIVE. PASS means that the test case completed without detecting any error. FAIL means that an error was detected, that is, the behavior of the IUT did not conform with the pre-defined specification. INCONCLUSIVE means that there was insufficient evidence for a conclusive verdict to be assigned, but that the behavior of the IUT was valid.
A verdict can be either preliminary or final, allowing for flexibility in the specification. A final verdict will terminate the active test case and return its verdict. A preliminary verdict will not terminate test case execution but it will flag either PASS, FAIL or INCONCLUSIVE. This preliminary verdict can be inspected during test execution, like any variable.
TTCN uses the comprehensive format shown in Figure 6. The indentation level of statements in the Behaviour Description column indicates where in the event tree an event belongs. The leaves of the tree hold verdicts that define test case outcome.
Figure 6 : The TTCN test case corresponding to the event tree in Figure 5
Data and Value Model
The TTCN data and value model is somewhat different from the one in traditional programming languages. It allows for the creation of complex data structures and types, and has the concept of constraints to do value assignments. Constraints are more powerful than values in that they also allow the use of patterns. A pattern can contain wild cards and define allowable value ranges for complex data structures. This is very useful when inspecting responses from the implementation under test.
TTCN has two alternative data and constraint representation formats: the TTCN native tabular form and ASN.1 (Abstract Syntax Notation One). ASN.1, which is a purely textual notation, provides a more flexible platform for describing complex data structures. ASN.1 also allows data descriptions to be shared between an SDL (Z.105) specification and a TTCN test suite.
Modular TTCN
With modular TTCN, it is possible to define test suite components for re-use. This facilitates test component re-use, and provides a language platform for multi-user test development projects. See also Distributed Development.
Concurrent TTCN
Concurrent TTCN introduces a parallel architecture for simultaneous execution of several test components, allowing many interfaces to be tested concurrently. There are several benefits:
- Test components become more cohesive/modular since they focus on the test of a specific interface of the IUT. Each interface is isolated in specific test components.
- Module and integration testing is easier and it facilitates test component re-use.
- Test suite maintenance becomes easier since test components are less monolithic. If one interface of the IUT changes, it will not influence any test components but the ones specifically dedicated to this interface.
- Each test component becomes smaller and simpler since it deals with fewer alternatives.
In concurrent TTCN, each test case consists of several parallel test components (PTCs) that execute autonomously, performing concurrent tests. A master test component (MTC) starts the execution of the PTCs and controls the final verdict. The PTCs can only set preliminary verdicts and the test case is completed and its verdict is decided when all the PTCs are finished. The PTCs are synchronized through co-ordination points (CPs) and co-ordination messages (CMs).
Graphical and Textual Notations
The TTCN language supports two notations that are equivalent. The graphical notation (TTCN-GR) and a textual notation (TTCN-MP).
Application Areas
Currently, TTCN is mainly known within the telecommunications industry. However, it has broader areas of application, which can be summarized as follows:
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |