小额支付系统普通汇兑链路介绍及其测试分析

小额支付系统普通汇兑链路介绍及其测试分析

金融app的测试经常涉及到支付交易的测试，例如理财申购，转入转出等。在未接触到银行系统之前，对支付系统的处理认识仅仅停留在接收返回结果的层面，并不清楚其中的处理逻辑。因此，本文将以小额普通贷记业务中的汇兑往账业务为例，介绍小额支付系统的处理链路及其测试分析。
  
一、小额支付系统的概述
  
支付系统根据交易金额的大小、交易的紧急情况，将支付系统划分为大额支付系统和小额支付系统。
  
1.小额支付系统的特点
  
小额支付系统主要处理跨行同城、异地纸质凭证可以截留的借记支付业务以及金额在规定起点以下的小额贷记支付业务。根据支付指令进行实时或批量转发，净额清算。小额支付系统主要有以下特点：
  
    批量处理
  
    借记业务、规定金额起点以下贷记业务
  
    主要服务于社会公众日常支付等零售支付领域
  
7*24小时运行
  
    实时业务20秒
  
2.小额支付系统的基本业务
  
小额支付系统处理的业务根据业务种类，可划分为支付类、信息类、特殊交易类、对账管理类。
  
    支付类业务主要包括普通借贷记业务、实时借贷记业务、定期借贷记业务；信息类业务主要是提供查询类业务，比如业务状态查询等；特殊交易类业务主要是针对异常业务进行对应的冲正处理等；对账管理类主要是进行对账处理。
  
二、普通汇兑业务的链路介绍
  
1.普通汇兑介绍
  
普通贷记业务主要是处理主动汇款业务，其中汇兑业务为普通贷记最重要的业务之一。会对主要包括现金汇款、普通汇兑、网银支付、外汇清算等。普通汇兑的应用场景是客户通过转账方式发起的汇款业务。
  
2.普通汇兑的处理链路
  
前面说到，小额支付系统的特点为批量转发，净额清算。因此，当客户1发起一笔普通汇兑交易时，银行的小额支付系统并不会单笔转发给人行，而是根据系统自设定，按照时间或者笔数组包，以包的形式转发给人行。人行接收到小额的批量包，也不会进行逐笔清算，而是净额清算。具体举例说明一下，方便大家理解。有如下一批交易（这里以A、B两个银行为例）：
  
    A银行向B银行发起一笔100元汇款
  
    A银行向B银行发起一笔300元收款
  
    A银行向B银行发起一笔20元汇款
                                          
1）渠道端发起汇款交易
  
2）A银行支付系统接收到渠道端发起的汇款交易指示后，每一笔都需要去核心系统进行记账。
  
3）当达到一定的时间或笔数达到一定的数量后，A银行支付系统便进行组包，并按照人行的规定的报文格式，将包以报文的格式转发给人行。
  
4）人行收到我行的报文后，根据报文内容，先将每笔交易记在相应银行的头寸下，汇总后，再进行清算，也就是净额清算。当批量包处理成功后，人行便将该包转发给B银行支付系统并将结果同步到A支付系统。
  
5）B银行收到报文后，便将对应的钱转入对应客户的账户。
  
6）A银行支付系统收到人行的成功回执后，再将结果返回给渠道端。
  
三、普通汇兑的测试分析
  
从上面的介绍来看，普通汇兑的处理好像并不复杂，但是涉及到钱的测试，在案例设计都需更加严谨，接下来我们就测试来进行分析。【汇兑分为汇兑往账（即从我行向他行发出的汇兑交易）、汇兑来账（他行向我行发来的汇兑交易），这里以汇兑往账为例】
  
1.需求分析
  
首先，我们先进行简要的需求分析。
                                          
支付系统接收到渠道端的交易后，对业务参数进行检查后，到核心进行记账；待柜面发起定时组包指令后，支付系统便进行组包发送人行，并等待接收人行的回执，根据回执进行对应的处理后，将结果同步返回到渠道端。需求项主要有：
  
    1.业务参数检查
  
    2.记账
  
    3.发送报文
  
    4.接收回执
  
    5.同步结果
  
2.实现逻辑分析
  
梳理完需求后，下面根据具体的需求与实现，我们进行逻辑的梳理，具体如下图。根据逻辑图，可从以下三块进行检查：
  
    1.逻辑处理检查：业务参数检查、异常处理检查、组包检查、报文发送检查、回执接收检查（拒绝、排队、清算）、冲正处理、状态更新
  
    2.判断分支检查：记账结果分支、大小额判断分支、发送人行结果判断、人行回执结果判断
  
    3.异常情况检查
                                          
3.测试点分析
  
根据逻辑梳理的检查项后，我们可进一步输出测试点。
                                          
输出测试点之后，有一个问题是，如何覆盖？
  
    为了保证流程的完整性、全面性，因此这里建议使用场景将测试点串起来的方法进行覆盖，如：“小额普通汇兑往账_扣账成功，人行拒绝_冲账成功”这一场景，即可覆盖以下这些测试点：
                                          
4.测试中的重难点
  
1）渠道多
  
    Q：发起汇兑交易的渠道有很多，比如柜面、网银、手机银行等，那么在测试设计时，我们如何判断是需要全渠道覆盖还是挑选典型渠道进行覆盖？
  
    A： 在考虑这个问题前，我们需清楚支付的业务处理逻辑。比如汇兑这一交易，若各个渠道调用的是支付同一个接口，那围绕支付展开的测试则只需保证这个接口的处理逻辑正确，用哪一渠道来覆盖并不重要。但围绕渠道展开的测试则不同，各渠道的参数配置、与支付的通讯方式等都各异，因此各渠道在接入支付后都需要再次测试。
  
    2）关联方依赖性强
  
    Q：在1的背景下，支付系统接收的每一笔汇兑交易假设都由渠道方来发起，那则需要关联方的配合，如果关联方配合度低，测试起来效率会很低。这种情况，应该如何解决？
  
 A： 由于支付百分之90的交易都可以在柜面发起，因此条件允许的话，测试人员可以安装柜面的相关环境进行交易的发起。若条件不允许，则需mock调用。
  
    以上两者都存在各自的优缺点：前者操作起来更加方便快捷，真实性高、连通性强，但是假设柜面环境出现问题，则会阻塞测试。后者不依赖于环境，也可以使得有效的增加覆盖，但mock会使测试失去真实性、连通性。因此哪种更合适需要实际考虑。
  
    3）账务检查
  
账务是测试中比较重要的一步，假设账务出现问题，那带来的经济损失是很严重的。所以账务的测试相当重要。
  
    账务有两种，一种是记账账务，一种是冲正账务。正常交易的记账账务，对该账务的金额、机构、科目号、科目名等等都需要仔细核对；异常处理产生的冲正账务，冲正账务是与错账相反的账务，此类账务在测试过程中是必须覆盖的。
  
    4）模拟人行报文
  
我们发的往账交易都需要人行的回执，测试时，人行不会根据你的测试需求，给你送你对应的异常情况。因此我们需自己模拟人行的报文进行测试，即自发自收。这对报文中的要素、逻辑需要有一定的熟悉程度。
  
    以上，就是小额系统普通汇兑的流程介绍以及测试相关分析。欢迎大家一起探讨，也欢迎指正。