ETSI TS 103 268-1 V1.1.1 (2017-04)

SmartM2M; Smart Appliances Ontology and Communication Framework Testing; Part 1: Testing methodology

DTS/SmartM2M-103 268-1 SAP_tst

General Information

• Status: Published
• Publication Date: 06-Apr-2017
• Technical Committee: SmartM2M - Smart M2M
• Current Stage: 12 - Completion
• Due Date: 15-Apr-2017
• Completion Date: 07-Apr-2017

Standards Content (Sample)

TECHNICAL SPECIFICATION
SmartM2M;
Smart Appliances Ontology and Communication
Framework Testing;
Part 1: Testing methodology
2 ETSI TS 103 268-1 V1.1.1 (2017-04)

Reference
DTS/SmartM2M-103 268-1 SAP_tst
Keywords
data, data sharing, IoT, M2M, Model,
multi service testing, oneM2M, ontology, testing

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2017.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 268-1 V1.1.1 (2017-04)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 8
4 Introduction to the SAP testing methodology . 8
5 Conformance testing. 10
5.1 Introduction . 10
5.2 Implementation Under Test . 11
5.2.1 Introduction. 11
5.2.2 Service Layer Communication . 12
5.2.2.1 oneM2M implementation . 12
5.2.2.2 SAP implementation . 12
5.3 Identification of the Reference points . 12
5.4 Development of Conformance Test Specifications . 12
5.4.1 Protocol Implementation Conformance Statements (PICS) . 12
5.4.2 Test Suite Structure & Test Purposes (TSS & TP) . 13
5.4.2.1 Introduction . 13
5.4.2.2 Test Suite Structure . 13
5.4.2.3 Test Purpose . 13
5.4.2.3.1 Introduction . 13
5.4.2.3.2 TP identifier . 15
5.4.2.3.3 Test objective . 15
5.4.2.3.4 Reference . 15
5.4.2.3.5 PICS selection . 16
5.4.2.3.6 TP behaviour . 16
5.4.3 Abstract Test Suite (ATS) . 20
5.4.3.1 Abstract protocol tester . 20
5.4.3.2 TTCN-3 test architecture . 21
5.4.3.2.1 Introduction . 21
5.4.3.2.2 Generic Conformance architecture . 22
5.4.3.2.3 Smart Appliance Conformance architecture . 23
5.4.3.3 TTCN-3 test suite . 24
5.4.3.3.1 TTCN-3 Test architecture . 24
5.4.3.3.2 Importing XSD definition . 24
5.4.3.3.3 The TTCN-3 naming conventions . 24
5.4.3.3.4 TTCN-3 code documentation . 26
5.4.3.3.5 Test cases structure . 26
5.4.4 Protocol Implementation eXtra Information for Testing (PIXIT). 27
6 Interoperability testing . 27
6.1 Introduction . 27
6.2 Basic concepts for interoperability testing . 28
6.2.1 Overview . 28
6.2.2 System Under Test (SUT) . 28
6.2.2.1 Introduction . 28
6.2.2.2 Devices Under Test (DUT) . 28
6.2.2.3 Test interfaces . 29
6.2.3 Test Environment . 29
ETSI
4 ETSI TS 103 268-1 V1.1.1 (2017-04)
6.2.3.1 Introduction . 29
6.2.3.2 Test Descriptions . 29
6.2.3.3 Test drivers . 29
6.3 Development of Interoperability Test Specifications . 30
6.3.1 Overview . 30
6.3.2 Generic SUT Architecture . 30
6.3.3 Test architecture and Interfaces . 30
6.3.4 Interoperable Functions Statement (IFS) . 32
6.3.5 Test Descriptions (TD) . 32
Annex A (informative): Example of ICS table . 34
A.1 SAREF Device Class Statement . 34
History . 35

