直播与短视频系统测试面试题

本文档包含 18 道直播与短视频系统方向的高频面试题，覆盖业务模型与全链路架构、推流、CDN 分发、播放与首屏、卡顿与画质、ABR 自适应、互动玩法（弹幕/点赞/礼物/连麦）、电商直播带货、内容审核、弱网与跨地区、海量并发观看、应急降级。直播与短视频是国内互联网最大的"流量入口"业务（抖音、快手、视频号、B 站、小红书都属此类），面试时常追问到链路细节，准备时建议结合自己经历过的产品对号入座。

一、业务模型与推流（4题）

Q1: 直播和短视频系统的架构差异在哪里？

答案：

很多同学把直播和短视频混为一谈，其实两者在工程层面差异巨大，测试关注点也很不一样。

直播是「实时流」。主播实时推流到源站，源站做实时转码再分发到 CDN，观众端拉流播放。所有内容必须在秒级（标准延迟 3~5 秒，低延迟 1~3 秒，超低延迟 < 500ms）送达观众，链路上每一跳都是"火上烤"。互动也是实时的，弹幕、礼物、点赞、连麦都要秒级响应。

短视频是「离线流」。创作者上传到对象存储，后端慢慢转码、生成多档分辨率和封面、过审、入库，最后通过推荐系统投递到 Feed 流。播放是按需触发的，CDN 缓存命中率高，整体压力远小于直播。

测试关注点差异：

直播重点测：推流稳定性、实时转码质量、低延迟、CDN 边缘节点切换、连麦互动、海量并发观看。

短视频重点测：上传体验（断点续传、HDR）、转码正确性（封面、分辨率档位、字幕）、推荐分发（CTR、播放完成率）、播放体验（预加载、码率自适应）。

也有混合场景。直播录制后可以作为短视频回放（一场带货直播切片成 5 分钟短视频），混合链路里要测"直播 → 切片 → 转码 → 短视频"的端到端流程。

Q2: 直播推流测试怎么做？

答案：

推流是直播链路的源头，推流不稳所有下游都白搭。推流端有三类：专业推流（OBS Studio、vMix）、移动端推流（APP 内置 SDK）、网页推流（WebRTC）。

主流推流协议：

RTMP。最经典，Adobe 2002 年发布，基于 TCP，延迟 3~5 秒。现在仍是绝大多数推流场景的事实标准。

SRT（Secure Reliable Transport）。基于 UDP，丢包恢复强，适合跨国推流和长距离传输，延迟可以做到 1~2 秒。

QUIC。基于 UDP，HTTP/3 底层协议，新一代推流方案。

WebRTC。浏览器原生支持，延迟最低（< 500ms），但服务端实现复杂，多用于连麦、互动直播。

推流测试维度：

推流稳定性。长时间（4~8 小时）连续推流不掉线、不卡顿、不变形。要模拟弱网（Charles 注入丢包延迟）、网络切换（WiFi 切 4G）、推流端进程切到后台、电量低、热噪过高（手机推流时常见）。

码率与画质。同一画面在不同码率下的清晰度、码率自适应（推流端根据网络情况降码率）、目标码率与实际码率的偏差。

音视频同步。音频和视频时间戳要对齐，常见 Bug 是音画不同步（一般要求 < 100ms）。

多档分辨率。专业推流支持同时推多档（1080p、720p、480p），要测各档画质和码率符合预期。

异常恢复。推流过程中网络突然断开后能自动重连、断开期间观众端是否有合理提示、恢复后画面能否平滑接续。

延迟测量。在主播端显示一个高精度时钟（如毫秒级），观众端拍主播屏幕，对比时间戳差，得到端到端延迟。生产中要持续监控延迟分布。

资源占用。推流时主播端的 CPU、内存、电量、流量消耗，移动端尤其关键（开播 1 小时不能把手机干烫了）。

测试工具上常用 OBS（PC 推流）、字节自研推流压测工具、Charles（弱网模拟）、ffmpeg（推流命令行）。线上要建立"推流质量看板"，按主播粒度看码率、延迟、卡顿率。

Q3: 直播 CDN 分发怎么测？

答案：

直播的 CDN 跟普通静态资源 CDN 不同，是「流式分发 CDN」，每个边缘节点都要做实时切流、协议转换、码率适配。测试时要把这条链路当独立系统看。

工作机制。主播推流到源站，源站经过转码生成多档码率，分发到上一级 CDN 节点，再分发到边缘节点。观众请求 CDN 时，CDN 根据地理位置、网络运营商、节点负载选择最优节点，建立长连接。

测试维度：

跨地区分发。同一场直播在北京、深圳、新疆、海外（东南亚、欧洲）观众端的延迟、首屏、卡顿率。地理位置越远延迟越大，跨国可能差 1~2 秒。要建一组"地理覆盖测试集"，覆盖国内五大区 + 海外热门地区。

多运营商支持。电信、联通、移动、广电观众端的访问质量。CDN 通常按运营商做路由，要测节点选择是否正确。

节点切换。当某个边缘节点故障或负载满时，CDN 应自动切到备用节点。要测切换时长、切换过程中是否丢帧、观众端是否感知。

协议适配。不同观众端用不同协议拉流：

HLS（M3U8 + TS）。兼容性最好，几乎所有平台支持，但延迟大（10~30 秒）。

FLV（HTTP-FLV）。延迟中等（3~5 秒），主流直播平台标配。

RTMP。延迟和 FLV 类似，但需要专门播放器。

WebRTC。延迟最低（< 1 秒），但服务端实现复杂。

LL-HLS（Low-Latency HLS）。HLS 的低延迟改进版，能做到 3 秒以内。

