支付与金融系统测试面试题

本文档包含 18 道支付与金融系统方向的高频面试题，覆盖业务全景、合规与牌照、支付链路、幂等设计、回调与签名、退款与冲正、对账与差错单、清结算、金额精度、并发扣款、风控、密钥管理、重放防御、监管报送、容灾与多活。支付测试是测试岗位里专业门槛最高的方向之一，资损案例多、监管要求严，准备时要从"资金安全"和"合规底线"两条主线展开。

一、业务全景与支付链路（4题）

Q1: 支付系统的角色和资金流向是什么样？

答案：

支付看着简单（扫码、点一下、付款完成），背后其实涉及多个角色和多条资金流，是金融基础设施的核心。

角色解释：

消费者。发起支付的最终用户，关心"能不能成功付款、扣的金额对不对"。

商户。接收付款的商家，关心"用户付的钱能不能到账、对账对不对"。

收单机构。为商户接入支付能力的中间方，有支付牌照的可以自营（如京东支付），没有的接第三方（如蚂蚁、财付通）。

第三方支付（支付宝、微信支付）。撮合用户和银行的中间方，承担风控、收单、对账。

银行。资金真正存放的地方，扣款发生在银行。

清算机构（网联、银联）。央行体系下的清算枢纽，从 2018 年起所有第三方支付都必须接入网联，资金流向受央行监管。

信息流和资金流是分开的。信息流是用户感知的"支付成功"（毫秒级），资金流是 T+1 / T+N 清算（从银行 → 清算机构 → 收单 → 商户，可能要 1~7 个工作日）。测试时要清楚区分两条流，业务系统主要管信息流，资金核对靠对账系统。

测试视角下要熟悉这张图，因为任何一个角色出问题（银行限额、第三方支付故障、清算延迟）都会反映到支付测试场景里。

Q2: 支付牌照和合规要求有哪些？测试时怎么覆盖？

答案：

支付系统不是"想做就能做"，国内监管极严，测试同学如果不懂合规很容易漏关键场景。

牌照体系。

支付业务许可证（央行发）。分网络支付、预付卡发行与受理、银行卡收单三类，每类还区分全国和地方。互联网公司常见的"支付牌照"就是这个，全国性网络支付牌照含金量最高。

银行业金融机构许可证。商业银行、信用社等需要这个，比支付牌照高一档。

基金销售、保险中介、证券、小贷等不同金融业务还有各自牌照。

合规要求。

PCI-DSS。国际银行卡数据安全标准，凡是涉及银行卡号、CVV、有效期的存储传输都要符合。测试时要验证：是否物理隔离卡号存储、密钥是否分级管理、是否有审计日志、敏感数据是否脱敏（页面、日志、监控全脱敏）。

人行二代支付清算（CNAPS2）。和银行直连的接口规范，对报文格式、加密方式、压数规则都有要求。

网联接入要求。第三方支付接网联的接入规范，包括接口协议、风控数据上报、断直连合规。

反洗钱（AML）。大额交易报告（单笔超 5 万、累计超 20 万 / 日要上报）、可疑交易上报、客户身份识别（KYC）、客户身份资料和交易记录保存（10 年）。

数据合规。个人信息保护法（个保法）要求数据收集最小化、加密存储、跨境数据传输需要合规审批。

测试覆盖思路：

合规清单化。把每条监管要求做成一份"合规检查清单"，每次发布前过一遍。

专项审计用例。专门做敏感字段加密、日志脱敏、留存期限、操作审计的回归用例。

监管接口测试。和网联、银联、央行的接口通常有专门的"测试环境"，定期跑联调用例验证报文格式正确。

合规演练。模拟监管检查，把所有数据导出、所有日志查询、所有审计追溯都跑一遍，看能不能在监管要求的时限内（一般 24 小时内）响应到。

支付测试岗位的资深同学通常是"半个合规专家"，建议每年抽时间看一遍央行公开的支付相关政策（央行官网 → 政务公开 → 政策法规）。

Q3: 常见支付场景有哪些？测试差异是什么？

答案：

支付场景比一般人想象的多，测试时要先识别属于哪种场景再设计用例。

C2B 主扫（用户扫商家二维码）。最常见的小额支付场景，二维码可以是固定（小卖部）或动态（餐厅点单后生成）。测试关注点：金额输入正确性、支付方式选择、超时设置（一般 2~15 分钟）、二维码失效后再扫的处理。

C2B 被扫（商家扫用户付款码，俗称声波支付）。商家用扫码枪扫用户出示的付款条码，常见于超市、便利店收银。测试关注点：付款码时效（1 分钟内有效）、付款码安全（不能截图盗用）、网络异常时商家端的重试。

B2C 主扫（商家拿钱）。常见于退款、转账、商家给用户发红包。

代扣（无感支付）。用户事先授权后，商家可以定期或按需扣款，常见于水电气、视频会员、信用还款、滴滴打车。测试关注点：用户授权流程、解约流程、扣款失败重试、扣款额度上限。

聚合支付（多个支付方式聚合到一个二维码）。一个二维码用户用支付宝、微信、银联云闪付都能扫，背后做协议解析。测试关注点：识别准确性、不同支付通道的优先级、单通道故障时的降级。