ETSI
5 ETSI TS 103 268-1 V1.1.1 (2017-04)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); 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 searches, 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.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Smart Machine-to-Machine
communications (SmartM2M).
The present document is part 1 of a multi-part deliverable covering Conformance test specifications for Smart
Appliances Ontology and Communication Framework Testing as identified below:
Part 1: "Testing methodology";
Part 2: "Protocol Implementation Conformance Statement (PICS) pro forma";
Part 3: "Test Suite Structure and Test Purposes (TSS & TP)";
Part 4: "Abstract Test Suite (ATS) and Protocol Implementation eXtra Information for Testing (PIXIT)".
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).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
6 ETSI TS 103 268-1 V1.1.1 (2017-04)
1 Scope
The scope of the present document is to support Smart Appliance common ontology and communication framework
testing needs. It specifies a global methodology for testing for Smart Appliances, based oneM2M specifications. It
analyses the overall testing needs and identifies and defines the additional documentation required.
The testing framework proposed in the present document provides methodology for development of conformance and
interoperability test strategies, test systems and the resulting test specifications for SAP.
2 References
2.1 Normative 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 the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://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 present document.
[1] ETSI TS 103 264: "SmartM2M; Smart Appliances; Reference Ontology and oneM2M Mapping".
[2] ETSI TS 103 267: "SmartM2M; Smart Appliances; Communication Framework".
[3] ETSI TS 118 101: "oneM2M; Functional Architecture (oneM2M TS-0001)".
[4] ETSI TS 118 104: "oneM2M; Service Layer Core Protocol Specification (oneM2M TS-0004)".
[5] ETSI TS 118 112: "oneM2M; Base Ontology (oneM2M TS-0012)".
[6] ETSI TS 118 108: "oneM2M; CoAP Protocol Binding (oneM2M TS-0008)".
[7] ETSI TS 118 109: "oneM2M; HTTP Protocol Binding (oneM2M TS-0009)".
[8] ETSI TS 118 110: "oneM2M; MQTT Protocol Binding (oneM2M TS-0010)".
[9] ETSI TS 118 120: "oneM2M; WebSocket Protocol Binding (oneM2M TS-0020)".
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 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] ETSI EG 202 798: "Intelligent Transport Systems (ITS); Testing; Framework for conformance and
interoperability testing".
[i.2] ISO/IEC 9646 (all parts): "Information technology - Open Systems Interconnection - Conformance
testing methodology and framework".
ETSI
7 ETSI TS 103 268-1 V1.1.1 (2017-04)
[i.3] ETSI ES 201 873 (all parts): "Methods for Testing and Specification (MTS); The Testing and Test
Control Notation version 3".
[i.4] ETSI EG 202 237: "Methods for Testing and Specification (MTS); Internet Protocol Testing
(IPT); Generic approach to interoperability testing".
[i.5] ETSI EG 201 058: "Methods for Testing and Specification (MTS); Implementation Conformance
Statement (ICS) pro forma style guide".
[i.6] ETSI ETR 266: "Methods for Testing and Specification (MTS); Test Purpose style guide".
[i.7] ETSI ETS 300 406: "Methods for Testing and Specification (MTS); Protocol and profile
conformance testing specifications; Standardization methodology".
[i.8] ISO 10746 (all parts): "Information technology - Open Distributed Processing - Reference model".
[i.9] ETSI TS 103 268-2:"SmartM2M; Smart Appliances Ontology and Communication Framework
Testing; Part 2: Protocol Implementation Conformance Statement (PICS) proforma".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ISO 10746 [i.8], ETSI TS 103 264 [1],
ETSI TS 103 267 [2], ETSI TS 118 101 [3], ETSI TS 118 104 [4] and the following apply:
conformance testing: process for testing that an implementation is compliant with a protocol standard, which is
realized by test systems simulating the protocol with test scripts executed against the implementation under test
interoperability testing: activity of proving that end-to-end functionality between (at least) two devices is as required
by the base standard(s) on which those devices are based
testing framework: document providing guidance and examples necessary for the development and implementation of
a test specification
conformance: compliance with requirements specified in applicable standards ISO/IEC 9646 [i.2]
Device Under Test (DUT): combination of software and/or hardware items which implement the functionality of
standards and interact with other DUTs via one or more reference points
Implementation Under Test (IUT): implementation of one or more Open Systems Interconnection (OSI) protocols in
an adjacent user/provider relationship, being the part of a real open system which is to be studied by testing
(ISO/IEC 9646-1 [i.2])
interoperability: ability of two systems to interoperate using the same communication protocol
interoperability test suite: collection of test cases designed to prove the ability of two (or more) systems to
interoperate
InterWorking Function (IWF): translation of one protocol into another one so that two systems using two different
communication protocols are able to interoperate
Qualified Equipment (QE): grouping of one or more devices that has been shown and certified, by rigorous and
well-defined testing, to interoperate with other equipment
NOTE 1: Once a DUT has been successfully tested against a QE, it may be considered to be a QE, itself.
NOTE 2: Once a QE is modified, it loses its status as QE and becomes again a DUT.
test case: specification of the actions required to achieve a specific test purpose, starting in a stable testing state, ending
in a stable testing state and defined in either natural language for manual operation or in a machine-readable language
(such as TTCN-3) for automatic execution
ETSI
8 ETSI TS 103 268-1 V1.1.1 (2017-04)
test purpose: description of a well-defined objective of testing, focussing on a single interoperability requirement or a
set of related interoperability requirements
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ISO 10746 [i.8], ETSI TS 103 268-2 [i.9], ETSI
TS 118 101 [3], ETSI TS 118 104 [4] and the following apply:
API Application Programming Interface
ATS Abstract Test Suite
DUT Device Under Test
EUT Equipment Under Test
IFS Interoperable Features Statement
IUT Implementation Under Test
IWF InterWorking Function
PICS Protocol Implementation Conformance Statement
PIXIT Protocol Implementation eXtra Information for Testing
QE Qualified Equipment
RP Reference Point
SAP Smart Appliance
SUT System Under Test
TP Test Purpose
TSS Test Suite Structure
TST Testing
4 Introduction to the SAP testing methodology
The present document provides:
• Identification of the implementations under test (IUT) for conformance testing and the device under test
(DUTs) for interoperability, i.e. answering the question "what is to be tested".
• Definition of the applicable test procedures, i.e. answering the question "how is to be tested".
• Definition of the procedure for development of test specifications and deliverables (for instance: TSS & TP,
TP pro forma, TTCN-3 test suite and documentation).
Figure 4-1 illustrates the SAP M2M testing framework and the interactions with M2M base standards and SAP M2M
test specifications. The SAP M2M testing framework is based on concepts defined in ISO/IEC 9646 [i.2], TTCN-3 [i.3],
ETSI EG 202 237 [i.4] and ETSI EG 202 798 [i.1].
ETSI
9 ETSI TS 103 268-1 V1.1.1 (2017-04)
Base specifications
Conformance SAP Test Interoperability
Test Test
Methodology
Specifications Specifications
Identification
IUTs of IUTs and DUTs
DUTs
PICS
IFS
Development
of test
specifications
TSS&TP
TDs
IOP Test
ATS
Abstract Test
Bed
Method
TTCN-3
Figure 4-1: SAP M2M testing methodology interactions
ETSI test specifications are usually developed for a single base protocol standard or for a coherent set of standards. As
such, it is possible to follow the methodology specified for conformance test development in ISO/IEC 9646-1 [i.2]
without much difficulty. However, M2M and Smart Appliance testing requirements are, in many cases, distributed
across a wide range of documents and, thus, an adaptation of the ISO/IEC 9646 [i.2] approach to test development is
necessary. Also, for readability, consistency and to ease reusability of TTCN-3 code it is necessary to apply some
guidelines on the use of TTCN-3.
It is this approach that is referred to as the "5Smart Appliance testing framework".
As its name implies, the framework is oriented towards the production of Test specifications. The Smart Appliance
testing Framework comprises:
• A documentation structure:
- Catalogue of requirements (PICS or IFS).
- Test Suite Structure (TSS).
- Test Purposes:
Conformance.
Interoperability.
• A methodology linking the individual elements of a test specification together:
- Style guidelines and examples.
- Naming conventions.
- A structured notation for TP.
- Guidelines on the development of TTCN-3 Test Cases (TCs).
- Guidelines on the use of tabulated English Test Descriptions (TDs).
ETSI
10 ETSI TS 103 268-1 V1.1.1 (2017-04)
5 Conformance testing
5.1 Introduction
The following clauses show how to apply the ETSI conformance testing methodology to SAP M2M in order to properly
produce SAP M2M conformance test specifications.
The Conformance testing can show that a product correctly implements a particular standardized protocol, that is, it
establishes whether or not the implementation under test meets the requirements specified for the protocol itself.
For example, it will test protocol message contents and format as well as the permitted sequences of messages. In that
context, tests are performed at open standardized interfaces that are not (usually) accessible to an end user, and executed
by a dedicated test system that has full control of the system under test and the ability to observe all incoming and out
coming communications; the high degree of control of the test system over the sequence and contents of the protocol
messages allows to test both valid and invalid behaviour.
Conformance
Implementation
Test System
Under Test
Figure 5.1-1: Conformance testing
Conformance test specifications should be produced following the methodology described in ISO/IEC 9646-1 [i.2]. In
summary, this methodology begins with the collation and categorization of the requirements to be tested into a tabular
form which is normally referred to as the "Protocol Implementation Conformance Statement" (PICS). Each PICS relates
to a specific protocol standard. In those cases where the requirements are distributed across a large number of
documents there may be very little benefit in producing an individual PICS for each document. Consequently, the
requirements should be collected together and categorized in a single document, referred as the Requirements
Catalogue. The present document could be structured as an overall PICS covering the requirements of all the relevant
specifications.
For each requirement in the catalogue, one or more tests should be identified and classified into a number of groups
which will provide a structure to the overall test suite (TSS). A brief Test Purpose (TP) should then be written for each
identified test and this should make it clear what is to be tested but not how this should be done. Although not described
or mandated in ISO/IEC 9646-1 [i.2], in many situations (particularly where the TPs are complex) it may be desirable to
develop a Test Description (TD) for each TP. The TD describes in plain language (often tabulated) the actions required
to reach a verdict on whether an implementation passes or fails the test. Finally, a detailed Test Case (TC) is written for
each TP. In the interests of test automation, TCs are usually combined into an Abstract Test Suite (ATS) using a
specific testing language such as TTCN-3.
In summary, the SAP M2M Conformance Testing methodology consists of:
• Selection of Implementations Under Test (IUT).
• Identification of reference points.
• Development of test specifications, which includes:
- Development of "Implementation Conformance Statements" (ICS), if not already provided as part of the
base standard.
- Development of "Test Suite Structure and Test Purposes" (TSS & TP).
- Development of "Abstract Test Suite" (ATS) including:
Definition of the Abstract Protocol Tester (APT).
Definition of TTCN-3 test architecture.
Development of TTCN-3 test suite, e.g. naming conventions, code documentation, test case
structure.
ETSI
11 ETSI TS 103 268-1 V1.1.1 (2017-04)
5.2 Implementation Under Test
5.2.1 Introduction
The "Implementation Under Test" (IUT) is a protocol implementation considered as an object for testing. This means
that the test process will focus on verifying the compliance of this protocol implementation (IUT) with requirements set
up in the related base standard. An IUT normally is implemented in a "System Under Test" (SUT). For testing, an SUT
is connected to a test system over at least a single interface. Such an interface is identified as "Reference Point" (RP) in
the present document. Further details on RPs are presented in clause 5.2.
NOTE: Other interfaces between the test system and the IUT may be used to control the behaviour of the IUT
during the test process.
IUTs normally are entities of a protocol architecture for a specific communication protocol located in an OSI layer.
Figure 5.2.1-1 shows a complete view of communication layer for M2M domain. Further details are presented in the
clause 5.2.2.
IUT
oneM2M
oneM2M
Security
ononeeM2MM2M
Management
Service Layer
HTTP/CoAP/MQTT
Network & Transport
WiFi/6LoWPAN/
Ethernet, Zigbee,.
Security
Management
Access
Figure 5.2.1-1: Example of IUT in the oneM2M reference architecture
ETSI
12 ETSI TS 103 268-1 V1.1.1 (2017-04)
5.2.2 Service Layer Communication
5.2.2.1 oneM2M implementation
Table 5.2.2.1-1 shows the IUTs for oneM2M reference architecture as defined in ETSI TS 118 101 [3].
Table 5.2.2.1-1: IUTs for oneM2M
IUT (node) Entities Interfaces Notes
ASN Application Entity (AE) Mca
Common Services Entity (CSE) Mca, Mcc, Mcn
ADN Application Entity (AE) Mca
MN Application Entity (AE) Mca
Common Services Entity (CSE) Mca, Mcc, Mcn
IN Application Entity (AE) Mca
Common Services Entity (CSE) Mca, Mcc, Mcn
Any of Network Services Entity (NSE) Mcn
above
5.2.2.2 SAP implementation
In Smart Appliance Testing, only the AE is tested.
Table 5.2.2.2-1: IUTs for Smart Appliance
IUT (node) Entities Interfaces Notes
ASN Application Entity (AE) Mca
ADN Application Entity (AE) Mca
MN Application Entity (AE) Mca
IN Application Entity (AE) Mca

