CN102053872A - 一种终端交易性能测试方法 - Google Patents

Abstract

本发明公开了一种终端交易性能测试方法，其测试工具包括客户端、数据库、服务端，由用户在客户端制作交易模板和测试案例并将其存储于数据库，在测试时由服务端接收测试命令并处理如下：a、从数据库将交易模板和测试案例装载至内存池；b、初始化用于从内存池中抽取交易的抽取算法；c、启动与收单平台、加密机的通讯连接；d、按需设置各通讯链路；e、作为终端处理交易；f、计算当前时间和进行上一次统计的时间间隔是否大于等于统计周期，并在满足条件时根据统计周期输出交易统计信息；g、返回步骤d循环处理和通讯交互的交易。使用本方法进行性能测试能支持多层级关联交易、真实模拟实际交易情形并保证测试的持续性。

Description

一种终端交易性能测试方法

【技术领域】

本发明涉及一种终端交易性能测试方法，尤其涉及一种能够较真实地模拟实际银行卡交易并且保证测试持续性的终端交易性能测试方法，属于银行卡交易仿真测试技术领域。

【背景技术】

随着银行卡的推广和普及，人们使用各种终端(例如，POS机、ATM机、自助终端、移动支付终端等)来支付消费的行为日益普遍。因此，除了普通交易外，例如消费撤销、消费冲正、退货、预授权完成、预授权完成撤销、预授权完成撤销冲正等等这些关联交易也越来越多的发生。银行卡信息交换系统下的收单平台，作为处理上述交易的主要平台，不但要求运行稳定、高效，而且在发生大量的关联交易(例如，在出现网络异常后再恢复时存在大量的冲正交易)时仍要求保证其能运行在相同的性能水平。

关联交易(或称为后续交易)一般会引起与原始交易相反的资金流向，因此要求收单平台能够准确找出其原始交易并予以处理。此外，还要在该原始交易上打上标记，以禁止其他的关联交易再对该交易进行处理，例如在发生网络异常时，终端可能在发送冲正交易后并未获得收单平台的应答，所以终端再次上送冲正交易来处理同一笔原始交易，这样在网络恢复后收单平台可能会收到两笔冲正，因此要求只能对原始交易进行一次资金冲销处理。另外，关联交易也可以有自己的关联交易，因此收单平台在收到关联交易的关联交易(或称为后续的后续交易)时，需要对最初的原始交易进行标记处理，例如消费交易在收到消费撤销后被打上已撤销的标记，如果又收到了消费撤销冲正则又需要将消费交易设置成是可撤销的。

综上可见，在发生关联交易时会引起收单平台的一连串操作，其所承受的性能压力较大，因此在现有的性能测试中，测试工具往往基于提高自身性能的考虑而针对实际交易采用不记数据库、不记文件的方法来向收单平台发送交易，但是这样处理的一个缺点是无法上送关联交易，因为原始交易信息完全被直接丢弃了。然而，如果测试工具采用与收单平台相同的处理方式，即也采用数据库记录交易的方式，那么将会造成测试工具自身性能的较大程度地下降，结果将会困惑用户：测试数据的下降究竟是由于收单平台性能下降导致的，还是由于测试工具的性能下降导致的？而且，为了支持测试工具的本身性能，就需要一系列配套软硬件的投入、额外的人力资源的投入，因此整体消耗是巨大的，也是不经济的。所以，现有的性能测试工具的特性决定其无法上送更接近交易实情的交易。对此，开发人员只能在进行系统开发时，大致估算关联交易消耗资源相对于普通交易消耗资源的一个比例系数，然后照此扩大需求对收单平台的性能要求，以期保证收单平台在实际工作环境下也能承受同样的交易压力。但是，上述做法显然是有风险的：一方面这种估算的精确度不高，从而新系统上线前要花费大量的精力来降低风险的发生(例如，延长并行测试的时间以尽量发现问题等)；另一方面，无法对新系统在各种情况下的性能瓶颈做全面的描述，从而在现有技术下也就无法使用目前的生产数据及其交易趋势图来准确评估新系统的效力(例如，当某一种或几种关联交易占到总交易的10％时，性能瓶颈可能在应用程序，而当某一种或几种关联交易占总交易量的20％时，瓶颈可能就在磁盘读写)。

此外，值得注意的是在真实的交易环境中，每天都有数十万个终端(或称为发送方)在上送交易，收单平台(或者其他的交易转换平台)出于安全和业务需要，必须管理这些终端的状态。例如，不允许签退的终端再做交易；终端收到批结应答后需要上送批上送报文以和收单平台对账，并且批结后的终端需要更改自身的批次号以和收单平台保持同步；签到的终端必须同步收单平台下发的密钥等等。所以，要在性能测试中模拟上述这些实际交易情形，是比较困难的。对此，现有技术通常采用两种方案来实现：①启动两个以上的性能测试工具进程并用每个进程模拟一个终端，该技术方案的优点在于被测系统收到的交易一般是终端和交易种类的混合搭配，但是缺点在于无法通过启更多的进程来真正实现数十万个终端的模拟量；②搭建两个性能测试工具进程，其中的一个进程只做普通交易、另一个进程只做引起终端状态变化的特殊交易，该技术方案的优点在于占用资源较少，只做特殊交易的终端由于每一笔交易都要导致终端状态重置，所以不需要在测试工具内实现控制终端做普通交易的业务逻辑，因而也不会导致测试工具性能的下降，但是其缺点是在收单平台收到的交易中，一部分终端只做普通交易、另一部分终端只做特殊交易，故交易种类和终端并不是混合搭配的，所以与交易的实际情况不吻合。由此可见，现有的测试技术方案均难以保证测试结果的准确性，并且它们都至少需要准备两个测试工具进程，因此操作过程比较复杂，当出现问题时也不易于排查定位。

