IBM
Contents Index Previous Next



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.

Figure 1 : Test System with Executable Test Suite (ETS)
connected to the system under test (SUT)

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:

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:

Figure 2 : The basic structure of a TTCN 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 component explanation:

Figure 3 : The TTCN dynamic part structure

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.

Figure 4 : PCOs together with ASPs and PDUs create an
abstract interface towards the IUT

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.

Figure 5 : An event tree and the corresponding execution order

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:

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
Contents Index Previous Next