CN105279090A - 应用于金融领域的测试脚本生成方法和装置 - Google Patents

Abstract

本发明实施例公开了一种应用于金融领域的测试脚本生成方法和装置。该方法包括：获取匹配用户所指定交易码的交易报文，该报文由数据字典中对应该交易码的交易相关数据组合形成，所述交易相关数据用于描述完成所述交易码所指定交易的规则和内容；从多种协议脚本配置文件中选择与用户所指定协议相匹配的协议脚本配置文件；组合所述交易报文、协议脚本配置文件以形成与用户所指定协议相匹配的协议脚本；将所述协议脚本转换为具有目标测试工具的测试脚本文件属性的测试脚本。本发明实施例能够减少人工参与度，从而降低对测试人员的专业依赖程度，并缩短脚本开发过程。

Description

应用于金融领域的测试脚本生成方法和装置

技术领域

本发明涉及金融系统软件测试技术领域，特别涉及应用于金融领域的测试脚本生成方法和装置。

背景技术

随着全球金融业务的不断扩展，中国的银行系统的IT总体架构也在发生变化。银行系统的稳健性、可靠性和可维护性越来越受重视。因此，软件测试的重要性也越发凸显。

目前，软件测试不仅包括功能指标测试，还包括非功能指标(例如响应时间和并发性)测试。目前，能够进行软件测试的工具有多种，例如，惠普公司发布的LoadRunner性能测试工具，其可通过模拟实际用户的操作行为，实施并发负载及性能监测的方式，来获取待测软件系统的非功能性指标。

目前脚本的开发的方式主要依赖于测试人员，即测试人员根据集成平台测试脚本的语法语义规范，选择不同的协议进行脚本的开发。发明人在实施本发明创造的过程中，发现现有的脚本开发方式人工参与度较高，从而导致一系列问题，例如：准确性依赖于测试人员的专业素质，测试人员需要学习并掌握目标测试工具(例如LoadRunner)的脚本开发规范，并熟知多种脚本接口与多种通信协议之间的对应关系；速度慢导致开发时间过长，且容易出错。

发明内容

有鉴于此，本发明提供了一种应用于金融领域的测试脚本生成方法和装置，以减少人工参与度，从而降低对测试人员的专业依赖程度，并缩短脚本开发过程。

为实现上述目的，本发明提供如下技术方案：

一种应用于金融领域的测试脚本生成方法，包括：

获取匹配用户所指定交易码的交易报文，该报文由数据字典中对应该交易码的交易相关数据组合形成，所述交易相关数据用于描述完成所述交易码所指定交易的规则和内容；

从多种协议脚本配置文件中选择与用户所指定协议相匹配的协议脚本配置文件；

组合所述交易报文、协议脚本配置文件以形成与用户所指定协议相匹配的协议脚本；

将所述协议脚本转换为具有目标测试工具的测试脚本文件属性的测试脚本。

在研究上述技术方案的过程中，发明人通过对各种协议的测试脚本的结构进行详细分析，把不同协议的测试脚本均分为有共性部分和差异化部分，将其中所述有共性部分抽象为交易报文，将其中差异化部分为抽象为协议脚本配置文件。即将测试脚本的生成过程分为：交易报文获取过程，协议交配配置文件选择过程和测试脚本产生过程。每个过程均可由电子设备自动执行，即：通过预先设置的数据字典匹配各种交易行为，能够针对用户随机输入的交易码确定出对应的交易相关数据，并根据交易相关数据组成所述交易报文；以及，根据用户指定的协议，选择与该协议相适配的协议脚本配置文件；以及，组合所述交易报文、协议脚本配置文件以形成与用户所指定协议相匹配的协议脚本；以及，根据目标测试工具的测试脚本属性，将所述协议脚本转换为具有目标测试工具的测试脚本文件属性的测试脚本。可以看出，本申请实施例人工参与程度较低，只需指定交易码和协议，其他步骤均可由电子设备自行运作，具有以下特点或优点：

1、可靠性较高

由于无需过多人工参与，因此其准确性无需依赖于测试人员的专业素质和工作态度，出错概率较小；

