OpenTTCN Tester User Guide

OpenTTCN Tester 2012 User Guide
VERSION 4.2.5 July 6, 2012
Contents
1 2 3 4 OVERVIEW OF OPENTTCN TESTER 2012 .................................................................................... 6 RELEASE HIGHLIGHTS OF OPENTTCN TESTER 2012 .................................................................... 7 PREREQUISITES FOR OPENTTCN TESTER ................................................................................... 8 OPENTTCN TESTER SYSTEM OVERVIEW .................................................................................... 9 4.1 4.2 4.3 SYSTEM SERVICES ............................................................................................................................ 9 USER INTERFACES ............................................................................................................................ 9 SUT AND PLATFORM ADAPTERS AND CODING AND DECODING .............................................................. 10 SUT Adapter .................................................................................................................... 11 Platform Adapter ............................................................................................................ 11 Coding and Decoding ...................................................................................................... 12
4.3.1 4.3.2 4.3.3 5
STARTING AND STOPPING OPENTTCN TESTER ........................................................................ 13 5.1 5.2 5.3 5.4 5.5 5.6 5.7 SELECTING A WORKSPACE ............................................................................................................... 14 INSTALLING OPENTTCN LICENSE KEY................................................................................................ 15 ACTIVATING OPENTTCN LICENSE KEY ............................................................................................... 16 PROXY CONFIGURATION.................................................................................................................. 19 ONLINE LICENSE VALIDATION .......................................................................................................... 20 OPENTTCN TESTER RUNNING ......................................................................................................... 22 STOPPING OPENTTCN TESTER ........................................................................................................ 25
TRYING OPENTTCN TESTER WITH DEMO3 EXAMPLE ............................................................... 27 6.1 6.2 EXPECTED RESULTS OF DEMO3 TEST CAMPAIGN ................................................................................. 31 EXPECTED RESULTS OF ASN1 TEST CAMPAIGN ................................................................................... 31
STARTING A NEW TTCN-3 PROJECT ......................................................................................... 32 7.1 7.2 7.3 7.4 CREATING A TTCN-3 PROJECT......................................................................................................... 32 CREATING A TTCN-3 FILE ............................................................................................................... 35 IMPORTING TTCN-3 FILE(S) ........................................................................................................... 37 MODULE PARAMETERIZATION ......................................................................................................... 39 Creating a Parameter File ............................................................................................... 39
7.4.1 7.5 7.6 7.7 7.8 8
COMPILING TTCN-3 CODE ............................................................................................................. 41 SETTING TTCN-3 ADAPTER CONFIGURATION (EXTERNAL TOOLS CONFIGURATION) ................................... 44 SETTING UP TTCN-3 TEST CAMPAIGN (RUN CONFIGURATION) ............................................................. 46 RUNNING TTCN-3 TEST CASES........................................................................................................ 50
ANALYZING TEST RESULTS ...................................................................................................... 51 Page 2 of 131

2012 OpenTTCN Ltd. All rights reserved.
8.1 9
STACK TRACE VIEW ........................................................................................................................ 51
OPENTTCN GFT LOG VIEWER................................................................................................... 53 9.1 9.2 FUNCTIONALITY OF OPENTTCN GFT LOG VIEWER .............................................................................. 53 USING EXAMPLE TEST SUITE............................................................................................................ 54 Obtaining Graphical Log for the Example Test Campaign .............................................. 54 Description of Test Cases in the Example Test Suite ....................................................... 56 Opening Log View Perspective for the Example Test Campaign ..................................... 58
9.2.1 9.2.2 9.2.3 9.3
VIEWING EXAMPLE LOGS ................................................................................................................ 58 Message-based, Procedure-based, and Timers .............................................................. 58 Concurrent Execution Involving Parallel Test Components ............................................. 62
9.3.1 9.3.2 10
OPENTTCN TTCN-3 DEBUGGER................................................................................................ 63 10.1 10.2 FUNCTIONALITY OF OPENTTCN DEBUGGER .................................................................................. 63 DEBUGGING THE EXAMPLE TEST SUITE ......................................................................................... 64 Executing test campaigns in the debugger ................................................................ 64 Debugging with the Debug Perspective ..................................................................... 66 Debugger Controls ..................................................................................................... 68 Debugger Summary ................................................................................................... 70
10.2.1 10.2.2 10.2.3 10.2.4 10.3
DEBUGGING COMMON PROBLEM SCENARIOS ................................................................................ 71 Debugging Test Case Deadlocks ................................................................................ 71 Introducing the Deadlock ........................................................................................... 71 Debugging the Deadlock ............................................................................................ 72
10.3.1 10.3.2 10.3.3 11
OPENTTCN ADAPTER LIBRARY ................................................................................................ 73 11.1 11.2 11.3 11.4 11.5 11.6 OVERVIEW .............................................................................................................................. 74 SERIAL ADAPTER ...................................................................................................................... 75 UDP ADAPTER......................................................................................................................... 75 TCP ADAPTER ......................................................................................................................... 76 HTTP ADAPTER ....................................................................................................................... 77 CUSTOMIZING YOUR OWN ADAPTER ............................................................................................ 77
12
OPENTTCN CODEC COMPONENT LIBRARY .............................................................................. 78 12.1 12.2 12.3 12.4 12.5 OVERVIEW .............................................................................................................................. 79 DIRECT CODEC FOR DIRECT ENCODING OF BIT PROTOCOLS ............................................................... 79 XML CODEC............................................................................................................................ 80 BER CODEC ............................................................................................................................ 81 PER CODEC............................................................................................................................. 81 Page 3 of 131

