RTC 实时音视频系统测试面试题

本文档包含 18 道 RTC 实时音视频（Real-Time Communication）方向的高频面试题，覆盖 WebRTC 协议栈与信令、NAT 穿透、拓扑选型（P2P / SFU / MCU）、编解码、端到端延迟、3A 算法、弱网对抗、混流与画面布局、1v1 / 多人会议 / 屏幕共享 / 美颜虚拟背景 / 直播连麦等典型场景、海量并发压测、跨地区跨国测试、QoS 监控与故障演练。RTC 是音视频通讯（Zoom、腾讯会议、飞书会议、声网、即构、Twilio）的核心方向，是测试岗位里专业门槛极高的细分领域。

一、RTC 基础与协议（4题）

Q1: RTC 跟传统直播的本质差异在哪里？

答案：

很多人把"实时音视频"和"直播"混在一起，工程上两者差异巨大，测试关注点完全不同。

核心差异维度：

延迟。

RTC：< 500ms（理想 < 200ms）。

直播：3~10 秒（标准）、< 1 秒（低延迟直播）。

双向 vs 单向。

RTC：所有参与方都既发又收，多对多。

直播：主播发、观众收，单向。

缓冲策略。

RTC：不能缓冲（缓冲就是延迟），丢包就丢，宁可丢帧不卡顿。

直播：可缓冲（缓冲提高稳定性），可重传，宁可卡顿不丢帧。

传输协议。

RTC：基于 UDP（WebRTC、SRT、RTMP-over-UDP），追求低延迟。

直播：基于 TCP（HLS、HTTP-FLV、RTMP-over-TCP），追求可靠。

并发模型。

RTC：单房间几人到几百人，但每对都有独立的低延迟通道。

直播：单直播间几万到几百万人，所有人接收同一份流。

应用场景。

RTC：1v1 视频通话、多人会议、连麦互动、教育课堂、医疗远程会诊。

直播：综艺、新闻、带货、游戏直播、晚会。

测试关注点差异：

RTC 重点测：端到端延迟、双向交互体验、回声噪声、弱网对抗、并发会议数。

直播重点测：首屏秒开、卡顿率、CDN 分发、海量观众承载、推流稳定性（详见直播章节 27）。

混合场景。直播连麦是 RTC + 直播的混合：连麦双方走 RTC（低延迟），普通观众走直播 CDN（标准延迟）。要测两套链路的协同。

RTC 测试是个专业方向，往往需要专门的实验室设备和测试工具，测试同学要逐步积累音视频领域的知识。

Q2: WebRTC 信令、媒体协议（SDP、ICE、SRTP）怎么测？

答案：

WebRTC 是 RTC 领域的事实标准，理解它的协议栈是测试的基础。WebRTC 不是一个单一协议，而是一组协议的集合。

WebRTC 协议栈：

信令层。SDP（Session Description Protocol）描述媒体能力，但 WebRTC 不规定信令传输协议，可以用 WebSocket、HTTP、自定义信令。

连接层。ICE（Interactive Connectivity Establishment）打洞建立连接，STUN / TURN 辅助。

传输层。

媒体：SRTP（Secure RTP）加密后的 RTP，跑在 UDP 上。

数据：SCTP over DTLS，跑在 UDP 上。

媒体层。音频（Opus）、视频（VP8、VP9、H.264、AV1）编解码。

SDP（Session Description Protocol）：

描述会话的"能力清单"：支持的编解码、媒体类型、加密参数、ICE 候选地址。

通信前双方交换 SDP（offer / answer 模式）协商。

测试关注：

SDP 解析正确（各字段按 RFC 4566）。

跨实现兼容（Chrome / Firefox / Safari / 自研客户端的 SDP 差异）。

编解码协商（双方都支持的编解码才能通信）。

媒体方向（sendrecv / sendonly / recvonly / inactive）。

ICE（Interactive Connectivity Establishment）：

打洞建立 P2P 连接的协议，按优先级尝试：

Host 候选。本地 IP 直连。

Server Reflexive。通过 STUN 服务器发现自己的公网 IP。

Relayed。通过 TURN 服务器中转。

ICE 测试关注：

各种 NAT 类型下的打洞成功率（详见 Q3）。

ICE 候选收集时长（一般 < 5 秒）。

候选优先级（优先用 Host、再用 Reflexive、最后用 Relayed）。

ICE 重启（网络切换后重新打洞）。

SRTP / DTLS：

SRTP 加密 RTP 包，保护媒体数据。

DTLS（基于 UDP 的 TLS）协商 SRTP 的密钥。

测试关注：

加密正确（抓包看不到明文媒体）。

证书校验（伪造证书的中间人攻击被拒绝）。

密钥协商性能（DTLS 握手延迟）。

加密性能（CPU 占用）。

RTP / RTCP：

RTP 承载媒体数据，每个包有时间戳、序列号。

RTCP 反馈控制（接收质量报告、丢包重传请求、带宽估计）。

测试关注：

RTP 时间戳正确（用于音视频同步、抖动缓冲）。

序列号顺序（用于丢包检测、乱序重排）。

RTCP 反馈及时（影响带宽自适应）。

JitterBuffer 工作（详见 Q8）。

测试方法：

抓包分析。Wireshark + WebRTC 解码插件，看 SDP、ICE 候选、SRTP 包结构。

WebRTC Stats API。getStats() 返回详细的连接质量数据：

往返时延（RTT）。

丢包率。

抖动（Jitter）。

带宽估算。

编解码器实际使用。

互通测试。Chrome、Firefox、Safari、自研 SDK 互相通信的兼容性。

WebRTC 内部工具。chrome://webrtc-internals/ 详细展示每条连接的统计信息，是测试同学必备工具。

实战中 WebRTC 协议测试是底层活，多数应用层测试同学不需要深入到 SRTP 包级别，但要理解协议栈以便排查问题。

Q3: NAT 穿透和 TURN/STUN 服务器怎么测？

答案：

NAT（Network Address Translation）是互联网的现实：绝大多数用户在 NAT 后面（路由器、企业网关、运营商网络），两个 NAT 后的用户不能直接通信。RTC 必须解决 NAT 穿透。

NAT 类型（影响打洞成功率）：

全锥型（Full Cone）。最宽松，任何外部地址都能访问。已经罕见。

地址限制锥型（Address-Restricted Cone）。只接受我先访问过的目标的回包。

端口限制锥型（Port-Restricted Cone）。比地址限制更严，要求源 IP + 源端口都匹配。

对称型（Symmetric）。最严格，对不同目标用不同的外部端口，几乎打不了洞。

打洞成功率：

两个全锥型/地址限制锥型 NAT 之间：可以 P2P 直连。

一边对称型 + 一边任意：基本不能 P2P，必须中转。

实际生产中，约 70% 用户可以 P2P，30% 需要中转。

