在测试到订单支付时，很多同学不知道支付有哪些测试异常点。希望下面总结的内容可以帮到大家。（这里主要是支付的点， 部分包含订单相关的点）
一、支付流程
我们在测试一个功能时，需要先了解一下这个逻辑，而订单支付逻辑普遍都会有以下内容：
创建本地唯一订单号；
-
去调用支付，在支付平台生成一个支付订单；
- 会返回一个支付凭证(payInfo)
- 支付订单号在回调方法中会拿到
-
此时待支付状态下，支付平台回调通知接口；
- 在本地保存待支付订单信息（此时有两个订单记录：一个本地订单，一个支付平台的订单，两个ID关联）
用户根据收到的支付凭证发起支付(只需要管支付成功的，不成功可以当成忽略)
-
支付平台回调通知接口(支付成功)
- 更新支付订单
- 更新本地订单
- 后续操作
-
主动查询订单状态
- 更新支付订单
- 更新本地订单
- 后续操作
退款或体现（不做具体阐述）
二、实际遇到支付的异常测试点
上面的内容了解即可，大部分内容项目熟了就知道了，很多时候具体项目具体分析。下面的异常测试点大多是我亲身经历过的容易出现异常的情况。
具体测试场景：
- 连续访问2次（或以上）支付接口，在第一次访问未回调完成时，第二次访问需要做限制；
- 可能出现的问题：直接返回第二次的结果，而第一次就可能是成功的，只是第一次请求返回的结果被第二次请求返回的失败结果所覆盖；
- 连续访问回调订单接口（向支付平台提交支付请求接口），生成的多个签名，需要校验订单返回的是否是最新的签名；
- 可能出现的问题：使用前面生成的一个签名去支付，会报错；
- 一个订单反复提交支付再返回，退出支付再次调取支付只允许生成不同的签名，这个根据需求；
- 需要校验1个签名只能支付1次，这个根据需求；
- 支付签名的校验，这个看需求及个人。如：异常/特殊符号等；
- 支付0元/0.01元/0.001元；
- 支付负值；
- 支付回调超时情况后端处理：一个合理的文案。方法：加挡板/断点；
- 注意一下消息回调，如果是第三方支付系统，通常会有消息的异步回调。
- 如：支付后，会在一定时间内无限循环查询接口，最后会回传成功或失败，但是订单不会直接知道这个结果，系统需要再次访问一个接口了解支付的最新状态才能知道订单是否支付成功；
10.网上找的图片，可借鉴。原地址：https://blog.csdn.net/wjoxoxoxxx/article/details/79813437
测试过程中容易疏忽的测试点
如果有疑问点、补充点，欢迎随时指出！
