5 Testing conventions

5.1 The Test Description proforma

The testing methodology used in the present document is specified in the oneM2M TS-0015 [6].

A Test Description (TD) is a well detailed description of a process that aims to test one or more functionalities of an implementation. Applying to interoperability testing, these testing objectives address the interoperable functionalities between two or more vendor implementations.

In order to ensure the correct execution of an interoperability test, the following information should be provided by the test description:

• The proper configuration of the vendor implementations.
• The availability of additional equipment (protocol monitors, functional equipment, ...) required to achieve the correct behaviour of the vendor implementations.
• The correct initial conditions.
• The correct sequence of the test events and test results.

In order to facilitate the specification of test cases an interoperability test description should include, at a minimum, the following fields as indicated table 5.1‑1.

Table 5.1‑1: Interoperability test description

The test descriptions are provided in proforma tables. In order to ensure the correct execution of an interoperability test, the following information is provided in the test description:

• The configuration applied for the test.
• The need of additional equipment (protocol monitors, functional equipment, etc.) required to achieve the correct behaviour of the implementations.
• The initial conditions.
• The sequence of the test events and test results.

The following different types of test operator actions are considered during the test execution:

• A stimulus corresponds to an event that enforces a DUT to proceed with a specific protocol action, such as sending a message.
• A configure corresponds to an action to modify the DUT configuration.
• An IOP check consists of observing that one DUT behaves as described in the standard: i.e. resource creation, update, deletion, etc. For each IOP check in the Test Sequence, a result can be recorded. The overall IOP Verdict will be considered OK if all the IOP checks in the sequence are OK.
• In the context of Interoperability Testing with Conformance Checks, an additional step type, PRO checks can be used to verify the appropriate sequence and contents of protocol messages, this is helpful for debugging purposes. PRO Verdict will be PASS if all the PRO checks are PASS.

5.2 Test Description naming convention

5.3 Test Settings

This clause contains some test requirements applied to the testing, some constraints, restrictions for executions or some recommendations.

In order to ease test setup and execution, the CSE and AE are requested to support the following settings:

• Security shall be disable as it is out of scope of this interoperability testing.
• Resource names are pre-provisioned, except for content instance resources that are automatically assigned by the hosting CSE.
• After each "Delete" primitive on a resource, the user shall check the resource is effectively deleted.
• Unless it is indicated in the test cases prerequisites, by default, all the applications shall have the required access rights to manage resources on the CSE.

In order to address the TBDs in the oneM2M CoAP binding specification (oneM2M TS-0008 [3]), basic XML and JSON media-type numbers shall be used in the contentFormat option.

In the test descriptions specified below, the following definitions of terms used for short-hand notation apply:

Serialized Representation: refers to either an XML or a JSON representation of data in text-string format as defined in clauses8.3 and 8.4 of oneM2M TS-0004 [2].

Host Address: refers to the authority part of a target URI as defined in IETF RFC 3986 [8] and IETF RFC 7230 [9] which can be represented as an IP literal encapsulated within square brackets, an IPv4 address in dotted decimal form, or a registered name, and optionally extended by a port identifier.

5.4 Pre-conditions

5.4.1 Registration

The AE or CSE that originates the request has been successfully registered to its corresponding CSE. The registration of the AE includes the creation of

5.4.2 Security

The Originator and the receiver have successfully established security association between each other. This may involve the exchange of key and the establishment of a security connection.

The security pre-condition also assumes that the originator has the appropriate access control privilege towards the requested resource.

5.4.3 Service Subscription

Service subscription means that the originator is allowed to be connected with the oneM2M system by contract between the owner of the application and the service provider of the oneM2M system. This may require a corresponding information record in the resource.

5.4.4 ID allocation

ID allocation means that the Originator has already acquired usable identity, either from its registrar CSE or the IN-CSE of the oneM2M system. The ID may be CSE relative or SP relative. The ID is then further used as the identity of the Originator to perform access control, charging, etc.

5.4.5 Existence of resource

Existence of resource means the resource been addressed and has already been created.

5.4.6 Management Session between Management Server and Management Client

Before the device management using external technologies is executed, it is required that a management session has already been established between the Management Server and Management Client. If there is no existing management session, the IN-CSE shall request the establishment of a management session between the Management Server and Management Client.

5.5 Binding message convention

In HTTP/CoAP/MQTT binding messages, the present document defines the convention for :

• [2].
• represents an AE-ID or CSE-ID in MQTT Topic names.

The value will be given at an interoperability test event.

In oneM2M TS-0010 [5], all oneM2M request/response parameters are carried in the MQTT message payload since it has no message header concept. Therefore, the MQTT message payload needs to be described more than HTTP and CoAP messages to describe those parameters in clause 8. In HTTP and CoAP binding messages, payloads are described as "empty" or " resource to be created" in a very abstract way.

Since the representation can be XML or JSON, payload should be abstract to support XML and JSON. The following example is an XML representation and its abstraction for creating a resource.