服务器角色：

STUN（Session Traversal Utilities for NAT）。

帮助客户端发现自己的公网 IP 和端口。

轻量，只发送和回应少量包。

成本极低，几乎所有 RTC 服务都自带。

TURN（Traversal Using Relays around NAT）。

当 P2P 打洞失败时，作为中转服务器转发所有媒体流。

资源消耗大（带宽、CPU），是 RTC 的主要成本。

通常按地理位置部署多个 TURN 节点。

测试维度：

打洞成功率。

模拟各种 NAT 组合，测打洞能否成功。

工具：客户端配置不同 NAT 类型（用路由器或虚拟网络），观察建连结果。

P2P vs Relay 比例。生产中健康比例约 60~80% P2P + 20~40% Relay。

ICE 候选收集。

各种网络环境下的候选种类（Host / Reflexive / Relayed）。

候选收集时长（一般 < 5 秒）。

候选优先级排序。

STUN 服务测试。

STUN 服务可用性（高 SLA）。

STUN 响应延迟（一般 < 100ms）。

STUN 服务地理分布（就近选择）。

TURN 服务测试。

TURN 服务可用性。

TURN 带宽承载（每个 TURN 节点能承载多少并发会话）。

TURN 流量按区域分流（北京用户走北京 TURN）。

TURN 凭据安全（短期凭据防滥用）。

跨地区。

国内打国内。

国内打海外。海外打国内。

不同运营商之间（电信 / 联通 / 移动）。

成本控制。

TURN 流量按时计费，要测流量统计准确。

按用户优先级分配 TURN 资源（VIP 用户优先）。

TURN 选择策略（按延迟、按容量、按成本）。

异常路径。

STUN 服务故障。降级到只用 Host 候选（可能完全连不上）。

TURN 服务故障。本路 P2P 失败的会话变成完全失败。

证书过期。STUN / TURN 服务的 SSL 证书续期。

NAT 类型变化。用户切换网络（WiFi → 4G）后 NAT 变化，要测 ICE 重启。

工具：

NAT 检测工具。比如 NatTypeTester、STUNclient。

WebRTC NAT Type Test。检测自己网络的 NAT 类型。

自家监控大盘。线上按地区、运营商统计 P2P vs Relay 比例、建连成功率。

实战中 NAT 穿透是 RTC 测试的"硬骨头"，特别是企业网络、医院、学校等限制网络下打洞难度高，要建立"网络环境实验室"持续测试。

Q4: RTC 拓扑结构（Mesh / SFU / MCU）选型和测试

答案：

多人 RTC 会议的核心架构问题是"谁来分发媒体流"，主流三种拓扑各有适用场景和测试关注点。

Mesh（全连接）：

工作原理。每个参与者和其他所有人都建立 P2P 连接，N 个人产生 N×(N-1) 条连接。

优点。

无服务器，零中间环节延迟。

服务端成本极低。

缺点。

带宽消耗大。N 人会议每人要发 N-1 路、收 N-1 路。4 人会议每人 6 路流。

客户端压力大（解码 N-1 路视频）。

不适合多人。

适用场景。1v1 通话、3~4 人小会议。

测试关注点。

P2P 打洞成功率（详见 Q3）。

客户端 CPU 占用（多路解码）。

带宽消耗（弱网下能否承受）。

SFU（Selective Forwarding Unit）：

工作原理。服务端只转发媒体包，不解码。每个客户端只往服务器发一路，收 N-1 路。

优点。

服务端简单（不解码），单机能承载大量会话。

客户端带宽不变（上行只 1 路）。

支持 Simulcast（同时发多档码率，服务器按订阅方网络情况选择）。

缺点。

下行依然要收 N-1 路（客户端解码压力）。

服务端有计算开销（路由、转发、码率自适应）。

适用场景。5~100 人会议（Zoom、腾讯会议、飞书会议都用 SFU）。

测试关注点。

SFU 单机并发能力（一般 1000~5000 路并发）。

SFU 跨地区部署（用户就近接入）。

Simulcast 切换（弱网下 SFU 给该用户发低码率流）。

订阅与取消订阅（用户只看部分参会者）。

MCU（Multipoint Control Unit）：

工作原理。服务端解码所有流，混合成一路（多个画面合成一个画面），再编码下发。

优点。

客户端简单（只收一路流，CPU 压力小）。

适合超大型会议（万人）和直播场景。

支持复杂的画面合成（如电视台多机位）。

缺点。

服务端 CPU 极高（解码 + 混合 + 编码）。

灵活性差（画面布局固定）。

延迟较高（解码 + 编码增加延迟）。

适用场景。直播连麦（连麦双方走 SFU/Mesh，观众走 MCU 混流后通过 CDN 分发）。

混合架构（生产常用）：

SFU + MCU 混合。会议参与者走 SFU、观看者走 MCU + CDN。

支持灵活的拓扑切换（小会议走 Mesh、中会议走 SFU、大会议走 MCU）。

测试要点：

各拓扑切换的平滑性。

混合架构下不同角色的延迟差异。

成本与体验的平衡（MCU 省客户端带宽但延迟高）。

选型与测试：

每种拓扑都要建立独立测试套件，覆盖：

不同人数（1v1、3 人、10 人、50 人、100 人、千人）。

不同带宽（高速 WiFi、4G、弱 4G、3G）。

不同设备（高端手机、中低端手机、桌面、车载等）。

不同网络（同机房、跨城市、跨国）。

实战中拓扑选型是个长期优化过程，结合用户分布、成本、体验综合决策。测试同学要能从指标分析架构瓶颈，给开发提供选型建议。

二、音视频质量（5题）

Q5: 音视频编解码（H.264/H.265/VP9/AV1/Opus）测试要点？

答案：

编解码是音视频质量的核心，选型决定清晰度、带宽、CPU 占用、延迟、兼容性。

主流视频编解码器：

主流音频编解码器：

测试维度：

兼容性。

编解码器跨平台兼容。iOS / Android / 桌面 / 浏览器各端都能编解码。

新老版本互通。新版客户端发的流老版能解、老版发的流新版能解。

硬解码 vs 软解码。

硬解码用 GPU，性能好但兼容性差（某些设备不支持某些编解码）。

软解码用 CPU，兼容性好但性能差。

测试两种解码方式都能正常工作，并能自动切换。

性能与质量。

不同码率档位（200kbps / 500kbps / 1Mbps / 3Mbps）的画质。

不同分辨率（180p / 360p / 720p / 1080p）的画质和 CPU 占用。

不同 fps（15 / 24 / 30 / 60）的流畅度。

不同设备的编解码能力差异。

质量评估。

PSNR（峰值信噪比）。客观指标，越高越好。

SSIM（结构相似度）。客观指标，越接近 1 越好。

MOS（Mean Opinion Score）。主观评分，1~5 分。

