¾ VIII. TTCN-3 ¾ TTCN-3 presentation · PDF file521265A Telecommunication Software Ch8 – TTCN-3 VIII. TTCN-3 Dept. Electrical & Information Engineering, Computer Engineering Lab

521265A Telecommunication Software Ch8 – TTCN-3521265A Telecommunication Software Ch8 – TTCN-3

VIII. TTCN-3

Dept. Electrical & Information Engineering, Computer Engineering Lab 8-1 Dr. Junzhao SunDept. Electrical & Information Engineering, Computer Engineering Lab 8-1 Dr. Junzhao Sun


Outline

IntroductionDisadvantages of TTCN-2N t f TTCN 3New aspects of TTCN-3

TTCN-3 core languageModule definitions partModule control part

TTCN-3 presentation formsTabular


Graphical

TTCN-3 InterfacesTTCN-3 Runtime interface (RTI)TTCN-3 Control interface (TCI)


Outline





Graphical



TTCN History



TTCN-3 Standardization

ETSI ES 201 873 (Part, Version, Published Year)Part 1: "TTCN-3 Core Language"; (4.2.1, 28.7.2010) P t 2 "TTCN 3 T b l P t ti F t (TFT)" (3 2 1 23 2 2007)Part 2: "TTCN-3 Tabular Presentation Format (TFT)"; (3.2.1, 23.2.2007) Part 3: "TTCN-3 Graphical Presentation Format (GFT)"; (3.2.1, 23.2.2007) Part 4: "TTCN-3 Operational Semantics"; (4.2.1, 28.7.2010) Part 5: "TTCN-3 Runtime Interface (TRI)"; (4.2.1, 28.7.2010) Part 6: "TTCN-3 Control Interface (TCI)". (4.2.1, 28.7.2010) Part 7: "TTCN-3 Using ASN.1 with TTCN-3". (4.2.1, 28.7.2010) Part 8: "The IDL to TTCN-3 Mapping" (4 2 1 28 7 2010)


Part 8: The IDL to TTCN-3 Mapping . (4.2.1, 28.7.2010) Part 9: "Using XML schema with TTCN-3". (4.2.1, 28.7.2010) Part 10: "TTCN-3 Documentation Comment Specification". (4.2.1, 28.7.2010)

http://www.ttcn3.org/StandardSuite.htm


TTCN-2 is too complexToo many different tables proformas

Disadvantages of TTCN-2

TTCN-2 is too restrictive‘Browser’ structure built into the

proformasDifficult to learnRedundant or unused functionalitiesIncludes things which tools could doBNF too ‘big’ (and not user

BNFPresents the OSI Conformance Testing viewTable proforma format too restrictive

Why no (human understandable) text version?


friendly) Why not other presentation formats?

Application-specific static semantics


From TTCN-2 to TTCN-3

TTCN (v1/v2) was an abbreviation for( )

Tree and Tabular Combined Notation

TTCN (v3) is now an abbreviation for


Testing and Test Control Notation


What Use is TTCN-2 in the Future?

It is obvious that TTCN-2 has not been accepted in many markets outside of Telecoms, e.g. the Internet

TTCN 2 i h till i ll i bl i it t d i tTTCN-2 is, however, still commercially viable in its accepted environment

TTCN-2 can not disappear for a number of yearsTTCN-2 must remain alive alongside TTCN-3

There are a number of existing TTCN-2 tests that will not be migratedThere are a number of test equipments that will not be converted/upgraded

S C


Some environments may even have TTCN-2 running alongside TTCN-3


TTCN-3 Motivations

SimplificationModernization of TTCNHarmonization of TTCN with ASN 1Harmonization of TTCN with ASN.1Simplification of proformas

TTCN-2 has 50 proformas (tables), TTCN-3 have only 25 proformas

Clear and clean interfaceFull support for ASN.1 97Remove TTCN redefinition of ASN.1 productions

Generalization


Support more general testing platforms other than OSIApplying other testing views than conformance testing view

Developed at ETSI and ratified by ITU-T and later by ISOTTCN, as viewed by ETSI, should be the first choice for test specifiers for all types of black-box testing


What is TTCN-3?

The new standardised test specification and test implementation language

I t ti ll t d di d t ti l P d t f th ETSI MTSInternationally standardized testing language, Product of the ETSI -MTS

Developed based on experiences from previous TTCN editionsRemoval of OSI specific conceptsImprovement of conceptsIntroduction of new concepts

Applicable for all kinds of black-box testing for reactive and di t ib t d t


distributed systems, e.g.Telecom systems (ISDN, ATM, DECT)Mobile systems (GSM, UMTS, 3G, TETRA)Internet (has been applied to IPv6, SIP, OSP)CORBA based systems


Why TTCN-3?

Enable testing of current and upcoming technologiesConsolidate test concepts Wider scope of application

Applicable to many kinds of test applications not just conformance, i.e. also for development, system, integration, interoperability, scalability … testingApplicable in the telecom and datacom domainUsed both for standardized test suites and as a generic solution in software development

Constantl de eloped and maintained at ETSI b a team of


Constantly developed and maintained at ETSI by a team of leading testing experts from industry, institutes, and academiaProven to work in very large and complex industrial tests, e.g., 3G network elements


Main New Aspects of TTCN-3

Triple CConfiguration: Dynamic concurrent test configurationsCommunication: Message- and procedure-based communicationCommunication: Message- and procedure-based communicationControl: Test case execution and selection mechanisms

ImprovedHarmonized with ASN.1 (and IDL, XML)Module concept

ExtendibilityAttributes, external function, external data


Well-defined syntax, static & operational semanticsDifferent presentation formats

Graphical for the ease of development, understanding and documentationIt is both a test programming and specification language


Kinds of testing TTCN-3 can do

ConformanceInteroperability

ReliabilityFault tolerance

ConfigurationCompatibilityPerformanceStressRobustnessI t ti

ScalabilityDegraded modeUnitProductDevelopmentD i


IntegrationFunctionalLoad

DesignInterfaceSystem


Wider Scope of Application Under Test



TTCN-3 test systems in a nutshell

TTCN-3 specifies a test but a test system is needed for test executionTRI and TCI standards define test

Test System ExecutorTRI and TCI standards define test system architecture

TTCN- 3 tools are required to support internal interfacesAllows reuse of test platforms with different tools but also for different SUTs

A test system requiresA TTCN-3 tool = TTCN-3 compiler SUT Adapter Platform Adapter

Test Control

[compiled]TTCN-3 Executable

CodecsLogging

TTCN-3 Test System

TCI

TRI


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

System Under Test (SUT)

TCI = TTCN-3 Control InterfaceTRI = TTCN-3 Runtime Interface


What is TTCN-3?

ASN.1 T &

Text format

TTCN-3 User

Types & Values

Graphical format

IDL types & values

Tabular format

TTCN-3corelanguageXML types

& values


Other types & values n

Presentation format n


What is TTCN-3?

Text format

TTCN-3 User

ASN.1 Types & Values

Graphical format

Other types & values 2

Tabular format

TTCN-3corelanguage

testcase myTestcase () runs on MTCType system TSIType{ mydefault := activate (OtherwiseFail);

verdict.set(pass);

:connect(PTC_ISAP1:CP_ISAP1,mtc:CP_ISAP1);


Other types & values n

Presentation format n

:map(PTC_ISAP1:ISAP1, system:TSI_ISAP1);:PTC_ISAP1.start(func_PTC_ISAP1());PTC_MSAP2.start(func_PTC_MSAP2());Synchronization(); all component.done;log(”Correct Termination”);

}

msc

mi_synch1_conc1

mtc

ISAP1

MSAP2


TTCN-3 General

