基于SOA的协同系统自动化测试技术研究*

杨 箴，吴方权

（贵州电网有限责任公司信息中心，贵阳 550002）

0 引言

依据南方电网公司“十三五”信息化发展规划，某电网公司建设的CSGII企业管理信息系统已在贵州电网全面推广应用。CSGII系统从顶层设计了各系统的协同业务、跨系统数据流及业务流程。

CSGII 系统交互遵循SOA[1]（面向服务的体系结构）技术路线。随着CSGII系统应用的不断深入和系统实用化的工作要求，跨系统SOA 接口测试的问题日益暴露出来，急需引入有效的技术工具提升多系统间SOA 接口服务的测试效率，提高协同业务集成质量。

本文提出了构建基于SOA 的协同系统自动化测试的设计和实现方法，阐述了项目背景，介绍了建设目标、技术路线、功能架构及系统关键技术、项目技术难点等，为保障企业级应用系统的安全稳定运行提供参考。

1 背景

随着企业级应用系统实用化程度的不断提升，系统协同业务运行质量显得尤为重要。作为信息系统建设质量检验的最有效手段，在系统运维阶段也离不开软件测试。在系统上线和发布前进行充分的协同功能测试，提前发现接口和功能缺陷，才能确保系统发布后的稳定运行。传统依靠人工的协同应用接口测试已经无法满足工作的要求，在具体的接口测试过程中主要存在以下问题。

（1）CSGII系统接口数量庞大，没有高效的自动化测试手段支撑，测试效率低。因CSGII系统涉及230个协同场景，系统间交互的SOA 接口813 个，仅依靠传统人工测试，给上线前的协同功能测试带来极大的人力和时间压力，也给运行过程中的缺陷排查带来极大困难，协同应用测试效率偏低。众多的系统接口相互集成产生海量的交互信息，测试工作量大，纯人工测试效率低，无法满足版本管理和高效测试的要求[2]。

（2）协同业务场景的业务逻辑和接口交联复杂，且各系统由不同开发商开发，管理难度大。协同功能出厂文档资料覆盖不全，且需求不断扩充，业务持续更新。CSGII系统协同应用涉及230 个协同场景，因系统出厂测试文档覆盖不全且更新周期较长，协同应用的交互过程基本属于黑盒或灰盒状态[3]，没有完整明晰的文档详述系统间的交互流程、数据约束条件，对于排错和指导实操的支持度还较差。

（3）流程问题难定位，各系统间缺乏业务流程汇集、交互的展现，没有完整的文档记录，导致问题出现时，无法快速、准确地定位问题的所在。如一个完整的配网电子化移交流程涉及23次不同接口之间的交互，出现问题时要想迅速定位解决问题，在没有完整地梳理交互流程的情况下是不可能实现的。

（4）系统上线之后，相比于建设阶段，存在较多的现实难题和压力，如不能引起业务运行中断，不能破坏系统存储的真实业务数据等。

（5）SOA 接口测试过程无相关报文记录，测试过程、测试结果难于管控、追溯。高效的协同应用测试必须有完整、科学的方法论进行指导，并且需要借助测试工具提升工作效率，在完备测试的基础上才能持续正确地更新协同应用相关知识文档，做好知识积累。

面对这些问题，对CSGII系统协同功能测试方法进行深入研究，构建一套自动化测评应用平台就显得十分必要。

1.1 CSGII系统

CSGII 系统是南方电网公司遵循“统一领导、统一规划、统一标准、统一建设”的“四统一”原则建设的企业级应用系统2.0版本，主要涵盖7大业务域，包括资产管理、营销管理、人力资源管理、财务管理、协同办公、综合管理及决策支持，为南方电网公司的核心业务提供信息系统支撑。CSGII系统主要包括了资产管理系统（含5个子系统）、营销管理系统、人力资源管理系统、财务管理系统、GIS 平台、4A 平台、数据资源管理平台等业务系统及基础技术平台。目前CS⁃GII系统包含了230个协同应用子场景。

贵州电网CSGII系统明细如表1所示。

表1 主要CSGII系统明细Tab.1 List of main CSGII systems

1.2 协同应用场景

CSGII 系统包含了230 个协同应用场景，通过CSGII 系统协同应用实现各系统之间的数据交互、跨系统的数据流及业务流程。如营销系统95598 客服模块接收故障单后，派单到资产管理系统生产子系统进行处理就是一个典型的协同应用场景。

CSGII系统协同业务应用是系统实用化过程中非常关键的一环，体现了各系统横向协同的理念，通过信息系统的顶层设计，打破了部门级系统之间的界限和壁垒。

1.3 蓝鲸平台

企业级系统协同功能自动化测试平台是基于蓝鲸智云PAAS平台构建的应用，该平台是南方电网公司统建统推的运维平台，基于该平台的深度集成大大降低了后期的推广难度和成本。蓝鲸提供了完善的前后台开发框架、调度引擎、公共组建等模块[4]。

