thettcn-3 language - etsi · pdf filethettcn-3 language introduction to ttcn-3 motivation

1

The TTCN-3 LanguageIntroduction to TTCN-3

Motivation

2Testing Technologies 2006 / All Rights Reserved / Confidential Information / www.testingtech.de©

„ ... the national annual cost estimates of an inadequateinfrastructure for software testing are estimated to be $59.5 billion.The potential cost reductionfrom feasible infrastructureimprovements is $22.2 billion.“

The Economic Impacts of Inadequate Infrastructure for Software Testing

Study by NIST, May 2002

How Much Does Testing Cost?

2


Testing Today

IsImportant

Expensive

Time critical

ButOnly rarely practiced

Unsystematic

Performed by hand

Error-prone

Uncool („If you are a bad programmer you might be a tester.“)

Destructive


TCL

Why Using TTCN-3 (1)

Speed to Market

HighIntegration

HighReliability

LawChanges

Optimal Cost

Complexity

WLANUMTS

IP

MISMATCH

Requir

em

ents

Test M

eth

ods

Java

C

3


TCL

Why Using TTCN-3 (2)

Speed to Market

HighIntegration

HighReliability

LawChanges

Optimal Cost

Complexity

WLANUMTS

IP

MATCH

Requir

em

ents

Test M

eth

ods

High Quality

JavaTCL

C

Java

C

TTCN-3


Testing is

a technical process,

performed by experimenting with a software product,

in a controlled environment,

following a specified procedure,

with the intent of observing one or more characteristicsof the product

by demonstrating the deviation of the product’s actualstatus from the required status / specification.

4


Testing Today‘s Systems

Component-based

Test-components to respect the SUT structure

Distributed

Not only local, but also distributed test setups

Dynamic in terms of behavior and configuration

Testing of static and dynamic aspects; dynamic creation of test components

Use various type systems to exchange data

Open to all type systems

Service is essential

Concentration on service-oriented black-box testing


Design Principles of TTCN-3

One test technology for different tests

Distributed, platform-independent testing

Integrated graphical test development, -documentation and -analysis

Adaptable, open test environment

One test technology for distributed IT and Telco systems

5


History (1)

TTCN (1992)Published as an ISO standard

Tree and Tabular Combined Notation

Used for protocol testing (GSM, N-ISDN, B-ISDN)

TTCN-2/2++ (1997)Concurrent tests

Modularization

Manipulate external data

Rather for conformance testing

TTCN-2

TTCN-2++

1997

1984

1994

1992

TTCN


History (2)

2000

1998

2006

�

TTCN-3 (2000), Upcoming v3Testing and Test Control Notation

ETSI STFs

Proper language (well defined syntax and semantics)

Enhanced communication, configuration and control

Standard test specification(SIP, SCTP, HiperLan, HiperAccess, IPv6 etc., WiMAX, IMS UE Testing)

TTCN-3: Change requests,Extension proposals

6

The TTCN-3 LanguageIntroduction to TTCN-3

Basic Concepts


What is TTCN-3?

Test and Testing Control Notation

Internationally standardized testing language for formally defining test scenarios. Designed purely for testing

Taking the best bits of TTCN-2 and combining them with a new more powerful textual notation

testcase Hello_Bob () {

p.send(“How do you do?“);

alt {

[]p.receive(“Fine!“);

{setverdict( pass )};

[else]

{setverdict( inconc )} //Bob asleep!

}}

7


TTCN-3 Execution

SUT

Bob

Tester

TTCN-3

API / Network

API / Communication