5.3 Identification of the Reference points
This clause illustrates candidate reference points (RPs) where test systems can be connected in order to test
conformance of oneM2M protocols (IUTs) with oneM2M base standards.
Table 5.3-1: RPs for oneM2M
RP Identifier RP Type oneM2M node- oneM2M node- Network
entity entity
RP-SAP-1 Mca ASN-AE ASN-CSE
RP-SAP-2 Mca MN-AE MN-CSE
RP-SAP-3 Mca IN-AE IN-CSE
RP-SAP-4 Mca ADN-AE IN-CSE
RP-SAP-5 Mca ADN-AE MN-CSE
5.4 Development of Conformance Test Specifications
5.4.1 Protocol Implementation Conformance Statements (PICS)
The guidance to produce ICS pro forma is provided in ETSI EG 201 058 [i.5] and no extra guidance is required for the
context of Smart Appliance.
ETSI
13 ETSI TS 103 268-1 V1.1.1 (2017-04)
5.4.2 Test Suite Structure & Test Purposes (TSS & TP)
5.4.2.1 Introduction
A test purpose is a prose description of a well-defined objective of testing. Applying to conformance testing, it focuses
on a single conformance requirement or a set of related conformance requirements from the base standards.
Several types of presentation of the test purposes exist. These presentations are combining text with graphical
presentations, mainly tables, and include sometimes message sequence charts. The present document presents a
proposed table template to write test purposes with recommendations concerning the wording and the organization of
the test purposes.
There are usually numerous test purposes, which need to be organized in structured groups. The organization of the test
purposes in groups is named "Test Suite Structure".
The development of the test purposes follows the analysis of the conformance requirements, clearly expressed in the
base standards. Furthermore, the analysis of a base standard leads to the identification of different groups of
functionalities, which are used to define the first levels of the test suite structure.
The guidance provided in the following clauses is based on two ETSI reference documents produced by the MTS
technical committee ETSI ETR 266 [i.6] and ETSI ETS 300 406 [i.7].
5.4.2.2 Test Suite Structure
Defining the test suite structure consists of grouping the test purposes according to different criteria like for instance:
• The functional groups and sub-groups of procedures in the base standard, from which the requirement of the
test purpose is derived.
• The category of test applying to the test purposes, for instance:
- valid behaviour test;
- invalid behaviour test;
- timer test;
- etc.
Usually the identification of the different functional groups of procedures leads to the definition of the top levels of the
TSS. Then further levels at the bottom of the TSS is used to group test purposes belonging to the same type of test.
Table 5.4.2.2-1 shows SAP Test Suite Structure (TSS) including its subgroups defined for conformance testing.
Table 5.4.2.2-1: TSS for SAP TST
Root Group Sub-group category
SAP SAREF XXX Valid behaviour
Valid behaviour
Invalid Syntax or Behaviour
Tests
Inopportune Behaviour
The test suite is structured as a tree with the root defined as SAP. The tree is of rank 3 with the first rank a Group, the
second a Sub-group and the third a Category. The third rank is the standard ISO conformance test categories.
5.4.2.3 Test Purpose
5.4.2.3.1 Introduction
A test purpose is an informal description of the expected test behaviour. As such it is written in prose.
ETSI
14 ETSI TS 103 268-1 V1.1.1 (2017-04)
In order to increase the readability of the TP, the following two recommendations should be followed:
• Each TP should be presented in a table, containing two main parts:
- The TP header, which contains the TP identifier, the TP objective and the external references (PICS, and
base standard).
- The behaviour part, which contains the test behaviour description. This part can be optionally divided in
the three following parts, in order to increase the readability:
the initial conditions;
the expected behaviour;
the final conditions.
• The prose describing the test behaviour (including initial and final conditions) should follow some rules, as for
instance the use of reserved keywords and syntax.
Table 5.4.2.3.1-1: TP pro-forma template
TP Id
Test objective
Reference
Config Id
PICS Selection
Initial conditions with {
}
Expected behaviour Test events
when {
}
then {
}
Table 5.4.2.3.1-2: Description of the fields of the TP pro-forma
TP Header
TP ID The TP ID is a unique identifier. It shall be specified according to the TP naming
conventions defined in clause 5.4.2.3.2.
Test objective Short description of test purpose objective according to the requirements from the base
standard.
Reference The reference indicates the sub-clauses of the reference standard specifications in
which the conformance requirement is expressed.
PICS Selection Reference to the PICS statement involved for selection of the TP. Contains a Boolean
expression.
TP Behaviour
Initial conditions The initial conditions define in which initial state the IUT has to be to apply the actual
TP. In the corresponding Test Case, when the execution of the initial condition does not
succeed, it leads to the assignment of an Inconclusive verdict.
Expected behaviour (TP Definition of the events, which are parts of the TP objective, and the IUT are expected
body) to perform in order to conform to the base specification. In the corresponding Test
Case, Pass or Fail verdicts can be assigned there.
Final conditions Definition of the events that the IUT is expected to perform or shall not perform,
according to the base standard and following the correct execution of the actions in the
expected behaviour above. In the corresponding Test Case, the execution of the final
conditions is evaluated for the assignment of the final verdict.

