TTCN
Download
1 / 116

TTCN - PowerPoint PPT Presentation


  • 485 Views
  • Updated On :

TTCN. TTCN: Testing and Test Control Notation Original meaning: Tree and Tabular Combined Notation Original purpose: Specification of abstract test suites for conformance testing of International Telecommunications Union protocols.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'TTCN' - Roberta


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Slide1 l.jpg
TTCN

  • TTCN: Testing and Test Control Notation

    • Original meaning: Tree and Tabular Combined Notation

  • Original purpose: Specification of abstract test suites for conformance testing of International Telecommunications Union protocols.

  • Now promoted as a general purpose test language for distributed / communicating systems.

  • Goal: Provide a complete, internationally standardized, specification for test case behaviour and execution that is repeatable in any test lab.

    • Predictable execution requires very precise semantic definitions.


History 1 l.jpg
History (1)

  • Initial discussions on a standardized test language as part of a conformance test framework for communications protocols started in 1984.

  • In 1994, the first version of the conformance test framework standard, ISO-9646, was published.

    • TTCN-1 eventually was part 3 of this standard, published in 1995.

    • Language assumed that the entire protocol testing methodology was being used.

  • In 1997, TTCN-2 was issued.

    • Most used in Europe; only limited use in North America.


Ttcn 2 l.jpg
TTCN-2

  • “Tree and Tabular Combined Notation”

    • Tables describe data formats, signal specifications, etc.

    • Trees used to describe test case behaviour

      • Execution starts at the root of the tree

      • Tree branches represent alternative execution paths.

        • Implication: no loops

        • Alternatives explicitly specified for valid and invalid behaviour.


Implementation of ttcn tests l.jpg
Implementation of TTCN Tests

  • TTCN describes abstract tests that are completely platform independent

  • The TTCN standard also provides operational semantics, which describe the exact execution behaviour of a test case

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

    • TTCN primitives are mapped to actual test environment.

    • Implementations must obey the operational semantics


Ttcn 2 tables l.jpg
TTCN-2 Tables

  • Example: an “abstract service primitive type” definition:


Ttcn 2 tables6 l.jpg
TTCN-2 Tables

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


Ttcn 2 trees l.jpg
TTCN-2: Trees

expected forward progress in time

alternatives




Ttcn 2 signal declarations l.jpg
TTCN-2 Signal Declarations

message

data format


Ttcn 2 table declarations l.jpg
TTCN-2: Table declarations

constraints

expected

message

data



Implementing ttcn 2 tests l.jpg
Implementing TTCN-2 tests

user interface

compiled

TTCN

test case

timer

management

executor

decoder

encoder

form

extract

manually-

written code

operating

system service

PCO queues

send/receive events

test equipment-

specific

to system under test


Implementing ttcn 2 tests14 l.jpg
Implementing TTCN-2 tests

user interface

compiled

TTCN

test case

timer

management

executor

decoder

encoder

! A

? B

form

extract

011001….

110010….

PCO queues

send/receive events

to system under test


History 2 l.jpg
History (2)

  • Discussions after TTCN-2 centred on making the language more flexible and “user-friendly”.

    • Standardization taken over by ETSI, the European Telecommunications Standards Institute.

  • First version of TTCN-3 issued in 2001

    • Radical change from the previous version


Credits l.jpg
Credits

  • Much of the following has been adapted from:

    • “TTCN-3: An Introductory Overview”

      • Anthony Wiles, ETSI

      • Conference presentation at TestCom

    • “About TTCN-3”

      • Tutorial available at www.etsi.org


What is ttcn 3 l.jpg
What is TTCN-3?

  • Testing and Test Control Notation Version 3

  • Internationally standardized testing language

    • Product of the European Telecommunications Standards Institute (ETSI)

    • A programming language that has been used for more than 15 years in standardization as well as industry

    • Specifically designed for black box testing and certification

    • Constantly developed and maintained at ETSI by a team of leading testing experts from industry, institutes, and academia

  • A testing technology that applies to a variety of application domains and types of testing

    • Proven to work in very large and complex industrial tests, e.g., 3G network elements