testcase Hello_Bob () {p.send(“How do you do?“);

alt {[]p.receive(“Fine!“);

{setverdict( pass )};[else]

{setverdict( inconc )} //Bob asleep!}

}


Application Areas

New application areas

Software testing

Text-based protocols …

Additional communication paradigm

Message-based communication

Procedure-based communication

Different kinds of testing

Functional testing

Conformance testing

Scalability testing …

Covering larger range within development cycle

From unit to integration testing

8


Main Aspects of TTCN-3

Triple C

Configuration: Dynamic concurrent test configurationswith test components

Communication: Various communication mechanisms(synchronous and asynchronous)

Control: Test case execution and selection mechanisms

Features

Well-defined syntax, static and operational semantics

Different presentation formats

Module concept

Extendibility via attributes, external function, external data

Harmonized with ASN.1


Differences TTCN-2 / TTCN-3

Configuration:Static configuration with configuration tables

Dynamic configuration with arbitrary amount of components

Differentiation between PCOs and CPs

One port concept

Communication:Asynchronous communication only

Abstract Service Primitives Protocol Data Unit

Procedure and message based communicationProceduresMessages

Control:Static selection of test cases via selection expression

Complete high level control flow mechanisms

9


Differences TTCN-2 / TTCN-3

ExternalisationTest suite operationsExternal functionPICS / PIXITModule parameters

Data types, valuesTTCN-2 / ASN.1TTCN-3, ASN.1, IDL, XML, ...

ModularisationPossible but seldom usedCentral concept

ExtensibilityNot possibleAttributes, languages

MethodologyConformance Testing MethodologyFramework (CTMF) (ISO 9646)No specific

PresentationTabular, machine processableTextual, graphical, tabular, ...

ImplementationNo runtime interfaces

TTCN-3 Runtime Interfaces, TTCN-3 Control Interfaces

AcronymTree and Tabular Combined NotationTest and Testing Control Notation


TTCN-3

TTCN-3

Metamodel

ASN.1 Types

& Values

IDL

Types

Other Types& Values n

Tabular

Format

Graphical

Format

Textual

Format

XML

Types

Other

Formats

msc mi_synch1_conc1

mtc ISAP1 MSAP2

testcase myTestcase () runs on MTCType systemTSIType

{ mydefault := activate (OtherwiseFail); setverdict(pass);

:

connect(PTC_ISAP1:CP_ISAP1,mtc:CP_ISAP1)

:

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”);

}

10


TTCN-3 Standards

ETSI ES 201 873-1 TTCN-3 Core Language (CL)

ETSI ES 201 873-2 TTCN-3 Tabular Presentation Format (TFT)

ETSI ES 201 873-3 TTCN-3 Graphical Presentation Format (GFT)

ETSI ES 201 873-4 TTCN-3 Semantics

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

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

Protocol and Testing Competence Center http://www.etsi.org/ptcc

Maintenance on the basis of change request


TTCN-3 Standards v3


ETSI ES 201 873-2 TTCN-3 Tabular Presentation Format (TFT)

ETSI ES 201 873-3 TTCN-3 Graphical Presentation Format (GFT)

ETSI ES 201 873-4 TTCN-3 TTCN-3 Semantics

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

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

ETSI ES 201 873-7 Integration of ASN.1

ETSI ES 201 873-8 Integration of IDL

ETSI ES 201 873-9 Integration of XML

New version v3 released and published

Standard available for download at http://www.etsi.org/ptcc

Testing Tech Tools support v3

11


Tester

Main Test Component

TTCN-3 By Example

TTCN-3 core notation is introduced by developing a test case for a Domain Name Service (DNS) server

System Under Test

Local Domain

Name Server

Local

Network

Client

Send fully qualified

hostname

Return IP-address


DNS Server – Test Purpose

The Internet’s Domain Name System (DNS) service offers hostname to IP Address resolution

Communication is message based (UDP)

We want to test the correct resolution www.testingtech.de => 217.160.141.54

(www.testingtech.de,A)

(www.testingtech.de,217.160.141.54,A)

Client DNSSUTTester

pass

12


TTCN-3 Modules

Main building block of TTCN-3 is a module

Unit of compilation

Contains definitions

And an optional control part

module DNS {

}

// module definitions

// module control (optional)


Module Definitions (1)

Module definitions

Type definitions

Templates

Port definitions

Component definitions

Test case

Control part

type record DNSQuery {charstring hostname,AnswerType answer optional,QueryType qtype

}type union AnswerType {

Byte ipAddress[4],charstring hostname

}type integer Byte (0 .. 255);type enumeration QueryType {

A, NS, CNAME, MX}