VMAF。Netflix 提出的综合评分，更接近主观感受。

编解码切换。

会议中能否切换编解码（一般不能，开始就定）。

带宽变化时切档（Simulcast 多档同时发，服务器选）。

弱网下的编解码选择（首选轻量编解码）。

特殊场景。

屏幕共享场景。屏幕共享内容（文字、PPT）和摄像头视频特征不同，要用专门优化的编解码模式。

低延迟模式。某些编解码（H.264 的 baseline profile、VP8）适合低延迟。

跨平台一致。同一参数在不同平台编码出的流，质量应基本一致。

工具。

VMAF 工具集。计算客观质量分。

FFmpeg。编解码测试和验证。

WebRTC Stats API。线上质量数据收集。

主观评分平台。组织真人评分。

实战中编解码选型涉及成本（专利费）、性能（硬解兼容性）、体验（清晰度）等多重权衡，测试同学要参与决策评估。

Q6: 端到端延迟（Mouth-to-Ear / Glass-to-Glass）怎么测？

答案：

延迟是 RTC 的核心 KPI，决定能否做"实时交互"。延迟测量是 RTC 测试的基本功。

延迟分类。

Mouth-to-Ear（音频）。说话方嘴巴说出声音到听方耳朵听到的总时长。

Glass-to-Glass（视频）。发送方摄像头采集到接收方屏幕显示的总时长。

延迟构成。

采集延迟。摄像头 / 麦克风采集到送给应用，一般 30~100ms。

编码延迟。编码器处理一帧的时间，10~30ms。

网络延迟。数据包从发送端到接收端，10~200ms（取决于距离）。

接收缓冲。JitterBuffer 缓冲一定数据避免抖动，10~100ms（详见 Q8）。

解码延迟。解码器处理一帧的时间，10~30ms。

渲染延迟。送到屏幕显示，10~50ms。

总计。一般 70~500ms（视场景）。

延迟目标。

1v1 通话。< 300ms（用户感觉"无延迟"）。

多人会议。< 500ms。

游戏 / 互动。< 200ms。

教学课堂。< 500ms。

直播连麦。< 1 秒。

测试方法：

主观法（最简单）。

发送方拍击桌子或拍手，接收方观察拍手画面 + 听到声音的延迟。

发送方屏幕显示精确时钟（毫秒级），接收方拍照对比时间戳。

客观法（精确）。

发送端和接收端都连接同一秒级时钟源（如 NTP 同步的服务器）。

发送端记录视频帧的时间戳。

接收端记录帧显示时的本地时钟。

两者相减得到 Glass-to-Glass 延迟。

专业设备。

声学测试盒。专门的硬件能精确测 Mouth-to-Ear 延迟（毫秒级）。

视频延迟测试仪。一些厂商有专业设备。

WebRTC 自带统计。

getStats() 的 googCurrentDelayMs（包括 JitterBuffer 延迟）。

googJitterBufferMs。

googRtt。

这些是估算值，不是真实端到端，但可以参考趋势。

延迟优化空间。

采集。固定采集帧率（避免动态采集带来的延迟）。

编码。低延迟编码模式（不用 B 帧，B 帧需要参考后续帧增加延迟）。

网络。

UDP（不是 TCP）。

低 RTT 路径（就近接入）。

减少中转跳数（直接 P2P 或就近 SFU）。

接收缓冲。

自适应缓冲（弱网时缓冲大，强网时小）。

低延迟模式（牺牲流畅度换低延迟）。

测试方法：

实验室测试。在受控环境下测各种网络条件下的延迟。

线上巡检。每天采样真实用户的延迟数据，按地区、设备、运营商分布看分布。

A/B 实验。新优化方案的延迟改进，A/B 评估。

跨场景测试。

国内同城。最理想，< 200ms 可达。

国内跨城。100~200ms。

跨国（国内 → 海外）。300ms ~ 1 秒。

跨大洲。500ms ~ 1.5 秒。

实战中延迟是 RTC 系统的硬指标，每减少 50ms 都是工程上的胜利，测试同学要建立"延迟看板"持续监控和优化。

Q7: 3A 算法（AEC / ANS / AGC）怎么测？

答案：

3A 算法是音频通讯的核心：AEC（回声消除）、ANS（噪声抑制）、AGC（自动增益控制）。没有 3A 就没有可用的语音通话。

AEC（Acoustic Echo Cancellation，回声消除）：

问题。A 通过扬声器播放 B 的声音 → A 的麦克风采集到 → 再发回 B → B 听到自己的声音回放（回声）。

原理。AEC 从麦克风采集中减去扬声器播放的声音。

测试维度：

回声残留。AEC 处理后还能听到的回声残留，理想是听不到。

近端语音保护。说话时不能因为消除回声把自己的声音也消除掉。

收敛速度。从开始通话到 AEC 充分发挥作用的时长（一般 1~3 秒）。

强干扰。环境嘈杂时 AEC 是否还有效。

双讲（Double Talk）。双方同时说话时 AEC 的表现（容易回声残留）。

延迟变化。手机扬声器和麦克风的延迟可能变化，AEC 要能适应。

ANS（Active Noise Suppression，噪声抑制）：

问题。环境噪声（空调声、风扇声、键盘声、交通噪声）影响通话质量。

原理。识别背景噪声，从音频中减去。AI 模型（如 RNNoise）效果更好。

测试维度：

噪声去除效果。

稳态噪声（空调声）。AI 模型容易处理。

非稳态噪声（键盘声、关门声、笑声）。难处理。

语音失真。降噪过度会让语音听起来"机械""空洞"，要测自然度。

不同语种的表现。AI 模型在训练集语种上效果好，其他语种可能差。

不同性别 / 年龄段。男声、女声、老人、小孩的语音保护。

AGC（Automatic Gain Control，自动增益控制）：

问题。不同人音量不同，距离麦克风远近不同，要把音量调到合适。

原理。自动调整增益，让小声变大、大声变小。

测试维度：

增益效果。各种音量下输出音量稳定。

响应速度。从开始说话到调整到位的时间。

防爆音。瞬间大声音（咳嗽、桌子拍击）要避免输出爆音。

防音量"喘息"。AGC 不能过于敏感，否则音量频繁变化让人不适。

综合测试方法：

POLQA / PESQ。客观音质评分工具，对比"原始信号 vs 处理后信号"打分。

MOS 评分。组织真人评分。

A/B 测试。不同 3A 算法对比，统计学评估。

场景化测试。

办公室通话（中等噪声）。

家中通话（电视、孩子噪声）。

户外通话（车流、风声）。

会议室通话（多个发言人）。

车载通话（路噪、引擎声）。

每种场景独立评估。

设备适配。

iOS。系统提供 VPIO 模式，可以用系统 3A。