【发明内容】

有鉴于此，本发明的目的在于提供一种终端交易性能测试方法，其能够较真实地仿真模拟实际银行卡交易并且保证测试性能和质量，以解决在现有的性能测试中存在的无法执行关联交易、不支持多层级的关联交易、难以真实地模拟实际交易情形、不能保证测试持续性等诸多问题。

为了实现上述的发明目的，本发明采用如下的技术方案：

一种终端交易性能测试方法，其用于测试系统性能的测试工具包括客户端、与所述客户端相连的数据库、以及与所述客户端和数据库均相连的服务端，由用户在所述客户端制作交易模板和测试案例并将它们存储于所述数据库，在测试时由所述服务端接收测试命令并按照如下的步骤进行处理：

a、从所述数据库将所述交易模板和所述测试案例装载至内存池；

b、初始化用于从所述内存池中抽取交易的抽取算法；

c、启动与收单平台、加密机的通讯连接；

d、根据需要设置各通讯链路；

e、作为终端处理交易；

f、计算当前时间和进行上一次统计的时间间隔是否大于等于统计周期，并在其大于等于所述统计周期时根据所述统计周期输出交易统计信息，所述统计周期被设定用于衡量系统处理交易的能力；以及

g、返回步骤d循环处理和通讯交互的交易。

优选地，在所述步骤f和步骤g之间还包括步骤：

fg、检测通讯链路，如果发现通讯断开则根据业务规则重新进行连接。

优选地，所述交易模板包括交易模板名称、交易的报文流、以及每一个关键域在所述报文流中的位置和长度，所述关键域由用户按需进行配置。

优选地，所述测试案例包括：案例集，其包括案例编号、所述收单平台的预期的每秒处理交易笔数、测试停止类型和测试停止值，所述测试停止类型被设为按时间停止或按交易笔数总量停止，所述测试停止值被设为测试总时间或测试总交易笔数；以及，案例明细，其包括案例编号、交易模板名称、原始交易明细和占比值，所述原始交易明细包括后续交易所对应的其在先交易的名称，所述占比值由用户按需进行配置，并且其对应于存在原始交易的后续交易是指被抽取作为数据源进行发送的后续交易在所述原始交易的应答中所占的比例，而对应于无原始交易的普通交易是指其在所述案例集的每秒处理交易笔数中所占的比例；每一个所述案例集至少下挂一笔所述案例明细。

优选地，所述抽取算法包括：普通交易抽取算法，其采用随机选择算法用于实现对应于所述普通交易的占比值；以及，关联交易抽取算法，其采用随机选择算法用于实现对应于所述后续交易的占比值。

优选地，所述步骤e中的所述服务端作为终端处理交易的步骤包括：

e1、判断收到的报文是否匹配所述案例明细中指定的原始交易明细所对应的应答报文：如果是，则进入步骤e2；否则，进入步骤e6；

e2、从所述报文中取出确定交易成败的关键域；

e3、根据所述案例明细判断交易属性是否为关联交易：如果是，则从所述应答报文获取原始交易关键域，然后进入步骤e4；否则，进入步骤e6；

e4、从所述内存池中抽取下一笔关联交易；

e5、判断步骤e3中所述关联交易对应的原始交易是否被抽中：如果是，则根据该关联交易对应的交易模板和获取的所述原始交易关键域组织关联交易报文，然后填写报文发送的缓冲池；否则，进入步骤e6；

e6、统计交易的成功笔数与失败笔数；

e7、释放所述应答报文占用的内存池；

e8、在所有普通交易案例明细中抽取下一笔交易的模板；

e9、根据被抽中的普通交易模板组织普通交易报文；以及

e10、填写报文发送的缓冲池。

优选地，所述案例集还包括发送速度，并且在所述步骤e和步骤f之间还包括步骤：

ef、从所述报文发送的缓冲池内读取请求报文，并判断记录于上一次统计所得交易统计信息中的发送交易总笔数是否小于按照所述测试案例的配置计算出的截止到当前应发送的交易总笔数：如果是，则增速发送存储于所述缓冲池中与各交易相对应的报文数据，否则以所述测试案例中指定的发送速度来发送存储于所述缓冲池中与各交易相对应的报文数据，以使得在所述缓冲池中存储的各交易的总数目不大于所述案例集的每秒处理交易笔数。

此外，本发明还采用如下的技术方案：

一种终端交易性能测试方法，其用于测试系统性能的测试工具包括客户端、与所述客户端相连的数据库、以及与所述客户端和数据库均相连的服务端，由用户在所述客户端制作交易模板、测试案例并将它们存储于所述数据库，并且所述数据库还存储有终端信息，在测试时由所述服务端接收测试命令并按照如下的步骤进行处理：

a、从所述数据库将所述交易模板、所述测试案例和所述终端信息装载至内存池；

b、初始化用于从所述内存池中抽取普通交易的普通交易抽取算法；

c、初始化所述终端信息；

d、启动与收单平台、加密机的通讯连接；

e、根据业务规则设置各通讯链路；

f、作为终端处理交易；

g、计算当前时间和进行上一次统计的时间间隔是否大于等于统计周期，并在其大于等于所述统计周期时根据所述统计周期输出交易统计信息，所述统计周期被设定用于衡量系统处理交易的能力；以及

h、返回步骤e循环处理和通讯交互的交易。

优选地，在所述步骤g和步骤h之间还包括步骤：

gh、检测通讯链路，如果发现通讯断开则根据业务规则重新进行连接。