DNSQueryanswer qtypehostnamehostname

ipAddress

13



Module definitions

Type definitions

Templates

Port definitions


Test case

Control part

template DNSQuery query := {hostname := "www.testingtech.de",answer := omit,qtype := A

}

template DNSQuery answer modifies query := {answer := { ipAddress :=

{217,160,141,54} }}

query

"www.testingtech.de" A

answer

"www.testingtech.de" A217, 160, 141, 54



Module definitions

Type definitions

Templates

Port definitions


Test case

Control part

type port DNSPort message {inout DNSQuery

// a port may send/receive messages // of more than one type

}


type component DNSTester {port DNSPort P

// a component may have more than one port}

DNSTester P

Port definitions

DNSQuery

14





Client DNS

pass

Module definitions

Type definitions

Templates

Port definitions


Test case

Control part

testcase Testcase1() runs on DNSTester {P.send(query);P.receive(answer);setverdict(pass);stop;

}// there may be more than one in a module



Module definitions

Type definitions

Templates

Port definitions


Test case

Control partControls theexecution of test cases

control {

execute(Testcase1(), 5.0);while( /* condition */) { };

// more testcases might follow// C-like control structures available

}

15


control {execute(Testcase1(), 5.0);while( /* condition */) { };

}

Execution of a Test Case

Tester

testcase Testcase1() runs on DNSTester {P.send(query);P.receive(answer);setverdict(pass);stop;

}

MTCP

verdict = pass

P SUTanswer = (www.testingtech.de, 217.160.141.54,A)

query = (www.testingtech.de,A)


answer = (www.testingtech.de, 127.0.0.1,A)

Tester

Dealing with Erroneous Behavior (1)


SUT???

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.

MTCverdict =

???

P P

16


Dealing with Erroneous Behavior (2)

testcase Testcase2() runs on DNSTester {

timer t := 5.0;P.send(query);

t.start;

alt {[] P.receive(answer) {

setverdict(pass);}[] P.receive { // any message

setverdict(fail);}[] t.timeout {

setverdict(inconc);}

}stop;

}

Client DNS

failinconc



failpassfailfail


failpass


Code Reusability – Altsteps and Defaults

altstep RefactoredAltstep() runs on DNSTester {

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

}[] t.timeout {

setverdict(inconc); }

}

refactoralt {[] P.receive(answer) {

setverdict(pass);}[] P.receive { // any message

setverdict(fail);}[] t.timeout {

setverdict(inconc); }

}

var default d := activate(RefactoredAltstep());P.receive(answer);setverdict(pass);

becomes

17


Non-Local DNS Query (1)

Tester

Main TestComponent

System Under Test

Local Domain Name Server

The internet‘s rootname service

Ask for remote DNS

Get remote address

Remote DNS

Ask for IP

address

Return desired IP

address

Local NetworkClient

Send fully qualified hostname

Return IP addressParallel Test Component 1

Parallel Test Component 3

Parallel Test Component 2


Non-Local DNS Query (2)

SUT TesterTester

Client

("www.testingtech.de",217.160.141.54,A)

DNS root NS

("testingtech.de",NS)

("testingtech.de","ns.testingtech.de",NS)

NS

("www.testingtech.de",A)

("www.testingtech.de", 217.160.141.54,A)

("www.testingtech.de",A)

18


From Simple To Complex Test Scenarios

Testsystems needs more interfaces

Test System Interface has to be extended

Additional test behaviour needed at additional test interfaces

Behaviour of Local Network Client already covered in Testcase2

Behaviour of RootNS and NS required

Test case that combines all pieces


Parallel Test Components (1)

Test system interface

type component TestSystemInterface {port DNSPort CLIENT,port DNSPort ROOT,port DNSPort NS

}

DNSQuery

DNSQuery

DNSQuery

Tester

CLIENT

ROOT

NS

Tester

P DNSQuery