蓝鲸平台主要分3个层次。第1层为用户界面层，是系统使用界面，也是系统的入口，主要针对测试人员；第2层为业务逻辑层，是系统的核心开发部分，主要是完成系统要求的各个模块的逻辑功能；第3层为基础服务层，主要完成一些通用服务，例如API 请求代理服务、数据持久化服务、队列缓存服务等；最底层为平台系统层，主要完成对硬件资源的调配，为上层提供服务。

2 技术实现方案

2.1 建设目标

建设一套协同业务接口自动化测评应用平台，并完成贵州电网实用化协同业务接口自动化测试脚本的编制，实现协同业务接口的自动化测评，提高测评效率，降低运行过程中的缺陷排查难度。

2.2 技术路线

基于SOAP 协议[5]构建接口自动化测试平台，模拟客户端请求及响应，支持贵州电网CSGII定制化协议报文解析，实现接口协议的功能性、符合性测试；基于XML[6]描述软件接口测试脚本，实现测试用例和测试数据分离，并基于规范随机生成测试数据；运用最新数据分析和数据挖掘技术，对测试结果统计分析，实现测试质量度量。自动化测试原理如图1 所示。

图1 自动化测试原理Fig.1 Schematic diagram of automatic test

2.3 系统功能设计

从系统功能角度，基于SOA 的协同系统自动化测试平台分为2层6大模块。功能架构如图2所示。

图2 功能架构Fig.2 Functional architecture

2.3.1 核心层

核心层功能如下：

（1）SOA 测试引擎，系统最核心模块，负责执行测试用例、捕获消息体、预言判断等；

（2）数据MOCK，负责产生随机数据；

（3）定时任务，负责定时任务执行。

2.3.2 业务层

业务层功能如下：

（1）用例配置，负责生成一个具体用例测试配置；

（2）用例管理，负责用例及测试集合管理；

（3）测试日志管理，负责测试日志及结果展示。

3 关键技术

3.1 接口自动化测试示例

配置接口自动化测试示例分为5步：（1）配置相关自动测试引擎；（2）准备相关的场景测试用例；（3）根据测试用例，执行测试步骤；（4）查看各消息在SOA 系统的分发记录；（5）查看是否按预定路径分发及驱动下一个消息，查看请求及响应体是否符合预期。协同自动化测试示例如图3所示。

图3 协同自动化测试示例Fig.3 Example diagram of collaborative system automation test platform based SOA

一般情况下，测试人员基于一个测试集合（TestUnit）执行一次测试工作。对于单接口连通测试，一个TestUnit包括了多条接口测试用例。在此场景下，测试要点是消息请求和返回是否符合预期即可。对于SOA 场景测试，一个场景测试相当于一个TestUnit，内部可能包含一条或多条接口，而每条接口可能触发一个或多个节点。在此场景下，测试要点包括每个接口的请求、响应，还包括其所有的传播路径及每个触发节点是否符合预期。复杂度比单接口测试高一个数量级。

3.2 会话保密设计

3.2.1 会话管理

系统提供的会话管理具体控制措施主要有：（1）用户登陆蓝鲸平台后点击该应用，应用会向API 接口服务发起认证请求，认证通过后返回临时调用凭证；（2）获取凭证后进入到应用主页即项目搜索页面，每次调用后端接口均需携带临时凭证，后端验证凭证成功后会延长凭证有效期；（3）在应用页面超过有效期未操作，则临时凭证会失效，会重新开始之前的认证过程；（4）后端绑定了认证服务器来源，因此只有蓝鲸平台的用户才能成功获取临时凭证，从而调用接口，正常使用该应用。

3.2.2 访问控制

系统使用蓝鲸平台的用户管理模块，即用户权限在蓝鲸平台操作，不同的用户通过蓝鲸平台认证后，通过接口获取个人相关的测试项目以及相关数据。

3.2.3 数据安全管理

数据安全管理如下。

（1）服务端数据安全控制措施[7]包括隔离应用的源代码等文件，不能通过外部网络请求方式获取文件数据；用户登录的验证信息通过对称加密的方式进行加密传输，后台通过秘钥进行解密，获取用户信息。

（2）客户端数据安全控制措施包括用户的信息数据不通过URL 参数形式传递；禁止表单中的自动填充功能，防止用户信息被盗用。

3.2.4 接口程序安全

该系统主要用于企业内部网络，相应的接口亦只能通过内部网络调用，这能起到一定的网络隔离作用，只有通过验证的合法用户才能调用接口程序。

4 技术难点及处理方法

4.1 协同应用测试方法论

4.1.1 接口总体版本管控

接口总体版本管控如下。

（1）做好CSGII系统接口的版本管理，记录好本系统提供的接口的关键信息，如接口名称、接口编号、历史版本、下发时间、更新情况等。

（2）做好接口的版本管理工作，接口需要更新时提交审批，确保版本的稳定性。

（3）在测试期间按“SOA 技术管控”相关模板提交对应资料，并提供必要的纸质资料签字确认，确保服务注册、服务变更、服务注销的全过程管控。

4.1.2 测试环境联调关键点

测试环境联调关键点如下。

