diff --git a/TS-0019-Abstract_Test_Suite_&_implementation_eXtra_Information_for_Test-V2_0_0.md b/TS-0019-Abstract_Test_Suite_&_implementation_eXtra_Information_for_Test.md
similarity index 58%
rename from TS-0019-Abstract_Test_Suite_&_implementation_eXtra_Information_for_Test-V2_0_0.md
rename to TS-0019-Abstract_Test_Suite_&_implementation_eXtra_Information_for_Test.md
index 8c642630ec7eef1a27d236f25a39602d577dcc97..70f0968999af3fde74880017c38e42189ed6f120 100644
--- a/TS-0019-Abstract_Test_Suite_&_implementation_eXtra_Information_for_Test-V2_0_0.md
+++ b/TS-0019-Abstract_Test_Suite_&_implementation_eXtra_Information_for_Test.md
@@ -6,9 +6,9 @@
|oneM2M<br>Technical Specification |oneM2M<br>Technical Specification |
|-|-|
-|Document Number |oneM2M-TS-0019-V-2.0.0 |
+|Document Number |oneM2M-TS-0019-V-2.7.0 |
|Document Name: |Abstract Test Suite and Implementation eXtra Information for Test |
-|Date: |2018 July 27 |
+|Date: |2022 January 26 |
|Abstract: |Abstract Test Suite and Implementation eXtra Information for Test consists of :<br>- Definition of the Abstract Protocol Tester (APT)<br>- Definition of TTCN-3 test architecture<br>- Development of TTCN-3 test suite, e.g. naming conventions, code documentation, test case structure.<br>- IXIT proforma; <br> |
|Template Version:23 February 2015 (Do not modify) |Template Version:23 February 2015 (Do not modify) |
@@ -26,7 +26,7 @@ The present document has not been subject to any approval process by the oneM2M
The purpose and goal of oneM2M is to develop technical specifications which address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide.
More information about oneM2M may be found at: http//www.oneM2M.org
Copyright Notification
-© 2018, oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC).
+© 2019, oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC).
All rights reserved.
The copyright extends to reproduction in all media.
@@ -35,7 +35,6 @@ The information provided in this document is directed solely to professionals wh
NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS TECHNICALLY ACCURATE OR SUFFICIENT OR CONFORMS TO ANY STATUTE, GOVERNMENTAL RULE OR REGULATION, AND FURTHER, NO REPRESENTATION OR WARRANTY IS MADE OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR AGAINST INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS. NO oneM2M PARTNER TYPE 1 SHALL BE LIABLE, BEYOND THE AMOUNT OF ANY SUM RECEIVED IN PAYMENT BY THAT PARTNER FOR THIS DOCUMENT, WITH RESPECT TO ANY CLAIM, AND IN NO EVENT SHALL oneM2M BE LIABLE FOR LOST PROFITS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES. oneM2M EXPRESSLY ADVISES ANY AND ALL USE OF OR RELIANCE UPON THIS INFORMATION PROVIDED IN THIS DOCUMENT IS AT THE RISK OF THE USER.
# Contents
-[toc]
1 Scope 4
2 References 4
@@ -44,17 +43,19 @@ NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS TECHNICALLY ACCURA
2.2 Informative references 4
-3 Definitions and abbreviations 5
+3 Definition of terms, symbols and abbreviations 5
-3.1 Definitions 5
+3.1 Terms 5
+
+3.2 Symbols 5
3.2 Abbreviations 5
-4 Conventions 5
+4 Conventions 6
-5 Abstract Test Method (ATM) 5
+5 Abstract Test Method (ATM) 6
-5.1 Abstract protocol tester 5
+5.1 Abstract protocol tester 6
5.2 Test Configuration 6
@@ -88,45 +89,55 @@ NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS TECHNICALLY ACCURA
5.4.4 infoPort 14
-6 Untestable Test Purposes 14
+5.5 Test components 14
+
+5.5.1 Tester 14
+
+5.5.2 AeSimu 15
+
+5.5.3 CseSimu 15
-7 ATS Conventions 14
+5.6 Test strategy 16
-7.0 Introduction 14
+6 Untestable Test Purposes 17
-7.1 Testing conventions 15
+7 ATS Conventions 17
-7.1.1 Testing states 15
+7.0 Introduction 17
-7.1.1.1 Initial state 15
+7.1 Testing conventions 17
-7.1.1.2 Final state 15
+7.1.1 Testing states 17
-7.2 Naming conventions 15
+7.1.1.1 Initial state 17
-7.2.1 General guidelines 15
+7.1.1.2 Final state 17
-7.2.2 oneM2M specific TTCN-3 naming conventions 16
+7.2 Naming conventions 17
-7.2.3 Usage of Log statements 17
+7.2.1 General guidelines 17
-7.2.4 Test Case (TC) identifier 17
+7.2.2 oneM2M specific TTCN-3 naming conventions 19
-7.3 IXIT 17
+7.2.3 Usage of Log statements 19
-8 TTCN-3 Verifications 19
+7.2.4 Test Case (TC) identifier 20
-Annex A (normative): TTCN-3 library modules 20
+7.3 IXIT 20
-A.0 Introduction 20
+8 TTCN-3 Verifications 22
-Annex B (informative): Bibliography 21
+Annex A (normative): TTCN-3 library modules 23
-History 22
+A.1 Electronic annex, zip file with TTCN-3 code 23
+
+Annex B (informative): Bibliography 24
+
+History 25
# <br/>1 Scope
-The present document contains the Abstract Test Suite (ATS) for oneM2M as defined in oneM2M TS-0001 [1] and oneM2M TS-0004 [2] in compliance with the relevant requirements and in accordance with the relevant guidance given in ISO/IEC 96467 [6].
+The present document contains the Abstract Test Suite (ATS) for oneM2M as defined in oneM2M TS-0001 [1] and oneM2M TS-0004 [2] in compliance with the relevant requirements and in accordance with the relevant guidance given in ISO/IEC 96467 [5].
The objective of the present document is to provide a basis for conformance tests for oneM2M products giving a high probability of interoperability between different manufacturers' equipment.
The ISO standard for the methodology of conformance testing (ISO/IEC 96461 [3] and ISO/IEC 96462 [4]) as well as oneM2M TS-0015 Testing Framework [i.2] are used as a basis for the test methodology.
@@ -136,7 +147,7 @@ The ISO standard for the methodology of conformance testing (ISO/IEC 96461
References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
The following referenced documents are necessary for the application of the present document.
-`[1] oneM2M TS-0001: "Functional architecture".`
+`[1] oneM2M TS-0001: "Functional Architecture".`
`[2] oneM2M TS-0004: "Service Layer Core Protocol".`
@@ -144,17 +155,15 @@ The following referenced documents are necessary for the application of the pres
`[4] ISO/IEC 9646-2 (1994): "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 2: Abstract Test Suite specification".`
-`[6] ISO/IEC 9646-7 (1995): "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 7: Implementation Conformance Statements".`
+`[5] ISO/IEC 9646-7 (1995): "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 7: Implementation Conformance Statements".`
-`[7] 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".`
+`[6] 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".`
-`[9] oneM2M TS-0018: "Test Suite Structure and Test Purposes".`
+`[7] oneM2M TS-0018: "Test Suite Structure and Test Purposes".`
## 2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of 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 they assist the user with regard to a particular subject area.
`[i.1] oneM2M Drafting Rules.`
@@ -164,16 +173,19 @@ The following referenced documents are not necessary for the application of the
`[i.3] oneM2M TS-0025: "Product profiles".`
-# 3 Definitions and abbreviations
+# 3 Definition of terms, symbols and abbreviations
-## 3.1 Definitions
+## 3.1 Terms
-For the purposes of the present document, the terms and definitions given in ISO/IEC 96461 [3], in ISO/IEC 96467 [6] and in oneM2M TS-0015 [i.2] apply.
+For the purposes of the present document, the terms given in ISO/IEC 96461 [3], ISO/IEC 96467 [5] and oneM2M TS-0015 [i.2] apply.
+
+## 3.2 Symbols
+Void.
## 3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
-`AE Application entity`
+`AE Application Entity`
`APT Abstract Protocol Tester`
@@ -191,12 +203,20 @@ For the purposes of the present document, the following abbreviations apply:
`IUT Implementation Under Test`
+`IXIT Implementation eXtra Information for Test`
+
+`JSON JavaScript Object Notation`
+
`MQTT Message Queuing Telemetry Transport`
+`MTC Main Test Component`
+
`PA Platform Adaptor`
`PICS Protocol Implementation Conformance Statement`
+`PTC Paralell Test Component`
+
`PX PiXit`
`SA System Adaptor`
@@ -205,18 +225,25 @@ For the purposes of the present document, the following abbreviations apply:
`TC Test Case`
+`TCP Transmission Control Protocol`
+
`TP Test Purposes`
+`TS Test System`
+
`TSS Test Suite Structure`
`TTCN Tree and Tabular Combined Notation`
+`UDP User Datagram Protocol`
+
`UT Upper Tester`
+`XML eXtensible Markup Language`
-# 4 Conventions
+# 4 Conventions
-The key words "Shall", "Shall not", "May", "Need not", "Should", "Should not" in this document are to be interpreted as described in the oneM2M Drafting Rules [i.1]
+The key words "Shall", "Shall not", "May", "Need not", "Should", "Should not" in this document are to be interpreted as described in the oneM2M Drafting Rules [i.1].
# 5 Abstract Test Method (ATM)
@@ -226,57 +253,56 @@ APTs used by the oneM2M test suite are described in figure 5.1-1. The test syste
 
-
+ 
**Figure 5.1-1: Abstract protocol testers - oneM2M**
-As figure 5.1-1 illustrates, the corresponding ATS needs to use lower layers to establish a proper connection to the system under test (SUT) over a physical link (Lower layers link). Three different lower layers have been specified corresponding to the binding protocols considered in oneM2M: HTTP, CoAP and MQTT
+As figure 5.1-1 illustrates, the corresponding ATS needs to use lower layers to establish a proper connection to the system under test (SUT) over a physical link (Lower layers link). Four different lower layers have been specified corresponding to the binding protocols considered in oneM2M: HTTP, CoAP, WebSocket and MQTT.
## 5.2 Test Configuration
### 5.2.1 AE Test Configuration
Test configurations are defined to test different entities such as CSE and AE, etc.
-Figure X shows a AE test configuration which is mapped to CF03 in clause 6.3.3.3 in oneM2M TS-0015 [i.2] and aligns with conformance test system architecture in clause 6.3.3.2 in oneM2M TS-0015 [i.2].
+Figure 5.2.1-1 shows a AE test configuration which is mapped to CF03 in clause 6.3.3.3 in oneM2M TS0015 [i.2] and aligns with conformance test system architecture in clause 6.3.3.2 in oneM2M TS-0015 [i.2].
The TTCN-3 Test Component in Test System sends triggering actions or behaviour to the Upper Tester Application of SUT through upper tester transport link Ut while the IUT sends/receives oneM2M service primitives through Mca to/from CSE in Test System.
-
+
**Figure 5.2.1-1: AE test configuration**
## 5.3 Test architecture
-The approach for the implementation of an Abstract Protocol Tester selected in oneM2M follows the recommendation of the oneM2M Testing Framework [i.2] where the TTCN-3 language and its architecture are recommended.
-Following this recommendation the oneM2M tester architecture comprises a non-platform dependent Test Suite, and a platform dependent part.
+The approach for the implementation of an Abstract Protocol Tester selected in oneM2M follows the recommendation of the oneM2M Testing Framework oneM2M TS-0015 [i.2] where the TTCN-3 language and its architecture are recommended.
+Following this recommendation the oneM2M tester architecture comprises a non-platform dependent Test Suite, and a platform dependent part.
-
-
-> NOTE: However, it can be implemented in a semi-independent manner, which will minimize the dependency to those elements.
+
+> NOTE: However, it can be implemented in a semi-independent manner, which will minimize the dependency to those elements.
>
**Figure 5.3-1: High level oneM2M Test Architecture**
-- oneM2M TTCN-3 Abstract Test Suite: the test suite is platform independent, and it is the cornerstone of the architecture. It allows a complete decoupling between the test suite and the rest of the test system. The test suite is composed of a complete set of test cases covering oneM2M requirements specified by [1] and [2].
-- oneM2M System Adaptor: this is the platform dependent part that includes adaptors and codecs (out of the scope of this document). This part of the architecture definition depends on the specific platform (e.g. Windows or Linux) and test tool on which the tester is going to run.
+- oneM2M TTCN-3 Abstract Test Suite: the test suite is platform independent, and it is the cornerstone of the architecture. It allows a complete decoupling between the test suite and the rest of the test system. The test suite is composed of a complete set of test cases covering oneM2M requirements specified by oneM2M TS0001 [1] and oneM2M TS-0004 [2].
+- oneM2M System Adaptor: this is the platform dependent part that includes adaptors and codecs (out of the scope of the present document). This part of the architecture definition depends on the specific platform (e.g. Windows or Linux) and test tool on which the tester is going to run.
Figure 5.3-2 shows the oneM2M TTCN-3 test architecture design used for the oneM2M ATS. The Test Suite needs to interact with the System Adaptor to implement the collection of TTCN-3 test cases that are intended to be used to test the oneM2M IUTs.
-The oneM2M TTCN-3 test cases implement the test algorithms specified in the TSS&TP document [9], including verdict logic that allows pass/fail diagnosis.
+The oneM2M TTCN-3 test cases implement the test algorithms specified in the TSS&TP document oneM2M TS0018 [7], including verdict logic that allows pass/fail diagnosis.
The test algorithms use the interfaces defined in [1] and [2] (mca, mcc) in order to:
-1. control the test event to be sent towards the IUT; and
-1. observe the test events received from the IUT.
+1. control the test event to be sent towards the IUT; and
+1. observe the test events received from the IUT.
In TTCN-3 these two interfaces have been implemented through a set of logical TTCN-3 ports (mcaPort and mcaPortIn for mca interface, and mccPort and mccPortIn for mcc interface) which allows oneM2M message primitives exchange with the IUT.
-
+
**Figure 5.3-2: oneM2M Test Architecture**
-The oneM2M primitive messages have been mapped into TTCN-3 structure. Through this mapping, the TTCN-3 is able to build and send these messages, as well as receive them via the ports defined above.
-Additionally, the test cases are able to control and configure the test platform through a dedicated port called acPort while port utPort enables oneM2M TTCN-3 Test Component module to trigger specific action or behaviour on IUT. TTCN-3 Test Components can also exchange information through a dedicated port called infoPort.
+The oneM2M primitive messages have been mapped into TTCN-3 structure. Through this mapping, the TTCN-3 is able to build and send these messages, as well as receive them via the ports defined above.
+Additionally, the test cases are able to control and configure the test platform through a dedicated port called acPort while port utPort enables oneM2M TTCN-3 Test Component module to trigger specific action or behaviour on IUT. TTCN3 Test Components can also exchange information through a dedicated port called infoPort.
To build up a tester, the test platform needs to be also developed (out of scope). This test platform is composed of three adaptation layers:
- PA (Platform Adaptor) layer functionality implements the communication between the TTCN-3 modules and external elements that constitute the test tool such as timers and external functions. The External functions are a powerful resources supported by TTCN-3 language. An External function is a function declared at the TTCN-3 level but implemented at the native level.
@@ -304,7 +330,7 @@ The oneM2M ATS implements the following ports:
These ports are used to send and receive the following message sets:
- Request Primitives messages in accordance with oneM2M TS-0004 [2].
-- Response Primitives messages in accordance with [2].
+- Response Primitives messages in accordance with oneM2M TS-0004 [2].
Two primitives are currently defined for these ports indicated as table 5.4.1-1:
@@ -341,7 +367,7 @@ Both primitives contain another parameters that permits to dynamically configure
### 5.4.2 utPort
#### 5.4.2.0 Introduction
-The utPort is included in the oneM2M ATS in order to be able to stimulate the IUT and receive extra information from IUT upper layers. For instance, the utPort can be applied to automate AE testing shown as clause 5.4.2.1.
+The utPort is included in the oneM2M ATS in order to be able to stimulate the IUT and receive extra information from IUT upper layers. For instance, the utPort can be applied to automate AE testing shown as clause 5.4.2.1.
#### 5.4.2.1 Usage for Automated AE Testing
The utPort is in charge of the communication between TTCN-3 Test Component module in Test System and the Upper Tester Application in SUT.
@@ -357,7 +383,7 @@ oneM2M service Primitive defined for utPort is listed as follows:
The Upper Tester Application in SUT can be implemented as an embedded source code. An example for implementation of automated AE test for Registration is shown as figure 5.4.2.1-1.
-
+
**Figure 5.4.2.1-1: Example of automated AE test using Ut interface**
@@ -371,36 +397,35 @@ The upper tester triggering message type maps to particular message formats for
**Table 5.4.2.2.1-1: Mapping of TTCN-3 Primitives to oneM2M Service Primitives**
-|Upper TesterControl Message Type |TTCN-3 Primitives |Direction |Direction |
+|Upper Tester Control Message Type |TTCN-3 Primitives |Direction |Direction |
|-|-|-|-|
-|Upper TesterControl Message Type |TTCN-3 Primitives |TS |UT |
+|Upper Tester Control Message Type |TTCN-3 Primitives |TS |UT |
|Trigger |UtTrigger Primitive | | |
|Trigger Acknowledgement |UtTriggerAck Primitive | | |
-##### 5.4.2.2.2 UtTrigger and UtTriggerAck Primitives
-The UtTrigger primitive is initialized by the Test System to send triggering message to the target IUT as depicted in figure 5.4.2.2.2-1. The IUT will send acknowledgement message back to the Test System using UtTriggerAck primitive if trigger message is successfully transported to the IUT. Then IUT starts interaction with Test System through oneM2M request and response primitives.
+##### 5.4.2.2.2 UtTrigger and UtTriggerAck Primitives
+The UtTrigger primitive is initialized by the Test System to send triggering message to the target IUT as depicted in figure 5.4.2.2.2-1. The IUT will send acknowledgement message back to the Test System using UtTriggerAck primitive if trigger message is successfully transported to the IUT. Then IUT starts interaction with Test System through oneM2M request and response primitives.
-
+
**Figure 5.4.2.2.2-1: Trigger message flow**
-Table 5.4.2.2.2-2 defines UtTrigger and UtTriggerAck primitives including oneM2M data types to which are mapped as well as examples to show how to implement UtTrigger and UtTriggerAck primitives.
-
+Table 5.4.2.2.2-1 defines UtTrigger and UtTriggerAck primitives including oneM2M data types to which are mapped as well as examples to show how to implement UtTrigger and UtTriggerAck primitives.
**Table 5.4.2.2.2-1: UtTrigger and UtTriggerAck Primitive**
-|Ut Control Primitive |Mapping to oneM2M data types |Description |Reference |Triggering Message |HTTP message |
+|Ut Control Primitive |Mapping to oneM2M data types |Description |Reference |Triggering Message |HTTP message |
|-|-|-|-|-|-|
-|UtTrigger Primitive |request <br>Primitive |ONLY essential parameters included for certain test case<br><br>See note 1 |TS-0004 [2] |Example A:<br>If the test objective is to test "Test System triggers IUT to execute a test case for creation of \<AE> with labels attribute under a CSEBase resource", then the triggering message would be serialized as following. |Example A:<br>If the test objective is to test "Test System triggers IUT to execute a test case for creation of \<AE> with labels attribute under a CSEBase resource", then the triggering message would be serialized as following. |
-|UtTrigger Primitive |request <br>Primitive |ONLY essential parameters included for certain test case<br><br>See note 1 |TS-0004 [2] |Request<br>{ <br>"m2m:rqp" :{<br> "op": 1, //indicate CREATE operation<br> "ty": 2, //indicate AE resource type<br> "to": {TEST_SYSTEM_ADDRESS},<br> "pc": {<br> "m2m:ae": {<br> "lbl":"UNINITIALIZED" //indicate that attribute labels needs to be included<br> }<br> }<br>}<br>} |Request<br>POST /{SUT_UT_APPLICATION_URL} HTTP/1.1<br>Host: {SUT_IP_ADDRESS:PORT}<br>Content-Length: {PAYLOAD_LENGTH}<br>Content-Type: application/json<br><br>{ <br>"m2m:rqp" :{<br> "op": 1, //indicate CREATE operation<br> "ty": 2, //indicate AE resource type<br> "to": {TEST_SYSTEM_ADDRESS},<br> "pc": {<br> "m2m:ae": {<br> "lbl":"UNINITIALIZED" //indicate that attribute labels needs to be included<br> }<br> }<br>}<br>} |
-|UtTrigger Primitive |request <br>Primitive |ONLY essential parameters included for certain test case<br><br>See note 1 |TS-0004 [2] |Example B: <br>If the test objective is to test "Test System triggers IUT to execute a test case for delete of a \<AE> resource.", then the triggering message would be serialized as following. |Example B: <br>If the test objective is to test "Test System triggers IUT to execute a test case for delete of a \<AE> resource.", then the triggering message would be serialized as following. |
-|UtTrigger Primitive |request <br>Primitive |ONLY essential parameters included for certain test case<br><br>See note 1 |TS-0004 [2] |Request<br>{ <br>"m2m:rqp" :{<br> "op": 4, //indicate DELETE operation<br> "to": {TARGET_AE_RESOURCE_ADDRESS} //indicate Target AE resource address<br>}<br>} |Request<br>POST /{SUT_UT_APPLICATION_URL} HTTP/1.1<br>Host: {SUT_IP_ADDRESS:PORT}<br>Content-Length: {PAYLOAD_LENGTH}<br>Content-Type: application/json<br><br>{ <br>"m2m:rqp" :{<br> "op": 4, //indicate DELETE operation<br> "to": {TARGET_AE_RESOURCE_ADDRESS} //indicate Target AE resource address<br>}<br>} |
-|UtTriggerAck Primitive |responsePrimitive |ONLY responseStatusCode attribute included<br><br>See note 2 |TS-0004 [2] |Response<br>{<br> "m2m:rsp": {<br> "rsc": 2000<br> }<br><br>}<br>For any triggering response, it only contains a response status code, and the response status code for the triggering operation can only be set to either 2000 (OK) or 4000 (BAD_REQUEST) according to the rules for triggering operations. |Response<br>HTTP/1.1 200 OK<br>X-M2M-RSC: 2000 |
-|NOTE 1: Additional rules defined in table 5.4.2.2.2-3 are also applied. <br>NOTE 2: Attribute response status code is defined at table 5.4.2.2.2-3. |NOTE 1: Additional rules defined in table 5.4.2.2.2-3 are also applied. <br>NOTE 2: Attribute response status code is defined at table 5.4.2.2.2-3. |NOTE 1: Additional rules defined in table 5.4.2.2.2-3 are also applied. <br>NOTE 2: Attribute response status code is defined at table 5.4.2.2.2-3. |NOTE 1: Additional rules defined in table 5.4.2.2.2-3 are also applied. <br>NOTE 2: Attribute response status code is defined at table 5.4.2.2.2-3. |NOTE 1: Additional rules defined in table 5.4.2.2.2-3 are also applied. <br>NOTE 2: Attribute response status code is defined at table 5.4.2.2.2-3. |NOTE 1: Additional rules defined in table 5.4.2.2.2-3 are also applied. <br>NOTE 2: Attribute response status code is defined at table 5.4.2.2.2-3. |
+|UtTrigger Primitive |requestPrimitive |ONLY essential parameters included for certain test case<br><br>See note 1 |oneM2M<br>TS-0004 [2] |EXAMPLE 1:<br>If the test objective is to test "Test System triggers IUT to execute a test case for creation of \<AE> with labels attribute under a CSEBase resource", then the triggering message would be serialized as following. |EXAMPLE 1:<br>If the test objective is to test "Test System triggers IUT to execute a test case for creation of \<AE> with labels attribute under a CSEBase resource", then the triggering message would be serialized as following. |
+|UtTrigger Primitive |requestPrimitive |ONLY essential parameters included for certain test case<br><br>See note 1 |oneM2M<br>TS-0004 [2] |Request<br>{ <br>"m2m:rqp" :{<br> "op": 1, //indicate CREATE operation<br> "ty": 2, //indicate AE resource type<br> "to": {TEST_SYSTEM_ADDRESS},<br> "pc": {<br> "m2m:ae": {<br> "lbl":"UNINITIALIZED" //indicate that attribute labels needs to be included<br> },<br> }<br> "rvi": "2a"<br>}<br>} |Request<br>POST /{SUT_UT_APPLICATION_URL} HTTP/1.1<br>Host: {SUT_IP_ADDRESS:PORT}<br>Content-Length: {PAYLOAD_LENGTH}<br>Content-Type: application/json<br><br>{ <br>"m2m:rqp" :{<br> "op": 1, //indicate CREATE operation<br> "ty": 2, //indicate AE resource type<br> "to": {TEST_SYSTEM_ADDRESS},<br> "pc": {<br> "m2m:ae": {<br> "lbl":"UNINITIALIZED" //indicate that attribute labels needs to be included<br> }<br> },<br> "rvi": "2a"<br>}<br>} |
+|UtTrigger Primitive |requestPrimitive |ONLY essential parameters included for certain test case<br><br>See note 1 |oneM2M<br>TS-0004 [2] |EXAMPLE 2: <br>If the test objective is to test "Test System triggers IUT to execute a test case for delete of a \<AE> resource.", then the triggering message would be serialized as following. |EXAMPLE 2: <br>If the test objective is to test "Test System triggers IUT to execute a test case for delete of a \<AE> resource.", then the triggering message would be serialized as following. |
+|UtTrigger Primitive |requestPrimitive |ONLY essential parameters included for certain test case<br><br>See note 1 |oneM2M<br>TS-0004 [2] |Request<br>{ <br>"m2m:rqp" :{<br> "op": 4, //indicate DELETE operation<br> "to": {TARGET_AE_RESOURCE_ADDRESS}, //indicate Target AE resource address<br> "rvi": "2a"<br>}<br>} |Request<br>POST /{SUT_UT_APPLICATION_URL} HTTP/1.1<br>Host: {SUT_IP_ADDRESS:PORT}<br>Content-Length: {PAYLOAD_LENGTH}<br>Content-Type: application/json<br><br>{ <br>"m2m:rqp" :{<br> "op": 4, //indicate DELETE operation<br> "to": {TARGET_AE_RESOURCE_ADDRESS}, //indicate Target AE resource address<br> "rvi": "2a"<br>}<br>} |
+|UtTriggerAck Primitive |responsePrimitive |ONLY responseStatusCode attribute included<br><br>See note 2 |oneM2M TS-0004 [2] |Response<br>{<br> "m2m:rsp": {<br> "rsc": 2000<br> }<br><br>}<br>For any triggering response, it only contains a response status code, and the response status code for the triggering operation can only be set to either 2000 (OK) or 4000 (BAD_REQUEST) according to the rules for triggering operations. |Response<br>HTTP/1.1 200 OK<br>X-M2M-RSC: 2000 |
+|NOTE 1: Additional rules defined in table 5.4.2.2.2-3 are also applied.<br>NOTE 2: Attribute response status code is defined at table 5.4.2.2.2-3. |NOTE 1: Additional rules defined in table 5.4.2.2.2-3 are also applied.<br>NOTE 2: Attribute response status code is defined at table 5.4.2.2.2-3. |NOTE 1: Additional rules defined in table 5.4.2.2.2-3 are also applied.<br>NOTE 2: Attribute response status code is defined at table 5.4.2.2.2-3. |NOTE 1: Additional rules defined in table 5.4.2.2.2-3 are also applied.<br>NOTE 2: Attribute response status code is defined at table 5.4.2.2.2-3. |NOTE 1: Additional rules defined in table 5.4.2.2.2-3 are also applied.<br>NOTE 2: Attribute response status code is defined at table 5.4.2.2.2-3. |NOTE 1: Additional rules defined in table 5.4.2.2.2-3 are also applied.<br>NOTE 2: Attribute response status code is defined at table 5.4.2.2.2-3. |
@@ -409,6 +434,10 @@ Table 5.4.2.2.2-2 defines UtTrigger and UtTriggerAck primitives including oneM2M
**Table 5.4.2.2.2-2: Rules for defining UtTrigger and UtTriggerAck primitives**
1. UtTrigger primitive is represented in requestPrimitive serialized in JSON format.
+1. UtTrigger primitive shall be interpreted as follows:
+ - Any attribute/parameter containing a value shall be present and equal in the triggered request primitive.
+ - Any attribute/parameter containing "UNINITIALIZED" value shall be present in the triggered request primitive.
+ - Any other attribute/parameter shall comply with oneM2M TS-0004 [2].
1. Parameters within UtTrigger are listed as following:
- operation: (mandatory)operation type that IUT is triggered to perform.
- resourceType: (optional)resource type of a target resource against which IUT is triggered to perform certain operation
@@ -417,27 +446,126 @@ Table 5.4.2.2.2-2 defines UtTrigger and UtTriggerAck primitives including oneM2M
+
**Table 5.4.2.2.2-3: Definition of ResponseStatusCode for UtTriggerAck primitive**
|Response Status Code Description |Response Status Code Value |Interpretation |
|-|-|-|
|OK |2000 |The SUT receives successfully the triggering message from Test System |
|BAD_REQUEST |4000 |The SUT does not interpret correctly the UtTrigger primitive |
-|NOTE: Only above two response status codes are allowed to use in UtTriggerAck primitive. |NOTE: Only above two response status codes are allowed to use in UtTriggerAck primitive. |NOTE: Only above two response status codes are allowed to use in UtTriggerAck primitive. |
+|NOTE: Only above two response status codes are allowed to use in UtTriggerAck primitive. |NOTE: Only above two response status codes are allowed to use in UtTriggerAck primitive. |NOTE: Only above two response status codes are allowed to use in UtTriggerAck primitive. |
##### 5.4.2.2.3 Control Communication Protocol
-Protocol used for proceeding communications between TS and Upper Tester Application is designated to the Hypertext Transfer Protocol (HTTP) protocol owning it is an application protocol that is widely supported by most all IoT devices and various intrinsic features such as persistent connection, ease of programming, flexibility, etc.
+Protocol used for proceeding communications between Test System and Upper Tester Application is designated to the Hypertext Transfer Protocol (HTTP) protocol owning it is an application protocol that is widely supported by most all IoT devices and various intrinsic features such as persistent connection, ease of programming, flexibility, etc.
##### 5.4.2.2.4 Control Message Serialization
Control commands that are wrapped within a request body of HTTP message shall be serialized into JavaScript Object Notation (JSON) because it is very lightweight and easy to parse and generate for machines.
### 5.4.3 acPort
-The acPort is included in the oneM2M ATS in order to be able to control and configure the test adaptor for specific cases.
+The acPort is included in the oneM2M ATS in order to be able to control and configure the test adaptor for specific cases.
### 5.4.4 infoPort
-The infoPort is included in the oneM2M ATS in order for the TTCN-3 test components to be able to exchange information such as last response primitives or request primitives received by a component, retrieved primitive contents.
+The infoPort is included in the oneM2M ATS in order for the TTCN-3 test components to be able to exchange information such as last response primitives or request primitives received by a component, retrieved primitive contents.
+
+## 5.5 Test components
+
+### 5.5.1 Tester
+The Tester test component includes a set of ports, timers and variables that are common to the other defined components which are described in table 5.5.1-1.
+
+**Table 5.5.1-1: Tester component elements**
+
+|Name |Instance type |Element type |Description |
+|-|-|-|-|
+|acPort |port |AdapterControlPort |Port that communicates with the adapter for sending configuration parameters |
+|infoPort |port |InfoPort |Port between test components for exchanging information |
+|utPort |port |UpperTesterPort |Port that communicates with the UT Application for triggering actions on the IUT |
+|tc_ac |timer |N/A |Timer for the reception of a message |
+|tc_wait |timer |N/A |Timer for the reaction of the IUT to an upper tester primitive |
+|tc_done |Timer |N/A |Timer for waiting completion of a component behaviour |
+|vc_config |variable |Configurations |Configuration being used for the given test case |
+|vc_testSystemRole |variable |TestSystemRole |Role of the test component |
+|vc_componentRegistered |variable |boolean |Flag to indicate that AeSimu/CseSimu is registered to IUT |
+|vc_resourcesList |variable |MyResourcesList |List of all resources created by the test system on the IUT |
+|vc_resourcesIndexToBeDeleted |variable |IntegerList |List of indexes of resources created by the test system on the IUT that need to be deleted |
+|vc_acpIndex |variable |integer |Index of accessControlPolicy resource used by the test system by default (when required) |
+|vc_request |variable |MsgIn |Latest request primitive received/sent |
+|vc_response |variable |MsgIn |Latest response primitive received/sent |
+|vc_aeSimu |variable |default |Reference to the default behaviour for an AeSimu component |
+|vc_cseSimu |variable |default |Reference to the default behaviour for an CseSimu component |
+|vc_primitiveContentRetrievedResource |variable |PrimitiveContent |Latest content of a RETRIEVE operation |
+|vc_myInterfaces |variable |Interfaces |Parameters for the ports of the given component:<br>Port (mcaPort, mcaPortIn, mccPort, mccPortIn)<br>Host (SUT IP address :port)<br>Protocol binding<br>Serialization |
+
+
+Note that vc_aeSimu and vc_cseSimu are not common to the other defined test components, but those variables are required in Tester for the correct activation/deactivation of default behaviours.
+
+### 5.5.2 AeSimu
+The AeSimu test component extends the Tester component by adding elements specific to an AE entity. Table 5.5.2-1 summarizes those elements.
+
+**Table 5.5.2-1: AeSimu component elements**
+
+|Name |Instance type |Element type |Description |
+|-|-|-|-|
+|mcaPort |port |OneM2MPort |Port that implements the mca interface when test system is the client (sending requests) |
+|mcaPortIn |port |OneM2MPort |Port that implements the mca interface when test system is the server (receiving requests) |
+|vc_ae2 |test component |AeSimu |Reference to the AE2 component when required |
+|vc_cse1 |test component |CseSimu |Reference to the CSE1 component when CF02 is used |
+|vc_auxiliaryAe2Up |variable |boolean |Flag to indicate that AE2 component has been started |
+|vc_aeIndex |variable |integer |Index of the AE resource in vc_resourcesList created by the AeSimu component |
+
+
+
+### 5.5.3 CseSimu
+The CseSimu test component extends the Tester component by adding elements specific to an CSE entity. Table 5.5.3-1 summarizes those elements.
+
+**Table 5.5.3-1: CseSimu component elements**
+
+|Name |Instance type |Element type |Description |
+|-|-|-|-|
+|mcaPort |port |OneM2MPort |Port that implements the mca interface when test system is the client (sending requests) |
+|mcaPortIn |port |OneM2MPort |Port that implements the mca interface when test system is the server (receiving requests) |
+|mccPort |port |OneM2MPort |Port that implements the mcc interface when test system is the client (sending requests) |
+|mccPortIn |port |OneM2MPort |Port that implements the mcc interface when test system is the server (receiving requests) |
+|vc_ae1 |test component |AeSimu |Reference to the AE1 component when CF02 (CseSimu as master) is used |
+|vc_localResourcesList |variable |MyResourcesList |List of all resources created by the IUT on the test system |
+|vc_localRemoteCseIndex |variable |integer |Index of the remoteCSE resource in vc_localResourcesList representing the IUT (CSE) |
+|vc_remoteCseIndex |variable |integer |Index of the remoteCSE resource in vc_resourcesList representing the CseSimu component |
+|vc_cSEBaseIndex |variable |integer |Index of the CSEBase resource in vc_localResourcesList of the CseSimu component |
+|vc_cseType |variable |CseTypeID |CSE type of the test system (default is MN) |
+
+
+
+## 5.6 Test strategy
+This clause introduces the test strategy being used for the TTCN-3 test cases. The chosen strategy permits to have a clear structure of the code that facilitates an easy navigation throw the different test steps.
+The use of the TTCN-3 MTC and PTC(s) is as depicted in figure 5.6-1.
+
+
+
+**Figure 5.6-1: Use of TTCN-3 components**
+
+
+At the start of the test case execution, the MTC is created. Then, the MTC executes the following steps:
+
+- Step 1) initialization of the master PTC.
+- Step 2) initialization of some parameters if required for the permutation test cases.
+- Step 3) running of the appropriate function on the master PTC. The function run on the master PTC implements a given Test Purpose. Such function follows a code structure as indicated here below:
+
+ - Local Variables, declaration of local variables.
+ - Test Control, checking IUT capability parameters required for the proper execution of the test.
+ - Test Component Configuration, that initializes the given test component and other test components acting as slave PTC(s) as required by a given configuration.
+ - Test adapter configuration, that configures the test adapter throw the acPort if required.
+ - Preamble, that implements the necessary test steps as described in the Initial conditions of a Test Purpose. It may also implement additional test steps which are required for the correct execution of the test.
+ - Test body, that implements the test steps as described in the Expected behaviour of a Test Purpose.
+ - Postamble, that implements the necessary test steps to bring the IUT back to the initial state.
+ - Tear down, that finalizes properly the TTCN-3 ports used by the different test components depending on the configuration.
+
+While master PTC follows the test structure described above, slave PTC(s) run only certain procedures, usually one by one, as mandated by the master PTC.
+A procedure usually implements a oneM2M request-response exchange between a given PTC and the IUT, although it can implement any other specific action (sending or reception of a message, several request-response exchanges, etc.).
+
+- Step 4) checking of some parameters if required for the permutation test cases.
+
+This test strategy may slightly vary for certain cases where specific requirements need to be fulfilled.
# 6 Untestable Test Purposes
Void.
@@ -463,11 +591,11 @@ As necessary, further actions may be included in the f_postamble functions.
## 7.2 Naming conventions
### 7.2.1 General guidelines
-This test suite follows the naming convention guidelines provided in [i.2].
+This test suite follows the naming convention guidelines provided in oneM2M TS-0015 [i.2].
The naming convention is based on the following underlying principles:
- in most cases, identifiers should be prefixed with a short alphabetic string (specified in table 7.2.1-1) indicating the type of TTCN3 element it represents;
-- suffixes should not be used except in those specific cases identified in table 7.2.1-1.
+- suffixes should not be used except in those specific cases identified in table 7.2.1-1;
- prefixes and suffixes should be separated from the body of the identifier with an underscore ("_");
`EXAMPLE 1: c_sixteen, t_wait.`
@@ -479,7 +607,7 @@ The naming convention is based on the following underlying principles:
Table 7.2.1-1 specifies the naming guidelines for each element of the TTCN3 language indicating the recommended prefix, suffixes (if any) and capitalization.
-**Table7.2.1-1: TTCN-3 generic naming conventions**
+**Table 7.2.1-1: TTCN-3 generic naming conventions**
|Language element |Naming convention |Prefix |Example identifier |
|-|-|-|-|
@@ -510,7 +638,7 @@ Table
### 7.2.2 oneM2M specific TTCN-3 naming conventions
-Next to such general naming conventions, table 7.2.2-1 shows specific naming conventions that apply to the oneM2M TTCN-3 ATS.
+Next to such general naming conventions, table 7.2.2-1 shows specific naming conventions that apply to the oneM2M TTCN-3 ATS.
**Table 7.2.2-1: oneM2M specific TTCN-3 naming conventions**
@@ -539,7 +667,7 @@ All TTCN-3 log statements use the following format using the same order:
Furthermore, the following rules are applied too:
-- All TTCN-3 setverdict statements are combined (as defined in TTCN-3 - ETSI ES 201 873-1 [7]) with a log statement following the same above rules (see example 2).
+- All TTCN-3 setverdict statements are combined (as defined in TTCN-3 - ETSI ES 201 873-1 [6]) with a log statement following the same above rules (see example 2).
`EXAMPLE 2: setverdict(pass, "TC_ONEM2M_CSE_DMR_CRE_001: Received correct message");`
@@ -567,7 +695,7 @@ Furthermore, the following rules are applied too:
-`EXAMPLE: TP identifier: TP/oneM2M/CSE/DMR/CRE/001<br/>TC identifier: TC_ONEM2M_CSE_DMR_CRE_001`
+`EXAMPLE: TP identifier: TP/oneM2M/CSE/DMR/CRE/001<br/>TC identifier: TC_ONEM2M_CSE_DMR_CRE_001.`
## 7.3 IXIT
@@ -577,55 +705,54 @@ The following parameters are used by the oneM2M ATS for the correct execution of
|GROUP |IXIT NAME |DESCRIPTION |DEFAULT VALUE |
|-|-|-|-|
-|IutParameters |PX_MN_CSE |MN-CSE |true |
-|IutParameters |PX_IN_CSE |IN-CSE |false |
+|IutParameters |PX_IN_CSE |MN-CSE |true |
+|IutParameters |PX_MN_CSE |IN-CSE |false |
+|IutParameters |PX_ASN_CSE |ASN-CSE |false |
|IutParameters |PX_SUT_ADDRESS |SUT address |"127.0.0.1:8080" |
|IutParameters |PX_UT_IMPLEMENTED |Upper Tester implemented |false |
|IutParameters |PX_CSE_NAME |IUT CSE Name |"cseName" |
-|IutParameters |PX_CSE_ID |IUT CSE-ID with SP-relative-CSE-ID format (relative) according to one M2M TS-0001 [1], table 7.2-1 |"/cseId" |
-|IutParameters |PX_CSE_RESOURCE_ID |IUT CSE resource ID with Unstructured-CSE-relative-Resource-ID (relative) format according to one M2M<br>TS-0001 [1], table 7.2-1 |"cseResourceId" |
-|IutParameters |PX_SP_ID |IUT M2M-SP-ID with M2M-SP-ID format (absolute) according to one M2M TS-0001 [1], table 7.2-1 Unstructured-CSE-relative -Resource-ID |"//om2m.org" |
-|IutParameters |PX_SUPER_AE_ID |AE-ID with privileges to CREATE at the IUT CSEBase with AE-ID-Stem format (relative) according to one M2M TS-0001 [1], table 7.2-1 |"admin:admin" |
-|IutParameters |PX_SUPER_CSE_ID |CSE-ID with privileges to CREATE at the IUT CSEBase with SP-relative-CSE-ID format (relative) according to one M2M TS-0001 [1], table 7.2-1 |"/admin:admin" |
+|IutParameters |PX_CSE_ID |IUT CSE-ID with SP-relative-CSE-ID format (relative) according to oneM2M TS-0001 [1], table 7.2-1 |"/cseId" |
+|IutParameters |PX_CSE_RESOURCE_ID |IUT CSE resource ID with Unstructured-CSE-relative-Resource-ID (relative) format according to oneM2M<br>TS-0001 [1], table 7.2-1 |"cseResourceId" |
+|IutParameters |PX_SP_ID |IUT M2M-SP-ID with M2M-SP-ID format (absolute) according to oneM2M TS-0001 [1], table 7.2-1 Unstructured-CSE-relative -Resource-ID |"//om2m.org" |
+|IutParameters |PX_SUPER_AE_ID |AE-ID with privileges to CREATE at the IUT CSEBase with AE-ID-Stem format (relative) according to oneM2M TS-0001 [1], table 7.2-1 |"admin:admin" |
+|IutParameters |PX_SUPER_CSE_ID |CSE-ID with privileges to CREATE at the IUT CSEBase with SPrelative-CSE-ID format (relative) according to oneM2M TS-0001 [1], table 7.2-1 |"/admin:admin" |
|IutParameters |PX_ALLOWED_C_AE_IDS | |{"C-AllowedAeId"} |
|IutParameters |PX_NOT_ALLOWED_C_AE_IDS | |{"C-NotAllowedAeId"} |
|IutParameters |PX_ALLOWED_S_AE_IDS | |{"S-AllowedAeId"} |
|IutParameters |PX_NOT_ALLOWED_S_AE_IDS | |{"S-NotAllowedAeId"} |
+|IutParameters |PX_NOT_ALLOWED_APP_ID | |"NotAllowedAppId" |
|IutParameters |PX_ADDRESSING_METHOD |Addressing method |e_hierarchical |
|IutParameters |PX_PRIMITIVE_SCOPE |Primitive scope |e_cseRelative |
-|IutParameters |PX_SERIALIZATION |Serialization |"XML" |
-|IutParameters |PX_PROTOCOL_BINDING |Protocol binding |"HTTP" |
+|IutParameters |PX_WS_PROTOCOL |WebSocket protocol |"oneM2M.R2.0.xml" |
+|IutParameters |PX_REQUEST_URI |WebSocket context |"/" |
+|IutParameters |PX_HOSTING_CSE_ID |Hosting CSE-ID for MQTT |"CSE-ID" |
+|IutParameters |PX_CREDENTIAL_ID |Credential-ID for MQTT |"admin:admin" |
|IutParameters |PX_XML_NAMESPACE |XML Namespace |"m2m=""http://www.onem2m.org/xml/protocols""" |
|IutParameters |PX_ACOR |AccessControlOriginators |{"all"} |
-|TesterParameters |PX_AE1_ADDRESS |AE1 component address |"127.0.0.1:3141" |
-|TesterParameters |PX_AE2_ADDRESS |AE2 component address |"127.0.0.1:3142" |
-|TesterParameters |PX_CSE1_ADDRESS |CSE1 component address |"127.0.0.1:4141" |
-|TesterParameters |PX_CSE1_NAME |Test System CSE1 Name |"CSE1_NAME" |
-|TesterParameters |PX_CSE1_ID |Test System CSE1-ID with SP-relative-CSE-ID format (relative) according to one M2M TS-0001 [1], table 7.2-1 |"/CSE1_ID" |
-|TesterParameters |PX_CSE1_RESOURCE_ID |Test System CSE1 resource ID with Unstructured-CSE-relative-Resource-ID (relative) format according to one M2M TS-0001 [1], table 7.2-1 |"CSE1_RESOURCE_ID" |
-|TesterParameters |PX_CSE1_SRT |CSE1 Supported resource type |{int1, int2, int3, int16} |
-|TesterParameters |PX_SP1_ID |Test System M2M-SP1-ID with M2M-SP-ID format (absolute) according to one M2M TS-0001 [1], table 7.2-1 Unstructured-CSE-relative -Resource-ID |"//onem2m.org" |
-|TesterParameters |PX_AE1_ID_STEM |Test System AE1-ID with AE-ID-Stem format (relative) according to one M2M TS-0001 [1], table 7.2-1 |"" |
-|TesterParameters |PX_AE2_ID_STEM |Test System AE2-ID with AE-ID-Stem format (relative) according to one M2M TS-0001 [1], table 7.2-1 |"" |
-|TesterParameters |PX_APP_ID |Test System APP-ID with App-ID format according to one M2M TS-0001 [1], table 7.2-1 |"NMyAppId" |
-|ExecutionParameters |PX_RESOURCES_TO_BE_DELETED |(For debugging purposes) |{"MyAe"} |
+|IutParameters |PX_TCONFIG_IUT |Time to configure IUT after a requested action |10.0 |
+|TesterParameters |PX_TS_AE1 |AE1 component settings |aeIdStem = ""<br>appId = "NMyApp1Id"<br>mcaPort and mcaPortIn settings which include per port the following info:<br>Binding:<br> - bindingProtocol<br> - bindingDesc:<br> - tsAddress<br> - localPort<br> - sutAddress<br> - remotePort<br>Serialization |
+|TesterParameters |PX_TS_AE2 |AE2 component settings |aeIdStem = ""<br>appId = "NMyApp2Id"<br>mcaPort and mcaPortIn settings which include per port the following info:<br>Binding:<br> - bindingProtocol<br> - bindingDesc:<br> - tsAddress<br> - localPort<br> - sutAddress<br> - remotePort<br>Serialization |
+|TesterParameters |PX_TS_CSE1 |CSE1 component settings |cseName = "CSE1_NAME"<br>cseId = "/CSE1_ID"<br>cseResourceId = "CSE1_RESOURCE_ID"<br>spId = "//onem2m.org"<br>supportedResourceType = {int1, int2, int3, int16}<br>mcaPort, mcaPortIn, mccPort and mccPortIn settings which include per port the following info:<br>Binding:<br> - bindingProtocol<br> - bindingDesc:<br> - tsAddress<br> - localPort<br> - sutAddress<br> - remotePort<br>Serialization |
+| |PX_TS_UT |UpperTester settings |url = "http://127.0.0.1:43000/" |
+|ExecutionParameters |PX_RESOURCES_TO_BE_DELETED |(For debugging purposes) |{"MyAe", "MyAccessControlPolicyResource", "SubscriptionVerificationAcp", "MyAcp", "MyRemoteCSEResource"} |
|ExecutionParameters |PX_RUN_POSTAMBLE |(For debugging purposes) |true |
# 8 TTCN-3 Verifications
-The principles for Verifying the TTCN-3 test code are given in one M2M TS-0015 [i.2].
+The principles for Verifying the TTCN-3 test code are given in oneM2M TS-0015 [i.2].
-All test cases provided with this document in Annex A which correspond to at least one of the product profiles defined in one M2M TS-0025 [i.3] have been verified at the time of publication of this document which corresponds with the TTCN-3 code gitlab tag provided in annex A.
+All test cases provided with the present document in annex A which correspond to at least one of the product profiles defined in oneM2M TS-0025 [i.3] have been verified at the time of publication of the present document which corresponds with the TTCN-3 code gitlab tag provided in annex A.
# <br/>Annex A (normative):<br/>TTCN-3 library modules
-A.1 Electronic annex, zip file with TTCN-3 code
-This ATS has been produced using the Testing and Test Control Notation (TTCN) according to ETSI ES 201 873-1 [7].
+
+## A.1 Electronic annex, zip file with TTCN-3 code
+This ATS has been produced using the Testing and Test Control Notation (TTCN) according to ETSI ES 201 873-1 [6].
+
This test suite has been compiled error-free using two different commercial TTCN-3 compilers.
The TTCN-3 library modules, which form parts of the present document, are contained in the following gitLab tag:
-[https://git.onem2m.org/TST/ATS/tags/TST-2018-0021-TS-0019_TTCN-3_Test_cases](https://git.onem2m.org/TST/ATS/tags/TST-2018-0021-TS-0019_TTCN-3_Test_cases).
-
+[https://git.onem2m.org/TST/ATS/tags/TS-0019-baseline-v2_7_0](https://git.onem2m.org/TST/ATS/tags/TS-0019-baseline-v2_7_0)
<br/>
# Annex B (informative):<br/>Bibliography
@@ -639,8 +766,11 @@ The TTCN-3 library modules, which form parts of the present document, are contai
|Publication history |Publication history |Publication history |
|-|-|-|
|V2.0.0 |2018-07-27 |Base document from TS-0019 v1.0.0 |
-| | | |
-| | | |
-| | | |
-| | | |
+|V2.1.0 |2018-11-20 |Integrated approved contributions:<br>TST-2018-0147-TS-0019_Test_strategy_and_test_component_details_R2 |
+|V2.2.0 |2019-04-24 |Integrated approved contributions:<br>TDE-2019-0050-TS-0019_Test_strategy_and_pixits_R2 |
+|V2.3.1 |July 2019 |Partners pre-processing done by editHelp!<br>e-mail: |
+|V2.4.0 |Sep 2019 |Integrated approved contributions:<br>TDE-2019-0162-TTCN-3_Test_cases |
+|V2.5.0 |May 2020 |Integrated approved contributions:<br>TDE-2020-0043-<br>- |
+|V2.6.0 |Jan 2021 |Integrated approved contributions:<br>TDE-2020-0105-TS-0019_TTCN3_Test_cases_R2 |
+|V2.7.0 |Jan 2022 |Integrated approved contributions:<br>TDE-2021-0070-TS-0019_TTCN3_Test_cases_R2<br>TDE-2022-0001-TS-0019_Update_Test_components_variables_R2 |
diff --git a/media/image10.png b/media/image10.png
new file mode 100644
index 0000000000000000000000000000000000000000..dec7f72a7d4aefe56519e08f27d78d46fcf1499b
Binary files /dev/null and b/media/image10.png differ
diff --git a/media/image11.png b/media/image11.png
new file mode 100644
index 0000000000000000000000000000000000000000..d0884834df5ecd8c217510c5b81678adab1b0068
Binary files /dev/null and b/media/image11.png differ
diff --git a/media/image5.emf b/media/image5.emf
deleted file mode 100644
index dc3a80a7339f4a53619df43dc2879233e3a44226..0000000000000000000000000000000000000000
Binary files a/media/image5.emf and /dev/null differ
diff --git a/media/image5.png b/media/image5.png
index ce3b1a680a4427f260e2cfe16e26f5c2c12fdbfc..5cbe262e726ebda36bf5dcc9306c1a349b4e7640 100644
Binary files a/media/image5.png and b/media/image5.png differ
diff --git a/media/image6.png b/media/image6.png
index e894d519bd2adfb8b2cda05ebe406a474461903b..20fd8a6f6955368a74cf55640dce246a884014b5 100644
Binary files a/media/image6.png and b/media/image6.png differ
diff --git a/media/image7.emf b/media/image7.emf
deleted file mode 100644
index 9bb7e9529a04881445e7c0c69bdedd353cc60ffb..0000000000000000000000000000000000000000
Binary files a/media/image7.emf and /dev/null differ
diff --git a/media/image7.png b/media/image7.png
index 105bffbc32bf3377222b63efd2d247134484b9b7..e894d519bd2adfb8b2cda05ebe406a474461903b 100644
Binary files a/media/image7.png and b/media/image7.png differ
diff --git a/media/image8.emf b/media/image8.emf
deleted file mode 100644
index 7ae8056bc8cd8dd3bbea8a0555d1116fe3dc796f..0000000000000000000000000000000000000000
Binary files a/media/image8.emf and /dev/null differ
diff --git a/media/image8.png b/media/image8.png
index 6fa8e0f4fa02f0aac7b7b89797f703227afdd18d..105bffbc32bf3377222b63efd2d247134484b9b7 100644
Binary files a/media/image8.png and b/media/image8.png differ
diff --git a/media/image9.emf b/media/image9.emf
deleted file mode 100644
index ec6f9e9bea5ad4debab714d37045cbe9c46910d1..0000000000000000000000000000000000000000
Binary files a/media/image9.emf and /dev/null differ
diff --git a/media/image9.png b/media/image9.png
index 7b3c3c5839e5f1a870401d454053c24837946632..a7938a3ceb2b3d8888a3a873a44929482bcdcf02 100644
Binary files a/media/image9.png and b/media/image9.png differ