跨境支付。跨境收款、跨境付款、跨境退款，涉及外汇管制、汇率、清关。测试关注点：汇率取值时机（下单时锁价 vs 实付时取价）、汇率波动差额承担方、外汇额度（个人年度 5 万美元）。

数字人民币支付。央行数字货币，2020 年起试点。技术上有双离线支付能力（双方都没网也能支付）、可控匿名性。测试关注点：钱包等级（不同等级有额度上限）、双离线场景、与第三方支付的差异。

每种场景下测试重点不同，准备时建议结合自己经历过的项目深入 2~3 个场景，泛泛而谈面试官会觉得没真做过。

Q4: 一笔 C2B 扫码支付的端到端链路怎么测？

答案：

C2B 主扫是最常见的支付场景，端到端链路涉及客户端、商户、收单、第三方支付、银行五方，每个环节都有测试关注点。

测试要点按链路拆分。

支付下单。验证签名、金额、订单号、商户号、回调地址等参数正确；幂等（同一订单号重复下单返回同一二维码）；金额校验（不能传 0、负数、超大值）；签名错误返回相应错误码。

收银台 / 二维码展示。展示金额、商品信息正确；超时时间设置（默认 2~15 分钟）；二维码格式（标准的 URL Scheme，支付宝/微信都能识别）。

支付过程。用户确认密码/生物识别失败的处理；支付过程中关闭收银台、点返回的处理；网络断开时的重试。

异步回调。回调签名验证、回调幂等（同一回调多次收到只处理一次）、回调失败的重试策略（一般 8 次：4min、10min、10min、1h、2h、6h、15h、24h，符合微信/支付宝规范）、回调字段完整性（金额、订单号、支付时间、第三方流水号）、回调到达前用户重新打开订单页的状态展示。

同步查询兜底。回调可能延迟或失败，业务方要主动调"订单查询接口"兜底。测试时人为屏蔽回调，验证主动查询能否补单。

异常路径。

用户支付成功但回调还没到。前端要不要轮询订单状态、轮询的频率、轮询超时后用户能否手动刷新。

回调到了但本地订单状态机不允许更新（如订单已超时关闭、订单状态异常）。此时资金已扣，必须有"异常单"处理流程（自动退款或人工介入）。

重复回调。同一笔回调多次到达，幂等处理后回 SUCCESS 给支付方；若回 FAIL 会持续重试。

回调签名错误。可能是密钥不一致或被攻击，应拒绝并告警。

测试时建议把这张时序图打印出来贴墙上，每个箭头都对应一组用例。这是支付系统最核心的测试场景。

二、幂等、回调与对账（5题）

Q5: 支付幂等怎么设计？测试时怎么验证？

答案：

支付链路里幂等是"红线"，任何一个非幂等环节都可能造成资损或重复扣款。要测的幂等环节远比一般人以为的多。

下单幂等。同一个商户订单号在支付平台只能产生一笔支付单。机制：商户传 out_trade_no，支付平台用唯一索引或 Redis 分布式锁保证一个 out_trade_no 只创建一笔。

支付幂等（重复支付防控）。同一笔商户订单在前端可能被用户支付多次（手抖、网络异常重试），支付平台要识别并阻止。机制：用户付款前先查同一 out_trade_no 的已支付记录，已支付的直接返回成功，未支付的才走支付流程。

回调幂等。同一笔回调可能被第三方支付重试多次到达商户系统，业务方处理回调时必须幂等。机制：根据 transaction_id（第三方流水号）+ 状态做去重，已处理的直接返回 SUCCESS。

退款幂等。同一笔退款请求重复提交，应只产生一笔退款。机制：用 refund_no（商户退款单号）做唯一性约束。

测试方法：

并发幂等。多线程同时提交相同 out_trade_no，断言只产生一笔支付单。

时序幂等。第一次提交成功后再次提交同样请求，断言返回相同结果（包括支付链接 / 二维码 URL 都应一致或至少业务等价）。

异常重试幂等。模拟网络超时，让客户端重发请求，断言不产生重复订单。

回调幂等。人为重发同一回调多次（用 curl 或 Postman），断言订单状态只变一次、入账记录只有一条。

跨支付方式幂等。同一商户单已经被微信支付了，再用支付宝重新发起支付，应被拒绝（同一商户单不能多次支付成功）。

幂等失败的反面案例：

订单状态先更新再做幂等校验。状态都改了才发现是重复，已经造成问题。

幂等键设计太粗。用 user_id + order_id 做幂等键，没考虑分布式场景下的并发，导致同一组合多次成功。

幂等记录有 TTL。Redis 幂等记录设了 5 分钟过期，5 分钟后重试又成功创建一笔。支付场景的幂等记录建议永久保留或至少 30 天。

幂等测试要做到自动化每日跑，发现新 Bug 立刻报。支付岗位的测试同学很多就是靠"幂等大师"成名的。

Q6: 支付异步回调怎么测？签名验证有哪些坑？

答案：

异步回调是支付系统资损 Bug 高发区，签名验证不做好就是给攻击者送钱。