2、开发成本较低

测试人员只需指定交易码和协议，无需学习并掌握目标测试工具(例如LoadRunner)的脚本开发规范，也无需熟知多种脚本接口与多种通信协议之间的对应关系。

3、开发速度较高

开发过程主要由机器自动操作，速度较快。

优选的，上述方案可按照以下步骤获取匹配用户所指定交易码的交易报文：

接收交易码；

从预设数据字典中读取匹配该交易码的交易相关数据，所述交易相关数据用于描述完成所述交易码所指定交易的规则及内容；

组合所述交易相关数据形成所述交易报文。

优选的，上述方案中，所述交易相关数据至少包括接口规范、报文字段和通用域字段。

优选的，上述方案中，所述交易相关数据还包括：数据库字段映射关系，用于指示交易报文中的字段与所述数据库中的数据集合的对应关系；

在所述组合所述交易相关数据形成交易报文后，所述方法还包括：

参考所述数据库字段映射关系，从数据库中确定数据集合，对所述交易报文中待参数化字段进行参数化处理。

优选的，上述方案中，所述目标测试工具为LoadRunner，所述交易报文为XML报文，所述具有目标测试工具的测试脚本文件属性的测试脚本包括：脚本初始化部分、脚本头部和脚本实体，其中：

脚本头部包括脚本的注释信息，该注释信息由XML报文和脚本配置文件中的参数字段组合形成；

所述脚本实体由存储于API接口参数内的XML报文和从脚本配置文件中获取的脚本模板基础元素生成。

优选的，上述方案还包括报文语法语义验证过程、交易连通调试过程和配置报文注释过程中的任意一个或者任意组合，其中：

所述报文语法语义验证过程包括：

对所述测试报文进行语法和语义方面的验证，在验证不通过时，发出提示信息；

所述交易连通调试过程包括：

向承载所述目标测试工具的服务器发出连接请求以建立连接，若连接失败，返回交易失败字符，否则，发送测试脚本；以及，判断发送是否成功，若是，则监听并接收返回报文，否则，返回交易失败字符；以及，通过所述返回报文判断交易是否成功，若是，返回交易成功字符，否则，返回交易失败字符；

所述配置报文注释过程包括：

配置报文注释，以提高测试脚本的可读性。

本申请同时还提供一种应用于金融领域的测试脚本生成装置，以实现上述测试脚本生成方法，该装置包括：

交易报文获取单元，用于获取匹配用户所指定交易码的交易报文，该报文由数据字典中对应该交易码的交易相关数据组合形成，所述交易相关数据用于描述完成所述交易码所指定交易的规则和内容；

配置文件选取单元，用于从多种协议脚本配置文件中选择与用户所指定协议相匹配的协议脚本配置文件；

协议脚本生成单元，用于组合所述交易报文、协议脚本配置文件以形成与用户所指定协议相匹配的协议脚本；

脚本转换单元，用于将所述协议脚本转换为具有目标测试工具的测试脚本文件属性的测试脚本。

优选的，上述装置还包括参数化单元，用于参数化所述交易报文。

优选的，上述装置还包括报文语法语义验证单元、交易连通调试单元和配置报文注释单元中的任意一个或者任意组合，其中：

所述报文语法语义验证单元用于：对所述测试报文进行语法和语义方面的验证，在验证不通过时，发出提示信息；

所述交易连通调试单元用于：向承载所述目标测试工具的服务器发出连接请求以建立连接，若连接失败，返回交易失败字符，否则，发送测试脚本；以及，判断发送是否成功，若是，则监听并接收返回报文，否则，返回交易失败字符；以及，通过所述返回报文判断交易是否成功，若是，返回交易成功字符，否则，返回交易失败字符；

所述配置报文注释单元用于：配置报文注释，以提高测试脚本的可读性。

优选的，上述装置中，所述目标测试工具为LoadRunner，所述交易报文为XML报文，所述具有目标测试工具的测试脚本文件属性的测试脚本包括：脚本初始化部分、脚本头部和脚本实体，其中：