Ttcn 3 standards l.jpg
TTCN-3 Standards

  • Standards from ETSI [some cross-listed as ITU standards]

    • ES 201 873-1 (Z.140): TTCN-3 Core Language

    • ES 201 873-2 (Z.141): TTCN-3 Tabular Presentation Format (TFT)

    • ES 201 873-3 (Z.142): TTCN-3 Graphical Presentation Format (GFT)

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

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

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

    • ES 201 873-7: Using ASN.1 with TTCN-3

    • ES 201 873-8: The IDL to TTCN-3 Mapping

  • Proposed: Mappings to XML, C++

  • Currently: Edition 3 of TTCN-3 (2007/8)


What makes ttcn 3 different l.jpg
What makes TTCN-3 different …

  • From conventional programming or scripting languages?

    • Rich type system including native list types and support for subtyping

    • Embodies powerful build-in matching mechanism

    • Snapshot semantics, i.e., well defined handling of port and timeout queues during their access

    • Concept of verdicts and a verdict resolution mechanism

    • Support for specification of concurrent test behaviour

    • Support for timers

    • Allows test configuration at run-time

    • Tests focus only on implementation to be tested


What makes ttcn 3 different20 l.jpg
What makes TTCN-3 different …

  • From a test tool or vendor proprietary testing language?

    • Not tied to a particular application or its interface(s)

    • Not tied to any specific test execution environment, compiler or operation system

    • TTCN-3 as such is not executable and requires a compiler/interpreter, adapter as well as codec implementations


Ttcn 3 test systems in a nutshell l.jpg

(s + s)

( )

TTCN-3 test systems in a nutshell

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

  • TRI and TCI standards define test system architecture

    • TTCN- 3 tools are required to support internal interfaces

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

  • A test system requires

    • A TTCN-3 tool = TTCN-3 compiler and execution environment

    • A test platform for a specific device under test

    • Note: Tools come with default Test Control & Logging

Test System Executor

TTCN-3 Test System

Test Control

Logging

Codecs

TCI

[compiled]

TTCN-3 Executable

TRI

SUT Adapter

Platform Adapter

System Under Test (SUT)

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


An example adaptation a ipv6 test system l.jpg
An example adaptation: A IPv6 test system

Test System Executor

TTCN-3 Test System

ToolLogging

ParameterFile

IPv6 Codecs

TCI

[compiled]

IPv6 ATS

TTCN-3 Executable

TRI

Ethernet Adapter

Real-time Adapter

Open Source FreeBSD Router


Minimal test configuration l.jpg
Minimal Test Configuration

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

TTCN-3 Test System

TCI

Test Control

TTCN-3 Executable

Logging

MTC

Communication with IUT

Codecs

TRI

SUT Adapter

Platform Adapter

Communication with SUT

System Under Test (SUT)

Communication with IUT

Implementation Under Test


Example concurrent test configuration l.jpg
Example Concurrent Test Configuration

  • A test involves execution of many parallel test components

  • Dynamic instantiation of components and communication links

TTCN-3 Test System

TCI

Test Control

TTCN-3 Executable

MTC

Logging

InternalCommunication

PTC

PTC

Codecs

TRI

SUT Adapter

Platform Adapter

System Under Test (SUT)

Implementation Under Test



Main capabilities of ttcn 3 l.jpg
Main Capabilities of TTCN-3

  • Dynamic concurrent testing configurations

  • Various communication mechanisms (synch and asynch)

  • Data and signature templates with powerful matching mechanisms

  • Specification of encoding information

  • Display and user-defined attributes

  • Test suite parameterization

  • Test case controland selection mechanisms

  • Assignment and handling of test verdicts

  • Harmonized with ASN.1 and IDL (XML and C++ coming)

  • Different presentation formats

  • Well-defined syntax, static semantics and operational semantics


The core language and other presentation formats l.jpg

Text format

Tabular Format

Graphical Format

PresentationFormat3

PresentationFormatn