TTCN-3 can be integrated with other 'type and value' systemsFully harmonized with ASN.1 (1997)H i ti ibl ith th t d l t ( ibl fHarmonization possible with other type and value systems (possibly from proprietary languages)

TTCN-3 can support various presentation formatsCore format is a text based languageCore can be viewed as text or in various presentation formatsTabular format for conformance testingGraphical format for visual overview


Graphical format for visual overviewOther standardized formats in the futureProprietary formats


Example Core (Text) Format

function PO49901(integer FL) runs on MyMTC {

L0.send(A_RL3(FL,CREF1,16));TAC.start;alt {

[] L0.receive(A_RC1((FL+1) mod 2)) {TAC.cancel;verdict.set(pass)

}[] TAC.timeout {

verdict.set(inconc)}


[] any.receive {verdict.set(fail)

}}END_PTC1() // postamble as function call

}


Example Tabular Format

Test Case Definition Name : MyTestcase Group :Group :Purpose : Example Testcase System I/f : MTC Type : MyComponentType Comments :

Name Type Initial Value Comments MyVar INTEGER 0

Behaviour Definition Comments alt


alt { [ ] MyPort.receive(Msg); [ ] : }

DetailedComments:


Example Graphical Format



TTCN-3 Experiences

TTCN-3 has been developed 1999-2001The first commercial tools have been available at the end of 2001

Telelogic (Sweden), Testing Technologies (Germany),Danet (Germany), Da Vinci Communications (New Zealand)

Internal work on TTCN-3 byNokia (Germany, Finland), Ericsson (Sweden, Hungary)Nortel (Canada), Motorola (UK, China)

Academic tools


University of Lübeck, Technical University of BerlinTrial applications

IPv6 testing performed by Ericsson (Hungary)Session Initiation Protocol (SIP) testing performed by ETSI (France) and GMD (Berlin)


TTCN-3 with packages



Outline





Graphical



TTCN-3 Core Language

Basic language elementsModules

1. Module definitions partTypes & valuesTest configurations

Communication ports, test componentsDeclarations & definitions

Constants ,variables , timers , procedure signatures , templatesDynamic test behaviors


Dynamic test behaviorsFunctions and altstepsTest casesProgram statements and operations

2. Module control part











Basic Language Elements

The top-level unit of TTCN-3 is a moduleA module cannot be structured into sub-modulesA module can import definitions from other modulesA module can import definitions from other modulesModules can have parameter lists to give test suite parameterization

A module consists of a definitions part and a control partThe definitions part defines test components, communication ports, data types, functions, test cases etc.

Dynamic test behaviour is expressed as test cases. TTCN-3 program statements include powerful behaviour description mechanisms

The control part calls the test cases and controls their execution. Program


The control part calls the test cases and controls their execution. Program statements can be used to specify the selection and execution order of individual test cases

TTCN-3 language elements may be assigned attributesEncoding information and display attributes (neglected in this course)


TTCN-3 Major Elements

TTCN 3 Core

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 Test System

TTCN-3 Core

Test Data

Data Types


p pthat are used to build various testing configurations

Specification of the dynamic test system behaviourTest

Behaviour

Architecture


Test Suite

Building blocks of a TTCN-3 Test Suite

Data types which specify• Structure of messages or calls and their

Test Data Types

ginformation elements (fields, parameters)

• Internal data structures (e.g., for computation)• Possibly encoding or display informationBuilt-in basic typesinteger, boolean, float,bitstring, hexstring, octetstring,charstring, universal charstring

... and structured typesf f


record, record of, set, set ofunion, enumerated... and special types such as

component, port, verdicttype, default, etc


Test Suite


Actual test data (values) used during testing

Actual Test Data

Test Data Types

g• Constants or Templates for specificmessage or call parameter values

• Matching expressions for allowing multiple message or call parameter values

• value range, value list, wildcards,presence, length, size, permutation

• regular expressions


g p• Using also template decomposition,

parameterization and modification


Test Suite


Static aspectsT t t d t t

Test Configuration

Actual Test Data

Test Data Types

• Test component and port types

Dynamic aspects• Dynamic instantiation andmanagement of test components

• Mappings of test components toabstract test system interfaces


• Connections between testcomponent interfaces

• Management of test components


Test Suite


test casesif di / i i

Test Configuration

Actual Test Data

Test Data Types

• specify sending/receiving messages,computation (e.g., checksums), and verdict assignment

• can be decomposed with functions andaltsteps

• can (re)use default behaviour

• can use timers and timeouts


Test Behaviour

gtest execution control (optional)• order, repetition, conditions, etc


TTCN-3 Language Elements

TTCN-3 module definitionImport of definitions from other module ModulesGrouping of definitionsData type definitionsCommunication port definitionsTest component definitionsConstant definitionsExternal function/constant definitionsVariable declarationsTi d l ti

Types & Values

Test Configurations

Declarations & Definitions


Timer declarationsSignature definitionsData/signature template definitionsFunction definitionsAltstep definitionsTest case definitions

Dynamic Test Behavior- Operator, statement, operation


TTCN-3 Modules

• Modules are the building blocks of all TTCN-3 specifications

Module (…)

Module Control

Module Definitions

• A test suite is a module• A module has a definitions part and

a control part• Modules can be parameterised• Modules can import definitions from

other modules


Module Controlmodule MyModule {

// module definitions// module control

}


TTCN-3 Module

module EtsiDnsTests{Module (…) {

// Test definition part

control{

// Test execution part// (optional)

}}

Module (…)

Module Control

Module Definitions



Module Parameter Lists

A set of values supplied by the test environment at run-timeDuring test execution these values shall be treated as constantsSh ll b d l d ithi th d l d fi iti t lShall be declared within the module definition part only

module MyModulewithParameters{

modulepar { integer TS_Par0, TS_Par1; boolean TS_Par2 };:template MyType Mytemplate


{field TS_Par3};

modulepar { hexstring TS_Par3 };}


Module Definitions Part

Specifies the top-level definitions of the moduleMay import identifiers from other modulesD l ti f d i l l t h ti h ll lDeclarations of dynamic language elements such as var or timer shall only be made in control part, test cases, functions, altsteps or component typesDefinitions can be collected in named groups

module MyModule{ // This module contains definitions only

:

group MyGroup {const integer MyConst:= 1;:


:const integer MyConstant := 1;type record MyMessageType { … }:function TestStep(){ … }:

}

:type record MyMessageType { … };group MyGroup1 {// Sub-group

type record AnotherMessageType { … };const boolean MyBoolean := false

}}


Definitions Partmodule EtsiDnsTests{

// Message structure// A t l t t d t// Actual test data// Test configuration// Test Case definitions

}



module EtsiDnsTests{

group MessageStructure{

Structured Definitions Part

{// Defintions of message types

}group TestData{

// Templates for messages instances}group TestSystemConfiguration{

// P t d t t d i


// Port and component types and mappings}group TestCases{

// Test case definitions}

}


Module Definitions Part

Data Types• Definitions are global to the entire

Communication Ports

Signature Templates

Data Templates

Signatures

Constants Definitions are global to the entire module

• Data Type definitions are based on TTCN-3 predefined and structured types

• Templates define the test data• Ports and Components are used

in Test Configurations


Test Cases

Test Steps

Functions

Test Componentsin Test Configurations

• Functions, Test Steps and TestCases define behaviour


Module Control PartMay contain local definitions and describes the execution order (possibly repetitious) of the actual test cases

A test case shall be defined in module definitions part and called in control part

module MyTestSuite{ // This module contains definitions … :

const integer MyConstant := 1;type record MyMessageType { … }template MyMessageType MyMessage := { … }:function MyFunction1() { … }testcase MyTestcase1() runs on MyMTCType { … }:// d l i i bl


// … and a control part so it is executable control{ var boolean MyVariable; // Local control variable

:execute MyTestCase1(); // sequential execution of test cases :

}}


Import from Modules

Re-use definitions specified in different modules Using the import statementTTCN 3 h li it t t tTTCN-3 has no explicit export construct

All module definitions in the module definitions part may be importedAn import statement can not be used in the control part Importing single definitions

import from MyModuleA { type MyType1 } Importing all definitions of a module

import from MyModule all;


import from MyModule all; Importing groups

import from MyModule { group MyGroup }Importing definitions of the same kind

import from MyModule { type all; template all }











Types & Values

Basic types and valuesSub-typing of basic typesStructured types and valuesThe anytypeArraysType compatibility



Types & Values – Basic Types & Values

Simpleinteger, -17, 0, 123char “A” “k” “O”char, A , k , Ouniversal char, four decimal values of its group, plane, row and cell

char ( 0, 0, 1, 113) denotes the Hungarian character "ű"float, 1.23 (= 123 × 10-2) or 12.3E4 (=12.3 × 104) boolean, true and falseobjid, object identifiers e.g. {itu_t(0) identified_organization(4) etsi(0)} verdicttype, pass, fail, inconc, none and error

String


Stringbitstring, '01101'Bhexstring, 'AB01D'Hoctectstring, 'FF96'Ocharstring, "abcd"


Types & Values – Sub-typing of Basic Types

Keyword type with user-defined types Lists, ranges and length restrictions

Lists of valuesLists of values type bitstring MyBitStrings ('01'B, '10'B, '11'B);type float pi (3.1415926);

Rangestype integer MyIntegerRange (1, 2, 3, 10 .. 20, 99, 100);type char MyCharRange ("a", "b", "c", "0" .. "9");type float piRange (3.14 .. 3142E-3);


String length restrictionstype bitstring MyByte length(8);type bitstring MyByte length(8 .. 8); // Exactly length 8, same as abovetype bitstring MyNibbleToByte length(4 .. 8);


Types & Values – Structured Types & Values (1/3)

Record type and valuesDefinition Assignment

var integer MyIntegerValue:= 1;

const MyOtherRecordType MyOtherRecordValue:= {

field1 := '11001'B,field2 := true

}

var MyRecordType MyRecordValue:= {

type record MyRecordType{

integer field1,MyOtherRecordType field2 optional,charstring field3

}

type record MyOtherRecordType{


{field1 := MyIntegerValue, field2 := MyOtherRecordValue,field3 := "A string"

}

{bitstring field1,boolean field2

}

Referencing fields of a record type MyVar1 := MyRecord1.myElement1;



Set type and values Enumerated type and values

type set MySetType type enumerated MyFirstEnumType {

Unions

type set MySetType{

integer field1,charstring field2

}

type enumerated MyFirstEnumType {Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday

}

var MyFirstEnumType Today := Tuesday;


type union MyUnionType{

integer number,charstring string

}

var MyUnionType age, oneYearOlder;var integer ageInMonths;

age.number := 34; oneYearOlder := {number := age.number+1};ageInMonths := age.number × 12;



Difference between Record, Set and Union

Record: ordered structured types Set: unordered structured types

Similar to records except that the ordering of the set fields is not significant

Union: collection of fields, each one identified by an identifierOnly one of the specified fields will ever be present in an actual union value


Only one of the specified fields will ever be present in an actual union value


Types & Values – The anytype

A shorthand for the union of all known typesknown types: set of defined types, imported ASN.1 and other imported external types

// A valid usage of anytype would be var anytype MyVarOne, MyVarTwo;var integer MyVarThree;


MyVarOne.integer := 34;MyVarTwo := {integer := MyVarOne + 1};

MyVarThree := MyVarOne × 12;


Types & Values – Array

Array may be specified at the point of a variable declarationArrays may be declared as single or multi-dimensional

var integer MyArray1[4]; // 3 elements with the index 0 to 3var integer MyArray2[2][3]; // 2 × 3 elements with indexes

// from (0,0) to (1,2) var integer MyArray3[1 .. 5]; // 5 elements with the index 1 to 5 var integer MyArray4[1 .. 5][2 .. 3 ]; M A 1[0] 10


MyArray1[0]:= 10;MyArray1[1]:= 20;MyArray1[3]:= 30;MyArray1:= {10, 20, -, 30}; //using a value list to assign


Types & Values – Type Compatibility (1/3)

Type compatibility of non-structured types

type integer MyInteger(1 10);type integer MyInteger(1 .. 10);var integer x;var MyInteger y; // Then y := 5; // is a valid assignment x := y; // is a valid assignment, because y has the same root type as x and no subtyping is violatedx := 20; // is a valid assignment


y := x; // is NOT a valid assignment, because the value of x is out of the range of MyIntegerx := 5; // is a valid assignmenty := x; // is a valid assignment, because the value of x is now within the range of MyInteger


Types & Values – Type Compatibility (2/3)Type compatibility of record types

type record AType {integer (0 10) a optional // Assignmentinteger (0..10) a optional,integer (0..10) b optional,boolean c}type record BType {integer a optional,integer (0..10) b optional,boolean c}type record CType {integer d optional,

// Assignmentvar AType MyVarA := { -, 1, true};var BType MyVarB := { omit, 2, true};var CType MyVarC := { 3, omit, true};var DType MyVarD := { 4, 4, true};

// ThenMyVarA := MyVarB; // is a valid assignmentMyVarC := MyVarB; // is a valid assignmentMyVarA := MyVarD; // is NOT a valid assignment because the optionality of fields does not match


integer e optional,boolean f}type record DType {integer a optional,integer b optional,boolean c optional}

because e op o a y o e ds does o a cMyVarC := { d:= 20 };// actual value of MyVarC is { d:=20, e:=2,f:= true }MyVarA := MyVarC // is NOT a valid assignment because field “d” of MyVarC violates subtyping of field “a” of AType


Types & Values – Type Compatibility (3/3)Type compatibility of set types

// Giventype set FType {

integer a optional,integer b optional,boolean c

}

type set GType {i t d ti l

// Assignment

var FType MyVarF := { a:=1, c:=true };var GType MyVarG := { f:=true, d:=7};

// ThenMyVarF := MyVarG; // is a valid assignment as types FType and GType are

tibl


integer d optional,integer e optional,boolean f

}

compatible

MyVarF := MyVarA; // is NOT a valid assignment as MyVarA is a record type


Types & Values – Summary Class of type Keyword Sub-type

Simple basic types integer range, listchar range, listuniversal char range, listfloat range, listg ,boolean listobjid listverdicttype list

Basic string types bitstring list, lengthhexstring list, lengthoctetstring list, lengthcharstring range, list, lengthuniversal charstring range, list, length

Structured types record listrecord of list, lengthset list


set listset of list, lengthenumerated listunion list

Special data types anytype listSpecial configuration types address

portcomponent

Special default types default











Test Configuration

SUT

TCTC TC


• Executing a test case

• Returning a verdict

MTC


Test Configuration General (1/2)

TTCN Test system

Abstract Test System Interface

MTC PTC1

PTC2


SUT

Real Test System Interface


Test Configuration General (2/2)Test components defined by key word “component”

Only one main test component (MTC), one more parallel test components or PTCsMTC is created by the system automatically at the start of each test case executionMTC is created by the system automatically at the start of each test case executionThe behaviour defined in the body of the test case shall execute on MTCDuring execution of a test case other components can be created dynamically by the explicit use of the create operation

Communication ports defined by key work “port”Communication between test components and between the components and the test system interface

The actual configuration of components and the connections between them is


The actual configuration of components and the connections between them is achieved by performing create and connect operations within the test case behaviourThe component ports are connected to the ports of the test system interface by means of the map operation



A well defined (but abstract) test system interface shall be associated with each test caseA test system interface definition is identical to a component definition

It is a list of all possible communication ports through which the test case is connected to the SUT

The test system interface statically defines the number and type of the port connections to the SUT during a test runC f C


Connections between the test system interface and the TTCN-3 test components are dynamic in nature and may be modified during a test run by using map and unmap operations


Test Components

There are three ‘kinds’ of componentsMTC (Main Test Component) PTC (Parallel Test Component) Abstract Test System Interface defined as component

MTC

Test System

PTCPTC PTC


Real test system interface

MTC PTCnPTC1 PTC2



Port communication modelTest components are connected via their ports

Connections among components and between a component and the test system interface are port-oriented. p

Each port is modelled as an infinite FIFO queue Ports have direction (in, out, inout)There are three types of port

message-based, procedure-based or mixedTTCN-3 connections are port-to-port and port-to-test system interface connections

O i l ll d


One-to-many connections are also allowed

PTCMTCIN OUT

OUT IN

Connected Ports


Allowed Connections

test componentA

test componentB

test system test componentA

A B

test componenttest component

A

test system interface

test componentA

test componentB




test componentA A

test componentA

test componentB

test componentC



test componentB


NOT Allowed Connections


test componentA

test componentA

test componentB





test componentA

test system



Test Configuration

Test systemTest system


PTCMTCIN OUT

OUT IN

Connected Ports

INOUTMapped Ports

INOUT




INOUT

SUT


Minimal Test Configuration

TTCN-3 Executable

TTCN-3 Test SystemTest Control

TCI

SUT Adapter Platform Adapter


TTCN 3 Executable

TRI

MTCCodecs

Logging

Communication with IUT

Communication with SUT


y ( )

Implementation Under Test

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

Communication with IUT


Example Concurrent Test Configuration

TTCN-3

TTCN-3 Test SystemTest Control

TCI

MTC

SUT Adapter Platform Adapter


TTCN 3 Executable

TRI

Codecs

LoggingInternalCommunication PTC PTC

MTC


y ( )

Implementation Under Test

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


Defining communication port typesPorts are directional, by keywords in, out and inoutMessage-based ports defined by keyword message

type port MyMessagePortType message{{

in MsgType1, MsgType2;out MsgType3;inout integer

} Procedure-based ports defined by keyword procedure

Allows the remote call of the procedures, procs are defined as signaturestype port MyProcedurePortType procedure{

out Proc1, Proc2, Proc3}


} Mixed ports defined by keyword mixed

type port MyMixedPortType mixed{

in MsgType1, MsgType2, Proc1, Proc2;out MsgType3, Proc3, Proc4;inout integer, Proc5;

}


Defining component types

The component type defines which ports are associated with a componentIt is possible to declare constants, variables and timers local to a particular component

type component MyMTCType {

var integer MyLocalInteger = 0;

Test Component

Local


timer MyLocalTimer = 0.6;port MyMessagePortType PCO1, PCO4;port MyProcedurePortType PCO2;

} Ports Used

Declarations


Defining the test system interface

A component type definition is used to define the test system interface

t t M ISDNT tS t I t ftype component MyISDNTestSystemInterface {

port MyBchannelInterfaceType B1;port MyBchannelInterfaceType B2;port MyDchannelInterfaceType D1

}

The operation returning the component reference of the test


The operation returning the component reference of the test system interface is system.

map(MyMTCComponent:Port2, system:PCO1);











Declaring Constants

Denoted by the keyword constValue of the constant shall be assigned at the point of declaration

const integer MyConst1 := 1;const boolean MyConst2 := true, MyConst3 := false;



Declaring Variables

Denoted by the keyword varCan be declared and used in the module control part, test cases, functions and altsteps. Shall not be declared or used in a module definitions part

i.e. global variables are not supported in TTCN-3

A variable declaration may have an optional initial value assigned

EXAMPLE:


EXAMPLE:var integer MyVar1 := 1;var boolean MyVar2 := true, MyVar3 := false;


Declaring Timers

Timers can be declared and used in the module control part, test cases, functions and altstepsMay have an optional default duration value assigned to it.

Non-negative float value and the base unit is secondstimer MyTimer1 := 5E-3; // timer MyTimer1 with the default value of 5mstimer MyTimer2; // MyTimer2 without a default timer value

Timer arrays can also be declaredDefault duration(s) of the elements of a timer array shall be assigned using a value array


a value array timer t_Mytimer1[5] := { 1.0, 2.0, 3.0, 4.0, 5.0 }// all elements of the timer array gets a default durationtimer t_Mytimer2[5] := { 1.0, 2.0, 3.0, 4.0, - }// the last element (t_Mytimer2[4]) is left without a default duration


Declaring Procedure Signatures

Needed for procedure-based communicationDeclared by keyword “signature”Signatures for blocking and non-blocking communication

signature MyRemoteProc1 (); // blocking procedure-based communicationsignature MyRemoteProc2 () noblock; // for non blocking communication

• Only have in parameters and shall have no return value

Parameters of procedure signatures signature MyRemoteProc3 (in integer Par1, out float Par2, inout integer Par3);

V l t i t d


Value returning remote procedures signature MyRemoteProcFour (in integer Par1) return integer;

Specifying exceptions signature MyRemoteProcFive (inout float Par1) return integer

exception (ExceptionType1, ExceptionType2);


Declaring Templates – Message TemplatesTemplates are used to either transmit a set of distinct values or to test whether a set of received values matches the template specification. Instances of messages with actual values g

type record MyMessageType{

integer field1 optional,charstring field2,boolean field3

}

Templates for sending messages // a message template could be template MyMessageType MyTemplate:=

Templates for receiving messages// a message template might be template MyMessageType MyTemplate:={


p y g yp y p{

field1 := omit,field2 := "My string",field3 := true

}// a corresponding send operation could be MyPCO.send(MyTemplate);

{field1 := ?,field2 := pattern "abc*xyz",field3 := true

}

// a corresponding receive operation could be MyPCO.receive(MyTemplate);


Declaring Templates – Signature Templates

Instances of procedure parameter lists with actual values // signature definition for a remote procedure signature RemoteProc(in integer Par1, out integer Par2, inout integer Par3) return integer;// example templates associated to defined procedure signature template RemoteProc Template1:={Par1 :=1,Par2 :=2,Par3 :=3}template RemoteProc Template2:={Par1 := 1,Par2 := ?,Par3 := 3}template RemoteProc Template3:={Par1 := 1,Par2 := ?,Par3 := ?}

Templates for invoking proceduresDefines a complete set of field values for all in and inout parameters

MyPCO.call(RemoteProc:Template1); // Valid invocation MyPCO.call(RemoteProc:Template2); // Valid invocation MyPCO call(RemoteProc:Template3); // Invalid invocation because Par3 has no value


MyPCO.call(RemoteProc:Template3); // Invalid invocation because Par3 has no value

Templates for accepting procedure invocations Defines template against which the incoming parameter fields are matched

MyPCO.getcall(RemoteProc:Template1);// Valid getcall, match if Par1 == 1 and Par3 == 3 MyPCO.getcall(RemoteProc:Template2);// Valid getcall, match if Par1 == 1 and Par3 == 3 MyPCO.getcall(RemoteProc:Template3);// Valid getcall, match on Par1 == 1 and Any of Par3


Declaring Templates – Parameterization

Templates for both sending & receiving can be parameterized

// The template// The template template MyMessageType MyTemplate (integer MyFormalParam):={

field1 := MyFormalParam,field2 := pattern "abc*xyz",field3 := true

}


// could be used as follows pco1.send(MyTemplate(123));











Operator ListCategory Operator Symbol or Keyword

Arithmetic operators addition +subtraction -multiplication *division /division /modulo modremainder rem

String operators concatenation &Relational operators equal ==

less than <greater than >not equal !=greater than or equal >=less than or equal <=

Logical operators logical not notlogical and andlogical or or


logical or orlogical xor xor

Bitwise operators bitwise not not4bbitwise and and4bbitwise or or4bbitwise xor xor4b

Shift operators shift left <<shift right >>

Rotate operators rotate left <@rotate right @>


Operator (1/2)

Arithmetic operators : +, -, *, /, rem, modOperators shall be of type integer or float (mod for integer only)

String operators : concatenation (&)String operators : concatenation (&)E.g. '1111'B & '0000'B & '1111'B gives '111100001111'B

Relational operators : ==, <, >, !=, <=, >=Operands of “==” and “!=” may be of arbitrary e.g. record, set, union

Logical operators : not, and, or, xorBitwise operators : not4b, and4b, or4b, xor4b

operands shall be of type bitstring hexstring octetstring


operands shall be of type bitstring, hexstring, octetstringnot4b '01A5'O gives 'FE5A'O 'B'H and4b '5'H gives '1'H 'A9'O or4b 'F5'O gives 'FD'O '1001'B xor4b '0101'B gives '1100'B


Operator (2/2)

Shift operators : shift left (<<), shift right (>>)Left-hand operand shall be of type bitstring, hexstring or octetstring.Right-hand operand shall be of type integerRight-hand operand shall be of type integer'111001'B << 2 gives '100100'B'12345'H << 2 gives '34500'H'111001'B >> 2 gives '001110'B '12345'H >> 2 gives '00123'H

Rotate operators : rotate left (<@), rotate right (@>)Left-hand operand shall be of type bitstring, hexstring, octetstring,

h t i i l h t i


charstring or universal charstringRight-hand operand shall be of type integer'101001'B <@ 2 gives '100110'B "abcdefg" <@ 3 gives "defgabc" '12345'H @> 2 gives '45123'H


Functions (1/2)

Function ( ) • Functions are the building-blocks ofFunction ( . . . )

Program Part

Local Definitions

Functions are the building blocks of test system behaviour

• Functions have local declarations and a program part

• Can be a 'pure' function doing some data calculation, or can specify testbehaviour using communication

• operations such as send and receiveE t l d d fi d f ti


Part • External and pre-defined functions can be used


Functions (2/2)

Behaviour can be defined by program statements and operationsfunction MyFunction() return integer

{ return 7; }{ return 7; }

If a function uses variables, constants, timers and ports that are declared in a component type definition, the component type shall be referenced using the runs on keywords in the function header

function MyFunction3() runs on MyPTCType {var integer MyVar := 5; PCO1.send(MyVar);}

Parameterization of functionsfunction MyFunction2(inout integer MyPar1) { MyPar1 := 10 * MyPar1; }


function MyFunction2(inout integer MyPar1) { MyPar1 := 10 MyPar1; }

Invoking functionsMyVar := MyFunction4();MyFunction2(MyVar2);MyVar3 := MyFunction6(4)+ MyFunction7(MyVar3);


Predefined functionsCategory Function Keyword

Conversion functions Convert integer value to char value int2charConvert integer value to universal char value int2unicharConvert integer value to bitstring value int2bitConvert integer value to hexstring value int2hexConvert integer value to octetstring value int2octConvert integer value to charstring value int2strCo ve ege v ue o c s g v ueConvert integer value to float value int2floatConvert float value to integer value float2intConvert char value to integer value char2intConvert universal char value to integer value unichar2intConvert bitstring value to integer value bit2intConvert bitstring value to hexstring value bit2hexConvert bitstring value to octetstring value bit2octConvert bitstring value to charstring value bit2strConvert hexstring value to integer value hex2intConvert hexstring value to bitstring value hex2bitConvert hexstring value to octetstring value hex2octConvert hexstring value to charstring value hex2strConvert octetstring value to integer value oct2intConvert octetstring value to bitstring value oct2bit


Convert octetstring value to bitstring valueConvert octetstring value to hexstring value oct2hexConvert octetstring value to charstring value oct2strConvert charstring value to integer value str2intConvert charstring value to octetstring value str2oct

Length/size functions Return the length of a value of any string type lengthofReturn number of elements in a record, record of, template, set, set of or array sizeof

Presence/choice functions Determine if an field in a record, record of, template, set or set of is present ispresentDetermine which choice has been made in a union type ischosen

String functions Returns part of the input string matching the specified pattern description regexpReturns the specified portion of the input string substr

Other functions Generate a random float number rnd


Altstep (1/2)

altstep ( ) • To specify default behavioraltstep ( . . . )

Set of alternatives

Local Definitions

• To specify default behavior• To structure the alternatives of an alt

statement• May use definitions by refer

associated component type using runs on keyword

• May define local constants, variables and timers


alternatives • Invocation is always related to an altstatement


Altsteps (2/2)

Use definitions of component type and local definitionsaltstep AnotherAltStep(in integer MyPar1) runs on MyComponentType {

var integer MyLocalVar := MyFunction(); // local variableconst float MyFloat := 3 41; // local constantconst float MyFloat := 3.41; // local constant[] PCO1.receive(MyTemplate(MyPar1, MyLocalVar) {

setverdict(inconc);}[] PCO2.receive {

repeat}

}Invocation of altsteps

alt {[] PCO3 receive {


[] PCO3.receive {…

}[] AnotherAltStep(); // explicit call of altstep AnotherAltStep[] MyTimer.timeout { }

}


Test Case Definition

Test Case ( ) • Test cases are a special kind of f ti t d i th t l tTest Case ( . . . )

Behaviour Part

System Part

Interface Part

function executed in the control part of a module

• The interface part (runs on) references the type of the MTC

• The system part (system) references the type of the test system interface


• The behaviour part defines the behaviour of the MTC


A Test Case example

testcase SIP_UA_REC_V_01()runs on SipTestComponent system SipConfiguration

{{var default mydefault := activate (Default_1("0"));map(self:SIP_PCO, system:SIP_PCO);SIP_PCO.send(Invite_s_1); T1.start;SIP_PCO.receive(Response_r_1);setverdict (pass);


setverdict (pass);T1.stop;deactivate (mydefault);postamble("0");

}


Execution of a Testcase in Module Control Part

Execute statement

MyVerdict := execute(MyTestCase3(),5E-3);

Testcase can be parameterisedReturns the test verdictCan be time-supervised



Sequential behaviour

Statements shall be executed in the order of their appearance, i.e. sequentially

S1

The individual statements in the sequence shall be separated by the delimiter ";".

EXAMPLE:MyPort.send(Mymessage); MyTimer.start; log("Done!");


S1; S2; S3;

S1

S2

S3


Program Statements and Operations Overview

Usable in functions & test cases and in module control partBasic program statements, :=, if/else, for, while, do/while, label, goto, stop

Timer operations, start, stop, read, running, timeout

Execution of test cases, execute

Usable only in functions & test casesBehavioural program statements, alt, repeat, return

Default Handling, activate, deactivate


Configuration operations, create,connect,map,mtc,system,self,start,stop, done

Communication operations, send,call,reply,raise,receive,trigger,getcall,getreply,catch,check,clear,start,stop

Test verdict operations, setverdict , getverdict


Basic Program StatementsBasic program statements

Statement Associated keyword or symbolExpressions (…)Assignments :=

MyVariable := (x + y - increment(z))*3;log("Line 248 in PTC A") // rite a character string to some logging de ice

Assignments :Logging logLabel and Goto label / gotoIf-else if (…) { … } else { … }For loop for (…) { … }While loop while (…) { … }Do while loop do { … } while (…)Stop execution stop


log("Line 248 in PTC_A"); //write a character string to some logging devicelabel L1; … goto L1; //cannot jump out of or into functions, test cases, altsteps and module control partif (MyVar < 10) { MyVar := MyVar * 10; log ("MyVar < 10"); } else { MyVar := MyVar/5; }for (var float i:=1.0; i<7.9; i:= i*1.35) { … }while (j<10) { … }do { … } while (j<10); // executed at least once before the loop condition is evaluated for the first timestop // may terminate execution of test execution or relevant test component depending on the context in use


Behavioural Program Statements – Overview

Behavioural program statementsStatement Associated keyword or symbol

Behavioural program statements may only be used in test cases, functions and altstepsalt, interleave repeat may be used in module control only for timer operations

Specify the dynamic behaviour of the test components over the communication ports

Alternative behaviour alt { … } Re-evaluation of alt statements repeatInterleaved behaviour interleave { … }Returning control return


Specify the dynamic behaviour of the test components over the communication portsTest behaviour can be expressed

as a sequenceas a set of alternativescombinations of both

interleave operator is neglected in this course


Behavioural Program Statements – Alternative S1

S3S2

S1; alt {[] S2 {

alt {[] S4 { S7 }[] S5 {

alt {[] L1.receive(DL EST CO:*) {

S3

S6

S2

S4

S7

S5

S8

S9 S10

[] S5 {S8; alt {[] S9 {}[] S10 {}

}}

}}

[] S3 { S6 }}

alt {[x>1] L2 receive {


[] L1.receive(DL_EST_CO: ) {TAC.stop;setverdict(pass)

}[] TAC.timeout {

setverdict(inconc);}[] L1.receive {

setverdict(inconc)}[] AnotherAltStep ();

}

[x>1] L2.receive {setverdict(pass);

}[x<=1] L2.receive {

setverdict(inconc);}[else] {

setverdict(fail);stop;

}}


Behavioural Program Statements – Repeat

The repeat statement causes the re-evaluation of an altstatement, which shall only be used

A l t t t t f lt ti i lt t t tAs last statement of an alternative in an alt statement Or as last statement of a top alternative in an altstep definition

alt {[] PCO3.receive {

count := count + 1;repeat

}


[] T1.timeout { }[] any port.receive {

setverdict(fail);stop;

}}


Behavioural Program Statements – Return

The return statement terminates execution of a function and returns control to the point from which the function was called. A return statement may be optionally associated with a return valuereturn statement may be optionally associated with a return value

function MyFunction() return boolean {:if (date == "1.1.2000") {

return false; // returns false}:return true; // returned true

}

f ti M B h i () t di tt {


function MyBehaviour() return verdicttype {:if (MyFunction()) {

setverdict(pass); // use of MyFunction}else {

setverdict(inconc);}:return getverdict; // explicit return of the verdict

}


Default Handling

Statements for default handlingStatement Associated keyword or symbol

Activate a default activate

Default is activated altsteps, stored in form of a listactivate appends a new default to the end of the list deactivate removes a default from the listdefault can be identified by means of default reference

Activate a default activateDeactivate a default deactivate

var default DefVar := null;Th d f lt h i i


var default DefVar2 := activate(2ndAltStep());var default DefVar3 := activate(3rdAltStep());:DefVar := activate(MyAltStep());:deactivate(DefVar); // deactivates MyAltStep):deactivate; // deactivates all

The default mechanism is evoked at the end of each altstatement, if none of the specified alternatives could be executed


Configuration Operation – Overview Configuration operations

Statement Operation NameCreate parallel test component createConnect one component to another component connectConnect one component to another component connectDisconnect two components disconnectMap component port to test interface port mapUnmap port from test system interface unmapGet MTC address mtcGet test system interface address systemGet own address selfStart execution of test component startStop execution of test component stopCheck termination of a PTC runningWait for termination of a PTC done


Configuration operations are used to set up and control test componentsThese operations shall only be used in TTCN-3 test cases, functions and altsteps (i.e. not in the module control part)


Configuration Operation – Create

MTC is the only test component automatically created when test case starts. All other test components (the PTCs) shall be created explicitly during test execution by create operationsexplicitly during test execution by create operations

A component is created with its full set of ports of which the input queues are emptyIf a port is defined to be of the type in or inout it shall be in a listening state ready to receive traffic over the connectionAll component variables and timers are reset to their initial value Any component can create any other PTC

Each test case shall completely create its required configuration


Each test case shall completely create its required configuration of components and connections when it is invokedThe create operation shall return the unique component reference of the newly created instance

var MyComponenttype MyNewComponent;MyNewComponent := MyComponentType.create;


Configuration Operation – MTC, System, Self

The component reference has two operations, mtc and systemwhich return the reference of the master test component and the test system interface respectivelytest system interface respectivelyThe operation self can be used to return the reference of the component in which it is called

var MyComponentType MyAddress; MyAddress := self;


// Store the current component reference


Configuration Operation – Connect & Map

Connected PortsIN

MTC PTC

Test system

OUT IN

OUTMTC PTC

INOUT

SUT



Mapped Ports

INOUT

var MyCompType MyNewPTC;:

MyNewPTC :=MyCompType.create;::

connect(MyNewPTC:Port1, mtc:Port3);map(MyNewPTC:Port2, system:PCO1);


connect operation is used to connections between two test components Connects one port to another with the in side connected to the out side

map operation for connecting a test component to a test system interfaceAs a name translation defining how communications streams should be referenced

SUT


Configuration Operation – Disconnect & Unmap

The disconnect and unmap operations are the opposite operations of connect and mapThey perform the disconnection (of previously connected) ports ofThey perform the disconnection (of previously connected) ports of test components and the unmapping of (previously mapped) ports of test components and ports in the test system interface

connect(MyNewComponent:Port1, mtc:Port3);map(MyNewComponent:Port2, system:PCO1);

:


:disconnect(MyNewComponent:Port1, mtc:Port3);// disconnect previously made connection

unmap(MyNewComponent:Port2, system:PCO1);// unmap previously made mapping


Configuration Operation – Start & Stop

The start operation shall bind the required behaviour to the PTC and start the execution of its behaviour

Thi b h i i d fi d b f t l d d fi d f tiThis behaviour is defined by reference to an already defined function

By using the stop test component statement a test component (MTC or PTC) can stop its own execution or the execution of another test component (PTC)

var MyComponentType MyNewPTC;MyNewPTC := MyComponentType.create;// Creation of new test component


connect(MyNewPTC:Port1, mtc:Port3);// Connection of new component map(MyNewPTCt:Port2, system:PCO1); // with its environment.MyNewPTC.start(MyPTCBehaviour()); // Start of the new component.

MyNewPTC.stop; //The component is stoppedself.stop //Stop itself, can simple be “stop”


Configuration Operation – Running & Done

The running & Done operation allows behaviour executing on a test component to ascertain whether behaviour running on a different PTC test component has completeddifferent PTC test component has completed

The running operation is considered to be a boolean expression Done can be used to determine an alternative in an alt statement Keywords any or all can be used

if (PTC1.running){

alt {[] MyPTC.done {


// Do something! }

while (all component.running != true){

MySpecialFunction()}

setverdict(pass)}

[] any port.receive {goto alt

}[] all component.done {}

}


Communication Operation – OverviewCommunication operations

Communication operation Keyword Can be used at message-based ports

Can be used at procedure-based ports

Message-based communicationSend message send YesSend message send YesReceive message receive YesTrigger on message trigger YesProcedure-based communicationInvoke procedure call call YesAccept procedure call from remote entity getcall YesReply to procedure call from remote entity reply YesRaise exception (to an accepted call) raise YesHandle response from a previous call getreply Yes


Catch exception (from called entity) catch YesExamine top element of incoming port queuesCheck msg/call/exception/reply received check Yes YesControlling operationsClear port clear Yes YesClear and give access to port start Yes YesStop access (receiving & sending) to port stop Yes Yes


Communication Operation – General FormatsSending operations

A test component sends a message (send), calls a procedure (call), or replies to an accepted call (reply) or raises an exception (raise) p ( p y) p ( )

Receiving operations A component receives a message (receive), awaits a message (trigger),accepts a procedure call (getcall), receives a reply for a previously called procedure

Send part (Optional) response and exception handling partPort and operation

Value part (Optional) add expres

MyP1.call (MyProc:{Var1}) toMyPartner;

{ [] MyP1.getreply(MyProc:{MyVar2}) {}[] MyP1.catch(MyProc, ExceptOne) {}

}


procedure call (getcall), receives a reply for a previously called procedure (getreply) or catches an exception (catch)

Receive part (Optional) assignment part

Port and operation

Matching part (Optional) address

expression

(Optional) value

assignment

(Optional) parameter

value assignment

(Optional) sender value

assignmentMyP2.receive (Template(5,7)) fromAPeer

-> valueMyVar

param (V1)

senderAPeer


Message-based Communication (1/3)

Communication based on an asynchronous message exchangeNon-blocking on send operation, processing in the SENDER continuesBlocked on receive operation RECEIVER processes received messageBlocked on receive operation, RECEIVER processes received messageA trigger operation filters messages with certain matching criteria

Send operation

SENDER RECEIVER

send receive or trigger


Send operationMyPort.send(MyTemplate(5,MyVar));// Sends template MyTemplate with parameters 5 and MyVar via MyPort.MyPort.send(5);// Sends the integer value 5.MyPCO.send(MyVariable + YourVariable - 2) to MyPartner;// Sends the result to MyPartner in case of one-to-many connections.



Receive operationIf match is unsuccessful, top message shall not be removed from port queue

Top message removed if and only if, it satisfies all matching criteria

MyPort.receive(MyTemplate(5, MyVar));

MyPort.receive(charstring:"Hello")from MyPeer; // Matches charstring "Hello" from MyPeer

MyPort.receive(MyType:?) -> value MyVar; // Value of received message is assigned to MyVar.


MyPort.receive(A<B) -> sender MyPeer; // The address of the sender is assigned to MyPeer

MyPort.receive; // With no argument list, equivalent to the OTHERWISE in TTCN-2

any port.receive(MyMessage); // To receive a message on any port



Trigger operation Messages at the top of the queue that do not fulfil the matching criteria are removed from the port without any further actionfrom the port without any further action

MyPort.trigger(MyType:?); // Specifies that the operation will trigger on the reception of the first message observed of the type MyType with an arbitrary value at port MyPort.

MyPort.trigger(MyType:?) from MyPartner; // Triggers on the reception of the first message of type MyType at port MyPort received from MyPartner.

MyPort.trigger(MyType:?) from MyPartner -> value MyRecMessage; // This example is almost identical to the previous example. In addition, the message which triggers i.e. all matching criteria are met, is stored in the variable MyRecMessage.

MyPort.trigger(MyType:?) -> sender MyPartner; // Identical to the first example. In


addition, sender component reference will be retrieved and stored in variable MyPartner.MyPort.trigger(integer:?) -> value MyVar sender MyPartner; // Trigger on the reception

of an arbitrary integer value which afterwards is stored in variable MyVar. The reference of the sender component will be stored in variable MyPartner.

MyPort.trigger from MyPartner;any port.trigger;


Procedure-based Communication (1/5)

To call procedures in remote entities (SUT or test component)blocking procedure-based communication

blocking on the calling and the called side

bl ki d b d i ti

CALLER CALLEE

call getcall

reply orraise exception

getreply orcatch exception

blocking blocking


non-blocking procedure-based communication only is blocking on the called side

CALLER CALLEE

call getcall

raise exceptioncatch exception

blockingnon-blocking



Call operation: invoke procedure callA test component calls a procedure in SUT or in another test componentInformation transmitted in the send part of the call operation is a signatureInformation transmitted in the send part of the call operation is a signature

May either be defined in the form of a signature template or be defined in-lineHandling of responses or exceptions is done by using getreply and catch

As alternatives in alt statements, no usage of else and altstep, no defaultMay use boolean expression for condition, time value for timeout

signature MyProc3 (out integer MyPar1, inout boolean MyPar2) return ResultTypeexception (ExceptionTypeOne, ExceptionTypeTwo);

M P t ll(M P 3 { t } 20E 3) t M P t { // C ll f M P 3


MyPort.call(MyProc3:{ -, true }, 20E-3) to MyPartner { // Call of MyProc3[ ] MyPort.getreply(MyProc3:{?, ?}) -> value Result param (MyPar1Var, MyPar2Var) { }[ ] MyPort.catch(MyProc3, MyExceptionOne) { setverdict(fail); stop; }[ ] MyPort.catch(MyProc3, ExceptionTypeTwo : ?) { setverdict(inconc); }[MyCondition] MyPort.catch(MyProc3, MyExceptionThree) { }[ ] MyPort.catch(timeout) { setverdict(fail); stop; }

}



Getcall operation: accept procedure call from remote entity

M Port getcall // Remo es the top call from M PortMyPort.getcall; // Removes the top call from MyPort. MyPort.getcall from MyPartner; // Removes a call from MyPartner from port MyPortany port.getcall(MyProc); //To getcall on any port is denoted by the any keywordMyPort.getcall(MyProc(5, MyVar)); // accepts a call of MyProc at MyPort MyPort.getcall(MyProc:{5, MyVar}) from MyPeer; // accepts a call of MyProc from MyPeerMyPort.getcall(MyProc:{5, MyVar}) -> param(MyVar1, MyVar2) sender MySenderVar;

// The address of the calling party is retrieved and stored in MySenderVarMyPort.getcall(MyProc:{?, MyVar}) -> param( - , MyVar2);


// The value of the first inout parameter is not important or not used

signature MyProc2(in integer A, integer B, integer C, out integer D, inout integer E); MyPort.getcall(MyProc2:{?, ?, 3, -, ?}) -> param (MyVarA, MyVarB, - , -, MyVarE); MyPort.getcall(MyProc2:{?, ?, 3, -, ?}) -> param (MyVarA:= A, MyVarB:= B, MyVarE:= E);



Reply operation: reply to procedure call from remote entityAll out and inout parameters of the signature shall have a specific value

MyPort.reply(MyProc2:{ - ,5}); // Replies to an accepted call of MyProc2.MyPort.reply(MyProc2:{ ,5}); // Replies to an accepted call of MyProc2.MyPort.reply(MyProc2:{ - ,5}) to MyPeer; // Replies to an accepted call of MyProc2 from MyPeerMyPort.reply(MyProc2:{5,MyVar} value 20); // Replies to an accepted call of MyProc2.

Getreply operation: handle response from a previous callMyPort.getreply; // Removes the top reply from MyPort.MyPort.getreply from MyPeer; // Removes the top reply received from MyPeer from MyPort.any port.getreply(Myproc); //To get a reply on any port use the any keyword. MyPort.getreply(MyProc:{5, ?} value 20); // Accepts a reply of MyProc with a return value of 20MyPort getreply(MyProc2:{ 5}) from MyPeer; // Accepts a reply of MyProc from MyPeer


MyPort.getreply(MyProc2:{ - , 5}) from MyPeer; // Accepts a reply of MyProc from MyPeerMyPort.getreply(MyProc1:{?, ?} value ?) -> value MyRetValue param(MyPar1,MyPar2);

// The returned value is assigned to variable MyRetValue and the value // of the two out or inout parameters are assigned to the variables MyPar1 and MyPar2.

MyPort.getreply(MyProc1:{?, ?} value ?) -> value MyRetValue param( - , MyPar2) senderMySender;// The value of the first parameter is not considered for the further test execution and // the address of the sender component is retrieved stored in the variable MySender.



Raise operation: raise exception (to an accepted call)An exception is a exceptional reaction to an accepted procedure callType of exception shall be specified in signature of the called procedureType of exception shall be specified in signature of the called procedure

MyPort.raise(MySignature, MyVariable + YourVariable - 2);// Raises an exception with a value which is the result of the arithmetic expression at MyPortMyPort.raise(MyProc, integer:5}); // Raises an exception with the integer value 5 for MyProcMyPort.raise(MySignature, "My string") to MyPartner;// Raises an exception with the value"My string" at MyPort for MyProc and send it to MyPeer

Catch operation: catch exception (from called entity)any port.catch; MyPort.catch; MyPort.catch from MyPartner; MyPort.catch -> sender MySenderVar;


[] MyPort.catch(timeout) { … }MyPort.catch(MyProc, integer: MyVar);

// Catches an integer exception of value MyVar raised by MyProc at port MyPort.MyPort.catch(MyProc, charstring:"Hello")from MyPeer; // Catches "Hello" exceptn from MyPeerMyPort.catch(MyProc, MyType:?) from MyPartner -> value MyVar;MyPort.catch(MyProc, MyTemplate(5)) -> value MyVarTwo sender MyPeer;

// Assignment of the exception value and the retrieval of the address of the calling component


Communication Operation – Check

Check msg/call/exception/reply receivedThe receiving operations receive, getcall, getreply and catch together with their matching and assignment parts are used to define the conditionwith their matching and assignment parts, are used to define the condition that has to be checked and to extract values of its parameters if requiredA copy of the top element of an incoming port queue is made and the receiving operation is performed on the copy, I.e. not remove

MyPort1.check(receive(5)); // Checks for an integer message of value 5.MyPort2.check(getcall(MyProc:{5, MyVar}) from MyPartner);

// Checks for a call of MyProc at port MyPort2 from MyPartnerMyPort2.check(getreply(MyProc:{5, MyVar} value 20));


// Checks for a reply from procedure MyProc at MyPort2 where the returned value is 20 and// the values of the two out or inout parameters is 5 and the value of MyVar.

MyPort2.check(catch(MyProc, MyTemplate(5, MyVar)));MyPort2.check(getreply(MyProc:{?, MyVar} value *) -> value MyReturnValue param(MyPar));MyPort.check(getcall(MyProc:{5, MyVar}) from MyPartner -> param (MyPar1Var, MyPar2Var));MyPort.check(getcall(MyProc:{5, MyVar}) -> sender MySenderVar);


Communication Operation – Controlling ports

clear: remove the contents of an incoming port queueMyPort.clear; // clears port MyPort

start: start listening at and give access to a portstart: start listening at and give access to a portIf a port is defined as allowing receiving operations such as receive, getcalletc., the start operation clears the incoming queue of the named port and starts listening for traffic over the portIf the port is defined to allow sending operations then the operations such as send, call, raise etc., are also allowed to be performed at that port

MyPort.start; // starts MyPort

stop: stop listening and disallow sending operations at a port


stop: stop listening and disallow sending operations at a portIf a port is defined as allowing receiving operations such as receive and getcall, the stop operation causes listening at the named port to ceaseIf the port is defined to allow sending operations then stop port disallows the operations such as send, call, raise etc., to be performed

MyPort.stop; // stops MyPort


Timer OperationsTimer operations

Statement Associated keyword or symbolStart timer Start Stop timer Stop

Timer values shall be non-negative float numbers (i.e. greater or equal 0.0)MyTimer1.start; // MyTimer1 is started with the default duration MyTimer2.start(20E-3); // MyTimer2 is started with a duration of 20 msMyTimer1.stop; // stops MyTimer1

Stop timer StopRead elapsed time ReadCheck if timer running runningTimeout event timeout


all timer.stop; // stops all running timers var float Myvar;MyVar := MyTimer1.read; // assign to MyVar the time that has elapsed since started if (MyTimer1.running) { … } // check if running, return true or falseMyTimer1.timeout; // checks for the timeout of the started timer MyTimer1 // shall not be used in a boolean expression, but can be used in an alt statement


Test Verdict Operations (1/2)

Verdicts: pass, fail, inconc, none, errorEach test component has its own local

Test verdict operations

Statement Associated keywordverdict

Can be written (set) and read (get)Global verdict returned by Test Case

Set local verdict setverdict

Get local verdict getverdict

Verdict returned by the test case when it terminatesPIF


MTC PTC1 PTC2

P

I

setverdict(inconc)setverdict(fail)

F P

setverdict(pass)


Test Verdict Operations (2/2)setverdict(pass);setverdict(inconc);MyResult := getverdict; // Where MyResult is a variable of type verdicttypeMyResult : getverdict; // Where MyResult is a variable of type verdicttype

Overwriting rules for the verdict


Error verdictSet by the test system to indicate a test case (run-time) error has occurredShall not be set and will not be returnedNo other verdict value can override an error verdict


Module Control Part

• Module control is the ‘dynamic’ part of a TTCN-3 specification

Test Case

Local Declarations

Controlpart 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

B i i t t t


Execution • Basic programming statements may be used to select and control the execution of the test cases


Module Control Statements & Operations

Usable in functions & test cases and in module control partBasic program statements, :=, if/else, for, while, do/while, label, goto, stop

Timer operations, start, stop, read, running, timeout

Execution of test cases, execute

Control{

var integer count := 0;var verdicttype myVerdict := pass;

if ( execute (UA_REC_V_01()) == pass) {


{while ( count <= 10 ) {

myVerdict := execute(UA_REC_V_02(), 5E3);// complete within 5ms, otherwise verdict is error count := count + 1;

} // end while} // end if

} // end control




Top 5 Errors Made in Writing TTCN-3 Test Suites Use of verdict.set(pass) or verdict.get() constructs is disallowed

Should use setverdict(pass) or getverdict (without parentheses) instead

E li itl t i l f t t i di ll dExplicitly returning a value from a test case is disallowedexecute(MyTestcase()) implicitly returns a verdict upon its termination

no return fail; but setverdict(fail); stop; no return getverdict but stop;

Hexadecimal notation for integers is not available in TTCN-3.write 35 instead of 0x0023

Named alt is an obsolete name for what is now called altstep


Activate construct is now an operation that can be part of an expressioncannot be used as a standalone statement anymore

Instead of writing activate(MyDefault()); you shall write

var default myDefaultRef := activate(MyDefault());


Outline





Graphical



Standards

ETSI ES 201 873

P t 2 "TTCN 3 T b l P t ti F t"Part 2: "TTCN-3 Tabular Presentation Format";

Part 3: "TTCN-3 Graphical Presentation Format (GFT)";



Tabular – Test Suite Control (1/2)



Tabular – Test Suite Control (2/2)



Tabular – Test Suite Parameters



Tabular – Module Imports



Tabular – Simple Types



Tabular – Structured Types



Tabular – Enumerated Types



Tabular – Port Types



Tabular – Component Types



Tabular – Constants



Tabular – Signature



Tabular – Structured Template



Tabular – Function (1/2)



Tabular – Function (2/2)



Tabular – Altstep (1/2)



Tabular – Altstep (2/2)



Tabular – Test Case (1/2)



Tabular – Test Case (2/2)



Graphical Presentation Format (GFT)

GFT is based on MSC-2000GFT uses the TTCN-3 data descriptionsGFT defines several MSC extensions to make MSC-2000 applicable in the testing contextIn GFT each TTCN-3 test case, function and test step is presented in form of a GFT diagramGFT defines only the requirements for a graphical presentation of the module structure, but no concrete graphics


, g p


Graphical – Control Diagram



Graphical – Test Case Diagram



Graphical – Function Diagram



Graphical – Altstep Diagram



Graphical – If-else



Graphical – Loops



Graphical – Alt



Graphical – Blocking Call



GFT Examples (1)

testcase MyTestCase (in boolean internetService, inout integer nrPass)runs on MtcType system TestSystemtype

MtcType

mtcmPCOtype

P1mCPtypemCPO

var default def := activate(MyDefault())

var reportType report


map(self:P1,System:mPCO)

if (internetservice)

newInternetPTC()


GFT Examples (2)function aGuest(in float eatingDur) runs on GuestType

GuestTypeself

gPCOtypeP1

pCPtypeCP

timer T1

var defaultdef := activate(GuestDefault())

T1(waitPizzaDur)standardPizzaOrder

PizzaTypeT1


pass

standardPaymentT1 (eatingDur)

T1

{guest, getverdict)

ReportType


Outline





Graphical



Standard

ETSI ES 201 873 Part 5: “TTCN-3 Runtime Interface (TRI)”P t 6 “TTCN 3 C t l I t f (TCI)”Part 6: “TTCN-3 Control Interface (TCI)”

General Structure of a TTCN-3 Test SystemTTCN-3 Runtime Interface and operationsTTCN-3 Control Interface and operations


Java language mappingANSI C language mapping


General Structure of a TTCN-3 Test System



General Structure of a TTCN-3 Test System



TM in a TTCN-3 Test System

Test Management (TM)Test Control (TC), responsible for overall management of test system, test

fexecution starting, and user interface implementation

Test Logging (TL), responsible for maintaining the test log, notified by the TE to log test events, record test management info generated by the TC

External CoDecs (ECD), responsible for encoding/decoding data associated with message or procedure based communication in the TE

Component Handler (CH), responsible for distributing parallel test t ll th TM t t d t l di t ib t d t t t


components, allows the TM to create and control distributed test systems


TE & Adapters in a TTCN-3 Test System

TTCN-3 Executable (TE)Responsible for the interpretation or execution of the TTCN-3 ATS

Executable Test Suite (ETS), handles the execution or interpretation of test cases, the sequencing and matching of test events defined

TTCN-3 Runtime System (T3RTS), interacts with the TM, SA and PA entities via TCI and TRI, and manages ETS and EDS entities

Encoding/Decoding System (EDS), responsible for the encoding and


g g y ( ), p gdecoding of test data, which includes data used in communication operations with the SUT


Adapters in a TTCN-3 Test System

SUT Adapter (SA)Adapts communication of test system with the SUT to the particular execution platform of the test systemexecution platform of the test system

Platform Adapter (PA)Implements TTCN-3 external functions and provides a TTCN-3 test system with a single notion of time



TTCN-3 Runtime Interface

The TRI defines the interaction between the TTCN-3 Executable (TE), SUT Adapter (SA), and Platform Adapter (PA) entities

TRI id f th TE t d t t d t t th SUT i l tTRI provides a means for the TE to send test data to the SUT or manipulate timers, and similarly to notify the TE of received test data and timeouts

The TRI can be considered to consist of two sub-interfacesThe triCommunication interface addresses the communication of a TTCN-3 ETS with the SUT, which is implemented in the SAThe triPlatform interface represents a set of operations, which adapt an ETS to a particular execution platform


p p


Correlation between TTCN-3 and TRI Operations


Lots of other TRI operations


TTCN-3 Control InterfaceThe TCI defines the interaction between the TTCN-3 Executable (TE), Component Handling (CH), the Test Management (TM), and the Coding/Decoding (CD) entities within a TTCN-3 test system

Provides means for the TE to manage test execution; distribute execution of test components among different test devices; and encode and decode test data.

The TCI consists of three sub-interfacesTCI Test Management Interface (TCI-TM), includes all operations needed to manage test execution, provide module parameters and external constants and provide test event loggingTCI Component Handling Interface (TCI-CH), consists of operations needed to implement the management of, and communication between TTCN-3 test components in a centralized or distributed test system It includes operations to


components in a centralized or distributed test system. It includes operations to create, start and stop test components, establish connection between TTCN-3components, manage test components and their verdicts, and handle message and procedure based communication between TTCN-3 components;TCI Coding/Decoding Interface (TCI-CD), includes all operations needed to retrieve and access codecs, i.e. encoders or decoders, for encoding data to be sent, defined using the TTCN-3 encode attribute, and to decode received data.


Correlation between TTCN-3 and TCI Operations

her T

CI o

pera

tions


Lots

of o

th


Danet – TTCN-3 Toolboxhttp://www.danet.de/ (TTCN-2 Toolbox see Chapter IV)Designed to meet the challenges of communications-based testing

Ranging from development environments over integration and system testing up toRanging from development environments over integration and system testing up toservice and network integration testing on large test floors

Its design is open, flexible and extensibleOpen means that all major interfaces of the TTCN-3 Toolbox are disclosedFlexible means that the TTCN-3 Toolbox can be adapted to your environmentExtensible stands for mission to find complete solutions meeting your requirements

Ready for Datacom testing (synchronous client/server communications),Telecom testing (asynchronous message exchange) and Web Service testing


Telecom testing (asynchronous message exchange) and Web Service testing(XML-based communications)


TTCN-3 Toolbox Structure



Testing Technologies – TT Tool Series

http://www.testingtech.de/

TTspec – the graphical test development toolp g p p

TTthree – the TTCN-3 to Java compiler

TTsuite – the collection of 3G and Internet test suites

TTman – the test execution and control tool

TTtwo2three – the TTCN-2 to TTCN-3 translator



Testing Technologies – TTspec

The graphical test development environment for user-friendly testdefinition, documentation and visualization of test executions in the modern powerful and standardized test technology TTCN 3the modern, powerful and standardized test technology TTCN-3



Testing Technologies – TTthree

The TTCN-3 to Java compiler supporting automated, rapid and flexible test development on all major platforms in the modern, powerful and standardized test technology TTCN 3powerful and standardized test technology TTCN-3



Benefits of TTCN-3

TTCN-3 is specifically designed for testingThe syntax and operational semantics of TTCN-3 tests are commonly understood and not related to a particularcommonly understood and not related to a particular programming languageTTCN-3 tests concentrate on the purpose of the test and are abstracted from particular test system detailsOff the shelf tools and TTCN-based test systems are readily availableThe language is constantly maintained and developed


The language is constantly maintained and developedEducation and training costs can be rationalized and reducedMaintenance of test suites and products is easierAllows the application of a common methodology and style, both on a corporate level and within standardization


TTCN-3 OutlookMajor telecoms companies are developing migration plans for moving from TTCN-2 to TTCN-3Extensibility and flexibility could make TTCN-3 a unifying technology y y y g gyculminating classical conformance testing with interoperability and software testing with a single languageShort term

Replacing TTCN-2 in functional and conformance testing as standard languageIncreasing use within the IP world especially for text based protocolsPossible key technology in the IP/telecom convergence

Medium termExpanding from pure protocol testing to software testing and interworking testing


Expanding from pure protocol testing to software testing and interworking testingPossible key technology for unifying testing technology across whole product development

Long termReal time and performance testing? (European INTERVAL project)Integration with UML (UML testing profile)

Documents

¾ VIII. TTCN-3 ¾ TTCN-3 presentation · PDF file521265A Telecommunication Software Ch8 – TTCN-3 VIII. TTCN-3 Dept. Electrical & Information Engineering, Computer Engineering Lab