优选地，所述终端信息包括密钥参数和交易状态，所述交易状态包括正常状态、已上送签到还未成功状态、已上送批结还未成功状态和签退状态。

优选地，所述交易模板包括交易模板名称、交易引起所述终端信息的交易状态发生改变的变化值、交易的报文流、以及每一个关键域在所述报文流中的位置和长度，所述关键域由用户按需进行配置。

优选地，所述测试案例包括：案例集，其包括案例编号、所述收单平台的预期的每秒处理交易笔数、测试停止类型和测试停止值，所述测试停止类型被设为按时间停止或按交易笔数总量停止，所述测试停止值被设为测试总时间或测试总交易笔数；以及，案例明细，其包括案例编号、交易模板名称、原始交易明细和占比值，所述原始交易明细包括后续交易所对应的其在先交易的名称，所述占比值由用户按需进行配置，并且对应于存在原始交易的后续交易是指被抽取作为数据源进行发送的后续交易在所述原始交易的应答中所占的比例，而对应于无原始交易的普通交易是指其在所述案例集的每秒处理交易笔数中所占的比例；每一个所述案例集至少下挂一笔所述案例明细。

优选地，所述步骤f中的所述服务端作为终端处理交易的步骤包括：

f1、判断收到的报文是否匹配所述案例明细中指定的原始交易明细所对应的应答报文：如果是，则进入步骤f2；否则，进入步骤f14；

f2、从所述报文中取出确定交易成败的关键域；

f3、根据所述案例明细判断交易属性：如果属于特殊交易则进入步骤f4，所述特殊交易包括签到、签退和批结；否则，进行关联交易处理，然后进入步骤f14；

f4、判断终端交易状态：如果是“已上送签到还未成功”，则进入步骤f5；如果是“已上送批结还未成功”，则进入步骤f10；

f5、判断是否成功应答：如果是，则进入步骤f6；否则，进入步骤f14；

f6、在内存池中查找终端信息；

f7、恢复当前终端的交易状态至正常状态；

f8、更新密钥；

f9、密码密文预处理，然后进入步骤f14；

f10、在内存池中查找终端信息；

f11、触发批上送处理；

f12、更新自身的批次号；

f13、恢复当前终端的交易状态至正常状态；

f14、统计交易的成功笔数与失败笔数；

f15、释放所述应答报文占用的内存池；

f16、在所有普通交易案例明细中抽取下一笔交易的模板；

f17、根据被抽中的普通交易模板组织普通交易报文；以及

f18、填写报文发送的缓冲池。

优选地，所述步骤f3中的所述关联交易处理步骤包括：

f31、从所述应答报文获取原始交易关键域；

f32、从所述内存池中抽取下一笔关联交易；以及

f33、判断步骤f31中所述关联交易对应的原始交易是否被抽中：如果是，则根据该关联交易对应的交易模板和获取的所述原始交易关键域组织关联交易报文，然后填写报文发送的缓冲池。

优选地，所述案例集还包括发送速度，并且在所述步骤f和步骤g之间还包括步骤：

fg、从所述报文发送的缓冲池内读取请求报文，并判断记录于上一次统计所得交易统计信息中的发送交易总笔数是否小于按照所述测试案例的配置计算出的截止到当前应发送的交易总笔数：如果是，则增速发送存储于所述缓冲池中与各交易相对应的报文数据，否则以所述测试案例中指定的发送速度来发送存储于所述缓冲池中与各交易相对应的报文数据，以使得在所述缓冲池中存储的各交易的总数目不大于所述案例集的每秒处理交易笔数。

使用本发明的终端交易性能测试方法的有益效果在于：

(1)本发明方法吸收了现有的性能测试不记数据库、不记入文件而具有较高执行性能的优点，本发明采用总是将最近一笔交易记入内存池的技术方案，从而有效地避免了丢失原始交易信息的弊端。

(2)本发明方法只将被记下的交易数据在指定的内存池保留一段时间，然后通过进行一个类似于抽奖的抽取算法，将被抽中作为关联交易的原始交易在提供完所需信息后就被丢弃出内存池空间，并且也将没有被抽中的原始交易丢弃以释放内存池空间，由此实现尽可能少占用资源、提供执行性能的目的。

(3)由于每一笔发送的关联交易只涉及内存池中被抽中的那一笔原始交易，因此对业务逻辑无需苛刻绑定，对交易类型并不敏感，所以能够在性能测试中支持多层级的关联交易测试，使得甚至多个层次之后的关联交易都可在同样一个程序逻辑中完成，不会因为业务逻辑的复杂而增加额外的处理消耗。

(4)本发明方法通过抽取算法使得各种交易在每秒发送的总量中占比是一个比例系数，而不是精确的；关联交易抽中原始交易的比例可以由用户配置，但同样也是一个比例系数，因此能够高度模拟实际的交易情形，能够通过测试而真实地反映出交易笔数的抖动对于收单平台的影响。

(5)本发明方法中的每秒处理交易笔数TPS(Transaction Per Second)是可以由用户根据实际需要而进行自由配置控制的，只有在某一段时间出现由于各种原因收单平台性能下降而后又恢复处理性能的情况下，将会在原有处理速度基础上增速处理(例如，增速1％)以追赶之前遗留下未予处理的交易笔数(或称为缺失交易笔数)，从而使得测试结果图形上形成U形，对此用户可根据当时的交易数据进行深入的分析。此外，这种做法使得内存池中最多只有和收单平台每秒处理交易笔数相同的交易，因此上送关联交易时要在数量有限的内存池中易于查询到自身的原始交易，而且不会影响到测试工具的性能，更不会由于测试工具的性能瓶颈而模糊了收单平台的性能瓶颈。通过应用本发明方法，可以实现性能稳定在每秒6000笔以上，摸高可到每秒10000笔，而相对于只能发送普通交易的性能测试，在每秒处理交易笔数上几乎没有任何下降。