12.6 13
WRITING YOUR OWN CODEC COMPONENT ................................................................................... 82
JAVA ADAPTER DEVELOPMENT USING OPENTTCN TESTER 2012 GUI ...................................... 83 13.1 13.2 13.3 13.4 OVERVIEW .............................................................................................................................. 83 IMPORTING A JAVA PROJECT ....................................................................................................... 83 SETTING UP JAVA COMPILATION .................................................................................................. 85 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 14.2 14.3 14.4 14.5 14.6 14.7 15 CONTROLLING SYSTEM SERVICES ................................................................................................. 91 SESSION MANAGEMENT ............................................................................................................ 91 LOADING MODULES................................................................................................................... 91 RUNNING TEST CASES ................................................................................................................ 92 LOADING VALUES OF MODULE PARAMETERS ................................................................................... 92 HANDLING ERRORS ................................................................................................................... 92 TYPICAL COMMANDS SEQUENCES ................................................................................................ 93
TESTING USING OPENTTCN TESTER COMMAND-LINE ............................................................. 94 15.1 STARTING TEST SYSTEM ............................................................................................................. 94 Starting the Server Part of OpenTTCN Tester ............................................................. 95 Starting SUT and Platform Adapters and Coding and Decoding ................................ 95
15.1.1 15.1.2 15.2 15.3 15.4
SELECTING TESTING SESSION ...................................................................................................... 96 COMPILING TTCN-3 AND ASN.1 MODULES ................................................................................. 97 TEST PARAMETERIZATION .......................................................................................................... 99 Using Multiple Par Files............................................................................................ 100
15.4.1 15.5 15.6
CHECKING FEASIBILITY OF STARTING FULL TESTING ....................................................................... 102 RUNNING ALL TESTS ............................................................................................................... 102 Stopping Test Campaign .......................................................................................... 103
15.6.1 15.7
REVIEWING TESTS RESULTS ...................................................................................................... 104 Reviewing Test Result Summary .............................................................................. 104 Reviewing Assigned Verdicts .................................................................................... 106
15.7.1 15.7.2 15.8
STOPPING TEST SYSTEM........................................................................................................... 108 Stopping SUT and Platform Adapters and Coding and Decoding ............................ 108 Stopping the Server Part of OpenTTCN Tester ......................................................... 109
15.8.1 15.8.2 16
OPENTTCN COMMAND-LINE REFERENCE .............................................................................. 110 Page 4 of 131