回调流程。第三方支付收到银行扣款确认后向商户系统的 notify_url 发 POST 请求，包含支付结果和签名。商户收到后验签 → 处理业务 → 返回 SUCCESS。如果商户没回 SUCCESS（或回 5xx），第三方会按递增间隔重试 8 次。

测试用例：

正常回调。带正确签名、正确字段，断言订单状态正确变更、入账记录正确生成、返回 SUCCESS。

签名错误。伪造一个错误签名的回调，断言拒绝处理、记录告警日志、不更新订单状态。这是防止攻击者伪造回调骗钱的关键。

参数篡改。修改金额、订单号等关键字段，重新签名（如果攻击者拿到了密钥）会怎样；不重新签名时拒绝处理。

签名算法降级。某些支付平台支持多种签名算法（MD5、HMAC-SHA256、RSA），要测每种算法的正确性，避免攻击者用弱算法绕过。

回调延迟。模拟回调延迟到达（如订单已超时关闭、用户已申请退款），断言系统按"异常单"处理。

回调缺失。屏蔽回调，断言主动查询能补单（如分钟级轮询、每天 T+1 对账补单）。

回调字段不一致。回调金额和订单金额不符，应拒绝并触发资损告警（典型攻击场景）。

回调来源 IP。某些支付方提供 IP 白名单，要测白名单生效（非白名单 IP 的请求被拒）。

签名验证常见坑：

密钥管理。生产、预发、测试用不同密钥，环境配置错误会导致全部回调签名失败。

字符串拼接顺序。验签前要把参数按字母序排列再拼接，少数实现按"传入顺序"拼接，跨语言交互时容易出错。

特殊字符编码。中文、空格、特殊符号在 URL 编码、JSON 编码下的差异，要测各种特殊字符场景。

签名字段。哪些字段参与签名（一般"sign 本身不参与"，多数实现也排除空值字段），实现不一致会导致跨平台对接失败。

测试时一定要用真实的支付沙箱（支付宝沙箱、微信支付沙盒）跑通完整链路，光看代码逻辑判断不出环境问题。

Q7: 退款、红冲、撤销和冲正有什么区别？怎么测？

答案：

这几个词常被混用，实际上对应不同场景，测试时要分清。

退款（Refund）。最常见场景，用户/商家发起，把已支付的钱退回给用户。可以全额退、部分退，可以是当天退（原路返回）、跨天退（T+N 入账）。

撤销（Cancel）。在某些通道（如银行卡 POS），如果交易当天发现错误（比如金额输错），可以发起"撤销"操作，相当于把这笔交易作废。撤销和退款的区别：撤销不产生新流水，原交易回滚；退款产生新流水，原交易保留。撤销有时效（一般当天），过期只能走退款。

冲正（Reverse）。银行 / 收单机构发起的"对冲"，用一笔反向交易抵消原交易。和撤销区别：冲正一般是系统内部使用，由收单系统自动发起；撤销是商户主动发起。

红冲。会计概念，用一笔"负数交易"或"反向交易"冲销原交易。常见于业务系统的账务记录。

测试要点：

退款测试。

正常退款（同卡退回）；

延迟到账（跨天退到银行卡可能要 1~3 个工作日）；

部分退款（订单 100 元，退 30 元，剩余 70 元保留）；

多次部分退款累计不能超过原金额；

退款金额合法性（不能负数、不能超过订单金额、最小金额限制如 0.01 元）；

特殊场景：原支付方式失效（如银行卡注销）应有兜底方案（退到支付平台余额）；

退款幂等：同一退款单号重复提交只产生一笔；

退款异步：退款是异步处理，要测从"申请"到"成功"各状态的流转（处理中 → 成功 / 失败）。

撤销测试。

当天撤销成功（原交易回滚、用户卡上无扣款流水）；

跨天撤销失败（应自动转为退款）；

部分撤销（部分通道不支持，测试时要确认通道能力）。

冲正测试。

通讯异常下的自动冲正：用户付款时银行已扣款但响应超时返回失败，系统应自动发起冲正避免长款；

冲正成功后业务方收到回调，订单状态正确回滚；

冲正失败后人工介入流程（如挂账等待人工处理）。

退款异常场景：

原支付通道故障（银行系统维护），退款请求堆积，要有重试和告警。

银行卡注销。退款时发现原卡已注销，按规则退到支付平台余额或冻结等待人工处理。

跨境退款。汇率波动导致退款金额和原支付金额不完全对等，按约定规则处理。

测试时强烈建议自己跑一遍真实场景（用沙箱或小金额真实交易），感受退款时效和异常路径，比看文档有用得多。

Q8: 商户对账和银行对账怎么测？

答案：

对账是支付系统的最后一道防线。前面所有的幂等、签名、状态机都做对了，如果对账对不上，照样赔钱。

商户对账（商户 vs 支付平台）。商户每天 T+1 从支付平台拉取昨日交易明细，和自己系统对比，找出"我有他没有""他有我没有""金额不一致"三类差异。

银行对账（支付平台 vs 银行）。支付平台每天对所有通过的银行接口（包括各家发卡行）做对账，确保自己记录的扣款笔数和银行实际扣款笔数一致。

测试关注点：

