ttcn3 basics

TTCN-3

© 2012 -TCLOUD Information Technologies Pvt Ltd

by TCLOUD Information Technologies (P) LTD

Introduction to TTCN-3

� Introduction to TTCN-3

� Capabilities of TTCN-3

� Message based concepts & Procedure Based Communicat ion� Managing concurrency and parallel testing with TTCN -3� Concurrent testing configurations, communication me chanisms,


� TTCN-3 test system in a nutshell� SUT, TMC, TE, TCI, TRI, SA, PA, components, ports

�TTCN first saw the light of day as a fledgling language in the mid-1980s.

�Since the, it has arguably progressed to be the de facto standardized language for writing test specifications.

�some ten years later, new technologies, not least the advent of the internet and the merging of mobile and fixed telecommunications, put

Introduction : TTCN-3


internet and the merging of mobile and fixed telecommunications, put pressure on TTCN to modernize. That, together with a growing perception in industry that rigorous and efficient testing was not a luxury but rather a necessity, made ETSI (European Telecommunication Standardization Institute) to decide to overhaul the original ISO/IEC TTCN specification.

�The result was TTCN-3.

Introduction to TTCN -3



� Message based concepts & Procedure Based Communicat ion� Managing concurrency and parallel testing with TTCN -3� Concurrent testing configurations, communication me chanisms



To test the SUT, we need to exchange messages with it. The two most important operations to do this are the send operation and the receive operation. The send operation can be used to send a message to the SUT. The receive operation compares a received message against a template. If the message matches the template, then the message is removed from the message queue.

Message-based communication

Capabilities of TTCN -3 (1)…