(6)由于在本发明方法中内存池容量空间的设置仅与每秒处理交易笔数相关，其并不会因为完成交易数量的多寡而发生改变，因此应用本发明方法进行性能测试稳定可靠、持续性佳，即便测试几小时、几天也不会引起测试工具本身性能的下降。

(7)使用本发明方法可以在性能测试时支持多个终端以及将混合交易(特殊交易和其他交易)随机匹配发送，这使得用户可根据实际工作环境配置特殊交易比例以对被测系统的性能进行测试，并且在被管理的终端完成特殊处理流程后能够恢复成普通终端进行交易，这更符合在真实工作环境下大量终端进行交易的实际情形，同时也并不会影响原有的性能水平。

【附图说明】

以下将结合附图和实施例，对本发明的技术方案作进一步的详细描述。其中：

图1是使用本发明的终端交易性能测试方法进行性能测试所用测试工具的较佳实施例的构成关系示意图；

图2是在本发明的终端交易性能测试方法的一个较佳实施例中服务端进行处理的主流程图；

图3是在本发明的终端交易性能测试方法中使用抽取算法进行普通交易及关联交易抽取的示意图；

图4是图2中终端处理交易的较佳实施例的流程图；

图5是在本发明的终端交易性能测试方法的另一个较佳实施例中服务端进行处理的部分流程图，其仅示出了与图2的主流程图相区别的部分；

图6是本发明的终端交易性能测试方法又一个较佳实施例中服务端的处理流程图；以及

图7是图6中终端处理交易的较佳实施例的流程图。

【具体实施方式】

请参阅图1，它是使用本发明的终端交易性能测试方法进行性能测试所用测试工具的较佳实施例的构成关系示意图。如图1所示，本发明方法所用的性能测试工具包括三个部分：客户端1、服务端2和数据库3。其中，客户端1的作用在于：一是制作交易模板和测试案例并将它们存储于与客户端1相连接的数据库3中；二是将测试命令发到服务端2，从而触发测试的开始或停止(当然，也可以由用户在服务端2以命令行等方式触发测试)。对于服务端2，它是整个性能测试工具的核心，其与客户端1和数据库3均相连，并且在服务端2中通过将最近一笔交易记入内存池并保留一段时间，然后采用抽取算法将作为关联交易的原始交易抽中并在其提供完所需信息后即将它丢弃出内存池空间，同时也将没有被抽中的原始交易进行丢弃处理以进一步地释放出内存池空间，从而能够有效地保证测试的持续性。除了处理关联交易外，服务端2还能够实现交易发送和终端加密、终端状态管理等功能，这些内容都将在下文中通过优选的若干具体实施例进行详细的说明。

以上所述的交易模板包括交易模板名称、交易的报文流以及每一个关键域在报文流中的位置和长度，另外也还可以按需增加一些其他的字段(例如，描述某些需要的信息)。上述的关键域是指相对于被测系统来说，一个交易中最敏感的几个域，如果被测系统使用的报文规范不同，关键域的定义也有偏差，例如，通常包括唯一确定一笔交易的域(交易时间、系统跟踪号、受理机构、受理商户和终端号等等)、确定交易成败的域(交易应答码等)、业务域(授权类交易的授权码等)，至于在本发明方法中具体采用哪些域作为关键域则完全是由用户根据其需要进行灵活配置的。

另外，对于测试案例，它包括案例集和案例明细。其中，案例集包括案例编号、收单平台的预期的每秒处理交易笔数TPS、测试停止类型(按时间停止或按交易笔数总量停止)和测试停止值(测试总时间或测试总交易笔数)；案例明细则用于描述交易名称、原始交易名称，以此可以对交易属性(普通交易、关联交易或特殊交易)进行明确区分，其包括案例编号、交易模板名称、原始交易明细和占比值，每个案例集下挂至少一笔案例明细。上述的每秒处理交易笔数可以由用户按需进行配置，而原始交易明细则包括后续交易所对应的其在先交易的名称。对于占比值，用户也可以根据实际需要对其进行具体配置，并且占比值对应于存在原始交易的后续交易是指被抽取作为数据源进行发送的后续交易在所述原始交易的应答中所占的比例，而对应于无原始交易的普通交易是指其在所述案例集的每秒处理交易笔数中所占的比例；每一个所述案例集至少下挂一笔所述案例明细。以下以消费交易为例，在一个具体实例中将案例集、案例明细的配置情况列表如下(限于篇幅仅示出其中用于说明的部分字段)：

表一：案例集

TPS	测试停止类型	测试停止值
			3000	按时间停止	500秒

表二：案例明细

图2是在本发明的终端交易性能测试方法的一个较佳实施例中服务端2进行处理的主流程图。如该图2所示，服务端2在接收到测试命令后就按照如下的步骤进行具体处理：

首先，在步骤S101中，服务端2从数据库3将交易模板和测试案例装载至内存池；

然后，在步骤S101、S102中，分别初始化普通交易抽取算法、关联交易抽取算法，对于普通交易抽取算法，其采用随机选择算法用于实现上述的测试案例中对应于普通交易的占比值，而关联交易抽取算法也采用随机选择算法实现对应于后续交易的占比值(对此，可以参见以上所列举的关于消费交易的具体实例)。此外，再请参阅图3，它是使用上述抽取算法进行普通交易及关联交易抽取的示意图，以下进行具体描述：在图3中示意性地将100个案例装载入抽取池中并将其初始值均初始化设置为“-1”，而根据普通交易抽取算法以及用户的案例明细1和3的配置情况，将抽取池中的该100个案例设置为20个以数值“1”代表的案例明细1(占比值20％)、数值“3”代表的案例明细3(占比值80％)；随后，根据关联交易抽取算法(其初始化过程相同于普通交易抽取算法，然而二者所使用的抽取池并不相同)以及用户的案例明细2和4的配置情况，分别将对应的前述抽取池中的案例再设置为10个以数值“2”代表的案例明细2(占比值10％)、以数值“4”代表的案例明细4(占比值50％)；

