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

2. Document History 2013-04-09, 21: Cross-referencing Message fields 2013-04-03, 15: Decomposition, test configuration 2013-04-02, 12: Packaging 2013-03-13, 6: Invalid tests 2013-03-13: Created + Template provided © ETSI 2011. All rights reserved 2

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

4. 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 2011. All rights reserved 4

5. 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 2011. All rights reserved 5

6. VALID/INVALID TEST BEHAVIOR Suggested: Andreas UlrichDate: 2013-03-13 6 © ETSI 2011. All rights reserved

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

8. 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 2011. All rights reserved 8

9. 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 2011. All rights reserved 9

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

11. 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 2011. All rights reserved 11

12. PACKAGING Suggested: Marc-Florian Wendland, Philip Makedonski Date: 2013-04-02 12 © ETSI 2011. All rights reserved

13. 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 2011. All rights reserved 13

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

15. DECOMPOSITION Suggested: Gusztáv Adamis Date: 2013-04-03 15 © ETSI 2011. All rights reserved

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

17. 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 2011. 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

18. 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 2011. All rights reserved 18

19. 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 2011. All rights reserved 19

20. 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 2011. All rights reserved 20

21. CROSS-REFERENCING MESSAGE FIELDS Suggested: György RéthyDate: 2013-04-09 21 © ETSI 2011. All rights reserved

22. 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 2011. All rights reserved 22

23. 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 2011. All rights reserved 23

24. TDL Feature Description Examples of use Example1: IPv6 Core CTS (ETSI TS 102 515 V1.1.2 (2008-01): 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 2011. All rights reserved 24

25. TDL Feature Description Example2: ETSI TS 102 790-2 V2.1.1 (2013-02) 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 2011. All rights reserved 25

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

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