The Core Languageand Other Presentation Formats

  • Core format is text based (most popular)

  • TTCN-3 can be edited or viewed in other formats

    • Tabular format (for TTCN-2 people)

    • Graphical format (good for visual overview)

    • Other standardized formats in the future?

    • Proprietary formats possible

TTCN-3 Core Language


Example core text format l.jpg
Example Core (Text) Format

testcase TC_resolveEtsiWww() runson DnsClient

{

timer t_ack;

serverPort.send(m_dnsQuestion("www.etsi.org"));

t_ack.start(1.0);

alt {

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

}

[] serverPort.receive { // any other message

setverdict(fail);

}

[] t_ack.timeout {

setverdict(inconc);

}

} t_ack.stop;

}


Example graphical format l.jpg
Example Graphical Format

testcase TC_resolveEtsiWww() runson DnsClient

mtc

serverPort

DnsClient

DnsPort

timer t_ack

m_dnsQuestion("www.etsi.org")

t_ack

alt

mw_dnsAnswer("172.26.1.17")

pass

?

fail

t_ack

inconc

t_ack



Use of ttcn 3 with other languages l.jpg

ASN.1 Types & Values

IDL Types & Values

XML Types & Values

Other types & Valuesn

Use of TTCN-3 With Other Languages

  • TTCN can be integrated with types systems of other languages

  • Fully harmonized with ASN.1

  • Harmonized with other languages

    • IDL, XML, C/C++

TTCN-3 Core Language


Major elements of ttcn 3 l.jpg

Test System Architecture

Test Data

Data Types

Test Behaviour

Major Elements of TTCN-3

  • Built-in and user-defined generic data types (e.g., to define messages, service primitives, information elements, PDUs)

  • Actual test data transmitted/received during testing

  • Definition of the components and communication ports that are used to build various testing configurations

  • Specification of the dynamic test system behaviour

TTCN-3 Core



Ttcn 3 modules l.jpg

Module Definitions

Module Control

Attributes

TTCN-3 Modules

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

  • A test suite is a module

  • A module has a definitions part and a control part

  • Modules can be parameterized

  • Modules can import definitions from other modules

  • Modules can have attributes

Module (…)


Example of module structure l.jpg
Example of Module Structure

module MyModule (integer MyTSPar1)

{

: // Definitions part

control

{

: // Control part

}

}

with display″ETSI format″;


Module definitions l.jpg

RP Signatures

Data Types

Data Templates

Constants

Communication Ports

Test Components

Functions

Named Alternatives

Test Cases

Module Definitions

  • Definitions are global to the entire module

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

  • Templates and Signatures define the test data

  • Ports and Components are used in Test Configurations

  • Functions, Named Alts and Test Cases define behaviour

Signature Templates


Importing definitions l.jpg
Importing Definitions

// Importing single definitions

import template MyTemplate from MyModule;

// Importing definitions of the same kind

import all template from MyModule;

// Importing all definitions

import all from MyModule;

// inhibiting recursive import

import template MyTemplate from MyModule nonrecursive;

/* To avoid name clashes the imported definition is prefixed with the identifier of the source module */


External definitions l.jpg
External Definitions

// External constants may be defined

external const integer MyExternalConst;

// External functions may be defined

external function MyFunction4() return integer;


Groups of definitions l.jpg
Groups of Definitions

// A nested group of function definitions

group MyTestStepLibrary

{ group MyGroup1

{ function MyTestStep11 { … }

:

function MyTestStep1n { … }

}

group MyGroup2

{ function MyTestStep21 { … }

:

function MyTestStep2n { … }

}

}




Example of integer type l.jpg
Example of Integer Type

/* integer sub-type RANGE definition */

type integer MyIntegerRange (1 .. 100)

type integer MyIntegerRange (0 .. infinity)

/* integer sub-type LIST definition */

type integer MyIntegerList (1 , 2, 3, 4)

/* integer sub-type as a mixed LIST and RANGE */

type integer MyIntegerListAndRange (1 ..5, 7, 9)


Example of a structured type l.jpg
Example of a Structured Type

// record type definition

type record MyMessageType