接着，在步骤S104中，启动与收单平台、加密机的通讯连接；

随后，在步骤S105中，设定各个非阻塞通讯的轮询参数；

接下来，在步骤S106、S107中，分别处理各通信端口、处理加密机的通讯端口；

然后，在步骤S108中，服务端2作为终端处理交易(包括普通交易和关联交易)；

随后，在步骤S109中，计算当前时间和进行上一次统计的时间间隔是否大于等于统计周期(其被设定用于衡量系统处理交易能力的参数，例如业界通常采用的常规计量是3000TPS，即每秒3000笔交易的处理能力)

在上述的时间间隔大于等于统计周期时，在步骤S110中，根据统计周期输出交易统计信息；

然后，在步骤S111中，检测检测通讯链路，如果发现通讯断开则根据业务规则重新进行连接，然后返回步骤S105循环处理和通讯交互的交易。

再请参阅图4，它是图2中终端处理交易的较佳实施例的流程图，它的具体处理步骤包括：

首先，在步骤S201中，判断收到的报文是否匹配案例明细中指定的原始交易明细所对应的应答报文：如果是，则进入步骤S202；否则，进入步骤S209；

其次，在步骤S202中，从报文中取出确定交易成败的关键域；

然后，在步骤S203中，根据案例明细判断交易属性是否为关联交易：如果是，则进入步骤S204从应答报文获取原始交易关键域，然后进入步骤S205；否则，进入步骤S209；

在步骤S205中，从内存池中抽取下一笔关联交易；

随后，在步骤S206中，判断在步骤S203中的关联交易对应的原始交易是否被抽中：如果是，则进入步骤S207：根据该关联交易对应的交易模板和获取的原始交易关键域组织关联交易报文，然后进入步骤S208：填写报文发送的缓冲池；否则，进入步骤S209；

在步骤S209中，统计交易的成功笔数与失败笔数；

随后，在步骤S210中，释放本应答报文占用的内存池；

再在步骤S211中，在所有普通交易案例明细中抽取下一笔交易的模板；

接着，在步骤S212中，根据被抽中的普通交易模板组织普通交易报文；

然后，在步骤S212中，填写报文发送的缓冲池。

通过以上描述，本发明的终端交易性能测试方法的上述较佳实施例已经能够有效地解决现有的性能测试中存在的无法执行关联交易、不支持多层级的关联交易、难以保证测试持续性等诸多的问题，性能测试工具的客户端1、数据库3和服务端2均能够良好地配合协调运行，从而能够高度仿真模拟实际银行卡交易情况，真实、有效地进行测试性能。

为了进一步地优化服务端2的处理流程，本发明还提供了终端交易性能测试方法的另一个较佳实施例。在图5中示出了该实施例在服务端进行处理的部分流程图，为了清楚起见在该图中仅展示出了其与图2的主流程图相区别的部分。在这个实施例中，还需要在案例集中专门增加描述发送速度的字段，其由用户进行设定用于控制从内存池中发送报文数据的处理速度。对比本实施例与前面图2所示实施例的处理流程，它们的区别之处在于前者在后者如图2所示的处理步骤S108和S109之间另增设了一个如图5所示的子流程，该子流程用于处理在某一段时间因各种原因而致使收单平台处理性能下降而后又恢复了的情形下，能够在原有处理速度基础上增速发送之前缺失/遗落下的交易笔数，以使得在缓冲池中存储的各交易的总数目不大于案例集中指定的每秒处理交易笔数。对此，请参考图5，下面将进行具体说明：

首先，在步骤S1081中，从报文发送的缓冲池内读取请求报文；

然后，在步骤S1082中，判断在进行上一次统计得到的交易统计信息中记录的发送交易总笔数是否小于按照用户设置的测试案例的配置计算出的截止到当前应发送的交易总笔数：如果是，则进入步骤S1083，否则，进入步骤S1084；

在步骤S1083中，增速发送存储于缓冲池中与各交易相对应的报文数据，具体而言，将此时的发送速度设定为以下两者中的最小值：在测试案例中指定的发送速度乘以一个大于1的比例系数K(例如，将K设为1.01或者其他的任意适配值)、在测试案例中指定的发送速度加上缺失交易笔数。这样处理能够有效保证内存池中最多只存储有数量与收单平台的每秒处理交易笔数相同的交易，因此在上送关联交易时要在数量有限的内存池中找到交易自身的原始交易并非难事，而对于测试工具的性能也不会造成影响，更不会因为测试工具的性能瓶颈而模糊了收单平台的性能瓶颈；

而在步骤S1084中，由于并未出现需要增速处理缺失/遗落下的交易的情形，所以仍保持以测试案例中指定的发送速度来发送存储于缓冲池中与各交易相对应的报文数据；

随后，在步骤S1085中，发送读取的请求报文；

接着，在步骤S1086中，从报文发送的缓冲池内读取应答报文；

然后，在步骤S1087中，发送读取的应答报文。

