1、 ETSI ES 203 119-1 V1.4.1 (2018-05) Methods for Testing and Specification (MTS); The Test Description Language (TDL); Part 1: Abstract Syntax and Associated Semantics floppy3ETSI STANDARD ETSI ETSI ES 203 119-1 V1.4.1 (2018-05)2 Reference RES/MTS-203119-1v1.4.1 Keywords language, MBT, methodology, m
2、odel, testing, TSS Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (https:/ipr.etsi.org/). Pursuant to the ETSI IPR Policy, no investigation, including IPR sear
3、ches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Trademarks The present document may include trademarks and
4、/or tradenames which are asserted and/or registered by their owners. ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does n
5、ot constitute an endorsement by ETSI of products, services or organizations associated with those trademarks. Foreword This ETSI Standard (ES) has been produced by ETSI Technical Committee Methods for Testing and Specification (MTS). The present document is part 1 of a multi-part deliverable coverin
6、g the Test Description Language, as identified below: Part 1: “Abstract Syntax and Associated Semantics“; Part 2: “Graphical Syntax“; Part 3: “Exchange Format“; Part 4: “Structured Test Objective Specification (Extension)“; Part 5: “UML Profile for TDL“; Part 6: “Mapping to TTCN-3“; Part 7: “Extende
7、d Test Configurations“. Modal verbs terminology In the present document “shall“, “shall not“, “should“, “should not“, “may“, “need not“, “will“, “will not“, “can“ and “cannot“ are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
8、 “must“ and “must not“ are NOT allowed in ETSI deliverables except when used in direct citation. ETSI ETSI ES 203 119-1 V1.4.1 (2018-05)8 1 Scope The present document specifies the abstract syntax of the Test Description Language (TDL) in the form of a meta-model based on the OMGMeta Object Facility
9、 (MOF) 1. It also specifies the semantics of the individual elements of the TDL meta-model. The intended use of the present document is to serve as the basis for the development of TDL concrete syntaxes aimed at TDL users and to enable TDL tools such as documentation generators, specification analys
10、ers and code generators. The specification of concrete syntaxes for TDL is outside the scope of the present document. However, for illustrative purposes, an example of a possible textual syntax together with its application on some existing ETSI test descriptions are provided. NOTE: OMG, UML, OCL an
11、d UTP are the trademarks of OMG (Object Management Group). This information is given for the convenience of users of the present document and does not constitute an endorsement by ETSI of the products named. 2 References 2.1 Normative references References are either specific (identified by date of
12、publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies. Referenced documents which are not found to be publicly availa
13、ble in the expected location might be found at http:/docbox.etsi.org/Reference. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The following referenced documents are necessary for the application of the presen
14、t document. 1 OMG formal/13-06-01: “OMG Meta Object Facility (MOF) Core Specification V2.4.1“. NOTE: Available at http:/www.omg.org/spec/MOF/2.4.1/. 2 OMG formal/11-08-06: “OMG Unified Modeling Language (OMG UML) Superstructure, Version 2.4.1“. NOTE: Available at http:/www.omg.org/spec/UML/2.4.1/. 3
15、 OMG formal/14-02-03: “Object Constraint Language (OCL), Version 2.4“. NOTE: Available at http:/www.omg.org/spec/OCL/2.4/. 4 Void. 5 ETSI ES 203 119-3 (V1.2.1): “Methods for Testing and Specification (MTS); The Test Description Language (TDL); Part 3: Exchange Format“. 6 ETSI ES 203 119-4 (V1.2.1):
16、“Methods for Testing and Specification (MTS); The Test Description Language (TDL); Part 4: Structured Test Objective Specification (Extension)“. 7 ISO/IEC 9646-1:1994: “Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts“.
17、ETSI ETSI ES 203 119-1 V1.4.1 (2018-05)9 2.2 Informative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of
18、the referenced document (including any amendments) applies. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The following referenced documents are not necessary for the application of the present document but t
19、hey assist the user with regard to a particular subject area. i.1 ETSI ES 201 873-1 (V4.5.1): “Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language“. i.2 ETSI TS 136 523-1 (V10.2.0): “LTE; Evolved Universal Terrestrial Radio Acces
20、s (E-UTRA) and Evolved Packet Core (EPC); User Equipment (UE) conformance specification; Part 1: Protocol conformance specification (3GPP TS 36.523-1 version 10.2.0 Release 10)“. i.3 ETSI TS 186 011-2: “Core Network and Interoperability Testing (INT); IMS NNI Interoperability Test Specifications (3G
21、PP Release 10); Part 2: Test descriptions for IMS NNI Interoperability“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: abstract syntax: graph structure representing a TDL specification in an independent form of an
22、y particular encoding action: any procedure carried out by a component of a test configuration or an actor during test execution actor: abstraction of entities outside a test configuration that interact directly with the components of that test configuration component: active element of a test confi
23、guration that is either in the role tester or system under test concrete syntax: particular representation of a TDL specification, encoded in a textual, graphical, tabular or any other format suitable for the users of this language interaction: any form of communication between components that is ac
24、companied with an exchange of data meta-model: modelling elements representing the abstract syntax of a language system under test (SUT): role of a component within a test configuration whose behaviour is validated when executing a test description TDL model: instance of the TDL meta-model TDL speci
25、fication: representation of a TDL model given in a concrete syntax test configuration: specification of a set of components that contains at least one tester component and one system under test component plus their interconnections via gates and connections test description: specification of test be
26、haviour that runs on a given test configuration test verdict: result from executing a test description tester: role of a component within a test configuration that controls the execution of a test description against the components in the role system under test ETSI ETSI ES 203 119-1 V1.4.1 (2018-05
27、)10 tester-input event: event that occurs at a component in the role tester and determines the subsequent behaviour of this tester component NOTE: Tester-input events in the present document are the following: square4 Quiescence. square4 TimeOut. square4 An Interaction with a Target that in turnvia
28、its GateReferencerefers to a ComponentInstance in the role Tester. If the source of an Interaction is also a tester then it is not a tester-input event. : semantical concept denoting an undefined data value 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply
29、: ADT Abstract Data Type EBNF Extended Backus-Naur Form IEC International Electrotechnical Commission IMS IP Multimedia Subsystem ISO International Organization for Standardization MBT Model-Based Testing MOF Meta-Object Facility OCL Object Constraint Language OMG Object Management Group SUT System
30、Under Test TDD Test Driven Development TDL Test Description Language TTCN-3 Testing and Test Control Notation version 3 UML Unified Modelling Language URI Unified Resource Identifier XML eXtensible Markup Language4 Basic Principles 4.1 What is TDL? TDL is a language that supports the design and docu
31、mentation of formal test descriptions that may be the basis for the implementation of executable tests in a given test framework, such as TTCN-3 i.1. Application areas of TDL that will benefit from this homogeneous approach to the test design phase include: Manual design of test descriptions from a
32、test purpose specification, user stories in test driven development or other sources. Representation of test descriptions derived from other sources such as MBT test generation tools, system simulators, or test execution traces from test runs. TDL supports the design of black-box tests for distribut
33、ed, concurrent real-time systems. It is applicable to a wide range of tests including conformance tests, interoperability tests, tests of real-time properties and security tests based on attack traces. TDL clearly separates the specification of tests from their implementation by providing an abstrac
34、tion level that lets users of TDL focus on the task of describing tests that cover the given test objectives rather than getting involved in implementing these tests to ensure their fault detection capabilities onto an execution framework. ETSI ETSI ES 203 119-1 V1.4.1 (2018-05)11 TDL is designed to
35、 support different abstraction levels of test specification. On one hand, the concrete syntax of the TDL meta-model may hide meta-model elements that are not needed for a declarative (more abstract) style of specifying test descriptions. For example, a declarative test description could work with th
36、e time operations wait and quiescence instead of explicit timers and operations on timers (see clause 9). On the other hand, an imperative (less abstract or refined) style of a test description supported by a dedicated concrete syntax could provide additional means necessary to derive executable tes
37、t descriptions from declarative test descriptions. For example, an imperative test description could include timers and timer operations necessary to implement the reception of SUT output at a tester component and further details. It is expected that most details of a refined, imperative test descri
38、ption can be generated automatically from a declarative test description. Supporting different levels of abstraction by a single TDL meta-model offers the possibility of working within a single language and using the same tools, simplifying the test development process that way. 4.2 Design Considera
39、tions TDL makes a clear distinction between concrete syntax that is adjustable to different application domains and a common abstract syntax, which a concrete syntax is mapped to (an example concrete syntax is provided in annex B). The definition of the abstract syntax for a TDL specification plays
40、the key role in offering interchangeability and unambiguous semantics of test descriptions. It is defined in the present document in terms of a MOF meta-model. A TDL specification consists of the following major parts that are also reflected in the meta-model: A test configuration consisting of at l
41、east one tester and at least one SUT component and connections among them reflecting the test environment. A set of test descriptions, each of them describing one test scenario based on interactions between the components of a given test configuration and actions of components or actors. The control
42、 flow of a test description is expressed in terms of sequential, alternative, parallel, iterative, etc. behaviour. A set of data definitions that are used in interactions and as parameters of test description invocations. Behavioural elements used in test descriptions that operate on time. Using the
43、se major ingredients, a TDL specification is abstract in the following sense: Interactions between tester and SUT components of a test configuration are considered to be atomic and not detailed further. For example, an interaction can represent a message exchange, a remote function/procedure call, o
44、r a shared variable access. All behavioural elements within a test description are totally ordered, unless it is specified otherwise. That is, there is an implicit synchronization mechanism assumed to exist between the components of a test configuration. The behaviour of a test description represent
45、s the expected, foreseen behaviour of a test scenario assuming an implicit test verdict mechanism, if it is not specified otherwise. If the specified behaviour of a test description is executed, the pass test verdict is assumed. Any deviation from this expected behaviour is considered to be a failur
46、e of the SUT, therefore the fail verdict is assumed. An explicit verdict assignment may be used if in a certain case there is a need to override the implicit verdict setting mechanism (e.g. to assign inconclusive or any user-defined verdict values). The data exchanged via interactions and used in pa
47、rameters of test descriptions are represented as values of an abstract data type without further details of their underlying semantics, which is implementation-specific. There is no assumption about verdict arbitration, which is implementation-specific. If a deviation from the specified expected beh
48、aviour is detected, the subsequent behaviour becomes undefined. In this case an implementation might stop executing the TDL specification. A TDL specification represents a closed system of tester and SUT components. That is, each interaction of a test description refers to one source component and a
49、t least one target component that are part of the underlying test configuration a test description runs on. The actions of the actors (entities of the environment of the given test configuration) may be indicated in an informal way. ETSI ETSI ES 203 119-1 V1.4.1 (2018-05)12 Time in TDL is considered to be global and progresses in discrete quantities of arbitrary granularity. Progress in time is expressed as a monotonically increasing function. Time starts with the execution of the first (base) test des