{ integer field1 optional,

boolean field2

}

// record value notation

var MyMessageType MyMessage

{ field1 1,

field2 true

}

// Individual field assignment

MyMessage.field2 := false


Arrays l.jpg
Arrays

/* Arrays are not considered to be types in TTCN-3. Instead, they are specified at the point of variable declaration */

// integer array of 5 elements

varinteger MyArray[5];

// indexing starts at zero

MyArray[0]:= 1;

// An initialiser may be used to set array values

MyArray := {1,2,3,4,5};



Uses of data in ttcn 3 test specifications l.jpg
Uses of Data in TTCN-3 Test Specifications

  • Data in TTCN-3 is used

    • internally to the test component

    • as information passed between test components within the test system

    • as test data transmitted to and received from the System Under Test (SUT)

  • The grouping mechanism can be used to collect data definitions of a similar ‘kind’ e.g.,

    • Service Primitives (ASP)

    • Protocol Data Units (PDU)

    • internal coordination messages


Constants and variables l.jpg
Constants (and Variables)

/* Constants are defined in the definitions part of a module (and inside functions and test components) */

constant integer MyConstant := 1;

/* Variables can only be declared in the module control part (and inside functions and test components) TTCN-3 does not support global variables*/

var hexstring MyHexString;


Example message definition l.jpg
Example Message Definition

// Complex messages can be defined by records

type recordMyMessageType MyMessage :=

{

field1 integeroptional,

field2 integer,

field3 integer,

field4 integer,

field5 booleanoptional,

field6 hexstringoptional,

field7 AnotherMessageType,

field8 bitstring,

field9 charstring (1 .. 20)

}


Data templates l.jpg
Data Templates

  • Templates are special data values that have the following characteristics

    • matching mechanisms

    • they can be parameterized

    • they can be modified to provide a simple form of inheritance

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

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



Examples of simple templates l.jpg
Examples of Simple Templates

/* Template for a simple integer type */

template integer MyData1 := *;

template integer MyData2 := (1, 2, 3);

/* This line in a test behaviour description will match any incoming integer value */

P1.receive(MyData1);

/* This line will match on one of the incoming integer values 1, 2 or 3 */

P1.receive(MyData2);


Example message template l.jpg
Example Message Template

templateMyMessageType MyMessage :=

{

field1 1 ifpresent,

field2 (1, 2, 3),

field3 (0 .. 255),

field4 not (1, 2, 3),

field5 omit,

field6 * ifpresent,

field7 ?,

field8 ′1011?110*1′B,

field9 ″abc″ <*> ″xyz″length (20)

}


Parameterized templates 1 l.jpg
Parameterized Templates (1)

// Value parameterization

templateMyMessageType MyMessage (integer MyPar) :=

{

field1 MyPar,

field2 true

field3 ‘110011’B

}

// Example use of this template

P1.send(MyMessage(1));


Parameterized templates 2 l.jpg
Parameterized Templates (2)

// Type parameterization

type record MyRecordType(MyMetaType)

{

boolean field1,

MyMetaType field2 // field2 type not defined

}

var MyRecordType(integer) MyRecordValue :=

{

field1 := true,

field2 := 123 // field2 now of type integer

}


Modified templates l.jpg
Modified Templates

// Writing

templateMyMessageType MyMessage1

{ field1 123,

field2 true

}

// and

template MyMessageType MyMessage2 modifies MyMessage1

{ field2 false

}

// Is the same as writing

templateMyMessageType MyMessage3

{ field1 123,

field2 false

}


Local function definitions l.jpg
Local Function Definitions

/* Functions can declare local constants, variables and timers */

functionMyFunction

{

const hexstring MyConst := ′FF00′H;

var integer MyVar :=1;

timerMyTimer;

:

}


Procedure signatures l.jpg
Procedure Signatures

/* Procedure signatures are needed for synchronous communication over procedure-based ports (remote procedure calls) */

signatureMyRemoteProc

( in integerPar1,

out float Par2,

inout integer Par3

)

return integer

exception (ExceptType1, ExceptType2);


Signature templates l.jpg
Signature Templates