type component DNSTester {port DNSPort P

// a component may have more than one port}

19


From Testcase to Test Function

function ClientBehaviour() runs on DNSTester {var default d := activate(RefactoredAltstep());timer t := 5.0; P.send(query); t.start;P.receive(answer);setverdict(pass);stop;

}

becomes

testcase Testcase2() runs on DNSTester {var default d := activate(RefactoredAltstep());timer t := 5.0; P.send(query); t.start;P.receive(answer);setverdict(pass);stop;

}

Functions define the behavior of the parallel test components


Additional Test Behaviour

function RootBehaviour() runs on DNSTester {alt { [] P.receive(rootquery) {

P.send(rootanswer); setverdict(pass);

}[] P.receive {

setverdict(fail);}}

}

Simple „react-on-request“ behaviour

20


Dynamic Configuration

testcase Testcase3() runs on MTC system TestSystemInterface {

var DNSTester RootComp, NSComp, ClientComp;

RootComp := DNSTester.create;NSComp := DNSTester.create;ClientComp := DNSTester.create;

map(RootComp:P, system:ROOT);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;

} Tester

Re-configuration during run time is possible

MTC

CLIENT

ROOT

NS

PTCClient

P

PTCNS P

PTCroot NS P


Procedure-Based Communication (1)

DNS also allows queries over TCP/IP connectionsHow can this be adequately tested?

Signature definitions

Ports for procedure based communication

Component

signature DNSCall(inout charstring hostname, out AnswerType ans, inout QueryType qtype

);

type port DNSCallPort procedure { out DNSCall

}

type component DNSCallComponent { port DNSCallPort Q

}

21


Procedure-Based Communication (2)testcase Testcase4() runs on DNSCallComponent {

Q.call(DNSCall:{"www.testingtech.de", -, A}, 5.0);{

[] Q.getreply(DNSCall:{"www.testingtech.de",{217.160.141.54},A}) {setverdict(pass)

}[] Q.getreply(DNSCall: ?) {

setverdict(fail)}[] Q.catch(timeout) {

setverdict(inconc)}

}stop;

}

The TTCN-3 LanguageIntroduction to the

Runtime Environment (TRI/TCI)

22


The Testing and Test Control Notation

The standardized test specification and test implementation language

Wider scope of applicationApplicable to many kinds of test applications, not just conformancei.e. also for development, system, integration, interoperability, scalability … testing

Applicable in the telecom and datacom domain

Used both For standardized test suitesAs a generic solution in software development

The Testing and Test Control Notation

The standardized test specification and test implementation language

Wider scope of applicationApplicable to many kinds of test applications, not just conformancei.e. also for development, system, integration, interoperability, scalability … testing

Applicable in the telecom and datacom domain

Used both For standardized test suites andAs a generic solution in software development

TTCN-3


History of

TTCN-3 was published as ETSI standard in Oct. 2000

Works on standardizing the runtime interfaces started immediately

Main driversNOKIA, Ericsson

Testing Technologies, Telelogic

FOKUS, TU Berlin

TRI - TTCN-3 Runtime InterfaceFirst draft released Oct. 2001

First version released 2002

Current version dated 02/2003

TCI – TTCN-3 Control InterfacesWork for TCI started after v1.0 of TRI

v1.0 of TCI released 03/2003

Ongoing Task in the maintenance group

1998

2000

�2002

2003

2006

TC

I

TR

I

�

�

23

Testing Technologies 2006 / All Rights Reserved / Confidential Information / www.testingtech.de©

Standard Overview

10. …

1. Core Language

2. Tabular Presentation Format

3. Graphical Presentation Format

4. Operational Semantics

5. TTCN-3 Runtime Interfaces (TRI)

6. TTCN-3 Control Interfaces (TCI)

7. ASN.1 to TTCN-3

8. IDL to TTCN-3

9. XML to TTCN-3

TTCN-3 concepts and syntaxCore Language

Presentation formatsTabular Presentation Format

Graphical Presentation Format

SemanticsExecution environment

Operational Semantics

TTCN-3 Runtime Interfaces (TRI)

TTCN-3 Control Interfaces (TCI)

Language mappings

ASN.1 to TTCN-3

IDL to TTCN-3

XML to TTCN-3

TTCN-3 Runtime Interfaces (TRI)

TTCN-3 Control Interfaces (TCI)


A TTCN-3 Test System

TE – TTCN-3 Executable

SA – System Adapter

PA – Platform Adapter

CD – Codec

TM – Test Management

CH – Component Handling

SUT – System Under Test




TCI

TRI

Test System User

SUT

CDCH

TM

TE

PASA

24


Example – Test Case

Tester

MTCP

verdict = pass

P SUTanswer =



How do I start

test cases?

Where is theMTC being

executed?

How is the communication really performed?

control {

execute(Testcase1(), 5.0);

}

testcase Testcase1() runs on DNSTester {

P.send(query);

P.receive(answer);

setverdict(pass);

}


Implementation

ATS

TE

SUT Communication

+TE

Test System

25


Steps to Implement TTCN-3

Translate TTCN-3 into executable code

Adapt runtime environment to test management

Implement communication and test platform aspects





Translate TTCN-3 Into Executable Code

Reads module definitions written in the TTCN-3 core notation

Generates code and compiles it into executable code

Runtime support through runtime libraries

F:\AB>TTthree DNSTest

exampleModule.ttcn3

RuntimeLib

Compilation

TE

26


Steps to Implement TTCN-3





TCI – Distribution, Management and Codec Adaptation

TCI

TRI

Test System User

SUT

CDCH

TM

TE

PASA

Facts on the TTCN-3

Control Interfaces (TCI)

Standardized (part 6)

Language independent specification using IDL

Multi-vendor support

27


Common Structure of Sub-Interfaces

Have to be provided by the user

Require functionality of the TE

Applies to all TCI interfaces

TciCH RequiredTciCH Provided

TE

TciCD Required TciCD Provided

CD:Codec

CH:Component

Handling






CD – Codec







TCI

TRI

Test System User

SUT

CDCH

TM

TE

PASA

28


Why Test Management Interface?

Different applications need different test management functionality

Command line test management

Graphical test management

Web-based test management

Integration into existing platforms

One TTCN-3 oriented interface needed!


The Test Management Interface

TM providesUser Interface, incl. error reporting

Keeps track of test case execution

Module parameter resolving

Logging

TE providesEntry points to the TE

Start/stop test case

Start/stop control part

6 operations provided

9 operations required

TciTM Provided

TciTM Required

TM

TE

29


control {


}

Dynamics of Test Management (1)

testcase Testcase1() runs on DNSTester{

P.send(query);P.receive(answer);setverdict(pass);

}

TM TE

send

receive

passtciTestCaseTerminated(pass)

tciTestCaseStarted(Testcase1,…,5.0)

tciStartControl()

tciControlTerminated()


TM TE

Dynamics of Test Management (2)

testcase Testcase2() runs on DNSTester

{

var charstring h:= MODULE_PAR ;

log(h);

setverdict(pass);

}

MODULE_PAR ??

h:= “HELLO”

pass

tciGetModulePar(MODULE_PAR)

tciTestCaseStarted(Testcase2,…,-)

tciLog(“HELLO”)

tciTestCaseTerminated(pass)

tciStartTestCase(Testcase2)

30


The TciTMRequired Interface

TE offers the entry point for test case execution and some rudimentary database functionality

Complete set of operationsvoid tciRootModule(moduleId);

TciModuleParameterList tciGetModuleParameters(moduleId);

TciTestCaseIdList tciGetTestCases();

TciParameterTypeList tciGetTestCaseParameters(testCaseId);

TriPortIdList tciGetTestCaseTSI(testCaseId);

void tciStartTestCase(testCaseId, parameterList );

void tciStopTestCase();

TriComponentId tciStartControl();

void tciStopControl();

TciTM Provided

TciTM Required

TM

TE


The TciTMProvided Interface

Feedback of the TE to the status of execution or request for module parameters

Complete set of operationsvoid tciTestCaseStarted (testCaseId, parameterList, timerValue);

void tciTestCaseTerminated ( verdict, parameterList);

void tciControlTerminated ();

Value tciGetModulePar (parameterId);

void tciLog (testComponentId, message);

void tciError (String message);

TciTM Provided

TciTM Required

TM

TE

31






CD – Codec







TCI

TRI

Test System User

SUT

CDCH

TM

TE

PASA


Why Component Handling Interface?

TTCN-3 suitable for different test applications

Functional testing

Load testing

Interoperability testing

Need to distribute test components if running short of resources!

32


Distributed TestingNetwork / Distributed System


The Component Handling Interface

Management of TTCN-3 componentsNo implementation of TTCN-3 functionality

Distribution of TTCN-3 configuration operations

Distribution of TTCN-3 intercomponent communication

Concept of Distributed TE, i.e. multiple TEsA single component handling entity

Presence of a distinct TE*, i.e. the TE where a test case or the control part has been started

Distinct TE* responsible for final verdict calculation

The most complex interface17 required operations

17 provided operations

33


Example: DNS Tester Scalability Testing

function clntBehavior(...) {

runs on MyPtcType{

// Do what you have to do !

setverdict(pass) ;

stop ;

}

}

testcase scalabilityTest() runs on ABClient system ABTester

{

var integer i;

for(i:=0;i<MAXNUMBER;i:=i+1) {abC[i] := MyPtcType.create;map(abC[i]:S, system:R); connect(mtc:C, abC[i]:C);abC.start(clntBehavior(USER[i]);

C.send(....) to abC[i] ;}

all component.done ;

}

testcase scalabilityTest()

runs on MTC system TestSystemInt




runs on MyPtcType{


setverdict(pass) ;

stop ;

}

}

TE*

tciStartTestCase

testcase scalabilityTest() runs on MTC system TestSytemInt

{

var integer i;




}

34



runs on MyPtcType{


setverdict(pass) ;

stop ;

}

}


