TTCN

TTCN: Testing and Test Control Notation Original meaning: Tree and Tabular Combined Notation Original purpose: Specification of abstract test suites for conformance testing of International Telecommunications Union protocols. Now promoted as a general purpose test language for distributed / communicating systems. Goal: Provide a complete, internationally standardized, specification for test case behaviour and execution that is repeatable in any test lab. Predictable execution requires very precise semantic definitions.
1

History (1)
Initial discussions on a standardized test language as part of a conformance test framework for communications protocols started in 1984. In 1994, the first version of the conformance test framework standard, ISO-9646, was published. TTCN-1 eventually was part 3 of this standard, published in 1995. Language assumed that the entire protocol testing methodology was being used. In 1997, TTCN-2 was issued. Most used in Europe; only limited use in North America.
2

TTCN-2
Tree and Tabular Combined Notation

Tables describe data formats, signal specifications, etc.

Trees used to describe test case behaviour

Execution starts at the root of the tree

Tree branches represent alternative execution paths. Implication: no loops Alternatives explicitly specified for valid and invalid behaviour.
3

Implementation of TTCN Tests

TTCN describes abstract tests that are completely platform independent The TTCN standard also provides operational semantics, which describe the exact execution behaviour of a test case

Implementations are often in high-level language (C++, Java)

TTCN primitives are mapped to actual test environment. Implementations must obey the operational semantics
4

TTCN-2 Tables
Example: an abstract service primitive type definition:

ASP Type Definition ASP name: ConnectRequest PCO type: UpperTesterPCO Comments: Parameter Name Parameter Type SA RA Contents OCTET_STRING[2] OCTET_STRING[2] OCTET_STRING[252] Comments sender address receiver address user data

Detailed comments:
5

TTCN-2 Tables
This table describes the data values to be used in one instance of a message of the type of the previous table, sent during a test case.

ASP Constraint Declaration

Constraint name: CReq_1 ASP type: ConnectRequest Comments: Parameter Name Parameter Value Comments

SA RA Contents

0A24H 004BH U_Data

sender address receiver address pre-defined constant

6

Detailed comments:

TTCN-2: Trees

Behaviour Description U ! ConnectRequest L ? ConnectIndication L ! ConnectResponse U ? ConnectConfirm U ? Otherwise L ? Otherwise

Constraint CReq_1 CI_1 CRes_1 CC_1

Verdict

PASS FAIL (FAIL)

expected forward progress in time alternatives

TTCN-2: Test Suite Overview

TTCN-2: Test Suite Declarations

TTCN-2 Signal Declarations

message data format

10

TTCN-2: Table declarations

constraints

expected message data

11

TTCN-2: Test case

12

Implementing TTCN-2 tests

user interface timer management executor

compiled TTCN test case

encoder
form

decoder
extract
manuallywritten code operating system service test equipmentspecific
13

PCO queues send/receive events

to system under test

Implementing TTCN-2 tests

user interface timer management executor

compiled TTCN test case

?B 110010.

!A
011001.

encoder
form

decoder
extract

PCO queues send/receive events

to system under test
14

History (2)
Discussions after TTCN-2 centred on making the language more flexible and user-friendly. Standardization taken over by ETSI, the European Telecommunications Standards Institute.

First version of TTCN-3 issued in 2001

Radical change from the previous version

15

Credits
Much of the following has been adapted from:

TTCN-3: An Introductory Overview

Anthony Wiles, ETSI Conference presentation at TestCom

About TTCN-3
Tutorial available at www.etsi.org

16

What is TTCN-3?
Testing and Test Control Notation Version 3 Internationally standardized testing language Product of the European Telecommunications Standards Institute (ETSI) A programming language that has been used for more than 15 years in standardization as well as industry

Specifically designed for black box testing and certification

Constantly developed and maintained at ETSI by a team of leading testing experts from industry, institutes, and academia A testing technology that applies to a variety of application domains and types of testing Proven to work in very large and complex industrial tests, e.g., 3G network elements

17

