音视频自动化测试体系（性能基准 / 设备兼容 / CI 回归）
内容提要
音视频测试因依赖真机、时序敏感、指标连续而难以自动化。文章提出三层测试体系：单元测试覆盖时间戳映射、抖动缓冲等纯逻辑；性能基准量化编码延迟、帧率、内存等硬指标；设备兼容按高中低配真机矩阵跑CI回归，并对比基准阈值防退化。强调分层测试，避免单层解决所有问题。
延伸解读
分层测试：音视频自动化的务实路径
文章强调音视频测试应分为单元测试、性能基准和设备兼容三层，各司其职。单元测试覆盖纯逻辑，性能基准量化硬指标，设备兼容在真机矩阵上回归。这种分层避免了试图用单一测试解决所有问题的误区，为团队提供了清晰的自动化实施框架。
性能基准的稳定性与阈值设定
性能基准测试需在真机上进行，模拟器因无硬编解码器结果偏差大。文章建议预热、固定环境、多次取中位数来减少波动，并将CI阈值放宽至15%以降低误报。这些实践有助于平衡测试敏感度与稳定性，确保基准结果可靠可比。
设备兼容矩阵：覆盖高中低配真机
设备兼容测试需按高、中、低配分级，每级至少两台真机，覆盖不同芯片平台。文章指出仅测旗舰机可能导致低端机上线后暴露问题，因此矩阵应包含入门机型。通过CI触发真机回归，可提前发现兼容性问题，降低线上风险。
测试维护：避免与实现强耦合
文章提到测试用例难维护的坑：测试与实现强耦合会导致改一处崩一片。建议测接口而非实现，并采用依赖注入。这能提升测试的稳定性和可维护性，使测试体系能适应代码演进，而不是成为开发负担。
Q&A
音视频自动化测试为什么比普通业务测试难？
音视频测试有三个核心难点：一是依赖真机硬件，如摄像头、麦克风、GPU、硬编解码器，模拟器无法测试；二是时序敏感，编码、网络、同步都依赖实时时序，单元测试覆盖不到；三是没有明确的“对错”，只有“好坏”，画质、流畅度是连续值而非布尔值。
音视频测试体系分为哪几层？各层职责是什么？
音视频测试体系分为三层：单元测试（纯逻辑）覆盖时间戳计算、时间轴映射、抖动估算等纯逻辑，量大、快、纯代码；性能基准（Benchmark）量化编码延迟、帧率、内存等硬指标，中量、量化指标；设备兼容（真机矩阵）在真机矩阵上跑回归，少量、真机、慢。三层各司其职，不能指望一层解决所有问题。
音视频单元测试主要覆盖哪些纯逻辑？
音视频单元测试主要覆盖可以脱离硬件测试的纯逻辑，包括时间戳换算、变速映射、抖动估算、采样率换算等。例如时间轴变速映射的单元测试、抖动缓冲的单元测试。
性能基准测试需要量化哪些关键指标？如何保证可重复和可对比？
性能基准测试需要量化编码延迟、帧率、内存、功耗等硬指标。关键是要可重复、可对比，例如通过固定环境、预热、多次取中位数来保证稳定性，并对比基准阈值防止退化。
设备兼容矩阵如何分级？CI 回归如何配置？
设备兼容矩阵按高配（如 iPhone 15 Pro、小米 14、三星 S24）、中配（如 iPhone 13、小米 12、荣耀 90）、低配（如 iPhone SE、红米 Note、入门机）分级，每个等级至少 2 台，覆盖不同芯片。CI 回归通过 GitHub Actions 等配置，在 pull request 触发时运行单元测试、性能基准（对比基准阈值）和设备兼容测试（真机矩阵）。
音视频自动化测试常见的坑有哪些？如何解决？
常见坑包括：基准结果不稳定（后台进程/发热/降频导致），需预热、固定环境、多次取中位数；模拟器测不准硬编（无硬编解码器），性能基准必须在真机跑；单测覆盖不了时序，需分层测试；兼容矩阵不完整，需设备分级每级至少 2 台；CI 误报频繁，阈值放宽到 15% 并多次重跑；测试用例难维护，应测接口不测实现，依赖注入。
