ETSI ES 203 119-2014 Methods for Testing and Specification (MTS) The Test Description Language (TDL) Specification of the Abstract Syntax and Associated Semantics (V1 1 1 Includes _1.pdf

1、 ETSI ES 203 119 V1.1.1 (2014-04) Methods for Testing and Specification (MTS); The Test Description Language (TDL); Specification of the Abstract Syntax and Associated Semantics floppy3ETSI Standard ETSI ETSI ES 203 119 V1.1.1 (2014-04) 2Reference DES/MTS-140_TDL Keywords language, MBT, methodology,

2、 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 (http:/ipr.etsi.org). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, h

3、as 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. Foreword This ETSI Standard (ES) has been produced by ETSI Techni

4、cal Committee Methods for Testing and Specification (MTS). ETSI ETSI ES 203 119 V1.1.1 (2014-04) 71 Scope The present document specifies the abstract syntax of the Test Description Language (TDL) in the form of a meta-model based on the OMG Meta Object Facility (MOF) 1 and also specifies the semanti

5、cs 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 enable TDL tools such as documentation generators, specification analyzers, and code generators. The specificatio

6、n 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. 2 References References are either specific (identified by date

7、 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 the referenced document (including any amendments) applies. Referenced documents which are not found to be publicly av

8、ailable 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. 2.1 Normative references The following referenced documents are necessary for

9、the application of the present document. 1 “OMG Meta Object Facility (MOF) Core Specification V2.4.1“, formal/2013-06-01. NOTE: Available at http:/www.omg.org/spec/MOF/2.4.1/. 2 “OMG Unified Modeling LanguageTM(OMG UML) Superstructure, Version 2.4.1“, formal/2011-08-06. 3 ISO/IEC 9646-1:1994: “Infor

10、mation technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts“. 2.2 Informative references The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particul

11、ar 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 Access (E-UTRA) and Evolved Packet Core (EPC); Use

12、r 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: “Technical Committee for IMS Network Testing (INT); IMS NNI Interoperability Test Specifications; Part 2: Test descriptions for IMS NNI Interop

13、erability“. ETSI ETSI ES 203 119 V1.1.1 (2014-04) 83 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 any particular encoding

14、NOTE: The TDL abstract syntax is defined in terms of the TDL meta-model. action: any procedure carried out by a component of a test configuration or an actor during test execution that could result in changes to the test verdict actor: abstraction of entities outside a test configuration that intera

15、ct directly with the components of that test configuration component: active element of a test configuration 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

16、 for the users of this language interaction: any form of communication between components that is accompanied with an exchange of data NOTE: An interaction can be a point-to-point or a point-to multipoint communication. meta-model: modelling elements representing the abstract syntax of a language Sy

17、stem 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 specification: representation of a TDL model given in a concrete syntax test configuration: specification of a set of co

18、mponents 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 behaviour that runs on a given test configuration test verdict: Result from executing a test description 3. tester: r

19、ole of a component within a test configuration that controls the execution of a test description against the components in the role system under test 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: EBNF Extended Backus-Naur Form IMS IP Multimedia Subsys

20、tem MBT Model-Based Testing MOF Meta-Object Facility SUT System 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 UTP UML Testing Profile ETSI ETSI ES 203 119 V1.1.1 (

21、2014-04) 94 Basic Principles 4.1 What is TDL? TDL is a language that supports the design and documentation of formal test descriptions that can 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

22、homogeneous approach to the test design phase include: Manual design of test descriptions from a test purpose specification, user stories in test driven development (TDD) or other sources. Representation of test descriptions derived from other sources such as MBT test generation tools, system simula

23、tors, or test execution traces from test runs. TDL supports the design of black-box tests for distributed, 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 tra

24、ces. Being a formal notation, TDL clearly separates the specification of tests from their implementation by providing an abstraction 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 ens

25、ure their fault detection capabilities onto an execution framework. TDL is designed to support different abstraction levels of test specifications. On one hand, the concrete syntax of the TDL meta-model can hide meta-model elements that are not needed for a declarative (more abstract) style of speci

26、fying test descriptions. For example, a declarative test description could work with the 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 dedi

27、cated concrete syntax could provide additional means necessary to derive executable test 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

28、 further details. It is expected that most details of a refined, imperative test description can be generated automatically from a declarative test description. Supporting different shades of abstraction by a single TDL meta-model offers the possibility of working within a single language and using

29、the same tools, simplifying the test development process that way. 4.2 Applicability of the present document The TDL language design is centered around the three separate concepts of abstract syntax, concrete syntax, and semantics (see figure 4.1). The present document covers the TDL abstract syntax

30、 given as the TDL meta-model and its associated semantics. The TDL concrete syntax is application or domain specific and is not specified in the present document. However, for information, see annex B for an example of a concrete textual syntax. The semantics of the meta-model elements are captured

31、in the individual clauses describing the meta-model elements defined in the present document. ETSI ETSI ES 203 119 V1.1.1 (2014-04) 10Abstract SyntaxMOF basedSemanticsConcrete Syntaxuser-defined as well as their related operations (clause 9). Predefined values for verdicts and time units that can be

32、 extended by a user (clause 10). 4.5 Notational Conventions In the present document, the following notational conventions are applied: element The name of an element or of the property of an element from the meta-model, e.g. the name of a meta-class. metaclass Indicates an element of the meta-model,

33、 which corresponds to a node of the abstract syntax, i.e. an intermediate node if the element name is put in italic or a terminal node if given in plain text. Enumeration Denotes an enumeration type. /name The value with this name of a property or relation is derived from other sources within the me

34、ta-model. 1 Multiplicity of 1, i.e. there exists exactly one element of the property or relation. 01 Multiplicity of 0 or 1, i.e. there exists an optional element of the property or relation. * or 0* Multiplicity of 0 to many, i.e. there exists a possibly empty set of elements of the property or rel

35、ation. 1* Multiplicity of one to many, i.e. there exists a non-empty set of elements of the property or relation. unique All elements contained in a set of elements shall be unique. ordered All elements contained in a set of elements shall be ordered, i.e. the elements form a list. Furthermore, the

36、definitions and notations from the MOF 2 core framework 1 and the UML class diagram definition 2 apply. 4.6 Conformance For an implementation claiming to conform to this version of the TDL meta-model, all features specified in the present document shall be implemented consistently with the requireme

37、nts given in the present document. The electronic attachement in annex A can serve as a starting point for a TDL meta-model implementation conforming to the present document. ETSI ETSI ES 203 119 V1.1.1 (2014-04) 125 Foundation 5.1 Overview The Foundation package specifies the fundamental concepts o

38、f the TDL meta-model. All other features of the TDL meta-model rely on the concepts defined in this Foundation package. 5.2 Abstract Syntax Figure 5.1: Foundational Language Concepts ETSI ETSI ES 203 119 V1.1.1 (2014-04) 13Figure 5.2: Comments and Annotations Figure 5.3: Test Objective Concepts 5.3

39、Classifier Description 5.3.1 Element Semantics An Element is a constituent of a TDL Specification. It is the super-class of all other classes in the meta-model. It provides the ability to add comments and annotation to each Element. ETSI ETSI ES 203 119 V1.1.1 (2014-04) 14Generalizations There are n

40、o generalizations specified. Properties name : String 01 The optional name of the Element. The name can contain any character, including white-spaces. Having no name specified is different from the empty name (which is represented by an empty string). comment : Comment 0* unique A possibly empty set

41、 of Comments attached to the Element. annotation : AnnotationType 0* unique A possibly empty set of Annotations attached to the Element. Constraints There are no constraints specified. 5.3.2 PackageableElement Semantics A PackageableElement is contained in a Package. It has a mandatory qualifiedName

42、 that shall be unique throughout the owning and any imported Package. The qualifiedName distinguishes equally named PackageableElements of different Packages from each other. This makes it possible that a PackageableElement with the same name can be imported into a Package without causing a name cla

43、sh. The qualifiedName is a compound name derived from the directly and all indirectly enclosing parent Packages by concatenating the names of each Package. As a separator between the segments of a qualifiedName the string : shall be used. The name of the root Package that (transitively) owns the Pac

44、kageableElement shall always constitute the first segment of the qualifiedName. The visibility of a PackageableElement is restricted to the Package in which it is directly contained. A PackageableElement may be imported into other Packages by using ElementImport. A PackageableElement has no means to

45、 actively increase its visibility. Generalizations Element Properties /qualifiedName : String 1 read-only A derived property that represents the unique name of a package within a TDL model. owningPackage : Package 01 The Package that owns the PackageableElement. Constraints Distinguishable qualified

46、 names All qualified names shall be distinguishable within a TDL model. ETSI ETSI ES 203 119 V1.1.1 (2014-04) 155.3.3 Package Semantics A Package represents a container for PackageableElements. A TDL model may contain any number of Packages, which may have any arbitrary substructure. A Package may c

47、ontain any number of PackageableElements. A Package builds a scope of visibility for its contained PackageableElements. A PackageableElement is only accessible within its owning Package and within any Package that directly import it. A Package may import any PackageableElement from any other Package

48、 with the means of ElementImport. By importing a PackageableElement, the imported PackageableElement becomes visible and accessible within the importing Package. Cyclic imports of packages are not permitted. Generalizations PackageableElement Properties packagedElements : PackageableElements 0* uniq

49、ue The PackageableElements that are directly contained in the Package. import : ElementImport 0* unique The list of import declarations. Constraints No cyclic imports Cyclic imports are not allowed. That is, a package shall not import itself directly or indirectly via other packages. 5.3.4 ElementImport Semantics An ElementImport allows importing PackageableElements from other Packages i