openttcn tester user guide

OpenTTCN Tester 2012 User Guide

VERSION 4.2.5 – July 6, 2012

of 131


© 2012 OpenTTCN Ltd. All rights reserved.

Contents

1 OVERVIEW OF OPENTTCN TESTER 2012 .................................................................................... 6

2 RELEASE HIGHLIGHTS OF OPENTTCN TESTER 2012 .................................................................... 7

3 PREREQUISITES FOR OPENTTCN TESTER ................................................................................... 8

4 OPENTTCN TESTER SYSTEM OVERVIEW .................................................................................... 9

4.1 SYSTEM SERVICES ............................................................................................................................ 9

4.2 USER INTERFACES ............................................................................................................................ 9

4.3 SUT AND PLATFORM ADAPTERS AND CODING AND DECODING .............................................................. 10

4.3.1 SUT Adapter .................................................................................................................... 11

4.3.2 Platform Adapter ............................................................................................................ 11

4.3.3 Coding and Decoding ...................................................................................................... 12

5 STARTING AND STOPPING OPENTTCN TESTER ........................................................................ 13

5.1 SELECTING A WORKSPACE ............................................................................................................... 14

5.2 INSTALLING OPENTTCN LICENSE KEY ................................................................................................ 15

5.3 ACTIVATING OPENTTCN LICENSE KEY ............................................................................................... 16

5.4 PROXY CONFIGURATION .................................................................................................................. 19

5.5 ONLINE LICENSE VALIDATION .......................................................................................................... 20

5.6 OPENTTCN TESTER RUNNING ......................................................................................................... 22

5.7 STOPPING OPENTTCN TESTER ........................................................................................................ 25

6 TRYING OPENTTCN TESTER WITH DEMO3 EXAMPLE ............................................................... 27

6.1 EXPECTED RESULTS OF DEMO3 TEST CAMPAIGN ................................................................................. 31

6.2 EXPECTED RESULTS OF ASN1 TEST CAMPAIGN ................................................................................... 31

7 STARTING A NEW TTCN-3 PROJECT ......................................................................................... 32

7.1 CREATING A TTCN-3 PROJECT......................................................................................................... 32

7.2 CREATING A TTCN-3 FILE ............................................................................................................... 35

7.3 IMPORTING TTCN-3 FILE(S) ........................................................................................................... 37

7.4 MODULE PARAMETERIZATION ......................................................................................................... 39

7.4.1 Creating a Parameter File ............................................................................................... 39

7.5 COMPILING TTCN-3 CODE ............................................................................................................. 41

7.6 SETTING TTCN-3 ADAPTER CONFIGURATION (EXTERNAL TOOLS CONFIGURATION) ................................... 44

7.7 SETTING UP TTCN-3 TEST CAMPAIGN (RUN CONFIGURATION) ............................................................. 46

7.8 RUNNING TTCN-3 TEST CASES ........................................................................................................ 50

8 ANALYZING TEST RESULTS ...................................................................................................... 51

of 131



8.1 STACK TRACE VIEW ........................................................................................................................ 51

9 OPENTTCN GFT LOG VIEWER................................................................................................... 53

9.1 FUNCTIONALITY OF OPENTTCN GFT LOG VIEWER .............................................................................. 53

9.2 USING EXAMPLE TEST SUITE ............................................................................................................ 54

9.2.1 Obtaining Graphical Log for the Example Test Campaign .............................................. 54

9.2.2 Description of Test Cases in the Example Test Suite ....................................................... 56

9.2.3 Opening Log View Perspective for the Example Test Campaign ..................................... 58

9.3 VIEWING EXAMPLE LOGS ................................................................................................................ 58

9.3.1 Message-based, Procedure-based, and Timers .............................................................. 58

9.3.2 Concurrent Execution Involving Parallel Test Components ............................................. 62

10 OPENTTCN TTCN-3 DEBUGGER................................................................................................ 63

10.1 FUNCTIONALITY OF OPENTTCN DEBUGGER .................................................................................. 63

10.2 DEBUGGING THE EXAMPLE TEST SUITE ......................................................................................... 64

10.2.1 Executing test campaigns in the debugger ................................................................ 64

10.2.2 Debugging with the Debug Perspective ..................................................................... 66

10.2.3 Debugger Controls ..................................................................................................... 68

10.2.4 Debugger Summary ................................................................................................... 70

10.3 DEBUGGING COMMON PROBLEM SCENARIOS ................................................................................ 71

10.3.1 Debugging Test Case Deadlocks ................................................................................ 71

10.3.2 Introducing the Deadlock ........................................................................................... 71

10.3.3 Debugging the Deadlock ............................................................................................ 72

11 OPENTTCN ADAPTER LIBRARY ................................................................................................ 73

11.1 OVERVIEW .............................................................................................................................. 74

11.2 SERIAL ADAPTER ...................................................................................................................... 75

11.3 UDP ADAPTER......................................................................................................................... 75

11.4 TCP ADAPTER ......................................................................................................................... 76

11.5 HTTP ADAPTER ....................................................................................................................... 77

11.6 CUSTOMIZING YOUR OWN ADAPTER ............................................................................................ 77

12 OPENTTCN CODEC COMPONENT LIBRARY .............................................................................. 78

12.1 OVERVIEW .............................................................................................................................. 79

12.2 DIRECT CODEC FOR DIRECT ENCODING OF BIT PROTOCOLS ............................................................... 79

12.3 XML CODEC ............................................................................................................................ 80

12.4 BER CODEC ............................................................................................................................ 81

12.5 PER CODEC............................................................................................................................. 81

of 131



12.6 WRITING YOUR OWN CODEC COMPONENT ................................................................................... 82

13 JAVA ADAPTER DEVELOPMENT USING OPENTTCN TESTER 2012 GUI ...................................... 83

13.1 OVERVIEW .............................................................................................................................. 83

13.2 IMPORTING A JAVA PROJECT ....................................................................................................... 83

13.3 SETTING UP JAVA COMPILATION .................................................................................................. 85

13.4 RUNNING JAVA ADAPTERS .......................................................................................................... 88

Option 1: OpenTTCN adapter launch configuration ...................................................................... 88

Option 2: Start as Java application ............................................................................................... 88

14 COMMAND-LINE TOOLS QUICK REFERENCE ............................................................................ 91

14.1 CONTROLLING SYSTEM SERVICES ................................................................................................. 91

14.2 SESSION MANAGEMENT ............................................................................................................ 91

14.3 LOADING MODULES................................................................................................................... 91

14.4 RUNNING TEST CASES ................................................................................................................ 92

14.5 LOADING VALUES OF MODULE PARAMETERS ................................................................................... 92

14.6 HANDLING ERRORS ................................................................................................................... 92

14.7 TYPICAL COMMANDS SEQUENCES ................................................................................................ 93

15 TESTING USING OPENTTCN TESTER COMMAND-LINE ............................................................. 94

15.1 STARTING TEST SYSTEM ............................................................................................................. 94

15.1.1 Starting the Server Part of OpenTTCN Tester ............................................................. 95

15.1.2 Starting SUT and Platform Adapters and Coding and Decoding ................................ 95

15.2 SELECTING TESTING SESSION ...................................................................................................... 96

15.3 COMPILING TTCN-3 AND ASN.1 MODULES ................................................................................. 97

15.4 TEST PARAMETERIZATION .......................................................................................................... 99

15.4.1 Using Multiple Par Files............................................................................................ 100

15.5 CHECKING FEASIBILITY OF STARTING FULL TESTING ....................................................................... 102

15.6 RUNNING ALL TESTS ............................................................................................................... 102

15.6.1 Stopping Test Campaign .......................................................................................... 103

15.7 REVIEWING TESTS RESULTS ...................................................................................................... 104

15.7.1 Reviewing Test Result Summary .............................................................................. 104

15.7.2 Reviewing Assigned Verdicts .................................................................................... 106

15.8 STOPPING TEST SYSTEM ........................................................................................................... 108

15.8.1 Stopping SUT and Platform Adapters and Coding and Decoding ............................ 108

15.8.2 Stopping the Server Part of OpenTTCN Tester ......................................................... 109

16 OPENTTCN COMMAND-LINE REFERENCE .............................................................................. 110

of 131



16.1 THE “OT” SERVER START-UP UTILITY ......................................................................................... 110

16.1.1 Start a Testing Server ............................................................................................... 110

16.1.2 Stop a Testing Server ................................................................................................ 111

16.1.3 Inquiry of a Testing Server Status............................................................................. 111

16.1.4 Print License Key OpenTTCN Identification .............................................................. 112

16.1.5 Print Command-Line Help ........................................................................................ 112

16.2 SESSION UTILITY ..................................................................................................................... 112

16.2.1 Create a Session ....................................................................................................... 113

16.2.2 Delete a Session ....................................................................................................... 114

16.2.3 List Sessions .............................................................................................................. 114

16.2.4 Show a Session Status .............................................................................................. 115

16.2.5 Unregister a Test System Interface .......................................................................... 115

16.2.6 Print Version Information ......................................................................................... 117


16.3 TESTER UTILITY ...................................................................................................................... 118

16.3.1 Run Tests .................................................................................................................. 118

16.3.2 Print Version Information ......................................................................................... 119


16.4 IMPORTER3 UTILITY ................................................................................................................ 120

16.4.1 Load Test Suite ......................................................................................................... 120

16.4.2 Analyse a Test Suite ................................................................................................. 121

16.4.3 Suite Using TTCN-3 Module Parameters .................................................................. 121


17 USING TTCN-2 COMPILER OPTION WITH OPENTTCN TESTER ................................................ 123

18 OPENTTCN TESTER CONFIGURATION FILE ............................................................................. 126

18.1 CHANGING CONFIGURATION SETTINGS ........................................................................................ 127

18.2 COMMONLY USED CONFIGURATION SETTINGS .............................................................................. 127

18.3 JAVA RELATED CONFIGURATION SETTINGS .................................................................................... 127

18.4 SYSTEM CONFIGURATION SETTINGS ............................................................................................ 128

19 FILES CREATED BY OPENTTCN ............................................................................................... 129

20 CONTACTING OPENTTCN ...................................................................................................... 131

of 131



1 Overview of OpenTTCN Tester 2012

OpenTTCN Tester 2012 is a TTCN-3 test development and execution package built

by integrating popular OpenTTCN Tester product and widely used Eclipse framework

providing an easy to use TTCN-3 editing, compilation, and execution environment.

OpenTTCN Tester 2012 includes seamless integration of OpenTTCN TTCN-3 just-

in-time compiler and virtual machine, and TTCN-3 editor. OpenTTCN Tester 2012

provides basic but easy to use support for integrating TTCN-3 test case editing,

TTCN-3 syntax and semantic checking, TTCN-3 compilation, starting TTCN-3

adapters on demand and execution of TTCN-3 test cases into one single integrated

development environment.

OpenTTCN Tester 2012 is compatible with OpenTTCN platform version 4.2. The

following OpenTTCN SDKs are included for programming TTCN-3 adapters:

OpenTTCN SDK for C1

OpenTTCN SDK for C++2

OpenTTCN SDK for C#3

OpenTTCN SDK for Java

OpenTTCN Tester 2012 is available for Windows and Linux platforms. The

Microsoft Windows 8 (after its release), Microsoft Windows 7, Microsoft Windows

Vista, and Microsoft Windows XP with Service Pack 3 operating systems are

supported. Latest Debian Linux is supported.

1 OpenTTCN SDK for C is compatible with Microsoft Visual Studio 2010 and Microsoft Visual Studio

2008 in Windows platform and with GCC4 in Linux platform.

2 OpenTTCN SDK for C++ is compatible with Microsoft Visual Studio 2010 and Microsoft Visual

Studio 2008 in Windows platform and with GCC4 in Linux platform.

3 OpenTTCN SDK for C# is compatible with Microsoft .NET Framework 3.5 / Mono and Microsoft

Visual Studio 2010, Microsoft Visual Studio 2008 and Mono / MonoDevelop.

of 131



2 Release Highlights of OpenTTCN Tester 2012

OpenTTCN Tester 2012 is a new production version containing all changes from

previous beta releases of OpenTTCN Tester. The following list contains highlights of

new additions included in this version. See the Release Notes document for detailed

list of changes from previous versions of OpenTTCN Tester.

Six major new features of OpenTTCN Tester 2012 are:

Super fast TTCN-3 compiler,

TTCN-3 Edition 4 (version 4.3.1) improvements,

New adapters: Serial, UDP, TCP, and HTTP adapters,

XML Codec to complement XML Schema to TTCN-3 translator,

ASN.1 BER and DER Codec as C# codec component, and

new Enterprise Edition.

Highlights of other major features included:

A graphical user interface simplifying test development and test management

supporting:

TTCN-3 test case editing,

TTCN-3 syntax and semantic checking,

TTCN-3 compilation,

Test management - Execution of TTCN-3 test cases,

Instantly-ready native TTCN-3 debugger,

GFT (Graphical Presentation Format) log viewer, and

On-demand adapter startup.

XML Schema to TTCN-3 translator,

TTCN-3 TRI and TCI-CD interfaces for Java,

TTCN-3 TRI, TCI-CD, and TCI-TM interfaces for ANSI C and C++,

TTCN-3 TRI and TCI-CD interfaces for C#,

Command-line tools for scripting and advanced use are included, and

Unified installer architecture - All tools and SDKs in one package.

of 131



3 Prerequisites for OpenTTCN Tester

OpenTTCN Tester 2012 is available for modern PC computers running Microsoft

Windows 8, Microsoft Windows 7, Microsoft Windows Vista, and Microsoft

Windows XP with Service Pack 4 or Debian operating systems.

OpenTTCN Tester 2012 is a standalone package integrating functionality of popular

OpenTTCN Tester product with an Eclipse-based TTCN-3 IDE.

OpenTTCN Tester 2012 uses Java for the Eclipse components as well as parsing

TTCN-3 and ASN.1 modules. For these reasons you need to have Java 6 Runtime

Environment or newer installed. OpenTTCN recommends using the latest version of

Java 6 JRE. Current version of OpenTTCN Tester requires 32 bit version of Java. If

you are developing adapters with the OpenTTCN Java SDK, you must install the Java

Development Kit (JDK).

You can download a Java Runtime Environment (JRE) or a Java Development Kit

(JDK) from: http://java.oracle.com.

http://java.oracle.com/

of 131



4 OpenTTCN Tester System Overview

OpenTTCN Tester consists of a Server, a User Interface, one or more SUT and

Platform Adapters, and one or more Coding and Decoding adapters. The Server is

used to execute test specification and it implements the TTCN-3 Executable (TE)

function described in the TTCN-3 architecture. The Graphical User Interface (GUI) is

used to perform test management operations and to control the testing. It implements

the Test Control (TC) and Test Logging (TL) interfaces described in the TTCN-3

architecture. The SUT and Platform adapters adapt the tester for certain application

domain that is specified by a test suite and implement the corresponding function