Android。各厂商系统 3A 质量差异大，多数厂商需要自研 3A。

桌面。Mac / Windows 各有差异。

蓝牙耳机。蓝牙音频和有线音频差异，AEC 难度高。

实战中 3A 算法的优劣直接决定通话质量口碑，测试同学要把它当作 P0 级体验保障，建立"音质评测实验室"长期跟踪。

Q8: 弱网对抗（FEC / ARQ / JitterBuffer / 带宽估计）测试

答案：

弱网（丢包、延迟、抖动）是 RTC 系统的最大挑战。RTC 要在弱网下"宁可降质量也要不卡顿"，每种技术都有自己的测试要点。

弱网典型场景：

丢包。5%、10%、20%、30% 丢包率。

延迟。100ms、500ms、1s 网络延迟。

抖动。延迟不稳定（如 100ms ± 50ms）。

带宽限制。500kbps、200kbps、50kbps 带宽。

突发断网。1~10 秒短暂断网。

FEC（Forward Error Correction，前向纠错）：

原理。除了发送原始数据，还发送冗余数据（一般 +10%~50%）。接收方丢包后用冗余数据恢复原始数据。

优点。无需重传，低延迟。

缺点。冗余增加带宽消耗。

测试要点：

不同冗余比的恢复能力（10% 冗余能恢复 5% 丢包，50% 冗余能恢复 20% 丢包）。

突发丢包（连续多包丢失）的处理。

冗余开销对带宽的影响。

自适应 FEC（按实时丢包率调整冗余）。

ARQ（Automatic Repeat reQuest，自动重传）：

原理。接收方发现丢包后请求重传。

优点。带宽利用高（按需重传）。

缺点。增加延迟（一个 RTT 等重传）。

测试要点：

重传时机（多久没收到判定为丢，触发重传）。

重传次数上限（不能无限重传）。

重传请求的有效性（NACK 反馈机制）。

ARQ 在不同 RTT 下的表现（高 RTT 时 ARQ 延迟大）。

混合 FEC + ARQ。小丢包用 FEC、大丢包补 ARQ。

JitterBuffer：

原理。接收端缓冲一定时间的数据再播放，对抗网络抖动。

测试要点：

缓冲大小。太小抗抖动差、太大延迟大。

自适应。网络好时缓冲小，网络差时缓冲大。

切换平滑。缓冲大小变化时不应有"声音变速""音量跳跃"。

丢包补偿（PLC）。

带宽估计（BWE，Bandwidth Estimation）：

原理。根据网络反馈（丢包、延迟变化）估计当前可用带宽，动态调整码率。

算法。

GCC（Google Congestion Control）。WebRTC 默认。

NADA、SCReAM、BBR。其他算法。

测试要点：

估计准确性。估计的带宽和实际可用带宽的偏差。

响应速度。网络变化后多久能调整码率（一般几秒）。

平滑性。码率不应频繁大幅波动。

公平性。多个 RTC 流共享带宽时不应一方独占。

弱网测试方法：

模拟工具。

Linux tc。可注入丢包、延迟、抖动、带宽限制。

Network Link Conditioner（macOS）。

Charles（弱网模拟）。

字节自研 / 第三方 RTC 弱网测试工具。

真实弱网。

地铁、电梯、电梯里、跨国机房等真实弱网环境。

跨运营商。

弱网组合测试。

不同弱网档位（弱 3G、弱 4G、3G）。

不同丢包模式（随机丢、突发丢、单向丢）。

不同延迟（稳定延迟、抖动）。

体验评估。

主观：真人通话评分。

客观：MOS、PESQ、POLQA、VMAF。

实战中弱网测试是 RTC 系统的"看家本领"，国内厂商（声网、腾讯云、字节火山）的核心竞争力之一就是弱网下的体验。测试同学要建立完整的弱网测试体系，把"弱网下能用 vs 不能用"作为产品核心评价标准。

Q9: 多路混流与画面布局测试

答案：

多人会议、直播连麦、电视台多机位等场景需要把多路视频合成一路画面（混流），是 RTC 系统的复杂功能之一。

混流场景：

直播连麦。主播 + 连麦观众的画面合成一路给观众看。

多人会议。所有参会者画面合成一路（特别是 MCU 拓扑）。

监控墙。多个监控画面合成一个画面。

电视台多机位。多个机位画面合成播出。

合成方式：

服务端合成（MCU）。服务器解码所有流，按布局合成，再编码。

客户端合成。客户端拿到多路流自己合成显示，更灵活但占客户端 CPU。

布局类型：

平铺布局（Grid）。所有参会者等大小排列，常见于多人会议。

主次布局。一个大画面 + 几个小画面，常见于演讲场景。

画中画（PiP）。一个画面叠在另一个画面上。

自定义布局。按业务需要定制。

测试维度：

布局正确性。

按设置的布局正确合成（位置、大小、层级）。

布局参数（边距、间距、圆角、阴影）正确应用。

布局切换。

会议中切换布局的平滑性（不应黑屏、闪烁）。

切换响应时间（一般 < 1 秒）。

动态参与者。

人加入会议时布局自动调整（如 4 人变 5 人）。

人离开时布局自动调整。

主讲人切换（主次布局下主画面切换）。

音视频同步。

合成后的画面和声音同步。

不同流的时间戳差异处理。

清晰度。

合成后的整体清晰度（不应低于源流）。

合成时的缩放质量（不应模糊）。

性能。

服务端 MCU 的 CPU 占用（合成是 CPU 密集型）。

客户端合成的 CPU 占用。

延迟（合成增加的延迟）。

特殊场景。

发言人识别。说话的人画面高亮或放大。

静音状态。麦克风关闭的人显示静音图标。

视频关闭。摄像头关闭的人显示头像或占位图。

屏幕共享 + 摄像头。共享屏幕时摄像头怎么显示。

录制混流。录制时合成的画面用于回放。

跨平台。

不同端（PC、移动、Web、TV）显示的布局一致。

不同分辨率屏幕的适配。

横屏 / 竖屏切换。

水印与商业化。

合成时加 Logo / 水印。

广告插入。

直播间的礼物特效合成。

监控墙的时间戳、机位标签。

测试方法：

视觉验收。人工对照设计稿验证布局准确。

自动化截图。在不同场景下自动截图，和预期对比。

性能测试。压测多路混流下的服务端 CPU、内存、带宽。

主观评分。组织真人评分合成画面的体验。

实战中混流是 RTC 系统的"门面"功能，特别是直播连麦场景，混流质量直接影响观众观看体验。测试同学要把它当作"产品级"功能保障。

三、典型场景测试（5题）

Q10: 1v1 视频通话测试要点

答案：

1v1 视频通话是 RTC 最经典场景，看似简单实际涉及大量细节（拨号、振铃、接听、通话、挂断），每个都有自己的测试关注点。

测试维度：

