基于WOSA_XFS标准的金融设备自动化测试平台的设计与实现

陈群 王怀杰

摘要：论文介绍了WOSA/XFS标准的概念，WOSA/XFS标准的体系结构，为测试平台的设计与实现奠定了技术基础；在对平台进行了详细的需求分析的基础上，确定了平台的整体框架，完成了用户界面的设计，解决了数据传输的问题。最后实现了测试平台，在真实的测试环境下表明，该文设计的基于WOSA_XFS标准的金融设备自动化测试平台的可用性，有效性达到了设计时的要求。

关键词：WOSA/XFS标准；自动化测试平台；金融设备；测试软件

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2015）06-0059-03

The Design and Implementation of the Test Platform of Financial Equipment Based on WOSA_XFS

CHEN Qun1， WANG Huai-jie2

（1.College of Computer Science and Technology， University of South China，Hengyang 421001， China； 2.Hunan Sunny Technology Engineering Co.，Ltd，Hengyang 421001， China）

Abstract： This paper introduces the concept of WOSA/XFS standard， the system structure of WOSA/XFS standard， the design and implementation of the testing platform. On the basis of a detailed analysis of the platform， the whole frame of the platform is defined， and the design of the user interface is finished. Finally， the test platform is implemented in the real test environment. The paper designs the availability of the WOSA_XFS standard.

Key words： WOSA_XFS standard；test platform；financial equipment；software testing

随着我国金融电子化建设的发展，有越来越多的银行机构希望在购买金融外设（VTM）的时候能够购买各个厂商的硬件，然后自己组装成一台完整的VTM机，这样就可以避免对单一厂商的依赖，而且有更多的选择。为了实现不同供应厂商提供的设备之间的兼容，从而定制了一套适用于银行系统的扩展标准--WOSA/XFS标准。因此，设计一套金融设备自动化测试平台是非常必要的。

1 相关技术介绍

1.1 WOSA概述

WOSA（全称是Windows开放式系统体系结构 Windows Open System Architecture），是微软公司提出的一种在Windows操作系统下的软件架构 WOSA/XFS是基于WOSA的扩展金融服务（Windows Open System Architecture/ Extensions for Financial Services），是微软公司为全球金融行业软件提出的一种软件架构，它在WOSA软件架构的基础上针对全球金融行业进行了一些相应的修改。

1.2 WOSA/XFS

XFS（Extensions for Financial Services）是1991年由Microsoft公司在WOSA软件架构的基础上针对全球金融行业进行的一些相应扩展修改的体系结构，是一个允许不同硬件供应商的金融自助外围设备连通性的标准。XFS是开发独立硬件程序的开放式标准。XFS的要素包括，一套的API函数的定义，与之对应的SPI函数定义，可以支持的服务，和基于Win32的金融服务程序提供的通道。它定义一套标准的接口，可以使程序通过调用API函数与不同厂商提供的设备进行通信。二者结合就称之为WOSA/XFS。

2 平台的设计与实现

2.1 平台的设计

为了方便而透彻的描述平台的设计，将以逻辑架构和物理架构两个维度来展开论述平台的设计理念。

2.1.1 逻辑架构

测试平台逻辑架构如下图1所示。整个测试平台是基于Windows操作系统，逻辑上主要分为五大功能部分：测试用例管理、自动化测试总控、测试结果分析和评价、测试用例辅助开发、测试配套模拟服务。这五大功能部分各司其职，组成整个测试平台解决方案。

从逻辑层次上看，测试平台向测试用例提供服务。测试平台统一管理测试用例，调度执行测试用例，并提供测试用例所需要的资源。

自动化测试总控的软件实体是测试执行系统TestRunner，负责调度管理测试用例，向测试用例提供所需资源或接口。测试结果分析和评价的软件实体是测试专家系统TestExpert，负责测试结果的展示、统计分析和评价；测试用例辅助开发预留到后期开发，主要是辅助二次开发者更快速地开发测试用例；测试配套模拟服务的软件实体在目前来说是模拟P和模拟SP。

2.1.2 物理架构（或网络架构）

如下图2所示，7×24小时服务器中部署的有模拟P、测试专家系统TestExpert（测试资源管理和测试结果存储分析等）；测试虚拟机中部署的有测试执行器TestRunner、模拟SP、测试脚本还有被测对象（例如：ATMC）；而测试者工作站主要是查看測试报告和编写自动化测试用例；

1）首先测试者开发自动化测试用例，将测试用例打包到7×24小时服务器；

2）当需要测试时，测试者将测试包、被测对象（例如ATMC）、模拟SP、测试执行系统TestRunner一同加载到测试虚拟机；