对账文件格式。每家平台/银行的对账文件格式不同（CSV、固定列宽、Excel），要测解析正确性、特殊字符处理、空行处理、文件名规范（一般 yyyyMMdd.txt）。

数据完整性。下载的对账文件必须包含 T-1 所有完成交易。要测大笔交易日（百万级订单）的下载是否完整、是否丢数据。

时区。涉及跨境时，对账文件按哪个时区切日是关键差异。支付宝、微信按北京时间切，PayPal 按美国东部切，要做时区转换适配。

差异分类。常见差异类型：

我有他没有（短款）：我方记录支付成功但平台没有，要发起查询确认是否真支付了，没支付的要冲销订单。

他有我没有（长款）：平台有但我方没有，要找原因（可能是回调失败但订单系统超时关闭了），需补入账。

金额不一致：双方都有但金额对不上，最严重的差异，必须人工介入。

状态不一致：双方都记录支付成功，但其中一边状态是"已退款"对方没有，按时间戳判断哪个是最新。

差异处理流程。每类差异都有对应处理 SOP：自动补单、自动冲销、自动转人工。测试时要验证各类差异都能识别并分类，无遗漏。

历史数据可追溯。对账记录、差异记录、处理记录都要长期保存（监管要求 10 年），要测查询和导出能力。

测试方法上常用"造数 + 跑对账"：

按场景造各类差异数据（短款、长款、金额不符），断言对账系统能识别。

把历史某天的真实对账文件解析后造一个测试库，回归对账业务逻辑。

线上做"日级巡检"，每天扫描对账结果，差异超过阈值（如金额超过 100 元 / 笔数超过 5 笔）告警。

支付测试岗位经常会要求"懂会计"，因为对账本质上是会计核对的工程化实现，搞不清借贷方向、流水概念，对账测试做不细。

Q9: 长尾差错单和异常单怎么处理？

答案：

支付系统永远会有"差错单"（数据不一致的订单），追求 100% 对账完美不现实，重点是建立差错单识别、分类、处理的完整闭环。

差错单的常见来源：

通讯异常。用户付款时银行已扣款但支付平台没收到响应，平台标"未支付"但用户卡上已扣，这是最常见的长款来源。要靠主动查询或对账补回。

回调丢失。支付成功但商户收不到回调，订单一直"待支付"超时关闭。靠商户主动查询或 T+1 对账补单。

状态错乱。同一笔交易在不同系统状态不同步，比如订单系统是"已完成"，支付系统是"待支付"。

时区错乱。涉及跨境和跨平台时，时区切换导致同一笔交易在 T 日和 T+1 日各出现一次。

测试要点：

差错单识别准确率。每类差错都应被识别并分类，不能漏分类导致"长尾投诉"。测试时按差错类型造数据，断言识别准确。

自动化处理覆盖率。常见差错（小金额短款、状态错乱）应能自动处理（自动查询、自动补单、自动冲销），大金额或复杂差错走人工。测试自动化处理的边界（如金额阈值、用户类型阈值）。

人工处理闭环。运营同学在差错处理后台能看到差错单详情、能查询关联数据、能执行预设操作（补单、退款、冻结）；每个操作都有审计日志；操作过程有权限校验（高金额需双人复核）。

数据追溯。任何差错单的处理记录都能反查到「原始交易」「对账差异」「人工操作」「最终结果」，符合监管"全链路可追溯"要求。

线上巡检。每天 T+1 跑全量对账后生成"差错单日报"，超过阈值的告警值班同学。测试时要模拟告警触发条件，确认告警能到对的人。

差错单的处理水平直接体现支付团队的工程能力。测试同学要把"差错率"和"差错处理及时率"作为团队 KPI 的一部分推进。

三、清结算与金额精度（4题）

Q10: T+1 清算与分账测试要做哪些？

答案：

清算和结算容易混淆，先说清概念：

清算（Clearing）。指交易双方应付应收的核算和净额计算，比如商户今天有 1000 笔交易共 50 万元，扣除手续费、退款后净结算金额是 X 元。

结算（Settlement）。指实际的资金划付，把 X 元从支付平台账户划付到商户银行账户。

T+1 是国内主流结算周期：T 日交易，T+1 日清算并出账。也有 T+0（实时到账，多用于秒到产品）、T+N（N 一般是节假日延后）。

分账是"一笔交易的钱分给多个收款方"，常见于平台型业务（淘宝商家、外卖平台、网约车）。一笔订单可能要分给商家、平台、物流、税费、第三方服务费等多方。

测试关注点：

清算正确性。每日清算金额 = 交易金额 - 退款金额 - 手续费 - 风控冻结 + 投诉金额回退 + ... 全部加减项要列清楚并逐项测。这是支付测试的"会计题"，每一项都要单测，再做组合测试。

结算文件。结算单要包含明细（每笔交易号、金额、手续费）和汇总（净结算金额、应收应付），格式要符合财务和监管要求。

结算时效。T+1 必须 T+1 日 X 点前出账（一般要求上午 11 点前），延迟超时要告警。测试时设置不同时区、跨周末、跨节假日（春节）的场景。

分账规则。

按比例分账（如商品价 100 元，平台抽 10%，商家 90%）。

按金额分账（如运费 5 元给物流，剩余给商家）。

