怎样测试一笔金融交易？

本文主要是介绍怎样测试一笔金融交易？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

- - 前言
- 一支付交易的过程
- 二支付交易测试点
- - 1. 报文前置数据处理
  - 2. 业务前置数据处理
  - 3. 业务处理中(交易进行中)
  - 4. 业务处理完成(交易完成)
  - 5. 上，下游关联功能检查

前言

这篇文章来梳理下关于金融支付的一些基本测试点，由于平时接触的基本都是偏业务底层和接口测试，所以从数字底层的角度来简单总结下金融支付交易的测试点，当个人笔记使用。

一支付交易的过程

一个完整的支付过程其实流程是比较长的，不是我们去银行取到钱或者买东西付完钱这个支付交易过程就结束了，这仅仅是支付过程中的一个交易环节。一个完整的支付过程主要有三个环节：交易，清算和结算。具体如下

交易：产生债权债务的过程。交易主要是由客户端产生，比如平时的消费，转账和充值交易。
清算：对交易产生的债权债务进行计算和轧差的过程。比如我们拿招商银行的卡去农业银行的ATM机取钱，当我们取到钱，退出卡的时候这个取款交易对于我们客户来说就完成了，但对于银行来说还没有结束，因为你的钱并不是招商银行直接给你的，而是农业银行帮招商银行垫付的，所以取款就是产生了招商银行债务，农业银行债权的关系。清算过程就是对银行与银行，银行与支付机构间类似跨行取款交易的债权债务关系的计算。类似的还有跨行支付，跨行转账等交易，把各种交易计算后进行收支抵销，确定最终的债权债务关系，即最终谁要收取多少，谁要支付多少。
结算：对清算的结果进行资金转移。即付钱与收钱。

整个支付过程其实和打麻将差不多，打麻将过程中的碰，杠，胡就是对应交易的过程，产生债权债务关系；胡牌后进行算‘鸡’，计算谁输多少，谁赢多少的过程对应的就是清算过程；最后的付钱与收钱就是结算过程。

二支付交易测试点

现在科技这么发达，日常生活中的消费，转账，充值提现等交易活动对于我们来说简直易如反掌，但这些表面上容易的交易活动对于银行和支付机构来说其实并不简单，其内在逻辑还是比较复杂的，因此在测试的过程中我们要尽量考虑全面，覆盖完全。下面梳理了在测试金融支付交易时应该注意的一些测试点。

1. 报文前置数据处理

接口数据格式转换
支付交易很多时候都是外部系统发起，系统与系统之间的交互是接口数据的交互。不同的系统之间数据传输的格式，系统处理数据的格式不尽相同，因此数据格式处理是基础。
常见的数据交互格式有：XML，JSON，YAML。
测试数据格式转换时需要注意几点：外部系统数据格式，内部系统数据格式，数据格式是否需要转换，请求数据转换以及应答数据转换
接口数据检查
一般前置都会做一些基本的接口数据检查，接口检查通过了才会发起底层业务请求。一些基础的接口校验：字段必填，字段长度，字段枚举等，接口检查这里先简单的说一下，具体的会有专门的文章写接口测试。
路由分发
众多的消费者每天都要发送很多交易请求，对于一些实时请求比较多的业务，后端一般都要采用多个服务器来进行分流处理，这时前置系统就得对每笔交易请求做好路由分发。所以在测试时需要关注：路由规则，路由覆盖。
其他前置数据处理

2. 业务前置数据处理

一笔交易请求发到业务系统，业务系统会进行一系列的业务前置检查，只有所有前置检查都通过后才能进行后续交易流程。检查具体如下。

客户身份信息检查
能够证明客户身份的基础信息是每次交易都要进行校验的，常见的有：银行卡，银行账户(银行交易)，账户号码，用户ID，钱包ID(数字人民币交易)等。客户信息要在系统中存在，才能进行交易。
银行卡，用户账户状态检查
以银行卡为例，交易时我们需要检查银行卡，银行账户的状态，不同状态对交易的限制是不同的。有的状态能够正常交易，有的状态只能做付款交易，也有的状态只能做收款交易。
常见的卡，账户状态有：正常状态，冻结状态，失效状态，关闭状态，挂失，睡眠状态，黑名单，白名单等。
交易场景限制
生活中的交易场景非常之多，但并不是每个银行卡，每个账户都能做所有的交易。比如银行卡的活期账户和存款账户，活期账户可以进行消费，转账，充值提现等交易，而存款账户只能做存取款交易，不能做支付交易。
个性化交易限制检查：停止支付，终止非柜面，终止所有。
特殊交易场景：某些场景可以对某些卡，某些账户做特殊处理。
账户余额检查
前置账户金额检查主要是金额透支检查，一般是根据交易方向，交易金额，账户可用余额进行余额透支检查
限额检查
不同等级的银行卡，不同等级的数字人民币钱包在不同场景都有着不同的限额，交易前我们要检查这些场景限额是否都能检查通过。
限额类型有：余额限额，单笔限额，日限额，年限额
常见的场景限额：消费限额，转账限额，充值提现限额
副卡，子钱包关联主卡，母钱包检查
如果是副卡，子钱包交易，这时我们不仅仅要对副卡，子钱包进行业务前置检查，还要对其关联的主卡，母钱包进行前置检查，只有两者都检查通过了才能进行后续交易流程。
防重检查
检查系统是否已存在该笔交易，交易不能重复。
其他检查