每种协议都要测端到端流程、错误恢复、缓冲策略。

回源测试。当 CDN 没有缓存（如直播刚开播）时，要回源到源站拉流。要测回源链路稳定性、回源后第一次拉流的耗时、回源失败的兜底。

容量与压测。模拟海量观众同时拉流，测 CDN 是否扛得住、节点是否会过载、过载后是否平滑降级。

成本指标。CDN 按流量计费，测试要关注流量数据是否精准（计费数据 vs 实际下行流量），结算口径不能错。

实际项目里直播 CDN 都是和第三方厂商（阿里云、腾讯云、字节云、火山引擎）合作的，测试经常要和厂商联调测，建立标准接口和监控规范是测试同学的必修课。

Q4: 直播延迟和首屏秒开怎么测？

答案：

直播延迟和首屏是观众感知最直接的两个指标，国内大厂的目标是「首屏 < 1 秒、延迟 < 3 秒」。

延迟分类：

端到端延迟。主播说话到观众听到的总时长。理想 < 3 秒（标准）、< 1 秒（低延迟）、< 500ms（超低延迟，连麦场景）。

互动延迟。观众发弹幕到主播屏幕显示的时长。理想 < 1 秒。

首屏。观众点击直播间到看到画面的时长。理想 < 1 秒，差的体验 > 3 秒就会流失大量用户。

测延迟的方法：

主播端展示时钟。主播屏幕显示精确到毫秒的时间戳（用网页或专门软件），观众端拍一张照对比，差值就是端到端延迟。这是最简单也最直观的方法。

打点埋点。SDK 层面在关键节点（推流时间、CDN 接收时间、播放器解码时间）打时间戳，端到端追踪。

线上巡检。CDN 厂商和自研监控都会上报延迟分布（P50、P95、P99），建立大盘持续监控。

延迟优化方向：

减少协议层延迟。HLS → FLV → RTMP → WebRTC，越下面延迟越低。

减少缓冲区。播放器的缓冲区设小（但太小会导致卡顿）。

GOP 优化。直播视频用 1~2 秒 GOP（关键帧间隔），太大首屏慢、太小压缩率低。

切流路径。让观众尽可能就近接入边缘节点。

首屏测试维度：

冷启动首屏。第一次打开直播间到出画面，最慢的场景。包括 DNS 解析、TCP 建连、TLS 握手、首段视频下载、解码渲染。每一步都要计时优化。

热启动首屏。从一个直播间切换到另一个直播间。这种场景常见于 Feed 流场景（抖音直播间无限滑动）。

预加载首屏。在 Feed 流里提前加载下一个直播间的部分数据，用户切到时秒开。这是抖音、快手的核心优化点，要测预加载策略的命中率和资源占用。

P95、P99 才是真用户感知。平均首屏 800ms 看着不错，但 P95 4 秒就是 5% 用户体验极差。要看分位数而不是平均值。

测试工具上 Chrome DevTools 的 Performance Tab、安卓的 SysTrace、Charles 的瀑布图都常用。线上要按地区、运营商、终端拆维度看首屏分布。

二、播放质量与体验（5题）

Q5: 卡顿率、首帧、流畅度这些指标怎么测？

答案：

直播和短视频的质量指标体系比较成熟，每个指标都有标准定义和测试方法，面试时能准确说出来体现专业度。

卡顿率（Buffering Ratio）。观看过程中出现卡顿（视频暂停加载）的频率和时长。计算公式：

卡顿率 = 卡顿总时长 / 观看总时长。生产环境一般要求 < 0.5%。

卡顿次数 = 一次播放中卡顿的次数。每分钟 < 1 次。

测试方法：

弱网模拟。Charles 注入不同丢包率（5%、10%、30%）和带宽限制（100kbps、500kbps），观察卡顿率变化。

跨地区测试。模拟海外、跨运营商、地铁等弱网常见场景。

长时间观看。连续观看 1~2 小时，统计累计卡顿。

首帧时间（First Frame Time，FFT）。从用户进入直播间到第一帧渲染出来的时长。目标 P50 < 500ms、P95 < 1 秒。包括：

DNS 解析。一般 < 50ms，但跨域和跨运营商可能 200ms。

TCP/TLS 建连。一般 100~300ms。

首段视频下载。取决于 GOP 大小和码率。

解码渲染。一般几十毫秒。

每一项都要单独测试和优化。

流畅度（Frame Rate）。视频播放的平均帧率，理想 = 视频源帧率（24fps、30fps、60fps）。低于源帧率意味着丢帧。

清晰度（Resolution）。实际播放分辨率，要和用户选择的档位一致。

音画同步（A/V Sync）。音频和视频时间戳差异，理想 < 50ms，差异 > 100ms 用户会感知到嘴型不对。

播放时长（Watch Time）。用户实际看的时长，是产品最关心的业务指标。

播放完成率（Completion Rate）。看完整个视频或观看 > N 分钟的比例。

退出率（Bounce Rate）。看 < N 秒就退出的比例，反映首屏质量。

测试上常用工具：

ExoPlayer / AVPlayer 的内置事件。各端播放器 SDK 都有完善的事件回调。

字节 ByteAudit / 阿里云 PCDN / 腾讯云直播质量监控。第三方提供的质量监控工具。

自建埋点 + 日志分析。把所有关键事件埋点上报，离线分析得各项指标。

线上要建大盘，按地区、运营商、终端、版本、时段拆维度看，发现异常立即告警。

Q6: 码率自适应（ABR）测试要点有哪些？

答案：

ABR（Adaptive Bitrate Streaming）是直播和短视频的核心技术，根据用户网络情况动态切换码率档位，保证流畅播放的同时尽量提升画质。

