支付接口场景测试点

支付接口场景测试大体从功能、接口、性能、兼容、安全、异常、兼容、集成、健壮性几个方面来考虑，个人觉得比较重要的测试点简单罗列如下：

1、历史存量数据兼容性（比如增加逻辑商户在白名单走新计费版本，下单时候会落这个这个版本号，做支付根据版本号判断是否请求商户计费接口，这个时候就有历史数据问题。比如很早已下过的订单，捡起支付可能也是走新计费的，结果走了老计费。未对这批数据进行处理）
2、参数检验(参数是否必填 数据类型 数据长度 非枚举值范围内 特殊字符 敏感字符 )
3、主流程(接口响应 数据库 资金 回调  日志埋点 反欺诈 )
4、基础检验规则(业务上要求 用户实名 账户状态)
5、业务风控(渠道限额限次)
6、异常场景:网络超时 同步失败（error、exception、warring） 异步失败 、同步异步快慢
7、补单补偿
8、并发测试（分布缓存锁）
9、消息(防止异步消息重复——1、引入原始状态  2、状态机   消息幂等性）
10、接口幂等性
（处理请求重发方法——缓存锁限制5s幂等或做插入操作先做查询判断、  处理数据库重复插入方面——数据库锁、处理消息重发方面——增加初始状态或状态机、前端使用防重发机制）
11、系统之间调用，加日志看传参，看数据库落库
12、历史版本兼容性(内部接口废弃 )     手段比如开关控制是否调用新版本逻辑
13、资金流（流转特别多，场景涉及到分账、手续费、退款，不同场景资金和资金流转都会不同）
14、状态机-订单中心抽象状态类 state-context+状态衔接类
15、 关注catch exception 行为
16、防止资损 测试过程资金流核对

17、考虑切流  少量用户走新逻辑验证，确保系统风险降低

18、日志监控告警是否要新增

19、各类错误码要覆盖全面

20、事务回滚（A调用B、C逻辑，C失败后，B是否要回滚）

21、系统之间依赖性、jar包依赖

一起持续在支付行业拼搏中～