described in the TTCN-3 architecture. The Coding and Decoding provides translation

between abstract TTCN-3 data and transfer syntax used by the application on the

wire.

4.1 System Services

The server part of OpenTTCN Tester, also called the Server or System Services,

consists of one or more processes that implement necessary functionality to control,

store, and execute test specifications.

System services shall be running before other parts of the test system are started and

while the rest of the test system is running. They are started automatically by the

Graphical User Interface, but must be started by hand for command-line use.

4.2 User Interfaces

The user interface part of OpenTTCN Tester consists of alternative user interfaces

that implement necessary functionality to perform test management operations and to

control the testing. The graphical user interface is the normal method of operating the

test system. OpenTTCN command-line utilities are also described in this document,

but they are intended for advanced users only. Alternatively a custom user interface

implemented using TCI-TM interfaces can be used.

of 131



Division of OpenTTCN Tester to user interface and server parts allows separate

evolution of these parts, and integration of customer specific test management

software if desired.

For simple scenarios use of the OpenTTCN provided graphical user interface is

recommended.

4.3 SUT and Platform Adapters and Coding and Decoding

The domain specific part of the OpenTTCN Tester, here called "SUT and Platform

Adapters and Coding and Decoding", consists of one or more processes that

implement necessary functionality to specialize a generic tester to a certain

application domain and operating system platform.

SUT adapter is used to create a concrete link between the Tester and the

Implementation Under Test (IUT). Platform Adapter is used to extend the used testing

language with external operations, and in some case implementing a platform specific

timing mechanism. Coding and Decoding is used to encode all data sent and to

decode all data received. Coding and Decoding can be implemented as a single

separate server or implemented together with the SUT or Platform Adapter server.

After these servers have been created for a specific test suite, a complete test system,

"Means of Testing" (MOT) in ISO 9646 terms, has been created.

The necessary SUT and Platform Adapters and Coding and Decoding can be provided

by OpenTTCN Ltd, a value added reseller, integrator, or they could be created by the

end-user with the OpenTTCN SDKs.

These three classes of adapters, SUT Adapter, Platform Adapter, and Coding and

Decoding, are described in the following sections.

of 131



4.3.1 SUT Adapter

The SUT Adapter consists of one or more processes that implement necessary

functionality to connect Implementation Under Test (IUT) to the Tester. Each of the

processes in turn may implement one or more TTCN-3 ports defined in the test

specification in abstract terms. Usually the implementation of the SUT Adapter

consists of message decoder and encoder, and code that sends and receives messages

to and from the used network hardware or connection.

The SUT Adapter shall be started and registered only after the Server is already

running. The SUT Adapter shall be unregistered and stopped before the Server is

stopped.

4.3.2 Platform Adapter

The Platform Adapter consists of one process that implements the TTCN-3 external

functions defined in the test specification in abstract terms. The TTCN-3 external

functions are an extension mechanism to add new operations to the testing language

that cannot be otherwise specified. The Platform Adapter can be implemented in a

separate process or it can be combined with one of the SUT Adapters. Usually, the

Platform Adapter is combined with the SUT Adapter, if the TTCN-3 external

functions are used to control the test system interface.

The Platform Adapter shall be started and registered only after the Server is already

running. The Platform Adapter shall be unregistered and stopped before the Server is

stopped.

of 131



4.3.3 Coding and Decoding

The Coding and Decoding consists of one or more decoding functions and one or

more encoding functions that implement necessary functionality to convert abstract

TTCN-3 values to desired transfer syntax and vice versa.

The Coding and Decoding is normally implemented together with the TTCN-3 SUT

Adapter or Platform Adapter needing its services. Alternatively a single standalone

Coding and Decoding server can be registered that provides all encoding and

decoding services for the test system.

The standalone Coding and Decoding shall be started and registered only after the

Server is already running. The standalone Coding and Decoding shall be unregistered

and stopped before the Server is stopped.

of 131



5 Starting and Stopping OpenTTCN Tester

You can start OpenTTCN Tester from the Windows Start menu under OpenTTCN

Tester 2012. Your Windows desktop also has a new icon to start OpenTTCN Tester,

if you chose to install it.

On startup you will be prompted for your workspace location. The term workspace

means the directory where all OpenTTCN Tester TTCN-3 projects, configuration

settings and TTCN-3 files are stored. It is recommended to place the workspace in

your home directory under the "OpenTTCN Tester 2012" folder. After your start

OpenTTCN Tester, OpenTTCN Tester splash screen shown in the following

screenshot is displayed.

Figure 1: OpenTTCN Tester 2012 splash screen.

of 131



5.1 Selecting a Workspace

When you select to start OpenTTCN Tester, the following dialog will be shown. You

can now change the workspace directory by specifying a directory name that you

want to use as your OpenTTCN Tester workspace directory.

For example, you can place the workspace in your home directory under the

"OpenTTCN Tester 2012" folder. This is the default recommended setting. This

would be specified in the dialog as C:\Users\<your username>\OpenTTCN Tester

2012\workspace (in Windows 7). Alternatively you can place the directory to your

desired location by clicking on the Browse -button.

Figure 2: Workspace launcher dialog.

Every time OpenTTCN Tester starts, the application will ask you for the workspace

you want to use. If you want to use the same workspace always, you can tick the “Use

this as the default and do not ask again” check box.

of 131



5.2 Installing OpenTTCN License Key

When OpenTTCN Tester starts it checks if you have already installed OpenTTCN.lic

license key and asks if you want to install the license key. The OpenTTCN.lic license

key can be downloaded from https://www.openttcn.com/updates using the same

account information that you used to download the OpenTTCN Tester software itself.

If OpenTTCN.lic license key of OpenTTCN Tester is missing when you start

OpenTTCN Tester, the application will ask you if you wish to install the license key

using the following dialog. Please click Yes button to proceed installing the missing

license key. Note that OpenTTCN Tester will refuse to start until you install and

activate a valid license key.

Figure 3: License file installation dialog.

If you answer No to the license installation request, you will be returned to the

License Management screen where you can choose to try again or exit the program.

When you answer Yes, the following Select license file dialog is shown. Navigate to

the correct folder that contains the OpenTTCN.lic license key you downloaded. If you

have downloaded the key using Windows 7, the license may be found from

"C:\Users\<your username>\Downloads" directory by default.

http://www.openttcn.com/updates

of 131



Figure 4: Select license file dialog.

5.3 Activating OpenTTCN License Key

Before the OpenTTCN license key can be used it needs to be activated. The activation

is performed using Internet connection with the OpenTTCN Activation server.

After you have installed OpenTTCN license key, OpenTTCN Tester checks if the

license key needs activation and asks you if you want to activate the license key to the

computer you are using. If you want to activate to the computer you are now using,

please click Yes button to proceed with the activation. If you do not activate your

license the software will not start and you will be returned to the License Management

screen where you can install another license or exit the program.

Note that activating the license key binds it to your computer and you cannot activate

it on another computer. If you want to activate the license key to another computer

instead, please click No button to cancel the activation.

of 131



Figure 5: License activation request dialog.

If the activation is successful OpenTTCN Tester will start up. In the case of errors you

will be returned to the License Management screen to resolve the problem. If you

encounter internet connectivity problems and your network requires a proxy server,

please refer to chapter 5.4.

The License Manager looks like in the following screenshot. If you encounter

problems with setting up your license, please contact OpenTTCN support using the

[email protected] e-mail address. In your message please indicate your license

keys OT ID number, the error message shown in red as well as the exact error details

shown when you click the Details... button.

mailto:[email protected]

of 131



Figure 6: OpenTTCN license management window.

of 131



5.4 Proxy configuration

If your network requires proxy settings, you might encounter problems when

activating your license or with Online License Validation. Proxy configuration can be

opened from the OpenTTCN License Management dialog. Later on you can access

the proxy settings via the Window -> Preferences... menu item. It is available in the

General -> Network Connections section.

The proxy configuration looks as in the following picture. Here you can select Direct

internet connectivity, Manual proxy configuration or use of the Native settings.

Figure 7: Proxy configuration in preferences.

of 131



The simplest option is to select the active provider as Native so that the system

settings will be used. If this does not work, you must inquire the correct proxy settings

from your network administrator and configure the proxy with the Manual setting.

5.5 Online License Validation

If your license requires Online License Validation with the OpenTTCN license server

and there is a problem with your network connectivity, you might encounter the

following license error:

Possible causes and ways to resolve these problems are:

1) No internet connectivity. Please connect your computer to the internet.

2) Erroneous proxy configuration. For instructions on configuring your proxy

settings please refer to Chapter 5.4 Proxy configuration.

Figure 8: License validation error.

of 131



3) Firewall configuration. You should configure your firewall to permit

network communication from OpenTTCN Tester to the activation server.

4) OpenTTCN license server is not available at this moment. You should try

again momentarily to see if the issue has been resolved. Should your problem

persist, please contact OpenTTCN support at [email protected] .

of 131



5.6 OpenTTCN Tester Running

After OpenTTCN Tester has started the welcome screen is displayed. From this

welcome screen you can select "Create example workspace" to import the TTCN-3

Demo3, DNS, and ASN.1 example projects. These examples are a helpful

introduction if you are new to TTCN-3, OpenTTCN and/or OpenTTCN Tester.

You can also choose to start with an empty workspace by selecting "Go to

workspace".

Figure 9: OpenTTCN welcome screen during first start-up.

If you wish to return to the welcome screen at a later date, you can find the

OpenTTCN Tester Welcome Screen option in the help menu:

of 131



Figure 10: Re-launching OpenTTCN welcome screen from Help menu.

After the import is finished OpenTTCN Tester will be put in the default TTCN-3

perspective. The term perspective means the TTCN-3 views and editors associated to

certain tasks that are displayed.

If you chose to import the workspace that came with OpenTTCN Tester installation as

the workspace to use then OpenTTCN Tester should look like in the following

screenshot.

Figure 11: Automatic compilation after examples were added.

of 131



Starting OpenTTCN Tester also automatically starts seamlessly integrated

OpenTTCN virtual machine component which is responsible for running TTCN-3 test

cases.

Clicking the Go to workspace button after importing the examples lets you enter the

basic workbench for OpenTTCN Tester 2012. Here you can see the Navigator view

on the left, where you workspace projects are located. In the center is the TTCN-3

editor for editing test scripts and on the right is the Outline view that shows the high

level structure of the current module. At the bottom is visible the Console view where

Build Logs, Adapter Logs and Test Campaign Logs are stored and shown.

Figure 12: Default TTCN-3 view of OpenTTCN Tester.

In the tab folder with Console view is also Problems view, where compilation errors

and warnings are placed when compiling, in addition to being displayed in the Build

Log.

of 131



5.7 Stopping OpenTTCN Tester

OpenTTCN Tester can be stopped by selecting Exit from the File menu. When you

exit OpenTTCN Tester the following dialog is displayed.

Figure 13: Exit confirmation dialog.

Every time OpenTTCN Tester stops, the application will ask you to confirm the exit.

If you want the application to exit without confirmation, you can tick the “Always exit

without prompt” check box in the Confirm exit dialog.

Closing the OpenTTCN Tester window also automatically asks whether to stop the

system services component.

Figure 14: OpenTTCN background services stop dialog.

of 131



OpenTTCN System Services is a background component used by all OpenTTCN

tools. It is recommended to have it terminate with OpenTTCN Tester. If the system

services are left running, subsequent OpenTTCN Tester startups will be faster, but

some system resources will be consumed by the running services. NOTE: System

Services are shared between OpenTTCN Tester instances, and if using multiple

windows you should choose not to terminate them. System services are also required

if you wish to utilize the command-line tools without the graphical user interface (can

be also started separately with "ot start").

You can check "Remember my selection" to have your selection remembered and not

be prompted again. You can still change your preference from the menu Window ->

Preferences... and there navigate to OpenTTCN Tester -> Runtime tab shown in the

image below.

Figure 15: Runtime preferences.

of 131



6 Trying OpenTTCN Tester with Demo3 Example

OpenTTCN Tester comes with four different examples to try:

Demo3 (TTCN-3 code demonstrating the use of many TTCN-3 keywords)

ASN1 (demonstrating the use of ASN.1 definitions from TTCN-3 code)

This chapter explains necessary steps to compile and to run the Demo3 example. The

other examples can be run in a similar fashion.

You can recompile all provided example TTCN-3 projects by selecting Project ->

Clean… -> Clean all projects and click OK button. This will clean all TTCN-3

projects causing automatic rebuilding of them by compiling all TTCN-3 files in these

projects. When you first create the examples from the welcome screen, they should be

automatically compiled.

Alternatively, you can just clean the Demo3 project by selecting Project -> Clean… -

> Clean projects selected below, selecting Demo3 project, and then clicking OK

button. This would have cleaned and automatically built the Demo3 project only.

Figure 16: Clean projects dialog.

of 131



After you have clicked OK button, OpenTTCN Tester invokes the OpenTTCN

TTCN-3 just-in-time compiler. You can see the output of the compiler in the console

of the TTCN-3 perspective of OpenTTCN Tester.

After compiling the Demo3 project that came with OpenTTCN Tester you should get

the same result as shown in the following screenshot: “Demo3 – 0 error(s), 0

warning(s).”

Figure 17: Demo3 compilation results in build console view.

of 131



Now you are ready to run the examples. Let's run the test cases of Demo3 TTCN-3

project. There are total 205 test cases in the Demo3 example TTCN-3 project. You

can start the Demo3 test campaign, i.e. start execution of Demo3 test cases by

selecting Run -> Run configurations… and selecting Demo3 and clicking Run button.

When the test campaign to run Demo3 test cases starts, the OpenTTCN Tester

switches to a console that shows the produced detailed TTCN-3 test log. You can

follow the log in the console in real time as testing progresses as seen below.

Figure 18: Test log in text log view.

When the test campaign to run Demo3 test cases has finished, the OpenTTCN Tester

console shows you the end of the detailed TTCN-3 test log produced as shown in the

above screenshot. The test results should match those in the image: 209 Pass verdicts,

0 Fail verdicts, 0 Inconclusive verdicts, 0 None verdicts and 0 Error verdicts, totaling

test results for 209 test cases. For further information, see the next chapter.

of 131



You can also switch to see the output of TTCN-3 adapter used in another console with

the "Display Selected Console" button. Below you can see the adapter log. The

"Display Selected Console" button is circled in red.

Figure 19: Adapter output in adapter output console view.

of 131



6.1 Expected Results of Demo3 Test Campaign

The Demo3 example project demonstrates the use of TTCN-3 keywords.

The expected test results of the Demo3 test campaign are:

Pass Fail Inconc None Error Total Duration

211 0 0 0 0 211 00:00:28

There are 211 pass verdicts produced. The fail, inconc, none and error verdicts are not

shown in the examples, but you are encouraged to modify the examples to product

other test results as well. The Demo3 example is illustrating use of various TTCN-3

keywords.