脚本头部包括脚本的注释信息，该注释信息由XML报文和脚本配置文件中的参数字段组合形成；

所述脚本实体由存储于API接口参数内的XML报文和从脚本配置文件中获取的脚本模板基础元素生成。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的测试脚本生成方法的流程图；

图2为本发明实施例提供的测试脚本生成方法中生成交易报文的流程图；

图3为本发明实施例提供的测试脚本生成方法中自动参数化的流程图；

图4为本发明实施例提供的测试脚本生成方法所应用的一种场景的示意图；

图5和图6为本发明实施例提供的测试脚本生成装置的结构示意图。

具体实施方式

为了方便读者理解，下面对本文所用到的一些专业术语进行解释说明：

性能测试：性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

测试脚本：指一个特定测试的一系列指令所形成的指令集，可以被测试工具所执行。

交易码：根据银行系统建模特性，每个系统所执行的交易分别用交易码进行唯一标识，即每个交易码唯一对应一个交易行为。

数据字典：指对数据的数据项、数据结构、数据流、数据存储、外部实体等进行详细的定义和描述。

API：ApplicationProgrammingInterface，即应用程序编程接口，是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。

正如前文背景技术所说，当前各大银行的IT系统数量繁多且采用的软硬件平台种类繁杂，并且IT系统数量呈逐年增加趋势。现有IT系统所采用的通信协议主要有Http通信协议，Socket通信协议和基于Tuxedo中间件的WSL通信协议。这意味着，依照现有的主要由人工编撰测试脚本的方式，测试人员需要熟知各种通信协议的规范和特点，然后针对各种通信协议的规范和特点有针对性地编撰测试脚本，开发周期较长。由此，本申请发明人通过大量的实验和研究，包括对当前银行的数据字典进行广泛深入的调研和总结，了解了不同平台、不同系统及不同通信协议报文之间的共同点和差异性，以及，各种目标测试工具(例如LoadRunner)的协议规范和特点，找到了一种能够自动生成测试脚本的方案。

该方案通过获取匹配用户所指定交易码的交易报文(该报文由数据字典中对应该交易码的交易相关数据组合形成，所述交易相关数据用于描述完成所述交易码所指定交易的规则和内容)；从多种协议脚本配置文件中选择与用户所指定协议相匹配的协议脚本配置文件，以及，组合所述交易报文、协议脚本配置文件以形成与用户所指定协议相匹配的协议脚本；以及，将所述协议脚本转换为具有目标测试工具的测试脚本文件属性的测试脚本。

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

请参考图1，为本方案一种实施例的流程图，包括以下步骤：

步骤S11、获取匹配用户所指定交易码的交易报文。

所述交易报文唯一对应一个交易码，用于承载该交易码所指定交易行为所需的数据(即交易相关数据)，一般的，是指用于描述完成该交易行为的规则和内容。

步骤S12、从多种协议脚本配置文件中选择与用户所指定协议相匹配的协议脚本配置文件。

目前金融IT系统包括运行不同通信协议的系统，例如运行HTTP协议的系统、运行Socket协议的系统和运行Tuxedo协议的系统(即基于Tuxedo中间件的WSL服务模式的系统)。本申请预先针对金融IT系统所运行的通信协议，设置相匹配的脚本配置文件，例如配置HTTP协议脚本配置文件，Socket协议脚本配置文件和Tuxedo协议脚本配置文件。

所述脚本配置文件包含脚本的基本信息，包括服务器IP及端口号、交易成功判断符等。

步骤S13、组合所述交易报文、协议脚本配置文件以形成与用户所指定协议相匹配的协议脚本。

可以认为，协议脚本配置文件是协议脚本的基本信息，交易报文为协议脚本的主体，基本信息加上主体即形成协议脚本。

协议脚本有以下几种：

HTTP协议脚本，包括vuser_init()文件、action.c文件和vuser_end()文件。

Socket协议脚本，包括vuser_init()文件、action.c文件、vuser_end()文件和data.ws文件。

Tuxedo协议脚本：包括vuser_init()文件、action.c文件和vuser_end()文件。