（1）确认联调哪些场景、功能点。

（2）各个系统版本联调兼容性确认。

（3）相关场景、功能点调用的服务/数据队列梳理。

（4）确认数据准备是否完备（试点单位的数据是否已导入、涉及主数据是否已完成初始化）。

（5）服务连通性测试1（各系统本身发布的服务能够正常访问）。

（6）确认各系统接口服务器到SOA总线的端口正常访问。

（7）服务连通性测试2（注册到SOA的服务各个系统能够正常访问）。

（8）各个系统确认是否有服务调用的配置项或流程，是否已经启用，平台检查用户名、密码、参数、模型、流程等配置是否正确。

（9）配置自动测试流程。

（10）开始联调。

（11）排错（查日志、报文、定位故障点、解决问题、记录问题及解决方法）。

（12）确认完成技术联调，整理过程调用报文以便复用，自动生成测试报告。

4.2 协同场景自动化测试配置

场景即一个测试场景，一个场景包含一个或多个SOA 服务，这些SOA 服务可能在执行顺序上有先后顺序，有可能参数与返回结果有引用关系。这一组SOA 服务也可以没有任何关系，仅仅是因为他们在一起组成了一个场景。创建场景后，根据场景涉及的SOA 服务，逐个搜索出SOA 服务，通过简单地点击服务名称，为场景添加测试用例。启动场景测试，即可对涉及的一系列接口进行测试，测试的详情会记录到日志，点击查看场景日志，会罗列出该场景的每次测试整体结果，查看详情可以还原测试现场，包括调用接口时传递了哪些参数，服务接口详细的返回值，很好地支持测试结果的分析。

4.3 SOA接口无法正常调用

大多数情况下，SOA 参数类型为基本类型，例如数字类型、字符串类型。但是对于服务接口参数类型非基本类型的，即参数的只是一个复合体，此种情况下仅能解析第1层参数，无法设置参数值为复杂类型。基版直接采用列表的方式展示其参数的输入，对与含有复合参数的服务，调用时无法解析参数总是服务调用失败。

重新调整了参数输入界面，对于普通参数接口仍采用列表形式展示参数输入，对于包含特殊复杂参数的SOA 服务，采用文本域接收器[8]参数。添加用例时会自动识别参数是否为复杂类型，复杂类型会生成JSON格式模版，较往常的XML简洁许多，便于填写参数。

5 效益分析

5.1 经济效益分析

5.1.1 接口技术连通性批量测试

贵州电网目前有SOA接口813个，每次大版本发布只能检查服务连通性时，都只有人工调用确认，效率低、工作量大。按每个SOA 接口需要10 min 确认，813×10/60/8＝16.93 人·天；按每年6 次大版本发布，每年SOA 接口连通性自动化批量测试可节约101.58 人·天；按每天1 400 元实施费计算，每年可节约14.22万元。

5.1.2 协同应用自动化测试

按230 个协同场景，每次大版本测试涉及30%的协同场景，每个协同场景测试2人·天，每次大版本发布自动测试可节约230×0.3×2＝138 人·天；按每年6 次大版本升级计算，每年可节约828人·天；按每天1 400元实施费计算，每年可节约115.92万元。

5.1.3 异常日志快速定位、统计

通过协同业务功能建模，全面梳理了协同应用调用逻辑，提升异常快速定位的能力。出现性能异常时，可按系统接口维度直接定位问题日志，可视可控，提升问题排查效率。按每年6次大版本发布，每次大版本测试异常个数50个计算，每个异常定位15 min，可节约人力50×15×6/60/8＝75 人·天；按每天1 400元实施费计算，每年可节约10.5万元。

5.2 社会效益分析

CSGII系统与企业及所有员工都有密切的关系，通过该自动化测试平台的建设，提升测试工作质量和效率，为各个业务系统及时测试、发布提供了更高效的工具，保障了电网核心信息系统相关业务的高效运转。

（1）有力地保障了配网电子化移交、故障抢修等跨专业、跨系统核心业务在系统测试过程中高效的迭代，支持了电网核心业务的正常流转，提升了整体的工作效率。

（2）通过严密的协同应用版本管理，确保了协同升级的稳定性，保证了公司企业级管理信息系统及重要信息系统的安全上线及无间断运行，有力地保障了电网的安全稳定运行，树立了公司的企业形象。

（3）通过日志管理模块的应用，对各个系统的测试情况进行分类分析，可按系统维度反向分析各信息系统的开发质量，为供应商评级提供依据。

6 结束语

协同系统自动化测试平台实现了协同自动化测试的固化，支撑了协同测试用例管理、实施管理、测试结果管理及展示。平台设计了可视化测试配置模块，将测试项规则化，实现接口测试信息域自动提取，自动产生测试报文。

协同系统自动化测试平台实现了贵州电网实用化协同业务接口自动化测试脚本编制与验证，建立接口自动化脚本集，可以将协同功能测试由人工测试向自动化测试转变，增强测试充分性和全面性，提升测试效率，减少测试人力投入，减少系统运行异常，降低缺陷排查的难度。