The duration of the test campaign, here shown lasting thirty seconds, depends

partially on the speed of your computer. The above test results are achieved in

computer having one Intel Core 2 CPU 6700 @ 2.66GHz, 4GB RAM, and running

64-bit Windows 7 operating system.

6.2 Expected Results of ASN1 Test Campaign

The ASN1 example project demonstrates the use of ASN.1 definitions from TTCN-3

code.

The expected test results of the ASN1 test campaign are:

Pass Fail Inconc None Error Total Duration

1 0 0 0 0 1 00:00:01

of 131



7 Starting a New TTCN-3 Project

In the previous Chapter you have learned how to use and run pre-configured TTCN-3

examples that come with OpenTTCN Tester. In this chapter, you will learn various

tasks that are needed when creating and running your own TTCN-3 testing projects

and test campaigns.

The following chapters follow typical sequence how new testing project is set up.

7.1 Creating a TTCN-3 Project

If you want to work with a new set of TTCN-3 modules you need to create a TTCN-3

project for them first.

Create a new TTCN-3 project by selecting File -> New -> TTCN-3 Project.

Set project name4 to the name you want (here “Example”) and click “Finish” button.

You can see the created Example project in the Navigator View of OpenTTCN Tester.

4 The project name corresponds to the name of the testing session when the same information is used

from the command-line.

of 131



Figure 20: New TTCN-3 project dialog.

You have now created a new TTCN-3 project under the currently used workspace.

The Location in the above New Project dialog shows you the file system directory

location of the new project. The name of the TTCN-3 project can contain all the

characters allowed for file and directory names for file system in the supported

operating system.

The newly created Example TTCN-3 project is shown in the end of the OpenTTCN

Tester workspace navigator in the left side of your workbench, as seen in the

screenshot at the bottom of this page.

You do not have any TTCN-3 files in the TTCN-3 project yet. We see how new

TTCN-3 files can be created in the Chapter 7.2. In Chapter 7.3 we learn how to

import existing TTCN-3 files to your TTCN-3 project.

of 131



Figure 21: New “Example” project in navigator view.

of 131



7.2 Creating a TTCN-3 File

If you want to write a new TTCN-3 module you need to create a TTCN-3 file for that

TTCN-3 module first.

Create a new TTCN-3 file by right-clicking the name of the TTCN-3 project you want

the TTCN-3 file to be created in from the Navigator view and then select New ->

TTCN-3 File (shown circled below).

Figure 22: New TTCN-3 file pop-up menu.

Set module name to the name you want (we choose the default, “DemoModule”, here)

and click “Finish” button. Note that the name is the module name and not the file

name. The file will be named "ModuleName.ttcn" automatically. You can see the New

TTCN-3 File dialog below.

of 131



Figure 23: New TTCN-3 file dialog.

The New TTCN-3 File dialog also shows the TTCN-3 Project (here “/Example”)

under which the new file will be created. You can also create template code with an

simple test case skeleton and an example TTCN-3 control part5. Do this by ticking the

“Create template code” check box in the New TTCN-3 File dialog.

You can only place one TTCN-3 module to one file. OpenTTCN recommends naming

both the TTCN-3 module and the file using the same name. For example

DemoModule TTCN-3 module would be placed to DemoModule.ttcn file.

OpenTTCN and ETSI recommends using .ttcn file suffix for TTCN-3 files.

OpenTTCN Tester 2012 automatically uses .ttcn suffix for newly created files.

5 Please note that there can be only one TTCN-3 control part in one complete TTCN-3 test suite

(collection of modules) and that the TTCN-3 control part must be the last top-level definition of the

module according to TTCN-3 standard.

of 131



7.3 Importing TTCN-3 File(s)

If you already have TTCN-3 file(s) that you want to use you can import these files

from some other location in the file system to the TTCN-3 project you are working

on.

Import existing TTCN-3 files by first selecting

the TTCN-3 project you want the files imported

to by clicking the project name in the Navigator

view of the OpenTTCN Tester and then

selecting Import… from the right-click context

menu.

Expand “General” and then select “File System”

or "Archive File" by clicking the icons. Then

click Next> button.

Figure 24: Import dialog.

of 131



Select the files to be imported by first clicking Browse button and browsing and

selecting the desired directory or archive file (here C:\temp\ttcn3) and clicking OK

button. Then select the directory for import by placing a tick mark to the check box

next to the directory name in the left pane of the Import from File system dialog.

Alternatively you can select the individual files by placing the tick mark to the check

box next to the file name in the right pane of the Import from File system dialog as

shown in the image below.

Figure 25: Import from file system dialog.

Click the Finish button to start importing of the selected directories and/or files to the

TTCN-3 project.

of 131



7.4 Module Parameterization

Most test suites define module parameters to specify test system specific setup and to

select optional features. The values of these parameters must be specified before

executing a test campaign, which is done by defining their values in a module

parameter value file with the ".par" extension, later .par file for short.

The module parameter values are usually specified using filled Protocol

Implementation Conformance Statement (PICS) and Protocol Implementation eXtra

Information for Testing (PIXIT) forms as guides.

The module parameter values can be given in one .par file or the module parameter

values can be split to multiple .par files according to structure defined by the user, for

example, splitting implementation specific PICS parameter values to one file and test

setup specific PIXIT parameter values to one file. For example, pics.par file can be

added to TTCN-3 project together with pixit.par file.

All module parameter value files (.par files) in a single TTCN-3 project are re-

compiled (re-parameterized) when even one .par is saved from TTCN-3 editor in

OpenTTCN IDE or the TTCN-3 project is cleaned. After this operation, so called

module parameter repository contains explicitly given module parameter values.

When a test case is executed, each module parameter either keeps its default value, or

gets a value given in .par file. The value given in .par file takes precedence over any

default value given in module parameter declaration in TTCN-3 module.

7.4.1 Creating a Parameter File

To create a new parameter file you should first compile the desired test suite in

OpenTTCN Tester. After this, you can right-click the target project and select New ->

New TTCN-3 Parameter File to access the parameter file creation wizard.

of 131



The New TTCN-3 Parameter File wizard will automatically create a module

parameter file with the ".par" extension, and fill in information about all module

parameters defined by the test suite as currently compiled. You should go through the

generated file and set valid values for all parameters after this. In the wizard you can

specify the Module name (which will also become the filename). If you tick the

Uncomment default parameters and Uncomment undefined parameters options the

parameter definitions will be uncommented with the value set to a default value or

omit if no value is specified in the test suite.

Figure 26: Create new TTCN-3 parameter file dialog.

T

he generated parameter file contains documentation comments for the parameters

defined. The following table explains the meaning of the documentation comments:

@parameter Name of the parameter being defined.

@typeclass Base TTCN-3 type of the parameter.

@default Default value specified in the test suite.

@recordfield Lists fields of a record type. Each line specifies one field, with

field type first and field identifier second.

@unionvariant Lists union variants. Each line specifies one variant, with

of 131



variant type first and identifier second.

@enumlabel Lists enumeration identifiers. Each line specifies one identifier.

7.5 Compiling TTCN-3 Code

OpenTTCN Tester automatically compiles TTCN-3 code when the TTCN-3 file is

saved, if compilation is not explicitly disabled for the select TTCN-3 file. By default

files with file suffix of .ttcn, .ttcn3 and .asn1 are compiled automatically when the

file is saved.

You can disable compilation for TTCN-3 files by clicking the file in the navigator,

pressing right mouse button, and selecting OpenTTCN Compiler -> Disable

Compilation from the displayed context menu. After selecting Disable Compilation

the icon of the TTCN-3 file is changed from OpenTTCN icon to include a small red

and white “no entry” traffic sign.

When you change a TTCN-3 file in the editor, the application compiles it

automatically when the file is saved. This feature is called Automatic compilation and

is enabled by default. The feature can be toggled from the Project menu by changing

the Build automatically option. If this option is disabled you can run a build of your

source code by selecting Project -> Build All.

OpenTTCN recommends keeping automatic compilation enabled, unless working on

very large and complex test suites where builds may take a significant amount of

time. This should not usually be an issue as only the changed files and their

dependencies are recompiled with automatic compilation.

A changed file that has not yet been saved is indicated by “*” before the file name in

the TTCN-3 editor panel title.

of 131



Figure 27: Editing a new TTCN-3 module.

You can also select Project -> Clean... from menu bar and click OK button to clean

all projects. This causes a rebuild of all TTCN-3 projects that have some TTCN-3

files selected for compilation.

In the next page we write a small Hello world test case to be used in the examples

shown in the following Chapters.

of 131



We write a small Hello world test case consisting of log statement to display “Hello

world” and setverdict statement to set the verdict of this test case to pass as an

example. This test case is shown in the following screenshot.

After you save the file, you should see the “Example – 0 error(s), 0 warning(s)”

message in the Console.

Figure 28: Compiling a new TTCN-3 module.

The TC_HelloWorld test case is now checked for syntax and semantic errors and

compiled into the System Services repository ready to be executed by OpenTTCN

virtual machine.

of 131



7.6 Setting TTCN-3 Adapter Configuration (External Tools

Configuration)

You can set up a new external tools configuration for running OpenTTCN Adapter

built with one of the OpenTTCN SDKs by creating a new launch configuration.

Select Run -> External Tools -> External Tools Configurations… and then click New

launch configuration icon button to create a new TTCN-3 test campaign launch

configuration.

Then you should set information correctly for the Name, Location, Working

Directory, and possible Arguments. In the screenshot below we use the robo adapter

included with the OpenTTCN Tester distribution which echoes all messages sent to it

back to the test system.

of 131



Figure 29: External tools configuration dialog for configuring a new OpenTTCN adapter set-up.

Name: Change the “New configuration” to descriptive name of your adapter

configuration. Here: Example_Adapter

Location: Give the path name to the executable that you use as your TTCN-3 adapter.

Here: ${RoboBin}

Working Directory: Give the directory name that you want to use as working the

directory for your TTCN-3 adapter executable.

Here: ${workspace_loc:/Example}

Arguments: Give the possible command-line arguments for the TTCN-3 adapter

executable to be started. Here: -s ${OpenttcnAddress}:Example TRI TRI

of 131



You could also use ${OpenttcnStartingSession} instead of "Example" above to

automatically fill in the starting session when the adapter is launched with a test

campaign.

7.7 Setting Up TTCN-3 Test Campaign (Run Configuration)

You can set up a new run configuration for running TTCN-3 test campaign by

creating a new launch configuration.

Select Run -> Run configurations… and then click New launch configuration icon

button to create a new TTCN-3 test campaign launch configuration.

Then you should set information correctly for at least the Name and for the Main, Test

Plan, and Adapters panels.

of 131



Figure 30: Run configurations dialog for configuring a new test campaign.

Name: Change the “New configuration” to a descriptive name of your test campaign.

Here: Example_Campaign

Main: Select the Project to match the TTCN-3 Project you want to use for this

campaign. Here: Example

Test Plan: Select Run control part, Run all test cases, or Run selected test cases

depending on your needs.

of 131



Adapters: Select OpenTTCN TTCN-3 adapters you want to be automatically started

for this test campaign from the list. You can add new adapter configurations to the

displayed adapter list as explained in Chapter 7.6. After adding the adapter

configuration, complete your test campaign set-up by selecting the Adapters to start

up automatically for the test campaign. Here: Start the following adapters

automatically with Test Campaign and Example_Adapter selected from the Adapters

list.

Figure 31: Configuring start-up of adapters for a test campaign.

Please read the following wiki article explaining how to synchronize adapter startup

completion with the commencement of the test campaign:

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Synchronizi

ng_Adapter_Startup

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Synchronizing_Adapter_Startup

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Synchronizing_Adapter_Startup

of 131



Parameters (optional): Select parameter files that will be used to parameterize the test

campaign prior to commencement of the test run. By default, all parameter files in the

project not disabled for compilation will be used to parameterize a test run. Parameter

files explicitly selected through the Parameters tab of a Run configuration will be

taken into use even if they were disabled for compilation.

If you explicitly specify a set of applicable parameter files through the Parameters tab,

you may as well want to disable compilation of selected parameter files performed by

default as part of the Build project procedure to avoid identifier collision and error

reports caused by it. In the TTCN-3 Navigator tab right click on a parameter file or

folder containing parameter files for which disabling the compilation is desired, then

select OpenTTCN Tester | Disable compilation for TTCN-3 files (recursive).

Figure 32: Configuring parameters for a test campaign.

of 131



7.8 Running TTCN-3 Test Cases

You can run one or multiple test cases by using the test campaign set-up you have

created in Chapter 7.7.

Select Run -> Run Configurations and then select one of the test campaigns (under

OpenTTCN Test Suite) and click Run button.

The detailed TTCN-3 test log will be displayed in the Console and you can scroll the

test to see the details. The Console in the next screenshot shows the TTCN-3 test log

produced by running the Hello world example TC_HelloWorld test case.

Figure 33: Viewing test log in test run console view

of 131



8 Analyzing test results

This section explains tools OpenTTCN Tester provides to simplify analyzing test

results, whether they are passes or fails.

8.1 Stack trace view

A Stack trace is a snapshot of program execution showing the function call stack.

Stack traces are a useful debugging tool for complex test suites, where many levels of

functions are used. The OpenTTCN Tester stack trace view enables a test

management system to send the context in which a fail verdict occurred to the

graphical user interface, allowing a test suite writer or tester to quickly see where the

failure occurred.

The stack trace view requires communications from the test management application

to receive information about stack traces. Please refer to your test system vendors

manual to see if they support this feature.

of 131



The screenshot shows a part of TTCN-3 code that set a fail verdict, a stack trace

visible in test log that was produced as a result of the verdict and the stack trace view

at the bottom. The user can quickly jump around in the source code by double-

clicking the items in the stack trace view.

Figure 34: Stack trace view.

Your stack traces are saved between sessions automatically. To delete a stack trace,

press the -button. To clear all stack traces press the -button.

of 131



9 OpenTTCN GFT Log Viewer

OpenTTCN GFT Log Viewer provides the capability to store logs in XML format and

view them in graphical, structural, and text form. This chapter explains the basic

features of the GFT Log Viewer and provides examples of its use.

First, we demonstrate graphical log for a simple example test case involving message-

based communication and timers. Then we demonstrate graphical log for procedure-

based communication and parallel execution involving multiple parallel test

components.

9.1 Functionality of OpenTTCN GFT Log Viewer

OpenTTCN GFT Log Viewer allows viewing logs recorded during test campaign

execution in graphical format. TTCN-3 test campaigns are primarily supported.

Design of the graphical log output takes into account graphical presentation format

guidelines set forth by the ETSI ES 201 873-3 “TTCN-3 Graphical presentation

Format (GFT)” standard.

Logs suitable as a data source for graphical rendering performed by the Log Viewer

are stored in XML format in a persistent repository in the file system in the Eclipse

workspace. Persistent repository is implemented as a collection of plain folders and