工作原理。服务端把同一份视频转码成多档码率（如 270p / 100kbps、480p / 500kbps、720p / 1500kbps、1080p / 3500kbps），播放器根据当前下行速度、缓冲区水位、丢帧情况，决定播放哪一档。

主流 ABR 算法：

基于带宽。简单粗暴，测当前下行速度选最合适的档位。问题是带宽波动大，频繁切档影响体验。

基于缓冲区。看播放器缓冲区水位，缓冲多就升档、缓冲少就降档。比基于带宽稳定。

混合算法（BOLA、MPC）。综合带宽、缓冲区、QoE 模型决策。主流流媒体平台都用这类算法。

机器学习算法。Pensieve 等基于强化学习的 ABR，效果显著但部署复杂。

测试维度：

档位切换正确性。模拟不同带宽和缓冲情况，断言算法选择的档位符合预期。

切换平滑性。从 480p 切到 720p 时，画面是否平滑过渡、有没有黑屏、卡顿。

切换频率。理想情况下频繁切换是不好的（来回切看着难受），算法应有"防抖"机制。

弱网降级。带宽极低时能否降到最低档继续播放，而不是卡死。

恢复升档。网络恢复后能否快速升回高清档位。

切换时序。播放器何时触发档位切换决策（每个分片下载完后？固定间隔？）。

测试方法上常用 Charles 的带宽限制能力，按时间动态调整带宽（如前 30 秒 3Mbps，中间 1Mbps，后面恢复 3Mbps），观察播放器档位变化轨迹。

实战中 ABR 调优是个长期工作，要建立 QoE 模型（综合清晰度、卡顿、切换的用户感知评分），用 A/B 实验持续优化。测试同学要参与 QoE 数据收集和 A/B 评估。

Q7: 直播延迟分几档？低延迟和超低延迟怎么实现和测？

答案：

直播延迟按目标值大致分三档，每档有不同的实现方案和适用场景。

标准延迟（3~10 秒）。最常见，多数普通直播（综艺直播、新闻直播）都用这一档。底层用 HLS 或 FLV 协议。

低延迟（1~3 秒）。带货直播、实时互动直播。底层用优化过的 HLS（LL-HLS）或 RTMP + 短 GOP。

超低延迟（< 500ms）。互动连麦、线上 KTV、电竞直播。底层用 WebRTC 或专门优化的 SRT、QUIC。

技术实现差异：

GOP 长度。标准延迟用 2~5 秒 GOP，低延迟用 1 秒，超低延迟用更短甚至无 GOP。

切片大小。HLS 标准切片 6 秒，LL-HLS 切到 200~500ms。

协议。WebRTC 基于 UDP，没有 TCP 重传带来的延迟。

CDN 优化。专门的低延迟节点，跳过中间的转码和缓存层。

测试维度：

延迟测量。用前面提到的"主播展示时钟 + 观众端拍照"方法，但要更精确（需要毫秒级时钟）。

互动场景延迟。连麦场景下双方说话的"乒乓"延迟，要测主播 A 说话 → 主播 B 听到的延迟。

弱网下的延迟。弱网下延迟会膨胀（重传、缓冲），要测各种网络情况下的延迟分布。

延迟稳定性。延迟在 1 小时直播过程中的波动，理想是稳定在目标值附近，不应频繁飙高。

跨地区延迟。北京主播给海外观众直播的端到端延迟。跨地理位置物理延迟是绕不开的，光速决定了从北京到欧洲至少 100ms。

测试场景设计：

带货直播。主播展示商品 → 用户秒杀 → 用户付款。整个链路要保证用户拍下时商品还在。如果延迟 10 秒，用户看到的"还有库存"实际已经卖完了，会引发投诉。

连麦 PK。两个主播实时连麦互动，延迟必须 < 500ms 才有真实感。要测各种音视频同步、回声、噪声、网络丢包恢复场景。

电竞直播。游戏主播的画面和实际操作要尽量同步，否则观众会觉得"主播怎么这么菜"。

实战中超低延迟的成本远高于标准延迟（CDN 节点要更多、转码资源要更猛、WebRTC 服务端实现复杂），所以业务上要明确"哪些场景值得低延迟"，不是越低越好。测试同学要参与延迟档位的产品决策，避免无脑追求低延迟。

Q8: 直播录制、回放和剪辑功能怎么测？

答案：

直播录制是直播的"副产品"，要把实时流转成可点播的视频文件，用于回放、剪辑、合规存档。这条链路虽然不是直播主链路，但出问题会影响内容资产。

录制方式：

服务端录制。直播 CDN 或源站把流持久化成 MP4 / FLV，上传到 OSS。这是主流方式，可靠性高。

主播端本地录制。用 OBS 等工具同时本地录一份，用作备份。

观众端录制（部分平台支持）。一般不允许，因为涉及版权。

录制测试维度：

录制完整性。一场 4 小时的直播录制下来要完整、不丢段。要测推流断网重连场景下录制是否会"碎片化"。

时间轴对齐。录制视频的时间轴和实际直播时间对齐，方便后续切片和检索。

录制延迟。从直播结束到回放文件可用的时长，要尽量短（一般 < 5 分钟）。

存储与清理。录制视频按业务规则保留（如 7 天、30 天、永久），到期自动清理。

回放测试：

回放体验。回放和直播 UI 一致，能拖进度条、倍速播放、跳过等。

弹幕回放。直播时的弹幕能否同步回放（弹幕也是按时间轴存储的，要和视频时间轴对齐）。

互动回放（不能回放）。礼物、连麦的互动数据通常不会回放（因为已经结束），UI 要正确处理。

