消息交互系统领域驱动测试框架研究与应用

鞠炜刚 胡继东

(中兴通讯南京研究所 江苏 南京 210012)

消息交互系统领域驱动测试框架研究与应用

鞠炜刚 胡继东

(中兴通讯南京研究所 江苏 南京 210012)

为解决消息交互系统测试用例编写维护复杂、效率低下的问题，基于领域驱动测试思想，针对消息交互系统的特点，提出一种通用消息交互系统领域测试模型。在此基础上设计开发了消息交互系统领域驱动测试框架，用领域语言描述测试用例，采用领域驱动设计DDD四层架构，基于领域模型，对测试用例进行组织、设计和开发，并直接驱动执行，提高了消息交互系统的测试效率。

消息交互系统 领域驱动测试 领域测试模型 测试框架 分层架构

0 引 言

消息交互系统由多个消息处理节点组成，通过消息交互完成业务。典型的网络通信系统，如移动通信、路由网络等，还有云计算、大数据系统都属于消息交互系统。消息交互系统规模大，复杂度高，应用范围广，需要通过自动化测试提高产品质量，缩短交付周期，但系统节点类型众多，节点间消息协议种类丰富，交互流程复杂多变，导致测试用例编写和维护越来越复杂，不能满足要求，需要采用新的技术和方法[1-2]。本文基于领域驱动测试思想，针对消息系统的特点，提出了一种通用消息交互系统领域测试模型，设计实现了消息交互系统领域驱动测试框架，在通信产品测试中得到了有效应用。

1 传统测试框架

消息交互系统传统测试框架中，被测系统边界是一系列真实消息节点，边界外是模拟消息节点，测试步骤如下：

(1) 被测消息节点执行命令进行预置条件设置；

(2) 模拟消息节点通过消息交互方式向边界内系统发起测试；

(3) 被测消息节点执行检查命令进行结果检查。

传统测试框架如图1所示[3]。

图1 传统测试框架

配置、检查命令和交互消息需要详细编辑，存在以下问题：

(1) 测试用例由消息序列组成，消息由协议细节构成，用例间存在大量重复消息和协议细节，编写复杂，不易理解；

(2) 协议字段升级变化后相关测试用例需要修改，代价大；

(3) 预置条件和结果检查需要通过命令方式操作，易用性和可维护性差。

这些问题导致消息交互系统测试用例编写速度慢，维护成本高，很难应对变化，给测试人员使用带来极大不便，为此设计了一种消息交互系统领域驱动测试框架解决这些问题。

2 领域驱动测试框架

2.1 相关工作

目前基于领域的软件测试方法在国内外受到不少关注，研究主要集中于软件测试领域知识表示、管理和应用的方法。其中知识表示的研究主要集中于采用各种方法对软件测试用例进行领域知识表示，例如本体理论[4]，知识管理主要研究知识的获取、存储和检索等管理方法，更有效地对测试领域知识进行有效的组织和管理，知识应用主要研究如何将软件测试活动和知识紧密联系起来进行有效的应用，提出了一些方法[5-6]。但是这些研究各自侧重于某一方面，没有从整体形成一个通用的体系和框架，测试领域知识的表示和组织在层次结构上相对扁平化，很难应对大型复杂系统的测试。另外针对应用越来越广泛的消息交互系统也未发现有文献提出适用性强的可扩展的通用领域测试模型，但是通信产品的测试又迫切需要，因此我们基于领域驱动设计DDD的分层架构提出了一种通用的领域驱动测试框架。针对消息交互系统的特点设计了一个通用的领域测试模型，并且用领域专用语言DSL来描述消息交互，自动处理基于消息收发的测试，很适合大型复杂通信系统的测试。

2.2 总体架构

消息交互系统领域驱动测试框架采用DDD四层架构[7]，由表示层、服务层、领域层、基础设施层构成，系统总体架构如图2所示。

图2 领域驱动测试框架总体架构

测试人员在表示层编写测试用例，表示层分两个子层，上层是测试用例层，下层是领域关键字层，测试用例由高层领域测试关键字组成，高层关键字由低层关键字分层组装而成。

表示层以下是领域驱动测试库，由测试服务层、领域层和基础设施层构成，层次清晰。表示层最底层测试关键字由测试服务层提供接口实现。

测试服务层对底层领域关键字提供测试接口，对内协调驱动领域层的领域对象来交互协作完成测试。

领域层提供了领域对象模型和消息的DSL模型。领域对象模型包括各类消息节点、用户角色和业务对象，实现业务测试逻辑，通过交互协作完成测试。对于每一种模拟消息节点，定义消息DSL模型，可以根据语义自动对消息进行处理。