其中，action.c文件是协议脚本的脚本实体，主要包含发送请求报文、获取返回报文及判断交易成功与否的基本指令。

步骤S14、将所述协议脚本转换为具有目标测试工具的测试脚本文件属性的测试脚本。

将所述协议脚本转换为具有目标测试工具的测试脚本文件属性的测试脚本的具体方式可以是：将所述协议脚本导入目标测试工具规范脚本框架(即依据目标测试工具规范设置的脚本框架)，形成所述目标测试工具可执行测试脚本。

所述目标测试工具可以是LoadRunner或Jmeter或者其他软件测试工具。为了避免描述过于冗长而影响理解，下面的各实施例均以所述目标测试工具为LoadRunner为例进行阐述，本领域技术人员应能理解，遵从本申请的技术逻辑，在所述目标测试工具为其他软件(例如jmeter)时，只需调整细节部分，例如采用与测试工具连接的接口会有所不同，目标测试工具规范脚本框架也会有所差别，但这些差异对于本领域技术人员来说是显而易见的。

运行上述方法的机器一般是计算机。其可以通过下面几种可能的方式获取匹配用户所指定交易码的交易报文：

方式1、响应用户(即测试人员)输入的交易码，生成交易报文。

具体过程如图2所示，包括以下步骤：

步骤S21、接收用户输入的交易码。

用户通过计算机的人机交互接口，例如触摸屏、键盘或者鼠标，输入交易码。

步骤S22、从系统数据字典中读取匹配该交易码的交易相关数据。

所述数据字典包括：报文通用域字段、报文实体域字段、各域取值范围及默认值等。

本实施例可以通过HSSF(HorribleSpreadSheetFormat)提供的API接口，利用HSSFworkboot类对象，HSSFSheet类对象和HSSFCell类对象，读取Excel格式的数据字典。

所述交易相关数据可以包括接口规范、报文字段和通用域字段，这些字段大部分承载于数据字典中的报文通用域字段和报文实体域字段中，读取所述交易相关数据即是识别并读取报文通用域字段和报文实体域字段。

步骤S23、组合所述交易相关数据形成交易报文。

将步骤S22中从数据字典中读取出来的数据按照预设规则组合，形成XML交易报文。

并以字符流形式写到XXX.xml文件中，以方便下一步操作。

方式2、针对一些常用的交易，系统中预存有与交易码对应的交易报文，即可直接获取(即存在XML格式的报文)，或者仅作简单转换即可得到(例如存储的文件是txt格式的，将该文件转换为XML格式的文件即可)。

在实际工作过程中，本实施例提供的方法，在接收到用户指定的交易码之后，可以先查询是否有与该交易码相对应的交易报文，若有，则直接获取，若没有，则执行方式1所述流程以生成交易报文，并可进一步将该交易报文存储，以方便后续复用。

所述具有目标测试工具的测试脚本文件属性的测试脚本，即是所述目标工具所能执行的测试脚本。该测试脚本从结构上分为三部分：脚本初始化部分、脚本头部和脚本实体，其中：

脚本初始化部分主要完成脚本基本变量的定义、通信连接的建立等。LoadRunner的脚本初始化部分为其可执行脚本中的vuser_init()部分。

脚本头部主要包含脚本的注释信息，用于加强脚本的可理解性。包括项目计划编号(标注每次测试任务的唯一编号)、项目名称、交易名称、交易码、交易路径和开发协议等内容。

脚本实体主要包含脚本报文发送、返回报文接收及判断交易是否成功操作。

对于LoadRunner而言，其可执行测试脚本的脚本头部由XML报文和脚本配置文件中的参数字段组合形成，其可执行测试脚本的脚本实体由存储于API接口参数内的XML报文和从脚本配置文件中获取的脚本模板基础元素生成。LoadRunner可执行测试脚本的过程包括以下部分：

配置vuser_init()部分；

配置脚本头部：具体的，分配项目计划编号；通过脚本配置文件中的name字段获取项目名称；通过XML报文中通用域内的transname域，获得交易名称；通过XML报文中的通用域内的transcode域获得交易码；通过脚本配置文件中的Path字段获取交易路径；通过脚本配置文件中的Protol字段获取开发协议。

