# 1. 支付测试的核心关注点，资金安全、数据一致性与幂等为什么优先于功能可用性，如何体现到用例设计？ A 功能可用性优先，因为用户最直接感知到的是页面流程 B 资金安全、数据一致性与幂等性优先于功能可用性，因为资金错误会造成真实损失 ✓ 正确答案 C 所有测试点优先级相同，应平均分配用例数量 D 数据一致性比资金安全更重要，因为账务对不上会直接导致停服
# 2. 支付主流程测试，下单→支付→回调→订单状态更新的全链路用例与异常分支如何设计？ A 首页加载过慢导致用户无法进入下单页 B 支付成功但订单状态更新失败/回调丢失时的一致性兜底 ✓ 正确答案 C 优惠券图片样式显示错误 D 下单页面的文案排版错位
# 3. 支付回调的可靠性测试，重复通知、乱序回调、超时重试与签名校验失败如何验证？ A 重复回调应返回成功并重复处理业务，以保证数据不丢失 B 乱序回调（如成功后又收到支付中）应被系统拒绝或忽略，不能覆盖已确认状态 ✓ 正确答案 C 签名校验失败的回调应直接入账，避免渠道重试 D 回调超时无需处理，因为渠道一定会保证送达
# 4. 幂等性测试在支付/转账场景的设计，重复提交、并发请求与超时重试如何保证只生效一次？ A 只需验证用户快速点击两次不会重复扣款即可 B 超时重试属于正常行为，系统应再次扣款以补足金额 C 幂等键必须有唯一性约束，且需验证重复提交、并发请求、超时重试三种场景下业务只生效一次 ✓ 正确答案 D 并发请求使用相同幂等键时，每个请求都应成功入账
# 5. 对账测试，渠道账单与系统账务的核对维度（笔数、金额、状态差异）与差错处理流程？ A 对账只需核对总笔数和总金额是否一致即可 B 渠道有流水但系统没有属于正常情况，无需处理 C 单边账、金额不一致、状态不一致都是典型差错，需验证系统能发现并处理这类差错 ✓ 正确答案 D 对账失败无需告警，人工定期检查即可
# 6. 金额边界与精度测试，最小/最大金额、分/厘精度、四舍五入、汇率折算与溢出如何覆盖？ A 金额可以使用 Double 浮点类型计算，只要表面看起来正确即可 B 只需验证金额大于 0 即可，无需关注精度 C 四舍五入规则统一即可，无需关心多笔金额汇总的舍入误差 D 金额应以整数分或 BigDecimal 存储计算，并覆盖舍入累积、汇率折算与溢出场景 ✓ 正确答案
# 7. 并发场景测试，重复支付、超卖、并发转账与余额不足竞态如何设计并发用例？ A 需验证扣款/扣库存的原子性，防止余额不足仍扣款、超卖等竞态，并以数据库最终状态断言 ✓ 正确答案 B 并发请求下每个请求都应成功，以保证用户体验 C 并发测试只需验证接口不报错即可 D 余额不足时允许余额为负，后续再补足
# 8. 账务与余额测试，冻结/解冻、入账/出账、流水明细与余额一致性的验证方法？ A 需验证可用余额与冻结/解冻的守恒关系，以及每笔变动对应流水、余额与流水勾稽一致 ✓ 正确答案 B 冻结金额可以同时被扣款，属于正常操作 C 流水明细可有可无，不影响余额正确性 D 只需验证充值和提现的页面上金额显示正确即可
# 9. 退款流程测试，原路退回、部分退款、退款失败重试与退款对账如何验证？ A 需验证原路退回、部分退款金额不超原支付、失败重试幂等及退款对账 ✓ 正确答案 B 退款必须一次性全额退，不支持部分退款 C 退款失败后不能重试，只能人工处理 D 多次部分退款可以累计超过原支付金额
# 10. 资金安全测试，参数篡改、越权查询、重放攻击与回调伪造如何构造用例？ A 前端把金额改为 0.01 元，服务端应信任前端并以此为准 B 用户 A 可以查询用户 B 的余额，只要金额正确 C 需验证参数篡改、越权查询、重放攻击与回调伪造都有防护，关键参数以服务端校验为准 ✓ 正确答案 D 不加签名的回调也应被信任并直接入账
# 11. 支付渠道切换与降级测试，主备渠道切换、限额控制、渠道不可用时的降级与恢复？ A 主渠道不可用时直接报错即可，无需降级 B 限额控制只对单笔生效，单日累计无需限制 C 切换渠道后订单状态可以不一致，后续人工处理 D 需验证主备渠道切换、限额控制、渠道降级与恢复，且降级期间不产生账务差错 ✓ 正确答案
# 12. 风控规则测试，频次限制、风控拦截、申诉放行与白名单如何验证？ A 只需验证高频交易能被拦截即可 B 白名单用户也应受全部风控限制 C 被拦截的交易无需申诉，直接永久拒绝 D 需验证频次限制、风控拦截、申诉放行与白名单，且规则能准确命中且不误伤正常用户 ✓ 正确答案
# 13. 金融合规测试，实名认证、KYC、反洗钱、利率与费用展示的合规要求如何验证？ A 只需验证页面能正常打开即可 B 未实名认证的用户也可以正常交易 C 利率展示可以模糊标注，无需明示年化利率 D 需验证实名认证、KYC、反洗钱监测与利率费用展示等符合监管要求 ✓ 正确答案
# 14. 清结算测试，日切、T+1 结算、节假日顺延与清算批次异常如何设计用例？ A 需验证日切账期归属、T+1 结算、节假日顺延及清算批次异常的幂等重试 ✓ 正确答案 B 节假日结算应照常进行，无需顺延 C 当日交易当天必须结算完成，无需 T+1 D 清算批次失败后重跑会重复结算，属正常现象
# 15. 金融系统的可靠性测试，容灾切换、发布回滚与账务数据恢复如何演练与验证？ A 只需在正常环境跑通主流程即可 B 容灾切换后数据可以不完整，后续人工补齐 C 发布回滚后会破坏数据，属于正常现象 D 需通过故障演练验证容灾切换、发布回滚与账务数据恢复，并保证故障期间账务一致 ✓ 正确答案
# 16. 支付订单状态机测试，订单状态流转、非法迁移与并发状态更新如何设计用例，状态机实现正确性如何验证？ A 需用"状态×事件"穷举矩阵验证合法流转、非法迁移被拦截及并发更新的正确性 ✓ 正确答案 B 已取消的订单可以再次支付成功并更新状态 C 只需验证支付成功后状态变为已支付即可 D 并发操作下状态可以任意覆盖，无需控制
# 17. 手续费与优惠计算测试，费率档位、四舍五入与优惠分摊的精度如何验证，金额守恒如何断言？ A 舍入误差无需关注，累计后可以忽略 B 只需验证单个订单的手续费显示正确即可 C 需验证费率档位边界、舍入精度、优惠分摊，并断言实付=原价-优惠+手续费的金额守恒 ✓ 正确答案 D 优惠分摊后剩余金额可随意处理，不影响守恒
# 18. 金融测试数据治理，账务数据的构造、脱敏与资金安全约束下如何准备测试数据？ A 直接使用生产真实数据测试，保证真实性 B 需对敏感字段脱敏、使用虚拟资金、生产测试环境隔离，并构造满足合规与守恒的数据 ✓ 正确答案 C 测试数据无需做任何标识，可随意混入生产 D 真实银行卡号可以保留在测试数据中
# 19. 账务试算平衡测试，借贷平衡、日结轧账与不平账定位如何处理，试算平衡脚本本身的正确性如何验证？ A 只需确认借贷合计相等即可，无需定位不平账 B 试算平衡脚本不会出错，无需单独验证 C 需验证借贷平衡、日结轧账、不平账定位，并用平衡与不平衡样本验证试算平衡脚本自身正确性 ✓ 正确答案 D 日结轧账不平衡时可以直接忽略，第二天再处理
