CN104038605B - 电话pos支付终端交易测试的方法 - Google Patents

Abstract

一种电话POS支付终端交易测试的方法，包括以下步骤：A：交易测试平台对交易配置文件、通讯接口、配置文件处理模块和项目处理模块进行初始化；然后配置文件处理模块加载一交易配置文件中记录的配置信息；交易测试平台再根据所述配置信息中的项目名称信息，加载对应的项目处理模块；所述配置信息包括交易流程信息、项目名称信息、协议信息、校验开关信息、交易代码偏移量、加密数据信息和交易代码信息，以及每一交易代码所对应的测试案例；每所述测试案例均包含有测试数据和预期结果；B：交易测试平台与支付终端之间根据所述交易流程信息进行交易测试。本发明大大地轻测试系统的开发工作量和测试人员的测试工作量。

Description

电话POS支付终端交易测试的方法

技术领域

本发明具体涉及一种电话POS支付终端交易测试的方法。

背景技术

在目前广泛应用于各种大小商场、产品批发市场、小商户、各个银行分行的电话POS产品中，其主要的功能就是金融交易。在电话POS产品研发和生产的过程中，对其金融交易进行调试和测试是一个必不可少的阶段和过程。目前在电话POS产品的金融交易测试中，最常用的测试方法包括两种，第一种是连接各个银行的后台中心，进行实际的交易，这种方式的测试，存在以下几个缺点：1、银行的后台中心交易数据对于用户来说是不可见的，交易测试的过程中，无法及时通过交易数据实时发现电话POS终端存在的缺陷；2、银行的后台中心系统一般都很完善，不会给电话POS终端发送异常的报文数据，这会使测试人员忽略了一些电话POS由异常交易引起的缺陷；3、真实的交易过程中，需要使用到真实的银行账户等，会发生一些金钱上的交易，特别是进行一些大量的交易测试，会产生数额不菲的手续费和其他费用；4、在项目开发阶段，程序未完成开发，使用真实的平台进程调试和测试存在一定的困难。

第二种方法是开发相应的模拟银行后台中心的交易系统，这种方法的缺点在于开发相应的测试平台，也是需要投入大量的时间和人力资源的，目前基于银联电话POS支付终端规范协议的衍生版本非常多，不同的银行之间存在着一定的差异，当不同银行的项目增多时，需要开发测试平台也需要相应的增加，当同一个项目出现需求改动的情况下，平台也需要进行相应的改动，这都会耗费相当多额外的时间和人力资源。

发明内容

本发明所要解决的技术问题在于提供一种电话POS支付终端交易测试的方法，实现方便快捷地模拟交易测试。

本发明是通过以下技术方案解决上述技术问题的：一种电话POS支付终端交易测试的方法，先配置一交易测试平台、复数个交易配置文件和支付终端；所述支付终端与交易测试平台通过通讯接口连接；所述交易测试平台包括配置文件处理模块和复数个项目处理模块；

该方法具体包括以下步骤：

步骤A：交易测试平台对交易配置文件、通讯接口、配置文件处理模块和项目处理模块进行初始化；然后配置文件处理模块加载一交易配置文件中记录的配置信息；交易测试平台再根据所述配置信息中的项目名称信息，加载对应的项目处理模块；

所述配置信息包括交易流程信息、项目名称信息、协议信息、校验开关信息、交易代码偏移量、加密数据信息和交易代码信息，以及每一交易代码所对应的测试案例；每所述测试案例均包含有测试数据和预期结果；

步骤B：交易测试平台与支付终端之间根据所述交易流程信息进行交易测试；

当交易测试平台通过通讯接口接收到支付终端的交易请求数据包时，所述项目处理模块调用所述协议信息对交易请求数据包进行解析，调用校验开关信息对交易请求数据包进行校验，并根据加密数据信息对交易请求数据包的密钥数据进行校验；

步骤C：项目处理模块根据所述交易代码偏移量，从交易请求数据包中调用交易代码，再根据所述交易代码调用该交易代码所对应的测试案例，同时运用所述协议信息、校验开关信息和加密数据信息对所述测试案例中的测试数据进行处理和封装，生成应答数据包，由交易测试平台通过通讯接口发送给支付终端；

所述交易代码偏移量是指交易代码在交易请求数据包中的位置；

步骤D：支付终端对应答数据包解析处理后，执行应答数据包中的测试数据，并将测试结果反馈给交易测试平台；然后项目处理模块将测试结果与所述测试案例中的预期结果进行比对，完成对支付终端的交易测试过程。

进一步地，所述交易流程信息包含交易总步骤数、交易循环起始步骤、交易步骤类型、交易步骤接口、交易步骤时延和交易步骤重复次数信息，其具体的数字格式结构分别如下：