基础设施层对上层提供支撑，分为两个层次，上层是设备控制层，包括了消息节点控制和测试引擎控制，下层是通道层。

针对消息交互系统的特点，采用DDD的分层架构，结构更加清晰，有利于更好设计、开发。

2.3 测试用例组织

通过分析消息交互系统领域，将需求特性用验收测试驱动开发ATTD用例来描述[8]。首先明确测试边界，然后划分不同测试领域，对每个领域划分不同特性，特性进一步划分不同测试集，测试集由相关的测试用例构成。不同测试用例的共性操作向所属测试集提取，测试集的共性操作又向所属特性提取，依次类推。

2.4 领域测试关键字组织

领域测试关键字是按基础关键字和特性关键字组织的[9]。其中基础关键字是公共基础的领域关键字，各领域的测试用例都可以使用，而特性关键字针对某一具体领域，在基础关键字基础上封装与该领域相关的高粒度的流程性关键字。基础领域关键字库的组织如图3所示。

图3 基础领域关键字库组织

其中公用关键字是与测试边界无关的关键字，测试边界相关业务关键字主要是各种业务关键字，在边界内按场景进行划分。

根据消息交互系统的特点，测试用例通过关键字拆分，一般由预置条件设置关键字、业务测试关键字和结果检查关键字组成，如图4所示。

图4 测试用例领域关键字组装结构

2.5 测试服务层

测试服务层对上层提供测试接口，协调驱动领域层的领域对象交互协作完成测试。服务层根据消息交互系统的特征，分为用户测试服务和消息节点测试服务，分别对各种用户业务、控制操作和消息节点控制操作进行测试，如图5所示。

图5 测试服务层

1) 用户测试服务

其中用户业务测试服务包括用户消息发送、接收服务，业务测试关键字最终分解为消息发送和接收关键字，调用该服务完成消息发送和接收；消息节点用户测试服务包括用户在消息节点上进行信息设置、检查服务，分为真实和模拟节点两种情况。

2) 消息节点测试服务

提供对真实消息节点和模拟消息节点的各种设置和检查服务，针对消息节点的设置和结果检查关键字调用相关服务完成操作。

2.6 领域层

领域层模型可以分为消息节点模型、用户角色模型和业务模型三大部分，用统一建模语言UML[10-11]建模类图如图6所示。

图6 领域模型层

2.6.1 消息节点模型

消息节点模型描述了消息节点和它们之间的关系，消息节点包括真实和模拟节点。领域模型中，消息节点基类Ne是公共基类，具有消息节点的公共属性，包括标识、ip地址和拓扑连接关系linkNeList属性，真实消息节点类RealNe和模拟消息节点类SimuNe均从它继承。

1) 真实消息节点

RealNe是各类真实消息节点的父类，拥有基础设施层的设备控制基类对象device。具体类型真实消息节点类从RealNe继承，提供对真实消息节点配置、检查及其他控制的接口方法，并通过设备控制对象对真实消息节点进行控制。

2) 模拟消息节点

SimuNe是各类模拟消息节点的父类，拥有users、messageBuffer、engine属性。其中users记录接入的用户列表，用于接收消息后根据用户标识查找用户对象；messageBuffer存储接收到的发送给节点的非用户消息；engine为消息节点使用的引擎代理，和实际测试引擎交互进行消息收发。

模拟消息节点类提供了消息收发方法，其中sendMsg委托engine发送消息；receiveMsg是消息接收回调函数，当基础设施层收到消息分发到本节点时调用该函数接收。

具体类型的模拟消息节点从SimuNe继承扩展，实现具体的设置、检查和业务流程方法。

2.6.2 用户角色模型

用户角色模型包括用户和角色对象，描述了领域模型中的用户、角色之间的关系。用户具有公共属性和行为，在不同消息节点中承担不同的角色，具有不同的属性和行为[12]。

用户对象User具有用户标识、别名等属性，并通过send和receive方法提供用户消息发送和接收的入口处理，然后根据用户接入的模拟消息节点类型，委托给相应的用户角色对象处理。

用户角色的公共基类是UserRole，各种类型的用户角色从它继承。UserRole存储用户在不同类型消息节点上的数据，具有一个消息接收缓冲区，存放接收的消息，UserRole直接关联业务模型对象。UserRole提供了send、receive基类方法，根据消息DSL模型进行消息收发的通用处理。

各类用户角色从UserRole基类继承扩展，实现一些具体的消息收发和设置、结果检查等逻辑。

2.6.3 业务模型

业务模型和用户角色模型关联，和具体的业务领域相关，需要根据消息交互系统的具体业务进行分析，获得业务模型对象和关联关系。

2.7 基础设施层