testcase tc_purchaseA () runs on TVMTester {


testcase tc_purchaseA () runs on TVMTester {// request the ticketpt_request.send( a_ticketA );pt_ticket.receive( a_payticket );// pay the ticketpt_cash.send( a_coin50 );pt_cash.send( a_coin100 );pt_ticket.receive( a_ticketA );setverdict( pass );};

Procedure-based communication

TTCN-3 procedure-based communication is used to model the (remote) method invocation of IDL. Indeed, the procedure-based communication mechanism of TTCN-3, with the separation of in, out, and inout parameters, has been modelled on IDL to serve exactly this purpose.

Capabilities of TTCN -3 (2)...


Concurrent TTCN -3

� Why do we need a concurrent test architecture?

Capabilities of TTCN -3 (3)…Managing concurrency and parallel testing withTTCN -3


� What kind of architectures can be used?

� How TTCN-3 supports such architectures?

� TTCN-3 Configuration Operations.

� Tips and Guidelines.

Terminology� PCO Point of Control and Observation� CP Control Point (Port type)� MTC Main Test Component (Component type)� PTC Parallel Test Component (Component type)� TS Test System

Capabilities of TTCN -3 (4)…Managing concurrency and parallel testing withTTCN -3


� TS Test System� TSI Test System Interface� SUT System Under Test

Capabilities of TTCN -3: Managing concurrency(5)…

Why do we need a concurrent test architecture?..

� By nature, devices and users which are interfaced to the SUT are functioning in a concurrent manner.

� Even with perfectly synchronized inputs to the SUT, there are no guaranties that the SUT will reply with the exact same sequence of outputs.


outputs.

Capabilities of TTCN-3: Managing concurrency (6)…

Tester T1 sends the message A to the SUT

� The SUT replies to both Testers, T1 and T2

� The SUT first sends C to T2, then B to T1

� Therefore the Test Sequence is {T1!A, T2?C, T1?B}


Why do we need a concurrent test architecture?

� The non-deterministic behaviors of the SUT and the channel delays yield to a set of possible sequences.

- This trivial example yields to two possible outcomes.� Having this kind of alternatives would soon generate very complex non-concurrent test case descriptions.


testcase TC_NonConcurrent_01()runs on HostYpe {


T1.send(A);alt {

[ ] T1.receive(B) {T2.receive(C)

}[ ] T2.receive(C)

T1.receive(B)}}

// Other events...}


Why do we need a concurrent test architecture?

� Conformance testing:- A PBX must accept 12 simultaneous connection requests.- A railroad switching controller must compute inputs from four

detection devices and give feedback.


� Service, function and feature testing:- Establish a 3-way conference.

� Stress, robustness and load testing:- System must accept 13 simultaneous Service Requests multiple

times during a sustaining period of time.


� Each tester uses different set of messages and interfaces: multiple port types.

� Each tester is different: multiple component types.

� But one port type per component type



� Architecture with multiple testers of different types.

� Each tester type can have multiple kind of interfaces



� The Executable Test suite can be:

-One Node - Multi-threaded (simplest, Default)-Multi-Node-Mixed



Benefits with concurrent TTCN

� Less code to write� Can have several test architectures in the same test suite� Several service providers can be used.� Other components can be created at any time during


� Other components can be created at any time during the test case execution.� Concurrency

- we can have several components executing simultaneously

- Several processes aiming at the same goal

Introduction to TTCN-3



� Message based concepts & Procedure Based Communicat ion� Managing concurrency and parallel testing with TTCN -3� Concurrent testing configurations, communication me chanisms



TTCN-3 Test System in a nutshell (1)…

TTCN-3 specifies a test but a test system is needed for test execution

TRI and TCI standards define test system architecture

Test System Executor

Test Control

[compiled]TTCN-3 Executable

CodecsLogging

TTCN-3 Test System

TCI

TRI


– TTCN- 3 tools are required to support internal interfaces

– Allows reuse of test platforms with different tools but also for different SUTs

SUT Adapter Platform Adapter

System Under Test (SUT)

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

An example adaptation: A IPv6 test system

Test System Executor

ParameterFile

IPv6 Codecs

ToolLogging

TTCN-3 Test System

TCI


A test system requires:

� A TTCN-3 tool = TTCN-3 compiler and execution environment� A test platform for a specific


Ethernet Adapter Real-time Adapter

Open Source FreeBSD Router

[compiled]

IPv6 ATS TTCN-3 Executable

TRI

� A test platform for a specific device under test

� Note: Tools come with default Test Control & Logging


TTCN-3 code is not executable by itself. It needs to be interpreted or translated into some executable format. TTCN-3 test system provides the following parts outside of the TTCN-3 code.

TM: Handles the overall test management by passing TTCN-3

Architecture of a TTCN-3 system


management by passing TTCN-3 module parameters to the TE, and by instructing it to start and stop execution of the test cases.

CH: The CH entity enables the distribution of the TE over several devices (if required) by passing information of test case events between the distributed TEs.


CD: Responsible for encoding the message into some format that is understood by the SUT. Responsible for decoding the message from SUT into TTCN-3 value


TTCN-3 value representation.

TL: The TL entity is responsible for maintaining test logs, which consists of events the TE notifies it about.

TTCN-3 Test System in a nutshell (5)…TE: The TE entity corresponds to the executable code resulting from compilation or interpretation of an Abstract Test Suite (ATS), which consists one or more TTCN-3modules

SA: Handles the actual interaction with the SUT, when this is requested by the

Architecture of a TTCN-3 system


the SUT, when this is requested by theTE or initiated by the SUT, and it also notifies the TE about any incoming events coming from the SUT (messages, function calls).

PA: The Platform Adapter (PA) realizes the external function call statements of TTCN-3, and it provides to the TE a timer service.

TCI: Exist between the TE and TMC,and between the TE and SA



and between the TE and SA and PA. It specifies the interface for user-implemented codecs.

TRI: Exist between TE and SA and PA. Most of the operations the interface provides are implemented by the SA and PA, and called by the TE.


Inside TTCN -3 Executable


Component:•A component is a user specified entity, which contains user-defined ports.•can interact with other components and the SUT with message and procedure operations. • May contain private variables and timers. The component itself does not specify any kind of behavior but it provides an environment for it. •This means that one can start functionality in the component and this functionality can then use the ports, variables, and timers of the component.• The functionality that can be started in the component can be either a test case or a function.

TTCN-3 Test System in a nutshell (8)…Inside TTCN -3 Executable

Port:• When two components want to communicate with each other, the ports of the componentshave to be first connected with each other.


TSI:• Unlike the other components, one cannot start any functionality in it,• It does not have any internal variables or timers. This component acts as an abstract. •Interface between the test case and the System Under Test (SUT). •The ports of the system component (TSI) are visible to the SUT Adapter, which routes any messages or procedure operations seen at these ports between the test case components and the real test system interface at the SUT..

• When a component needs to communicatewith the SUT, its port has to be mapped with one of the ports of the TSI component

TTCN-3 Executable

TTCN-3 Test System

TRI

Test Control

Codecs

Logging

TCI

InternalCommunication

PTC PTC

MTC

TTCN-3 Test System in a nutshell

Inside TTCN-3 Executable : Concurrent Test ConfigurationMTC is responsible for creating other components which are called Parallel Test Components,and for starting functionality in them.


SUT Adapter Platform Adapter

System Under Test (SUT)

TRI

Implementation Under Test

All test behavior is executed on one (main) test c omponentA test involves execution of many parallel test com ponentsDynamic instantiation of components and communicati on links

So…what is new in TTCN -3 and what are the TTCN -3 corner stones??

� Main new aspects& Concepts of TTCN3• Different TTCN-3 Presentation Formats• Logging Aspects

� Basic Elements of TTCN-3• Basic Language Elements

- Core Language Elements- Scoping Rules- Basic Programming Statements- Expressions- Operators & their Precedence


- Operators & their Precedence- Control Transfer Statements, Module Import, Module Parameterization

• TTCN-3 Types- Basic & Structured Types- Any Type, Sub typing - Timer

� Building blocks of TTCN-3 -Type Definitions-Templates-Test Configurations-Test cases

Main new aspects& Concepts of TTCN 3

TTCN can be integrated with types systems of other languages

Fully harmonized with ASN.1 (1997)TTCN-3

Core IDL Types &

XML Types &

Values

ASN.1 Types

& Values

Use of TTCN -3 With Other Languages


with ASN.1 (1997)

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

Core Language

IDL Types &

Values

Other types & Values n

IDL: Integration Description Language


Different TTCN-3 Presentation FormatsThe Core Language and Other Presentation Formats

TTCN-3

Text format

Tabular

Format

Core format is text based (most popular)

TTCN-3 can be edited or viewed in other formats

� Tabular format


TTCN-3 Core Language Presentation

Format 3

PresentationFormat n

Graphical Format

� Tabular format (for TTCN-2 people)

� Graphical format (good for visual overview)

� Other standardized formats in the future?

� Proprietary formats possible

Main new aspects & Concepts of TTCN 3

testcase TC_resolveTCLOUDWww() runs on DnsClient{

timer t_ack;serverPort.send(m_dnsQuestion("www.tcloudtech.com"));t_ack.start(1.0);alt {

[] serverPort.receive(mw_dnsAnswer("176.136.72.81")) {

setverdict (pass);}

Different TTCN-3 Presentation Formats: Example Core (Text) Format


}

[] serverPort.receive { // any other messagesetverdict(fail);}

[] t_ack.timeout {setverdict(inconc);

}

}t_ack.stop;

}


Different TTCN-3 Presentation Formats Example Grap hical Format

testcase TC_resolveTCLOUDWww() runs on DnsClient

DnsClient

mtc

DnsPort

serverPort

m_dnsQuestion("www.tcloudtech.com")

timer t_ack

t_ack


m_dnsQuestion("www.tcloudtech.com")t_ack

altmw_dnsAnswer("176.136.72.81")

?

t_ack

inconc

fail

pass

t_ack

Main new aspects& Concepts of TTCN 3Different TTCN-3 Presentation Formats Example Tabu lar Format

Testcase

Name TC_resolveTCLOUDWww()

Group

Purpose

System Interface

MTC Type DnsClient

Comments

Local Def Name Type Initial value Comments

t_ack timer


t_ack timer

Behavior

serverPort.send(m_dnsQuestion("www.tcloudtech.com"));

t_ack.start(1.0);

alt {

[] serverPort.receive(mw_dnsAnswer("176.136.72.81")) { setverdict (pass); }

[] serverPort.receive // any other message{ setverdict(fail); }

[] t_ack.timeout{ setverdict(inconc); }

}

t_ack.stop;

Detailed Comments:


� Logging Aspects

It is allowed to use in a user log statement• literal values (incl. charstrings -> the only logged item in v.2.2.1)• module parameter values• constant (TTCN-3, ASN.1 or external) values.• templates.• variable values.• component instance actual values and names.


• component instance actual values and names.• component states (running & alive).• port states.• timer states and elapsed time.• default reference values (incl. 'UNITIALIZED' ).• function return values (TTCN-3 or external).• formal parameter values.

Main new aspects& Concepts of TTCN3

� Main new aspects& Concepts of TTCN3• Triple C, Module concept, Extendibility• Different TTCN-3 Presentation Formats• Logging Aspects


- Core Language Elements- Scoping Rules- Basic Programming Statements- Expressions


- Expressions- Operators & their Precedence- Control Transfer Statements, Module Import, Module Parameterization



Basic Elements of TTCN -3: Basic Language Elements

Core Language Elements(1)

• Keywords per language element• TTCN-3 module definition: module• Import of definitions from other module: import• Grouping of definitions: group• Data type definition: type• Communication port definitions: port• Test component definitions: component• Signature definitions: signature


• Signature definitions: signature• External function/constant definitions: external• Constant definitions: const• Data/signature template definitions: template• Function definitions: function• Alt step definitions: altstep• Test case definitions: test case• Variable declarations: var• Timer declarations: timer

• Keywords are written in all lowercase letters

Core Language Elements(2)

�Generally, the order in which declarations can be m ade is arbitrary

� Identifiers• Start with a letter• Can contain digits and underscores• Are case sensitive



• Are case sensitive

� Comments• as free text• may appear anywhere in a TTCN-3 specification module• Nested comments are not allowed

Scoping Rules

� Six scope units• Module definition part• Control part• Component types• Functions• Alt steps• Test cases



• Test cases• “Blocks of statements and declarations”

� Each scope unit can have declarations (optional)

Basic Program Statements



�Label/goto construct can only be used in alternativ es

�{ } can not be omitted

� Expressions are only allowed for compatible types

� They are read left to right, respecting parenthesis

Expressions



� Boolean expression can only contain boolean values or boolean expressions

�There are no prefix or postfix operations (like C: i++;)

Operations ...(1)



Operations ... (2)



And their precedence ...



Operation: Bit oriented



�Bitwise operators• Operands can be of compatible type

• bitstring• hexstring• octetstring

• Operands must have the same compatible type and the same length�Shift and rotate operators

• Right hand operand must be an Integer (expression)

�Labels can be declared everywhere except as a top a lternative in a alt or interleave statement

�Label identifiers shall be unique in their scope• Example

label MyLabel;i := i +1;

Label / Goto



i := i +1;label L01;goto MyLabel;

� Goto can be used to jump forward and backward in one fun ction, but not into an alt, interleave while, for statement, e tc.

� DON’T USE IT! (“Why goto’s are considered harmful”)

�Grammar ruleif “(“ BooleanExpression “)”StatementBlockElseIfClause[ElseClause]ElseIfClause := else if “(“ BooleanExpression “)” StatementBlockElseClause := else StatementBlock

Control Flow: The if-clause



�{ } are mandatory!

�Exampleif (i>5) {x(7) ;} else if (i<5) {y(9) ;} else { return ;}

�Grammar rule• for “(“ Initial ; Final ; Step “)” StatementBlock• Initial := VarInstance / Assignment• Final := BooleanExpression• Step := Assignment

�Examplefor ( var integer i:=0; i<10; i:= i + 1) {y:=i;}

Control Flow: The for clause



}

Control Flow: The while clause�Grammar rule

while “(“ BooleanExpression “)” {StatementBlock }

�BooleanExpression will be evaluated before entering the Statement Block.�{ } are mandatory!!!� Example

while (i<10) {i := i + 1;}

� Grammar ruledo { StatementBlock } while “(“ BooleanExpression “)”

� BooleanExpression will be evaluated after execution of theStatementBlock.

� { } are mandatory!!!

Control Flow: do-while-clause



� Exampledo {i := i + 1;} while (i<10)

activate, deactivate, stop, repeat and return

Other Control transfer statements

Groups in TTCN -3

• TTCN-3 groups are a way to organize data

• Limited functionality• No scope unit• In TTCN-3 specification only importing is specified

• Group identifiers have their own scoping rules



• Group identifiers have their own scoping rules• Group identifiers can be reused

• Examplegroup G1 {group Valid {...}}group G2 {group Valid {...}}

Module Import

�Import of� Single definition

import from MyModuleC {type MyType;}� All definitions

import from MyModule all;� Groups

import from MyModule {group Valid;}� Definitions of the same kind



� Definitions of the same kindimport from MyModule {template all;}

� Definitions of the foreign languageimport from MyModule language “ASN.1:1997” all;

� Mixtureimport from MyModule {type MyType, OtherType; template all;}

� Import is by default nonrecursive� Name clashes are handled with module name prefixes

Module Parameterization

� Needed for parameterization at runtime

� Module Parameters• Several test system installations

• Different access data to SUT• Different capabilities/versions of SUT

• Do not execute irrelevant test cases• Provide data when starting test system



• Provide data when starting test system• No hardcoding into constants to avoid recompilation

• modulepar {charstring mp_nameServerHost:=

"localhost";integer mp_nameServerPort := 2000}

� External Constants•Similar concept but without default value external const integer port No;






- Expressions- Operators & their Precedence- Control Transfer Statements, Module Import, Module Parameterization



TTCN-3 Types

� Basic Types(1)• Boolean type

Boolean : true, false

• Integer type

Integer : unrestricted range

Example: -5,0,33445555

• Float type


Float : unrestricted range

Example: -5.3,0.3,0.34E-1

•Char type

Char : A single character according to ISO/IEC 646

Example: “a”,”0”

• Universal Char type

Universal Char type: A single character according to ISO/IEC 10646

Example: “a”, char(0,0,1,113)

TTCN-3 Types

� Basic Types(2)

�Octet string type

Octet string : a sequnce of octets

Example: ‘AAF09E’O,’00FF’O

�Hex string type

Hex string : a sequnce of hexdigits


Hex string : a sequnce of hexdigits

Example: ‘AAF09E’H,’0FF’H

�Bit string type

Bit string : a sequence of bits

Example: ‘1101’,’0110’

Contd…..

� (Universal) Char string type[Universal] Char string : a sequence of charsExample : ”Hello”, “Hell” & char(0,0,0,46)

� Verdict TypeVerdict Type: a type for test verdictsExample : pass, fail, inconc

� Basic Types(3)

TTCN-3 Types


Example : pass, fail, inconc

type record url {charstring protocol,charstring host,charstring file}

type set of dinosaur dinolist;

� Structured Type Definition

TTCN-3 Types


type set of dinosaur dinolist;

type record dinosaur { charstring name,integer len,integer mass optional,charstring time,charstring place}

� Relevant TTCN-3 Definitions

type set of dinosaur dinolist ;type record dinosaur {charstring name,charstring len,charstring mass ,charstring time ,charstring place}type record url {charstring protocol ,

TTCN-3 Types


charstring protocol ,charstring host ,charstring file}template url requestURL := {protocol := " http://",host := " www.tcloudtech.com ",file := " /TTCN-3_Example/dinolist.xml "}type port httpTestPortType message {out url ;in dinolist ;}

Types : record, record of, set, set of, union, enumeratedCan be nested into: record, record of, set, set of, union

type record MyRecord {

union {integer choice1,octetstring choice2

� Nested structured type definitions

TTCN-3 Types


octetstring choice2} field1,

enumerated {Rose, lotus, lilli

} field2,integer field3 (0..31)

};

const MyRecord.field1 := { choice2 := '80'O };

� Any type

TTCN-3 Types

�Models a union of all known types in a TTCN-3 module

Var anytype MyVarOne, MyVarTwo;

Var integer MyVarThree;

MyVarOne.integer :=34;

MyVarTwo:={integer :=Myvarone+1};


MyVarTwo:={integer :=Myvarone+1};

MyVarThree;=MyVarOne X 12;

�DON’T USE THIS!

� Basic and Structured types can be sub typed

TTCN-3 Types


� Sub typing : Examples

TTCN-3 Types

�Sub typing of simple types

• type integer Byte (0….255)

• type integer odd (1,3,5,7,9)

• type octet string Buffer length (2…5)


• type octet string Buffer length (2…5)

• type char string Identifier (“a”..”z”,”A”…”Z”)

�Sub typing of Structured elements

• Type record length(10) of integer MyRecord OfType

• Type record length(0….10) of charstring stringarrey length(12);

� Sub typing : Examples

TTCN-3 Types

�Type compatibility is required for assignements, comparison and instantiation

�Enumerated are only compatible to themselves strong typing)