signatureMyRemoteProc

( in integer Par1,

out float Par2,

inout integer Par3

)

return integer

exception (ExceptType1, ExceptType2);

/* templates may be used to define the actual parameters to a remote procedure call */

templateMyRemoteProc Mytemplate :=

{

Par1 := 7,

Par2 := *,

Par3 := MyConst

}



Test components l.jpg

Local Declarations

Ports Used

Test Components

  • Test components are the entities on which test behaviour is executed (in parallel)

  • Declarations may be made locally in the component

  • A list of the ports used by the component must also be given

  • Actual configurations are built dynamically in the test behaviour using operations such as create, connect etc.

Test Component


Kinds of test components l.jpg

MTC1

PTC1

PTCn

PTC2

Abstract Test System Interface

Kinds of Test Components

  • There are three ‘kinds’ of component

    • MTC (Main Test Component)

    • PTC (Parallel Test Component)

    • a PTC that defines the Abstract Test System Interface

Abstract Test System

Real test system connected to an SUT


Communication ports l.jpg

P1 (out)

P1 (in)

P1.send(Msg)

P1.receive(Msg)

Communication Ports

  • Test components communicate via communication ports

  • A test port is modeled as an infinite FIFO queue

  • Ports have direction (in, out, inout)

  • There are three types of port

    • message-based, procedure-based or mixed

PTC1

PTC2


Example port definition l.jpg
Example Port Definition

// Definition of a message-based port

type port MyMessagePortType message

{

in MsgType1, MsgType2;

out MsgType3;

inout integer

}

// Definition of a procedure-based port

type port MyProcedurePortType procedure

{

out ProcedureSignature1, ProcedureSignature2

}


Example component definition l.jpg
Example Component Definition

// Definition of test component type

type component MyComponentType

{ // Local declarations

var integer MyVar;

timerMyTimer;

// Ports used by the component

MyMessagePortTypeP1, P2;

MyProcedurePortTypeP3

}


Test system interface l.jpg
Test System Interface

/* A user-defined component that defines the port interface to the underlying real test system */

type component MyTestSystemIntefaceType

{

MyLowerPCOTypeLT;

MyUpperPCOTypeUT

}



Ttcn 3 functions l.jpg

Local Declarations

Program Part

TTCN-3 Functions

  • Functions are the building-blocks of test system behaviour

  • Functions have local declarations and a program part

  • Can be a 'pure' function doing some internal test system task or specify test behaviour using communication operations such as send and receive

  • External functions are allowed

  • There are some pre-defined functions (type conversion etc.)

Function ( . . . )



Function definitions 1 l.jpg
Function Definitions(1)

// Functions can be parameterised

// in, out, inout paramters. Default is in

functionMyFunction (in integer MyPar)

{

:

}

// Functions can return values

// Default is void

functionMyFunctionreturn integer

{

:

}


Function definitions 2 l.jpg
Function Definitions(2)

/* This function performs a generic task. It does not use any communication operations */

functionMyFunction

{

:

}

/* This function uses communication operations consistent with the ports offered by MyPTC */

functionMyFunctionruns onMyPTC

{

:

}


Test case definitions l.jpg

Interface Part

System Part

Behaviour Part

Test Case Definitions

  • Test cases are a special kind of function executed in the control part of a module

  • The interface part (runs on) references the MTC on which the test case will run

  • The system part (system) references the test system interface component. Can be omitted if the test case only consists of an MTC

  • The Behaviour part defines test case behaviour

Test Case ( . . . )


Example test case definitions l.jpg
Example Test Case Definitions

// Parallel configuration

testcaseMyTestCase()

runs on MyMTCType

system MyTestSystemType

{

: // behaviour defined here

}

// Configuration consists only of an MTC

testcaseMyTestCase()runs on MyMTCType

{

: // behaviour defined here

}





Example program statement l.jpg
Example Program Statement

functionMyFunction

{

varinteger x, j;

for (j:=1; j<=10; j:=j+1)

{ if (MyGlobalFlag == true)

{ x:=j*2;

log int2str(x);

}

else x := j*3

}

}







