第6章 类FIX协议应用案例
在智能一体化测试平台推广过程中，经常会遇到一些使用特定协议的系统，需要进行一些个性化开发才能够使用平台进行测试。这类系统采用的协议本质上或基于Socket协议，或基于HTTP协议，为更好地支持这类协议，往往会对其进行一定地封装，以方便测试人员快速设计测试案例。
本章以银行交易系统常见的FIX协议作为案例，介绍如何在智能一体化测试平台中对新的协议进行二次开发。通过本章的讲解，读者将掌握面对新的协议时，如何基于智能一体化测试平台快速完成对新系统的测试。
6.1 类FIX协议介绍
6.1.1 类FIX协议说明
FIX协议是由国际FIX协会组织提供的一个开放式协议，目的是推动国际贸易电子化的进程。FIX协议的目标是把各类证券金融业务需求流程格式化，使之成为一个个可用计算机语言描述的功能流程，并在每个业务功能接口上统一交换格式，方便各个功能模块的连接。
FIX协议是一种开放的信息交换控制标准，它的一般格式是一个标准头加上后续的多个信息域，以一个标准尾结束。信息格式中的数据域与其在本信息中的位置无关。每个信息域以ACSCII码1（以下用<SOH>表示）作为域结束符。
类FIX协议的实质是一个二维的数据表，包含了记录数、字段数、字段名等信息。它在实现上参照了FIX协议，保留了FIX协议中扩充性好、按名取值的优点，又没有像FIX协议那么复杂，所以比较适合用于各种数据交换的接口。与FIX一样，它也是由若干个信息域组成，域中的内容均为字符串，每个域以<SOH>作为域结束符。其中第一个域表示字段数（列数），第二个域表示记录数（行数），从第三个域开始是字段名（列名），每个字段名占一个域，之后是字段数据区。字段的顺序可以改变，如某字段不存在，表示为空值，字段名本身区分大小写，字段名长度不超过20个字符。
6.1.2 类FIX结构示意和举例
类FIX结构的格式如下：
列数<SOH>行数<SOH> 列名1<SOH>列名2<SOH>...<SOH>列名n<SOH> 数据1<SOH>数据2<SOH>...<SOH>数据n<SOH> 数据1<SOH>数据2<SOH>...<SOH>数据n<SOH> ...... 数据1<SOH>数据2<SOH>...<SOH>数据n<SOH> |
其中<SOH>代表“Start Of Heading”，即报头开始，其值为ASCII表中的1，十六进制为\x01。在实际的报文中，<SOH>为不可见字符，因此并不会显示成“<SOH>”字符串。
类FIX结构的报文示例如下：
5<SOH>2<SOH> CustomerName<SOH>Account<SOH>AccountType<SOH> Code<SOH> Message<SOH> 张三<SOH>1234 5678 4321 8765<SOH>1<SOH>0000<SOH>交易成功<SOH> 李四<SOH>6789 0123 0987 7876<SOH>2<SOH>0000<SOH>交易成功<SOH> |
示例是一个虚拟的用户账号信息查询服务的返回报文：第一行表示包含五个字段，两条返回记录；第二行标识所有的字段名；第三行和第四行是返回的两条记录。
6.2 测试需求分析
6.2.1 现有处理方案
类FIX协议本质上是采用Socket协议进行通信的方式，因此智能一体化测试平台的Socket协议的接口处理方式，能够支持类FIX协议接口的测试。与Socket协议相比，关键环节中的数据模板的编写、车间的创建、案例的编写和调试、场景的创建和执行并没有本质区别，但是由于类FIX协议格式的特殊性，存在下面两个问题：
●由于类FIX协议中的特殊字符<SOH>（\x01），用户编写报文模板时，需要添加特殊字符，同时还要计算报文长度，这个过程非常耗费时间且容易出错。图6-1是一个报文模板的例子，可见其编写较为复杂。
图6-1 现有处理方式下的类FIX模板示例
●从返回报文中获取返回成功标识符或某些重点关注的字段值，比较困难。即使通过“起始位置|偏移量”、“左边界|右边界”、“标识符|偏移量|长度”等方式将其勉强取出，也存在可能由于返回报文字段长度变化或者字段顺序变化导致的取值失效问题出现，因此现有处理方案并不是最佳方案。图6-2所示例子中，如果获取ErrorNo对应的“9999”错误标识码，采用“起始位置|偏移量”方式，设置为“97|4”；若采用“标识符|偏移量|长度”，设置为“ErrorNo|67|4”；无法采用“左边界|右边界”，因为左侧的SerialNo是不断变化的。即使采用前两种方式，也存在由于返回字段顺序变化而造成的取值无效的风险。
图6-2 现有处理方式下的类FIX响应报文示例
综合如上的分析，可以看出现有Socket协议处理方案针对笔者遇到的类FIX协议接口，并不是理想的处理方案。
6.2.2 工具需求设想
既然现有的Socket协议处理方案针对类FIX协议的处理并不理想，我们是否可以分析类FIX协议的报文特点，给出一种特殊的处理方式？答案是肯定的：我们在前一小节中发现的问题，可以通过对工具进行个性化开发来解决。
我们可以从如下两方面考虑：
（1）降低模板编写的复杂度，对用户屏蔽报文格式的拼装过程，由程序依据类FIX协议特点自动来完成。
（2）返回报文进行格式化的解析，组装成字段名=字段值的形式，方便用户提取字段值，展示起来也更加清晰。
对于类FIX协议，针对以上两个主要需求，我们可以进行定制化的开发，在智能一体化测试平台增加对类FIX协议的支持。
6.3开发方案定制
为了在智能一体化测试平台新增对类FIX协议的支持，为其定制了开发方案。该方案涉及配置中心、工具中心、数据中心、事务中心、运行中心、界面添加与改造等几个主要方面。通过这几个方面的定制开发要达到如下效果：模板创建界面中仅需要输入相关字段名即可完成模板的创建；结果字段的获取也仅仅需要给出输出字段名即可；发送报文的拼装和返回报文的解析均在后台自动完成。
●配置中心
实际推广中遇到的类FIX协议，通讯包的包头为Q008*****（*****为包体的长度，前补0）,如包体长度168，通讯包头即为Q00800168。为此，需要在现有测试车间配置的通用属性基础上，新增类FIX协议测试车间属性：包头长度、是否包含包头、固定部分长度、固定部分内容，然后在车间配置代码中，增加对新增配置属性的读取和保存。
默认测试车间新增配置项相关的代码如图6-3所示。
图6-3FIX协议默认车间配置新增属性代码片段示例
●工具中心
工具中心应为类FIX协议新增工具类FIXUtil，用来完成返回结果的格式化工作。其中formattedResponseData用来进行格式化后结果的展示；resultCollectionList是一个存取返回结果记录的Hashtable对象的列表，用来存取多组返回结果的字段名和字段值。主要代码片段如图6-4所示。
图6-4类FIX协议工具类代码片段示例
●数据中心
为类FIX协议新增数据模板类FIXTestDataTemplateUtil，并使其继承于TestDataTemplateUtil，重写其核心方法UpdateValueByHashTable，完成发送报文的拼装。核心代码如图6-5所示。
●事务中心
为类FIX协议新增事务执行结果类FIXTransactionExcuteResult，并使其继承于类XTransactionExcuteResult，重写其核心方法GetTransactionReturnedData，获取事务执行后的结果数据。核心代码如图6-6所示。
在单事务机器人类XSingleServiceExplorer和多事务机器人类XMultiServiceExplorer中，增加对类FIX协议返回结果类型“FIXData”的处理。核心代码片段如图6-7所示。
图6-5类FIX协议数据模板类代码片段示例
图6-6类FIX协议事务执行结果类核心代码片段示例
图6-7类FIX协议事务处理机器人类中新增代码片段
●界面的添加与改造
为支持类FIX协议，界面增加与改造主要涉及两部分：默认车间配置界面、模板创建编辑界面。
（1）改造默认车间配置界面，新增FIX协议支持，新增数据模板类型“FIX”，新增结果类型“FIXData”，如图6-8所示。
图6-8类FIX协议默认车间配置界面
（2）新增模板创建或编辑界面，在该界面仅需根据接口说明填写输入字段名称即可。如图6-9所示。
图6-9FIX模板创建编辑界面
本文选自《大型IT系统智能一体化测试》第六章，本站经电子工业出版社和作者的授权。
版权声明：51Testing软件测试网获电子工业出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