�Basic types: the value “b” is compatible to type “A “ if


�Basic types: the value “b” is compatible to type “A “ if type “B” resolves to the same root type as type “A” and it does not violate subtyping (eg. Ranges, length restrictions) of type “A”.

Example: type integer A(0,…256);

type integer B(10……256);

Var B myB :=b:

• Timers are used to observe time progress

• Timers can be declared and used• local in control part, testcases, functions and altesteps• additionaly component wide in component type definition

• Timer values are floats, its unit are seconds

• Examples of timer declaration• timer t1 := 1.0 ; // default value one second

TTCN-3 Timers


• timer t1 := 1.0 ; // default value one second• timer t2 := 0.010 ; // default value of ten milliseconds• timer t3 := 1E-2 ; // using alt float notation

• Examples of timer operations• t1.start(5.5) ; // overriding any default value• t2.stop ;• boolean b := t1.running ;• float f := t2.read ;• t3.timeout ;






- Expressions- Operators & their Precedences- Control Transfer Statements, Module Import, Module Parameterization



Building blocks of TTCN -3 Module (1)…

� Type definition (Definition of different types used in the message)

� Templates (test data description) and matching mechanisms(pattern matching)

� Test configurations• Formally defined interfaces to the SUT• Dynamic creation of test component


• Dynamic creation of test component• Concurrency to describe distributed test setups

