1 互操作测试

互操作性测试可以证明一个产品可以与其他类似的产品一起工作：证明（至少）两个设备之间的端到端功能符合基准要求的。 在这种情况下，被测系统由来自不同供应商的不同被测设备组合而成。

体现互操作测试特点的重要事实是：

• 互操作测试在仅提供正常控制和观察的接口执行（即不在仅用来进行测试目的的特殊接口
• 互操作测试基于用户体验的功能（即：非在协议级别定义的）。在这个背景下，用户可以是人或者软件应用。
• 测试的执行和观察在功能界面，如人-机界面（MMIs),协议服务界面和应用程序界面（APIs)
• 互操作测试在端点及功能界面执行的事实意味着互操作测试例仅用来定义功能行为。它们不能明确引发或者测试协议错误行为。

 

当前段落提供用户与互操作测试相关的主要步骤指导。指导简单实用以便这个文档可以用作一个“烹饪书” ，而非一个关于如何执行互操作测试的严格规定。

这个指导的主要部分如下：

• 基本概念定义
• 互操作测试规范开发，包括：

          定义一个通用的SUT架构

          定义测试平台架构

          测试场景和配置规范

          互操作功能确定

          互操作测试描述开发

• 互操作测试程序

 

2 基本概念

2.1 概览

互操作性测试仅包括互操作不同供应商的实现，根据预期的与基础标准的一致性，这些实现应该是可以互操作的。 即使这个过程看起来很简单，它也需要指定一个完整的环境，在真实条件下操作供应商的实现。 参与到互操做测试的所有供应商的实现集合与所需的执行测试过程的测试设备一起被命名为“测试平台”。

当描述测试方法时，要用到很多不同的条款和概念。下边的章节描述这些指导的最重要的概念，这些概念或者归类作为SUT部分，或者作为测试环境部分。

2.2 待测系统 

2.2.0 介绍

在互操作测试背景下，待测系统由一定数量的来自不同供应商的待测设备组成。

取决于端到端系统的复杂程度，以及所研究DUT的总体数量和它们之间的相互作用，可能建议定义不同的SUT配置来满足特定的功能域或者测试组。

定义互操作测试规范的第一步是明确待测设备和描述所有要求的待测系统配置都适合的通用架构。

 

2.2.1 待测设备(DUT)

对于oneM2M, 待测设备是实现了oneM2M功能并通过reference point与其它设备交互的软件和/或硬件的组合。

注：当应用互操作测试规范在一个认证系统中时， Qualified Equipment (QE) 或者 Qualified Device (QD)符号适用。 QD是一款成功与其它待测设备测试的DUT。 互操作测试规范在认证方案中的使用超出了本文的范围。 有关这个主题的更多细节可以在ETSI EG 202 237找到。

2.2.2 测试接口

SUT提供的用于测试的接口通常被称为测试接口。 测试驱动者访问这些接口来验证测试行为。SUT提供的其他接口可用于监控，日志分析,等等。

在最简单的例子中，测试接口是一些待测设备提供的常用的用户接口（命令行，GUI, web界面等），在另外一些例子中，待测设备提供API, 通过API, 互操作测试或者通过应用专用的应用手动执行，或者应用程序化的测试设备自动执行。 在一些例子中，观察和验证待测设备的功能行为或者反应或许需要分析它的日志或者记录。

另外，在互操作测试背景下，待测设备间的接口不需要测试，结合互操作测试和一致性测试检查也许需要监控这些接口来评估交换的信息和消息的一致性。

 

2.3 测试环境

2.3.0 介绍 

互操作测试涉及在功能（非协议）级别控制和观察。测试环境是测试待测设备互操作的测试设备和程序（process)的结合。测试环境中的实体通过待测系统提供的测试接口访问不同的待测设备。这些实体确保测试描述的选择、解释和执行，协调和同步在测试接口上的动作，提供设备间交互时记录日志、报告、监控和观察的机制。

测试环境的主要实体在以下章节描述。

2.3.1 测试描述 

测试描述提供为了执行测试需要遵循的详细的指导（或步骤）。通常，互操作测试被描述为一系列由终端设备使用者执行的动作。

在测试由人来执行的例子中，测试由自然语言来描述。在自动化测试的例子中，用程序语言或者测试语言（TTCN-3)来描述测试。

测试说明中的步骤可能具有不同的性质，具体取决于所需的操作类型：触发一个DUT上的行为，验证另一个DUT上的功能响应，配置SUT（添加/移除DUT），检查日志， 等等。每个步骤都应该清楚地标识该动作所针对的DUT和/或接口。

 

2.3.2 测试驱动者 

