抖音点赞功能如何设计测试用例，并在弱网、重试和状态一致性下验证结果？｜字节跳动测开面经解析

60 秒回答模板

我会先把点赞看成一个有状态的交互，而不是一个按钮。基础用例覆盖未点赞到已点赞、已点赞到取消点赞、连续点击、刷新后状态保持、切换视频后状态保持、登录/未登录、被删除或不可见视频、点赞数展示和个人喜欢列表更新。重点场景是弱网和重试：在高延迟、丢包、断网、请求超时、请求成功但响应丢失、恢复网络后重放、连续快速点击等情况下，客户端可以有乐观展示，但最终必须和服务端状态一致，不能出现点赞数重复增加、按钮状态反复跳、取消后又恢复点赞等问题。验证时我会同时看 UI、接口响应、服务端查询结果、埋点日志和跨页面状态；如果没有服务端直查条件，也要通过刷新、重登、换端或拉取列表验证最终一致性。弱网可以用系统网络调试工具、代理工具、移动端网络模拟、服务端 mock 或自动化框架注入延迟和失败来构造。指标上关注点赞成功率、失败回滚率、重复请求率、最终一致性错误率、弱网下 p95 响应时间、用户重试率和错误提示曝光。用例设计的重点是证明点赞在异常链路下可恢复、可解释、可观测，而不是只证明正常点击能变色。

考点 状态机思维

难度 真实面经题

回答目标 讲清设计、取舍和边界

深入解析

先抽象点赞状态机

点赞至少包含未点赞、点赞中、已点赞、取消中、失败回滚等状态。客户端可能为了体验做乐观更新，但乐观状态不等于最终状态。测试时要明确每次点击后本地 UI、请求状态、服务端状态、计数和列表归属分别应该是什么。

基础功能覆盖主路径和边界

主路径包括点击点赞、取消点赞、刷新保持、切换页面保持、点赞数变化和喜欢列表更新。边界包括未登录点赞、视频下架、作者拉黑或权限变化、重复进入同一视频、不同入口展示同一视频、长时间停留后再操作等。基础用例要先证明功能语义正确。

弱网场景要覆盖请求生命周期

弱网不是简单把网速调慢。需要模拟高延迟、低带宽、丢包、断网、DNS 或连接失败、请求超时、响应丢失、请求成功但客户端重试、网络恢复后批量发送等情况。每种情况都要观察按钮状态、计数、错误提示、重试策略和最终状态。

幂等和乱序是点赞测试重点

用户可能在弱网下连续点击点赞和取消，多个请求可能乱序返回。测试目标不是要求每个中间状态都稳定，而是保证最终意图和服务端结果一致，且计数不能重复增加或减少。可以通过快速连点、延迟首个响应、打乱响应顺序和重复发送同一操作来验证。

一致性要跨入口验证

点赞状态通常会在信息流卡片、视频详情、作者页、个人喜欢列表、推荐刷新后的同一视频和可能的多端登录中出现。测试不能只看当前按钮变色，还要通过刷新、重新拉取、切换账号或换设备验证最终状态，避免局部缓存和服务端事实不一致。

落地要有自动化和观测闭环

弱网用例适合沉淀为自动化和专项回归：构造网络 profile、记录请求、截图或录屏、查询最终状态、校验埋点。线上还要监控点赞失败率、重试率、重复请求率、状态回滚率、弱网投诉和接口错误码分布，便于定位是客户端、网络还是服务端问题。

易错点

只写点击按钮变色、点赞数加一，没有拆状态机和最终一致性。
把弱网等同于网速慢，漏掉超时、断网、响应丢失、乱序和恢复网络后的重放。
没有验证重复点击和重试导致的幂等问题，容易漏掉点赞数重复变化。
只在当前页面看结果，不刷新、不换入口、不验证个人喜欢列表或多端最终状态。
默认客户端展示就是服务端成功，没有区分乐观更新、失败回滚和最终提交。
臆造具体内部接口字段、队列或存储实现，而不是从可观察结果设计测试。

面试官追问

弱网下客户端是否应该先把按钮变成已点赞？

可以做乐观更新，但必须有明确的失败回滚和最终校验策略。测试时要验证请求失败、超时、响应丢失和恢复网络后，UI 不会长期停留在错误状态。

如何验证点赞接口的幂等性？

从黑盒角度可以重复发送同一操作、快速连点、让响应超时后重试，再检查最终点赞状态和计数是否只变化一次。不要假设内部幂等键，只验证对外结果是否满足幂等语义。

点赞数和按钮状态不一致时怎么定位？

先区分是本地缓存、接口响应、服务端最终状态还是列表刷新问题。可以抓请求、刷新页面、重新登录、换入口查看同一视频，并对照埋点和错误码缩小范围。

未登录用户点赞怎么测？

要验证登录引导、登录后是否延续原操作、取消登录后的状态、重复点击登录入口和登录态过期。重点是不能在未授权状态下误展示已成功，也不能丢失用户明确的操作意图。

弱网测试如何沉淀到自动化？

可以固定网络 profile，脚本执行点赞、取消、连点和刷新，再收集请求日志与最终状态断言。自动化应覆盖稳定的关键路径，把复杂随机网络留给专项测试或混沌测试。