按层级分账（先扣平台佣金，剩下按商家约定再分）。

测试时每条规则都要正向和反向用例，关注小数点分摊（除不尽时按规则取整或四舍五入）。

分账时机。

同步分账（支付成功立即分账）：风险是商家可能后续退款，分给商家的钱已经发出去要追。

担保分账（资金先冻结，确认收货后分账）：电商常用，但要测冻结、释放、超时自动释放逻辑。

冻结期与释放。冻结期（如 7 天确认收货）测试要包括正常释放、提前释放（用户主动确认）、超时释放、退款时冻结资金回退。

异常处理。

分账失败如何处理（某个收款方账户异常）。

部分分账失败如何处理（其他方继续，失败方挂账）。

分账后退款如何处理（按比例从各收款方追回，可能涉及法律风险）。

实际场景里"分账冲突"是大头：商家收到分账了，用户又申请退款，钱已经支付出去了怎么追？答案是建立"准备金"或"风险金"机制，从商家结算款里预留一部分应对退款，测试时要专门覆盖。

Q11: 金额精度和舍入策略怎么测？

答案：

支付测试有句话："金额错一分，事故升一级"。金额精度处理是技术债重灾区，几乎每个团队都踩过坑。

存储与传输。

金额必须用 BigDecimal（Java）、Decimal（C#）、Decimal（Python）等高精度类型，禁用 double / float。double 0.1 + 0.2 ≠ 0.3 这种小学水平的坑在金融系统里千万不能犯。

接口传输统一用字符串或整数（分），不要用浮点数。比如金额 1.23 元，接口传 "1.23" 或 123（单位分），收到后再转 BigDecimal 处理。

精度等级。

人民币精确到分（2 位小数）。

USD 精确到美分（2 位小数）。

加密货币可能精确到 8~18 位小数，要专门处理。

舍入策略。常见几种：

四舍五入（ROUND_HALF_UP）。最常用，1.235 → 1.24，1.234 → 1.23。多数电商业务用。

银行家舍入（ROUND_HALF_EVEN）。1.235 → 1.24，1.225 → 1.22（向偶数靠拢，减少累计误差）。多数金融业务用。

向上取整（ROUND_UP）。1.231 → 1.24。计费类业务用（手续费向上算对自己有利）。

向下取整（ROUND_DOWN）。1.239 → 1.23。打折类业务用（用户优先）。

测试场景：

基础运算精度。0.1 + 0.2 应等于 0.3，不能是 0.30000000000000004。

舍入策略一致性。系统内所有金额计算用统一舍入，不能这边四舍五入那边向上取整。

边界值。0.01（最小币种单位）、0.005（精度边界）、9999999.99（最大金额）、负数（应禁止或专门处理）。

分摊场景。100 元优惠分摊到 3 件商品，每件应分多少？33.33 + 33.33 + 33.34 还是 33.33 + 33.33 + 33.33（差 1 分挂账）？必须有明确策略并测试。

跨币种。人民币 → 美元的汇率换算，先除还是先乘、先汇率还是先金额，结果差几分。

整批运算。1 万笔小金额累加是否准确。可以用财务报表的"总金额"和"明细金额累加"做对比。

实战坑：

数据库 decimal 字段长度不够。订单金额 decimal(10,2) 最大 99999999.99 元，遇到大单溢出。

前端展示截断。后端是 1.236，前端显示 1.24，发邮件用 1.23，三处不一致。

跨系统传递丢精度。订单系统传 BigDecimal，财务系统接成 double，精度丢失。

金额测试一定要写自动化断言，每个金额相关接口都加"精度断言"，不能光靠肉眼比对。

Q12: 账户余额扣减并发怎么测？分布式锁和乐观锁怎么选？

答案：

账户余额扣减是金融系统并发热点，多个交易同时扣同一账户余额，处理不好就出问题：余额扣成负数、并发扣款只扣了一次、扣多了找不回。

并发场景：

同一用户多设备同时支付。

定时扣款（代扣）多任务并行触发。

商家余额提现同时被多笔退款扣减。

技术方案：

数据库行锁（悲观锁）。SELECT ... FOR UPDATE 锁住余额行，扣减后释放。优点是简单可靠，缺点是高并发下性能差，容易死锁。

乐观锁（版本号）。读余额时带版本号，更新时 UPDATE ... WHERE version = ?，更新失败重试。优点是性能好，缺点是高冲突场景下重试多。

分布式锁（Redis、ZK）。用 Redis SET NX 或 Redisson 锁住"账户 ID"，扣减完成后释放。优点是和数据库解耦，缺点是要处理锁超时、网络分区。

数据库原子操作。UPDATE account SET balance = balance - ? WHERE id = ? AND balance >= ?，依赖数据库本身的原子性和约束。这是最简单也最可靠的方案，金融场景首选。

测试方法：

正常单线程。先把基础场景跑通，扣减、回滚、查询都对。

并发压测。500 线程同时给同一账户扣款，断言：余额不会变成负数；总扣款数等于成功响应数；账户流水记录数等于成功扣款数。

故障注入。压测过程中重启数据库、断主从，看是否会产生超扣、漏扣。

