Eclipse Titan

Primary tabs

The Eclipse Titan documentation is available in the /doc directory of the downloadable packages.

ETSI TTCN-3 website with downloadable TTCN-3 standards:

Eclipse Titan command line  installation:

Eclipse Titan command line basic workflow:

Ericsson TTCN-3 course material:



The project aims to provide an Eclipse-based IDE for TTCN-3 based test design and execution environment. The following are within the projects scope:

  • Provide a complete test design, execution and log analysis environment for TTCN-3 within the Eclipse IDE.
  • Provide a command line test execution and result reporting interface.
  • Utilize the TTCN-3 standard.
  • Analyze TTCN-3 code quality and report metrics, code smells, code structure, all kind of information that helps the users to maintain robust and high quality code.
  • Assist the users in refactoring their TTCN-3 code.
  • Allow testing of XML interfaces and applications.
  • Allow testing of JSON interfaces and developing JSON schemas.
  • Permit the ingestion of ASN.1 and IDL specifications, describing the messaging and signal structures at the tested interfaces.
  • Utilize the capabilities of other programming languages in TTCN-3 and allow other programming languages to utilize TTCN-3 and/or Titan's advantages.
  • Provide message and signal encoding/decoding functionality within the tool, to keep test cases concentrating on the test behaviour at the higher abstraction level.
  • Provide runtime features for distributed, multi-platform and load-balanced multi-process test execution on POSIX-based operational systems as Linux, Solaris and Cygwin over Windows.
  • Provide the features to specify test execution logic, like conditional, looped, repeated execution with different sets of test data etc. 
  • Collect local test verdicts from the distributed processes (test components) of the system and calculate the overall test case verdict.
  • Provide statistics of attended or unattended test execution sessions.
  • Generate logs in different possible formats and verbosity during test execution.
  • Support continuous integration (CI), for example by providing test results for CI tools like Jenkins.
  • Provide Eclipse-based and command line log collecting and post-processing utilities.
  • Provide means for high-level test result- and detailed (low-level) log analysis.
  • Allow viewing logs in different presentation formats, like graphical. tabular/textual etc.

To help start using the toolset, a few popular, existing IP-based transports and protocols are also submitted to open source.

The following test ports (see the description section) are included into this proposal:

  • TCP, UDP, TELNET, SQL, PIPE (creating and executing command line shells from TTCN-3), SCTP, HTTP, PCAP (reading wireshark traces into TTCN-3), LANL2 (handling Ethernet frames), SIP, and Abstract Socket (it is not a test port on is own, but a library handling the TCP socket of the Linux kernel; it is used in our test ports and making it easy to develop any new test port that is using TCP).

See more information on the test port's capabilities in the Description section.

The following protocol modules are also included into this proposal:


The useful functions library contains non-domain specific utilities, like reading/writing files, get access to operational system variables, system time etc.

Any further test ports, protocol modules or generic, non-domain specific libraries, developed by contributors wil be part of this project, as they are technically closely related to the tool (due to using the test port API and message/signal encoding control of Titan).

Titan can be used for automated testing by developing test frameworks and test cases manually. But, when integrating it with modeling tools, thus providing a complete model-based-design AND model-based-testing environment, testing efficiency can be increased: test cases are generated instead of manual development, and the same environment can be used starting from the requirements engineering phase of system design up to testing of the system's functionality.

Test frameworks are domain-specific and often specific to the system under test (SUT), e.g. through managing the SUT via its management interface or accessing the SUTs internal status and data using embedded components. Sharing of libraries and frameworks developed by (Titan) users and contributors is important to the success of the test system, but due to their domain-specific nature they should not be part of this project but should create other projects, related to this one.

Working Group: 
6.2.0 Current2017-06-21