tciCreateTestComponent

tciCreateTestComponentReq

testcase scalabilityTest() runs on MTC system TestSystemInt

{

var integer i;




}TE*



runs on MyPtcType{


setverdict(pass) ;

stop ;

}

}


tciStartTestComponent

tciStartTestComponentReq


{

var integer i;




}TE*

35



runs on MyPtcType{


setverdict(pass) ;

stop ;

}

}


tciTestCaseStarted


{

var integer i;




}TE*



tciCreateTestComponentReq

tciCreateTestComponent


{

var integer i;




}TE*


runs on MyPtcType{


setverdict(pass) ;

stop ;

}

}

36



tciConnectReq

tciConnect


{

var integer i;




}TE*


runs on MyPtcType{


setverdict(pass) ;

stop ;

}

}



tciStartTestComponentReq

tciStartTestComponent


{

var integer i;




}TE*


runs on MyPtcType{


setverdict(pass) ;

stop ;

}

}

37



tciSendConnect

tciEnqueueMsgConnected


{

var integer i;




}TE*


runs on MyPtcType{


setverdict(pass) ;

stop ;

}

}



{

var integer i;




}


TE*


runs on MyPtcType{


setverdict(pass) ;

stop ;

}

}

setverdict(pass) ;

stop ;

38




{

var integer i;




}