混合场景。同一账户同时有充值、扣款、退款，看最终余额是否正确（等于初始余额 + 所有充值 - 所有扣款 + 所有退款）。

死锁检测。设置死锁告警，压测时观察死锁次数；正常应该零死锁，有死锁说明 SQL 设计有问题。

资金安全是金融系统的核心 KPI，资损 Bug 一旦上线就是 P0 事故，建议账户相关代码强制 100% 单元测试覆盖率 + 完整并发回归用例。

Q13: 多币种和汇率测试要做哪些？

答案：

跨境支付、跨境电商、外汇等业务都涉及多币种，汇率处理是高频出 Bug 的地方。

币种基础知识。

ISO 4217 标准定义币种代码：CNY（人民币）、USD（美元）、EUR（欧元）、JPY（日元）等。

不同币种精度不同。CNY、USD 精确到分（2 位小数），JPY 精确到日元（0 位小数，没有"日分"），KWD（科威特第纳尔）精确到 3 位小数。

汇率体系。

中行牌价：央行公布的官方中间价。

银行实时汇率：每家银行按中间价上下浮动报价。

第三方汇率：支付宝、PayPal 等给的实时汇率，比银行牌价略差。

汇率取值时机：

下单锁价。用户下单时锁定汇率，付款时按锁价结算。风险归商户（汇率波动商户承担）。

实付取价。付款瞬间取最新汇率。风险归用户（用户可能看到价格变动）。

跨日切价。订单跨日时按哪天汇率，要业务约定。

测试场景：

币种精度。JPY 不能有小数（如金额 100.5 日元是错的）；KWD 必须 3 位小数；测试各币种边界精度。

币种转换。CNY → USD → JPY 中间是先换 USD 再换 JPY，还是直接 CNY → JPY；不同路径的汇率不一定一致，按业务约定测试。

汇率浮动。同一笔订单下单时 1 USD = 7.20 CNY，付款时 1 USD = 7.25 CNY，差额 5 元怎么处理。

退款汇率。原支付汇率 7.20，退款时汇率 7.25，应按哪个汇率退（一般按原支付汇率，差额平台承担，但要测系统是否按预期执行）。

汇率失效。汇率数据源故障时怎么处理（用上次汇率？拒绝交易？）。

货币符号显示。前端展示要正确，¥（人民币）、$（美元）、€（欧元）、￥（日元，看着像 ¥ 但实际是 ￥，全角）、₩（韩元）、￡（英镑）。一个常见 Bug 是把 CNY 显示成 $，跨境用户混淆。

跨币种结算。商户在中国用 CNY 结算，但平台是国际平台，最终币种转换要走外汇申报。

合规。外汇管制（个人年度 5 万美元结售汇额度）、申报、监管报送，每个都要测。

跨境支付测试岗位的资深同学很少，多数都是边做边学，建议把国家外汇管理局、央行、各大银行的公开政策每年扫一遍。

四、风控、安全与稳定性（5题）

Q14: 支付风控规则怎么测？反洗钱、反欺诈、黑名单各自关注什么？

答案：

支付风控是金融系统的生命线，测试时要分清不同类型风控的关注重点。

反洗钱（AML）。监管要求，目的是切断犯罪资金流转。核心规则：

大额报告。单笔超 5 万元、累计 24 小时超 20 万元的交易自动上报到央行 PBC（人民银行）反洗钱中心。测试要覆盖刚好 5 万、刚好 20 万、跨日累计、跨账户累计的边界。

可疑交易识别。如频繁高额转入立即转出（资金过路）、与高风险国家交易、与制裁名单交易。识别后人工复核 + 报送监管。

KYC（Know Your Customer）。用户身份信息核验，包括实名认证（身份证 + 人脸）、地址证明、职业信息。要测各级账户的认证要求差异（小额账户 KYC 简单，大额账户更严格）。

可疑客户跟踪。被标记可疑的客户后续交易要专项监控，关注交易模式变化。

反欺诈（Fraud Prevention）。主要防黑产、盗刷、欺诈。核心规则：

设备指纹。识别设备唯一性，防群控、改机、模拟器。测试时用真机正常使用、群控模拟器、改机软件分别尝试，看识别率。

行为分析。下单速度、滑动轨迹、点击模式判断真人 vs 脚本。

异地登录。新城市登录触发二次验证。要测从北京到上海登录、海外登录的风控触发条件。

异常交易模式。如夜间高频小额、节日高额、新用户大额，触发不同等级风控。

短期高频。1 小时内多笔到不同账户，可能是被盗刷在洗钱。

黑名单（Blacklist）。直接拒绝的对象，包括：

身份证黑名单（被举报欺诈、监管要求冻结的身份证）。

手机号黑名单（虚假号、黑产号）。

银行卡黑名单（被盗刷卡、监管冻结卡）。

设备黑名单。

IP 黑名单（代理 IP、机房 IP）。

商户黑名单（违规商户）。

测试方法：

规则功能测试。每条规则都按"刚好命中 / 不命中 / 边界"设计用例，覆盖正反场景。

灰白测试。建立"白名单用例"（真实合法用户行为）和"黑样本用例"（已知黑产手段），定期跑回归看规则的真阳率和误伤率。

