TTCN-3: Towards a common testing methodology

By Raquel Jiménez Garrido

In the expansion of telecoms systems there are key factors such as: the growing complexity of the technology, the reduced time to market for new products; interoperatibility between systems, as well as the increasingly high quality demands. All these factors have contributed to decreasing the reliability of the systems.

Testing activities are very important for systems quality assurance and reliability at the beginning of development phases and during the regression phase. Testing and Test Control Notation 3 (TTCN-3) is becoming a safe bet for the telecom companies replacing other testing languages used in the past.

TTCN-3 testing methodology

1. Introduction

TTCN is a standard testing language used in Black-Box testing for the specification and implementation of test cases. The TTCN language allows simulating a state diagram of the system under test (SUT). The SUT is a Black-Box that will be excited with stimuli. The answers to those stimuli are observed and compared with the expected answers. Taking in account the results of this comparison, the SUT behaviour can be successful, getting a test case pass; or unsuccessful, getting a test case fail.

TTCN-3 testing methodology

1.1 History

TTCN originated within the Conformance Testing framework and is linked to protocol telecommunication testing. “Conformance Testing” is the process verification of a particular vendor implementation. This implementation must be compliant with a determinate standard release. In the first versions, 1 and 2, TTCN behaviour was based on the OSI (Open System Interconnection) representation.

The TTCN-3 evolution has been motivated by several factors such as:

  • A language simplification more similar to C language.
  • A clear distinction between its homonymous ASN.1 (Abstract Syntax Notation One), which was confusing with TTCN versions 1 and 2.
  • New application fields besides telecommunications, such as automotion, avionics or CORBA systems.
  • Use in several kinds of testing, such as function testing, load testing, stress testing, interoperability testing; avoiding the use of expensive testing equipment with low flexibility used in that kind of testing.
  • Use in complex systems with several nodes e.g. UMTS (Universal Mobile Telecommunications System).

TTCN-3 testing methodology

2. TTCN-3 Features

TTCN is a standard language for formal test specification that includes a language description in addition to a mechanism to describe a complete execution environment. The environment description and the core language are shown in Figure 2 and available on the website.

TTCN has a set of properties that make it a very flexible language. TTCN has the possibility to import other presentation data into TTCN-3 such as IDL (Interface Definition Language), ASN.1 or XML (Extensible Mark-up Language).

The characteristics listed below make TTCN3 a testing language which can also be used in other fields than telecom:

  • Changing parameter values outside test cases without re-compiling the test cases.
  • Automatic checking through matching mechanisms in reception operations
  • The default behaviour mechanism to control unexpected events
  • Avoiding “ad-hoc” solutions.
  • Easy portability and test case re-use
  • Allowing to simulate complex systems with different interface communication at the same time
  • Code re-use in different testing phases e.g. function test and system test.
  • Resource reductions in equipment that is expensive and not very flexible.
  • TTCN is independent of a platform or system to test.
  • There are already test batteries for technologies such as (Global System for Mobile Communications), TETRA (Trans-European Trunked Radio) or WCDMA (Wideband Code Division Multiple Access).
  • Standardization groups such as 3GPP, ETSI, EUROESCOM or ATM Forum have adopted TTCN as a testing language.

The communication mechanism to test the SUT has also been improved compared to previous versions. TTCN-3 allows using two communication ways between different entities involved in the testing process.

TTCN-3 provides an asynchronous mechanism communication based on messages like in the previous versions. The asynchronous communication is distinguished as a communication between equals: in fact in a client/ server scenario the messages are sent and received using the same primitives (send, receive) independently of pair role (client/ server). The message is sent and the pair continues its behaviour without expecting an answer to the message sent.

TTCN-3 testing methodology

TTCN-3 also supplies a synchronous communication based on procedures. This communication has appeared due to the application of TTCN-3 to new areas. In contrast to message communication, the synchronous communication is characterized by the client/ server role and is completely defined in the communication. The client invokes a remote procedure and the server processes this invocation, returning an answer (reply) or an error condition which raises an exception (raise/match). This communication is done with specific primitives (call, getcall, reply…) depending on the pair role. The message is sent and the pair sender is blocked until the receipt of the answer message.

TTCN-3 testing methodology

Other TTCN-3 features are predefined functions or external functions. The predefined functions facilitate the type language conversion: as int2char (), which transforms an integer into a charstring or oct2bit (), which transforms an octetstring into a bitstring. The external functions are developed by the user (e.g. in C++) and can be called inside the TTCN-3 code.