上层进行设备控制，包括消息节点控制和测试引擎控制，其中消息节点控制使用设备控制对象对真实消息节点进行控制，而测试引擎控制通过引擎代理进行，采用json格式消息作为控制接口。下层为上层提供不同类型的通道。

3 领域驱动测试过程

消息交互系统领域驱动测试框架的具体测试过程如图7所示。

图7 消息交互系统领域驱动测试过程

左侧大框为消息交互领域驱动测试框架，右侧框为被测消息交互系统。测试框架包括主框架和测试引擎两部分，可以分别部署在不同的测试机上，主框架从左到右依次分层，可连接多个测试引擎。

测试用例由领域驱动测试关键字组成，最终分解为消息收发、预置条件和结果检查关键字，下面说明具体测试实现过程。

3.1 消息发送和接收

3.1.1 消息模型DSL

对模拟消息节点定义消息模型DSL[13-14]，对每一种消息，定义其在测试中发送或接收处理的语义。消息交互系统中，消息本质上是对领域模型的操作控制，结合测试进行扩充，用yml定义如下：

消息通用部分定义

消息名

方向(请求或响应)

接收条件

应答消息成功定义

消息领域控制部分定义

领域名称1

操作

操作数据

消息领域控制部分定义消息对各领域的操作控制，包括领域名称、对领域的操作，可以有一种或多种操作，目前定义CREATE、REMOVE、MODIFY三种基本操作，操作中可以定义操作数据，一般为消息字段和相关领域属性的映射。根据业务领域模型和消息模型DSL定义，按照对领域定义的操作，进行消息收发处理，包括构造、保存消息和对领域对象生命周期、状态的控制。

3.1.2 消息发送处理过程

如图7所示，消息发送处理过程如下：

(1) 消息发送关键字通过服务层请求用户对象发送消息；

(2) 用户对象根据接入的模拟消息节点获得用户角色，请求其发送消息；

(3) 用户角色请求消息节点添加用户，建立用户ID和用户对象的映射，用于接收消息查找用户；

(4) 用户角色获取发送消息DSL模型，根据定义从领域模型获取数据构造发送消息，对领域对象进行生命周期和状态控制；

(5) 用户角色将消息编码成json格式，请求模拟消息节点发送；

(6) 模拟消息节点委托引擎代理发送，引擎代理将消息发送给测试引擎；

(7) 测试引擎将消息协议编码后在链路上发送到被测系统消息节点。

3.1.3 消息接收处理过程

消息接收处理过程如下：

(1) 被测真实消息节点回送应答或发送请求；

(2) 测试引擎收到消息后协议解码，转为json格式发送给引擎代理；

(3) 引擎代理的接收线程接收消息，存放在接收消息缓冲区，另一分发线程从缓冲区取消息，根据目的消息节点名，找到模拟消息节点对象，调用接收回调方法处理；

(4) 模拟消息节点根据消息中用户ID查找用户角色，将消息添加到角色的接收队列中；

(5) 消息接收关键字通过服务层接收服务找到用户对象，请求接收消息；

(6) 用户对象获得用户角色，请求其接收消息；

(7) 用户角色获取接收消息DSL模型，得到消息接收条件定义，从缓冲区接收消息；

(8) 用户角色根据领域模型中设置的预期对接收的消息进行比较；

(9) 用户角色根据领域模型和消息模型DSL定义的接收动作进行接收处理，对领域对象进行生命周期和状态控制。

3.2 预置条件和结果检查

预置条件和结果检查关键字分解为以下对消息节点和用户的控制操作：

1) 对真实消息节点控制操作

请求真实消息节点对象执行配置、检查方法，将参数自动组装成操作命令，请求设备控制对象通过底层通道对真实消息节点执行命令。

2) 对模拟消息节点控制操作

请求模拟消息节点对象执行设置、检查方法，对相关属性进行设置、检查。

3) 对用户控制操作

对于用户自身业务属性设置、检查，直接请求用户对象处理；对于在真实消息节点上配置、检查用户特性的，请求真实消息节点对象处理；对于在模拟消息节点中设置、检查用户特性的，请求相应用户角色处理。

4 应用实例

在移动通信系统测试中成功应用了消息交互系统领域驱动测试框架，被测系统是产品X，包括A、B网元，测试系统由模拟网元C、D组成。从其中一个核心用例出发进行领域关键字拆分，领域建模，驱动设计和开发，核心用例如下：

A网元打开策略开关，用户通过C网元接入A，接入过程中A向D网元请求策略，D根据策略配置返回策略控制信息，A根据策略建立相应的承载。

测试用例通过拆分由以下领域关键字组成：

(1) 打开策略开关 A

(2) 用户设置QOS策略 USER1 ，D

(3) 用户发起带策略附着 USER1，C，A，D