TTCN-3 Standards
Standards from ETSI [some cross-listed as ITU standards] ES 201 873-1 (Z.140): TTCN-3 Core Language ES 201 873-2 (Z.141): TTCN-3 Tabular Presentation Format (TFT) ES 201 873-3 (Z.142): TTCN-3 Graphical Presentation Format (GFT) ES 201 873-4 (Z.143): TTCN-3 Operational Semantics ES 201 873-5: TTCN-3 Runtime Interface (TRI) ES 201 873-6: TTCN-3 Control Interfaces (TCI) ES 201 873-7: Using ASN.1 with TTCN-3 ES 201 873-8: The IDL to TTCN-3 Mapping Proposed: Mappings to XML, C++ Currently: Edition 3 of TTCN-3 (2007/8)
18

What makes TTCN-3 different

From conventional programming or scripting languages? Rich type system including native list types and support for subtyping Embodies powerful build-in matching mechanism Snapshot semantics, i.e., well defined handling of port and timeout queues during their access

Concept of verdicts and a verdict resolution mechanism

Support for specification of concurrent test behaviour Support for timers Allows test configuration at run-time Tests focus only on implementation to be tested

19

What makes TTCN-3 different

From a test tool or vendor proprietary testing language? Not tied to a particular application or its interface(s) Not tied to any specific test execution environment, compiler or operation system TTCN-3 as such is not executable and requires a compiler/interpreter, adapter as well as codec implementations

20

TTCN-3 test systems in a nutshell

TTCN-3 specifies a test but a test system is needed for test execution TRI and TCI standards define test system architecture TTCN- 3 tools are required to support internal interfaces Allows reuse of test platforms with different tools but also for different SUTs A test system requires A TTCN-3 tool = TTCN-3 compiler and execution environment ( ) A test platform for a specific device under test ( s+ s) Note: Tools come with default Test Control & Logging

Test System Executor

TTCN-3 Test System Test Control TCI
[compiled]

Logging

Codecs

TTCN-3 Executable TRI SUT Adapter Platform Adapter

System Under Test (SUT)

TCI = TTCN-3 Control Interface TRI = TTCN-3 Runtime Interface 21

An example adaptation: A IPv6 test system

Test System Executor
TTCN-3 Test System Parameter File TCI
[compiled]

Tool Logging

IPv6 Codecs

IPv6 ATS TRI

TTCN-3 Executable

Ethernet Adapter

Real-time Adapter

Open Source FreeBSD Router

22

Minimal Test Configuration

TTCN-3 Test System
TTCN-3 Executable TCI Test Control Logging Codecs TRI SUT Adapter Communication with SUT Platform Adapter

MTC
Communication with IUT

System Under Test (SUT)

Communication with IUT

Implementation Under Test

All test behavior is executed on one (main) test component 23

Example Concurrent Test Configuration

TTCN-3 Test System
TTCN-3 Executable TCI Test Control

MTC
Logging

Internal Communication

PTC
TRI SUT Adapter

PTC

Codecs

Platform Adapter

System Under Test (SUT)

Implementation Under Test

A test involves execution of many parallel test components Dynamic instantiation of components and communication links
24

Basic Concepts

25

Main Capabilities of TTCN-3

Dynamic concurrent testing configurations Various communication mechanisms (synch and asynch)

Data and signature templates with powerful matching mechanisms

Specification of encoding information Display and user-defined attributes Test suite parameterization Test case control and selection mechanisms Assignment and handling of test verdicts Harmonized with ASN.1 and IDL (XML and C++ coming)

Different presentation formats

Well-defined syntax, static semantics and operational semantics

26

The Core Language and Other Presentation Formats

Text format Tabular Format Core format is text based (most popular) TTCN-3 can be edited or viewed in other formats Tabular format (for TTCN-2 people)

TTCN-3 Core Language

Graphical Format Presentation Format3

Graphical format (good for visual overview)

Other standardized formats in the future? Proprietary formats possible
27

Presentation Formatn

Example Core (Text) Format