tciTestComponentTerminated

tciTestComponentTerminatedReq

TE*


runs on MyPtcType{


setverdict(pass) ;

stop ;

}

}





{

var integer i;




}

tciTestComponentTerminatedReq

tciTestComponentTerminated

TE*


runs on MyPtcType{


setverdict(pass) ;

stop ;

}

}

39



tciTestCaseTerminated

testcase scalabilityTest()

runs on MTC system TestSystemInt{

var integer i;

for(i:=0;i<MAXNUMBER;i:=i+1) {abC[i] := MyPtcType.create;map(abC[i]:S, system:R); connect(mtc:C, abC[i]:C);abC.start(clntBehavior(USER[i]));



} TE*


runs on MyPtcType{


setverdict(pass) ;

stop ;

}

}


Steps To Implement TTCN-3




40


TRI – Communication Adaptation

TCI

TRI

Test System User

SUT

CDCH

TM

TE

PASA

Facts on the TTCN-3 Runtime Interfaces (TRI)

Standardized (part 5)

Language independent specification

Multi-vendor support


Why TRI ?

Abstract Test Specifications (ATS) have to run on different test devices of different vendors

Different access to underlying protocol stacks

ATS shall runs against systems in different development stages

Simulation

Software only

Embedded in hardware

ATS can use different communicationsmechanismens and dynamic test configurations