3）在虚拟机上启动执行测试包，TestRunner被启动运行，当需要银行P端介入的测试由服务器端的模拟P替代；

4）TestRunner将正在测试用例产生的测试结果提交到TestExpert服务器系统中；

5）TestExpert服务器存储测试结果并分析测试结果产生测试报告；

6）测试者、QA或其他用户可以在自己的工作台上通过浏览器查看测试报告和测试统计分析报告等数据；

2.2 平台的实现

平台的核心实现基于两个个领域的开发，分别是自动化测试用例开发，设备插件开发。

2.2.1 自动化测试用例开发

自动化测试用例就是自动化测试执行的测试用例，其实体就是基于测试平台中的TestRunner系统运行的Python脚本，统称为测试用例包。

自动化测试用例通过在被测对象（系统）上模拟各类操作，同时对操作流程中的节点进行监控，对相关参数进行读取设定和判断，从而实现对被测对象（系统）进行自动化检查测试，并对测试结果进行判断、记录保存。自动化测试用例的开发是根据测试用例对被测对象（系统）整体流程的具体操作要求，选取操作过程中需要检查和监控的检查点，进而实现对系统功能的测试。

测试用例的功能特点：正常、异常测试全面覆盖；可对各类命令（XFS）输入、输出参数做精确地设定和检查；测试过程无人员干预，排除人为因素测试结果真实可靠

以下这些接口函数是测试脚本的实现测试功能的基本：

1）TestPlugins.WaitForRequest（'设备名'， '命令名'， 时间）：此函数设置当前等待（监控）的响应命令，设定时间内成功命中后返回 0。

2）TestPlugins.WaitForResponse（'设备名'， '命令名'， 时间）：此函数设置当前等待（监控）的返回命令，设定时间内成功命中后返回 0。

3）TestPlugins.GetValue（'设备名'， '命令名'，'输入/出参数名'）：此函数设置获取命令的输入/出参数值，获取成功后返回 命令参数字符串。

4）TestPlugins.SetValue（'设备名'， '命令名'，'输入/出参数名'）：此函数设置设置命令的输入/出参数值，设置成功后返回 0。

5）TestPlugins.AllowResponse（'设备名'， '命令名'，True）：此函数用在WaitForRequest后面时，代表允许设备响应命令；用在WaitForResponse后面时，代表允许设备回应命令（一般会有输出参数返回）。

6）设备插件开发

设备插件是基于TestRunner系统的，为完成自动化测试用例与设备之间的数据交互而设计的。

7）設备插件

如下图3所示，测试用例（Test Case）如果需要控制被测对象（Under Unit Test，UUT），并监控被测对象（UUT）的输入和输出，则需要通过与被测对象交互的设备或模拟设备（Device/Sim Device）建立联系。其中Plugins表示的就是设备插件，它帮助测试用例（Test Case）与被测对象（UUT）之间建立测试控制和测试数据传输，从而达到不修改被测对象就可以测试到被测对象的目的（黑盒测试）。TestRunner负责管理0至多个设备插件。

8）测试控制和测试数据传输

测试控制：同步测试时机，修改、获取测试数据或执行测试所需的命令。例如：当被测对象ATMC向SP读卡设备读取卡数据时（也就是设备接收数据时），测试用例希望获得该时机，以便作修改卡数据等其它测试控制操作。

测试数据传输：将测试时被测对象与设备之间产生的交互数据根据测试用例所需传输给测试用例。

9）插件工作原理

我们需要测试某个被测对象时（黑盒测试），一方面是检测被测对象的输出数据是否符合预期，另一方面是注入相应的被测对象输入数据检查被测对象的响应是否符合预期。那么测试用例在判断输出数据和注入输入数据时如何与被测对象同步？测试用例又如何拿到输出数据和注入输入数据？这就需要插件与设备之间配合完成了。

TestRunner在开始测试之前将会调用插件的Init接口初始化插件，将在TestRunner主程序退出时调用插件的Exit接口。基于该机制，请作好插件的资源的管理。在开始测试之前，初始化插件之后，TestRunner需要通过GetDeviceName接口来获取插件管理的设备名称（设备名称必须唯一）。

在测试执行时，测试用例将通过TestRunner使用以下几个接口：

1）WaitForRequest：测试用例等待被测对象（Under Unit Test）向设备请求时机（同步机制）

2）WaitForResponse：测试用例等待设备响应被测对象（Under Unit Test）时机（同步机制）

3）AllowResponse：测试用例允许设备向被测对象回应数据