交易总步骤数＝N，且N为自然数；

交易循环起始步骤＝n，n为自然数，且1≤n≤N；

交易步骤m.类型＝发送或接收；

交易步骤m.接口＝项目处理模块中的一预设函数；

交易步骤m.时延＝时间；

交易步骤m.重复次数＝i，且i为正整数；

所述m为自然数，且1≤m≤N。

进一步地，所述交易配置文件的格式为“.ini”格式文件。

本发明的有益效果在于：在实现方便快捷地模拟电话POS支付终端交易测试的前提下，同时可以兼容不同银行的项目，大量的减轻测试系统的开发工作量和测试人员的测试工作量。

附图说明

下面参照附图结合实施例对本发明作进一步的描述。

图1为本发明电话POS支付终端交易测试的方法的原理框图。

图2为本发明电话POS支付终端交易测试的方法的操作流程图。

具体实施方式

请参阅图1，一种电话POS支付终端交易测试的方法，先配置一交易测试平台、复数个交易配置文件和支付终端；所述支付终端与交易测试平台通过通讯接口连接；所述交易测试平台包括配置文件处理模块和复数个项目处理模块；

交易测试平台的主要功能是初始化交易配置文件、通讯接口、配置文件处理模块和项目处理模块，接收和发送交易数据；交易配置文件用于存储项目测试时需要用到的数据等；项目处理模块的主要功能是处理交易请求数据包，对数据包的业务层进行解析，但项目处理模块不进行实际的交易操作，不会操作实际的账户中的金额等。

电话POS交易的通讯方式共包含五种：(1)传统的电话线路通讯，电话线路通讯通过语音卡和交易测试平台对接；(2)Modem方式的HDLC(高级数据链路控制)方式的通讯，经过路由器或者网控器处理之后，走网络线路与交易测试平台对接；(3)无线网络通讯；(4)有线网络通讯；(5)串口通讯。因此所述通讯接口包含语音卡接口、网络接口、串口接口。

请再参阅图1和图2，该方法具体包括以下步骤：

步骤A：交易测试平台对交易配置文件、通讯接口、配置文件处理模块和项目处理模块进行初始化；然后配置文件处理模块加载交易配置文件中记录的配置信息；交易测试平台再根据所述配置信息中的项目名称信息，加载对应的项目处理模块；

所述交易配置文件的格式为“.ini”格式文件，所述配置信息包括交易流程信息、项目名称信息、协议信息、校验开关信息、交易代码偏移量、加密数据信息和交易代码信息，以及每一交易代码所对应的测试案例；每所述测试案例均包含有测试数据和预期结果；

不同的项目，分别对置有一交易配置文件和项目处理模块，给定一个交易配置文件，就相当于指定了项目处理模块，交易配置文件记录有项目名称，交易测试平台只要加载与交易配置文件记录中的项目名称一致的项目处理模块。

在测试一个产品时，需要预先配置好的测试案例，测试案例是由测试数据和说明信息组成的，即标注出执行了这个测试案例之后，期望得到的结果。如果支付终端执行了一个测试案例之后，得到的结果和测试案例中标注的期望结果不一致，说明产品存在某种问题；如果得到的结果和案例中标注的结果一致，那么在当前测试案例描述的情况下，这个产品可以完成这个功能。

步骤B：交易测试平台与支付终端之间根据所述交易流程信息进行交易测试；

当交易测试平台通过通讯接口接收到支付终端的交易请求数据包时，项目处理模块调用所述协议信息(协议是指“中国银联电话支付终端规范”和“中国银联银联卡受理终端应用规范”)对交易请求数据包进行解析，调用校验开关信息对交易请求数据包进行校验，并根据加密数据信息对交易请求数据包的密钥数据进行校验；

步骤C：项目处理模块根据所述交易代码偏移量，从交易请求数据包中调用交易代码，再根据所述交易代码调用该交易代码所对应的测试案例，同时运用所述协议信息、校验开关信息和加密数据信息对所述测试案例中的测试数据进行计算处理和封装，生成应答数据包，由交易测试平台通过通讯接口发送给支付终端；

所述交易代码偏移量指的是交易代码在交易请求数据包中的位置，是对不同的协议所总结出的一个位置标识，同一个项目的交易请求数据包偏移量是固定的。

步骤D：支付终端对应答数据包解析处理后，执行应答数据包中的测试数据，并将测试结果反馈给交易测试平台；然后项目处理模块将测试结果与所述测试案例中的预期结果进行比对，并将产生的过程日志信息和测试结果记录到日志文件和测试报告中，完成对支付终端的交易测试过程。