回放跨设备同步。用户在 A 设备看到 50% 关掉，B 设备打开能继续看（依赖账号同步播放进度）。

剪辑功能测试：

切片准确性。指定起止时间切出来的视频，时间精度（一般要求秒级）。

转码后清晰度。切片后转码档位（多数平台只保留中等清晰度，省存储）。

水印与版权。切片后是否加平台水印、版权标识。

二次分发。切片后能否分享、再投流到推荐池、和原直播间关联。

剪辑权限。仅主播本人或获得授权的用户能剪辑、剪辑后能否分享到外部（短视频、私信）。

合规与审计：

录制存档。某些类型直播（金融、医疗、监管要求）必须长期存档（10 年以上），按合规要求测。

内容审核。录制后是否再次过审（直播时已经过审，但有些违规可能漏过、回放时被举报），要走二次审核流程。

实战中"切片+短视频"是直播间运营的重要手段，一场带货直播能切出几十个短视频，反复投流到 Feed。测试时要把这条链路当成"创作者上传短视频"的子集来测，但比上传链路多一道"切片"的工序。

Q9: 短视频上传、转码和封面生成怎么测？

答案：

短视频上传是创作者最直接的入口，每一步都可能影响发布成功率。整条链路 = 客户端编辑/压缩 → 上传到 OSS → 转码（多档 + 封面 + 字幕） → 入库 → 过审 → 入推荐池。

上传测试维度：

文件格式。主流支持 MP4、MOV、AVI、MKV 等，要测格式白名单和不支持格式的友好提示。

文件大小。一般限制几百 MB ~ 几 GB，超过上限提示，分片上传支持大文件。

分辨率与码率。源视频分辨率（4K、1080p、720p、竖屏 1080×1920、横屏 1920×1080），码率上限和下限。

时长。短视频一般限制几秒~ 几分钟（抖音 60 秒、B 站 10 分钟），跨平台限制不同。

上传体验。

断点续传。上传 50% 网络断了，恢复后能接着传，不要重头开始。

并发上传。同时传多个视频，互不影响。

后台上传。退到后台或锁屏时上传继续，APP 后台被杀时能否恢复。

弱网上传。低带宽和不稳定网络下的上传速度、超时重试。

进度反馈。上传进度条准确、上传失败的错误码和提示明确。

转码测试维度：

多档生成。一个原视频转出多档分辨率（如 4K → 1080p → 720p → 480p → 360p），每档画质正常、码率符合预期。

封面生成。

自动封面。从视频里抽取关键帧作为封面（一般取第一帧或人脸帧）。要测各类视频（人物、风景、动画、黑屏开场）的封面合理性。

用户上传。用户上传自定义封面，要支持图片格式、压缩、尺寸适配。

封面合规。封面图也要过审，不能涉黄涉政。

字幕生成。

自动字幕。用 ASR 把视频里的语音转成字幕，要测准确率、时间轴对齐、多语言支持。

字幕样式。字号、颜色、位置、背景框，要符合产品规范。

封面之外的元信息。

视频时长。转码后时长和原视频一致（多数情况下，剪切除外）。

视频标签。从视频内容识别标签（如美食、宠物、舞蹈），用作推荐特征。

人脸识别。识别视频里的人物，用于推荐和审核。

转码时效。从上传成功到转码完成可见，目标 < 1 分钟（短视频），最慢不应超过 5 分钟。要测高峰期（春晚后大量上传）转码队列是否会堆积。

异常路径：

转码失败。源视频损坏、格式不支持、内容不合规等导致转码失败，要有明确错误码和重试机制。

转码中删除。用户在转码过程中删除视频，已生成的资源要清理。

存储失败。OSS 故障时上传失败的兜底，是否能切换备用存储。

性能与成本：

转码资源消耗。转码是 CPU/GPU 密集型任务，要测转码集群的吞吐量、资源利用率、成本。

CDN 预热。新视频入推荐池前要预热到 CDN，避免被推荐时回源拉垮。

短视频上传链路是创作者体验的核心，测试同学要在产品上线前打磨好，发布失败率是 KPI，建议建立"发布漏斗"看板（上传 → 转码 → 过审 → 发布 → 推荐分发）。

三、互动、商业化与推荐（5题）

Q10: 弹幕、点赞、礼物、连麦怎么测？

答案：

直播互动是直播的核心商业化和氛围承载，每种互动都有自己的协议和测试要点。

弹幕测试。

可靠性。发出去的弹幕主播和其他观众应都能看到，但允许少量丢弃（高并发下不可能 100% 送达）。

延迟。从发送到主播屏幕显示 < 1 秒，普通观众端 < 2 秒。

顺序。多数情况下不要求严格顺序，但主播屏幕上不应"插队"显示。

去重。同一用户高频发同一弹幕（刷屏）应限频或合并。

审核。弹幕内容要走敏感词过滤，违规内容拦截。

样式。普通弹幕、彩色弹幕（付费）、置顶弹幕（管理员）、表情弹幕，各种类型 UI 都要测。

点赞测试。

聚合策略。海量点赞不需要每个点赞都精准上报，可以本地聚合后批量上报（如每秒上报一次）。

数字一致性。所有观众看到的点赞数应大致一致，差异 < 几秒。

动效流畅。点赞动效（飞心、烟花）在主播端和观众端都要流畅，不能因为点赞多卡掉。

防刷。机器刷点赞（脚本快速点击）应被识别并限制。

礼物测试。

支付链路。点击礼物 → 支付（用余额或第三方）→ 服务端确认 → 通知主播。整条链路要幂等、可靠。

特效。不同价位礼物有不同特效（小礼物只是飘过、大礼物全屏动画），要测各类特效正确显示。