测试驱动者实现在一个测试描述中规定的在特定测试接口上的步骤。测试效率和连贯性可以通过由可编程的自动化设备来执行特定测试步骤、担任测试驱动者的角色来改进。 这种方法可能需要DUT中标准化的测试接口。

在一些给定的测试案例中，可能有多个测试接口，通过这些接口执行测试。在这样的例子中，在不同的测试驱动者间协调并同步他们的活动是必须的，这个测试协调的角色可以由其中一个测试驱动者担任，或者由测试环境中的另外实体来担任。

 

3 互操作测试规范开发 

3.1 概述

• 开发一个互操作测试规范过程涉及到的主要步骤如下：
• 描述一个待测系统的通用架构
• 定义测试场景
• 确定测试平台架构
• 收集互操作功能声明中的要求
• 定义测试规范结构
• 为互操作声明中的每个条目写一个测试说明

3.2  通用待测系统架构 

一个通用的SUT架构提供了一个抽象的框架，在这个框架内，任何特定的待测系统配置都应该适合。定义一个通用的待测系统架构的出发点通常是在基本标准中描述的功能架构，结合行业和开源项目实际如何执行这些功能模块（分组，捆绑等）。

如前面章节描述，在一个复杂的体统中，可能需要定义几个待测系统被配来覆盖所有定义的测试组。在早期阶段定义通用的架构和确定待测系统配置帮助提供后来的测试描述结构。通用的测试架构通常用图表描述，而且应该明确确定：

• 待测设备，以及待测设备实现的功能模块
• 待测设备间通信路径
• 可能需要待测设备间通信应用的协议，APIs和／或数据模型。

 

3.3 测试场景    

在oneM2M中，确定了大量的用例。 为了执行互操作性测试，需要待测设备支持同样的用例，互操作性测试通过测试场景分类。 因此，一个测试场景选择一组用例，并且被限制为全功能的子集。

换句话说，被考虑定义测试场景的EUT实现oneM2M实体不同角色，但分享一个共同的功能。为了覆盖测试场景，定义了不同的测试配置。

 

3.4 测试平台架构和接口

测试平台是测试中逻辑实体、接口和通信链路的抽象描述。它描述了互操作测试中涉及的所有待测，以及执行测试的设备和程序。

测试架构主要包含以下功能实体：

 

• 待测系统：由一组DUTs（oneM2M节点）组成。DUTs由执行测试需要的所有设备组成。

•  
• 测试平台控制模块：这个实体管理整个测试平台。它被认为是测试平台的核心。这个模块同步、配置、控制和运行其它实体，甚至是待测系统。此外，这个实体收集每个实体的痕迹信息，目的是全局概览测试的执行。根据待测平台的实现，这个模块也可能执行测试判断。
• 测试促进环境：这个实体负责为了某个特定的测试条件刺激待测系统，
• 监控：这个实体查看和收集相关通信链路上的信息
• oneM2M架构元素：它负责为某些用例提供oneM2M应用。
• 网络：依据传输消息的类型，测试平台确定两类型网络。一个用于传输数据，另外一个用来控制。

注意：测试平台架构定义应该和测试描述规范一起做。

 

测试平台接口分为三组：

• 数据：这个组保护用于数据交换的接口。根据被交换的数据类型，接口被分类为三种：          

• 刺激：这种接口携带测试平台产生为某特定行为刺激DUT产生的信息
• 监控：这类接口携带测试过程中DUT间交换的协议信息
• 跟踪：这类接口携带DUT和测试平台执行状态信息，为了能够最大可能的分析测试

• 控制：这组接口通过传递必要的参数，用来分配和控制测试平台各类实体，甚至是待测设备。
• 测试操作：这组接口提供控制测试平台控制模块的能力。通过这个接口，测试操作者要执行的测试，配置测试中涉及的不同实体，分析测试过程中获得的结果。

 

3.5可互操作功能声明（IFS）

“互操作功能声明”（IFS）明确DUT应该支持的标准功能。 这些功能或者是强制性的，或者是可选的，再或者是有条件的（取决于其他功能）。

另外，互操作声明可以被设备制造商用来作为一种形式，明确待测设备在与其他设备制造商互操作时将支持的功能。

互操作声明开发的理想出发点是“实施一致性声明”（ICS），该声明明确被测试协议选项和条件。如ICS, IFS应该被当作基础协议规范部分，而不是一个测试文档。

IFS形式指导由ETSI EG 202 237提供，oneM2M不需要而外的指导文件。

 

3.6  测试描述 (TD) 

“测试描述”（TD）是假定测试 implementation的一个或多个功能的过程的详细描述。 应用于互操作性测试，这些测试目标对应两个或更多供应商implementations之间的互操作功能。