4）SetValue：测试用例需要修改设备与被测对象之间的请求/响应值

5）GetValue：测试用例需要获取设备与被测对象之间的请求/响应值

6）ExecuteCmd：测试用例执行设备某条命令

3 平台的运行与测试

3.1 平台的运行

平台的运行主要分为三步： 提交或下载测试用例包；执行自动化测试；生成或查看测试报告。其中第二步最为关键，我们把自动化测试平台起名为蝴蝶（butterfly），旨在将所有虫子（bug）变为美丽的蝴蝶。整个蝴蝶软件由界面，后台应用两部分组成。

3.1.1 蝴蝶界面

首先蝴蝶软件的启动必须验证测试人员的权限，方便日后管理与记录，测试人员必须输入账号与密码验证权限无误后方可登录蝴蝶软件，而这条登录操作也会上传到专家系统，与登录者绑定的还有测试生成的错误日志，日志产生的时间等等，这些记录也会一并上传到专家系统，为日后的错误分析，硬件分析打下了坚实的基础。权限通过后便可以进入蝴蝶软件，软件具体样式如图4所示：

首先展示在页面两边的为一边四个对称的按钮，每个按钮都具有不同的不可替代的功能，从测试操作顺序上讲：

1）选择：选择你要测试机型的测试用例。

2）启动：启动整个蝴蝶软件进行测试，代表一次测试的开始。

3）暂停：此按钮是非必要按钮，测试人员可以中途暂停/恢复测试，显得更加人性化。

4）重测：当一次测试检测出硬件的错误而停止（NG）后，可以点击重测按钮进行重新测试。

5）停止：测试人员可以手动停止（NG）测试。

6）提交：一次测试停止（NG）后，测试人员可以点击提交按钮将错误原因，日志等信息上传到专家系统。

7）退出：退出蝴蝶软件。

8）关于：蝴蝶开发人员和版本信息。

3.1.2 后台应用

蝴蝶软件运行的核心就是后台应用，主要后台应用有两个：TestRunner，PackUpLoad。

1）TestRunner

TestRunner整合了所有测试所要用到的部分，包含了测试用例模块管理和加载测试用例、初始化python环境、连接数据库、定义测试记录对象、初始化插件管理器、启动执行服务模块、加载测试计划、启动测试用例包的测试，总共8个步骤。

2）PackUpLoad

PackUpLoad中文译作日志打包上传，主要在执行TestRunner之后并检测到了硬件的错误的情况下，蝴蝶软件会调用PackUpLoad，将sp，TestRunner，Plugin的日志一并打包上传到专家系统（TestExpert）。

3.2 平台的测试

平台的测试重要侧重于四个方面：exception，fail，pass。Exception表示硬件有异常情况，但不妨碍测试，不代表测试失败；fail表示硬件有故障直接导致测试结束；pass表示测试通过。

平台在测试过程中发生的三种场景和相对应的测试结果，其中详细记录了唯一确定一台金融设备的SN序列号、测试场景（老化前，老化中，老化后）、开始时间、耗时、测试人、通过率、结果这七大信息。

关于测试平台在去年（2014年）十一月初到十二月初大概一整个月的测试结果如下图5所示：

4 结束语

随着金融业务的电子化向更高，更深层次的发展，硬件设备日益发挥着重要的作用，同时计算机技术也在飞速的发展，各种技术推陈出新，也为金融设备的应用提供了很好的平台，WOSA/XFS标准的出现实现了多种硬件产品能够兼容，更加迅速地适应了金融市场的需求与变化。为了保证硬件设备良好 的运行，解决模块测试分散，测试力度不够的问题。设计并实现这一测试平台，为提高效率，降低测试成本，持续提升产品質量保驾护航。

参考文献：

[1] WOSA/XFS的介绍[EB/OL].http：//www.zahui.com/html/1/3403.html.

[2] 信怀义. 基于WOSA/XFS标准的ATMC软件应用[J]. 中国金融点脑， 2007（5）： 64-65.

[3] 2004年中国银行业信息化建设与IT应用趋势研究报告[M]. 北京： 中国计算机世界出版社， 2005： 3-7.

[4] Dela Rue， DIEBOL，IBM，NCR，SUN，WINCOR，NIXDORF.Financial Device interface for J/XFS Administrator Guide[Z]， 2002： 20-154

[5] CEN Workgroup Agreement[Z]. Extensions for Financial Services （XFS）interface specification， 1998.

[6] 普拉达. C++ Primer Plus[M]. 张海龙， 袁国忠， 译.6版.北京： 人民邮电出版社， 2015.