排行榜。礼物贡献榜、土豪榜实时更新。

退款。礼物送错了能否退款（多数平台不支持，但要测策略）。

主播分成。礼物按比例分给主播，分成结算要准确。

特殊礼物。如盲盒礼物（随机开出价值）、活动礼物（限时限量）。

连麦测试。

申请与接受。观众申请连麦、主播接受/拒绝、连麦中断开。

音视频质量。连麦双方的音视频延迟、回声消除、噪声抑制、码率自适应。

多人连麦。3 人以上同时连麦的混流（多个画面合成一个画面再分发给观众）、布局切换。

权限。仅主播能接受连麦、能踢出连麦者。

异常恢复。连麦过程中一方网络中断，能否自动恢复或被踢出连麦。

互动服务的核心挑战是"海量并发下的实时性"，万人直播间一秒钟可能有几千条弹幕、几万次点赞、几百份礼物，互动服务的压测和故障演练是测试重点。

Q11: 直播间高并发互动场景怎么测？

答案：

直播间高并发是直播测试的"硬核"场景，万人甚至百万人同时在线时，互动数据可能达到每秒几万次操作，对互动服务、IM 服务、存储都是极限挑战。

典型高并发场景：

晚会/大型活动直播。100 万 ~ 1000 万同时在线，央视春晚级别。

明星直播首播。50 万 ~ 200 万同时在线，瞬时高峰。

带货大主播开播。10 万 ~ 50 万同时在线，要持续几小时。

赛事直播。5 万 ~ 50 万同时在线，关键节点（进球、决胜）瞬时互动暴增。

压测维度：

观众入场。10 万观众同时进入直播间，加入聊天室、订阅弹幕、加载礼物列表、获取主播信息。测进入耗时和成功率。

弹幕风暴。开播第一分钟可能有几万条弹幕涌入（"老板好""新主播加油"），测弹幕服务的入队、过审、分发能力。

点赞瀑布。万人同时点赞，测客户端聚合策略、服务端处理能力。

抽奖/秒杀。直播间限量抽奖（一辆车、一台手机），瞬间几十万用户参与，测请求堆积、排队、库存原子性。

礼物风暴。当主播完成挑战或某关键节点，几千用户同时送礼物，测支付链路并发能力。

下播退场。直播结束后所有观众一起退场，测退订阅、清理资源能否快速完成。

压测工具：

JMeter / Gatling。HTTP 接口压测。

自研 IM 压测工具。模拟海量长连接、订阅、消息收发。

云上压测平台。阿里云 PTS、腾讯云 WeTest、字节火山引擎等提供大规模分布式压测。

压测策略：

阶梯压测。逐步加压（1k → 10k → 100k → 1m），观察各阶段瓶颈。

混合场景压测。同时跑入场、弹幕、点赞、礼物，模拟真实直播间。

故障注入压测。压测过程中关掉一个节点、断开机房网络，观察影响。

长时间压测。维持 50% 目标并发 4~8 小时，看资源泄漏、内存膨胀。

监控维度：

服务端：CPU、内存、GC、QPS、RT、错误率、消息队列堆积。

客户端：APP 响应、消息处理速度、UI 渲染卡顿、电量消耗。

链路：CDN 边缘节点负载、回源压力、网络带宽。

实战中大型直播前一般会做 3~5 轮全链路压测，每轮目标递增。最后一轮要打到 1.5 倍预期峰值，留出冗余应对突发。

Q12: 直播带货和电商联动怎么测？

答案：

直播带货是国内电商最大的创新场景，把直播流量直接转化为电商订单。这条链路融合了直播 + 电商 + 支付，复杂度极高。

业务流程：主播展示商品 → 用户点购物车 → 用户下单 → 支付 → 主播看到下单数据 → 直播间显示销售排行。

测试关注点：

商品挂载。主播开播前挂载商品到购物车，要测挂载数量上限、商品状态（上架 vs 下架）、活动价 vs 日常价的切换、限时限量商品。

实时讲解切换。主播讲到 A 商品时把 A 商品置顶到购物车第一位，用户看到的购物车顺序要和主播讲解同步。

秒杀场景。主播喊"3、2、1，上链接"，瞬间几万人下单同款商品。测试要点和普通秒杀类似，但因为有"延迟"问题（用户看到的画面比实际慢 3~5 秒），秒杀开始时间要按"用户感知时间"对齐而不是真实服务端时间。这是直播带货特有难题。

订单延迟与库存。延迟导致用户看到"还有库存"实际已经卖完，下单失败要给出友好提示，并尽量减少"看着还有但点下去说没了"的体验。

价格一致性。主播讲解的价格 = 商品详情页价格 = 下单页价格 = 支付价格。任何一处不一致都是资损或投诉。

优惠券。直播专享券（仅在直播间能领），要测领取限制、使用限制、库存。

库存共享。直播间库存和店铺总库存的关系，是独立隔离还是共享。

订单归因。下单订单要标记"来源直播间"，用于主播分成结算。要测归因准确性、跨设备归因（用户在 PC 端看直播，到手机下单，能否归因到直播间）。

主播工具。主播端的"小黄车"（购物车管理）、实时销售看板、订单数据导出。

售后联动。在直播间买的商品退款时，是否扣回主播的分成、是否影响主播的口碑分。

监管合规。

广告法。主播话术合规（不能说"绝对""最好""国家级"等禁用词），有声音转文字识别。

价格法。承诺的低价必须实际兑现，承诺补差价的要兑现。

商品资质。三品一械（食品、保健食品、特殊食品、化妆品、医疗器械）有专门资质要求。

消费者权益保护。售后政策（七天无理由）必须支持。