41


Goals of TRI

Specify a small and well-defined runtime interface for all future TTCN-3 test system implementations

Free TRI definition from any unnecessary restrictions

Exclude test management and data access

Exclude communication between test components and their execution model

Avoid bias towards any particular programming language

Historical older interface

Reference Implementation

Slightly different interface naming


The TRI Communication Interface

Interface structure

Due to historical reasons different naming

Applies to all TRI interfaces

SA reports status back

TE indicates error

TriCommunicationTE

TriCommunicationSA

SA

TE

42


control {


}

testcase Testcase1() runs on DNSTester system TSI {

map(mtc:P, system:P);

P.send(query);

P.receive(answer);

setverdict(pass);

}

Dynamics of TRI SA

TE SA

triEnqMsg(mtcId,systemPortId,a,msg)

triExecuteTestcase(Testcase1,TSI)

triSAReset()

SUT

process

triMap(mtcId,systemPortId)

triSend(mtcId,systemPortId,a,msg)

pass


TriCommunicationSA Interface

Defines setting up configuration and sending of message to and/or calling of operations in the SUT

Complete set of operationsTriStatusType triSAReset();

TriStatusType triExecuteTestCase(…);

TriStatusType triMap(…);

TriStatusType triUnmap(…);

TriStatusType triSend(…);

TriStatusType triCall(…);

TriStatusType triReply(…);

TriStatusType triRaise(…);TSI

TC TC

43


TriCommunicationTE Interface

Defines receiving of messages and/or calling of operations in the TE

Complete set of operationsvoid triEnqueueMsg(…);

void triEnqueueCall(…);

void triEnqueueReply(…);

void triEnqueueException(…);

TSI

TC TC


The TRI Platform Interface

Interface structure

Implementation of time and external functions

PA reports status back

TE indicates error

TriPlatformTE

TriPlatformPA

PA

TE

44


control {


}

testcase Testcase2() runs on DNSTester system TSI{

var timer t := 5.0 ;

t.start ;

var octetstring crc := crc32(myData);

t.timeout ;

setverdict(pass);

}

Dynamics of TRI PA

TE PA

triTimeout(t)

triStartTimer(t, 5.0)

triPAReset()

SUT

triExternalFunction(crc32, myData)

calculation

pass


TriPlatform Interface

Defines control of time and calling of external functions

Complete set of operations (PA)TriStatusType triPAReset();

TriStatusType triStartTimer(…);

TriStatusType triStopTimer(…);

TriStatusType triReadTimer(…);

TriStatusType triTimerRunning(…);

TriStatusType triExternalFunction(…);

Complete set of operations (TE)void triTimeout(…);

PA

TC TC ��

45

The TTCN-3 LanguageThe Codec Interface






CD – Codec







TCI

TRI

Test System User

SUT

CDCH

TM

TE

PASA

46


Why Codec Interface?

TTCN-3 data has to be translated into a representation the SUT understands

Two different tasks

EncodingInternal TTCN-3 data representation to bitstring

Needs access to the TTCN-3 type and value system

DecodingBitstring to TTCN-3 data representation

Based upon a decoding hypothesis

TE may query multiple times for the decoding of the same bitstring


The Codec and Value Interface

Management of different codecs

Complete set of provided (TciCDProvided) operationsValue decode (in TriMessageType message,

in Type hyp)

TriMessageType encode (in Value value)

Facts on the TTCN-3 Type and Value Interface

TE maintains abstract type and data presentation

Codec translates betweenabstract and concretepresentation

CD:Codec

TciCD ProvidedTciCD Required

47


The Data Types Used

