目录：导读
前言
1、支付类的测试关注点及异常点
对于市场上的支付系统，其实原理大同小异。市场上大多数软件系统涉及到支付功能，都会与第三方支付系统交互，跳转到相应的支付系统实现其支付功能，下面说下开展这类型测试之前，需要考虑哪些因素：
1）了解第三方支付接口有哪些，系统直接交互如何实现，建议画流程图，重复熟悉系统实现流程，只有搞清楚流程，才能更好的评估其中的风险，才能有利于测试用例的设计；
2）除了主要功能之外，还需要考虑异常场景有哪些；
3）有哪些风险？如何规避？
针对测试过程中涉及到主要的测试点整理如下：
测试过程中需要注意的主要测试点及异常场景：
①首先要保证接口都能正常调用；
②生成一笔订单，支付完成后，同步或异步重复回调，只有一次有效；
③生成一笔订单，复制订单号和金额，再次生成一笔订单，用fiddler设置断点，用第一笔已完成的订单号和订单金额去替换现有的订单号和金额，无法完成支付；
④生成一笔订单，跳转到第三方时修改金额，无法到账，或者如果是游戏充值游戏币的话，到账为篡改后的金额对应的游戏币；
⑤异步通知屏蔽，同步有效，进行支付，同步能够正常到账；
⑥同步设置无效，异步有效，进行支付，异步能够正常到账；
⑦同步异步都设置无效，在第三方支付完成后，在重发机制时间范围内，设置异步有效，到下次通知时间点时，能够正常通知到账（补单机制的验证，如果商户收到第三方支付成功的通知后，要告知第三方支付收到了成功的通知，如果第三方支付收到商户应答不是ok或超时，第三方支付就会认为通知失败，会在规定的时间内持续调用notify_url，一般有时间或次数的限制）；
⑧针对支付订单在数据库中存储是否完整和正确进行校验（比如：第三方订单号–方便与第三方对账和问题排查、订单金额、订单状态等）；
⑨如果是用户购买实物商品，用户发起退货，要保证退货流程正常，资金能正常返还，要考虑下并发情况的验证以确保安全性；
⑩如果是用户购买虚拟商品，比如话费、油卡之类的商品，只有在发货失败的时候才能发起退货，注意验证；
常遇的坑
用户购买100元游戏币时，前往第三方支付跳转进行金额的篡改由100元改成0.01元，结果就拿了0.01元充值了100元的游戏币。对订单金额没有做校验导致这样的后果，损失比较大。大家在测试的过程中一定要注意对服务端进行校验，支付时数据的篡改一定要有校验。
当同步、异步通知都存在的情况的，异步通知（第三方支付成功后台通知），没有到账，导致部分用户充值不到账，引起客诉。
当同步、异步并存的时候，一定要分别对同步和异步进行检验，确保都能正常到账。
我们所做的绝大多少的互联网产品都会涉及到第三方支付，所以支付功能必然是重要的，作为测试互联网产品的一员，我们必须要做好支付的安全性。
如何规避支付风险？
为了进一步的加强支付功能的安全，也可以适当的增加一些监控机制。
比如：
订单与第三方订单进行对比，可以使用跑批完成，当我们完成支付的订单从数据库中查出来与通过第三方订单查询接口查询出来的同一个订单金额有异常时，进行报警通知能够及时发现处理，甚至当有异常情况进行创建订单的终止，从而把损失降到最低。
2、支付平台是如何测试各种渠道和银行通道的？
作为一个支付平台，接入了快钱、易宝或直连银行等多家的渠道，内在的产品流程是自己的。
业内有什么比较好的测试办法，来测试各渠道及其支持的银行通道呢？作为产品，我自己办了十几张银行卡方便测试，但QA和开发不愿意这样做，怎么办呢？
回答：对支付平台而言，与支付渠道相关的测试大致可以分为：测试支付渠道功能、测试支付产品功能。
1）支付渠道功能测试
主要是测试与银行、银联、其他外部支付渠道以及诸如实名认证等非支付类功能的功能。
一般情况下，支付渠道的接口只对第三方支付内部开放，不会直接将支付渠道暴露给外部商户，对外部商户都是包装成支付产品形式提供的。
支付渠道是第三方支付公司最基础的能力，由于涉及调用外部形形色色的各种接口及服务，各家的渠道提供的测试环境、准生产环境、生产环境要求也不同，同时第三方支付自己也需要维护对应的测试环境、准生产环境、生产环境不同版本的环境，要完整做测试确实挺麻烦。
测试方法：
在内部开发一套统一的测试网关（不管是接口通信协议是socket、http、xml等，一般都统一为http以方便测试），统一各种渠道的测试入口，针对不同的渠道维护对应的接口参数模板，方便测试人员快速输入并提交原始的支付请求。
提交到支付渠道后，如果支付渠道维护有测试环境、准测试环境，则可以直接用提供的测试账号完成实际调用支付渠道测试。
如果不提供，只能像如题一样，针对不同的渠道开通银行卡、对公账户等进行测试。
此种情况下一般都以最低限额测试。测试卡的申请、测试费用出处、日常管理可以根据每家公司实际情况制定对应政策，最好是公司承担各种费用、简化相关流程并有对应的激励措施，例如不要对此类费用还要走极为漫长的报销流程。
测试目的：
保证支付渠道功能的正确性、完整性、可用性，验证渠道是否畅通、功能是否正常。
一个典型例子是，原有支付渠道新上线一个功能，生产环境测试发现有问题，要在生产环境完整跑一边流程极为麻烦，可以用测试或准生产环境稳定版本的测试网关测试，快速定位是上线新版本影响生成功能，还是支付渠道端的问题，或者生产环境网络等问题影响。
2）支付产品功能测试
这里的支付产品可以是第三方支付内部的基础性产品，也可以是对外部商户提供的产品或接口。
此种情况下，测试重点不是支付渠道的基础功能，而是支付产品的核心功能。对支付产品而言，可以假设支付渠道是一个黑盒子，黑盒子对外提供的服务是可靠稳定的。
测试方法：
在内部开发一套支付渠道的模拟网关，对各种支付渠道的各个接口功能进行模拟并根据支付请求返回对应的模拟报文。
支付请求不用实际提交给外部支付渠道。 一般模拟网关与上面的测试网关会统一开发部署。
| 下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |
一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结（尾部小惊喜）
秉持梦想之翼，放飞心灵的火焰，勇往直前，无惧困难。不论何时何地，坚守信念，追求卓越，终将成就不凡的人生传奇。
勇往直前，迎接挑战的呼唤。放下犹豫，抛却困惑，努力奋斗，才能获得真正的自由与成就。在每一次努力中超越自己，才能创造出辉煌的人生篇章。
在漫漫征途中，不放弃、不言败，坚守初心，追求卓越。勇敢迎接挑战，超越自己的极限，才能成就那个矢志不渝的梦想。只要努力，成功将无可避免。