实战中直播带货最常见的事故是"商品讲错链接""价格设置错误""库存不足跑路"。测试要把这些场景都做成自动化用例，开播前自检。

Q13: 推荐系统和短视频投流怎么测？

答案：

短视频的核心竞争力是推荐系统，把对的视频推给对的人。推荐系统的测试是一门专门学问，跟传统功能测试差异很大。

推荐系统组成：

召回。从亿级视频库里选出几千个候选（按用户兴趣、行为相似度、热门度）。

粗排。从几千个候选选出几百个，用轻量模型快速打分。

精排。用复杂模型对几百个候选精排，输出几十个。

重排。最后阶段做多样性、去重、商业化调权（广告插入）等。

测试维度：

召回正确性。给定一个用户画像，召回出来的候选视频应符合兴趣特征。要建一组"标准用户画像"（如喜欢宠物、喜欢美食），测召回是否合理。

排序质量。CTR（点击率）、播放完成率、停留时长、互动率、留存率，这些是 KPI 但很难单元测，更多靠 A/B 实验评估。

多样性。同一个用户连续刷 50 个视频，不应全是同一类内容。要测重复率、品类覆盖。

冷启动。新用户没有历史数据时，推什么、推几条、补充哪类内容做兴趣探测。

新视频投流。刚上传的视频要"投流"到一批种子用户看看反响，要测投流逻辑（投给谁、投多少、何时停止）。

实时调权。直播带货、突发事件、明星新闻这些场景需要紧急加权某些内容到推荐池，要测调权生效时间、影响范围、可回滚性。

降级与兜底。推荐系统挂了要降级到热门榜单或编辑精选，不能空白页面。

A/B 实验测试：

实验配置。能正确为不同用户分流到不同实验组、配置生效后多久能看到效果。

指标计算。实验组 vs 对照组的指标计算准确、统计显著性正确。

实验隔离。多个实验同时跑互不干扰，能精确归因效果。

实验回滚。发现实验组指标下降能快速回滚。

数据指标：

线下指标。AUC、NDCG、Recall@K 等推荐算法学术指标，模型上线前用。

线上指标。CTR、Watch Time、Like Rate、Comment Rate、Share Rate、Follow Rate、Next Day Retention。

业务指标。DAU、月活、用户时长、广告收入、留存曲线。

测试方法：

人工审核。建立"金标准"测试集（人工标注的优质用户画像 + 期望推荐），定期跑回归。

自动化 A/B 实验。把每次模型变更都做 A/B 实验，统计学显著后才上全量。

线上巡检。监控推荐结果的多样性、品类分布、敏感内容比例，异常时告警。

推荐系统测试是数据驱动的，需要算法、产品、测试同学密切配合。测试同学的核心价值是搭建评估体系和保证 A/B 实验的可信度。

Q14: 主播管理后台怎么测？违规识别和封禁机制呢？

答案：

主播管理是直播平台的"治理"环节，要平衡内容质量、平台收益、监管合规。测试主要在主播认证、违规识别、处罚、申诉这几条链路。

主播认证测试：

实名认证。身份证号、人脸识别、绑定手机，三要素核验。要测各种异常（身份证读不出、人脸不匹配、手机已绑定他人账号）。

资质认证。

主播资质（无业务限制类直播）。

带货资质（食品、保健品、化妆品等需要相关资质和店铺授权）。

特殊行业资质（医生直播要有执业医师证、律师直播要有律师证）。

不同资质对应不同直播分类的权限。

公会/MCN 绑定。主播加入公会后分成按公会规则、退出时的清算。

违规识别测试：

实时识别。

视频识别。识别画面中的违规内容（涉政、涉黄、涉暴、低俗），实时阻断或降权。

音频识别。把语音转文字（ASR），识别违规话术。

弹幕识别。识别用户发的违规弹幕，自动屏蔽并连坐惩罚发布者。

历史回查。

直播录制后再次过审，发现违规可追溯处罚。

定期审计抽查（每周 10% 直播流随机审），保证合规率。

举报机制。

用户举报。任意观众都能举报，举报达到阈值或被人审认定违规则触发处罚。

测试举报流程：举报通道是否畅通、举报理由分类是否合理、处理时效（一般 24 小时内）。

处罚机制测试：

处罚梯度。

警告（短信通知主播，无实际影响）。

降权（直播间不进推荐池）。

限播（一段时间不能开播，如 7 天）。

封禁（永久或长期不能开播）。

资金冻结（违规期间的礼物收入冻结，严重违规没收）。

每种处罚都要测：触发条件、生效时间、申诉路径、解除条件。

申诉流程。

主播能在管理后台发起申诉，提交说明和证据。

平台运营审核，48 小时内反馈结果。

申诉成功后处罚撤销，相关资产解冻。

监管联动。

公安系统联动。涉嫌违法的直播要上报公安，主播信息备查。

广电系统联动。涉政直播按要求停播、备案。

监管报送。月度、季度合规报告，按地区监管要求报送。

后台功能测试：

数据看板。主播的开播次数、时长、观看人数、收入、违规次数等关键数据。

财务结算。礼物收入计算、平台抽成、税费扣除、提现申请。

合同管理。主播签约、续约、解约的电子合同流程。

权限管理。运营同学的角色和权限分级，越权操作要拒绝并审计。

主播管理后台是平台运营的核心工具，测试同学要把它当作正经业务系统对待，覆盖权限、审计、数据准确性、并发安全等维度。

四、内容安全与稳定性（4题）

Q15: 直播内容审核怎么测？

答案：

直播内容审核是平台合规的生命线，国内监管对直播平台要求极严，任何一次违规事故都可能导致整站下架。审核能力是测试同学的重点保障对象。

