第三方支付系统性能测试要点分析

自2010年06月21日中国人民银行公布《非金融机构支付服务管理办法》以来,针对非金融机构“支付业务许可证”的申请及检测认证工作已经逐步展开。下面,我们将结合央行检测认证的相关规定,对非金融机构第三方支付系统性能检测的要点进行解读和分析。

  一、第三方支付系统性能检测内容

  中国人民银行于2011年1月17日发布了《非金融机构支付服务业务系统检测认证管理规定》(征求意见稿)。其对第三方支付系统性能检测的目的和内容作了如下说明:“验证业务系统是否满足业务需求的多用户并发操作,是否满足业务性能需求,评估压力解除后的自恢复能力,测试系统性能极限”。

  通过这段说明我们不难看出,对支付服务业务系统性能的检测主要包括以下三方面内容:一是系统的并发能力验证;二是压力解除后系统自恢复能力;三是系统性能极限验证。

  系统的并发能力验证应包含两方面检测内容:一是验证系统是否支持业务的多用户并发操作;二是结合典型交易检验各测试点在给定并发用户数下,系统各项性能指标是否满足用户性能需求。

  系统自恢复能力验证的内容主要是在系统并发能力验证和系统性能极限验证的同时,记录各测试点在加压和压力解除前后系统资源的使用情况及资源恢复所用的时间。

  系统性能极限验证的内容主要是对典型交易采用极限测试策略,通过逐步增加系统负载的方式,测试系统性能的变化,并最终确定在什么负载条件下系统性能处于失效状态,同时记录此时系统所能承受的最大并发用户数。

  二、第三方支付系统性能检测要点分析

  与其他应用系统的性能测试一样,规范的第三方支付系统性能测试同样需要经历测试准备、测试实施和测试总结等过程。

  1) 性能需求分析

  因各家非金融机构支付服务系统的用户规模不同,所以央行并未对第三方支付系统性能检测环境和性能指标进行硬性规定,性能指标的确认依据主要来自于系统需求文档中对性能的约定或用户性能需求的调研。

  性能需求的主要调查内容包括:系统实际使用的用户数量、正常情况下系统的平均使用用户数、高峰时段的在线用户量、可预期生命周期内系统的用户增长情况、一年的业务量及日交易量、压力解除后系统自恢复时间要求等。

  2) 测试策略分析

  根据非金融机构支付服务系统的业务特点,对其性能的测试大致可分为两类:一类是包含数据插入操作和数据查询操作的并发测试性能(如:支付、交易明细查询等);另一类是大数据量处理性能(如:日终批处理等)。

  并发测试策略的主要内容应包括:并发用户数、性能指标要求(包括响应时间、系统资源占用)等;对大数据量计算性能测试策略的制定过程中,需要关注的是对批处理交易数据量的要求。

  3) 性能测试点选取分析

  按照央行的定义,第三方支付服务包含网络支付、预付卡和银行卡收单等,而无论采用哪种支付方式,三种支付平台实质上都是买卖双方交易过程中的“中间件”,它的核心功能就是通过提供的支付网关为交易双方提供支付、充值等交易服务,并记录双方的交易数据。对其测试点的选择可以典型交易、复杂业务流程、频繁的用户操作、大数据量处理等为总体指导原则,围绕支付、交易管理、资金结算、对账处理等核心业务进行选取。

  在网络支付系统中,我们将重点选取支付、预存、交易明细查询、日终批处理等操作进行测试;预付卡部分重点选取联机消费、联机余额查询、交易明细查询、批量充值、日终批处理等操作进行测试;银行卡收单部分重点选取消费、预授权、日终批处理等操作进行测试。

  三、第三方支付系统测试方法简析

  第三方支付系统性能测试可以选择常见的商用性能测试软件进行,但需要注意的是由于交易过程通常需要调用银行接口与协约银行进行数据交换,因此在测试脚本编辑过程中需要用模拟接口来替换真实的银行接口来测试支付平台的真实性能。预付卡和银行卡收单其交易数据的来源均为Pos机,性能测试中只能用开发的工具或编制的脚本来模拟发送报文到Pos前置服务器进行并发测试,具体可通过Socket协议编写报文发送脚本的过程进行实现。

本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/

上一篇:java多线程之:深入JVM锁机制2-Lock (转载)


下一篇:linux 批量建立信任关系