ETSI TTCN-3
ES-201 873-1 Part 1: TTCN-3 Core Language
ES-201 873-2 Part 2: Tabular Presentation Format (TFT)
ES-201 873-3 Part 3: Graphical Presentation Format (GFT)
ES-201 873-4 Part 4: Operational Semantics (OS)
ES-201 873-5 Part 5: TTCN-3 Runtime Interface
ES-201 873-6 Part 6: TTCN-3 Control Interface
ES-201 873-7 Part 7: The use of ASN.1
ES-201 873-8 Part 8: The IDL to TTCN-3 Mapping
ES-201 873-10 Part 10: Documentation Comment Specification

2.1 Test System

Within the test terminology “test suite” is a set or a test battery that has to be passed by the system under test. In TTCN, an “abstract test suite” is used instead; the reason for the use of the word “abstract” is that the TTCN test cases have no information about the system under test.

As a programming language, TTCN-3 is not executable by itself but needs to be interpreted or translated to an executable format. In addition to this, information about the SUT to be executed in needs to be added. The test system parts for the test execution are explained below:

  • System Adapter (SA): responsible for establishing the communication between the test cases written in TTCN-3 and the real system.
  • Platform Adapter (PA): responsible for implementing the timers defined in TTCN-3 test cases in the different platforms.
  • Codecs: responsible for coding/decoding the TTCN-3 messages to the right format to be sent to the SUT.
  • Test Management: responsible for providing the control part to specify the test cases execution order.
  • Test Logging: responsible for defining the logs generated during test execution.

3. Application Fields

TTCN was originally used in the telecoms field. TTCN was created to test ISDN (Integrated Service Digital Network) networks and ATM (Asynchronous Transfer Mode); in the 2nd version TTCN-3 was adopted by 3GPP to test mobile handsets. In version 3, it is also used to test Internet protocols. In fact, there are companies dedicated to commercialized test batteries, and even the standardization groups offer test batteries such as SIP (Session Internet Protocol) or H323 protocol.

TTCN-3 testing methodology

New application fields, some of them in study, are:

  • Web applications; testing hyperlinks, text paragraph, html syntax or format. The study is made at Ottawa University.
  • Test Automotive Software, with companies such as DaimlerChrysler or Renault.
  • Using TTCN-3 for testing telematics and electronic systems in vehicles.
  • Testing of system trains interlocking in a study by Centrum voor Wiskunde in Informatics, Amsterdam. Test components devices over CAN-Bus (e.g. X-ray devices) made by Siemens Medical Solutions.

Conclusion

TTCN in its version 3 is a versatile testing tool that is increasingly used in many fields also outside telecoms. The use of TTCN-3 by several standardization groups has contributed to its many features, as has the existence of testing batteries, which also increase its popularity as a test language.

TTCN-3 allows having a common testing methodology in the same company. TTCN-3 can be applied to different fields and saves money in human and equipment resources, avoiding ―ad-hoc‖ testing solutions.

TTCN-3 is a tool that can be applied to all testing cycles: from function test, performance test, system test to load test. As disadvantages, the development of the system adapter and platform adapter could be mentioned. This adaptation, however, is only made once. The statistics say that effort in performing the first test is three times more than doing it manually; but the effort required for subsequent regressions is four times less.

Cross References

[1] TTCN-3 Standard Part 1: ES 201 873-1 TTCN-3 Core Language.
[2] TTCN-3 Standard Part 2: ES 201 873-2 TTCN-3 Tabular Presentation Format.
[3] TTCN-3 Standard Part 3: ES 201 873-3 TTCN-3 Graphical Presentation Format.
[4] TTCN-3 Standard Part 4: ES 201 873-4 TTCN-3 Operational Semantics.
[5] TTCN-3 Standard Part 5: ES 201 873-5 TTCN-3 Runtime Interface.
[6] TTCN-3 Standard Part 6: ES 201 873-6 TTCN-3 Control Interface.
[7] ITU-T Recommendation X.292: Tree and Tabular Combined Notation.
[8] ISO/IEC 9646-3: Tree and Tabular Combined Notation
[9] TTCN-3 User Conference 2006, Berlin.

TTCN-3 opens a new market in the testing world; it allows commercializing the ―test suites‖, adaptations (system adapter) or codecs. The test engineer only needs to design the TTCN-3 test cases and the associated parameters.

 

Further articles of the testing experience magazine

Adopt Your Local Professor: The Need for Industry and Academia to Work Together
By Patricia A. McQuaid

Putting the ‘Analysis’ in a Test Analyst
By Mike Smith

Leave a Reply

Your email address will not be published. Required fields are marked *