此外，本发明还提供了在银行卡交易系统进行性能测试时管理特殊交易对终端(或称为发送方)产生影响的方法，其在业务上实现当一个终端发送了一些特殊交易(例如，签到、签退、批结等)后将触发一些特殊流程(例如，发送签退后不得再做交易、发送签到后根据应答报文更新本终端密钥、收到批结交易的应答后自动上送批上送交易等)，而对于被测系统(例如，收单平台)也同样会触发一连串的复杂处理。具体而言，采用将终端信息固定存储在数据库中，并且在开始进行测试时将其装载入内存池的技术方案。对于终端信息，它记载有密钥参数和交易状态，而交易状态则一般应包括正常状态(指已经完成签到，可做任何交易)、已上送签到还未成功状态(指终端上送签到，但还没有收到被测系统返回成功应答，这时终端是不被允许做交易的)、已上送批结还未成功状态(指终端上送批结，这时被测系统还未返回应答，这时终端也是不能再上送任何交易的)以及签退状态(指终端一旦签退，除非抽取到下一个交易是签到并成功，否则是不能做其他交易的)。当交易种类抽取到特殊交易时，交易状态将变动到特定的值，于是当发生下一笔交易时，这个变动后的交易状态将会被检验获得：如果不是普通交易状态则跳过，继续寻找下一个终端；当发生了恢复普通交易状态的交易(如签到的成功应答报文、批上送结束的请求报文)时就会改变终端状态，在下一轮交易寻求可用终端时就会被找到并恢复使用。鉴于被测系统通常对终端的唯一代码(终端号)不敏感，因此采用一定的规则来命名终端代码，然后通过算法直接计算出终端信息在内存池中的位置，由于内存池操作比较快捷，因而将不会影响性能测试水平，也比在数据库和文件中查找都要迅速得多。因此在性能测试时，每一笔交易采用的终端的都是顺序使用的，例如第一笔交易使用内存池中第一个终端、第二笔交易就使用内存池中第二个终端，依此类推并且循环使用。而发送每一笔交易时，交易种类是根据测试案例的指定比例随机抽取的，因此在被测系统看来，终端和交易种类的搭配是混合的，并且只要终端状态不改变，每一个终端发送的交易是基本均衡的。所以能够与客观实际情形基本吻合，能够较好地测试出被测系统的性能瓶颈所在。在采用上述技术方案时，本发明仍然使用如图1所示的由客户端1、服务端2和数据库3共同组成的测试工具，涉及由用户制成的测试案例(包括案例集、案例明细)、交易模板的内容也与前述内容基本相同，而在交易模板的字段中另增设了“交易引起终端信息的交易状态发生改变的变化值”的字段，以记载交易期间交易状态的变化情况。

图6示出了采用以上技术方案的本发明又一个较佳实施例中服务端2的处理流程图。请参阅图6，此时的服务端2的处理步骤具体包括：

首先，在步骤S301中，从数据库3将交易模板、测试案例和终端信息装载至内存池；

其次，在步骤S302、S303中，分别初始化普通交易抽取算法、初始化终端信息；其中，对于初始化普通交易抽取算法的过程，已在此前对其进行了详细描述，故不再赘述；而对于初始化终端信息的处理，则是将所有终端的交易状态都初始化设置成“已上送签到还未成功”，因为如果不将所有终端的初始交易状态如此设置，则它们无法进行交易处理；

然后，在步骤S304中，启动与收单平台、加密机的通讯连接；

接着，在步骤S305中，设定各个非阻塞通讯的轮询参数；

随后，在步骤S306、S307中，分别处理各通信端口、处理加密机的通讯端口；

接着，在步骤S308中，服务端2作为终端处理交易；

接下来，在步骤S309中，计算当前时间和进行上一次统计的时间间隔是否大于等于统计周期(其含义参见前述)；

在上述的时间间隔大于等于统计周期时，在步骤S310中，根据统计周期输出交易统计信息；

随后，在步骤S311中，检测通讯链路，如果发现通讯断开则根据业务规则重新进行连接，然后返回步骤S305循环处理和通讯交互的交易。

再请参阅图7，它是图6中终端处理交易的较佳实施例的具体处理流程图，它的具体处理步骤包括：

首先，在步骤S401中，判断收到的报文是否匹配案例明细中指定的原始交易明细所对应的应答报文：如果是，则进入步骤S402；否则，进入步骤S415；

其次，在步骤S402中，从报文中取出确定交易成败的关键域；

接着，在步骤S403中，根据案例明细判断交易属性：如果该笔交易属于特殊交易(例如，签到、签退、批结等)，则进入步骤S405；否则，转入步骤S404进行关联交易处理(对此可以采用例如前述的图4中步骤S204-S208所揭示的处理方式，当然也可以根据实际测试需要而采用其他的处理方式)，然后再进入步骤S415；

随后，在步骤S405中，判断终端交易状态：如果是“已上送签到还未成功”，则进入步骤S406；如果是“已上送批结还未成功”，则进入步骤S411；

然后，在步骤S406中，判断是否成功应答：如果是，则进入步骤S407；否则，进入步骤S415；

接着，在步骤S407中，在内存池中查找终端信息；

接着，在步骤S408中，恢复当前终端的交易状态至正常状态；

随后，在步骤S409、S410中，分别进行更新密钥处理、密码密文预处理，然后进入步骤S415；

在步骤S411中，在内存池中查找终端信息；

接着，在步骤S412、S413中，分别进行触发批上送处理、更新终端自身的批次号处理；

随后，在步骤S414中，恢复当前终端的交易状态至正常状态；

再在步骤S415中，统计交易的成功笔数与失败笔数；

接着，在步骤S416中，释放本应答报文占用的内存池；

然后，在步骤S417中，在所有普通交易案例明细中抽取下一笔交易的模板；

再在步骤S418中，根据被抽中的普通交易模板组织普通交易报文；

随后，在步骤S419中，填写报文发送的缓冲池。