testcase TC_resolveEtsiWww() runs on DnsClient { timer t_ack; serverPort.send(m_dnsQuestion("www.etsi.org")); t_ack.start(1.0); alt { [] serverPort.receive(mw_dnsAnswer("172.26.1.17")) { setverdict (pass); } [] serverPort.receive { // any other message setverdict(fail); } [] t_ack.timeout { setverdict(inconc); } } t_ack.stop; }
28

Example Graphical Format

testcase TC_resolveEtsiWww() runs on DnsClient
mtc serverPort

DnsClient
timer t_ack t_ack alt pass fail t_ack inconc t_ack m_dnsQuestion("www.etsi.org") mw_dnsAnswer("172.26.1.17")

DnsPort

29

Example Tabular Format

Testcase Name Group Purpose System Interface MTC Type Comments DnsClient TC_resolveEtsiWww()

Local Def Name

t_ack

Type
timer Behavior

Initial value

Comments

serverPort.send(m_dnsQuestion("www.etsi.org")); t_ack.start(1.0); alt { [] serverPort.receive(mw_dnsAnswer("172.26.1.17")) { setverdict (pass); } [] serverPort.receive // any other message { setverdict(fail); } [] t_ack.timeout { setverdict(inconc); } } t_ack.stop; Detailed Comments:

30

Use of TTCN-3 With Other Languages

ASN.1 Types & Values

XML Types & Values

IDL Types & Values

TTCN can be integrated with types systems of other languages

TTCN-3 Core Fully harmonized Language with ASN.1

Harmonized with other languages IDL, XML, C/C++
31

Other types & Valuesn

Major Elements of TTCN-3

TTCN-3 Core
Data Types Test Data Test System Architecture Test Behaviour

Built-in and user-defined generic data types (e.g., to define messages, service primitives, information elements, PDUs) Actual test data transmitted/received during testing

Definition of the components and communication ports that are used to build various testing configurations
Specification of the dynamic test system behaviour

32

Structure and Contents of a TTCN-3 Test Suite

33

TTCN-3 Modules
Module () Module Definitions Module Control Attributes
34

Modules are the building blocks of all TTCN-3 specifications A test suite is a module A module has a definitions part and a control part Modules can be parameterized Modules can import definitions from other modules

Modules can have attributes

Example of Module Structure

module MyModule (integer MyTSPar1) { : // Definitions part control { : }

// Control part

} with display ETSI format;

35

Module Definitions
Definitions are global to the entire module Data Type definitions are based on the TTCN-3 predefined types Templates and Signatures define the test data Ports and Components are used in Test Configurations Functions, Named Alts and Test Cases define behaviour

Data Types Constants RP Signatures Data Templates Signature Templates Communication Ports Test Components Functions Named Alternatives

Test Cases

36

Importing Definitions
// Importing single definitions import template MyTemplate from MyModule; // Importing definitions of the same kind import all template from MyModule; // Importing all definitions import all from MyModule; // inhibiting recursive import import template MyTemplate from MyModule nonrecursive; /* To avoid name clashes the imported definition is prefixed with the identifier of the source module */

37

External Definitions
// External constants may be defined
external const integer MyExternalConst;

// External functions may be defined external function MyFunction4() return integer;

38

Groups of Definitions
// A nested group of function definitions group MyTestStepLibrary { group MyGroup1 { function MyTestStep11 { } : function MyTestStep1n { } } group MyGroup2 { function MyTestStep21 { } : function MyTestStep2n { } } }
39

TTCN-3 Data Types

40

TTCN-3 Base Types

Class of type Basic types Keyword
integer

Sub-type
range, list

Basic string types Character string types User-defined structure types Special configuration types

float boolean objectidentifier verdicttype bitstring hexstring octetstring

charstring universal charstring record, record of set, set of enumerated union address port component

list, length list, length

41

Example of Integer Type

/* integer sub-type RANGE definition */ type integer MyIntegerRange (1 .. 100) type integer MyIntegerRange (0 .. infinity)

/* integer sub-type LIST definition */ type integer MyIntegerList (1 , 2, 3, 4)

/* integer sub-type as a mixed LIST and RANGE */ type integer MyIntegerListAndRange (1 ..5, 7, 9)

42

Example of a Structured Type

// record type definition type record MyMessageType { integer field1 optional, boolean field2 } // record value notation var MyMessageType MyMessage { field1 1, field2 true } // Individual field assignment MyMessage.field2 := false

43

Arrays
/* Arrays are not considered to be types in TTCN-3. Instead, they are specified at the point of variable declaration */ // integer array of 5 elements var integer MyArray[5];

// indexing starts at zero MyArray[0]:= 1;

// An initialiser may be used to set array values MyArray := {1,2,3,4,5};

44

Defining Test Data

45

Uses of Data in TTCN-3 Test Specifications

Data in TTCN-3 is used internally to the test component as information passed between test components within the test system as test data transmitted to and received from the System Under Test (SUT) The grouping mechanism can be used to collect data definitions of a similar kind e.g., Service Primitives (ASP) Protocol Data Units (PDU) internal coordination messages

46

Constants (and Variables)

/* Constants are defined in the definitions part of a module (and inside functions and test components) */ constant integer MyConstant := 1; /* Variables can only be declared in the module control part (and inside functions and test components) TTCN-3 does not support global variables */ var hexstring MyHexString;

47

Example Message Definition

// Complex messages can be defined by records type record MyMessageType MyMessage := { field1 integer optional, field2 integer, field3 integer, field4 integer, field5 boolean optional, field6 hexstring optional, field7 AnotherMessageType, field8 bitstring, field9 charstring (1 .. 20) }
48

Data Templates
Templates are special data values that have the following characteristics matching mechanisms they can be parameterized

they can be modified to provide a simple form of inheritance

Templates can be applied to simple types as well as complex types

Are most often used to define the possible received values of messages and responses to remote procedure calls
49

Matching Mechanisms
Notation ( ... ) not ( ... ) Description Match a value in a list of values Match a value not in a list of values

(lower..upper)
? * ... <?> ... ... <*> ... length ifpresent

Match an integer range

Wildcard for any value Wildcard for any value or no value Wildcard for any single element in a string or array Wildcard for any number of consecutive elements in a string or array Match on a restricted length (string type) Match if an optional element is present
50

Examples of Simple Templates

/* Template for a simple integer type */ template integer MyData1 := *; template integer MyData2 := (1, 2, 3); /* This line in a test behaviour description will match any incoming integer value */ P1.receive(MyData1); /* This line will match on one of the incoming integer values 1, 2 or 3 */ P1.receive(MyData2);

51

Example Message Template

template MyMessageType MyMessage := { field1 1 ifpresent, field2 (1, 2, 3), field3 (0 .. 255), field4 not (1, 2, 3), field5 omit, field6 * ifpresent, field7 ?, field8 1011?110*1B, field9 abc <*> xyz length (20) }

52

Parameterized Templates (1)

// Value parameterization template MyMessageType MyMessage (integer MyPar) := { field1 MyPar, field2 true field3 110011B } // Example use of this template P1.send(MyMessage(1));

53

Parameterized Templates (2)

// Type parameterization type record MyRecordType(MyMetaType) { boolean field1, MyMetaType field2 // field2 type not defined } var MyRecordType(integer) MyRecordValue := { field1 := true, field2 := 123 // field2 now of type integer }

54

Modified Templates
// Writing template MyMessageType MyMessage1 { field1 123, field2 true } // and template MyMessageType MyMessage2 modifies MyMessage1 { field2 false } // Is the same as writing template MyMessageType MyMessage3 { field1 123, field2 false }

55

Local Function Definitions

/* Functions can declare local constants, variables and timers */ function MyFunction { const hexstring MyConst := FF00H; var integer MyVar :=1; timer MyTimer; : }

56

Procedure Signatures
/* Procedure signatures are needed for synchronous communication over procedurebased ports (remote procedure calls) */ signature MyRemoteProc ( in integer Par1, out float Par2, inout integer Par3 ) return integer exception (ExceptType1, ExceptType2);

57

Signature Templates
signature MyRemoteProc ( in integer Par1, out float Par2, inout integer Par3 ) return integer exception (ExceptType1, ExceptType2); /* templates may be used to define the actual parameters to a remote procedure call */ template MyRemoteProc Mytemplate := { Par1 := 7, Par2 := *, Par3 := MyConst }
58

Specifying Elements of Test System Architecture

59

Test Components
Test components are the entities on which test behaviour is executed (in parallel) Declarations may be made locally in the component A list of the ports used by the component must also be given Actual configurations are built dynamically in the test behaviour using operations such as create, connect etc.

Test Component Local Declarations

Ports Used

60

Kinds of Test Components

There are three kinds of component MTC (Main Test Component) PTC (Parallel Test Component) a PTC that defines the Abstract Test System Interface

Abstract Test System MTC1 PTC1 PTC2

PTCn

Abstract Test System Interface Real test system connected to an SUT

61

Communication Ports
Test components communicate via communication ports A test port is modeled as an infinite FIFO queue Ports have direction (in, out, inout) There are three types of port message-based, procedure-based or mixed
P1 (out) P1 (in)

PTC1
P1.send(Msg)

PTC2
P1.receive(Msg)

62

Example Port Definition

// Definition of a message-based port type port MyMessagePortType message { in MsgType1, MsgType2; out MsgType3; inout integer } // Definition of a procedure-based port type port MyProcedurePortType procedure { out ProcedureSignature1, ProcedureSignature2 }

63

Example Component Definition

// Definition of test component type type component MyComponentType { // Local declarations var integer MyVar; timer MyTimer; // Ports used by the component MyMessagePortType P1, P2; MyProcedurePortType P3 }

64

Test System Interface

/* A user-defined component that defines the port interface to the underlying real test system */ type component MyTestSystemIntefaceType { MyLowerPCOType LT; MyUpperPCOType UT }

65

Specifying Test System Behaviour

66

TTCN-3 Functions
Functions are the building-blocks of test system behaviour Functions have local declarations and a program part Can be a 'pure' function doing some internal test system task or specify test behaviour using communication operations such as send and receive External functions are allowed There are some pre-defined functions (type conversion etc.)
67

Function ( . . . ) Local Declarations Program Part

Pre-defined Functions
Function Conversion functions
Convert bitstring value to integer value Convert hexstring value to integer value Convert octetstring value to integer value Convert charstring value to integer value Convert integer value to bitstring value bit2int hex2int oct2int str2int int2bit

Name

Convert integer value to hexstring value

Convert integer value to octetstring value Convert integer value to charstring value

int2hex
int2oct int2str

Length functions
Return the length of a value of any string type Return number of elements in record, record of, template, set, set of lengthof sizeof

Presence / Choice functions

Determine if an optional field in a record, template, etc. is present
Determine which choice has been made in a union type

ispresent
ischosen 68

Function Definitions(1)
// Functions can be parameterised // in, out, inout paramters. Default is in function MyFunction (in integer MyPar) { : } // Functions can return values // Default is void function MyFunction return integer { : }
69

Function Definitions(2)
/* This function performs a generic task. It does not use any communication operations */ function MyFunction { : } /* This function uses communication operations consistent with the ports offered by MyPTC */ function MyFunction runs on MyPTC { : }
70

Test Case Definitions

Test cases are a special kind of function executed in the control part of a module The interface part (runs on) references the MTC on which the test case will run The system part (system) references the test system interface component. Can be omitted if the test case only consists of an MTC The Behaviour part defines test case behaviour
71

Test Case ( . . . ) Interface Part

System Part
Behaviour Part

Example Test Case Definitions

// Parallel configuration testcase MyTestCase() runs on MyMTCType system MyTestSystemType { : // behaviour defined here } // Configuration consists only of an MTC testcase MyTestCase()runs on MyMTCType { : // behaviour defined here }
72

TTCN-3 Program Statements and Operations

73

Kinds of Statements and Operations

Kind of statement or operation Basic program statements Dynamic test behaviour Configuration operations Communication operations Timer operations Verdict operations SUT operations Yes Used in module control Yes Yes (limited) Used in functions or test cases Yes, except execute Yes Yes Yes Yes Yes Yes
74

Basic Program Statements

Statement Keyword or Symbol

Expressions Assignment
Logging If-else statement For loop While loop Do loop Label definition Jump to label Stop execution of function or control Execute test case

(...) :=
log if (...) {...} else {...} for (...) {...} while (...) {...} do {...} while (...) label goto stop execute
75

Example Program Statement

function MyFunction { var integer x, j; for (j:=1; j<=10; j:=j+1) { if (MyGlobalFlag == true) { x:=j*2; log int2str(x); } else x := j*3 } }

76

Operators (1)
Category Operation

Arithmetic operators

addition
subtraction multiplication division modulo

Symbol + * / mod & == != < <= > >=

77

String operator Relational operators

concatenation equal not equal less than less than or equal greater than greater than or equal

Operators (2)
Category Operation

Logical operators

logical not
logical and logical or logical exclusive or

Symbol not and or xor not4b and4b or4b xor4b << >> <@ @>
78

Bitwise operators

bitwise not bitwise and bitwise or bitwise exclusive or

Shift operators Rotate operators

shift left shift right rotate left rotate right

Pre-defined Functions
Function Conversion functions
Convert bitstring value to integer value Convert hexstring value to integer value Convert octetstring value to integer value Convert charstring value to integer value Convert integer value to bitstring value Convert integer value to hexstring value Convert integer value to octetstring value Convert integer value to charstring value bit2int hex2int oct2int str2int int2bit int2hex int2oct int2str

Name

Length functions
Return the length of a value of any string type Return number of elements in record, record of, template, set, set of lengthof sizeof

Presence / Choice functions

Determine if an optional field in a record, template, etc. is present Determine which choice has been made in a union type ispresent ischosen 79

Creating, Building and Controlling Test Configurations

80

Configuration Operations
Operation Keyword

Create a new parallel test component

Connect two components

create
connect

Connect component to test system interface

Get master test component address Get test system interface address Get own address Start execution of test component Stop execution of test component

map
mtc system self start stop

Check termination of test component

done

81

Creating Components
The master test component (MTC) is the only component that is automatically created when the test case is executed
All parallel test components (PTCs) must be created explicitly using the create operation The create operation returns the unique component reference for the newly created component Components can be created at any point in a behaviour description
82

Example of Create
// Define a variable of type component type component MyComponentType { : }

// Define a variable of type component var MyComponentType MyComponent;

// create the component MyComponent := MycomponentType.create

83

Connecting and Mapping Components

Test System

IN

Connected Ports OUT

MyMTC

P1
OUT

P1
IN OUT Mapped Ports

MyPTC P2 PCO
IN

IN

Abstract Test System Interface

OUT

Real Test System Interface

SUT

84

Example of Connect and Map

/* The connect operation is used to connect components within the test system */ connect(MyPTC:P1, mtc:P1)

/* The map operation is used to connect components to the abstract test system interface */ map(MyPTC:P2, system:PCO)

85

Communication Between Test Components

86

Asynchronous Communication

send MTC

receive PTC

non-blocking

blocking

87

Asynchronous Communication Operations

Operation Send a message Receive a message Trigger on a given message Check in queue of port for message Clear port Clear and give access to port Stop access to port send receive trigger check clear start stop Keyword

88

Examples of Asynchronous Communication Operations

MyPort.send(integer:5); MyPort.receive(MyTemplate(5, MyVar)); MyPort.receive(A<B) from MyPartner; MyPort.receive(MyType:*) -> value MyVar; MyPort.receive(integer:5) -> sender MyPeer;

89

Synchronous Communication

call MTC

getcall PTC

getreply or catch exception blocking

reply or raise exception blocking

90

Synchronous Communication Operations

Operation Invoke (remote) procedure call Reply to (remote) procedure call Raise an exception Accept (remote) procedure call Handle response from previous call call reply raise getcall getreply Keyword

Catch exception (from called entity)

Check reply or exception Clear port Clear and give access to port Stop access to port

catch
check clear start stop
91

Examples of Synchronous Communication Operations

// Calling a remote procedure MyPort.call (MyProc, 30ms) to MyPeer { [] MyPort.getreply(MyProc) -> value MyResult; [] MyPort.catch (MyProc, Exception1) } // Replying to a remote procedure MyPort.reply (MyProc)

92

TTCN-3 Behaviour Trees

93

Behaviour Statements
Statement Sequential behaviour ... Keyword or symbol ... ; ... ; ... ;

Alternative behaviour
Interleaved behaviour Activate a default Deactivate a default Returning control

alt {}
interleave {} activate deactivate return
94

Behaviour Statements
// Sequential statements are denoted by a semi-colon function MyFunction1 { MyFunction2; x:=x+1; MyPort.receive(myMessage); // Blocks execution until message received MyPort.send(MyMessage) }

95

Alternative Behaviour
Alternative behaviour is defined using the alt statement alt statements may only be the receiving communication operations and timer events receive, trigger, getcall, getreply, catch, check, timeout
S1

S2 S4 S7 S9 S5 S8

S3

S6 S10

S1; alt {[ ] S3; S6; [ ] S2; alt { [ ] S4; S7; [ ] S5; S8; alt { [ ] S9; [ ] S10; } } }

96

Schematic View of Alternatives

Each alternative consists of a guard (possibly empty) an event, and an (optional) sequence of actions (including further alts) The TTCN-2 concept of snapshot semantics still applies

alt guard1 guard2 guardn

event1 event2 eventn

actions1 actions2 actionsn

97

Example Alt Statement

alt { []

[x>1] [x<1] }

MyPort.receive(MyMessage1) { MyPort.send(MyMessage4) alt { // Next level } } MyPort.receive(MyMessage2); MyPort.receive(MyMessage3)

98

Named Alternatives
Named alternatives (named alt) are descriptions of partial alternatives defined in the module definitions are named and may be parameterised

Named alternatives are macro-expansions

they are not functions Can be referenced from anywhere that it is legal to write a normal alt statement The expand statement allows a named alt to be explicitly expanded inside another set of alternatives

99

Example of Named Alt (1)

// Definition in module definitions named alt MyNamedAlt { [] L1.receive(MyMessage1) [] L1.receive(MyMessage2) } // Use of the named alt testcase TC101() { MyNamedAlt() // In-line reference in test case alt { [] L1.receive(MyMessage3); [expand] MyNamedAlt(); // Macro expansion here } }

100

Example of Named Alt (2)

// Is the same as testcase TC101() { alt { [] L1.receive(MyMessage1) [] L1.receive(MyMessage2) } alt { [] L1.receive(MyMessage3) [] L1.receive(MyMessage1) [] L1.receive(MyMessage2) } }

101

Default Behaviour
Default behaviour is defined using named alternatives Defaults must be explicitly activated and deactivated The expansion of defaults is applied to the end of the top-level set of alternatives in an alt statement and to all single receiving operations and timeouts // Note that the single statement L1.receive(MyMessage1); // is equivalent to alt { [] L1.receive(MyMessage1)}
102

Activate and Deactivate

named alt MyDefault { [] } // Use of the named alt testcase TC101() { : activate (MyDefault) : // Default applies from here L1.any.receive

deactivate (MyDefault) : // Default does not apply from here

}
103

Interleaved Behaviour
/* The interleave statement specifies all possible combinations of executing a given set of alternative statements */

interleave {

[] PCO1.receive(MyMessageOne);
[] PCO1.receive(MyMessageTwo); [] PCO1.receive(MyMessageThree); }

104

Timers, Verdicts and SUT Operations

105

Additional Operations
Statement Timer operations Start timer start Yes Yes Keyword or symbol Module control part Functions and test cases

Stop timer
Read elapsed time Check timeout event Check timer status Verdict operations Set local verdict Get local verdict

stop
read timeout running

Yes
Yes Yes Yes

Yes
Yes Yes Yes Yes Yes Yes
106

verdict.set verdict.get sut.action

SUT operations
Cause SUT action

Verdicts
Verdicts: pass, fail, inconc, none, error Each test component has its own local verdict can be written (set) and read (get) Global verdict returned by Test Case (read-only)
Verdict returned by the test case when it terminates

MTC

PTC1

PTC2

verdict.set(fail)

verdict.set(pass)

verdict.set(inconc)

107

Timer Operations
// Starting, stopping and reading a timer MyTimer.start(20E-3)// Default unit is seconds MyTimer.stop MyVar := MyTimer.read // Check if a timer is running if (MyTimer.running) { } // timeout in an alternative : [] MyTimer.timeout :

108

Executing and Controlling Test Cases

109

Module Control
Module control is the dynamic part of a TTCN-3 specification where test cases are executed (execute) Local declarations, such as variables and timers may be made in the control part Basic programming statements may be used to select and control the execution of the test cases

Control Local Control Declarations

Test Case Execution

110

Local Control Declarations

control { const hexstring MyConst := FF00H; var integer MyVar :=1; timer MyTimer; : }
:

111

Executing Test Cases

module MyModule

// Test cases are defined in the module definitions

testcase MyTestCase() runs on MyMTC system MyTestSystem { // behaviour defined here }

control
{ } } // and executed in the control part execute (MyTestCase())

112

Controlling Test Cases

// Test Cases return verdicts execute(MyTestCase()) -> value MyVerdict; // Timeouts may be placed on Test Cases execute(MyTestCase(),0.5) -> value MyVerdict; // Test Cases can be used with program statements while (x<10) { x:=x+1; execute(MyTestCase()) }

// Selection of Test Cases if (MySelectionExpression) execute(MyTestCase())

113

Specifying Additional Attributes

114

Defining Attributes
Special attributes can be associated with most TTCN-3 language elements using the with statement encoding information (encode) standardized: ASN.1 application specific, proprietary display information (display) standardized: tabular and MSC formats

Language Element

Attributes

or proprietary
user-defined (extension) proprietary
115

Example Attributes
type record MyPDU { integer field1, ia5string field2, boolean field3 } with { display ETSI Tabular := PDU; encode BER; extension MyRule }

// Tabular PDU // Encoding directive // User specific

116