商户入网测试点：
内部接口
1、接口参数（必填项、字符类型、字符长度、银行卡、身份证）
2、幂等性测试（并发测试（fiddler、jmeter）、重复发送一样的请求）
3、安全性：传输加密（敏感信息–姓名、身份证、手机号、银行卡、商户编号）
4、服务器日志（还原用户行为），日志对敏感信息要脱敏
5、数据存储，加密处理
6、状态转换（审核中、审核通过、审核拒绝）
7、异步接口（同步接口）、回调（根据第三方接口文档自己模拟；mock服务）、查询
外部接口（抓包出来看）
其他测试点同内部接口
专业名词：
进件：商户入网就是进件
商户配置测试点：
1、接口参数（必填项、字符类型、字符长度、各个字段）
2、配置多种/一种支付方式
3、渠道优先级
4、支付方式配置好之后，有没有生效（支付一笔，然后去抓包）
5、内部接口参数、外部接口参数
支付接口测试：
1、内部接口、外部接口
2、接口参数
3、安全（加密、日志脱敏）
4、订单号的唯一性（大数据量并发）订单号的生成规则（5万多单）
5、数据库连接池（内存泄漏）
6、请求频次（同一个IP一秒钟一般不会超过10次，多线程并发）
7、回调（各种场景）、查询（主动查询支付结果）
8、重复支付（同一笔订单订单号相同，只能成功一笔）
9、接口幂等
10、支付金额边界值（支付限额、单笔最大金额5w、当天最大金额、最小的支付金额-最低消费、小数位（精度99.95/0.01/0.88888））
11、性能
12、支付方式的枚举（支付宝、微信）
13、支付渠道切换
清分测试点：
1、清分的时间，实时清分（数据库订单状态、清分明细）
2、清分明细表（记录各个角色应该拿多少钱）
3、通过定时任务（2分钟请求一次，批处理）
4、同一笔订单只能清分一次（订单号）
5、精度问题（清分计算的规则）
会计：资产=负债+所有者权益
（1）四舍五入（账对不齐）
（2）银行家算法（账对不齐）
（3）兜底算法
6、算法取值，计算过程是否有误
7、测试技巧：通过Excel精准设置好公式，直接往Excel填对应的数据即可
对账的逻辑：
1、以自己平台为准和上游平台的订单进行对账，（支付时间、订单号、金额、支付状态（支付成功））
2、以上游平台为准和自己平台进行对账
3、支付对账、退款对账
4、对账的执行时间：凌晨执行对账的任务
5、开始对账—是否有挂账—（在七天之内去找掉单的数据进行对账）—对账完成
对账测试点：
1、对账结果:对平、挂账（我们平台有订单，上游无订单）、掉单（我们平台没有，上游有）、销账
2、日切的场景：在我们平台23:59:59到上游第二天，数据构造（修改数据库、修改服务器的时间）
3、销账
4、重复对账（支持），先删（逻辑删除）除当天的所有对账数据，重新对账
5、定时任务写的有没有问题（能否正确触发定时任务）
6、对账性能（10万条账单，10分钟以内完成对账）
7、对账单的解析：上游订单一般通过文件的形式放到服务器上面，解析异常、解析正常
流程：
支付环节：商户入网–对商户进行配置（支付方式、支付渠道）–商户激活收款码–发起支付–清分–对账–结算
支付后的环节：商户提现（渠道提现、地推提现）-退款（商户退款）
逻辑：
结算概念：平台做垫资结算（信息流来进行垫资），为了垫资而做的结算，提升用户体验
结算维度：机构（微信、支付宝、京东、美团）、渠道（进件商户的公司）、商户（大商户–中石化）
好处：能控制资金流
结算的发起：2次审核（运营审核、财务审核）-发起结算
结算逻辑：结算服务根据你的结算维度去获取对账结果，根据对账结果（已经对账对平的订单）进行结算
结算的测试点：
1、运营平台进行操作结算（前端做防多点），点一次发一次http请求，你网络卡，重复触发结算按钮（弱网测试、狂点）
2、直接测后端接口：幂等校验（脚本并发）
后端实现：触发这个接口，提前请求一个接口，后端会生成一个卫衣的UUID给前端，然后再带着这个UUID去发起结算请求，
3、重新结算（支持）
4、非待结算的订单（未审核的）进行结算
5、未对账对平的订单进行结算（不支持）
6、批量结算（支持）
7、结算性能（时间不能太长、5分钟）
8、各种维度都要进行结算测试（混合维度不支持）
9、金额精度（0.99、100.99、负数、0）
10、结算一定要稳定、容错性要强（服务器原因挂掉了），恢复机制、数据库的事物（触发结算之前先备份结算相关的表数据）
清分-对账-结算测试点：
1、清分：做告警处理，清分异常了
2、对账：对清分的数据进行校验（对应支付笔数、如果笔数差距太大，就没有必要对账，触发报警机制（没有对平的超过多少笔，未对平的金额超过多少）、钉钉消息通知、微信消息通知、邮件、对账报错日志）
3、结算：容错处理、对账结果混乱（只要发现金额不等，立马停止结算，回滚已经结算的数据）
4、整个平台
1、各个页面的数据统计，准确性、一致性
2、财务报表
提现模块
角色：地推、商户、代理渠道
提现流程：
客户端（web、app、小程序）—支付平台后端—发送提现请求到合作银行
测试点：
1、各个角色的提现，角色的状态
2、内部接口（异步）：客户端-支付平台后端（核对请求接口的参数、测试场景）
3、外部接口（异步）：支付平台后端—合作银行（测试桩自测、联调测试：测试环境、生产环境）
4、回调接口的测试：外部接口的回调（1、银行主动调你2、主动查询（1s6次））
5、具体场景：
- 黑白名单（四要素、mac地址）
- 提现额度（每天的提现额度（渠道）、单笔提现、用户余额（平台–银行（子账户）））
- 提现额度锁定（余额1000–提现1000–二次发起提现提现不能成功，余额不足）
- 提现并发（2笔一起提现，消息队列，锁额度的时间）
- 同一笔订单提现多次（后端做两个接口，A接口（返回UUID）B接口（提现接口））
6、提现失败后的处理：（解冻额度、短信提醒、支持重新发起提现）
7、运营：支持后端重新提现（运营操作）
8、提现的手续费：查询用户配置的手续费与他提现代扣款的手续费是否一致
内扣：提现金额等于到账金额，扣余额的钱
外扣：提现金额大于到账金额，扣到账的钱
9、账户的种类：余额、垫资账户、冻结账户
可提现额度 = 余额+垫资-冻结
10、虚拟账户之间的关系要梳理清楚
11、通过脚本去校验
12、提现流水、出款渠道信息（出款路由逻辑）
退款模块
一、提现失败的退款
1、对应银行的接口文档各种失败的场景
2、退款各个账户计算是否正确
3、提现的流水、数据逻辑删除（有效性）、失败原因
二、商家发起的退款
1、全额退款
2、部分退款
3、退款清分（将支付订单的利润退回来），地推、渠道、商户
退款对账
4、支付订单银行要收费的，平台来承担银行支付所产生的手续费
5、退款金额原路返回
6、冻结商户的可提现金额，退多少冻多少
7、单笔交易要限制退款次数（避免退款多次，垫付过多的手续费 5次）
8、边界值（动了账户系统，提现金额边界值一定要测试）平台的余额、银行的余额
