STF 454 “DESIGN OF TDL” Proposed TDL features © ETSI All rights reserved

Document History , 21: Cross-referencing Message fields , 15: Decomposition, test configuration , 12: Packaging , 6: Invalid tests : Created + Template provided © ETSI All rights reserved 2

TEMPLATE Used to describe any new feature 3 © ETSI All rights reserved

TDL Feature Description Proposed structure (to be partially completed at least) TDL feature name Covered TDL use cases (see next slide) Motivation Description (abstract syntax, meta-model) Semantics Proposed textual concrete syntax Proposed graphical concrete syntax Examples of use © ETSI All rights reserved 4

TDL use cases UCShort descriptionExample ATDL for documentation (incl. informal parts) 3GPP test specs BTDL for generation of tests that can be made executable (i.e. all parts are formal) Automatic mapping of a TDL spec to partial TTCN-3 code CTDL for representation of generated tests (i.e. output from MBT tools) Test cases generated from system models DTDL for representation of test logsTest execution log of a TTCN-3 tool ETDL for test generation (i.e. input to MBT tools) Test models as activity diagrams FTDL for performance testingOn-the-fly testing from a TDL spec © ETSI All rights reserved 5

VALID/INVALID TEST BEHAVIOR Suggested: Andreas UlrichDate: © ETSI All rights reserved

Valid/invalid test cases Feature name Structure, Test case, Kind, {valid, invalid} Covered TDL use cases A, B, C, D © ETSI All rights reserved 7

Motivation (1) Functional (conf, iop) tests typically describe the expected behavior of a SUT  Valid test Possible verdict mechanism (implementation dependent) Init state: none Intermediate state: pass (as specified) or inconc/fail (any deviation, not specified) Final state: pass (as specified) or fail (any deviation, not specified) © ETSI All rights reserved 8

Motivation (2) Security tests typically describe the behavior of a possible attacker of the SUT  Invalid test Possible verdict mechanism (implementation dependent) Init state: none Intermediate state: inconc (as specified) or pass (any deviation, not specified) Final state: fail (as specified) or pass (any deviation, not specified) Requires a different verdict arbiter, since inconc < pass (opposite to valid test) Explicit verdict setting leads to cluttered specs © ETSI All rights reserved 9

Example: Session Hijacking © ETSI All rights reserved 10 ‘neg’ block indicates invalid test behavior; alternative representations possible, e.g. as a stereotype

Semantics Invalid test behavior indicates behavior that shall be not allowed for a correct SUT Invalid and valid (default) are a property of a test case Invalid and valid tests differ in the way verdicts are assigned to specified and unspecified SUT outputs which implies the use of different arbiters Can be extended to cover valid/invalid test data © ETSI All rights reserved 11

PACKAGING Suggested: Marc-Florian Wendland, Philip Makedonski Date: © ETSI All rights reserved

Packaging in TDL A simple Package concept ‚Viewpoint‘ for futher meta-information Identify adequate elements as packageable Only these elements can be packed in Packages A non-packageable element needs to be contained somewhere else Scoping must be made explicit through a dedicated concept © ETSI All rights reserved 13

General packaging mechanism (with scoping) © ETSI All rights reserved 14

DECOMPOSITION Suggested: Gusztáv Adamis Date: © ETSI All rights reserved

Motivation (1) General Structure of IMS interoperability test SUT distributed Tester distributed Different port types (interfaces on picture) © ETSI All rights reserved 16

Example An example of a concrete test configuration (here the SUT is not distributed, but the tester is) Communication between tester components: special (formalized) protocol ISO/IEC 9646: Multy-party testing; Coordinated test method © ETSI All rights reserved 17 TTCN3 Test Case MSC Sv I2 Sv Protocol Implement. I2 Protocol Implement. trigger call flow trigger Sv call flow trigger I2 call flow get I2 result get Sv result => verdict

Conclusion In interoperability and system testing The SUT may be decomposed The Tester may be decomposed (distributed) The components can communicate with each other through interaction gates (‘ports’) Connections may be between SUT and Tester Tester components SUT components © ETSI All rights reserved 18

Proposed TDL constructs (1) Interaction Gate type Specifies messages/function calls that can be sent/received through it Component type ‘Container’ of several interaction gates Can be mapped to concrete physical equipment Internal synchronization among contained gates Component instances (Interaction Gate instances) Defined implicitly by component instances Question: Gate/Component types to be defined explicitly or possibility of implicit definition (e.g. derived from behavior description) © ETSI All rights reserved 19

Proposed TDL constructs (2) Test configuration Component instances SUT component(s) Tester component(s) Interconnections among the components Can only be static (as proposed by HLTD) Cannot see a need for dynamic test configuration © ETSI All rights reserved 20

CROSS-REFERENCING MESSAGE FIELDS Suggested: György RéthyDate: © ETSI All rights reserved

TDL Feature Description Proposed structure TDL feature name: Cross-referencing message fields Covered TDL use cases: A, B, C, E, F(see last slide) Motivation: In protocol communication data received in a message often shall be repeated in another message; some typical examples: Session/call/context/etc. IDs generated runtime (either by the originating side or sometimes both sides generate IDs) shall be used in all subsequent messages belonging to the same Session/call/context/etc. When testing a relaying node, several data shall also be relayed between the sides, like User IDs, media descriptors, etc. © ETSI All rights reserved 22

TDL Feature Description Proposed structure Description (abstract syntax, meta-model): to be defined by the STF; Semantics The content of a given message field shall be the same as the content of the referenced message field. The referenced message field may be a field of the same message or a field of an other message The requirement here is that the syntax identifies the semantics unambiguously, i.e. the user should not guess what e.g. “.. =. ” on a sending operator means, but it is specified in the standard (for example: subfield name2 of field name1 of this message shall be a compatible type and shall contain the same value as field name4 of message Name3). © ETSI All rights reserved 23

TDL Feature Description Examples of use Example1: IPv6 Core CTS (ETSI TS V1.1.2 ( ): TP Id : TP_COR_1082_02 summary : 'Tests acceptance of (three) correctly fragmented packets' RQ Ref : RQ_COR_1082 config : CF_000_C TC Ref : TC_COR_1082_02 with { IUT 'Node' and 'IUT ready to process IPv6 packets‘ } ensure that { when { IUT receives 'first IPv6 packet' containing 'fragment header' indicating 1 'more fragments' and IUT receives 'second IPv6 packet' containing 'fragment header' indicating 1 'more fragment' and containing 'Identification' indicating 'same value as in first IPv6 packet' and IUT receives 'third IPv6 packet' containing 'fragment header' indicating 0 'last fragment' and containing 'Identification' indicating 'same value as in first IPv6 packet' } then { IUT accepts 'the packet‘ and IUT sends 'no error message' } } © ETSI All rights reserved 24

TDL Feature Description Example2: ETSI TS V2.1.1 ( ) IMS specific use of Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Conformance Testing; Part 2: Test Suite Structure (TSS) and Test Purposes (TP) © ETSI All rights reserved 25

TDL Feature Description Example3: ETSI TS V4.1.3 ( ) IMS NNI Interoperability Test Specifications; Part 2: Test description for IMS NNI Interoperability TD_IMS_REG_0001_AKA © ETSI All rights reserved 26

TDL Feature Description Example3, TD_IMS_REG_0001_AKA (continued) © ETSI All rights reserved 27