配置脚本实体：

将XML报文作为字符流存储在用于发送请求报文的API接口参数内，并从脚本配置文件中获取脚本模板基础元素，包括服务器IP、端口、交易判断字符及runtime-setting设置等，生成Action.c部分和vuser_end部分。

可以看出，本申请实施例由于无需过多人工参与，因此其准确性无需依赖于测试人员的专业素质和工作态度，出错概率较小；并且，测试人员只需指定交易码和协议，无需学习并掌握目标测试工具(例如LoadRunner)的脚本开发规范，也无需熟知多种脚本接口与多种通信协议之间的对应关系，省去学习成本。开发过程主要由机器自动操作，速度较快。

需要说明的是，上述各实施例中，步骤S23所生成的交易报文中各字段均可为默认值。在另外某些实施例中，可能需要配置多元化报文字段阈值，这种情况下，按照本领域技术的常规教导，可通过手动方式在数据库中获取相应字段的数据后，倒入到测试脚本中实现数据字段参数化(即配置报文字段阈值)，或者进一步针对上述各实施例的描述，将相应字段的数据填写入所述步骤S23所生成的交易报文中的相应字段。发明人在此基础上进行了进一步的思考和分析，提供了自动字段参数化的方案，即自动实现对交易报文中某个或者某些字段的配置。自动字段参数化的过程可以如图3所示，包括下步骤：

步骤S31、确定交易报文中需要参数化的目标字段。

确定字需要参数化的字段的方式可以是根据用户指定，例如可以提供给用户一个显示所有可参数化的字段的界面，由用户在该界面上进行选择；也可以根据用户之前输入的交易码进行选定，例如，针对某些交易行为，交易报文中的某些字段通常需要配置，这时，如果交易码确定，则需要参数化的字段也就相应确定了。

步骤S32、查询数据字典中与所述目标字段对应的数据库字段名。

本实施例中，数据字典不仅包括报文通用域字段、报文实体域字段、各域取值范围及默认值，还包括用于指示交易报文中待参数化字段与数据库字段名之间的对应关系。

步骤S33、查询数据库，获取与该数据库字段名相匹配的表结构。

该表结构中存储有与该数据库字段名对应的数据集合。

所述数据集合一般以.dat为后缀，例如xx.dat文件。

步骤S34、将该数据集合导入到所述交易报文中所述目标字段，实现对所述目标字段的参数化。

本发明实施例通过在数据字典中设置报文字段与数据库字段名之间的对应关系，巧妙地将数据库中的数据集合与报文字段进行绑定，从而使得参数化过程无需人工参与(例如人工查找数据集合)，方便、快捷且准确。

在其他实施例中，在上述各实施例所提供的方案基础上，还可以包括报文语法语义验证过程、交易连通调试过程和配置报文注释过程中的任意一个或者任意组合，其中：

所述报文语法语义验证过程包括：

对所述测试报文进行语法和语义方面的验证，在验证不通过时，发出提示信息。

所述交易连通调试过程包括：

向承载所述目标测试工具的服务器发出连接请求以建立连接，若连接失败，返回交易失败字符，否则，发送测试脚本；以及，判断发送是否成功，若是，则监听并接收返回报文，否则，返回交易失败字符；以及，通过所述返回报文判断交易是否成功，若是，返回交易成功字符，否则，返回交易失败字符。

所述配置报文注释过程包括：配置报文注释，以提高测试脚本的可读性。

上述各实施例所提供的方法可以承载于电子设备，尤其是智能化电子设备，例如计算机或者具有人机交互界面的设备。图4为本方法所应用的场景，其中，计算机41响应测试人员42的指示，启动测试脚本生成过程。并在测试脚本生成后发往承载有测试工具的服务器43，由测试工具执行该测试脚本。计算机41与服务器43之间可以通过数据线连接，也可以通过网络连接，该网络可以是局域网或者互联网。

为了描述方便，所述计算机41中用来实施上述各实施例所提供的方法的功能部件称为测试脚本生成装置。该测试脚本生成装置的一种逻辑结构如图5所示，包括：交易报文获取单元51、配置文件选取单元52、协议脚本生成单元53和脚本转换单元54，其中：