对比于现有的其他测试方法，以上描述的本发明方法的这个较佳实施例能够在性能测试时根据实际需求灵活配置特殊交易和其他交易比例并混合发送，并且能够支持多个终端和混合交易随机匹配在一起发送交易，还可以在其中某一个终端发生了特殊交易时仅管理该终端做出相应动作而不会影响其他终端的交易，此外还能够在被管理的终端完成特殊处理流程后将其恢复成普通终端进行交易，因此采用该发明方法能够高效、真实、灵活地测试被测系统的性能，更加符合实际环境下大量终端进行交易的情况。

另外，需要指出的是还可以在以上最后列出的两个较佳实施例中，将前述的在图5中揭示的用于增速处理交易的子流程相应地增设入它们各自的处理流程中，以期能够进一步地完善它们的仿真测试效果和使用功能。该子流程的特征及其优点已在此前进行了详细说明，故不再赘述。事实上，用户完全可以依据其所面对的测试需要，而将前文所揭示的各个技术特征进行叠加或组合从而能够获得更理想的技术效果。

以上列举了多个具体实施例来详细阐明本发明的终端交易性能测试方法，这些个例仅被用于说明本发明的原理及其实施方式，而并非是对本发明的限制，在不脱离本发明的精神和范围的情况下，本领域的普通技术人员还可以做出各种的变形和改进。例如，为了慎重起见，在本发明方法中还可以考虑将流程处理过程中收到的异常报文记入单独的日志文件而不做抛弃处理，并且至于是否这样处理也完全可以由用户根据专设的配置文件内的对应参数进行选择调整；再如，在前述的普通交易抽取算法和关联交易抽取算法中完全能够采用涉及现有的选择算法的全部通用技术。因此，这些及其他的诸多现有技术均可以被灵活地并入本发明方法中，由此所有等同的技术方案均应属于本发明的范畴并为本发明的各项权利要求所限定。

Claims (15)

1.一种终端交易性能测试方法，其用于测试系统性能的测试工具包括客户端、与所述客户端相连的数据库、以及与所述客户端和数据库均相连的服务端，其特征在于，由用户在所述客户端制作交易模板和测试案例并将它们存储于所述数据库，在测试时由所述服务端接收测试命令并按照如下的步骤进行处理：

a、从所述数据库将所述交易模板和所述测试案例装载至内存池；

b、初始化用于从所述内存池中抽取交易的抽取算法；

c、启动与收单平台、加密机的通讯连接；

d、根据需要设置各通讯链路；

e、作为终端处理交易；

f、计算当前时间和进行上一次统计的时间间隔是否大于等于统计周期，并在其大于等于所述统计周期时根据所述统计周期输出交易统计信息，所述统计周期被设定用于衡量系统处理交易的能力；以及

g、返回步骤d循环处理和通讯交互的交易。

2.根据权利要求1所述的终端交易性能测试方法，其特征在于，在所述步骤f和步骤g之间还包括步骤：

fg、检测通讯链路，如果发现通讯断开则根据业务规则重新进行连接。

3.根据权利要求1或2所述的终端交易性能测试方法，其特征在于，所述交易模板包括交易模板名称、交易的报文流、以及每一个关键域在所述报文流中的位置和长度，所述关键域由用户按需进行配置。

4.根据权利要求3所述的终端交易性能测试方法，其特征在于，所述测试案例包括：

案例集，其包括案例编号、所述收单平台的预期的每秒处理交易笔数、测试停止类型和测试停止值，所述测试停止类型被设为按时间停止或按交易笔数总量停止，所述测试停止值被设为测试总时间或测试总交易笔数；以及

案例明细，其包括案例编号、交易模板名称、原始交易明细和占比值，所述原始交易明细包括后续交易所对应的其在先交易的名称，所述占比值由用户按需进行配置，并且其对应于存在原始交易的后续交易是指被抽取作为数据源进行发送的后续交易在所述原始交易的应答中所占的比例，而对应于无原始交易的普通交易是指其在所述案例集的每秒处理交易笔数中所占的比例；每一个所述案例集至少下挂一笔所述案例明细。

5.根据权利要求4所述的终端交易性能测试方法，其特征在于，所述抽取算法包括：

普通交易抽取算法，其采用随机选择算法用于实现对应于所述普通交易的占比值；以及

关联交易抽取算法，其采用随机选择算法用于实现对应于所述后续交易的占比值。

6.根据权利要求4所述的终端交易性能测试方法，其特征在于，所述步骤e中的所述服务端作为终端处理交易的步骤包括：

e1、判断收到的报文是否匹配所述案例明细中指定的原始交易明细所对应的应答报文：如果是，则进入步骤e2；否则，进入步骤e6；

e2、从所述报文中取出确定交易成败的关键域；

e3、根据所述案例明细判断交易属性是否为关联交易：如果是，则从所述应答报文获取原始交易关键域，然后进入步骤e4；否则，进入步骤e6；

e4、从所述内存池中抽取下一笔关联交易；

e5、判断步骤e3中所述关联交易对应的原始交易是否被抽中：如果是，则根据该关联交易对应的交易模板和获取的所述原始交易关键域组织关联交易报文，然后填写报文发送的缓冲池；否则，进入步骤e6；

e6、统计交易的成功笔数与失败笔数；

e7、释放所述应答报文占用的内存池；

e8、在所有普通交易案例明细中抽取下一笔交易的模板；

e9、根据被抽中的普通交易模板组织普通交易报文；以及

e10、填写报文发送的缓冲池。

7.根据权利要求6所述的终端交易性能测试方法，其特征在于，所述案例集还包括发送速度，并且在所述步骤e和步骤f之间还包括步骤：

