如何设计微信发红包功能的测试用例？｜字节跳动测开面经解析

60 秒回答模板

可以按业务状态机设计用例：用户填写金额、个数和祝福语，选择支付方式，支付成功后红包生成并进入可领取状态；接收方领取后金额分配、余额入账、领取记录更新；到期未领完要退回；所有环节要有通知、账单和审计。功能用例覆盖单聊红包、群红包、普通红包、拼手气红包、金额和个数边界、支付取消、支付失败、余额不足、密码错误、重复提交、领取成功、已抢完、自己领取限制和消息展示。风险用例重点覆盖多人同时抢最后一个红包、支付回调重复或乱序、客户端重试、服务端幂等、金额精度、退款失败、风控拦截、账号异常和对账差异。红包涉及资金，测试不能只看界面，还要核对账户流水、红包状态、领取明细、退款单和通知一致性。

考点 资金一致性

难度 真实面经高频题

回答目标 讲清机制、边界和追问

深入解析

业务模型拆解

先明确红包类型、参与角色和状态。常见角色有发送方、接收方、群成员、支付渠道和账务系统；状态包括草稿、待支付、支付中、已发送、领取中、已抢完、已过期、退款中和已退款。用状态机组织用例，能避免漏掉中间态和异常态。

创建与支付

创建阶段要覆盖金额、个数、留言、红包类型、支付方式和限额规则。边界包括 0 元、超过余额、超过单笔限额、金额小数精度、群人数小于红包个数、敏感词、重复点击和页面返回。支付阶段要覆盖成功、取消、失败、密码错误、渠道超时和扣款后回调丢失。

领取与并发

领取阶段要覆盖首次领取、重复领取、红包已抢完、红包过期、发送者领取限制、被踢出群后领取、账号冻结和网络重试。群红包最关键的是并发抢同一个余额池，尤其是最后一个红包，必须验证不会超发、不会负数、不会重复入账，金额总和严格等于发送金额。

退款与对账

未领取金额到期后应按规则退回发送方。测试要覆盖全部未领、部分未领、退款失败重试、退款通知、账单记录、余额变更和支付渠道对账。资金系统要以流水为准，界面状态、消息状态和账务状态必须能相互核对。

安全与体验

红包功能容易被薅羊毛和攻击，需覆盖登录态、支付密码、设备风险、频控、金额篡改、重放请求、接口越权、抓包改参数和批量领取脚本。体验侧要覆盖消息通知、动画反馈、领取详情、失败文案、多端同步、弱网加载和客服可追踪的错误码。

易错点

只列创建和领取的正常流程，忽略支付失败、回调异常、过期退款和账务对账。
没有设计并发抢红包用例，导致超发、重复入账或最后一个红包分配错误无法发现。
只看客户端金额展示，不核对支付流水、账户余额、红包明细和退款记录。
忽略安全风控，把金额、个数、领取资格和群关系都默认相信客户端传参。

面试官追问

多人同时抢最后一个红包怎么测？

用并发请求压测同一个红包余额池，重点检查成功人数、领取金额总和、红包剩余金额、账户流水和幂等记录。预期是只有合法名额成功，不能超发、负数或重复入账。

支付成功但回调重复或乱序怎么办？

服务端应以支付单号和红包单号做幂等处理，重复回调不能重复生成红包或重复扣款。乱序时要按可验证的支付状态推进，异常状态进入补偿或人工可追踪流程。

红包过期退款要覆盖哪些点？

要覆盖全部未领、部分未领、退款成功、退款失败重试、通知发送、账单展示、余额恢复、领取入口关闭和到期任务重复执行。退款金额必须等于未领取金额。

如何防止客户端篡改金额或个数？

客户端参数只能作为请求输入，服务端必须重新校验金额、个数、限额、群关系、支付状态和签名。支付金额、红包总额和领取明细要由服务端可信数据计算。