拨号流程。

拨号成功。被叫方在线且接听。

拨号失败。被叫方不在线、忙线中、拒接、超时未接（一般 30~60 秒）。

主叫取消。拨号中主叫挂断，被叫不应振铃。

被叫不在线时的通知方式（推送、短信、离线消息）。

振铃。

声音和振动。

UI 显示主叫信息（姓名、头像、来电时间）。

锁屏场景下的来电界面。

来电时被叫已在另一个通话中（呼叫等待）。

来电时被叫正在使用其他 RTC 应用。

接听。

接听响应时间（点击接听到通话建立 < 1 秒）。

接听后摄像头和麦克风权限申请。

接听后立即可以看到对方画面。

被叫接听后主叫等待时长。

通话中。

音视频流畅（详见 Q5、Q6）。

弱网体验（详见 Q8）。

切换前置 / 后置摄像头。

静音 / 取消静音。

关闭 / 打开视频（变成纯语音）。

切换扬声器 / 听筒 / 蓝牙耳机。

通话中切换网络（WiFi → 4G）。

通话中接受其他来电（呼叫等待）。

通话中接听后切换或挂断。

挂断。

挂断响应时间。

挂断后双方 UI 状态正确。

挂断后通话时长统计准确。

挂断后通话记录入库。

特殊场景。

接听后转视频通话（升级）。

通话中切换音视频（降级）。

通话中静音保持。

后台通话。APP 切到后台后通话继续。

锁屏通话。锁屏后通话继续，息屏。

熄屏。视频通话时屏幕息灯节能。

通话录制。征得双方同意后录制。

紧急切断。某方网络断开 30 秒后自动挂断。

异常路径。

通话过程中一方 APP 崩溃。

通话过程中一方设备死机或断电。

通话过程中切到飞行模式。

通话过程中切换通讯软件。

通话过程中收到系统通知（如银行短信）。

通话过程中接听传统电话。

测试方法。

真机对测。两台真机两个测试同学对测。

自动化对测。两台设备各自跑自动化脚本。

端到端模拟。模拟拨号、信令、媒体流、挂断的完整流程。

1v1 通话是用户感知最强的功能之一，每个细节都关系到用户体验。测试同学要把"通话能否打通、通话质量、通话稳定"作为基础保障。

Q11: 多人会议测试（参会者管理、发言权、举手）

答案：

多人会议（Zoom、腾讯会议、飞书会议、谷歌 Meet）是 RTC 应用最复杂的场景之一，涉及大量管理功能。

参会者管理：

入会方式。

会议号 + 密码。

会议链接。

日历邀请。

二维码扫描。

入会权限。

公开会议（所有人能进）。

密码保护。

等候室（主持人审批后才能进）。

仅企业内部成员。

参会者状态。

在线 / 离开 / 静音 / 关摄像头。

举手 / 鼓掌 / 喜爱等表情反馈。

发言中（高亮）。

主持人权限。

设置共同主持人。

静音 / 取消静音参会者。

关闭参会者摄像头。

允许 / 禁止参会者共享屏幕。

允许 / 禁止参会者改名。

踢出会议。

锁定会议（之后不允许新人进入）。

测试要点。

入会流程的各种入口（会议号、链接、邀请）。

入会前的设备测试（摄像头、麦克风测试）。

参会者列表实时更新。

主持人权限的生效（被静音的人麦克风立即关闭）。

权限变更的同步（如主持人退出后主持人权限转移）。

发言权管理：

自由发言（默认）。

所有人都能开麦克风发言。

适用于小会议。

举手发言。

普通模式：参会者举手，主持人手动开麦。

适用于研讨会、培训。

主持人控制。

主持人指定谁能发言。

适用于正式会议、面试。

测试要点。

举手列表实时更新。

主持人开麦后该参会者麦克风立即开启。

主持人关麦后该参会者麦克风立即关闭。

主持人下发"我要发言"权时参会者收到提示。

互动功能。

聊天。

群聊天（所有人可见）。

私聊（指定对象）。

主持人对所有人。

主持人对部分人。

文件传输。

文字反馈（举手、鼓掌、表情）。

投票 / 问卷。

抽奖。

笔记 / 会议纪要。

测试要点。

聊天消息实时性。

聊天历史在会议结束后可保存 / 查看。

文件传输的大小限制、安全性。

投票数据准确性、隐私（匿名投票）。

分组讨论（Breakout Rooms）：

会议中把参会者分成小组各自讨论，结束后回到主会议室。

测试要点。

分组创建（手动分组、随机分组、按属性分组）。

参会者进入子房间。

主持人巡视各子房间。

子房间内的独立 RTC（音视频独立、聊天独立）。

子房间结束后回到主会议室。

数据汇总（子房间的聊天、共享内容）。

录制。

主持人录制（云端 / 本地）。

参会者征得同意后录制。

录制完整性（所有发言、共享内容）。

录制的处理（剪辑、字幕、共享）。

无障碍。

实时字幕（语音转文字）。

手语翻译。

视障辅助（屏幕阅读器兼容）。

合规。

GDPR / 个保法合规（数据保留、用户授权）。

会议录制的合规告知（必须告知所有参会者）。

跨境会议的合规（数据出境）。

性能。

百人会议、千人会议的承载（详见 Q4 的拓扑选型）。

参会者列表的渲染性能。

聊天的实时性。

测试方法：

多端联调。10+ 台设备同时入会，覆盖各端各角色。

自动化测试。脚本自动入会、操作、退出。

混沌测试。会议过程中随机断开某些参会者，看会议是否还能继续。

多人会议是 RTC 应用的"皇冠功能"，测试同学要把它做成"百分百可靠"的标杆。

Q12: 屏幕共享和桌面共享测试

答案：

屏幕共享是 RTC 应用的核心功能之一，看似简单实际涉及大量细节（共享源选择、画质、延迟、互动）。

共享源类型：

整个屏幕。共享整个显示器内容。

应用窗口。仅共享某个应用（如只共享 PPT）。

浏览器标签页。仅共享某个网页。

特定区域。共享屏幕的某个矩形区域。

虚拟摄像头。把屏幕作为虚拟摄像头输入。

测试维度：

共享发起。

UI 弹窗选择共享源。

源缩略图清晰可见。

权限请求（macOS / Windows / Linux 需要授权）。

多显示器场景。

共享显示。

观众端看到清晰的共享内容。

文字、表格、PPT 清晰可读（不糊）。

动态内容（视频、动画）流畅。

光标、点击高亮显示。

延迟（一般 < 500ms）。

帧率。

静态内容（PPT）：低帧率（5~15fps）足够。

动态内容（视频）：高帧率（30fps）。

自适应帧率（识别内容类型，动态切换）。

清晰度。

不同分辨率显示器的适配。

观众端不同分辨率屏幕的缩放。

