能源量测数据交换协议测试系统设计与实现

李峻 李鹏飞 周云波 蒋鑫伟

（威胜信息技术股份有限公司 湖南省长沙市 410205）

协议是设备间进行数据交换而建立的规则、标准或约定的集合。协议的实现者面对使用自然语言描述的标准协议，存在理解上的差异，会导致不同的协议实现，“协议测试”就是对协议实现进行识别，以验证协议实现与标准协议的等价性的一种有效的测试方法。

国际上，协议的测试和认证一直都非常受重视，其中DLMS/COSEM UA测试认证和由伊斯卡、埃创、兰吉尔发起的IDIS测试认证，都针对协议开展了专业的测试和认证。国内能源量测领域，虽然协议测试起步较晚，但近年来对协议测试的重视程度越来越高，测试方法已经由基本的功能和协议的集成测试，发展到单独进行协议测试，且针对协议的测试研究已经有了系统的理论和方法，但测试系统还存在通用性不强、与设备功能测试重叠等问题。

随着能源互联网技术和业务的快速发展，应用场景日益繁多，新型的能源量测和采集设备层出不穷，而且能源量测和采集设备间的数据交换协议随之更加灵活、复杂和可扩展性强，而传统的协议测试方法已经难以满足能源量测和采集设备及其数据交换协议快速发展的需要。

本文针对能源量测和采集设备间的数据交换协议，提出了兼顾测试充分性和测试方案实现效率的新型测试模型和方法，系统实现效果分析表明，相较于传统的测试方法，新设计的测试系统明显地提升了测试覆盖率和测试方案实现效率。有助于推动能源互联网的绿色高效发展，助力国家“双碳”目标的实现。

1 协议测试概述

协议测试属于黑盒测试范畴，通常包括四种：一致性测试、互操作测试、鲁棒性测试、性能测试。一致性测试是检查被测设备与协议规范是否一致，是根据协议的标准文本描述对IUT（Implementation Under Test 被测实现）进行测试，判定IUT与对应的协议标准保持一致。一致性测试又可细分为静态一致性测试和动态一致性测试。静态一致性测试主要是评审IUT是否具备PICS（Protocol Implementation Conformance Statements 协议实现一致性声明）的基本实现。动态一致性测试主要是验证IUT的基本互连测试、能力测试、行为测试等。互操作性测试是检查被测设备在各个版本之间的互联操作性和互通能力，以评价相同协议在不同设备之间能否正确的互通，且完成协议规范所规定的功能。鲁棒性测试用来检验IUT在协议实现过程中，对异常数据的处理能力，保障IUT运行的安全性与可靠性。性能测试是检测IUT的各种性能指标，如吞吐量、传输延迟、并发度、执行速度、数据传输率等，测试结果与输入的负载有关。

本文依据能源量测和采集设备间数据交换协议的应用场景，分析协议测试方法特征，从协议一致性、互操作性和鲁棒性测试三个方面提取测试关键要素，设计了两种协议测试模型；创新性提出了基于FSM(Finite State Machine 有限状态机)模型的测试用例自动生成方法，测试系统动态生成测试用例，提升自动化测试水平，大幅度提高测试用例开发效率；并在系统构建中，大量应用了虚拟仿真技术，创建了支撑协议测试的虚拟仿真环境。基于协议测试模型和用例生成方法的研究，保证了测试充分性，提高了测试环境构建效率。

2 协议测试的模型设计

2.1 协议一致性测试

依据《GB/T 17178.1信息技术开放系统互连一致性测试方法和框架》的描述，协议一致性测试方法一般分为本地测试法、分布式测试法、协调测试法、远程测试法。这些方法基本都要求IUT与UT（Upper Tester 上测试器）、LT（Lower Tester 下测试器）、SUT（System Under Test 被测系统）等部件在同一个系统内，既无法完全满足单一测试系统对IUT协议快速自动化的测试要求，也无法融入容错测试用例的测试要求，分析总结能源物联网应用场景和能源量测和采集设备间数据交换协议的特点后，设计了新型的一致性测试架构（见图1）。

图1：协议一致性测试架构

图1中IUT是协议实体的被测实现，也就是需要被测试的协议对象。UT是上层测试器，指上层的测试软件或硬件，对IUT的向上服务进行观察与控制。LT是下层测试器，指下层的测试软件或硬件，对IUT的向下服务进行观察与控制。参考OSI七层模型定义，IUT是n层协议实体，UT属于(n+1)层，通过PCO（Point of control and observation 控制观察点）和IUT交换n层的ASP（Abstract Service Primitive抽象服务原语），LT属于(n-1)层，通过PCO和IUT交换n-1层的抽象服务原语(n-1)ASP。PCO是测试系统和IUT之间的通信点。PR(Protocol Resolver 协议解析器)用于UT和LT之间，与IUT进行通信时，解析服务原语。考虑到协议报文的安全要求，参照渡船模型测试方法，在测试架构中增加了RT(Robust Tester 容错测试器) 测试器，在协议通信过程中，由RT测试器对PDU（Protocol Data Unit协议数据单元）进行篡改、伪造或其他非正常操作，同时对返回进行监听与认证，以验证协议交互过程的健壮性。

