围绕企业服务总线的测试解决方案及测试场景解析

• 背景

1. 企业服务总线概述

企业服务总线，即ESB全称为Eenterprise Service Bus，指的是传统中间件技术与XML、Web服务等技术结合的产物。随着金融系统的架构体系日渐复杂、各系统间交互协议或标准不统一、共有服务存在分离及重复开发等情况发生的风险及频率增高。为避免此类情况频发，企业服务总线正在被越来越多的金融系统架构所采纳、建设、实施。企业服务总线提供了连接企业内部及跨企业间新的和现有软件应用程序的功能，由中间件技术实现面向服务的体系结构（service-oriented architecture，SOA），使得构建在各系统中的服务可以以一种统一和通用的方式进行交互。

1. 测试视角解析

在构建企业服务总线的过程中，对应的测试工作需要同步提升及跟进。实施企业服务总线之前，基于分离系统下的独立接口测试方法正逐渐向以企业服务总线为中心的整体全流程集中测试方法过渡。本文将根据一些实践经验，围绕企业服务总线阐述具体的测试方法、测试经验、测试场景运用。通过测试的视角去解析企业服务总线的一些具体场景运用。

• 通用测试方法

1. 报文通讯测试

通过建立满足自身企业服务总线特点（协议\标准\规范）的自动化接口测试平台或者模拟工具，去模拟报文并发送到对应的ESB服务节点或者对外的F5节点。并通过事先建立与上送请求对应的预期结果检查点，结合通讯及解析等维度，进行整体的报文通讯结构测试。

图2-1 接口通讯及解析测试场景

拼装报文后具体测试流程如下：

1. 首先确认报文是否发送成功，发送失败的原因可能有“上送网络问题、上送报文格式及规范不合法、目标地址错误、被目标端基于某种策略的主动拒绝”等原因。
2. 报文发送成功后，确认是否收到ESB返回，未收到ESB返回的原因可能有“返回网络问题、上送与返回回执关系错误、单向接口无返回”等原因。
3. 收到ESB返回后，确认是否成功解析报文，根据ESB定义的接口协议、规范及标准进行解析。
4. 解析成功后，最终确认检查点是否验证成功。根据预先定义的配对预期结果检查点，确认返回报文中对应信息的匹配性。

1. 报文结构测试

根据上文“报文通讯测试”中涉及到的解析报文，展开说明“报文结构测试”。报文结构一般测试点包含：

1. 上送报文头、报文体结构是否正确？
2. 返回报文头、报文体结构是否正确？
3. 接口字段中是否包含空格？
4. 接口字段是否与约定存在差异（多或少）？
5. 每个业务级字段是否都包含了返回值？
6. 涉及循环结构的测试是否覆盖？
7. 涉及多层结构嵌套的，是否测试到每个层级（及最深层级）？
8. 上送及返回报文最大长度测试等。

1. 字段值返回测试

通过设置与业务场景所对应的预期结果检查点，与实际结果比对后进行字段值返回测试。测试点主要包含如：

1. 特定定长字符类型，长度不足是否左填0；
2. 预期与实际结果是否一致；
3. 多个预期值的“并且”与“或”满足关系；
4. 特定金额类型，是否增加小数点，格式化金额；
5. 日期时间格式是否一致等。

图2-2 预期结果与实际结果比对

1. 错误码返回测试

企业服务总线一般提供三种类型错误码形式：1、平台级封装错误码；2、应用级透传错误码；3、应用级mapping（映射）错误码。

对于第一种错误码测试，一般为平台层面（系统、环境、解析）等触发场景，如“发送数据异常、接收数据异常、连接异常、连接关闭、拼报错误、解析错误、调用服务异常、调用服务超时、组件异常、交易超时”等。有些如“组件异常、连接关闭”等需要与技术配合一同修改测试环境部分代码适配测试。如“交易超时”则可通过设置测试环境特定请求返回较长时间模拟，或者不做返回处理。本类测试暂不涉及业务层面测试。

后面二种错误码测试，为接口业务级测试。第二种透传的测试重点是能够接收并传递被调服务系统的返回错误代码及错误信息，并保证按照统一规范输出，特别注意返回信息的完整性（是否被截位）。第三种mapping测试需要核对映射关系，一般的映射关系有“数据库、文件、联动交易”等形式触发。多数的映射关系采用非实时模式进行批量更新及加载，以减轻系统实时压力。映射关系测试的重点，为“映射源的一致性对照、匹配重复情况下的唯一映射、多映射源的优先级、映射效能测试”等。