清晰度档位（720p、1080p、原始）。

音频共享。

是否共享系统音频（如共享时播放视频）。

音视频同步。

系统音频不可用时的兜底（如有些 OS 不支持系统音频）。

互动。

观众端可以看到光标。

主讲人可以远程允许观众操作（远程协助）。

涂鸦（在共享内容上画线指出）。

虚拟笔（光标变成笔，可在屏幕上画）。

权限。

主持人允许 / 禁止参会者共享。

同时共享（多个参会者同时共享，各自独立显示）。

切换共享（主讲切换共享源）。

终止共享（主讲终止 / 主持人强制终止）。

特殊场景。

共享视频。系统音频 + 视频流畅播放。

共享白板软件（如 Whiteboard）。

共享游戏（高帧率 + 低延迟）。

共享移动端（手机投屏）。

跨平台。

PC 端（Mac / Windows / Linux）的共享。

移动端（iOS / Android）的屏幕广播。

Web 端（浏览器内共享）。

智能电视、车机的共享。

性能。

主讲端 CPU 占用（屏幕捕获 + 编码）。

观众端 CPU 占用（解码 + 渲染）。

带宽消耗。

弱网下的体验（自动降清晰度、降帧率）。

异常处理。

主讲端断开连接，共享停止。

主讲端切到其他应用（共享内容是否暴露隐私）。

主讲端通知弹窗（如收到短信通知）出现在共享内容里（要测隐私保护）。

主讲端切换显示器。

合规与隐私。

共享前的"内容警告"（可能共享隐私内容）。

通知静默（共享时屏蔽通知）。

录屏检测（部分企业禁止共享时录屏）。

水印（共享内容加水印防外泄）。

实战中屏幕共享是企业会议的"刚需"，做不好直接影响用户体验。建议建立"共享场景库"覆盖各种内容类型，每次大版本发布跑一遍。

Q13: 美颜、滤镜和虚拟背景测试

答案：

美颜和虚拟背景是消费级 RTC 的"软实力"，特别是直播、视频通话场景。技术上是实时视频特效处理，对性能、效果、稳定性要求都高。

美颜功能：

基础美颜。

磨皮（去除皮肤瑕疵）。

美白。

红润。

锐化（让五官更清晰）。

进阶美颜。

瘦脸。

大眼。

瘦鼻。

调整下巴。

调整唇形。

调整发际线。

风格美颜。

可爱风、网红风、专业风等风格化套餐。

测试维度：

效果。

不同肤色、不同性别、不同年龄的美颜效果。

不同光照（强光、弱光、逆光）的表现。

调节滑杆生效（轻度、中度、重度美颜）。

性能。

帧率（开启美颜后是否仍达 30fps）。

CPU / GPU 占用。

电量消耗。

不同设备（高端 / 中端 / 低端）的兼容性。

稳定性。

长时间使用不内存泄漏。

切换不同美颜方案不崩溃。

低端设备的降级（自动关闭高级美颜）。

滤镜功能：

色调滤镜。

文艺、复古、冷色调、暖色调。

测试要点。

不同滤镜效果对比。

性能影响。

弱光场景下的表现。

特效贴纸：

虚拟物品。

帽子、眼镜、胡子、口罩。

跟随人脸位置和角度。

动物贴纸。

猫耳、狗鼻、兔耳。

动态特效。

下雨、下雪、爱心飘。

测试要点。

跟踪准确（贴纸跟随人脸移动）。

多人识别（一个画面里多个人各自贴）。

不同表情下的适配。

虚拟背景：

绿幕模式。

需要物理绿幕。

精度最高。

AI 抠图。

无需绿幕，AI 识别人物轮廓。

精度依赖光线、背景对比度。

模糊背景。

不替换，只模糊。

性能开销最小。

测试维度：

抠图精度。

人物轮廓清晰（不抠丢头发、手指）。

不抠错（不把椅子、衣服当作背景）。

边缘平滑（不锯齿）。

不同背景。

简单背景（白墙、单色）：精度高。

复杂背景（书架、人群）：精度差。

类似肤色的背景（木质墙）：容易抠错。

不同光线。

强光、弱光、逆光的表现。

光线变化的适应（如关灯瞬间）。

不同人物。

不同肤色、不同发色、不同发型。

戴眼镜、戴口罩的处理。

多人同框。

虚拟背景图。

预设背景（办公室、海滩、太空）。

用户上传自定义背景。

视频背景（动态背景）。

性能。

实时性（不能因抠图增加延迟）。

帧率（不能因抠图掉帧）。

设备适配（低端设备的降级）。

异常处理。

抠图失败的兜底（如显示纯色背景）。

光线突变的处理。

人物离开画面后的处理。

合规。

合理使用。某些场景（如银行视频客服）禁用美颜、虚拟背景（防欺诈）。

未成年人保护。某些场景禁止使用美颜（防止过度修饰）。

肖像权。背景图不能用未授权的他人肖像。

实战中美颜和虚拟背景是消费级产品的核心竞争力之一，测试同学要联动算法团队建立"效果评估体系"（客观指标 + 主观评分）。

Q14: 直播连麦怎么测？

答案：

直播连麦是 RTC + 直播的混合场景，是直播间互动的核心玩法。技术上要同时满足"实时交互"（连麦双方）和"海量观众观看"。

连麦流程：

观众端申请连麦。

观众点击"申请连麦"按钮。

申请进入主播的"连麦队列"。

主播看到申请列表。

主播同意连麦。

主播选择某个观众接入。

服务端建立 RTC 通道。

连麦观众的画面进入直播间。

连麦中。

双方 RTC 通信（低延迟）。

普通观众通过 CDN 看混流后的画面（标准延迟）。

聊天、礼物、点赞依然正常。

下麦。

主播主动下麦或连麦观众主动下麦。

RTC 通道关闭。

观众回到普通观众状态。

测试维度：

连麦申请。

申请按钮可见性、申请规则（VIP 优先、新粉丝免费、其他用户付费）。

申请列表展示（主播能看到申请人头像、用户级别）。

申请取消。

连麦审批。

主播审批的便利性（一键同意 / 拒绝）。

审批响应时间（不能让申请人等太久）。

审批权限（主播 + 房管能审批）。

连麦建立。

从同意到双方画面互通的时长（< 5 秒）。

新连麦观众的设备测试（摄像头、麦克风）。

布局自适应（主播 + 1 个连麦观众 vs 主播 + 多个连麦观众）。

连麦质量。

延迟。连麦双方的端到端延迟 < 500ms。

弱网。连麦观众网络差时如何处理（降画质、纯语音、断开）。

回声 / 噪声。3A 算法对连麦双方都生效。

观看体验。

普通观众看到的混流画面流畅。

延迟可接受（标准直播 3~5 秒）。

互动正常（弹幕、点赞、礼物）。