策略组合测试。多条规则同时触发时按优先级处理，测试不同优先级组合下的行为。

规则配置测试。规则配置后台的增删改查、上下线、灰度发布、回滚能力。

线上模拟攻击。定期做"红蓝对抗"，红队尝试各种欺诈手段，蓝队观察识别率和处理时效，迭代规则。

风控规则更新频繁，建议每条规则都有对应自动化用例，规则变更时自动跑回归。

Q15: 加签验签和密钥轮换怎么测？

答案：

支付系统大量使用密码学保证传输和身份安全，签名 / 验签 / 密钥管理出错是高频资损来源。

签名机制。

对称签名（HMAC-SHA256）。商户和支付方共享一个密钥，双方用同一个密钥做签名和验签。优点是简单快，缺点是密钥泄露双方都失守。

非对称签名（RSA / SM2）。商户用自己的私钥签，支付方用商户的公钥验；支付方用自己的私钥回签，商户用支付方的公钥验。优点是更安全（私钥不离开本机），缺点是性能略差。

国密 SM2 / SM3 / SM4。国产密码算法，金融监管推荐使用。SM2 对应 RSA，SM3 对应 SHA-256，SM4 对应 AES。

签名测试维度：

签名生成正确性。给定输入和密钥，签名结果应与预期一致。可以用业界标准测试向量验证算法实现没问题。

字段拼接顺序。多数实现要求字段按字母序排列后拼接成 querystring 再签名。测试时打乱字段顺序看签名是否还能正确生成（应一致）。

特殊字符。中文、空格、URL 编码、JSON 转义等特殊字符的处理一致性。

空值处理。值为 null / 空字符串 / 缺失字段是否参与签名。多数实现是"空值字段不参与签名"，但要明确并测试。

时间戳。签名一般包含 timestamp 防重放，测试过期签名应被拒（如 5 分钟前的签名）。

随机数 nonce。同一签名内容用不同 nonce 应得到不同签名结果，防止预计算攻击。

密钥管理与轮换：

存储安全。密钥必须加密存储，不能明文落盘、不能写日志、不能进版本控制。生产建议用 HSM（硬件加密机）或 KMS（密钥管理服务）。

权限隔离。开发同学不应能接触生产密钥；通过 OnDuty 流程可以临时查看，所有查看操作要审计。

定期轮换。密钥要定期更换（一般 90 天 ~ 1 年），轮换期间要有"双密钥"过渡（新旧密钥都可用），避免业务中断。

紧急轮换。密钥疑似泄露时立即更换，并通知所有关联方。

测试时常见坑：

环境串密钥。把测试密钥用到生产、或生产密钥用到测试，泄露风险大。

密钥编码混乱。base64 编码、hex 编码、PEM 格式互转出错。

证书过期。RSA 证书有有效期，过期后所有签名失败，要监控证书到期时间提前续期。

签名验签的测试一定要在每个环境真实跑通，跨环境差异是大头。

Q16: 重放攻击怎么防御和测试？

答案：

重放攻击是支付系统的经典攻击：攻击者抓到一个合法支付请求，重复发送多次，骗系统多次扣款或多次到账。

防御机制：

时间戳。请求带 timestamp，服务端校验当前时间和 timestamp 差距，超过阈值（一般 5 分钟）拒绝。优点是简单，缺点是时间窗内重放还是有效。

Nonce / RequestId。请求带唯一随机数，服务端缓存已用过的 nonce（一般 Redis 缓存 5~30 分钟），重复使用直接拒绝。和时间戳配合用最稳。

幂等键 / 业务单号。业务层面的幂等保证，同一商户订单号多次提交只处理一次。

签名包含时间戳和 nonce。时间戳和 nonce 必须参与签名，否则攻击者修改这两个值就能绕过。

测试场景：

完整重放。把抓到的一个合法请求原封不动重发，断言被拒。

修改时间戳重放。把 timestamp 改成当前时间，但 nonce 不变，断言被拒（nonce 已用）。

修改 nonce 重放。把 nonce 改成新值但其他不变，断言被拒（签名校验失败，因为 nonce 参与签名）。

修改时间戳和 nonce 同时重放。两个都改并重新签名（如果攻击者拿到密钥），断言不应该被拒；这里能被拒说明攻击者还要绕过密钥拿不到，密钥安全是最后防线。

跨设备 / 跨用户重放。A 用户的请求被 B 用户重发，断言被拒（用户身份字段参与签名）。

并发重放。同一请求同时发 100 次，断言只处理 1 次（幂等保证）。

时间窗边界。timestamp 在阈值边界（如 5 分钟差 1 秒、5 分钟过 1 秒）的行为。

测试方法上常用 Postman 或 Python 脚本抓真实请求重放，配合不同的修改组合，每种攻击场景写对应用例。专业的支付公司还会做红蓝对抗，专门攻击自己。

防御深度上的建议：永远假设"前端是不可信的"，所有关键校验必须在服务端做，并且每一层都设防御（前端 + 网关 + 业务 + 数据库）。

Q17: 监管报送和日志合规怎么测？

答案：

国内金融业务监管严格，报送和日志合规是测试同学必须懂的环节。

主要监管报送类型：

人行报送。