1. 其他测试

其他测试还包含如下：

1. 字段命名规范；
2. 接口代码命名规范；
3. 必输域及条件必输域测试；
4. 上送及返回数据类型；
5. 上送及返回长度边界测试；
6. 同步异步模式测试；
7. 其他企业服务总线封装的特定功能测试等。

• 测试场景运用

上文介绍了企业服务总线的一些通用测试方法，本章将介绍围绕企业服务总线，从测试驱动角度触发的一些具体场景运用。

1. 界面不可见信息测试

测试过程中往往根据界面（渠道）上的可见信息，通过测试输入及信息获取进行相关测试或比较。但由于如下等情况，部分重要信息可能处于界面不可见：

1. 后台系统的操作标志，如“新增、修改、删除”等；
2. 页面间跳转传递的唯一标识/信息；
3. 根据监管要求，需要（超出界面范围）多送的字段，待后续审计；
4. 根据登记簿及相关日志查询需要，需要（超出界面范围）多送的字段；
5. 获取交互行为及操作的重要埋点信息；
6. 系统间传递及约定的标识信息等。

如此类信息出现在报文的上下文中，则可以通过围绕企业服务总线下的标准进行相关接口测试，获取上送、返回信息。可通过模拟报文，或查看日志等方式进行重要信息的检索及收集。

1. 作为唯一数据准备入口

受限于测试环境的局限性，数据准备不能完全通过UI等系统交互形式进行准备。相关涉及系统，由于“环境及网络、权限控制、前端校验、功能未完全开发完毕”等原因，无法进行数据准备。通过围绕企业服务总线下的标准接口，进行数据准备，很好的解决了这些问题。可以在相关系统操作交互及业务模式不是完全了解的情况下，通过接口的方式进行唯一的数据准备入口。

1. 获取相关外部测试信息

部分测试中涉及的外部系统，如“直连商户系统、支付系统、政府及公安网、企业内部的总分系统、第三方批量代扣代缴平台”等。涉及外部系统数据（多数情况下）无法通过本地相关系统直接进行相关测试基准信息的展示及获取。可通过围绕企业服务总线约定下标准接口的方式提前进行相关测试信息获取，为后续测试预期结果建立及与实际结果比对提供重要基准信息。

1. 流程测试场景

测试过程中接口测试同业务测试一样，存在多个场景/交易间的信息传递，称之为流程接口测试场景。如下场景举例：

• 接口的输出是后续接口的输入；
• 接口的输入是后续接口的输出；
• 接口的输出是后续接口返回的预期结果比较基准；
• 接口的输入是后续接口返回的预期结果比较基准；

流程测试场景中，通过“请求信息”或者“获取的返回信息”作为基准值。将此基准值作为下一个接口的输入，进行流程传接。通过最终测试结果返回，根据基准值（或者按照特定逻辑加工的基准值）进行测试结果的比较，评估测试的正确性。

图3-1 流程接口测试场景

1. 其他场景

其他场景运用还包括：

1. 对于渠道界面较难模拟的测试场景，可通过发送接口的方式进行快速批量测试请求，以提升测试效能；
2. 测试环境中可能无法通过真实手机接收动态验证码，可通过查看返回报文的方式，查看并获取动态验证码进行测试；
3. 渠道在获取返回信息时，可能存在错位、失真及截取等情况，通过同步获取接口中对应原始返回信息，进一步提升测试准确性；
4. 对于渠道操作，如短时间内重复提交两次等场景，在无法确认数据是否重复入库的情况下，可通过检查上送报文的发送次数，确认相关控制逻辑。

• 总结

随着越来越多的金融机构采用企业服务总线并按照其自身特点进行演变及扩展，对应的测试解决方案不断在实践过程中得以归纳、规范、提升。从围绕企业服务总线进行单一的测试，逐渐转变为通过测试驱动企业服务总线进行多场景、多系统的打通及融合，更好的进行全流程测试。同时各实施金融机构需要同步建设以企业服务总线为主要对象的自动化接口测试平台，以满足日益频繁的测试任务及需求，使得测试手段及测试方法得到进一步提升，最终提升测试效能及企业服务总线全链路系统质量。