下麦。

下麦动作的流畅性（画面平滑过渡）。

下麦后状态恢复（主播 UI、观众 UI）。

下麦后连麦观众的礼物 / 弹幕保留。

异常处理。

连麦观众网络断开。

连麦观众主动退出直播间。

主播网络问题。

连麦时间过长（部分平台有时间限制，如 5 分钟自动下麦）。

连麦双方互踢（黑名单、拉黑）。

商业化。

付费连麦。观众付费获得连麦机会。

VIP 连麦权益。

打赏后优先连麦。

连麦排队系统。

合规。

连麦观众的实名认证（监管要求所有上麦人实名）。

连麦内容审核（连麦观众也要过审）。

违规连麦的处罚（封号、扣分）。

不同业务的差异。

普通直播连麦。1v1 连麦（一个观众进入）。

聚会直播。多人同时上麦。

PK 连麦。两个主播 1v1 PK（双方各自有观众群）。

带货连麦。商家直播 + 嘉宾连麦。

性能。

服务端混流压力（详见 Q4 MCU）。

成本（连麦多消耗 RTC 资源 + 混流资源）。

测试方法：

真实环境测试。多设备模拟主播、连麦观众、普通观众。

弱网测试。连麦双方都注入弱网，看体验。

并发测试。多个观众同时申请连麦的承载能力。

混合测试。连麦 + 弹幕 + 礼物 + 点赞同时压测。

直播连麦是直播平台的"商业化引擎"之一，测试同学要把"连麦体验 + 直播观看体验"两端都保障好。

四、稳定性与监控（4题）

Q15: RTC 海量并发和频道压测怎么做？

答案：

RTC 系统的压测和普通 HTTP 服务不同，要关注的是"并发会话数""并发音视频流""跨地区延迟"等独特维度。

典型压测目标：

会议系统。万级并发会议、十万级并发参会者。

直播连麦。同时 1000 个连麦会话、百万观看。

视频客服。万级并发客服会话。

教育课堂。万级并发课堂、百万并发学员。

压测维度：

会话数。

同时存在的 RTC 会话总数。

服务端能承载的会话上限。

每个会话的资源占用（CPU、内存、带宽）。

会话规模。

每个会话的参与者数（1v1 vs 多人 vs 大房间）。

不同规模会话的承载差异。

媒体流并发。

总并发流数（每个会话 N 路）。

服务端转发能力（特别是 SFU）。

服务端混流能力（特别是 MCU）。

带宽。

平台总带宽消耗。

每个 RTC 流的带宽。

带宽峰值与平均值。

地理分布。

跨地区会话（北京和深圳的人开会）。

跨国会话（北京和美国的人开会）。

不同 ISP 之间的会话。

压测方法：

模拟客户端。

用脚本模拟大量客户端建立 RTC 会话。

每个模拟客户端发送和接收媒体流。

机器规模（一台机器能模拟几十~几百个客户端）。

媒体流真实性。

最真实：每个模拟客户端发真实音视频流（资源消耗大）。

折中：发预录制的音视频流（节省 CPU）。

最轻量：只发信令 + 静音/黑屏的媒体流（验证信令路径）。

压测策略。

单维度压测。固定其他维度，只压一个维度（如固定 1v1 会话，压会话数）。

复合压测。多维度同时压（多人会议 + 1v1 + 连麦）。

阶梯压测。逐步加压（1k → 10k → 100k 会话）。

混合压测。

会议进行中 + 新会议涌入 + 旧会议结束的混合模式。

观察资源动态调整。

故障注入。

压测过程中关掉某个 SFU 节点，观察会话能否自动迁移。

注入网络故障（机房间断开），看跨区会话表现。

数据库故障，看信令是否依然可用。

监控指标。

服务端。

各服务的 CPU / 内存 / 网络。

媒体流的转发延迟、丢包率。

新建会话的成功率。

新建会话的耗时。

客户端（模拟）。

建连成功率。

媒体流接收完整性。

音视频质量指标。

业务。

会议数、参会者数。

异常断开率。

容量评估：

单机能力。一台 SFU 服务器能承载的流数（如 1000~5000 路）。

集群能力。整个 RTC 集群的会议数和参会者数。

弹性扩容。流量超过当前容量时能否自动扩容。

成本估算。每个会议的资源成本（CPU + 内存 + 带宽）。

实战中 RTC 压测的成本很高（带宽 + 算力），建议每个版本只做关键指标的压测，每季度做一次完整压测。

Q16: RTC 跨地区、跨国测试要点？

答案：

RTC 系统的用户分布广，从同城近距离通话到跨国跨大洲会议，每个场景的网络环境差异巨大，要建立完整的跨地区测试体系。

跨地区分级：

同城内。北京内、上海内。物理延迟 < 10ms。

同省内。江苏内、广东内。物理延迟 < 30ms。

跨省。北京 ↔ 深圳。物理延迟 30~50ms。

跨大区。东北 ↔ 西南。物理延迟 50~80ms。

跨国（亚洲内）。中国 ↔ 日本 / 韩国 / 东南亚。物理延迟 100~200ms。

跨大洲。中国 ↔ 欧洲 / 美洲。物理延迟 200~400ms。

测试维度：

延迟。

物理延迟。光速决定，不可改变。

实际延迟。物理延迟 + 网络处理 + RTC 处理。要测实际延迟分布。

延迟可接受性。1v1 通话 < 300ms 可接受，> 500ms 用户感知明显。

丢包率。

不同地区之间的网络丢包差异。

跨国丢包通常比国内高。

特殊地区（如非洲、南美）丢包率更高。

抖动。

跨大洲网络抖动大。

跨运营商抖动差异。

带宽。

不同地区用户的平均带宽。

高峰时段带宽限制。

NAT 类型分布。

不同国家、不同运营商的 NAT 类型分布。

特殊地区（企业网、酒店网）的 NAT 限制。

测试方法：

真实环境测试。

在目标地区部署真实测试设备（实验室）。

定期跑测试用例，监控指标。

VPN / 跨地区机器测试。

便宜但不完全真实（VPN 流量可能比直连慢）。

可作为辅助手段。

云服务跨地区。

在云服务的不同地区机房部署测试节点。

用云内网络模拟跨地区通信。

合作伙伴测试。

和当地 ISP、CDN 厂商合作做联调。

接入当地的测试节点。

线上监控。

按地区、ISP、设备类型上报真实用户的 RTC 质量数据。

建立"地区健康度看板"。

部署优化：

接入节点。

按地理位置部署 SFU、TURN 节点。

智能调度。根据用户位置选最近节点。

跨地区中转。

跨大洲会议需要中转节点（不能直接 P2P）。

中转节点放在网络中心（如新加坡、洛杉矶、伦敦）。

边缘节点。

CDN 边缘节点提供低延迟接入。