所述交易流程信息包含交易总步骤数、交易循环起始步骤、交易步骤类型、交易步骤接口、交易步骤时延和交易步骤重复次数信息，其具体的数字格式结构分别如下：

交易总步骤数＝N，且N为自然数；即总共的交易步骤数为6。

交易循环起始步骤＝n，n为自然数，且1≤n≤N；即交易未结束，从步骤n继续开始。

交易步骤m.类型＝发送或接收，m为自然数，且1≤m≤N；即第m个步骤类型，为平台发送数据或接收数据。

交易步骤m.接口＝项目处理模块中的一预设函数；即第m个步骤接口，调用项目处理模块中某一具体的函数，如名称为send_link的函数。

交易步骤m.时延＝时间；即第m个步骤时延，在预设的时间内处理该步骤的工作。

交易步骤m.重复次数＝i，且i为正整数；即第m个步骤若处理不成功，再重复处理的次数i，次数可以随时调整。

上述m为自然数，且1≤m≤N。

例1：某个银行项目的中，交易的协议包含81,82,83,84,87五种类型的数据包。其中从支付终端发往交易测试平台的数据包类型有82,83,87三种类型，从交易测试平台发往支付终端的数据包类型有81,83,84三种类型，其交易顺序为：81->82->87->83->84->83，即交易测试平台下发类型为81的数据包，支付终端应答82类型的数据包，支付终端继续发送87类型的数据包，交易测试平台应答83类型的数据包，交易测试平台发送84类型的数据包，支付终端应答83类型的数据包，如果交易未结束，继续从87类型的数据包开始，否则交易结束。那么此时，交易流程的配置如下：

TotalStep＝6(交易总步骤数为6)；

LoopStep＝2；(交易未结束继续从步骤2开始)；

Step1.type＝SEND(第1个步骤类型，为交易测试平台发送数据)；

Step1.fun＝send_link(第1个步骤接口，调用项目处理模块中名称为send_link的接口，即项目处理模块是名称为“send_link”的函数)；

Step1.ctime＝3000ms(第1个步骤时延，在3000毫秒的时间内处理该步骤的工作，时间可以随时调整)；

Step1.times＝3(第1个步骤如果处理不成功，再重复处理的次数，3次，处理次数可以随时调整)；

Step2.type＝RECV(第2个步骤类型，为交易测试平台接收支付终端的数据)；

Step2.fun＝recv_link(第2个步骤接口，调用项目处理模块中名称为recv_link的接口，即名称为“recv_link”的函数)；

Step2.ctime＝300ms(第2个步骤时延，在300毫秒的时间内处理该步骤的工作)；

Step2.times＝1(第2个步骤如果处理不成功，再重复处理的次数，1次)

Step3.type＝RECV(第3个步骤类型，为交易测试平台接收支付终端的数据)；

Step3.fun＝recv_pack(第3个步骤接口，调用项目处理模块中名称为recv_pack的接口，即名称为“recv_pack”的函数)；

Step3.ctime＝300ms(第3个步骤时延，在300毫秒的时间内处理该步骤的工作)；

Step3.times＝1(第3个步骤如果处理不成功，再重复处理的次数，1次)

Step4.type＝SEND(第4个步骤类型，为交易测试平台发送数据)；

Step4.fun＝send_pack_ack(第4个步骤接口，调用项目处理模块中名称为send_pack_ack的接口，即名称为“send_pack_ack”的函数)；

Step4.ctime＝300ms(第4个步骤时延，在300毫秒的时间内处理该步骤的工作)；

Step4.times＝1(第4个步骤如果处理不成功，再重复处理的次数，1次)

Step5.type＝SEND(第5个步骤类型，为交易测试平台发送数据)；

Step5.fun＝send_pack(第5个步骤接口，调用项目处理模块中名称为send_pack的接口，即名称为“send_pack”的函数)；

Step5.ctime＝300ms(第5个步骤时延，在300毫秒的时间内处理该步骤的工作)；

Step5.times＝1(第5个步骤如果处理不成功，再重复处理的次数，1次)

Step6.type＝RECV(第6个步骤类型，为交易测试平台接收支付终端的数据)；

Step6.fun＝recv_pack_ack(第6个步骤接口，调用项目处理模块中名称为recv_pack_ack的接口，即名称为“recv_pack_ack”的函数)；

Step6.ctime＝300ms(第6个步骤时延，在300毫秒的时间内处理该步骤的工作)；

Step6.times＝1(第6个步骤如果处理不成功，再重复处理的次数，1次)

例2：某个银行项目的交易协议比较简单，只有84和87两种类型的数据包，87包为支付终端上送给交易测试平台的数据包，84包为交易测试平台下发给支付终端的数据包，交易为87->84，即支付终端上送交易请求数据，交易测试平台处理成功应答结果，依次循环。遵循例1的规则，只需要将交易流程稍作修改，配置如下：