DNSQueryanswer qtypehostnamehostname

ipAddress

The DNS Query example

type record DNSQuery {charstring hostname,AnswerType answer optional,QueryType qtype

}type union AnswerType {

Byte ipAddress[4],charstring hostname

}type integer Byte (0 .. 255);type enumeration QueryType {

A, NS, CNAME, MX}


Dynamics of the Codec (Sending)

control {execute(Testcase1(), 5.0);

}

testcase Testcase1() runs on DNSTester system TSI {


P.send(query);

P.receive(answer);

setverdict(pass);

}

TE SA SUTCD

triExecuteTestcase(Testcase1,tsiP)

triMap(mtcId,systemPortId)

encode(value)encode

triSend(mtcId,systemPortId,a,msg)

process

48


Dynamics of the Codec (Receiving)

control {execute(Testcase1(), 5.0);

}

testcase Testcase1() runs on ABClient system ABTester{


P.send(query);

P.receive(answer);

setverdict(pass);

}

TE SA

triEnqMsg(mtcId,systemPortId,a,msg)

SUT

decode(msg,type)

CD

process

try to decode

pass


The decodingHypothesis

The interpretation of an arbitrary bitstring is context sensitive

Example: What is ‘56455300'O ?

Four bytes as one octetstring: ‘56455300'O

An integer: 1447383808

A charstring: “YES”

Decode() can be read as follows:

Try to decode the provided bitstring, with the appropriated decoding rules into a value of given type

If you succeed, return the value

If you fail, return NULL

49


Access To TTCN-3 Data Types and Values

Formal definitionSpecification of Abstract Data TypesType for TTCN-3 Types Different ADT Types for TTCN-3 Values

Set of high-level operations define the functionality

Practical usageTTCN-3 environments provide functions/operations to

Access TTCN-3 typesRead existing TTCN-3 values andCreate new TTCN-3 values

Underlying philosophy behind the ADT operations is an object oriented model


Abstract Data Type: Type

Type represents every TTCN-3 type

Only types defined in TTCN-3 modules can be accessed

No creation of user defined types at the TCI

... but creation of new instances of given type!

type record DNSQuery {charstring hostname,AnswerType answer optional,QueryType qtype}

type union AnswerType {Byte ipAddress[4],charstring hostname

}

Type

TcoModuleId getDefiningModule()String getName()TciTypeClass getTypeClass()String getTypeEncoding()Value newInstance()

50


template DNSQuery query := {hostname := "www.testingtech.de",answer := omit,qtype := A

}

ADT: Value

UnionValue EnumeratedValue RecordOfValue RecordValue

HexstringValue OctetstringValue CharstringValue BitstringValue

UniversalCharstringValue

Value

Type getType()String getValueEncoding()boolean notPresent()

FloatValue

IntegerValue

BooleanValue

ObjidValue

VerdictValue


The Codec Interface

Complete set of required (TciCDRequired) operationsType getTypeForName(…)

Type getInteger()

Type getFloat()

Type getBoolean()

Type getChar()

Type getUniversalChar()

Type getObjid()

Type getCharstring ()

Type getUniversalCharstring ()

Type getHexstring ()

Type getBitstring()

Type getOctetstring ()

Type getVerdict()

void tciErrorReq(…)

51


TE

The Codec and Value Interface

3rd Party Codec provides

Operations to construct values

Operations to query values

Operations to encode values

Operations to decode bitstring TE

CD provides

Operations to construct values

Operations to query values

CD implementation maps TCI value structures into codec value structures

CD

TciCD ProvidedTciCD Requested

3rd

Party

Codec


Summary

TTCN-3 provides two different interfaces

TTCN-3 Runtime Interface

TTCN-3 Control Interface

Provide a complete, implementation independent set of operations for implementing TTCN-3 test suites

Some components

are provided by the TTCN-3 tools,

others are provided by TTCN-3 solutions

and others have to be implemented manually.

Result: High flexibility and reuse of software components within the test system development

thettcn-3 language - etsi · pdf filethettcn-3 language introduction to ttcn-3 motivation

Documents