files for easier processing and sharing of logs. Logs for individual test cases are stored

in XML format that complies with ETSI ES 201 873-6 standard XSD schema

definitions as defined in chapter “The TCI-TL interface” and annex “XML mapping

for TCI TL Provided” of the standard.

Graphical log and related structured log are displayed in the same collection of views

of the Log View Eclipse perspective. Correspondence between elements of graphical

log and structured log can be established by clicking on elements of the graphical log.

Detailed information about selected log event is displayed in the Log event view.

of 131



The following graphical elements of the GFT log are implemented:

message-based communication: send and receive operations, enqueued

message indication;

timer operations: start timer, stop timer, timer timeout;

procedure-based communication: call, getcall, reply, getreply, raise, catch;

verdict operations: setverdict;

display of ports and elements of port arrays that are actually involved in

communication operations;

display of functional diagrams for individual test components.

9.2 Using Example Test Suite

We will be using the gft_example project included in the OpenTTCN Tester

distribution. To access the example, you must first import the TTCN-3 code into the

workspace. When first starting OpenTTCN Tester, the welcome screen contains the

option to "Create example workspace". Select this option to create the example

projects including the gft_example project. If you have an existing workspace, either

create a new workspace for experiments, or select Help -> OpenTTCN Tester

Welcome Screen to access the welcome screen again, and create the gft_example

project.

The gft_example project is a simple test suite consisting of one test module. You can

run test cases included in the project by selecting the gft_example project launch

configuration from the list of launch configurations. The test campaign should execute

and you should receive pass verdicts.

9.2.1 Obtaining Graphical Log for the Example Test Campaign

Prior to running test cases, we need to make sure that XML logging and log storing

is enabled for the gft_example project launch configuration. Logs are stored in the

log repository as a collection of directories in the file system. Log repository is used

of 131



by the GFT Log Viewer as a data source for graphical rendering of diagrams and their

output.

Log storing can be enabled by opening launch configuration settings for the

gft_example as illustrated by Figure 35 and ticking the corresponding checkbox as

illustrated by Figure 36.

Enabling this option is necessary for obtaining graphical logs of test campaigns.

Figure 35: Opening launch configuration for gft_example.

of 131



Figure 36: Enabling log storing in the log repository.

Now we are ready to launch. Since the gft_example comes with a ready-made launch

configuration, simply select the gft_example launch configuration from the list of

launch configurations and run it.

9.2.2 Description of Test Cases in the Example Test Suite

There are three test cases in the gft_example test suite:

TC_Simple demonstrating message-based communication and timer

operations;

TC_Procedural demonstrating procedure-based communication;

TC_Concurrent demonstrating parallel execution involving multiple test

components.

of 131



In TC_Simple we:

start the T_GUARD timer (line 65);

activate the DefaultAltstep altstep to catch all kind of unexpected input

messages and unexpected timeout events (line 66);

perform mapping of main test component ports to test system interface ports

(lines 68-69);

send a couple of messages to ports of the loopback adapter (lines 71-73);

start the T_wait timer (line 75);

wait for receipt of a message on port p1 (lines 77-88);

wait for receipt of a message on port ps[1] (lines 90-101);

wait for the T_wait timer timeout event (line 103);

stop the T_GUARD timer (line 104).

Notice that message sent on line 72 to port ps[0] never comes back, because this port

is not mapped to a test system interface port.

In TC_Procedural, in addition to basic test case setup operations similar to those

described for TC_Simple, we:

perform a procedural call (line 125);

wait for a procedural call from the loopback adapter (lines 128-139).

In TC_Concurrent we:

create two test components (lines 167, 170);

connect ports of the main test component to ports of created parallel test

components (lines 168, 171);

start behaviour functions on created test components (lines 173-174);

send messages to started parallel test components from the main test

component (lines 176, 179);

wait for response from parallel test components (lines 177, 180);

wait for all parallel test components to terminate (line 182);

set the pass verdict (line 183).

of 131



9.2.3 Opening Log View Perspective for the Example Test Campaign

To be able to see GFT graphical logs generated during test campaign run, we need to

switch to Log View perspective from TTCN-3 perspective in Eclipse. This switching

is illustrated by Figure 37.

Figure 37: Switching from TTCN-3 perspective to Log View perspective.

9.3 Viewing Example Logs

9.3.1 Message-based, Procedure-based, and Timers

After Log View perspective is selected, you can view campaign logs as illustrated by

Figure 38 and Figure 39.

of 131



Figure 38: Graphical log: Message-based communication and timers.

Figure 39: Graphical log: Procedure-based communication.

of 131



Clicking on an event in the Graphical log panel selects corresponding event in the

Structured log panel and updates the Log event panel accordingly.

Elements of graphical log diagrams presented in Figure 38 and Figure 39 are shown in

detail in Figure 40.

(a) Main test component instance

(b) Port instance

(c) The start timer operation

(d) The send operation

(e) A message was received in port and enqueued to the end of an incoming input

queue of a port

of 131



(f) The receive operation

(g) The setverdict operation

(h) The timeout operation

(i) The stop timer operation

(j) The call operation

(k) The getcall operation

Figure 40: Magnified view of elements of graphical log diagrams.

of 131



9.3.2 Concurrent Execution Involving Parallel Test Components

To obtain a graphical log diagram for a particular test component in a test case run

involving multiple parallel test components, select the corresponding test case in the

Campaign browser panel, then expand the test case to show the list of test

components created during the test case execution, then select the test component in

question to show its graphical log representation as illustrated by Figure 41.

Figure 41: Obtaining graphical log diagram for a parallel test component.

of 131



10 OpenTTCN TTCN-3 Debugger

OpenTTCN TTCN-3 Debugger component provides the capability to debug TTCN-3

code at runtime. In the following, we explain the basic features of the debugger and

provide examples of debugging basic errors found in test suites.

At first brief description of OpenTTCN TTCN-3 Debugger functionality is given.

Next we demonstrate use of the debugger with a simple example test suite. Then we

demonstrate finding specific kinds of bugs from a test suite, such as deadlocks.

10.1 Functionality of OpenTTCN Debugger

OpenTTCN TTCN-3 debugger allows running TTCN-3 code in debug mode without

special debug compilation. Therefore all TTCN-3 code can be then run in debug mode

during TTCN-3 test case development and test case validation, allowing use of

debugger features with ease whenever needed. User can proceed debugging without

extra delay. Debugging is done in separate Eclipse Debug perspective.

The debugger allows setting break- and tracepoints by double clicking next to the

source code line of interest. Breakpoints allow suspending TTCN-3 test case

execution in order to allow examination of parameter and variable values at any given

line. Tracepoints allow inspection of parameter and variable values without

suspending the test case execution. Execution can be suspended when breakpoint is

hit, or when a user breaks execution manually. When the execution has been

suspended with the debugger, the execution can be continued with step in, step over,

step out, and continue instructions.

Multiple test components can be debugged in sequence. Test component to be

debugged can be selected from the list of available test components. This can be done

after the test execution has been suspended. Under the selected test component, the

user can select of specific stack frame for display of parameters and variable values of

that context.

of 131



10.2 Debugging the Example Test Suite

We will be using the Fibonacci example included with the OpenTTCN Tester

distribution. To access the example, you must first import the TTCN-3 code into the

workspace. When first starting OpenTTCN Tester, the welcome screen contains the

option to "Create example workspace". Select this option to create the example

projects including the Fibonacci project. If you have an existing workspace, either

create a new workspace for experiments, or select Help -> OpenTTCN Tester

Welcome Screen to access the welcome screen again, and create the Fibonacci

example.

The Fibonacci example is a simple one test suite consisting of one test case. It uses a

Parallel Test Component (PTC) as a Fibonacci calculating server that can be

requested to calculate the i'th number in the Fibonacci sequence (0,1,1,2,3,5,8,13 and

so forth, read more at http://en.wikipedia.org/wiki/Fibonacci_number). After the PTC

is started and synchronized, the MTC then sends it a request to calculate the 10th

number in the Fibonacci series, and the PTC complies, responding with 55.

You can run the test case by selecting its launch configuration from the list of launch

configurations. The test campaign should execute and you should receive one pass

verdict. Next let's look at how to run the test case in the debugger.

10.2.1 Executing test campaigns in the debugger

The debugger uses the same launch configurations as normal test campaign execution.

First we must however define a breakpoint at the location we wish to examine in the

debugger. Open the Fibonacci.ttcn file (under Fibonacci project) in the editor by

double-clicking it. Let us place a breakpoint at the point where the recursive

fibonacci_recursive() function is invoked by the PTC. Navigate to line 70 and double-

click the left margin to set a breakpoint. Alternatively you can right-click the margin

and select "Toggle Breakpoint".

http://en.wikipedia.org/wiki/Fibonacci_number

of 131



You can see to breakpoint set in Figure 42. The margin location you must double-

click to set the breakpoint is circled in red (Note that the line numbers are not visible

by default, you can turn them on by right-clicking in the text editing area, select

"Preferences..." and in the dialog tick "Show line numbers").

Figure 42: Set breakpoint on the highlighted line by double-clicking on the margin.

Now that we have our breakpoint set, let’s switch to the debug perspective: Click on

the icon near the top right corner of your workbench showing a table with a plus sign.

From the list of perspectives, select "Debug". You can see this illustrated in Figure

43.

Figure 43: Open the debug perspective by clicking the plus icon and selecting Debug.

of 131



Now we are ready to launch. Since the Fibonacci example comes with a ready-made

launch configuration, simply select the same launch configuration you used to execute

the test campaign normally from the list of debug configurations to start debugging.

The proper menu is shown in Figure 44.

Figure 44: Launch the Fibonacci launch configuration as a debug configuration from the debug

dropdown menu.

The test campaign should start and rapidly break at the breakpoint we set. In the next

chapter, we'll go over how the debug perspective looks after breaking on a breakpoint

and the operations you can perform there.

10.2.2 Debugging with the Debug Perspective

When a breakpoint is hit, the debug perspective automatically shows the line where

the break happened. In this case, it's the line where we set our only breakpoint. Figure

45 shows what the debug perspective looks like after hitting the breakpoint.

of 131



Figure 45: Debug perspective after hitting breakpoint.

Let’s run over the views visible on the debug workbench: On the top left is the Debug

view showing the currently running items. The Fibonacci test campaign is visible,

with two running test component, mtc and ptc1. From the toolbar in the Debug view

you can control the execution by breaking, continuing, terminating and stepping over

code. We'll get back to this later. Clicking on a stack frame will select that frame as

the active stack frame. The Variables and code views will be updated to show the

active stack frame.

On the top right of the perspective is the Variables and Breakpoints views. The

Breakpoints view is hidden in Image 4 behind Variables. The Breakpoints view

shows a list of active breakpoints, and you can also easily disable and remove

breakpoints there. The Variables view shows the variables in the active stack frame.

In this case its showing that the Fibonacci value we will be calculating (i) is 10.

of 131



In the middle is the code and outline views, that show the code for the current stack

frame. Modifications made here will not be reflected in the running code until the test

campaign is restarted. At the bottom is the test log for the test campaign.

10.2.3 Debugger Controls

You can control the execution of the test campaign with the debugger controls shown

in Figure 46, or by pressing the corresponding hotkeys. The following list refers to the

red numbers shown in the image 5:

1) Resume (F8): Resumes execution of the test campaign regardless of how it

was suspended.

2) Suspend: Suspends a running test campaign at the next opportune time. Mostly

used for debugging deadlock situations.

3) Terminate (Ctrl-F2): Terminates the test campaign.

4) Step In (F5): Steps the active stack frame one line at a time, entering into any

functions.

5) Step Over (F6): Steps the active stack frame one line at a time, skipping over

any function calls (moves directly to next line in current stack frame).

6) Step Out (F7): Steps out of current stack frame. Execution continues until

current stack frame returns to the previous level.

Figure 46: Control buttons in the Debug view.

of 131



Let's try these controls with our debugging session. We were suspended at the

breakpoint where the system is about to call fibonacci_recursive(10) for the first time.

Try stepping though the code to see how the Fibonacci calculation proceeds. Make

sure you have ptc1 as the active stack frame and press F5 once to enter the

fibonacci_recursive function. Now press F6 four times to skip over the input check,

the end condition check and the two recursive call to fibonacci_recursive(). You

should end up on the last line of the function with the return statement, as shown in

Figure 47.

Figure 47: View on screen after stepping through the fibonacci_recursive() function.

Here in the Variables view you can see the fibMinusOne variable contains the sum

34 from one branch of the recursion, while fibMinusTwo shows the sum 21 from the

other branch of recursion. 34+21 is 55, which is indeed the 10th number in the

Fibonacci series we are calculating (variable i). You can now press F8 to let the test

campaign continue execution till the end.

of 131



10.2.4 Debugger Summary

This simple example showed you how to navigate code in the debugger. As a test of

your skills, you could now try removing the break points set previously (e.g. through

the Breakpoints view) and set a new breakpoint at the end condition of the recursion.

This is line 40 as visible in Image 6 on the previous page, with the return i;

statement. If you now launch the debug session again, the execution will stop with

many levels of recursive calls of fibonacci_recursive() visible. You can click on the

stack frames to see the path the recursion has taken and see in the variables and their

values in each level of the stack.

If you press F8, the execution will continue until the next recursion hits the end

condition. Here you can see why this recursive algorithm is inefficient, as it will

recurse to the end condition very many times while calculating the same intermediate

results over and over, before arriving at a final result. You can also choose to use Step

Out (F7) and Step Over (F6) to work your way out from the recursive call one level at

a time and see how the end result is put together through the Variables view.

Debugging recursive code may be complex at times. Rest assured that it is much

easier to debug normal functional code.

of 131



10.3 Debugging Common Problem Scenarios

Here we go through debugging of common problem scenarios. A common problem in

debugging test system with any level of parallelism, whether from Parallel Test

Components (PTCs) or a non-synchronous System Under Test (SUT).

10.3.1 Debugging Test Case Deadlocks

Deadlocks can occur when dealing with Parallel Test Components (PTCs). Our

Fibonacci example conveniently uses a PTC for calculations, so let's introduce a

deadlock into the PTC and see how the debugger helps in solving it.

10.3.2 Introducing the Deadlock

Let us comment out the terminating condition for the PTC, causing it to ignore the

termination message from the MTC. Find the line containing the code terminate :=

true; in the PTC behavior function fibonacci(). This should be located on line 67 as

shown in Figure 48. Place two slash characters before the line to comment it out ("//")

and save the document to compile the changes.

Figure 48: Line commented out to introduce a deadlock into the test.

Make sure your test session isn't still running and that you don't have any breakpoints

set (delete all breakpoints if there are any).

of 131



10.3.3 Debugging the Deadlock

After the setup in the previous chapter, you are ready to start debugging the deadlock

issue. Launch the debug session as previously. This time the test campaign will not

break, since we did not set any break points. It does not reach its natural end either. It

is deadlocked.

