商户入网测试点：
内部接口
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、边界值（动了账户系统，提现金额边界值一定要测试）平台的余额、银行的余额
标签：提现,聚合,测试点,结算,接口,对账,支付,退款 来源： https://blog.csdn.net/liwen0042/article/details/120352685
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。