Creating components l.jpg
Creating Components

  • The master test component (MTC) is the only component that is automatically created when the test case is executed

    • All parallel test components (PTCs) must be created explicitly using the create operation

  • The create operation returns the unique component reference for the newly created component

  • Components can be created at any point in a behaviour description


Example of create l.jpg
Example of Create

// Define a variable of type component

type component MyComponentType

{

:

}

// Define a variable of type component

var MyComponentType MyComponent;

// create the component

MyComponent := MycomponentType.create


Connecting and mapping components l.jpg

ConnectedPorts

INOUT

P1

P1

OUT IN

P2

OUT

IN

MappedPorts

PCO

OUT

IN

SUT

Connecting and Mapping Components

Test System

MyPTC

MyMTC

Abstract Test System Interface

Real Test System Interface


Example of connect and map l.jpg
Example of Connect and Map

/* The connect operation is used to connect components within the test system */

connect(MyPTC:P1, mtc:P1)

/* The map operation is used to ‘connect’ components to the abstract test system interface */

map(MyPTC:P2, system:PCO)



Asynchronous communication l.jpg

MTC

PTC

send

receive

non-blocking

blocking

Asynchronous Communication



Examples of asynchronous communication operations l.jpg
Examples of Asynchronous Communication Operations

MyPort.send(integer:5);

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

MyPort.receive(A<B) from MyPartner;

MyPort.receive(MyType:*) -> value MyVar;

MyPort.receive(integer:5) -> sender MyPeer;


Synchronous communication l.jpg

MTC

PTC

call

getcall

reply orraiseexception

getreply orcatchexception

blocking

blocking

Synchronous Communication



Examples of synchronous communication operations l.jpg
Examples of Synchronous Communication Operations

// Calling a remote procedure

MyPort.call (MyProc, 30ms) to MyPeer

{

[] MyPort.getreply(MyProc)->valueMyResult;

[] MyPort.catch (MyProc, Exception1)

}

// Replying to a remote procedure

MyPort.reply (MyProc)




Behaviour statements95 l.jpg
Behaviour Statements

// Sequential statements are denoted by a semi-colon

function MyFunction1

{

MyFunction2;

x:=x+1;

MyPort.receive(myMessage); // Blocks execution until message received

MyPort.send(MyMessage)

}


Alternative behaviour l.jpg

S1

S2

S3

S4

S5

S6

S7

S8

S9

S10

Alternative Behaviour

  • Alternative behaviour is defined using the altstatement

  • altstatements may only be the receiving communication operations and timer events

    • receive, trigger, getcall, getreply, catch, check, timeout

S1;

alt {[ ] S3; S6;

[ ] S2;

alt { [ ] S4; S7;

[ ] S5; S8;

alt { [ ] S9;

[ ] S10;

}

}

}


Schematic view of alternatives l.jpg

actions1

guard2

event2

actions2

guardn

eventn

actionsn

Schematic View of Alternatives

  • Each alternative consists of

    • a guard (possibly empty)

    • an event, and

    • an (optional) sequence of actions (including further alts)

  • The TTCN-2 concept of snapshot semantics still applies

alt

guard1

event1


Example alt statement l.jpg
Example Alt Statement

alt

{

[] MyPort.receive(MyMessage1)

{

MyPort.send(MyMessage4)

alt

{ // Next level

}

}

[x>1] MyPort.receive(MyMessage2);

[x<1] MyPort.receive(MyMessage3)

}


Named alternatives l.jpg
Named Alternatives

  • Named alternatives (named alt) are descriptions of partial alternatives

    • defined in the module definitions

    • are named and may be parameterised

  • Named alternatives are macro-expansions

    • they are not functions

  • Can be referenced from anywhere that it is legal to write a normal alt statement

  • The expand statement allows a named alt to be explicitly expanded inside another set of alternatives


Example of named alt 1 l.jpg
Example of Named Alt (1)

// Definition in module definitions

named alt MyNamedAlt

{ [] L1.receive(MyMessage1)

[] L1.receive(MyMessage2)

}