16.1
THE OT SERVER START-UP UTILITY ......................................................................................... 110 Start a Testing Server ............................................................................................... 110 Stop a Testing Server................................................................................................ 111 Inquiry of a Testing Server Status............................................................................. 111 Print License Key OpenTTCN Identification .............................................................. 112 Print Command-Line Help ........................................................................................ 112
16.1.1 16.1.2 16.1.3 16.1.4 16.1.5 16.2
SESSION UTILITY ..................................................................................................................... 112 Create a Session ....................................................................................................... 113 Delete a Session ....................................................................................................... 114 List Sessions .............................................................................................................. 114 Show a Session Status .............................................................................................. 115 Unregister a Test System Interface .......................................................................... 115 Print Version Information ......................................................................................... 117 Print Command-Line Help ........................................................................................ 117
16.2.1 16.2.2 16.2.3 16.2.4 16.2.5 16.2.6 16.2.7 16.3
TESTER UTILITY ...................................................................................................................... 118 Run Tests .................................................................................................................. 118 Print Version Information ......................................................................................... 119 Print Command-Line Help ........................................................................................ 119
16.3.1 16.3.2 16.3.3 16.4
IMPORTER3 UTILITY ................................................................................................................ 120 Load Test Suite ......................................................................................................... 120 Analyse a Test Suite ................................................................................................. 121 Suite Using TTCN-3 Module Parameters .................................................................. 121 Print Command-Line Help ........................................................................................ 122
16.4.1 16.4.2 16.4.3 16.4.4 17 18
USING TTCN-2 COMPILER OPTION WITH OPENTTCN TESTER ................................................ 123 OPENTTCN TESTER CONFIGURATION FILE ............................................................................. 126 18.1 18.2 18.3 18.4 CHANGING CONFIGURATION SETTINGS ........................................................................................ 127 COMMONLY USED CONFIGURATION SETTINGS .............................................................................. 127 JAVA RELATED CONFIGURATION SETTINGS .................................................................................... 127 SYSTEM CONFIGURATION SETTINGS ............................................................................................ 128
19 20
FILES CREATED BY OPENTTCN ............................................................................................... 129 CONTACTING OPENTTCN ...................................................................................................... 131

Page 5 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 justin-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.
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.

Page 6 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.
Page 7 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.

Page 8 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.

Page 9 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.

Page 10 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.

Page 11 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.

Page 12 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.

Page 13 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.

Page 14 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.

Page 15 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.

Page 16 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 support@openttcn.fi 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.

Page 17 of 131
Figure 6: OpenTTCN license management window.

Page 18 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.

Page 19 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:
Figure 8: License validation 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. OpenTTCN Tester 2012 User Guide
Page 20 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 support@openttcn.fi .

Page 21 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:

Page 22 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.

Page 23 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.

Page 24 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.

Page 25 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.

Page 26 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.

Page 27 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.

Page 28 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.

Page 29 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.

Page 30 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 211 Fail 0 Inconc 0 None 0 Error 0 Total 211 Duration 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 1 Fail 0 Inconc 0 None 0 Error 0 Total 1 Duration 00:00:01

Page 31 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.
The project name corresponds to the name of the testing session when the same information is used
from the command-line.

Page 32 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.

Page 33 of 131
Figure 21: New Example project in navigator view.

Page 34 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.

Page 35 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.
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.

Page 36 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.

Page 37 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.

Page 38 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 recompiled (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. OpenTTCN Tester 2012 User Guide
Page 39 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 @typeclass @default @recordfield
Name of the parameter being defined. Base TTCN-3 type of the parameter. Default value specified in the test suite. 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

Page 40 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.

Page 41 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.

Page 42 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.

Page 43 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.

Page 44 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

Page 45 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.

Page 46 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.

Page 47 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 OpenTTCN Tester 2012 User Guide
Page 48 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.

Page 49 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

Page 50 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.

Page 51 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 doubleclicking 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.

Page 52 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 messagebased communication and timers. Then we demonstrate graphical log for procedurebased 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.

Page 53 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 OpenTTCN Tester 2012 User Guide
Page 54 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.

Page 55 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.

Page 56 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).
Page 57 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.

Page 58 of 131
Figure 38: Graphical log: Message-based communication and timers.
Figure 39: Graphical log: Procedure-based communication.

Page 59 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 OpenTTCN Tester 2012 User Guide
Page 60 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.

Page 61 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.

Page 62 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. OpenTTCN Tester 2012 User Guide
Page 63 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 doubleclick the left margin to set a breakpoint. Alternatively you can right-click the margin and select "Toggle Breakpoint".

Page 64 of 131
You can see to breakpoint set in Figure 42. The margin location you must doubleclick 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, lets 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.

Page 65 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.

Page 66 of 131
Figure 45: Debug perspective after hitting breakpoint.
Lets 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.

Page 67 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.