所述交易报文获取单元51，用于获取匹配用户所指定交易码的交易报文，该报文由数据字典中对应该交易码的交易相关数据组合形成，所述交易相关数据用于描述完成所述交易码所指定交易的规则和内容。用户指定交易码的方式可以是用户通过人机交互界面输入。

所述配置文件选取单元51，用于从多种协议脚本配置文件中选择与用户所指定协议相匹配的协议脚本配置文件。

所述协议脚本生成单元52，用于组合所述交易报文、协议脚本配置文件以形成与用户所指定协议相匹配的协议脚本。

脚本转换单元53，用于将所述协议脚本转换为具有目标测试工具的测试脚本文件属性的测试脚本。

在一些实施例中，还可以包括用于对交易报文中某些字段进行参数化的功能单元，如图6所示，测试脚本生成装置的另外一些实施例，在图5所示结构的基础上，进一步包括参数化单元61，用于确定交易报文中需要参数化的目标字段，查询数据字典中与所述目标字段对应的数据库字段名，以及，查询数据库，获取与该数据库字段名相匹配的表结构，最后，将该数据集合导入到所述交易报文中所述目标字段，实现对所述目标字段的参数化。

此外，在其他实施例中，还可以包括一些辅助功能单元，例如：

报文语法语义验证单元，用于对所述测试报文进行语法和语义方面的验证的，在验证不通过时，发出提示信息；

所述交易连通调试单元，用于向承载所述目标测试工具的服务器发出连接请求以建立连接，若连接失败，返回交易失败字符，否则，发送测试脚本；以及，判断发送是否成功，若是，则监听并接收返回报文，否则，返回交易失败字符；以及，通过所述返回报文判断交易是否成功，若是，返回交易成功字符，否则，返回交易失败字符；

配置报文注释单元，用于配置报文注释，以提高测试脚本的可读性。

需要说明的是，上述测试脚本生成装置用于执行前文所述测试脚本生成方法，该装置中的各单元的功能的具体实现，例如交易报文如何获取，协议脚本如何形成，如何转换为测试脚本，以及交易报文的结构、内容，测试脚本的结构和内容等，都可以参照前文方法部分中的内容。

通过上述内容，本申请所提供的生成测试脚本的方案总的来说，具有以下优点或特点：

1、可靠性较高

由于无需过多人工参与，测试人员只需提供简单信息，例如交易码，或者选定协议，其他工作均由设备自行运作，准确性无需依赖于测试人员的专业素质和工作态度，出错概率较小。

2、开发成本较低

测试人员只需指定交易码和协议，无需学习并掌握目标测试工具(例如LoadRunner)的脚本开发规范，也无需熟知多种脚本接口与多种通信协议之间的对应关系，省去对这些复杂的知识的学习过程。降低测试人员的专业门槛。

3、开发速度较高

开发过程主要由机器自动操作，速度较快。

4、具有较好的通用性和扩展性

通过配置协议配置文件，交易报文及数据字典，屏蔽各种测试工具规范及协议所带来的差异性，具有较好的通用性；

此外，在需要使用新的测试工具进行测试时，只需添加响应的协议配置文件，在数据字典中添加适配该测试工具的内容，即可进行测试，无需测试人员进一步学习新测试工具的规范、特点，无需改变测试脚本的生成流程，扩展性较好。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种应用于金融领域的测试脚本生成方法，其特征在于，包括：

获取匹配用户所指定交易码的交易报文，该报文由数据字典中对应该交易码的交易相关数据组合形成，所述交易相关数据用于描述完成所述交易码所指定交易的规则和内容；

从多种协议脚本配置文件中选择与用户所指定协议相匹配的协议脚本配置文件；

组合所述交易报文、协议脚本配置文件以形成与用户所指定协议相匹配的协议脚本；

将所述协议脚本转换为具有目标测试工具的测试脚本文件属性的测试脚本。

2.根据权利要求1所述的方法，其特征在于，按照以下步骤获取匹配用户所指定交易码的交易报文：