大额交易报告（24 小时内单笔超 5 万或累计超 20 万）。

可疑交易报告（识别后 5 个工作日内上报）。

跨境交易报告（跨境支付超 1000 美元的）。

实名信息（KYC 数据）。

银保监会 / 网联报送。

支付机构客户备付金日报。

商户备案信息。

风险事件报告。

公安部门报送。

涉嫌欺诈、洗钱、违法的交易和用户。

报送规范。

报文格式严格按央行规范，错一个字段都会被退回。

报送时效有要求（如 T+1 上午 11 点前）。

报送方式多为专线 + 加密报文，不能走公网。

每次报送有回执，超时未回执要重试。

测试要点：

报文生成正确性。每个字段按规范填写，特别是日期格式、币种代码、机构代码这类强类型字段。

报送时效。模拟报送延迟、报送失败的重试机制；报送通道故障时的告警。

报送可追溯。每次报送的报文、回执、处理记录都要长期保留（10 年以上），支持监管检查。

报送数据完整性。按报送规则筛选数据，不能漏报（漏报有罚款）、不能错报（错报有罚款）、不能多报（增加合规成本）。

日志合规：

操作日志。所有用户操作（登录、查询、下单、修改）必须有日志，记录时间、操作人、操作内容、IP、设备。

审计日志。后台运营操作（封号、退款、修改配置）记录详细日志，支持事后追溯。审计日志一般要"不可篡改"（写入后只读、定期备份到异地）。

敏感数据脱敏。日志里的银行卡号、手机号、身份证号、地址必须脱敏（如 6228 **** **** 1234）。要测各处日志输出（业务日志、监控、告警、数据看板）都做了脱敏。

日志留存。一般 6 个月到 10 年（按数据类型，金融交易日志 10 年）。

日志查询权限。生产日志不能开放给所有开发，要有权限审批和审计。

测试方法：

报文格式校验。写脚本按监管规范的 XSD / JSON Schema 校验每天报送的报文。

业务关联校验。报送数据要和业务系统数据一致，按相同规则筛选后对比。

权限测试。日志查询接口的权限校验，未授权访问应被拒。

合规审计模拟。定期模拟监管检查，把所有需要追溯的数据导出，看能不能在时限内（一般 24 小时）响应。

监管合规是支付测试的"专业护城河"，很多 0~3 年测试同学很难理解这些场景的重要性，资深同学就是靠在这块沉淀经验拿到竞争力。

Q18: 支付系统的容灾、切流和异地多活怎么测？

答案：

支付系统的可用性要求极高，一般 SLA 是 99.99%（年故障时间 < 53 分钟）甚至 99.999%（< 5 分钟）。一次故障的影响巨大：用户支付不了 = 商户没生意 = 平台没流水。

容灾架构层级。

单机房高可用。同城多机房（一般 3 个机房），单机房故障流量自动切到其他机房。多数业务起步阶段就要做到。

同城双活 / 多活。两个或多个机房同时承担流量，单机房故障切流后服务能继续。

异地多活。北京、上海、深圳等地多个机房，跨地理位置，应对地震、断电等区域性故障。蚂蚁、京东、字节都在做。

测试维度：

机房故障演练。模拟一个机房整体宕机（拔网线、关电），观察：

流量切到其他机房的时延（一般 < 30 秒）；

用户的影响（理想是无感，实际可能是一次"重试"）；

正在进行中的交易（应自动重试或转移）；

故障期间的告警和定位流程；

恢复后回切的平滑性。

数据库主备切换。主库宕机后从库提升为主，观察：

切换时延（一般 < 1 分钟）；

切换期间的写入失败处理（应有重试或缓存）；

数据一致性（不能丢已确认的事务）。

跨机房延迟。异地多活下跨机房调用有几十毫秒延迟，业务必须能容忍。要测延迟敏感的接口（支付下单）是否在限度内。

数据双写一致性。多活方案下数据可能多机房双写或主从复制，要测各机房读到的数据一致性。

切流演练。

无害切流：把读流量从机房 A 切到机房 B，但写还在 A，观察机房 B 的服务能力。

完整切流：把所有流量切到机房 B，观察机房 B 单独能否扛住。

回切演练：把流量切回 A，验证回切流程正确。

降级演练。每个核心功能要有降级开关，预案演练时人工开启每个开关，验证业务可接受。比如风控服务挂了不能阻塞支付，要有"风控降级"模式（放过低风险交易）。

混沌工程。借助 Chaos Mesh / ChaosBlade 定期注入故障：网络延迟、网络丢包、CPU 满载、磁盘 IO 慢、进程挂掉、节点离线。观察系统反应是否符合预期。

值班响应。每次故障演练同时测试值班人员的响应：是否收到告警、是否及时响应、是否能在 SLA 内恢复、是否有完整复盘文档。

实际生产中的最佳实践是"演练即生产"：每月一次小规模演练（单服务、单机房），每季度一次大规模演练（整机房、跨地域），每年一次极限演练（突发场景、极端流量）。测试团队要参与所有演练并出具评估报告。

支付系统的稳定性是产品口碑的根基，资深支付测试同学的核心价值之一就是把"稳定性"作为质量主线持续推进。