抖音上下滑动视频流如何设计测试用例，覆盖加载、预取、播放状态、手势和弱网？｜字节跳动测开面经解析

60 秒回答模板

我会把上下滑动视频流拆成 feed 数据、视频资源、播放器、手势交互和性能稳定性几层。基础用例先验证进入页面首条视频能加载并播放，上滑加载下一条、下滑回到上一条，当前视频播放、非当前视频暂停或释放，标题、点赞等附属信息和视频内容不串位。加载层要测分页、预取、缓存命中、视频失效和无更多内容；播放层要测首帧时间、缓冲、seek、声音、暂停恢复和前后台切换；手势层要测滑动阈值、快速连续滑动、半滑回弹、反向滑动和误触；弱网层要测 2G/3G/高延迟/丢包/断网恢复下的 loading、重试、降级和提示。断言不能只看肉眼，要采集当前 itemId、播放器事件、currentTime、buffer、首帧耗时、卡顿次数、内存、流量和曝光日志，确认播放状态和业务统计一致。

考点 状态唯一

难度 真实面经题

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

深入解析

先拆信息流主链路

主链路包括首屏请求、列表分页、视频地址获取、预取、播放器绑定 item、滑动切换、当前播放和旧视频暂停。测试要确认内容、封面、标题、作者和交互状态不会在复用 cell 或快速滑动时串位。

加载和预取要有边界

验证首页冷启动、缓存命中、下一条预取、分页加载、无更多内容、接口失败、视频地址过期和资源失效。预取要提升首帧速度，但不能无限占用流量、磁盘和内存，也不能预取错误 item。

播放状态必须唯一且可观测

每次切换后应断言当前视频进入播放，上一条暂停或释放，同一时间不应有多个声音或多个播放器活跃。观测点包括 play/pause/waiting/error 事件、currentTime、buffered、音量状态、首帧时间和卡顿次数。

手势和滚动状态要细测

上下滑动要覆盖短滑、长滑、快速连滑、半屏回弹、反向滑动、边界页、横向误触和与点赞评论等手势冲突。断言当前 index、动画完成状态、播放器绑定和曝光触发时机一致。

弱网和中断决定体验

在高延迟、低带宽、丢包、断网恢复和网络切换下，要验证 loading 时长、重试、降级清晰度、错误提示、继续滑动能力和恢复后的播放位置。不能让页面卡死、黑屏或无限转圈。

性能和统计一起回归

短视频 feed 容易出现内存增长、解码压力、耗电、流量异常和曝光错报。回归要记录首帧 P95、卡顿率、崩溃、内存峰值、播放器实例数、预取命中率、曝光和播放完成事件，确保体验和数据都正确。

易错点

把题目写成普通视频播放测试，忽略上下滑动信息流的 cell 复用和状态切换。
只测能不能播放，不测旧视频暂停、声音串播和播放器资源释放。
预取只看速度收益，不看流量、内存、磁盘和错误资源污染。
没有覆盖快速连滑、半滑回弹、反向滑动和手势冲突。
弱网测试只看断网提示，不看重试、降级、继续滑动和恢复后的状态。
忽略曝光、播放进度和完播等业务日志，导致体验正确但数据错误。

面试官追问

如何验证滑走的视频已经停止播放？

除了肉眼听声音，还要检查播放器 pause/release 事件、当前活跃播放器实例数、音频焦点、currentTime 是否停止推进，以及旧 item 是否不再上报播放进度。

预取策略怎么测试是否合理？

看预取命中率、首帧时间、额外流量、缓存占用和错误资源比例。构造快速滑动、反向滑动、弱网和视频失效场景，验证预取不会污染当前播放或耗尽资源。

快速连续上滑最容易出什么问题？

容易出现播放器绑定错 item、上一条声音未停、曝光错报、请求乱序覆盖、缓存未释放和短时间内内存飙升。需要用 itemId 和播放器事件串起来断言。

弱网下是否应该阻止用户继续滑动？

通常不应让用户卡死在当前视频。可以允许继续滑动并展示明确加载或错误状态，同时重试或降级资源。测试要以产品契约为准验证可恢复性。

曝光日志什么时候算触发？

应按业务定义，例如视频进入可见区域并停留达到阈值或首帧展示后触发。测试要避免快速滑过也记曝光，或播放了却漏记曝光。