审核策略：

事前审核。开播前的资质审核、直播预告内容审核、商品上架审核。

实时审核（直播中）。

机器审核（机审）。AI 模型每秒抽几帧分析，识别涉黄、涉政、违法、暴力。机审是主力，覆盖率 99%+。

人工审核（人审）。机审标记可疑的内容进人审队列，人工二次判断。

抽样人审。即使机审通过也按一定比例抽样人审，防止机审漏过。

事后审核。直播结束后录制视频再次过审，违规可追溯处罚。

测试维度：

机审准确率。

真阳率（违规内容被识别）。要建立各类违规样本库（涉黄、涉政、暴力、违法），定期跑回归看真阳率。

误判率（正常内容被错判）。同样建立白样本库（合规直播切片），测误判率，过高就是骚扰用户。

机审延迟。从直播流到识别结果的时长，目标 < 5 秒。延迟太大违规内容已经播出去了。

机审覆盖率。

抽帧策略。多少帧抽一次（一般每秒 1~5 帧），关键场景（如开播前 5 分钟）抽更密。

不同类型识别。视频、音频、文本、Logo、屏幕共享内容、连麦对方画面，全部要覆盖。

人审流程。

人审队列的优先级（高粉丝主播优先、敏感时段优先）。

人审决策延迟（一般要求 < 1 分钟内做出判断）。

人审一致性（同一内容多人审核的判断一致性，体现审核标准的明确性）。

阻断与处罚。

实时阻断。机审或人审判定违规后切断直播流的时长（一般 < 2 秒，越快越好）。

处罚联动。阻断后自动触发警告、限播、封禁，处罚级别和违规严重度匹配。

申诉路径。主播认为误判可申诉，48 小时内反馈结果。

监管报送。

违规事件按要求报送给监管部门（一般 T+1）。

监管检查时的数据可追溯（录制、审核日志、处罚记录、申诉记录全部留存）。

测试方法：

红蓝对抗。专门组织"红队"找违规漏洞（用各种规避手段尝试），蓝队改进规则。每月一次，持续提升识别能力。

线上巡检。每天扫描所有审核日志，统计准确率、覆盖率、延迟分布，告警异常。

合规演练。模拟监管突击检查，把所有审核数据导出，看能不能在监管要求的 24 小时内响应。

内容审核是测试同学最容易出彩的领域之一，把审核能力做扎实可以避免平台级事故。

Q16: 直播弱网和跨地区观看怎么测？

答案：

直播观众分布广，从一线城市的 5G 用户到农村的 4G 老旧网络，再到海外用户（东南亚、欧美），每种网络环境下的体验都要保证。

测试维度：

弱网档位定义。建立标准弱网测试集：

3G。低带宽（200kbps）、高延迟（200ms+）。

弱 4G。中带宽（500kbps~1Mbps）、波动大、丢包 5~10%。

地铁/电梯。频繁切换基站、临时断网（10~30 秒）。

跨运营商。电信、联通、移动用户访问的差异。

弱网下的体验：

首屏。弱网下首屏一般会变长（2~5 秒），要给用户合理的"加载中"动画。

卡顿。弱网下卡顿率会升高，要测自动降码率是否生效、降到最低档后是否还能流畅播放。

ABR 切档。弱网下自动切到低清，恢复后切回高清。

互动延迟。弱网下弹幕、点赞、礼物的延迟会变大，要测延迟边界（10 秒？30 秒？多久放弃）。

退出与重连。弱网导致断流，再连接的成功率、重连时长、重连后的播放接续。

跨地区观看：

国内分区。建立北上广深、新疆、西藏、海南等地的"代表节点"测试环境，每次大版本发布跑一遍这些地区的播放体验。

国际/海外。

东南亚（印尼、马来、泰国、越南）。中国直播平台出海重点市场。

港澳台。地理近但运营商不同，要专门测。

欧美。延迟最大、跨国带宽贵。

中东、非洲。基础设施差，对低带宽适配要求高。

跨地区测试要点：

延迟。跨地区物理延迟是绕不开的（光速限制），北京 → 美西大概 150ms 起步。要测各地区延迟分布。

CDN 节点选择。CDN 应自动给用户选最优节点，不应跨大洲拉流。要验证节点路由策略。

合规要求。

数据本地化（GDPR、东南亚 PDP）。

内容差异化（不同国家文化、宗教、政治敏感不同）。

货币和支付（礼物充值要按当地货币和支付方式）。

语言与时区。

界面国际化（i18n），多语言显示正确。

时区显示（直播开播时间按用户本地时区显示）。

弹幕中的多语言。

测试工具：

Charles + Network Conditioner。模拟各类弱网。

VPN / 真实跨地区机器。验证真实地理位置的访问质量。

第三方测速服务（Speedtest API、字节内部 NetInfo）。监控真实用户网络情况。

线上灰度。新功能先在小地区灰度，没问题再全量。

实战中海外测试是直播出海的关键短板，建议建立"海外真实设备实验室"，每个目标国家有 2~3 台真机持续监控。

Q17: 直播间海量观众怎么压测？

答案：

直播间的并发挑战和普通业务不同，重点不在 QPS 而在「同时长连接 + 实时消息扇出 + 视频流并发」。压测要把这三块都打到极限。

压测目标：

晚会级别。100 万 ~ 1000 万同时在线，4~6 小时持续。

大型 IP 直播。50 万 ~ 200 万同时在线。

普通带货直播。1 万 ~ 50 万同时在线。

压测维度：

长连接维持。压测客户端建立 N 个长连接并维持几小时，测服务端是否能稳定承载、心跳是否正常、资源不泄漏。