� Test cases• Small (complete) separate compileable programs• Share (type and data) information

� Test verdicts

Structured Definitions Part

module TcloudDnsTests{

group MessageStructure{

// Defintions of message types}


� TTCN3 Module


}group TestData{

// Templates for messages instances}group TestSystemConfiguration{

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

// Test case definitions}

}

� TTCN3 Modulemodule TcloudDnsTests{

// Test definition part

control{

// Test execution part// (optional)

Module (…)

Module Definitions



// (optional)}

}Module Control


// Message structure// Actual test data// Test configuration// Test Case definitio

}

Definitions Part

� TTCN3 Module

Module (…)

Module Definitions


// Test definition partmodulepar boolean mp_example;


Control Part



Module Control

Definitions // .. as in previous slide}

// Test execution partcontrol {if (mp_example) {

execute(TC_resolveTCLOUDWww());}

}}

Control Part

� TTCN3 Module Definition Continued..

�Module Definitions

•Type Definitions

•Templates

•Port Definitions

type record DNSQuery {

charstring hostname,

AnswerType answer optional ,

QueryType qtype

}



•Component Definitions

•Test case

•Control Part

�Module Control

type union AnswerType {

Byte address[4],

charstring hostname}

type integer Byte (0 .. 255);

type enumeration QueryType {

}A, NS, CNAME

