全网天花板，软件测试项目实战，银行项目支付业务测试看这一篇就够了_银行跨行支付测评怎么写

---

前言

支付的本质，就是发生在买方和卖方之间的金融交换，是社会经济活动中所引起的货币债权转移过程。

工欲善其事必先利其器，所谓了解一个方向，先学学行业 “黑话”，这样别人说的啥你也能听得懂。

第三方支付：拥有支付牌照的机构，比如支付宝、微信支付等等；
零钱：客户在第三方支付机构支付体系下的现金户余额，类似支付宝余额、微信的零钱；
两联：银联和网联；
客户：指个人和商户，统称为客户；
备付金账户：三方支付机构在人民银行开立的，存放用户在交易过程中产生的资金。

备付金账户产生的背景是啥呢？
因为支付机构作为第三方，其实是不能直接触碰用户的钱的，监管机构要求，第三方机构收取的钱，都统一放在银行的备付金账户里(所以大家不用担心存放在第三方机构的资金安全)。

第三方支付的能力
第三方支付一般是提供了哪些能力/产品？
充值、提现、查询、转账、退款
支付、代扣、代付
实名认证、签约
记账、对账、出账

第三方支付架构
大家上网查查各家支付的机构图，感觉都很厉害。不难发现，每家有不同之处，其实也有很多相同的地方。

相同之处就是解决支付业务的共同要解决的问题：

问题一：怎么准确又快速，并且合法合规地从用户手里扣钱？
客户系统(用户+商户)可以解决，客户系统可以进行用户实名、商户注册、存储签约信息等等。

问题二：怎么才能把钱扣成功？并且完整记录扣钱的过程？
支付中心+账务核心+会计核心可以解决，支付中心提供各种出金入金服务，账务核心可以进行记账对账，会计中心又能提供各种科目汇总和日期处理。

问题三：扣完钱后，怎么去给商家结算？
结算核心可以解决，计算卖家手续费等等。

业务测试

由于支付业务的特点，个人认为在业务测试中，
主要是两大点：
一个是支付单子的钱
一个是支付单的状态

钱的话，有这种重复支付的异常、使用各种优惠券的场景，单位也需要注意，有的通道可能是元，有的通道可能是分；退款时，如果是部分退款，注意退款的总金额不超过订单金额。

支付订单状态，要注意支付超时的情况，支付失败等等一些情况等等。

自动化测试
在自动化测试中，支付业务有啥特别的呢？
首先在断言的时候，校验订单金额，支付核心模块不同系统订单的状态，可能不同系统，成功状态不一样。比如异步的代扣订单有时延，提交完订单立刻去调查询接口查询时就可能查询到的是订单在支付中。

所以我们可以写个循环去读数据库的状态，数据库状态OK了后，再去调查询接口。

因为线上的cases都是扣的我们自己真实的钱，所以，我们一般是把扣款、查询和退款放在同一个cases中，支付完再退款，完成单笔订单资金自闭环线上涉及到真实的资金变动，我们线上有单独的测试商户号，不会对线上真实的商户账单产生影响。

性能测试
在性能测试中，支付业务有啥特别的呢？

每个业务都去考虑的仿真度这些这里就不展开讨论了，支付业务最重要的是钱的安全！
措施：
压测开关控制：通过开关控制是否接受压测流量；
压测的交易数据隔离：影子库/影子表；
资金监控告警：大量资金变化报警；
资金闭环：资金流动能闭环，不会产生资损；
压测专用用户：不会影响线上真实用户的钱。

线上监控
支付业务有大家通用的机器性能的监控、接口qps的监控。除了这些，还会有一些业务维度的资金的监控等等。

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

日出东海落西山，愁也一天，喜也一天；遇事不钻牛角尖，人也舒坦，心也舒坦；早晚操劳勤锻炼，忙也乐观，闲也乐观。

上帝制造人类的时候就把我们制造成不完美的人，我们一辈子努力的过程就是使自己变得更加完美的过程，我们的一切美德都来自于克服自身缺点的奋斗。

为了成就一番事业，为了实现自己人生的目标，经常为自己整整枝。排除那些不必要的留恋与顾盼，鞭策鞭策自我，以便集中精力于人生的追求。