3. 业务处理中(交易进行中)

当上面的一系列前置检查通过后，业务系统就会接受处理该笔交易，进行数据落库处理。这时常见测试点如下。

字段落库检查
交易数据入库后，我们需要检查：数据库数据与交易接口数据是否一致，接口数据是否全部落库，字段编码是否正确，是否存在长度截取等。
状态更新
交易处理时一般都会伴随着状态流转，因此要注意相关状态的更新是否正确。比如是一笔退款或者冲账交易，这时就会涉及到原交易的状态更新。
账户余额更新
账户余额更新是金融交易测试的重中之重，因此在涉及余额更新的交易时要重点关注。如果是收款交易，那么对应的账户余额就会累加，是付款交易，对应的账户余额就会减少，如果是冻结交易，那么对应的可用账户余额也会减少。因此需要关注不同交易场景下，账户余额的更新是否正确。
限额检查
交易前要进行限额检查，主要是检查不能超过限额上限值。而交易时也要进行限额检查，这时检查的是各种限额的累加，限额恢复以及初始化是否正确。
不同的交易场景，限额的更新也是不同的。比如是消费付款，转账付款交易，那么对应的消费日限额，消费年限额，转账日限额，转账年限额就会累加；如果交易是对原消费付款，转账付款交易的冲账，那么对应的日限额，年限额就会恢复到原交易之前的值；如果交易是跨日交易，跨年交易，那么对应的日限额，年限额就会初始化后重新累加。
其他检查

4. 业务处理完成(交易完成)

交易完成后（不管交易是成功还是失败，只要到达终态就行）也有一系列的检查。交易成功，会涉及到很多上下游系统功能检查，其中账户余额更新，面向客户类的单据检查是尤其重要。具体如下。

状态更新
交易完成后，涉及到状态流转的一般都会流转终态，不管是交易失败还是成功。
数据写表
有些数据是需要交易完成后才落库写表的，也需要检查其落库写表是否正确。比如日志表，防重表。
账户余额更新
当交易处理完成后，需要关注不同终态下账户余额的更新。比如交易成功，交易失败，交易撤销等场景。
限额检查
交易完成后限额检查和交易处理中的一样，也需要检查各种限额的累加，限额恢复以及初始化是否正确。
其他检查

5. 上，下游关联功能检查

一笔交易往往涉及的不仅仅只有交易系统，大多都还涉及到上下游的一些关联系统，因此与交易有关的关联功能我们也需要关注检查。常见的一些关联功能及其测试注意点具体如下。

单据打印
单据打印是面向客户类的功能，需要重点关注。单据打印的信息都是从数据获取的，因此在检查此类功能要重点关注：单据上的信息与数据库信息是否一致，有无乱码问题，有无超长截取，有无错别字等。
动账通知
当客户开通了交易动账通知，风控通知等通知功能的时候，在交易完成时需要向客户发送动账通知或风控通知。这时需要关注： 通知能否正常发送，发送内容与交易信息或数据库信息是否一致等。
数据推送
交易系统产生的交易数据除了自己本身存储外，可能还需要推送给其它系统，比如中间件kafaka。这时需要关注：交易数据能否正常推送，推送数据是否与数据库一致等。
对账清算
上面说过，一个完整的支付流程除了交易，还有清算和结算。其中具体到交易上的环节是清算过程中的对账流程，对账的基本流程一般是数据统计–>数据核对–>数据调账。因此还要保证交易数据能够：正常统计，核对和调账。
日志打印
一般交易流程都会有日志进行跟踪，目的是为了在出问题时能够通过日志信息快速定位问题。所以我们还需要关注一下交易的日志打印是否正确。
其它检查