TotalStep＝2(交易总步骤数为2)；

LoopStep＝1(交易未结束继续从步骤1开始)；

Step1.type＝RECV(第1个步骤类型，为交易测试平台接收支付终端数据)；

Step1.fun＝recv_pack(第1个步骤接口，调用项目处理模块中名称为recv_pack的接口，即名称为“recv_pack”的函数)；

Step1.ctime＝3000ms(第1个步骤时延，在3000毫秒的时间内处理该步骤的工作)；

Step1.times＝3(第1个步骤如果处理不成功，再重复处理的次数，3次)；

Step2.type＝SEND(第2个步骤类型，为交易测试平台发送数据)；

Step2.fun＝send_pack(第2个步骤接口，调用项目处理模块中名称为send_pack的接口，即名称为“send_pack”的函数)；

Step2.ctime＝300(第2个步骤时延，在300毫秒的时间内处理该步骤的工作)；

Step2.times＝1(第2个步骤如果处理不成功，再重复处理的次数，1次)

本发明具有以下优点：

1、摆脱了对银行真实交易平台的依赖，实际交易过程中，不会发生实质性的金钱交易；

2、测试兼容多个银行的项目，兼容多种类型的终端；只需要通过简单的修改交易流程配置，更换不同的项目处理模块中的预设函数，即可以完成对符合银联电话支付终端规范项目的兼容测试；一个平台可以支持多个项目，多种终端的交易测试。目前在本公司测试使用中，已经支持了七种型号的终端近二十多个项目的测试；

3、降低测试人员的测试工作量，研发人员开发测试平台的工作量；测试人员只要简单地修改交易配置文件中的交易流程信息，即可实现交易的测试，由于平台之间的兼容性，一次学习，即掌握其他项目的测试方法，研发人员不再需要针对项目开发相应的平台，只需要进行稍加修改即可，同时可以使用于初期项目的调试使用。

Claims (3)

1.一种电话POS支付终端交易测试的方法，其特征在于：先配置一交易测试平台、复数个交易配置文件和支付终端；所述支付终端与交易测试平台通过通讯接口连接；所述交易测试平台包括配置文件处理模块和复数个项目处理模块；

该方法具体包括以下步骤：

步骤A：交易测试平台对交易配置文件、通讯接口、配置文件处理模块和项目处理模块进行初始化；然后配置文件处理模块加载一交易配置文件中记录的配置信息；交易测试平台再根据所述配置信息中的项目名称信息，加载对应的项目处理模块；

所述配置信息包括交易流程信息、项目名称信息、协议信息、校验开关信息、交易代码偏移量、加密数据信息和交易代码信息，以及每一交易代码所对应的测试案例；每所述测试案例均包含有测试数据和预期结果；

步骤B：交易测试平台与支付终端之间根据所述交易流程信息进行交易测试；

当交易测试平台通过通讯接口接收到支付终端的交易请求数据包时，所述项目处理模块调用所述协议信息对交易请求数据包进行解析，调用校验开关信息对交易请求数据包进行校验，并根据加密数据信息对交易请求数据包的密钥数据进行校验；

步骤C：项目处理模块根据所述交易代码偏移量，从交易请求数据包中调用交易代码，再根据所述交易代码调用该交易代码所对应的测试案例，同时运用所述协议信息、校验开关信息和加密数据信息对所述测试案例中的测试数据进行处理和封装，生成应答数据包，由交易测试平台通过通讯接口发送给支付终端；

所述交易代码偏移量是指交易代码在交易请求数据包中的位置；

步骤D：支付终端对应答数据包解析处理后，执行应答数据包中的测试数据，并将测试结果反馈给交易测试平台；然后项目处理模块将测试结果与所述测试案例中的预期结果进行比对，完成对支付终端的交易测试过程。

2.如权利要求1所述的电话POS支付终端交易测试的方法，其特征在于：

所述交易流程信息包含交易总步骤数、交易循环起始步骤、交易步骤类型、交易步骤接口、交易步骤时延和交易步骤重复次数信息，其具体的数字格式结构分别如下：

交易总步骤数＝N，且N为自然数；

交易循环起始步骤＝n，n为自然数，且1≤n≤N；

交易步骤m.类型＝发送或接收；

交易步骤m.接口＝项目处理模块中的一预设函数；

交易步骤m.时延＝时间；

交易步骤m.重复次数＝i，且i为正整数；

所述m为自然数，且1≤m≤N。

3.如权利要求1所述的电话POS支付终端交易测试的方法，其特征在于：所述交易配置文件的格式为“.ini”格式文件。