改进后的测试设计，能够支持多种能源量测和采集设备间数据交换协议的测试，同时扩大了协议在异常场景下的容错覆盖，提升了协议测试能力。

2.2 协议互操作性测试

协议互操作测试中，采用的是选择经互操作认可的设备来与被测设备进行互操作测试，认可设备可能是单独的认证设备或多个认证设备的组合。但是测试系统和被测系统独立地存在于不同的系统之中,要监视被测系统之间通过(n-1)SP进行的通信,测试系统必需能够监听(n-1)SP的通信，设计层级复杂，而且测试器分布于各个被测系统之中,它们之间协调过程的同步难以保证。

因此在测试架构中引入了经过认证的虚拟仿真能源量测和采集设备，作为互操作性测试中测试器节点。测试模型见图2所示。

图2中，同时存在UTD(Upper Test Driver 上测试驱动器)和LTD(Lower Test Driver下测试驱动器)，测试驱动器是可以执行特定测试步骤的自动测试系统，能够在功能层次对IUT进行控制与观察。通信线路上设置Control控制器，可以对线路上的通信报文，进行监控与控制。测试驱动器中使用多个经过认可的虚拟仿真能源量测和采集设备QE（Qualified Equipment 认证设备），QE完全由代码实现，独立封装成类，方便实例化与复用。

图2：协议互操作性测试架构

目前能源量测和采集设备众多，若搭建真实应用环境进行测试，建设及维护工作量大，场地面积占用多。因此，利用虚拟仿真技术，能快速搭建测试场景，满足了对IUT多维度的互操作性测试，并保证互操作性测试环境构建效率。

2.3 基于FSM模型的用例生成方法

根据设计的协议一致性和互操作性测试模型开展测试，还需要完整的测试过程来确保测试覆盖率。目前的协议测试中，普遍生成测试序列方法是根据被测协议的规范，结合等价类划分法、因果图法等成熟的测试用例设计规则，手动设计测试用例集并开展测试，根据用例集验证结果来评估协议实现的正确性和完整性。该方法简单易实现，但是往往存在用例设计开发时间长，测试覆盖率较低等问题。

通过分析协议的关键要素，认为能源量测和采集设备间的数据交换协议具有测试对象多、状态转换复杂的特点，应采用FSM模型来梳理状态迁移过程，结合协议测试类型与协议测试数据结构以及PR协议解析器，通过自动建模方法，完成FSM建模，将模型解析为可执行用例，从而保证测试用例设计的逻辑性和全面性。

FSM模型是被广泛用于描述有限状态机从一种状态过渡到另一种状态的数学模型。FSM模型定义了一个五元数组{X,I,O,N,M}。如下所示：

X表示状态的有限集合，有限状态机的含义就表示着X是有限的，如果X是无限的，称为图灵机；I表示输入的有限集合；O表示输出的有限集合，且O⊆X；N表示状态变迁函数；M表示输出函数。FSM模型的核心思想在于状态迁移，表示存在一个初始状态Xn，经过有限条件输入或事件发生In，而迁移到另外一个状态Xn+1的过程。

以协议测试中部分场景为例。测试主站为UT，用能量测设备为IUT，仿真电能表设备为LT。在正常连接初始状态下，检测系统触发输入条件I，IUT和LT从状态X，迁移到状态X，并输出结果O。根据测试场景，依次触发输入条件，直到迁移到最终状态X，输出测试结果。IUT的状态迁移图，如图3所示。

图3：状态迁移图

（1）IUT处于初始状态，即正常连接组网状态，进行不规则的建立档案操作，IUT状态未进行迁移。

（2）IUT处于初始状态，进行规则的建立档案操作，档案建立成功，且档案与LT对应，IUT状态迁移到档案等待状态。

（3）IUT处于档案等待状态，IUT向LT发出正确的读取/设置对象属性请求帧，LT正确响应，IUT状态迁移为获取正常读取/设置返回。

（4）IUT处于档案等待状态，IUT向LT发出异常的读取/设置对象属性请求帧（如帧结构异常、传输规则异常、应用服务标记异常），LT拒绝响应或回复带错误标记的响应，IUT状态迁移为获取非正常读取/设置返回。

（5）IUT处于档案等待状态，IUT向LT发出读取/设置对象属性请求帧，帧报文被RT模块截取，状态迁移为RT容错。

（6）状态处于RT容错，RT模块对帧报文进行多余插入、错误篡改、部分删除等容错操作，并向LT发送容错请求帧，LT拒绝响应或回复带错误标记的响应，IUT状态迁移为获取非正常读取/设置返回。

（7）IUT处于档案等待状态，LT向IUT发出正确的上报对象属性请求帧，LT正确响应，IUT状态迁移为获取正常上报信息。

（8）IUT处于档案等待状态，LT向IUT发出上报对象属性请求帧，帧报文被RT模块截取，状态迁移为RT容错。

（9）状态处于RT容错，RT模块对帧报文容错操作，并向IUT上报容错请求帧，IUT拒绝响应或回复带错误标记的响应。