Page 68 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.

Page 69 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.

Page 70 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). OpenTTCN Tester 2012 User Guide
Page 71 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.

Page 72 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 reusing 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. OpenTTCN Tester 2012 User Guide
Page 73 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. OpenTTCN Tester 2012 User Guide
Page 74 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. OpenTTCN Tester 2012 User Guide
Page 75 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.

Page 76 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

Page 77 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. OpenTTCN Tester 2012 User Guide
Page 78 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 OpenTTCN Tester 2012 User Guide
Page 79 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
You can find more information about the use of XML Codec from the following article: OpenTTCN Tester 2012 User Guide
Page 80 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
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. OpenTTCN Tester 2012 User Guide
Page 81 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
Contact support@openttcn.fi 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

Page 82 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.

Page 83 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.

Page 84 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: OpenTTCN Tester 2012 User Guide
Page 85 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.

Page 86 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.

Page 87 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

Page 88 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.

Page 89 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. OpenTTCN Tester 2012 User Guide
Page 90 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: Stop a testing server: Finding out OT ID that identifies your license key:
ot start ot stop 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: List available testing sessions: Delete a testing session:
session create SessionName3 session list 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 OpenTTCN Tester 2012 User Guide
Page 91 of 131
14.4 Running test cases

Running all test cases of a module: Running TTCN-3 control part: Running a test case: Running a list of test cases: tester run SessionName3 @all tester run SessionName3 @control tester run SessionName3 TC_while 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: (For example if a test case hangs) Press Control-C

Page 92 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
By OpenTTCN Ltd convention, the test system interface start-up command is put to a file that is in Linux start_adapter.sh or startif.sh, and in Windows
called
start_adapter.bat or startif.bat.

Page 93 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.

Page 94 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.

Page 95 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.

Page 96 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.
ETSI recommends .ttcn file prefix to be used for files storing TTCN-3 modules written in TTCN-3
Core Language.

Page 97 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 importer3 load ModuleDemo mod2.ttcn importer3 load ModuleDemo mod3.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: OpenTTCN Tester 2012 User Guide
Page 98 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 OpenTTCN Tester 2012 User Guide
Page 99 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

Page 100 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

Page 101 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 OpenTTCN Tester 2012 User Guide
Page 102 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.

Page 103 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
************************************************************ *** TEST EXECUTION SUMMARY Pass 211 Fail 0 Inconc 0 None 0 Error 0 Total 211 Duration 00:00:28
: : a few to thousands of log lines later :

Page 104 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 Any error verdict Action 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. Rerun the test cases that produced inconc verdicts to see if the problem persists. Many fail verdicts. Many pass verdicts, some fail verdicts, few inconc verdicts. Problem in the Implementation Under Test; determine the cause for this many fail verdicts before you continue. 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. Rerun 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 OpenTTCN Tester 2012 User Guide
Page 105 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 redirecting 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.

Page 106 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.

Page 107 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.

Page 108 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.

Page 109 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 startup, 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

Page 110 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.
Command Syntax and Example: 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.

Page 111 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.
Command Syntax and Example: 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.
Command Syntax and Example: 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.
Each command option is described in the following sections. OpenTTCN Tester 2012 User Guide
Page 112 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 9
Module parameter is a term used in association with TTCN-3. 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.

Page 113 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.
Command Syntax and Example: session list

Page 114 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 unregistered.
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 OpenTTCN Tester 2012 User Guide Page 115 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).

Page 116 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.
Command Syntax and Example: session version
16.2.7 Print Command-Line Help The session help command or session command without any arguments prints a list of available commands of this tool and allowed arguments.
Command Syntax and Example: session help

Page 117 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
Each command option is described in the following sections.
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 @control11 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.

Page 118 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.
Command Syntax and Example: tester version
16.3.3 Print Command-Line Help The tester help command or tester command without any arguments prints a list of available commands of this tool and allowed arguments.
Command Syntax and Example: tester help OpenTTCN Tester 2012 User Guide
Page 119 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.
Each command option is described in the following sections. 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 asn112, 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.

Page 120 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.

Page 121 of 131
16.4.4 Print Command-Line Help The importer3 command without any arguments prints a list of available commands of this tool and allowed arguments.
Command Syntax and Example: importer3

Page 122 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

Page 123 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.

Page 124 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.