To start solving the problem, select the launch in the Debug view and press the

Suspend button (looks like a pause button, with two yellow vertical bars). The test

execution will suspend, showing you that there are two test components running. Let's

look at what they are doing to find where the deadlock is. Start by clicking on the

topmost stack frame in mtc. The code shows that it is waiting for a PTC to be done.

From the variables view we can see it has already calculated the Fibonacci number,

and from the comment on the previous line we know it has already sent a message to

the PTC to terminate.

Based on the previous, let's see what the PTC is doing. Select the topmost stack frame

of ptc1 in the Debug view. It is waiting to receive a message. Looking at the

variables, you can see that the previous received message was -2 which is the

termination message, but the variable terminate is still false.

This trail leads us right to the line we commented out, which was supposed to set the

terminate flag to true when the terminate message is received. Now that we've found

the problem, remove the comment sign in front of the terminate line to remove the

bug and press save to compile the changes. To terminate the still deadlocked test

campaign, you must press the red stop button in the Debug view. Finally, you can

launch the test campaign again in Debug mode to confirm that it indeed runs through

smoothly once again.

of 131



11 OpenTTCN Adapter Library

OpenTTCN has packaged ready to use TTCN-3 adapters as OpenTTCN Adapter

Library so that OpenTTCN users can avoid writing commonly used adapters. By re-

using TTCN-3 adapters from OpenTTCN Adapter Library OpenTTCN users can

faster implement new test system from tested and proven components maintained by

OpenTTCN. These adapters implement TTCN-3 SUT adapter functionality to send

and receive messages using the interface or protocol. These adapters also include a

number of existing codec components that allow integration with complete adapters

without programming or with limited programming.

Now, commonly used interfaces of:

serial port,

UDP socket,

TCP socket, and

HTTP

can be taken into use without programming, simply by starting OpenTTCN Serial

(otserial.exe), UDP (otudp.exe), TCP (ottcp.exe), or HTTP (othttp.exe) adapter from

OpenTTCN IDE or from command-line both in Windows and in Linux. These

adapters are located in <install path>/bin directory. The interface of these adapters is

defined in <install path>/lib/ttcn/AdapterLib.ttcn TTCN-3 module.

In addition, users can easily write new TTCN-3 adapters by deriving and sub-classing

SerialPort, UdpPort, TcpPort, or HttpPort C# classes that represent the TTCN-3 ports

of Serial, UDP, TCP, and HTTP adapters of OpenTTCN Adapter Library

respectively. This allows creating new adapters that implement new TTCN-3 ports or

combine multiple TTCN-3 ports into one adapter.

Alternatively, users can use the full power of TTCN-3 Runtime Interface (TRI) and

program the adapter from scratch using OpenTTCN SDK for C#, C++, ANSI C, or

Java. Writing OpenTTCN SUT adapters is easy by following the “HOW TO” articles

of adapter programming published in http://wiki.openttcn.com.

http://wiki.openttcn.com/

of 131