� Module Definitions

•Type Definitions

•Templates

•Port Definitions

template DNSQuery query {

host name :=“ www.tcloudtech.com ”; answer := omit ; qtype := A;

}

� TTCN3 Module Definition Continued..




•Test case

•Control Part

�Module Control

}

template DNSQuery response modifiesquery {

answer.address := {176,136,72,81};

}

• Templates• Basic and Parameterized Templates• Modified and Inline Templates• Matching

Examples of Send Templates

• Template of basic type

�Template Details



• Template of basic typetemplate integer i := 1 ;template octetstring o := 'AABBCC'O

• Template of structured typestemplate MyRecord r := {fieldA := omit, // must be declared optionalfieldB := 1,fieldC := f(4) }template MyUnion u := {integerVariant := 4 }

Examples of Receive Templates

• Template of basic typetemplate integer i := ? ;template octet string o := 'AA??CC'Otemplate integer i := 1 ;template integer i := (1, 2, 4..5) ;

�Template Details continued



• Template of structured typestemplate MyRecord r := {

fieldA := *, // must be declared optionalfieldB := ?,fieldC := pattern “ab*z” }

template MyUnion u := {integerVariant := 2 }

• Elements that can have templates as parameters• Function• Testcase• Altstep

Parameterization of Templates




• Altstep• Template

function f2(template MyRecord r1)runs on C {p1.send(r1) ;}

Parameterization of Templates

• Parameterization with values• template MyRecord r2(integer i) := {integerField1 := i,integerField2 := i+2,charstringField := ””"Hello””"}




charstringField := ””"Hello””"}

• Parameterization with templates• To enable passing of wildcards and other matching operations

• template MyRecord r2(template SubRecord r1) := {aRecordField := r1,charstringField := ””"Hello”"" }

Modifications of Templates

• Parameterization is applicable

• Example// Giventemplate MyRecordType MyTemplate1(integer i) := {




field1 := i,field2 := "A string",field3 := true}

// then writingtemplate MyRecordType MyTemplate2(integer i)

modifies MyTemplate1 := {// field1 remains parameterizedfield2 := "A modified string"// field3 is unchanged }

Implicit (Inline) Templates

• Named templates vs. unnamed templates

• Unnamed, so called inline templates reduce amount o f template definitions

• Especially in combination with modifies




• Especially in combination with modifies

• Might enhance readability, but handle with care

• Example:template MyRecord r1 := {

fieldA1 := { fieldB1:= 2, fieldB2 := "test" },fieldA2 := 2}

Matching Operations

• Group 1: Specific Values• expression that resolves to a single value• omit

• Group 2 : Instead of Values• ? wildcard for any value• * wildcard for any value or no value at all

Building blocks of TTCN -3 Module (13)



• Group 3: Special Symbols inside values• ? wildcard for any single element of a string, array, record of, and set of• * wildcard for any number of consecutive elements of a string, array,record of, and set of

• Group 4: Unspecific Values• length: restriction on length of strings and of number of elements of array, record of, and set of• ifpresent: for matching optional field values

Basic Elements of TTCN -3 Module (1)…

�Test system configuration

type port DNSPort message {

inout DNSQuery;

// a port may send/receive messages

// of more than one type}

// Port Definition� Module Definitions

•Type Definitions

•Templates

•Test system configuration

•Port Definitions


}

type component DNSTester {

port DNSPort P;

// a component may have more than

one port}

// Component Definition

PDNSTesterDNSQuery

•Port Definitions


•Test case

� Module Control

Basic Elements of TTCN -3 (2)…

TTCN3 Module Definition Continued… Test Case

testcase Testcase1() runs on DNSTester {

P.send(query);

P.receive(response);

setverdict(pass);

stop;}


•Type Definitions

•Templates



Client

(“www.tcloudtech.com”,A)

(“www.tcloudtech.com”, 176.136.72.81 ,A)

DNS

Pass

•Port Definitions


•Test case

� Module Control

Basic Elements of TTCN -3 (3)…

TTCN3 Module Definition Continued… : Control part

�Controls the execution of the test case

control {

execute (Testcase1());


•Type Definitions

•Templates



// more test cases might follow

}


•Port Definitions


•Test case

� Module Control

�Introduction to Test Data type, Actual test data, Test Configuration,- Test component, Communication ports, Functions, Test Behavior - Control and monitor component - How TTCN-3 supports concurrent architectures- Behavior alternative

� Foreign data (ASN.1) usage in TTCN -3

Building blocks of TTCN -3 test suite


� Foreign data (ASN.1) usage in TTCN -3- Goal, Overview, ASN.1 to TTCN-3 mapping, Conventions,ASN.1/

TTCN-3 type equivalence, Open Type, Other String Types, Structured Types, ASN.1 values, Modules

Building blocks of a TTCN -3 Test Suite (1)…

Test Suite

Test Data Types

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

information elements (fields, parameters)information elements (fields, parameters)information elements (fields, parameters)information elements (fields, parameters)• Internal data structures (e.g., for computation)Internal data structures (e.g., for computation)Internal data structures (e.g., for computation)Internal data structures (e.g., for computation)• Possibly encoding or display informationPossibly encoding or display informationPossibly encoding or display informationPossibly encoding or display informationBuilt-in basic typesinteger, boolean, float,integer, boolean, float,integer, boolean, float,integer, boolean, float,bitstring, hexstring, octetstring,bitstring, hexstring, octetstring,bitstring, hexstring, octetstring,bitstring, hexstring, octetstring,


bitstring, hexstring, octetstring,bitstring, hexstring, octetstring,bitstring, hexstring, octetstring,bitstring, hexstring, octetstring,charstring, universal charstringcharstring, universal charstringcharstring, universal charstringcharstring, universal charstring... and structured typesrecord, record of, set, set ofrecord, record of, set, set ofrecord, record of, set, set ofrecord, record of, set, set ofunion, enumeratedunion, enumeratedunion, enumeratedunion, enumerated... and special types such ascomponent, port, verdict type, default, etc component, port, verdict type, default, etc component, port, verdict type, default, etc component, port, verdict type, default, etc


Test Suite

Actual Test Data

Test Data Types

Actual test data (values) used during testing• Constants or Templates for specific

message or call parameter values• Matching expressions for allowing multiple

message or call parameter values• value range, value list, wildcards,

presence, length, size, permutation


presence, length, size, permutation• regular expressions

• Using also template decomposition,parameterization and modification

Test Data Definitions• Templates define the test data• Are based on basic or structured types

• Send templates, contain only concrete values and no matching operations

• Receive templates can contain



• Receive templates can contain• Wildcards• Matching operations


Test Suite

Actual Test Data

Test Data Types

Static aspects

• Test component and port types

Dynamic aspects

• Dynamic instantiation andmanagement of test components

• Mappings of test components to


Test Configuration

Test Data • Mappings of test components toabstract test system interfaces

• Connections between testcomponent interfaces

• Management of test components

Test Suite

Actual Test Data

Test Data Types

test cases

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

• can be decomposed with functions andaltsteps

• can (re)use default behavior



Test Behaviour

Test Configuration

• can (re)use default behavior

• can use timers and timeouts

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

TTCN-3 functions define the behavior of the parallel testcomponents function root_behaviour runs on DNSTester {

alt {

[ ] P.receive (rootquery) {

P.Send(rootanswer);

setverdict (pass );

}

DNS Root NS

(“tcloudtech.com”, NS)alt

Parallel Test Component



}

[ ] P. receive { setverdict (fail );

}

}

stop ;

}

(“tcloudtech.com”, “ns.tcloudtech.com”, NS)

Pass

fail

� Test Verdicts� Type verdicttype

• 5 values: none, pass, inconc, fail, error• error: set by runtime system

� Each component maintains a verdict• Initial value: none

• setverdict ( …) to change verdict

Building blocks of a TTCN -3 Test Suite (6)...


• setverdict ( …) to change verdict• getverdict to read verdict

• Verdict cannot be improved• setverdict ( fail ) ;• setverdict ( pass) ;• getverdict; // --> fail

� Overall verdict: minimum of testcomponent verdicts

• Several components in a test configuration• Always: Main Test Component, Test System Interface

• Main Test Component• Reference: mtc• Created when test case execution starts

Building blocks of a TTCN -3 Test Suite

� Special Components


• Test system interface• Reference: system• Created when test case execution starts• Defines ports to communicate with SUT• May contain timers, etc.

• Initially: one test component, mtc and system coincide

• Later: access to timers, etc., dynamic test configurations

var DNSTester RootComp, NSComp, ClientComp;

RootComp := DNSTester. create ;

NSComp := DNSTester. create ;

ClientComp := DNSTester. create ;

map(RootComp:P, system :ROOT);

testcase Testcase3() runs on mtc

system TSI {

Building blocks of a TTCN -3 Test SuiteDynamic Configuration


map(NSComp:P, system :NS);

map(ClientComp:P, system :CLIENT)

RootComp. start (RootBehaviour());

NSComp. start (NSBehaviour());

ClientComp. start (ClientBehaviour());

ClientComp. done ;

// block until ClientComp is donestop ;

}

How TTCN-3 supports concurrent architectures?� Dynamic creation of the test configuration

- Creation of components• create

� Creation of connections between Components• map, unmap

� Creation of connections with the TSI/SUT• connect, disconnect

� Dynamic control of the component behavior



� Dynamic control of the component behavior- Control of component behavior

• start, stop, kill- Lookup of component behavior

• running, done, alive, killed

� Communication between components- Exchange of messages between components

send, receive- Implicit verdict mechanism

setverdict, getverdictnone, pass, inconc, fail, error

Testing Concept : Self-test of Test Cases� Use concurrency to perform a self-test of a test case

- All behavior is encapsulated in a function. In the normal case, this function is simply called in the MTC.



-For Self-Testing, a simulation of each of the SUT port is implemented in one or more Parallel Test Components (PTCs). They are connected to MTC ports.

- Since the Test System Interface can be left empty, SUT Adaptation is not needed for the self-test test suite.


• Everything that “pure” functions are, plus• Runs-on clause defining the component type the func tion can beexecuted only• Port parameters possible• Templates as parameters, can only be in

• Examples• Runs -on clause

Behaviour Functions


• Runs -on clausefunction f() runs on C return integer {p.send (SomeTemplate) ;return 1;}

• Template parametersfunction f(template R myRecord) runs on C {p.send (myRecord) ;}

• Use runs on to access component entities• Timers, ports, constants, variables

type component AddressBookClient {port ServerPort pt_server;const float c_maxDuration := 2.0;… ;


Functions on Components


… ;}

function f_addEntry (in Entry p_entry )runs on AddressBookClient{

pt_server. send ( … );pt_server. receive ( … ) { … };

}

function f_startup() runs on MyComp{/* A new component of type SomeComp is created, and a reference to this* component is stored into variable cp_someCompRef. */var SomeComp cp_someCompRef := SomeComp.create;/* Local port pt_control is connected with the port pt_ctrl* of the newly created component. */connect(self:pt_control, cp_someCompRef:pt_ctrl);/* Port pt_data of the newly created component is m apped* with the port tcp of the test system interface co mponent.*/


Functions on Components: Example


*/map(cp_someCompRef:pt_data, system:pt_tcp);/* Function tp_someBehaviour() is started in the co mponent,* and string "10.10.10.1" is given to it as a param eter.* .start() is a non blocking command, so the execut ion continues* immediately after the below statement.*/cp_someCompRef.start(tp_someBehaviour("10.10.10.1") );// Wait for cp_someCompRef to finish its execution.cp_someCompRef.done;// Set own verdict to pass.setverdict(pass);// Stop own execution.self.stop}

�Introduction to Test Data type, Actual test data, Test Configuration,- Test component, Communication ports, - Functions, Test Behavior - Control and monitor component - How TTCN-3 supports concurrent architectures- Behavior alternative



� Foreign data (ASN.1) usage in TTCN-3- Goal, Overview, ASN.1 to TTCN-3 mapping, Conventions,ASN.1/ TTCN-3

type equivalence, Open Type, Other String Types, Structured Types, ASN.1 values, Modules

Behavior alternative : alt statement & altstep

Alt Statement: Alt statement allows to group several block operations into a single statement.It is also possible to have an alt statement with only a single alternative.The alt statement specifies a list of receiving operations: receive, getcall, getreply, catch trigger and check, done and timeout. The "done" operation blocks the execution of calling component, until the specified other component has finished its function execution.

Altstep: In TTCN-3, altstep is similar to function in that they can have parameters, but unlike functions, they also allow the description of guard


parameters, but unlike functions, they also allow the description of guard expressions and receive and timeout operations.

Functions versus Altsteps• Two similar concepts, where are the differences?

Guideline: Use functions, whenever possible

Functions Alts teps-------------- ---------Return value No re turn valuecan't be used as default Can be used as default

queryserverPortmtc


Test Behaviorresponse


timer t_ack;serverPort.send(m_dnsQuestion (‘www.tcloudtech.com ’));t_ack.start(1.0);alt {

[]


[] serverPort.receive(mw_dnsAnswer(“ 176.136.72.81")) {

setverdict(pass);}

[] serverPort.receive { // any other messagesetverdict(fail);

}[] t_ack.timeout {

setverdict(inconc);} }

t_ack.stop;}

Events of two ports(pt_myport,pt_control) and a tim er (t_timer)// Function-local timertimer t_timer;// Function-local variablesvar MyPdu myPdu;var integer count := 0;// Start timert_timer.start(10.0);// Alt-statementalt{

Behavior alternative : Alt Statement (Example)


{// Receive maximum of maxCount PDUs that match with template a_myPdu_r[count < c_maxCount] pt_myPort.receive(a_myPdu_r) -> value myPdu{// Forward the received message via port pt_myOtherPortpt_myOtherPort.send(myPdu);setverdict(pass);count := count + 1;// Wait for next PDUrepeat;}

/* Else if we receive something else than a_myPdu_r (plain .receive matches* with everything)*/[/* Empty boolean guard is treated as true */] pt_myPort.receive{log("Received something else");setverdict(falil);// Execution continues at line “self.stop”}// Else if we receive from control port an instruction to stop[] pt_control.receive(charstring: "stop")

Behavior alternative : Alt Statement (Example contd .)


[] pt_control.receive(charstring: "stop"){log("Received control message ""stop"" via pt_contrl");// Execution continues at line “self.stop”}// Else if timer expires[] t_timer.timeout{// Execution continues at line “self.stop”}}self.stop;

Behavior alternative : Altstep (Example)

altstep alt_timeGuard ( inout timer p_t ) {[] p_t.timeout { setverdict ( fail ) }};

t_guard.start ( 30.0 );

�could be used within an alt statement in the following manner

altstep definition:


t_guard.start ( 30.0 );alt {[] pt_ticket.receive ( a_ticketA ) {t_guard.stop ;setverdict ( pass )};[] alt_timeGuard( t_guard );}

An altstep can also be activated as one of the default alternatives.

testcase Testcase1() runs on DNSTester {

P.send (query);

P.receive (answer);

setverdict(pass );

stop ;}

Client DNS

Alt statement: Revisit DNS Tester Example)

Behavior alternative


Client

(“www.tcloudtech.com”, A)


DNS

Pass

Behavior alternative : Erroneous Behavior (DNS Teste r Example)

Client DNS

• P.receive(answer) blocks until it receives a message that

matches answer .

• Any other message does not unblock the tester, which then blocks forever.

• If no message is received, the tester will also block forever.


(www.tcloudtech.com, A)

Blocked

Alt statement: Dealing with erroneous behaviour (DN S Tester)testcase Testcase2() runs on DNSTester {

timer t := 5.0;

P.send (query);

t.start ;

alt {

[ ] P.receive (answer) {

setverdict (pass );

}

Client

(www.tcloudtech.com,A)

DNS


}

[ ] P.receive { // any message

setverdict (fail );

}

[ ] t. timeout {

setverdict (inconc )

}

}

stop ; }

inconc

Non-local DNS Query

Send fully qualified hostname

Return IP-addressLocal N/W

client

Internet’s root service

Parallel Test Component 1


Tester


root service

Remote DNS


Main Test Component

Local DNS

System Under Test

Non-local DNS Query contd.

Client


DNS Root NS NS

(“tcloudtech.com”,NS)

(“tcloudtech.com”,”tcloudtech.com,NS)



Pass




� Introduction to Test Data type, Actual test data, T est Configuration- Test component, Communication ports, Functions, Test Behavior - Control and monitor component - How TTCN-3 supports concurrent architectures- Behavior alternative




� Foreign data (ASN.1) usage in TTCN -3- Goal, Overview, ASN.1 to TTCN-3 mapping, Conventions,ASN.1/ TTCN-3


Foreign data (ASN.1) usage in TTCN -3

Integration of ASN.1 into TTCN -3

� Two approaches• Direct: import ASN.1 modules• Indirect: Convert ASN.1 to TTCN-3, import TTCN-3• Same definitions are available

• m1.asn1:


• m1.asn1:module m1 ....

• t.ttcn3:module t {

import from m1 language "ASN.1:1997" all;}

Overview

• ASN.1 to TTCN-3 mapping

• Simple types and constants

• Single Module



• Single Module

• Single Interface


ASN.1 to TTCN -3 Mapping

� Given an ASN.1 module, how can the definitions be used in

�TTCN-3 test cases?

�ASN.1: Abstract Syntax Notation One (ITU -T X.680)


�ASN.1: Abstract Syntax Notation One (ITU -T X.680)

�Types, constants� Modules� No behavioral interface

�Mapping to TTCN-3

�Straight forward one-to-one mapping


�Referencing to ASN.1 modules by standardized langua ge tags

�"ASN.1:1997" for ASN.1 version 1997,� "ASN.1:1994" for ASN.1 version 1994,� "ASN.1:1988" for Blue Book version of ASN.1

Conventions


�Different preprocessing steps

�Replace all “-” with “_”

�TTCN-3 keywords

�Strictly: ASN.1 definitions using TTCN-3 keywords cannot be converted�Solution: append ‘_’ to used keywords


ASN.1 / TTCN-3 Type Equivalence



OPEN TYPE / NULL

�ASN.1: OPEN TYPE

� TTCN-3: anytype� Union over types known in a module� ‘known’: defined, imported


�ASN.1: NULL

�TTCN-3: enumerated

�• type enumerated <identifier> { NULL }�• <identifier>: ASN.1 Type reference

Foreign data (ASN.1) usage in TTCN -3Other String Types

• BMPString -> universal charstring( char ( 0,0,0,0 ) .. char ( 0,0,255,255) )

• UTF8String -> universal charstring

• NumericString -> constrained charstring


• NumericString -> constrained charstring

• PrintableString -> constrained charstring

• TeletexString, T61String -> constrained universal charstring

• VideotexString -> constrained universal charstring

• GraphicString -> universal charstring

• GeneralString -> universal charstring


Structured Types

� SEQUENCE -> record

� SEQUENCE OF -> record of• Including length restrictions

� SET -> set


� SET -> set

� SET OF -> set of• Including length restrictions

� CHOICE -> union

� ENUMERATED -> enumerated


• One-to-one transformationmyValue MyMessageType ::= {

field1 "A string",field2 123,

field3 {field31 '11011'B,field32 456789,

ASN.1 Values


field32 456789,field33 'FF'O},

field4 {true, false}}

• Missing optional fields are equivalent to omitted f ields in TTCN-3


� Introduction to Test Data type, Actual test data, T est Configuration- Test component, Communication ports, Functions, Test Behavior - Control and monitor component - How TTCN-3 supports concurrent architectures- Behavior alternative



� Foreign data (ASN.1) usage in TTCN -3- Goal, Overview, ASN.1 to TTCN-3 mapping, Conventions,ASN.1/ TTCN-3


� Tool Providers• Testing Technologies• Elvior• Telelogic

TTCN-3 tool providers


• Telelogic• Danet• DaVinci Communications• Strategic Test Solutions• Open TTCN

The TTCN-3 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)


�ES 201 873-4 (Z.143)TTCN-3 Operational Semantics

�ES 201 873-5TTCN-3 Runtime Interface (TRI)

� ES 201 873-6TTCN-3 Control Interfaces (TCI)

�ES 201 873-7 and onwards (under development)Using ASN.1, XML, IDL, C/C++ with TTCN-3

ttcn3 basics

Documents

control transfer

basic programming

parallel testing

concurrent

core language

parallel testing

test case

3 core language