接收交易码；

从预设数据字典中读取匹配该交易码的交易相关数据，所述交易相关数据用于描述完成所述交易码所指定交易的规则及内容；

组合所述交易相关数据形成所述交易报文。

3.根据权利要求1或2所述的方法，其特征在于，所述交易相关数据至少包括接口规范、报文字段和通用域字段。

4.根据权利要求3所述的方法，其特征在于：

所述交易相关数据还包括：数据库字段映射关系，用于指示交易报文中的字段与所述数据库中的数据集合的对应关系；

在所述组合所述交易相关数据形成交易报文后，所述方法还包括：

参考所述数据库字段映射关系，从数据库中确定数据集合，对所述交易报文中待参数化字段进行参数化处理。

5.根据权利要求1所述的方法，其特征在于，所述目标测试工具为LoadRunner，所述交易报文为XML报文，所述具有目标测试工具的测试脚本文件属性的测试脚本包括：脚本初始化部分、脚本头部和脚本实体，其中：

脚本头部包括脚本的注释信息，该注释信息由XML报文和脚本配置文件中的参数字段组合形成；

所述脚本实体由存储于API接口参数内的XML报文和从脚本配置文件中获取的脚本模板基础元素生成。

6.根据权利要求1所述的方法，其特征在于，还包括：报文语法语义验证过程、交易连通调试过程和配置报文注释过程中的任意一个或者任意组合，其中：

所述报文语法语义验证过程包括：

对所述测试报文进行语法和语义方面的验证，在验证不通过时，发出提示信息；

所述交易连通调试过程包括：

向承载所述目标测试工具的服务器发出连接请求以建立连接，若连接失败，返回交易失败字符，否则，发送测试脚本；以及，判断发送是否成功，若是，则监听并接收返回报文，否则，返回交易失败字符；以及，通过所述返回报文判断交易是否成功，若是，返回交易成功字符，否则，返回交易失败字符；

所述配置报文注释过程包括：

配置报文注释，以提高测试脚本的可读性。

7.一种应用于金融领域的测试脚本生成装置，其特征在于，包括：

交易报文获取单元，用于获取匹配用户所指定交易码的交易报文，该报文由数据字典中对应该交易码的交易相关数据组合形成，所述交易相关数据用于描述完成所述交易码所指定交易的规则和内容；

配置文件选取单元，用于从多种协议脚本配置文件中选择与用户所指定协议相匹配的协议脚本配置文件；

协议脚本生成单元，用于组合所述交易报文、协议脚本配置文件以形成与用户所指定协议相匹配的协议脚本；

脚本转换单元，用于将所述协议脚本转换为具有目标测试工具的测试脚本文件属性的测试脚本。

8.根据权利要求7所述的装置，其特征在于，还包括参数化单元，用于参数化所述交易报文。

9.根据权利要求7或8所述的装置，其特征在于，还包括：报文语法语义验证单元、交易连通调试单元和配置报文注释单元中的任意一个或者任意组合，其中：

所述报文语法语义验证单元用于：对所述测试报文进行语法和语义方面的验证，在验证不通过时，发出提示信息；

所述交易连通调试单元用于：向承载所述目标测试工具的服务器发出连接请求以建立连接，若连接失败，返回交易失败字符，否则，发送测试脚本；以及，判断发送是否成功，若是，则监听并接收返回报文，否则，返回交易失败字符；以及，通过所述返回报文判断交易是否成功，若是，返回交易成功字符，否则，返回交易失败字符；

所述配置报文注释单元用于：配置报文注释，以提高测试脚本的可读性。

10.根据权利要求7或8所述的装置，其特征在于，所述目标测试工具为LoadRunner，所述交易报文为XML报文，所述具有目标测试工具的测试脚本文件属性的测试脚本包括：脚本初始化部分、脚本头部和脚本实体，其中：

脚本头部包括脚本的注释信息，该注释信息由XML报文和脚本配置文件中的参数字段组合形成；

所述脚本实体由存储于API接口参数内的XML报文和从脚本配置文件中获取的脚本模板基础元素生成。