All four language mappings of TTCN-3 TRI interface (C#, C++, ANSI C, and Java)

are available with all OpenTTCN Tester editions without extra cost. This allows

implementing each adapter with the most suitable programming language. Adapters

written in different programming languages can be used in the same test system

without difficulty.

OpenTTCN also offers SIP Adapter (Session Initiation Protocol specified in IETF

RFC 3261) and CORBA Adapter as option for OpenTTCN Tester.

The adapters of OpenTTCN Adapter Library can be used with OpenTTCN provided

or user written codec component. The OpenTTCN provided codec components are

explained in the following chapter 12.

11.1 Overview

Adapters from OpenTTCN Adapter Library can be used by starting adapter

executables or by using the adapter C# port classes as starting point when

programming your own adapters. Starting existing adapters as executables allows use

of common transports (serial port, UDP, TCP, and HTTP) without programming.

Programming your own adapters allows greater flexibility for the adapters and better

productivity by re-using existing code.

You can use codec from OpenTTCN Codec Component Library with UDP, TCP, or

HTTP Adapter including:

Direct (Encoding) Codec,

XML Codec,

BER Codec, or

Custom codec.

In the following chapters, adapters in the OpenTTCN Adapter Library are described

in detail.

of 131



11.2 Serial Adapter

Serial Adapter is OpenTTCN TTCN-3 Serial (USB or RS232) SUT adapter for

sending and receiving serial traffic. Serial Adapter was originally developed for

issuing AT commands for mobile phones during mobile phone testing. The adapter is

addressed using either COM ports or devices depending on the operating system.

Serial Adapter is taken into use in your own TTCN-3 module by the following import

statement:

import from AdapterLib { group Serial };

See <install path>/lib/ttcn3/AdapterLib.ttcn for the interface of the Serial Adapter.

In addition the following libraries need to be added into your TTCN-3 compilation:

-lAdapterLib –lUsefulTypes

Start otserial.exe without command-line options for help about the options needed to

start OpenTTCN Serial Adapter.

11.3 UDP Adapter

UDP Adapter is OpenTTCN TTCN-3 UDP SUT adapter for sending and receiving

UDP packets with remote hosts. The adapter can act as both UDP server and client

depending on the needed set-up. The adapter allows handling UDP packets up to 64K.

Both IPv4 and IPv6 addresses are supported when addressing remote hosts.

UDP Adapter is taken into use in your own TTCN-3 module by the following import

statement:

import from AdapterLib { group UDP };

See <install path>/lib/ttcn3/AdapterLib.ttcn for the interface of the UDP Adapter.

of 131





Start otudp.exe without command-line options for help about the options needed to

start OpenTTCN UDP Adapter.

11.4 TCP Adapter

TCP Adapter is OpenTTCN TTCN-3 TCP SUT adapter for sending and receiving

traffic using TCP connections with remote hosts. The adapter can act as both TCP

server and client depending on the needed set-up. The adapter supports multiple

preconfigured modes for handling TCP connection establishment and release

including connection establishment when traffic is sent, or using user sent connection

control messages. The adapter also supports multiple operating modes including

packet, stream, and various operating modes required by HTTP protocol. In addition,

the user can easily program additional operating modes based on existing hook

methods. Both IPv4 and IPv6 addresses are supported when addressing remote hosts.

TCP Adapter is taken into use in your own TTCN-3 module by the following import

statement:

import from AdapterLib { group TCP };

See <install path>/lib/ttcn3/AdapterLib.ttcn for the interface of the TCP Adapter.



Start ottcp.exe without command-line options for help about the options needed to

start OpenTTCN TCP Adapter.

of 131



11.5 HTTP Adapter

HTTP Adapter is OpenTTCN TTCN-3 HTTP SUT adapter for sending and receiving

HTTP requests and responses with remote hosts. The adapter can act as both web

server and browser (client) depending on the needed set-up. The adapter supports

multiple modes. Both IPv4 and IPv6 addresses are supported when addressing remote

hosts.

HTTP Adapter is taken into use in your own TTCN-3 module by the following import

statement:

import from AdapterLib { group HTTP };

See <install path>/lib/ttcn3/AdapterLib.ttcn for the interface of the HTTP Adapter.



Start othttp.exe without command-line options for help about the options needed to

start OpenTTCN HTTP Adapter.

11.6 Customizing Your Own Adapter

Sometimes the provided adapter executables are not providing some detail needed. In

these cases you can create new adapters by re-using the C# classes of the existing

serial, UDP, TCP, and HTTP adapters and customize their behavior using C# code.

The adapter implementation using adapter framework (C# classes implementing the

adapter library) is described in the following article:

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Creating_Ad

apters_with_Adapter_Framework

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Creating_Adapters_with_Adapter_Framework

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Creating_Adapters_with_Adapter_Framework

of 131



12 OpenTTCN Codec Component Library

OpenTTCN has packaged ready to use TTCN-3 codecs (TTCN-3 coding and

decoding implementations) as OpenTTCN Codec Component Library so that

OpenTTCN users can avoid writing codec for commonly used transfer syntaxes. By

re-using TTCN-3 codecs from OpenTTCN Codec Component Library OpenTTCN

users can faster implement new test system from tested and proven components

maintained by OpenTTCN. These codecs implement TTCN-3 coding and decoding

functionality to encode and decode messages and parameter lists of procedures and

external functions.

Now, commonly used transfer syntaxes of:

Direct Encoding (transfer syntax used by ETSI for describing encoding of bit

protocols used in GSM and 3G protocols, etc. applicable also for Internet

Protocol messages defined using bit fields),

XML,

ASN.1 BER, and

ASN.1 PER

can be taken into use by instantiating a codec component from the adapter of

command-line or from C# / C++ source code, depending on the codec component.

Alternatively, users can use the full power of TTCN-3 Control Interface – Coding and

Decoding (TCI-CD) and program custom codec from scratch using OpenTTCN SDK

for C#, C++, ANSI C, or Java. Writing OpenTTCN codec is easy by following the

“HOW TO” articles of adapter programming published in http://wiki.openttcn.com.

All four language mappings of TTCN-3 TRI interface (C#, C++, ANSI C, and Java)

are available with all OpenTTCN Tester editions without extra cost. This allows

implementing each codec with the most suitable programming language. Codecs

written in different programming languages can be used in the same test system

without difficulty as long as the SUT adapter is written in the same programming

language also.


of 131



OpenTTCN also offers SIP Adapter (Session Initiation Protocol specified in IETF

RFC 3261) and CORBA Adapter as option for OpenTTCN Tester. These adapters

contain special SIP codec and CORBA CDR codec handling the special encoding and

decoding needs of these protocols.

12.1 Overview

Codecs from OpenTTCN Codec Component Library can be used by starting adapter

executables or by instantiating the codec components from the adapter C# code when

programming your own adapters. Starting existing adapters as executables allows use

of common transfer syntaxes (Direct Encoding, XML, and BER) without

programming. Programming your own adapters allows greater flexibility for the

codecs and better productivity by re-using existing code.

You can use codec from OpenTTCN Codec Component Library with UDP, TCP, or

HTTP Adapter including:

Direct (Encoding) Codec,

XML Codec,

BER Codec, or

Custom codec.

In the following chapters, codecs in the OpenTTCN Codec Component Library are

described in detail.

12.2 Direct Codec for Direct Encoding of Bit Protocols

Direct Codec is OpenTTCN TTCN-3 Direct Encoding Coding and Decoding

providing Direct Encoding transfer syntax encoding and decoding as defined by ETSI

specifications such as LTE test documentation. Direct Encoding is based on guidance

given by encode attributes from standard TTCN-3 libraries such as ETSI UsefulTypes

of 131



or ETSI CommonLib or from similar attributes used in the user's own type

definitions.

The Direct Codec has been successfully applied for writing codecs for multiple

protocols including: DNS, DHCP, ICMP, and IGMP.

Direct Codec Component is identified by the:

http://www.openttcn.com/Codecs/2012/Direct URI when it is instantiated.

You can find more information about the use of Direct Codec from the following

article:

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Direct_code

c_explained

Direct Codec is replacing Standard Codec in OpenTTCN Tester as the recommended

tool for encoding and decoding of bit protocol messages.

12.3 XML Codec

XML Codec is OpenTTCN TTCN-3 XML Coding and Decoding providing XML

transfer syntax encoding and decoding for structures generated by XML Schema to

TTCN-3 translator.

The XML Codec is successfully applied for writing codecs for multiple protocols

including: Netconf, TR069, and multiple customer specific protocols.

XML Codec Component is identified by the:

http://www.openttcn.com/Codecs/2011/XML URI when it is instantiated.

You can find more information about the use of XML Codec from the following

article:

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Direct_codec_explained

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Direct_codec_explained

of 131



http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Creating_NE

TCONF_Over_SOAP_XML_Codec

12.4 BER Codec

BER Codec is a dynamic TTCN-3 coding and decoding library provided as C# library

allowing user friendly encoding and decoding of ASN.1 data using Basic Encoding

Rule (BER) transfer syntax. No generated code. If ASN.1 definitions are changed,

only recompilation of ASN.1 definitions and restart of TTCN-3 adapter are necessary.

BER Codec is available in Professional Edition and Enterprise Edition.

The BER Codec is successfully applied for writing codecs for multiple protocols

including: CMPv2 (Certificate Management Protocol), SNMPv2 (Simple Network

Management Protocol), SNMPv3, and payment card related protocol based on EMV

standard.

BER Codec Component is identified by the:

http://www.openttcn.com/Codecs/2011/BER URI when it is instantiated.

You can find more information about the use of BER Codec from the following

article:

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Creating_SN

MP_BER_Codec

12.5 PER Codec

PER Codec is a dynamic TTCN-3 coding and decoding library provided as C++

library allowing user friendly encoding and decoding of ASN.1 data using Packet

Encoding Rule (PER) transfer syntax. No generated code. If ASN.1 definitions are

changed, only recompilation of ASN.1 definitions and restart of TTCN-3 adapter are

necessary. PER Codec is available in Professional Edition and Enterprise Edition.

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Creating_NETCONF_Over_SOAP_XML_Codec

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Creating_NETCONF_Over_SOAP_XML_Codec

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Creating_SNMP_BER_Codec

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Creating_SNMP_BER_Codec

of 131



Please note the PER codec currently supports the unaligned PER transfer syntax and

that it available for C/C++ code using ANSI C API.

The PER Codec is successfully applied for writing codecs for multiple protocols

including: DSRC (Digital Short Range Communication), and EFC (Electronic Fee

Collection) application.

PER Codec Component is identified by the:

http://www.openttcn.com/Codecs/2011/PER URI when it is instantiated.

Contact [email protected] for more information and example about the use of PER

codec.

12.6 Writing Your Own Codec Component

After you have implemented a regular TTCN-3 coding and decoding using C# or

C++, turning that codec to OpenTTCN codec component is easy task by

implementing a few extra codec component specific operations. The codec

component implementation is described in the following article:

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Writing_Cus

tom_Codec_Component


http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Writing_Custom_Codec_Component

http://wiki.openttcn.com/media/index.php/OpenTTCN/Knowledge_base/Writing_Custom_Codec_Component

of 131



13 Java adapter development using OpenTTCN Tester 2012 GUI

13.1 Overview

If you installed the complete package including SDK for Java, the OpenTTCN Tester

2012 GUI may be used for Java adapter development. This is done using the popular

Eclipse Java Development Tools, which are included in the package. This chapter

provides a tutorial to the Java development by going through the examples included

with the OpenTTCN Java Development Kit.

To begin with, let's assume that you have OpenTTCN Tester 2012 running and you

have created the example workspace from the welcome screen. In order to develop

TTCN-3 adapters using Java, we have a couple of steps to be performed:

1. Create a Java project or import an existing project to the workspace. In this

example we import existing projects.

2. Setup the build path to OpenTTCN SDK for Java library and corresponding

javadoc documentation.

3. Start writing Java code!

13.2 Importing a Java project

Because some of the OpenTTCN Java development kit examples are supplied as

Eclipse projects, they can be imported into the workspace as-is. From the main menu,

select File -> Import... and an import wizard will be launched. In this wizard, select

General -> Existing Projects Into Workspace as shown in the next figure.

of 131



Figure 49: Import dialog.

After clicking Next in the import dialog, you will be presented with the Import

Projects window. There are three points of interest, illustrated in the subsequent

figure:

Root directory. Select the OpenTTCN Tester 2012 Installation

Path/sdk4java/examples.

Project selection. This list contains the Eclipse projects that were found inside

the root directory. Here we can see the hello example.

Copy projects into workspace. Checking this selection instructs eclipse to

create a local copy of all the data files. This is recommended in order to

prevent potential problems with file access permissions as well as to keep

things simple: all your data files are inside the workspace.

of 131



Figure 50: Importing adapters projects to workspace.

Select the projects as shown in the figure and click Finish to proceed with the import.

13.3 Setting up Java compilation

After the import finishes, you will be taken back to the main workbench view. In this

case, the examples contain both TTCN-3 code and Java code. The example projects

have the OpenTTCN nature and compiler enabled by default, and therefore the

TTCN-3 code will be built straight after import. This can be seen in the build log. To

enable Java compilation, there are a couple of steps to be taken:

of 131



Switch to Java perspective

Setup path to OpenTTCN SDK libraries

To switch the perspective, click on the Open perspective button in the top-right

corner, as shown in the next figure.

Figure 51: Switch perspective button.

From the perspective list select Other... and then Java from the list. In the Java

perspective, you will notice an error icon at the freshly imported projects, as well as

several problems in the Problems tab. These are illustrated in the next figure.

of 131



Figure 52: Problems tab for adapter compilation problems.

These problems are caused by not having the build path set to OpenTTCN SDK

libraries, and may be corrected by setting up the build path as follows:

1. Right-click on the project java_hello_example

2. Select OpenTTCN Tester -> Setup Java SDK build path

After this, the errors will disappear and the adapters will be built automatically. At

this point the IDE will compile either TTCN-3 or Java files, depending on the

perspective. To go back to editing TTCN-3, select the TTCN-3 perspective at the top

right corner. In order to run the examples entirely within the GUI, there is one more

step to be taken: Launch configurations. Chapters 7.6 and 7.7 describe the process of

creating the launch configurations, and the next section discusses the options specific

to Java adapters developed inside the OpenTTCN Tester 2012 GUI.

of 131



13.4 Running Java adapters

First of all, it is important to note that the .bat script files inside the example projects

are not suitable for running the adapter, compiling the test suite or running the tests

from the GUI. The .bat files are only intended to be used from the command line.

Compared to other adapters, the Java adapters can be considered somewhat a special

case. There are two reasonable options for running them, each with their benefits and

downsides:

Option 1: OpenTTCN adapter launch configuration

Adapter launch configurations are described in chapter 7.6, and the same procedure

may be applied for Java adapters that are built within the GUI. Once set up, this

method allows convenient, automatic adapter startup during the test campaign startup.

However, the setup requires moderate amount of work, making it less ideal for a

quick test. On other hand, the option 2 described below is quick and convenient to set

up, but requires manual startup of the adapter before test execution.

In the first approach, the OpenTTCN adapter configuration must start java.exe (as

opposed to the typical adapter.exe) with appropriate arguments which will instruct the

JVM to start the adapter. This procedure is not really specific to OpenTTCN Tester,

and therefore is not covered here in detail, but the start_adapter.bat supplied with the

examples may be used as a starting point. Java.exe must be provided with path to the

OpenTTCN.SDK.jar, jacorb.jar, slf4j-api-1.5.6.jar, and slf4j-jdk14-1.5.6.jar as well as

to the javac output directory.

Option 2: Start as Java application

The second approach utilizes the built-in Eclipse Java Development environment

tools to launch the application. To begin, click the arrow at the Run as.." toolbar

of 131



button to open the launch configurations and select the Run Configurations.." menu

item. This is illustrated in the following figure.

Figure 53: Run configuration for Java adapter.

In the Run Configurations window, right-click the Java Application and select New.

Fill the relevant fields, particularly in the Main tab. This adapter requires no

arguments, and therefore we only need to fill the main tab, as shown below.

of 131



Figure 54: Setting up a run configuration for Java adapter.

Once the adapter run configuration is set up, we may proceed to actually executing

the example. Following the instructions in chapter 7.7, set up also a run configuration

(OpenTTCN Test Suite) for the java_hello_example project. Only the project has to

be selected, all other default values are fine. It is also recommended to select the

"Display in favorites menu" option on the Common tab.

Finally, go back to the TTCN-3 perspective and then launch first the adapter and then

the test execution from the Run as... dropdown menu on the toolbar. If everything was

configured correctly, the adapter will start in one of the windows inside the Console

view (as described in chapter 6), and the test execution log is shown in another

console view. The test will fail with a timeout if no SUT is running. Please refer to

README.txt and start_sut.bat found in the SDK installation hello example directory

for instructions on starting the SUT used in this example.

of 131



14 Command-line Tools Quick Reference

The next two pages give short “how-to” instructions for people who want a quick start

into the command-line tools of OpenTTCN Tester. You are recommended to use the

graphical user interface for normal operation, the command-line is provided for the

convenience of advanced users.

14.1 Controlling System Services

Multiple test campaigns can be run while the testing server is running. In Linux

platform the testing server can be started on the operating system start-up, and kept

running until rebooted. The graphical user interface automatically starts the system

services, and requires them to be running during operation.

Start a testing server for a single session: ot start

Stop a testing server: ot stop

Finding out OT ID that identifies your license key: ot id

14.2 Session Management

Sessions correspond to the project name in the graphical user interface. Test

scripts are automatically imported to a session with the name of the project when

compiled. You should select a session name that does not conflict with OpenTTCN

Tester GUI project names for command-line use.

Create a testing session: session create SessionName3

List available testing sessions: session list

Delete a testing session: session delete SessionName3

14.3 Loading modules

Loading a TTCN-3 module: importer3 load SessionName3 ModuleName.ttcn

Loading an ASN.1 module: importer3 load SessionName3 ModuleName.asn1

of 131



14.4 Running test cases

Running all test cases of a module: tester run SessionName3 @all

Running TTCN-3 control part: tester run SessionName3 @control

Running a test case: tester run SessionName3 TC_while

Running a list of test cases: tester run SessionName3 TC_if TC_for TC_while

14.5 Loading values of module parameters

Loading of values of module parameters needs to be done only if values differing

from the default values of module parameters are used.

Loading TTCN-3

module parameters: importer3 param SessionName3 ParameterFile.par

14.6 Handling errors

Stopping a test case/tester: Press Control-C

(For example if a test case hangs)

of 131



14.7 Typical Commands Sequences

The testing server shall be running before issuing any of the following commands.

Instructions how to start a testing server are given in section 14.1, above.

1. Commands given to start a SUT Adapter and register the adapter to a testing

session

depends on the SUT Adapters used6, for example: startif

a testing session name to where the adapter is registered is specified in the

above start-up script, after this registration the tester and the SUT Adapter

can communicate; the tester can issue a “map” operation to SUT Adapter,

and communication using “send”, “receive”, and procedure-based

communication operations is possible

2. importer3 load SessionName3 ModuleName.ttcn

a test suite in a file ModuleName.ttcn is loaded to SessionName3 session

3. tester run SessionName3 @all

all test cases in the test suite loaded to SessionName3 session are executed

6 By OpenTTCN Ltd convention, the test system interface start-up command is put to a file that is

called in Linux “start_adapter.sh” or “startif.sh”, and in Windows

“start_adapter.bat” or “startif.bat”.

of 131



15 Testing Using OpenTTCN Tester command-line

Testing using OpenTTCN Tester command-line utilities follows seven steps:

1. Starting a Test System (if it is not running already),

2. Selecting a Testing Session,

3. Setting Up a Tester for Testing New Implementation,

4. Checking Feasibility of Starting Full Testing,

5. Running All Tests,

Stopping a Test Campaign

6. Reviewing Tests Results,

7. Stopping a Test System (if no further tests are to be run).

This chapter describes how to accomplish these steps.

15.1 Starting Test System

A complete OpenTTCN Tester based test system consists of the server part of

OpenTTCN Tester, and SUT and Platform Adapters.

To start an OpenTTCN test system you need to perform the following operations in

sequence:

1. Start the server part of OpenTTCN Tester,

2. Start SUT and Platform Adapters, and optionally standalone Coding and

Decoding.

of 131



15.1.1 Starting the Server Part of OpenTTCN Tester

Starting the server part of an OpenTTCN Tester is the first step to start an OpenTTCN

test system.

Instructions:

Issuing “ot start” command starts the server part of an OpenTTCN Tester.

During the start-up of the server part of the OpenTTCN Tester, the “ot start”

command launches an “openttcnd” daemon process in the background and returns

silently if no errors occurred.

15.1.2 Starting SUT and Platform Adapters and Coding and Decoding

Starting the SUT and Platform Adapters and standalone Coding and Decoding is the

last step to start an OpenTTCN test system.

The start-up instructions for the SUT and Platform Adapters and standalone Coding

and Decoding depend on the specific adapters. Please consult the end-user

documentation of the adapters for instructions how to start them. Coding and

decoding co-located in another adapter is started together with the adapter in question.

Generic start-up instructions for SUT and Platform Adapters and Coding and

Decoding usually include starting the executable(s) that implements the SUT Adapter,

the Platform Adapter, and the Coding and Decoding, and the adapters register

themselves directly to a specific testing session.

of 131



15.2 Selecting Testing Session

If the OpenTTCN Tester you are using is a part of a complete test system coming

from integrator or value added reseller, the test system usually comes with a number

of pre-configured testing sessions and you can select the testing session you want to

use by specifying the testing session name for the commands that you issue. The first

step you can do is to find out a list of available testing sessions.

Instructions to list available testing sessions:

Issuing “session list” command displays a list of available testing sessions.

When you have found out the name of the test session, this testing session name is

specified as the second parameter for each command, i.e. “importer3 load Demo3

demo3.ttcn”, “tester run Demo3 @all”, etc.

A user of OpenTTCN Command-Line Utilities may work with multiple currently

active testing sessions at a time. A user can create and delete sessions, and ask a

current status of a session. A testing session holds information about used modules,

values of module parameters, and addresses of SUT and Platform Adapters and it can

be referred by a testing session name.

Sessions correspond to projects in the graphical user interface. Any changes to the

session from the command line will also change the session in the graphical user

interface.

Instructions to create a testing session:

Issuing “session create Demo3” command creates a new testing session with a name

“Demo3”.

of 131



Instructions to ask a current status of a testing session:

Issuing “session status Demo3” command shows the current status of an existing

testing session with a name “Demo3”.

Instructions to delete a testing session:

Issuing “session delete Demo3” command deletes an existing testing session with a

name “Demo3”.

15.3 Compiling TTCN-3 and ASN.1 Modules

New test suites including TTCN-3 and ASN.1 modules needs to be compiled and

loaded to OpenTTCN test suite repository before testing can be performed. The

loading process includes syntax check, semantic checks, and compilation of the

source code to intermediate OpenTTCN FS format that can be used by test

components implementing OpenTTCN virtual machine. When the test case is started

the final just in time type of compilation is performed by the test component from the

intermediate OpenTTCN FS format taken from the test suite repository.

The test suites and TTCN-3 and ASN.1 modules are held in the OpenTTCN test suite

repository until they or the test session they are held is erased.

Loading a TTCN-3 module: importer3 load SessionName3 ModuleName.ttcn7

Loading an ASN.1 module: importer3 load SessionName1 ModuleName.asn1

Instructions to load a new TTCN-3 module:

Loading a new TTCN-3 module is a simple one step process, loading a module to a

test suite repository that is associated to a testing session. Instructions to perform this

are in the following.

7 ETSI recommends “.ttcn” file prefix to be used for files storing TTCN-3 modules written in TTCN-3

Core Language.

of 131



Issuing “importer3 load Demo3 demo3.ttcn” command loads a module using

TTCN-3 core notation format from a file “demo3.ttcn” to a testing session with a

name “Demo3”.

Instructions to load multiple TTCN-3 modules to the same testing session:

Multiple TTCN-3, modules can be loaded to the same testing session. Multiple

modules can be loaded by placing all loaded modules to same list and invoking a

single “importer3 load” command. In this case all dependencies are automatically

resolved between the modules based on correct TTCN-3 import statements included

in the modules.

Example: Loading multiple modules at once:

importer3 load ModuleDemo mod1.ttcn mod2.ttcn mod3.ttcn

Multiple modules can be loaded by invoking separate “importer3 load” commands for

each TTCN-3 module. In this case, the user needs to make sure that the modules are

loaded in such order that all dependencies can be resolved between the modules. This

means that a module can be loaded only if you have already loaded modules that this

new module is dependent on.

Example: Loading multiple modules in sequence:

importer3 load ModuleDemo mod1.ttcn



The above example assumes that mod1.ttcn is totally independent of other two

modules, the mod2.ttcn can depend on mod1.ttcn, and the mod3.ttcn can depend on

mod1.ttcn and mod2.ttcn.

Instructions to load a new ASN.1 module:

of 131



Loading a new ASN.1 module is a simple one step process, loading a module to a test

suite repository that is associated to a testing session. Instructions to perform this are

in the following.

Issuing “importer3 load asn1 DemoTypes.asn1” command loads a module using

ASN.1 syntax format from a file “DemoTypes.asn1” to a testing session with a name

“asn1”.

Multiple ASN.1 modules can be loaded to the same testing session. The ASN.1

modules need to be loaded before any TTCN-3 modules that are depended on the

ASN.1 definitions.

15.4 Test Parameterization

When a new Implementation Under Test (IUT) is tested using OpenTTCN Tester

command-line tools, you need to inform the OpenTTCN Tester about the special

implementation options and implementation specific values this new implementation

is using in order to specialize the used test suite for testing this particular

implementation.

This process of information the tester about which optional features are implemented

and which specific values are used when a range of values are allowed by the standard

is called Test Parameterization.

In the Test Parameterization, the claimed implemented optional capabilities and

specific values used in the Implementation Under Test are first recorded in the

Protocol Implementation Conformance Statement (PICS) document that is then used

to give correct values to module parameters. The module parameters are then used to

parameterize the used Abstract Test Suite (ATS) so that it can be used for testing.

Similarly, some extra information needed for testing is first recorded in the Protocol

Extra Information for Testing (PIXIT) document that is then used to give correct

of 131



values to some module parameters. This extra information may include addresses and

description of some capabilities of the test system.

Preparations:

1. Fill in a PICS Proforma document producing a PICS document

2. Fill in a PIXIT Proforma document producing a PIXIT document

3. Extract values of module parameters from the filled PICS and PIXIT

documents to a module parameters file. The module parameters file is in

TTCN-3 Core Language format and gives a list of values of module

parameters with their name, type, and value. The values used shall describe

properties of the Implementation Under Test or the test system.

Instructions to load values of TTCN-3 module parameters:

Loading a new set of values of TTCN-3 module parameters is a simple one step

process, loading a set of values of module parameters to a parameter repository that is

associated to a testing session. Instructions to perform this are in the following.

Issuing “importer3 parameterize Demo3 parameters.par” command loads a new

set of values of module parameters from a file “parameters.par” to a testing session

with a name “Demo3”.

If no syntax errors are found in the parameters, the values of the module parameters

are loaded to testing session. Otherwise, the command will display an error message

to show the error details.

15.4.1 Using Multiple Par Files

Normally, it is simplest to keep module parameter values in a single value as

described in the previous chapter. In some cases, it is necessary or feasible to split

module parameter values to multiple module parameter value (.par) files. Using

of 131



multiple .par files requires special attention when using “importer3 parameterize”

command.

Instructions to load values of TTCN-3 module parameters from multiple files:

Loading a new set of values of TTCN-3 module parameters can be accomplished

during one step process or by invoking multiple commands with special append

option.

One step process to load module parameter values from multiple files:

Issuing “importer3 parameterize DemoX parameters1.par parameters2.par

parameters3.par” command loads a new set of values of module parameters from

three module parameter value files “parameters1.par”, “parameters2.par”, and

“parameters3.par” to a testing session with a name “DemoX”.

Multi-command process to load module parameter values from multiple files:

Issuing the following three commands loads a new set of values of module parameters

from three module parameter value files “parameters1.par”, “parameters2.par”, and

“parameters3.par” to a testing session with a name “DemoX”. Please note that the

first command is without and the last two commands are invoked with (-a) append

option.

“importer3 parameterize DemoX parameters1.par“

“importer3 parameterize -a DemoX parameters3.par“

“importer3 parameterize -a DemoX parameters3.par“

of 131



15.5 Checking Feasibility of Starting Full Testing

Before starting a full Test Campaign, it is better to check if this is feasible. This can

be simply done by selecting a couple of test cases with simple test purposes that any

stable Implementation Under Test should handle. These test cases are called Basic

Interconnection Tests (BIT) which are simple tests selected from the whole set for this

purpose. If the most simple test cases found errors or there is a test system set-up

problem that is detected, there is no use continue testing further, before these

problems are first corrected.

Instructions:

First, start those test cases with “tester run” command that you want to run as Basic

Interconnection Tests. Look for the list of these test cases in the end-user

documentation of your test system.

For example, issuing “tester run Demo3 TC_1 TC_2” command starts testing using

information in “Demo3” testing session, and starts a list of test cases as specified in

the end of the command, here two test cases, “TC_1”, and “TC_2” are started.

If all of these simple test cases show “pass” verdict, you are more ready to run the

remaining test cases. Any “fail” verdicts usually indicate problems in the

Implementation Under Test. Any “inconc” verdicts usually indicate problems in the

test system set-up.

15.6 Running All Tests

In the conformance testing of a protocol, it is customary to run all possible test cases

as the testing can be automated.

Instructions to run all TTCN-3 test cases:

Issuing “tester run Demo3 @all” command starts testing using information in

“Demo3” testing session, and starts all test cases in the test suite associated with the

of 131



used testing session. This form of running all tests can be used for TTCN-3 test cases.

When TTCN-3 test cases are executed from command-line, the TTCN-3 test cases

shall not have parameter lists.

Instructions to run a TTCN-3 control part:

Issuing “tester run Demo3 @control” command starts testing using information in

“Demo3” testing session, and starts all test cases in the test suite associated with the

used testing session under the control of TTCN-3 control part. This form of running

all possible tests can be used for TTCN-3 test cases only, because only TTCN-3 test

suite contains a control part used by this command. If TTCN-3 test cases are

executed, the TTCN-3 test cases may have parameter lists.

The execution of all test cases may take seconds or hours depending on the number

and the type of the test cases used.

The following chapter discusses how the test results are reviewed.

15.6.1 Stopping Test Campaign

You can prematurely terminate a running test campaign by pressing Control-C where

the tester command is executing, and the issuing “tester terminate” command in the

same window to stop the testing server.

Instructions to stop a test campaign:

Issuing “tester terminate Demo3” command stops test campaign currently running

using information in “Demo3” testing session.

of 131



15.7 Reviewing Tests Results

Test results can be reviewed in two phases. First by getting an overview of the test

results of the last test campaign, and then if necessary, review the conformance log of

an individual test case.

15.7.1 Reviewing Test Result Summary

After a test campaign with one or more test cases has been executed, a summary of

the test results is displayed. This allows the user to see a summary of the execution

results of the most recent test campaign.

Example:

tester run Demo3 @all : : a few to thousands of log lines later : ************************************************************ *** TEST EXECUTION SUMMARY Pass Fail Inconc None Error Total Duration 211 0 0 0 0 211 00:00:28

of 131



Instructions:

In the end of log produced by “tester run” command, you can see a summary of the

test results of the previous Test Campaign. Get an overview of the test result and

proceed accordingly. The following list gives instructions how to proceed in different

situations.

Symptoms Action

Any “error” verdict Problem in the test system or the test system is used

incorrectly; determine the cause of this with the technical

support of your test system.

Many “inconc” verdicts. Problem in the test system set-up, check that you have installed

and configured the test system correctly and that you are using

right testing project and correct set of module parameters. Re-

run the test cases that produced “inconc” verdicts to see if the

problem persists.

Many “fail” verdicts. Problem in the Implementation Under Test; determine the

cause for this many “fail” verdicts before you continue.

Many “pass” verdicts, some “fail”

verdicts, few “inconc” verdicts.

Problem in the Implementation Under Test; typical situation in

the first round of testing. First check that you are using the

right testing project and correct set of module parameters. Re-

run the test cases that produced “fail” and “inconc” verdicts to

see if the problem persists.

All “pass” verdicts. No indications of non-conformance has been found in the

Implementation Under Test.

Table 1: Possible actions after different types of test results

The summary information displayed in the Reports tab consists of the following:

Pass: shows the number of test cases that produced a “pass” verdict. The

“pass” verdicts shows that no indication of non-conformance has been found

from the IUT,

Fail: shows the number of test cases that produced a “fail” verdict. The “fail”

verdict shows that indication of non-conformance has been found from the

IUT,

Inconc: shows the number of test cases that produced an “inconc”

(inconclusive) verdict. The “inconc” verdict shows that it cannot be concluded

of 131



weather the IUT shows indication of non-conformance or the IUT shows no

indication of non-conformance,

Error: shows the number of test cases that produced an “error” verdict. The

“error” verdict shows possible problem in the test system,

None: shows the number of test cases that has not produced any verdict,

Total: shows the total number of test cases in the test suite. The total number

of test cases should be the same as the number of test cases in Pass, Fail,

Inconc, Error, and None columns added together, and

Duration: shows the duration of the test campaign execution.

15.7.2 Reviewing Assigned Verdicts

The conformance logs should be viewed to see the details how a test case was

executed and to review the assigned verdicts. These logs need to be created by re-

directing the tester command output to a file, so that the created conformance logs can

be later inspected.

Instructions to save conformance log:

Issuing “tester run Demo3 @all > Demo3.log” command starts testing using

information in “Demo3” testing session, starts all test cases in the test suite associated

with the used testing session, and saves the conformance log to a log file named

“Demo3.log” in the current directory.

Alternative instructions to save conformance log in Linux:

Issuing “tester run Demo3 @all | tee Demo3.log” command in Linux command

prompt starts testing using information in “Demo3” testing session, starts all test cases

in the test suite associated with the used testing session, and both displays the

conformance log to the display and saves it to a log file named “Demo3.log” in the

current directory.

The next chapters will explain actions necessary for different verdicts.

of 131



15.7.2.1 Reviewing Test Case with PASS Verdict

A test case with a “pass” verdict shows that no indication of non-conformance has

been found. No manual review of test logs in this case is needed, unless you want to

see an example how successful test case execution is recorded to a conformance log

or you want to double check the log.

15.7.2.2 Reviewing Test Case with FAIL Verdict

A test case with “fail” verdict shows that an indication of non-conformance has been

found.

When a “fail” verdict is given for a test case, this has a side effect from the fact that

an error may have occurred in the IUT. After a test case execution produces a “fail”

verdict, the test results of the test campaign following this test case cannot be trusted.

The Test Campaign may be run to completion, but the results of the test cases after

the one that produced the first “fail” verdict may be invalid. If a “fail” verdict is

found, the whole test campaign shall be executed after the error has been correct to

produce accurate results for those test cases that that were executed after the one that

produced a “fail” verdict. This property results from the principles used in ISO/IEC

9646 testing standards.

15.7.2.3 Reviewing Test Case with INCONC Verdict

A test case with “inconc” (inconclusive) verdict shows that it cannot be concluded

weather the IUT shows indication of non-conformance or the IUT shows no

indication of non-conformance.

A detailed inspection of test log and regressions testing is needed to determine the

reason of this verdict. The cause of “inconc” verdict can be a set-up or configuration

problem of the test system.

of 131



15.7.2.4 Reviewing Test Case with ERROR Verdict

A test case with “error” verdict shows a problem in the test system.

As the complete test system consists of OpenTTCN Tester, SUT and Platform

Adapters, the test suite used, and the values of module parameters, the cause of

“error” verdict can be in any of these parts. Contact your first level technical support

to determine the cause of this verdict. The occurrence of this type of verdict should be

rare, but it also shows the correct behavior of the test system, as internal errors are

shall be detected and recorded.

15.8 Stopping Test System

This chapter gives instructions how to stop a complete OpenTTCN test system that

consists of the server part of OpenTTCN Tester, and SUT and Platform Adapters.

To stop OpenTTCN test system, perform the following operations in sequence:

1. Stop SUT and Platform Adapters and Coding and Decoding,

2. Stop Server Part of OpenTTCN Tester.

The following chapters give instructions for the above operations.

15.8.1 Stopping SUT and Platform Adapters and Coding and Decoding

Stopping the SUT and Platform Adapters and standalone Coding and Decoding is the

first step to stop an OpenTTCN test system.

The stopping instructions for the SUT and Platform Adapters and standalone Coding

and Decoding depend on the specific adapters. Please consult the end-user

documentation of your test system how to stop these adapters.

of 131



Generic stopping instructions for the SUT and Platform Adapters and standalone

Coding and Decoding usually include un-registering the Platform Adapter address,

the SUT Adapter address, and the Coding and Decoding address from the OpenTTCN

Tester, and after that, stopping the executable(s) that implement the SUT and Platform

Adapters and the Coding and Decoding.

Instructions to un-register SUT and Platform Adapter addresses:

Issuing “session unregister Demo3 TRI” command un-registers a combined SUT

and Platform Adapter from an existing testing session with a name “Demo3”.

Instructions to un-register standalone Coding and Decoding address:

Issuing “session unregister Demo3 TCI_CD” command un-registers a standalone

Coding and Decoding adapter from an existing testing session with a name “Demo3”.

Instructions to stop SUT and Platform Adapters:

Issuing “session stop Demo3 TRI” command stops a combined SUT and Platform

Adapter from an existing testing session with a name “Demo3”.

Instructions to stop standalone Coding and Decoding adapter:

Issuing “session stop Demo3 TCI_CD” command stops a standalone Coding and

Decoding from an existing testing session with a name “Demo3”.

15.8.2 Stopping the Server Part of OpenTTCN Tester

Stopping the server part of an OpenTTCN Tester is the last step to stop an

OpenTTCN test system. The graphical user interface will perform this automatically.

Instructions:

Issuing “ot stop” command stops the server part of an OpenTTCN Tester.

of 131



16 OpenTTCN Command-line Reference

The OpenTTCN command-line utilities consist of set of commands for test control:

“ot”, “session”, “tester”, “importer3”, and “importer2”. These commands control

the test execution of the server part of OpenTTCN Tester.

16.1 The “ot” Server Start-Up Utility

The ot server start-up utility controls OpenTTCN Testing Server, i.e. the server part of

OpenTTCN.

The command options of “ot” are:

start,

stop,

status,

id

help.

Each command option is described in the following sections.

16.1.1 Start a Testing Server

The “ot start” starts an OpenTTCN Testing Server. If there are no errors in the start-

up, the command returns silently. When the tester has been started, other test control

commands, i.e. “session”, “tester”, “importer3”, and “importer2” can be issued.

Multiple testing sessions can share the testing server.

Command Syntax and Example:

ot start

of 131



16.1.2 Stop a Testing Server

The “ot stop” stops a running OpenTTCN Testing Server. The command performs a

safe testing server termination including saving testing session data to be used when

the tester is started next time. If there are no errors in the stopping of testing server,

the command returns silently.


ot stop

16.1.3 Inquiry of a Testing Server Status

The “ot status” prints the status of an OpenTTCN Testing Server.

Command Syntax:

ot status

Example 1 – OpenTTCN server is running normally:

ot status

OpenTTCN server is running.

Example 2 – OpenTTCN server is not started; or it is already stopped or terminated:

ot status

OpenTTCN server is not running.

of 131



16.1.4 Print License Key OpenTTCN Identification

The “ot id” command prints a license key OpenTTCN identification (OT ID) number

uniquely identifying your license key. The format is xxx-xxx, where x is digit from

range 0-9.


ot id

16.1.5 Print Command-Line Help

The “ot help” command or “ot” command without any arguments prints a list of

available commands of this tool and allowed arguments.


ot help

16.2 Session Utility

Session utility controls information about current testing session, i.e. information that

is used to execute a test campaign.

The command options of session tool are:

create

delete,

register,

unregister,

stop,

status,

list,

version

help.


of 131



16.2.1 Create a Session

The “session create” command creates a new testing session with the specified name

to be used to store various pieces of information used during a following test

campaigns and separate this information from the information used in different test

campaigns that can be executed in sequence or in parallel by the same test system.

A testing session can be created explicitly by the “session create” command or

implicitly by the “importer3 load” or “importer2 load” command.

The session stores the following pieces of information:

test suite (consisting of TTCN-3 and ASN.1 modules),

optionally values for module parameters8,

address of the Platform Adapter9, and

address of the SUT Adapter10

.

Command Syntax:

session create session_name

Example:

session create Demo3

8 Module parameter is a term used in association with TTCN-3.

9 Platform adapter is a term used in TTCN-3 architecture about an entity which implements TTCN-3

external functions.

10 SUT adapter is a term used in TTCN-3 architecture about an entity which implements TTCN-3 test

system interface and ports.

of 131



16.2.2 Delete a Session

The “session delete” command deletes the testing session and deletes or releases all

information associated to it such as the test suite, values of module parameters, and

addresses of SUT and Platform Adapters.

Command Syntax:

session delete session_name

Example:

session delete Demo3

16.2.3 List Sessions

The “session list” command lists all available test sessions.


session list

of 131



16.2.4 Show a Session Status

The “session status” command gives a report of the specified testing session. The

“session status” command will tell the status of:

parameter repository: if a parameter repository is registered or not,

main test component: if a main test component is registered or not,

adapters: registered SUT and Platform Adapters, interface server(s), and

operation server,

suites and modules: list of loaded TTCN-3 and ASN.1 modules.

Command Syntax:

session status session_name

Example:

session status Demo3

16.2.5 Unregister a Test System Interface

A SUT or Platform Adapter can be programmed to register the address of the adapter

to a named testing session. After the execution of the program implementing a SUT

Adapter finishes the registration of the adapter in the testing session needs to be un-

registered.

The un-registration of a testing session needs to be done in order to avoid conflicts

due to having the save adapter address registered to multiple testing sessions or

having an invalid adapter address still registered to a testing session after the

execution an adapter has been already terminated.

The use of “TRI” as the identifier of the test system interface designates to the tester

that all sub-interfaces of the TRI (i.e. both triCommunication (for SA) and triPlatform

(for PA)) maybe found by using this identifier. The use of “TRI_SA” as the identifier

of the test system interface designates to the tester that only the triCommunication

of 131



(for SA) sub-interface is found by using this identifier. For more detailed explanation

of the use of the identifier of the test system interface, refer to the Table 2, below.

TRI TRI_SA TRI_PA Semantics

- - - Both SA and PA are undefined.

- - “TRI” defines both SA and PA.

- - “TRI_SA” defines SA, PA is undefined.

- “TRI_SA” defines SA, “TRI” defines PA.

- - “TRI_PA” defines PA, SA is undefined.

- “TRI_PA” defines PA, “TRI” defines SA.

- “TRI_SA” defines SA, “TRI_PA” defines PA.

“TRI_SA” defines SA, “TRI_PA” defines PA,

“TRI” not used.

Table 2 Semantics of registering SUT and platform adapters using predefined “TRI”, “TRI_SA”,

and “TRI_PA” test system interface identifiers from the perspective of a test component

Un-registering the address of the SUT adapter in the testing session is done by

invoking the “session unregister“ command.

The “session unregister” command removes a registration of a test system interface

from the specified testing session.

The argument “pco_name“ is the identifier of the test system interface used. The

“TRI” identifier is used for the TTCN-3 test system interface.

Command Syntax:

session unregister session_name pco_name

The parameters of the command are the name of the testing session (e.g.

“UdpSession”), and the identifier of the test system interface (“TRI_SA” or “TRI”).

of 131



Example:

Command to un-register the address of the SUT adapter in the testing session

session unregister UdpSession TRI_SA

More examples:

session unregister Demo3 TRI

session unregister Demo3 TRI_PA

16.2.6 Print Version Information

The “session version” command prints the version number of this tool.


session version


The “session help” command or “session” command without any arguments prints a

list of available commands of this tool and allowed arguments.


session help

of 131



16.3 Tester Utility

Tester utility controls the execution of the test cases.

The command options of tester tool are:

run

terminate

version

help


16.3.1 Run Tests

The “tester run” command starts a test campaign and runs the requested test cases

and produces a detailed conformance log to standard output. The command can be

give one test case name or a list of test case names. The command also understands

special “@all” and “@control”11

options.

The “@all” option causes all the test cases in the associated test suite to be run.

The “@control” option causes test cases in the associated test suite to be run under

the control of TTCN-3 control part.

The “tester run” command initializes the tester automatically by invoking an

initialization command that previously was issued separately. This initializes the

tester from the information in the session at the time of initialization. The information

supplied to the testing session prior to the initialization is used, and changes to the

testing session does not take effect until the next tester initialization except the new

11 The “@control” option is available only for TTCN-3 test suites.

of 131



registrations of test system interface. The tester reads the current test system interface

address information from the test session before each test case is executed.

Command Syntax:

tester run session_name testcase_name+

tester run session_name @all

tester run session_name @control

Examples:

tester run Demo3 TC_while

tester run Demo3 TC_while TC_if TC_for

tester run Demo3 @all

tester run Demo3 @control

The “tester run” command accepts various options between the “tester run” and the

name of the session. A current list of these options and detailed information how they

are used can be found by invoking “tester help” command.

16.3.2 Print Version Information

The “tester version” command prints the version number of this tool.


tester version


The “tester help” command or “tester” command without any arguments prints a list

of available commands of this tool and allowed arguments.


tester help

of 131



16.4 Importer3 Utility

The importer3 utility controls the use of TTCN-3 and ASN.1 modules. The importer3

utility is used to load TTCN-3 and ASN.1 modules and values of TTCN-3 module

parameters into a repository from which the tester accesses parameterized test cases

just before tests are run. Other modules can share information from the loaded

modules using the TTCN-3 import statement.

The command options of importer utility are:

load

parameterize

help.


16.4.1 Load Test Suite

The “importer3 load” command loads a TTCN-3 test suite or other TTCN-3 or

ASN.1 modules into a repository. Each module is loaded to specified testing session,

or if the session does not exist, it is created automatically. If the session exists but

there is another module already loaded using the same module identifier, the

command replaces the old module with the new one.

A module is expected to be in ASN.1 format, if the file suffix is “asn” or “asn1”12

,

otherwise TTCN-3 Core Language format is expected instead.

When a module that requires definitions from other modules is loaded, all modules

that are referenced by TTCN-3 import statement by this module need to be already

loaded to the same testing session or they need to be specified in the same command

line when invoking a “importer3 load” command.

12 Also “ASN” and “ASN1” file suffixes denote ASN.1 files.

of 131



Command Syntax:

importer3 load session_name module_name+

Examples:

importer3 load Demo3 demo3.ttcn

importer3 load Demo3 demo3.ttcn module1.ttcn module2.ttcn

16.4.2 Analyse a Test Suite

The “importer3 load” command performs a syntax and semantic analysis for the

specified TTCN-3 test suite or TTCN-3 or ASN.1 module. The semantic analysis is

invoked only if the syntax analysis does not find any syntax errors.

16.4.3 Suite Using TTCN-3 Module Parameters

The “importer3 parameterize” command loads values of TTCN-3 module

parameters from file in TTCN-3 Core Language format13

into a repository. The

values of module parameters loaded to specified testing session, or if the session does

not exist, it is created automatically. If the session exists but there are other parameter

values already loaded using the same parameter names, the command replaces the old

parameters values with the new ones.

Command Syntax:

importer3 parameterize session_name parameter_file_name

importer3 param session_name parameter_file_name

Example:

importer3 param Demo3 parameters.par

13 Only one “module” section can exist in that file, in addition to optional “group” sections.

of 131




The “importer3” command without any arguments prints a list of available

commands of this tool and allowed arguments.


importer3

of 131



17 Using TTCN-2 Compiler Option with OpenTTCN Tester

OpenTTCN Tester 2012 offers TTCN-2 compiler as a separate option. This option is

enabled by updating the license key a new license having this option enabled.

Compliance: TTCN-2 compiler option supports TTCN-2 language standardized by

ISO 9646-3:1998 and ITU-T X.292:1998 standards as described in OpenTTCN Tester

2012 release notes.

TTCN-2 compiler features:

compilers TTCN-2 test suites,

accepts .MP (machine processable) files for compilation,

supports TTCN-2 (Tree and Tabular Combined Notation) testing language,

supports ASN.1 language both embedded to TTCN-2 test suites and as

separate modules,

compiler users TTCN-3 adapters (SUT adapter, platform adapter, and coding

and decoding) when communicating with System Under Test (SUT), and

translates TTCN-2 types, PDUs, and ASPs to TTCN-3 type definitions to

facilitate programming the necessary adapters.

TTCN-2 .MP files can be compiled using command-line tools or using OpenTTCN

IDE. In the following command-line instructions are given. If you want to use

OpenTTCN IDE, please first create a TTCN-3 project, and then drag-and-drop or

import the TTCN-2 .MP file to the TTCN-3 project by following the instructions

given in this user guide.

Compiling TTCN-2 test suite:

ot start

importer2 load <session name> <.MP file name>.mp

e.g. importer2 load MAC MAC_OBU.mp

of 131



Compiling ASN.1 modules and TTCN-2 test suite:

ot start

importer3 load <session name> <ASN.1 file name>.asn1

importer2 load <session name> <.MP file name>.mp

e.g.:

importer3 load MAC *.asn *.asn1

importer2 load MAC MAC_OBU.mp

If there are no errors in the TTCN-2 compilation, you can proceed to program the

TTCN-3 adapters (SUT adapter, platform adapter, and coding and decoding) needed.

These adapters are programmed using the TRI and TCI-CD interfaces described in the

ETSI ES 201 873-5 (TRI) and ES 201 873-6 (TCI-CD) standards. If needed,

OpenTTCN provides adapter programming training or turn-key adapter projects.

Please note adapter projects range from a couple of days projects to multi-year

projects.

TTCN-3 SUT adapter is used to implement TTCN-2 SEND and RECEIVE

communication through TTCN-2 PCO with real System Under Test.

TTCN-3 platform adapter is used to implement TTCN-3 test suite operations.

TTCN-3 coding and decoding is used to implement encoding and decoding of needed

transfer syntax.

After you have compiled TTCN-2 test suite successfully, you can translate TTCN-2

types, PDUs, and ASPs to TTCN-3 type definitions to facilitate programming the

necessary adapters.

of 131



Translating TTCN-2 types, PDUs, and ASPs to TTCN-3 type definitions:

mkdir <new directory>

cd <new directory>

exporter3 export <session name>

e.g. exporter3 export MAC

The new directory now contains TTCN-3 files that shows the type definitions

needed for programming the adapters.

of 131



18 OpenTTCN Tester Configuration File

OpenTTCN Tester uses OpenTTCN.ini for configuring options used by different

OpenTTCN tools. By default the OpenTTCN.ini configuration file is located in

C:\ProgramFiles\OpenTTCN\Tester2012\etc (32-bit Windows) or C:\Program Files

(x64)\OpenTTCN\Tester2012\etc (64-bit Windows).

The default configuration file created during the installation contains the following

lines.

################### # OpenTTCN config # ################### # OpenTTCN Tester configuration file. ######################### # network configuration host = 127.0.0.1 port = 5500 ######### # paths install-path = C:\Program Files (x86)\OpenTTCN\Tester2012 # Path for variable data. Same as install-path by default. #instance-path = # java.exe (on linux just java) is a special name that causes searching the # system path to find the binary #java-runtime = java.exe ########### # features # Configure debug logging for tracking errors. # Valid values are between 0 and 40, higher being more verbose. #debug-level = 0 # Proxy configuration for internet connectivity. #proxy-address = ip_address:port # Supported proxy types are: HTTP, SOCKS4, SOCKS5 #proxy-type = HTTP #proxy-login = user:password # By default proxy settings are read from Internet Explorer settings. # Uncomment the line below to disable the use of proxy. #disable-proxy = yes

of 131



18.1 Changing configuration settings

To change a configuration setting:

1. stop OpenTTCN server, by closing the graphical user interface or by

typing: ot stop

2. change configuration setting from configuration file using a text editor

3. start OpenTTCN Tester

18.2 Commonly used configuration settings

Configuration Setting Description

host OpenTTCN server IP address. Default: 127.0.0.1. If you run

TTCN-3 adapters in different computer, this setting shall be

set to the real IP address of the computer.

port OpenTTCN server TCP and UDP port number. Default: 5500.

If the default port is reserved by some other application you

may need to change this setting to other available port.

install-path Directory where OpenTTCN Tester is installed and set by the

installer. Defaults: C:\Program Files\OpenTTCN\Tester2012

(32 bit Windows) and C:\Program Files

(x64)\OpenTTCN\Tester2012 (64 bit Windows)

instance-path Directory for variable data, such as system repository. Placed

in your home directory by default.

Table 3: Common configuration settings in the configuration file.

18.3 Java related configuration settings


java-runtime Java runtime executable program name. In Windows, the

system path is search for Java runtime, if java-runtime setting

is specified as java.exe. Default: java.exe (Windows)

Table 4: Java related configuration settings in the configuration file.

of 131



18.4 System configuration settings


debug-level Selects if OpenTTCN produces extra debugging information.

By default extra debugging information is not produced.

Default: 0

proxy-address Address of proxy to use for internet connection in

“ip_address:port” format.

proxy-type Type of proxy server. Supported values: HTTP, SOCKS4,

SOCKS5

proxy-login User and password for the proxy server in “user:password”

format.

disable-proxy By default the proxy may be autoconfigured from Internet

Explorer settings. Enabling this option will disable the use of

the autoconfigured proxy.

Table 5: System configuration settings in the configuration file.

The proxy configuration is automatically updated by OpenTTCN Tester during

startup of the graphical user interface, and it is recommended to edit the information

from the License Management dialog of OpenTTCN Tester.

of 131



19 Files Created by OpenTTCN

OpenTTCN Tester creates and/or appends data to the following kind of files during its

operation.

Test log files

OpenTTCN IDE saves text and graphical test log data to <workspace>\.metadata\

.plugins\com.openttcn.reprise.repository\data directory if user has selected Run > Run

Configurations… > Store log to log repository option. User can delete these files in

Log View perspective using Campaign browser by clicking Delete data of selected

campaigns (indicated by red X mark) button.

Compiler intermediate files

OpenTTCN Tester saves intermediate files with .fs file suffix resulting from

compilation of TTCN-3, etc. modules to var directory located in the instance

directory. User can delete these files while OpenTTCN Tester is not running, if user is

prepared to compile the necessary modules again.

Test case error list

OpenTTCN Tester appends test case error records to messages file in the logs

directory located in the instance directory. User can delete this file.

IDE problem log

If OpenTTCN IDE has problems it may append error information to

<workspace>/.metadata/.log file.

OpenTTCN recommends user to send this file to OpenTTCN together with version

information to facilitate debugging of IDE problems. User can delete this file.

of 131



Tester problem dump files

If OpenTTCN Tester command-line binary terminates abnormally in Windows, it

may create Windows process dump files to %temp% directory (use “cd %temp%”

command to get there) with name <name of command>_<timestamp>_<process

id>.dmp and <name of command>_<timestamp>_<process id>_full.dmp.

If OpenTTCN Tester command-line binary terminates abnormally in Linux, it may

create core files to current working directory. Usually user needs to allow creation of

core files for this to happen.

OpenTTCN recommends user to send these files to OpenTTCN together with version

information to facilitate debugging of tester problems. User can delete these files.

of 131



20 Contacting OpenTTCN

Please give us your feedback about OpenTTCN Tester 2012 and send your questions

using [email protected] e-mail address.

Latest user guides and training course materials can be found from:

http://www.openttcn.com/support/user-guides

Tutorials and articles about OpenTTCN use and programming can be found from:

http://wiki.openttcn.com

You can contact OpenTTCN sales by [email protected] e-mail.

OpenTTCN wishes you a good time using OpenTTCN Tester 2012!


http://www.openttcn.com/support/user-guides



openttcn tester user guide

Documents