ETSI
15 ETSI TS 103 268-1 V1.1.1 (2017-04)
Defining the initial and final conditions, separately from the expected behaviour, makes the reading of the TP easier and
avoid misinterpretations.
The "expected behaviour", which matches the events corresponding to the TP objective, can also be named "TP body",
which is similar to the "test case body" in an abstract test suite (ATS).
5.4.2.3.2 TP identifier
The TP identifier identifies uniquely the test purposes. In order to ensure the uniqueness of the TP identifier, it follows a
naming convention.
The more useful and straightforward naming convention consists of using the test suite structure, to form the first part
of the TP identifier. Then the final part consists of a number to identify the TP order within a TP group.
Table 5.4.2.3.2-1 shows an example of TP naming convention applying to the TSS described in table 5.4.2.3.1-2.
The TP identifier is formed by the abbreviation "TP", followed by abbreviation representing the group of the following
TSS levels, ending with a number representing the TP order. Each field of the TP identifier is separated by a "/".
Table 5.4.2.3.2-1: Example of TP naming convention SAP TST
Identifier: TP/////
= root
= group
= subgroup
= type of testing BV Valid Behaviour tests
BI Invalid Syntax or Behaviour Tests
BO Inopportune Behaviour
= sequential number 01 to 99

A TP identifier, following the TP naming convention of the table could be TP/SAP/SAREF/BV/001.
The TP numbering uses two digits for presentation, and starts with 01 rather than with 00. Exceeding 99 TPs per group
is not recommended. In such a case, it is rather recommended to create sub-groups, in order to keep clarity in the Test
Suite Structure.
5.4.2.3.3 Test objective
The test objective clearly indicates which protocol requirement is intended to be tested in the test purpose. This part
eases the understanding of the TP behaviour. This also eases the identification of the requirements, which were used as
a basis for the test purpose.
It is recommended to limit the length of the test objective to one sentence.
See also the example in table 5.4.2.3.6-2.
5.4.2.3.4 Reference
In the reference row, the TP writer indicates, in which clauses of the protocol standards, the requirement are expressed.
This information is critical, because it justifies the existence and the behaviour of the TP.
The reference row may refer to several clauses. When the clause containing the requirement is big (for instance, more
than ½ page), it is recommended to indicate the paragraph of the clause where the requirement was identified.
The reference to the base standard actually is precise enough to enable the TP reader to identify quickly and precisely
the requirement.
See also the example in table 5.4.2.3.6-2.
ETSI
16 ETSI TS 103 268-1 V1.1.1 (2017-04)
5.4.2.3.5 PICS selection
The PICS selection row contains a Boolean expression, made of PICS parameters. It is recommended to use PICS
acronym, which clearly identify the role of the PICS, instead of using the PICS table and row references.
A mapping table is included in the TP document to link the PICS acronym with its corresponding reference in the PICS
document. See the example table 5.4.2.3.5-1.
Table 5.4.2.3.5-1: Mnemonics for PICS reference
Mnemonic PICS item
PICS_AE A.5.1/1 [1]
PICS_CONTAINER A.5.1/1 [1]
PICS_FLEXCONTAINER A.5.1/1 [1]
PICS_GENERIC_IWK_SERVICE A.5.1/1 [1]
PICS GENERIC_IWK_OP_INSTANCE A.5.1/1 [1]
PICS_DEVICE A.5.2/1 [1]
PICS_FUNCTION A.5.3/1 [1]
PICS_ PROPERTY A.5.5/1 [1]
PICS_ COMMAND A.5.6/1 [1]
PICS_DEVICECATEGORY A.5.7/1 [1]
PICS_STATE A.5.8/1 [1]
PICS_TASK A.5.9/1 [1]
PICS_UNITOFMESURE A.5.10/1 [1]
PICS_COMMODITY A.5.11/1 [1]
PICS_BUILDINGOBJECT A.5.12/1 [1]
PICS_BUILDINGSPACE A.5.13/1 [1]
PICS_PROFILE A.5.14/1 [1]
PICS_FUNCTIONCATEGORY A.5.15/1 [1]
PICS_OBJECTPROPERTY A.5.16/1 [1]
PICS_DATATYPE A.5.17/1 [1]
PICS_OPERATION A.5.18/1 [1]
PICS_THING A.5.19/1 [1]
PICS_ASPECT A.5.20/1 [1]
NOTE: [x] being the bookmark to the PICS standard, in the reference
clause of the TP document.
5.4.2.3.6 TP behaviour
First of all, the following global rules apply, when writing the behaviour description:
• The behaviour description is written in an explicit, exhaustive and unambiguous manner.
• The behaviour description only refers to externally observable test events (send/receive PDUs, timer, counters,
etc.) or to events or states, which can be directly or indirectly observed externally.
• All test events used in the behaviour description are part of the procedures specified in the protocol standards.
• The wording of the test events in the behaviour description is explicit, so that the ATS writers do not have to
interpret the behaviour description.
• All test events in the behaviour description should result as far as possible in one ATS statement (for instance
a TTCN statement).
The test behaviour is described in prose. This enables to use different ways to express similar behaviour. But using
different expressions to define identical behaviours can lead to some misinterpretation of the test purposes. Also the
meaning and the expected order of the test event have a clear and unique meaning for different readers.
Thus, the present document recommends to use pre-defined keywords in order to express clearly and uniquely the test
behaviour.
Table 5.4.2.3.6-1 shows some recommended pre-defined keywords and their context of usage. The pre-defined
keywords are also likely to be used in combination with the "{" "}"delimiters, in order to clearly delimitate their action
in the test behaviour description.
ETSI
17 ETSI TS 103 268-1 V1.1.1 (2017-04)
Table 5.4.2.3.6-1 does not present an exhaustive list, so that additional keywords might be defined as necessary. The
definition of additional keywords is included in the corresponding TSS & TP document.
Table 5.4.2.3.6-1: List of pre-defined keywords for the behaviour description
Behavioural keywords
with
with, together with "{" "}" delimiters is used to express the initial conditions, which consist
of a set of events, to be executed before starting with the test behaviour corresponding to the
test objective.
EXAMPLE:
with {
the CSE being in the "initial state" and

the IUT having a Functionality class or subclass instance and
the IUT having privileges to perform CREATE operation
}
ensure that
ensure that, together with "{" "}" delimiters is used to define the place of the expected
behaviour (TP body) or the final conditions.
EXAMPLE:
ensure that
when {
the IUT starts and registers
}
when/then
when combined with then enables to define the test behaviour involving a combination of
stimuli and response events. The when/then combination is used when the occurrence of an
event is triggered by the realization of a previous event.
EXAMPLE:
ensure that {
when {
the IUT starts and registers
}
then {
the IUT sends a valid CREATE request containing
To set to address of and
Resource-Type set to type and
From set to AE-ID and
Content containing
resource containing
descriptor attribute containing
instance of the Command class or subclass
containing
rdf:about attribute containing
URI of the Device
concatenated with the letter "*"
and the class name of the
Command.
}
ETSI
18 ETSI TS 103 268-1 V1.1.1 (2017-04)
Table 5.4.2.3.6-2: Event keywords
Event keywords
the IUT
Event in the TP is expressed from the point of view of the IUT. This avoid any
misinterpretation.
receives
states for an event corresponding to the receipt of a message by the IUT.
having received
states for a condition where the IUT has received a message.
sends states for an event corresponding to the sending of a message by the IUT.
having sent states for a condition where the IUT has sent a message.
from/to
Indicates the destination or the origin of a message as necessary (interface, .)
EXAMPLE:
ensure that {
when { the IUT receives a valid XXX mes
...