ef、从所述报文发送的缓冲池内读取请求报文，并判断记录于上一次统计所得交易统计信息中的发送交易总笔数是否小于按照所述测试案例的配置计算出的截止到当前应发送的交易总笔数：如果是，则增速发送存储于所述缓冲池中与各交易相对应的报文数据，否则以所述测试案例中指定的发送速度来发送存储于所述缓冲池中与各交易相对应的报文数据，以使得在所述缓冲池中存储的各交易的总数目不大于所述案例集的每秒处理交易笔数。

8.一种终端交易性能测试方法，其用于测试系统性能的测试工具包括客户端、与所述客户端相连的数据库、以及与所述客户端和数据库均相连的服务端，其特征在于，由用户在所述客户端制作交易模板、测试案例并将它们存储于所述数据库，并且所述数据库还存储有终端信息，在测试时由所述服务端接收测试命令并按照如下的步骤进行处理：

a、从所述数据库将所述交易模板、所述测试案例和所述终端信息装载至内存池；

b、初始化用于从所述内存池中抽取普通交易的普通交易抽取算法；

c、初始化所述终端信息；

d、启动与收单平台、加密机的通讯连接；

e、根据业务规则设置各通讯链路；

f、作为终端处理交易；

g、计算当前时间和进行上一次统计的时间间隔是否大于等于统计周期，并在其大于等于所述统计周期时根据所述统计周期输出交易统计信息，所述统计周期被设定用于衡量系统处理交易的能力；以及

h、返回步骤e循环处理和通讯交互的交易。

9.根据权利要求8所述的终端交易性能测试方法，其特征在于，在所述步骤g和步骤h之间还包括步骤：

gh、检测通讯链路，如果发现通讯断开则根据业务规则重新进行连接。

10.根据权利要求8或9所述的终端交易性能测试方法，其特征在于，所述终端信息包括密钥参数和交易状态，所述交易状态包括正常状态、已上送签到还未成功状态、已上送批结还未成功状态和签退状态。

11.根据权利要求10所述的终端交易性能测试方法，其特征在于，所述交易模板包括交易模板名称、交易引起所述终端信息的交易状态发生改变的变化值、交易的报文流、以及每一个关键域在所述报文流中的位置和长度，所述关键域由用户按需进行配置。

12.根据权利要求11所述的终端交易性能测试方法，其特征在于，所述测试案例包括：

案例集，其包括案例编号、所述收单平台的预期的每秒处理交易笔数、测试停止类型和测试停止值，所述测试停止类型被设为按时间停止或按交易笔数总量停止，所述测试停止值被设为测试总时间或测试总交易笔数；以及

案例明细，其包括案例编号、交易模板名称、原始交易明细和占比值，所述原始交易明细包括后续交易所对应的其在先交易的名称，所述占比值由用户按需进行配置，并且对应于存在原始交易的后续交易是指被抽取作为数据源进行发送的后续交易在所述原始交易的应答中所占的比例，而对应于无原始交易的普通交易是指其在所述案例集的每秒处理交易笔数中所占的比例；每一个所述案例集至少下挂一笔所述案例明细。

13.根据权利要求12所述的终端交易性能测试方法，其特征在于，所述步骤f中的所述服务端作为终端处理交易的步骤包括：

f1、判断收到的报文是否匹配所述案例明细中指定的原始交易明细所对应的应答报文：如果是，则进入步骤f2；否则，进入步骤f14；

f2、从所述报文中取出确定交易成败的关键域；

f3、根据所述案例明细判断交易属性：如果属于特殊交易则进入步骤f4，所述特殊交易包括签到、签退和批结；否则，进行关联交易处理，然后进入步骤f14；

f4、判断终端交易状态：如果是“已上送签到还未成功”，则进入步骤f5；如果是“已上送批结还未成功”，则进入步骤f10；

f5、判断是否成功应答：如果是，则进入步骤f6；否则，进入步骤f14；

f6、在内存池中查找终端信息；

f7、恢复当前终端的交易状态至正常状态；

f8、更新密钥；

f9、密码密文预处理，然后进入步骤f14；

f10、在内存池中查找终端信息；

f11、触发批上送处理；

f12、更新自身的批次号；

f13、恢复当前终端的交易状态至正常状态；

f14、统计交易的成功笔数与失败笔数；

f15、释放所述应答报文占用的内存池；

f16、在所有普通交易案例明细中抽取下一笔交易的模板；

f17、根据被抽中的普通交易模板组织普通交易报文；以及

f18、填写报文发送的缓冲池。

14.根据权利要求13所述的终端交易性能测试方法，其特征在于，所述步骤f3中的所述关联交易处理步骤包括：

f31、从所述应答报文获取原始交易关键域；

f32、从所述内存池中抽取下一笔关联交易；以及

f33、判断步骤f31中所述关联交易对应的原始交易是否被抽中：如果是，则根据该关联交易对应的交易模板和获取的所述原始交易关键域组织关联交易报文，然后填写报文发送的缓冲池。

15.根据权利要求13所述的终端交易性能测试方法，其特征在于，所述案例集还包括发送速度，并且在所述步骤f和步骤g之间还包括步骤：

fg、从所述报文发送的缓冲池内读取请求报文，并判断记录于上一次统计所得交易统计信息中的发送交易总笔数是否小于按照所述测试案例的配置计算出的截止到当前应发送的交易总笔数：如果是，则增速发送存储于所述缓冲池中与各交易相对应的报文数据，否则以所述测试案例中指定的发送速度来发送存储于所述缓冲池中与各交易相对应的报文数据，以使得在所述缓冲池中存储的各交易的总数目不大于所述案例集的每秒处理交易笔数。

Images