Page 125 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) 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 settings. # Uncomment the line below to disable the use of proxy. #disable-proxy = yes is a special name that causes
Explorer

Page 126 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 host Description 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) Directory for variable data, such as system repository. Placed in your home directory by default. Table 3: Common configuration settings in the configuration file.
instance-path
18.3 Java related configuration settings

Configuration Setting java-runtime Description 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.

Page 127 of 131
18.4 System configuration settings

Configuration Setting debug-level Description 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. Type of proxy server. Supported values: HTTP, SOCKS4, SOCKS5 User and password for the proxy server in user:password format. 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.
proxy-type
proxy-login
disable-proxy
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.

Page 128 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. OpenTTCN Tester 2012 User Guide
Page 129 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.

Page 130 of 131
20 Contacting OpenTTCN
Please give us your feedback about OpenTTCN Tester 2012 and send your questions using support@openttcn.fi 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 sales@openttcn.fi e-mail.
OpenTTCN wishes you a good time using OpenTTCN Tester 2012!

Page 131 of 131

OpenTTCN Tester User Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OpenTTCN Tester User Guide

Uploaded by

Copyright:

Available Formats

OpenTTCN Tester 2012 User Guide

VERSION 4.2.5 July 6, 2012

4.3.1 4.3.2 4.3.3 5

7.4.1 7.5 7.6 7.7 7.8 8

ANALYZING TEST RESULTS ...................................................................................................... 51 Page 2 of 131

OpenTTCN Tester 2012 User Guide

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

9.2.1 9.2.2 9.2.3 9.3

10.2.1 10.2.2 10.2.3 10.2.4 10.3

10.3.1 10.3.2 10.3.3 11

OpenTTCN Tester 2012 User Guide

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

15.1.1 15.1.2 15.2 15.3 15.4

15.4.1 15.5 15.6

15.7.1 15.7.2 15.8

OPENTTCN COMMAND-LINE REFERENCE .............................................................................. 110 Page 4 of 131

OpenTTCN Tester 2012 User Guide

16.1.1 16.1.2 16.1.3 16.1.4 16.1.5 16.2

16.2.1 16.2.2 16.2.3 16.2.4 16.2.5 16.2.6 16.2.7 16.3

16.3.1 16.3.2 16.3.3 16.4

16.4.1 16.4.2 16.4.3 16.4.4 17 18

FILES CREATED BY OPENTTCN ............................................................................................... 129 CONTACTING OPENTTCN ...................................................................................................... 131

OpenTTCN Tester 2012 User Guide

1 Overview of OpenTTCN Tester 2012

2008 in Windows platform and with GCC4 in Linux platform.

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

OpenTTCN Tester 2012 User Guide

2 Release Highlights of OpenTTCN Tester 2012

OpenTTCN Tester 2012 User Guide

3 Prerequisites for OpenTTCN Tester

OpenTTCN Tester 2012 User Guide

4 OpenTTCN Tester System Overview

4.1 System Services

4.2 User Interfaces

OpenTTCN Tester 2012 User Guide

4.3 SUT and Platform Adapters and Coding and Decoding

OpenTTCN Tester 2012 User Guide

OpenTTCN Tester 2012 User Guide

OpenTTCN Tester 2012 User Guide

5 Starting and Stopping OpenTTCN Tester

Figure 1: OpenTTCN Tester 2012 splash screen.

OpenTTCN Tester 2012 User Guide

5.1 Selecting a Workspace

Figure 2: Workspace launcher dialog.

OpenTTCN Tester 2012 User Guide

5.2 Installing OpenTTCN License Key

Figure 3: License file installation dialog.

OpenTTCN Tester 2012 User Guide

Figure 4: Select license file dialog.

5.3 Activating OpenTTCN License Key

OpenTTCN Tester 2012 User Guide

Figure 5: License activation request dialog.

OpenTTCN Tester 2012 User Guide

Figure 6: OpenTTCN license management window.

OpenTTCN Tester 2012 User Guide

5.4 Proxy configuration

Figure 7: Proxy configuration in preferences.

OpenTTCN Tester 2012 User Guide

5.5 Online License Validation

Figure 8: License validation error.

Possible causes and ways to resolve these problems are:

OpenTTCN Tester 2012 User Guide

5.6 OpenTTCN Tester Running

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