合规与监管：

数据本地化。某些国家要求数据不出境（中国、欧盟）。

跨境数据传输的合规审批。

监管要求。某些国家对 RTC 应用有特殊要求（如俄罗斯要求语音可监听）。

特殊地区：

中国大陆 ↔ 海外。中国防火墙影响，部分 RTC 服务可能被限制。要测专线 / 加速服务。

香港 / 台湾。介于内地和海外之间，路由复杂。

中东 / 非洲。基础设施差，体验降级。

实战中跨地区测试是 RTC 出海的关键挑战，要建立"全球质量看板"持续监控和优化。

Q17: RTC 监控指标和 QoS 体系怎么建？

答案：

RTC 系统的监控比传统系统复杂得多，因为要关注的不只是"接口可用性"，还有大量音视频质量维度。

QoS（Quality of Service，服务质量）核心指标：

通信质量。

建连成功率。从拨号到通话建立的成功率，理想 > 99%。

建连时长。拨号到通话建立的耗时，理想 P95 < 3s。

通话异常率。通话过程中异常断开的比例，理想 < 1%。

通话时长分布。短时（< 5s）、中时、长时（> 30 min）通话的分布。

音视频质量。

音频。

MOS 评分。客观或主观评分。

回声 / 噪声残留率。

音频流畅度（卡顿次数、卡顿时长）。

视频。

帧率。理想 30fps、可接受 15fps。

分辨率。

码率。

卡顿率。

清晰度（PSNR、SSIM、VMAF）。

延迟。

端到端延迟分布（P50、P95、P99）。

各组成部分的延迟（采集、编码、网络、解码、渲染）。

网络。

丢包率。

RTT。

抖动。

带宽估计。

设备。

CPU 占用。

内存占用。

电量消耗。

发热（手机过热可能降码率）。

监控数据来源：

客户端上报。每个 RTC 会话结束后上报详细数据（建连耗时、平均码率、卡顿次数、用户体验评分）。

服务端日志。SFU、TURN 等服务的日志统计。

WebRTC Stats API。线上实时数据。

第三方监控。集成的 RTC SDK 厂商提供的 dashboard（如声网、即构）。

数据分析维度：

时间维度。

实时（分钟级）。

历史（日 / 周 / 月）。

业务维度。

不同业务（会议 / 1v1 / 连麦）。

不同房间规模。

地理维度。

国家、地区、城市。

运营商。

设备维度。

操作系统、设备型号、APP 版本。

新老用户。

新用户 vs 老用户。

VIP vs 普通用户。

异常检测：

阈值告警。某指标超过阈值告警（如错误率 > 1%）。

异常波动。机器学习识别非阈值的异常。

地区异常。某地区指标突然恶化。

用户群异常。某设备型号、某 APP 版本指标恶化。

监控大盘：

实时大盘。每分钟刷新的核心指标。

历史大盘。趋势分析、对比分析。

告警面板。当前未处理告警。

事故复盘。历史事故的影响范围、恢复时间。

QoE（Quality of Experience，用户体验）：

QoS 是技术指标，QoE 是用户感知。两者不完全对应。

用户主观评分。每次通话后弹"通话质量评分"。

NPS 调研。

投诉率。投诉量除以总通话量。

留存率。RTC 用户的留存。

测试同学的工作：

参与监控指标定义。哪些指标该监控、阈值多少。

参与告警规则配置。哪些告警该响、级别多高。

参与告警响应。线上故障时快速定位和恢复。

参与数据复盘。每周、每月分析指标趋势，发现可优化点。

实战中"监控能力"是衡量 RTC 系统成熟度的核心指标，测试同学要把它做成"系统的眼睛"。

Q18: RTC 故障演练和降级怎么测？

答案：

RTC 系统的稳定性 SLA 极高（一般 99.9%~99.99%），任何故障都会引起用户投诉甚至公关事故（如 Zoom 故障上头条）。要建立完整的故障预案和演练体系。

常见故障类型：

服务端故障。

SFU / MCU 节点宕机。

TURN / STUN 服务故障。

信令服务故障。

数据库故障（用户信息、会话记录）。

消息队列故障。

监控系统故障。

网络故障。

机房间网络中断。

某地区接入故障。

跨国链路故障。

DNS 故障。

CDN 故障。

第三方依赖。

推送通道故障。

短信通道故障。

地图服务故障（位置信息）。

人脸识别服务故障。

客户端问题。

某 APP 版本崩溃。

某设备型号兼容问题。

某 OS 版本兼容问题。

故障演练：

混沌工程。

工具：ChaosBlade、Chaos Mesh、Litmus。

场景：随机注入网络延迟、丢包、CPU 满载、磁盘 IO 阻塞、进程挂掉。

频率：日常每周一次小演练、每季度大演练。

灾难演练。

机房断电。

跨地区切流。

主备数据库切换。

降级方案。

每个核心功能要有降级开关。

降级时用户体验可接受（不是完全不可用）。

每个降级开关都要测可控、可回滚。

应急响应：

值班机制。7x24 值班，按"业务方向 + 故障级别"分配人。

响应时长。

P0 故障（影响 > 30% 用户）：5 分钟内响应、30 分钟内恢复。

P1 故障（影响 5~30% 用户）：15 分钟响应、1 小时恢复。

P2 故障（影响 < 5%）：30 分钟响应、4 小时恢复。

应急 SOP。每类故障的处理步骤、决策权、联系人。

降级策略：

按功能降级。

非核心功能下线（聊天、文件传输、虚拟背景）。

核心功能简化（如降画质、降帧率）。

按用户降级。

VIP 用户优先保障。

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

按地区降级。

某地区故障时只影响该地区。

其他地区正常服务。

降级开关。

精细到功能维度（如"虚拟背景降级开关""高清降级开关"）。

秒级生效。

灰度切换（1% → 10% → 100%）。

回滚能力。

权限审计。

测试方法：

故障注入测试。在受控环境注入故障，验证系统恢复。

灾难演练。模拟真实灾难场景，全团队参与。

混沌测试。日常自动注入小故障，提升系统韧性。

复盘文化。

每次故障演练后写复盘报告。

每次真实故障后必须复盘。

改进项落地跟踪。

知识沉淀。复盘报告共享给团队，作为新人培训材料。

监控告警：

告警准确。不漏报、不误报。

告警分级。P0 ~ P3。

告警送达。短信 + 电话 + 邮件 + 群通知。

告警响应。值班同学秒级响应。

数据备份与恢复。

会话记录、用户数据、配置数据的定期备份。

异地备份。

恢复演练。定期演练数据恢复流程。

实战中"故障演练"是 RTC 系统的护城河，做得多了团队对故障"脱敏"，应急能力强；做得少团队对故障"敏感"，每次都手忙脚乱。测试同学要把故障演练当成日常工作。