订阅与扇出。每个连接订阅同一直播间的消息，主播或某些用户发消息时扇出到所有连接，测扇出 QPS 和延迟。

互动行为模拟。按真实直播间的行为分布（如 1% 用户每分钟发 1 条弹幕、5% 用户点赞、0.1% 用户送礼物），模拟海量用户行为。

视频流并发。每个客户端实际拉一份流，对 CDN 边缘节点压力很大。要测 CDN 节点的连接数上限、回源压力、节点切换。

进入退出。模拟用户陆续进入和退出（开播时陆续涨、结束时一起退），测峰值前后的资源动态调整。

混合场景。同时打互动 + 视频 + 进入退出，模拟最真实的直播间。

压测注意事项：

机器规模。模拟 100 万并发需要 1000~10000 台机器（每台模拟 100~1000 个客户端，受 CPU、内存、网络限制），云上压测平台更适合。

流量真实。从压测发起方到目标系统的网络要模拟真实链路（经过 LB、网关、各层服务），不能直接打内部接口。

成本控制。视频流并发会消耗大量带宽，全量模拟成本极高。可以"模拟订阅但不拉流"或"少量真拉流 + 大量信令模拟"组合。

故障注入。压测过程中注入各种故障（节点宕机、网络分区、依赖服务超时），看系统恢复能力。

线上预演。最理想是在线上做"灰度压测"（用真实流量比例放大），但风险高，多数大厂用"影子库 + 影子流量"模式。

监控大盘：

业务指标。在线人数、消息扇出 QPS、视频拉流 QPS、互动行为 QPS。

技术指标。各服务的 QPS / RT / Error / GC、Redis 命中率、MQ 堆积、CDN 节点负载、网络带宽。

资源水位。CPU / 内存 / 磁盘 / 句柄数 / 连接数。

异常告警。任何指标突破阈值立即告警，压测组随时观察。

实战中大型直播前一般有 3~5 次全链路压测演练，每次目标递增，最后一次打到 1.5~2 倍预期峰值。每次压测后出复盘报告，列出瓶颈和优化项，给开发团队整改。

Q18: 直播事故应急和降级演练怎么做？

答案：

直播 P0 事故（无法开播、大面积卡顿、内容审核漏过）影响极大，平台都会建立"应急 + 降级 + 演练"三位一体的稳定性体系。

应急响应机制：

值班制度。7×24 小时值班，按"业务方向 + 故障级别"分配值班同学。直播稳定性、互动服务、CDN 各有专人。

告警分级。P0 → P1 → P2 → P3，每级有不同响应时长（P0 一般要求 5 分钟内响应、30 分钟内恢复）。

应急 SOP。每类典型故障有详细操作流程，新人按 SOP 也能处理：

源站宕机：切到备用源站。

CDN 故障：切到备用 CDN 厂商。

互动服务挂掉：降级到"只看不互动"模式。

转码集群拥塞：临时下调主播开播数量、降低码率档位。

降级机制：

按功能降级。

核心功能（看直播）必须保住，其他功能可临时下线。

互动降级：弹幕、点赞、礼物可降级到"延迟显示"或"暂不可用"。

清晰度降级：高清/超清不可用时降到标清，标清不可用时音频流。

按用户降级。

VIP 用户优先保障。

新用户、长期不活跃用户优先降级。

地区降级（某地区故障时只影响该地区）。

按时段降级。

非黄金时段可主动降级一些功能以节省资源。

突发流量时优先保核心，逐步降级辅助功能。

降级开关测试：

开关粒度。开关应能精细到功能维度（如"礼物降级开关""弹幕降级开关""高清降级开关"）。

生效时间。开关切换后多久生效（理想是秒级），过慢容易错过事故窗口。

回滚能力。降级恢复后能否快速回到正常状态。

灰度切换。开关支持灰度（1% → 10% → 100%），避免全开关引发新问题。

权限审计。开关切换有权限校验和审计日志，谁切的、什么时候切的、为什么切的可追溯。

混沌工程演练（Chaos Engineering）：

工具。ChaosBlade、Chaos Mesh、Litmus，按场景注入故障。

故障类型。

网络故障（延迟、丢包、断网）。

资源故障（CPU 满载、内存耗尽、磁盘 IO 阻塞）。

服务故障（接口超时、错误率飙升、进程挂掉）。

依赖故障（数据库主库挂、Redis 集群故障、第三方支付不可用）。

演练频次。

日常演练。每周 1 次小规模，单服务、单环境。

季度演练。每季度 1 次大规模，跨服务、跨环境。

年度演练。每年 1 次"全员断网"或"机房整体宕机"演练。

演练复盘。每次演练后写复盘报告：

什么故障被注入了。

系统反应是否符合预期。

值班同学响应时长是否达标。

恢复操作是否正确。

发现哪些待改进点。

事故复盘文化：

每次真实事故必须复盘，输出复盘报告。

复盘不甩锅，重点是找根因、定改进项、跟进闭环。

复盘报告共享给团队（脱敏后），知识沉淀给新人。

定期复盘"复盘"，看历史事故的改进项是否真的落地。

测试同学在事故应急体系里的核心价值：

参与 SOP 设计。每类典型故障的处理流程要测试同学验证可执行性。

参与降级开关测试。每个降级开关都要有专门测试用例。

参与混沌演练。担任演练发起方或观察方，记录系统行为。

参与事故复盘。从测试视角分析"为什么测试没发现这个 Bug"，反推测试体系改进。

稳定性是产品口碑的根基，资深的直播测试同学最大的价值就是把"稳定性"做成可量化、可演练、可改进的工程体系。