（10）LT向IUT发出异常的上报对象属性请求帧，IUT拒绝响应或回复带错误标记的响应。

图示状态迁移，能够覆盖协议的一致性测试与互操作测试，适用协议的应用数据传输测试、应用服务标记测试，满足量测对象的各类测试需求。

根据上述FSM模型状态迁移特征，可设计出测试用例自动生成的方法，该方法能够依据协议描述（典型的描述方法是采用ASN.1语法描述）及测试用例规范，按照测试用例数据类型的映射规则和测试用例行为映射规则，自动完成测试用例的数据模型构建，采用测试用例数据模型对测试用例文本进行标注，生成形式化的测试用例，该测试用例可以被测试系统自动解析，生成可执行的测试用例对象，实现测试用例的自动生成。

上述基于FSM模型的测试用例自动生成方法，能够在保证测试覆盖充分性的前提下，大幅度提高测试用例的实现效率。

3 协议测试的实现与分析

3.1 协议测试系统实现

基于上述协议一致性测试模型和协议互操作性测试模型，设计并实现完整的协议测试系统。该协议测试系统主要由测试系统、能源量测和采集设备及其仿真设备组成。设备是数据交换协议的载体，即被测对象IUT。如图4所示。

图4：协议测试系统框架图

测试系统主要完成测试控制调度、协议建模、测试用例自动生成、提供协议解析、构建容错场景、虚拟QE等功能。测试控制调度是测试系统的总控制，控制整个系统的闭环测试过程，管理与被测对象IUT之间的交互，UTD和LTD仿真设备的认证。

测试系统采用微服务软件架构实现，将设计的协议测试模型，划分成测试控制服务、用例建模与自生成服务、协议解析服务、测试执行服务、容错测试服务、虚拟仿真设备服务等互相协调、互相配合的微服务体系。每个微服务围绕具体业务进行构建，并且能够独立的部署和运行。

用例建模与自生成服务，能够自动生成状态迁移模型，覆盖所有正常规约状态迁移和异常规约状态迁移，在保证用例场景的最大覆盖情况下，提升了用例设计与开发效率，相比传统的测试系统，能在减少用例设计与开发耗时的同时，增加用例的输出。

规约解析服务，能够完成服务原语到具体规约报文的解析，支持当前主流的能源量测和采集设备间数据交换协议，且独立运行、自由拓展，能够提高IUT设备准入范围。

容错测试服务，通过篡改、伪造或其他非正常操作，能够辅助异常容错的测试实现，验证协议的健壮性，提升容错测试覆盖。

虚拟仿真设备服务，能满足协议快速自动化测试的要求，提高了互操作性的效率，全面覆盖了协议支持的设备类型，减少了真实设备不可控因素的干扰，新协议测试系统，实现了常见的能源量测和采集设备的接入和测试，也预留了接口便于后续新型能源量测和采集设备的接入。

协议测试系统自动测试流程，可以分以下步骤实现，如图5所示。

图5：协议测试实现模型

（1）将被测协议定义的数据结构类型进行分类，必要时进行拆分，采用ASN.1语法进行描述，形成测试用例的数据结构；

（2）结合步骤S1的用例规范，对用例行为和步骤2的数据结构进行一一映射与扩展，形成测试用例的FSM模型；

（3）根据测试用例规范，编制PICS，结合已生成的FSM模型，生成ATS（Abstract Test Suite 抽象测试套）；

（4）结合高级程序语言的特性，引用面向对象思想，设计适配测试用例模型的解析器，将ATS抽象测试套解析成PETS（Parameterization Executable Test Suite参数化可执行测试套）；

（5）使用测试引擎，执行PETS可执行测试套，进行相应的协议一致性检测和协议互操作检测，得出相应的协议一致性结果和协议互操作结果，分析结果之后，输出PCTR（Protocol Conformance Test Report协议一致性测试报告）。

3.2 系统实现效果分析

对比原有的IEC 62056和DL/T 698.45等协议的传统测试系统，本文提出的协议测试系统能同时支持多种能源量测和采集设备，可以模拟仿真更为复杂的现场应用场景用于测试，对于异常场景下的容错测试能力更强。测试用例自动生成技术和虚拟仿真技术时协议测试的覆盖面更广且测试方案的构建更为方便快捷。

针对协议测试实现过程中用例设计、用例开发、系统实现、环境建设等各测试阶段进行耗时统计分析，如表1所示。相较于传统的测试方法，本文提出的测试方法明显地减少了测试实现耗时，提升了测试方案实现效率。

表1：测试方案实现效率分析

4 结束语

本文针对量测数据交换协议设计了协议一致性和互操作性测试模型，并使用了一种基于FSM模型的测试用例自动生成方法，在协议测试覆盖率上实现了优化，提升了检测效率，验证了协议的正确性。但是所设计的架构主要应用于功能测试，只能基于模型做基本的性能校验，在面向数据传输率、联接时间、执行速度、吞吐量、并发度等复杂场景的性能指标的测试略有不足，在今后的测试应用中还需继续研究，优化性能设计，弥补设计短板。