// Use of the named alt

testcase TC101()

{ MyNamedAlt() // In-line reference in test case

alt

{ [] L1.receive(MyMessage3);

[expand] MyNamedAlt(); // Macro expansion here

}

}


Example of named alt 2 l.jpg
Example of Named Alt (2)

// Is the same as

testcase TC101()

{ alt

{ [] L1.receive(MyMessage1)

[] L1.receive(MyMessage2)

}

alt

{ [] L1.receive(MyMessage3)

[] L1.receive(MyMessage1)

[] L1.receive(MyMessage2)

}

}


Default behaviour l.jpg
Default Behaviour

  • Default behaviour is defined using named alternatives

  • Defaults must be explicitly activated and deactivated

  • The expansion of defaults is applied to the end of the top-level set of alternatives in an alt statement …

  • … and to all single receiving operations and timeouts

// Note that the single statement

L1.receive(MyMessage1);

// is equivalent to

alt { [] L1.receive(MyMessage1)}


Activate and deactivate l.jpg
Activate and Deactivate

named alt MyDefault

{ [] L1.any.receive

}

// Use of the named alt

testcase TC101()

{ :

activate (MyDefault)

: // Default applies from here

deactivate (MyDefault)

: // Default does not apply from here

}


Interleaved behaviour l.jpg
Interleaved Behaviour

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

interleave {

[] PCO1.receive(MyMessageOne);

[] PCO1.receive(MyMessageTwo);

[] PCO1.receive(MyMessageThree);

}




Verdicts l.jpg

V

V

V

V

V

V

verdict.set(fail)

verdict.set(pass)

verdict.set(inconc)

Verdicts

  • Verdicts: pass, fail, inconc, none, error

  • Each test component has its own local verdict

    • can be written (set) and read (get)

  • Global verdict returned by Test Case (read-only)

Verdict returned by the test case when it terminates

MTC

PTC1

PTC2


Timer operations l.jpg
Timer Operations

// Starting, stopping and reading a timer

MyTimer.start(20E-3)// Default unit is seconds

MyTimer.stop

MyVar := MyTimer.read

// Check if a timer is running

if (MyTimer.running) { … }

// timeout in an alternative

:

[] MyTimer.timeout

:



Module control l.jpg

Local Control Declarations

Test Case Execution

Module Control

  • Module control is the ‘dynamic’ part of a TTCN-3 specification where test cases are executed (execute)

  • Local declarations, such as variables and timers may be made in the control part

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

Control


Local control declarations l.jpg
Local Control Declarations

:

control

{

consthexstring MyConst := ‘FF00’H;

varinteger MyVar :=1;

timer MyTimer;

:

}

:


Executing test cases l.jpg
Executing Test Cases

module MyModule

{ // Test cases are defined in the module definitions

testcase MyTestCase() runs on MyMTC system MyTestSystem

{

// behaviour defined here

}

control

{ // and executed in the control part

execute (MyTestCase())

}

}


Controlling test cases l.jpg
Controlling Test Cases

// Test Cases return verdicts

execute(MyTestCase()) -> value MyVerdict;

// Timeouts may be placed on Test Cases

execute(MyTestCase(),0.5) -> value MyVerdict;

// Test Cases can be used with program statements

while (x<10)

{ x:=x+1;

execute(MyTestCase())

}

// Selection of Test Cases

if (MySelectionExpression) execute(MyTestCase())



Defining attributes l.jpg

Attributes

Defining Attributes

  • Special attributes can be associated with most TTCN-3 language elements using the with statement

  • encoding information (encode)

    • standardized: ASN.1

    • application specific, proprietary

  • display information (display)

    • standardized: tabular and MSC formats

    • or proprietary

  • user-defined (extension)

    • proprietary

Language Element


Example attributes l.jpg
Example Attributes

type record MyPDU

{

integer field1,

ia5string field2,

boolean field3

}

with

{

display″ETSI Tabular := PDU”; // Tabular PDU

encode ″BER″; // Encoding directive

extension″MyRule″// User specific

}


ad