(4) 检查用户是否附着成功 USER1 ，A

(5) 检查用户是否符合QOS策略 USER1， A

(6) 用户去附着 USER1

“用户发起带策略的附着”业务关键字进一步拆分为模拟网元C和D对真实网元A进行消息收发的一系列关键字组合。

应用消息交互系统领域驱动测试框架，领域层通过扩展继承很容易实现针对A、C、D网元的用户角色对象：AUserRole、CUserRole、DUserRole，模拟消息节点对象：SimuC、SimuD，真实消息节点对象：RealA、RealB，业务对象：Session、Bear，并对模拟网元C、D定义了消息模型DSL，扩展实现相关的消息收发、配置、设置、检查等测试行为，完成了服务层对外提供的测试服务，领域层模型类图如图8所示。

图8 产品X测试领域模型类图

通过在X产品实际应用消息交互系统领域驱动测试框架，取得了较好的效果，主要有以下几点：

(1) 测试用例使用领域语言描述，更容易理解和编写；

(2) 消息协议或版本升级，只需要修改测试库，用例不需要任何修改，维护方便，可以快速应对变化；

(3) 测试用例和领域关键字的设计、开发、组织更加快速、有效，比使用传统框架节约一半时间。

5 结 语

消息交互系统领域驱动测试框架是一种通用测试框架，可以有效适应各种消息交互系统复杂的业务测试，通过领域模型分析，继承扩展框架，对消息节点、用户角色、业务领域建模、分层设计，快速有效地开发测试用例和领域关键字，更加容易编写和维护，可以在基于消息交互的通信和互联网产品测试中推广。

未来应该向基于DSL的消息交互系统测试框架自动生成方面继续探索研究。

[1] 吴显光. 软件自动化测试[J]. 中国新通信, 2012(14):67-69.

[2] 龚丹. 自动化测试之我见[J]. 计算机光盘软件与应用, 2012(17):83-84.

[3] 夏晶. 基于QTP的功能自动化测试框架的研究与应用[D]. 武汉：武汉科技大学, 2010.

[4] 徐克圣，张影. 基于领域知识软件测试方法的研究与应用[J]. 电脑知识与技术, 2014, 10(10):2457-2460.

[5] 柳永坡，邹磊，金茂忠，等. 软件测试领域的知识管理及模型研究[J]. 计算机应用研究, 2009, 26(1):143-145.

[6] Bj∅rnson F O，Dings∅yr T. Knowledge management in software engineering: A systematic review of studied concepts, findings and research methods used[J]. Information and Software Technology, 2008, 50(11):1055-1068.

[7] Eric Evans. 领域驱动设计[M]. 北京：人民邮电出版社, 2010:11.

[8] Beck K. Test-driven development by example[M]. Upper Saddle River: Addison Wesley, 2002:95-128.

[9] 王君，朱美正，李欣. 关键字驱动测试框架的研究与实现[J]. 计算机工程与设计, 2010, 31(10):2246-2248.

[10] 冀振燕. UML系统分析设计与应用案例[ M] . 北京：人民邮电出版社, 2003.

[11] Roff J T. UML a Beginner's Guide[ M] . 张瑜，译. 北京：清华大学出版社, 2003:9-13.

[12] 谭宗威，刘振宇，阳小华，等. 一种实现DCI架构的方法[J]. 计算机技术与发展, 2011, 21(7):16-20.

[13] 胡海涛，刘颖. 一种基于DSL的服务组合语言[J]. 计算机工程, 2011, 37(9):107-109.

[14] Jouault F，Bézivin J. KM3: A DSL for Metamodel Specification[J]. Lecture Notes in Computer Science, 2006, 4037:171-185.

RESEARCH AND APPLICATION OF THE DOMAIN-DRIVEN TEST ARCHITECTURE FOR MESSAGE INTERACTION SYSTEM

Ju Weigang Hu Jidong

(ZTENanjingInstitute,Nanjing210012,Jiangsu,China)

A universal domain-driven model for the message interaction system based on the theory of domain-driven test and the characteristics of message interaction system is proposed to solve the problem of complexity and low efficiency in writing and maintaining test cases in the message interaction system.On the basis of this model,the domain-driven test architecture for message interaction system is designed and developed,and the test cases are described in domain language.At the same time,we organize,design and develop test cases based on domain model by using the DDD four-layer architecture,and then execute them directly.In such a way,the test efficiency of message interaction system is enhanced successfully.

Message interaction system Domain-driven test Domain test model Test framework Layered architecture

2015-10-11。鞠炜刚，工程师，主研领域：软件测试，自动化测试。胡继东，工程师。

TP3

A

10.3969/j.issn.1000-386x.2017.01.007