行车记录仪拉流性能测试方案

在车载终端测试里，行车记录仪相关性能测试是一个很典型、也很容易"看起来简单、做起来复杂"的方向。

很多人一开始会把它理解成"压一压接口"，但真正做起来会发现，这类测试其实同时涉及：

业务控制接口
设备在线状态
音视频流建立
双摄像头切换
直播与录像流混合负载
特殊工作状态下的稳定性
监控平台的数据观测
资源释放与异常恢复

如果只是单纯看某个 HTTP 接口是否返回成功，通常只能说明"请求收到了"，并不能说明"视频真的稳定拉起来了"。

这篇文章结合一个典型的车载行车记录仪测试项目，系统整理一下：
如何设计一套面向实时拉流场景的性能测试方案。

一、先说结论：行车记录仪拉流性能测试，不只是接口压测

这类项目最容易踩的坑，是把"开流接口成功"误认为"拉流成功"。

一个典型过程通常是这样：

客户端发起开流请求
业务平台返回对应通道的播放地址
监控或流媒体平台中出现对应在线流
客户端持续拉取视频流
在播放过程中维持连接、统计码率、在线时长和观众数
用户切换摄像头、切换直播/录像、停止拉流
平台释放连接和会话

所以，测试目标至少应覆盖两个层面：

1）控制面

也就是各种接口和控制行为：

登录
查询设备状态
发起开流
停止拉流
摄像头切换
录像流请求
特殊状态下的请求行为

2）媒体面

也就是流是否真的正常建立和持续存在：

在线流是否注册成功
连接数是否正常
码率是否合理
观众数是否匹配
在线时长是否持续增长
停流后资源是否正确回收

因此，这类测试必须把接口结果 和监控平台观测结果结合起来分析。

二、测试对象应该怎么拆

为了避免测试范围混乱，我一般会把行车记录仪拉流性能测试拆成以下几个对象层级：

1. 设备层

这是最底层，也是很容易被忽略的一层。

需要关注：

设备是否在线
双摄像头是否都可用
是否支持直播流与录像流
是否存在特殊运行状态（如低功耗、驻车、AOV 等）
设备在长时间拉流后是否出现性能退化

2. 接口层

主要关注业务系统提供的开流、停流、切换、录像流等接口。

需要观察：

请求成功率
P95 响应时间
并发能力
参数校验
异常返回是否明确

3. 流媒体/监控平台层

这里是最关键的观测面。

常见需要看：

在线流数
当前观众
连接类型
连接数
流 ID
码率
在线时长
轨道信息
停流后是否及时下线

4. 业务场景层

这是最终决定方案是否有价值的一层。

典型场景包括：

单路直播
双摄切换
直播与录像混合
AOV 状态下拉流
停流释放
批量设备并发拉流

三、为什么这类测试不能只盯着 JMeter

JMeter 在这类项目里很有用，但它的定位要分清楚。

JMeter 适合做什么

并发发起开流请求
并发调用停流接口
做参数化控制
模拟批量用户或批量设备行为
统计响应时间、成功率、错误率
编排测试节奏和事务流程

JMeter 不擅长什么

判断视频是否真正稳定可用
直接分析流媒体质量
观察在线流生命周期
跟踪连接是否正常释放
从平台视角统计在线流和观众数

所以更合理的做法是：

JMeter 负责控制面
监控平台负责媒体面
日志系统负责问题定位

只有把这三部分串起来，测试结论才可信。

四、一个比较完整的测试目标怎么写

以一个典型的第一阶段项目为例，可以把目标定义为：

验证 100 台行车记录仪在实时拉流场景下的建流成功率
验证双摄像头场景下通道切换的稳定性
验证直播流与录像流混合场景下的平台承载能力
验证特殊工作状态（如 AOV）下的拉流稳定性
验证停流后资源是否正常释放
输出第一阶段容量基线和问题清单

这几个目标看起来不复杂，但足够支撑一轮完整的性能测试。

五、核心测试场景怎么设计

场景 1：建流接口基线测试

这是第一步，用来摸底接口层能力。

建议做法：

设置 10 / 20 / 50 / 100 并发
分别对不同摄像头通道进行建流请求
关注接口成功率、P95、错误率
校验返回的播放地址是否非空

这个阶段主要是确认：

接口本身有没有明显瓶颈
参数化脚本有没有问题
平台是否能稳定返回播放地址

场景 2：100 台设备分批拉流

这个场景更接近真实压测。

建议做法：

按 20 台一批逐步建立连接
先拉第一路，再拉第二路
每一批建立后保持一段时间
观察平台在线流、观众数、连接数、码率变化

这样做的好处是：

更容易定位问题从哪一批开始出现
不会因为瞬间压满导致故障点模糊
有利于观察资源爬升曲线

场景 3：100 路稳定保持

建立完流之后，不要立刻结束，要进入"保持阶段"。

这个阶段建议重点看：

在线流是否持续存在
在线时长是否连续增长
码率是否稳定
观众数是否正常
是否出现异常断流
平台资源是否持续升高

很多系统建流阶段表现正常，但在保持阶段会暴露出：

资源泄漏
长连接不稳定
流生命周期异常
平台线程压力持续累积

场景 4：双摄切换

双摄设备最大的特点就是不能只测单路。

至少要覆盖：

单设备从 ch1 切换到 ch2
单设备从 ch2 切换到 ch1
往返切换
批量切换
混合切换

切换场景要重点观察：

目标流是否成功建立
旧流是否释放
切换时延
切换后码率和观众数是否正常
是否出现残留流或僵尸连接

这个场景往往比单纯建流更能测出平台问题。

场景 5：50 台直播 + 50 台录像流混合

这是一个很有价值的场景，因为它更贴近真实业务。

测试重点：

直播流和录像流是否互相抢资源
混合负载下平台是否出现响应劣化
不同流类型对连接、码率和在线流数的影响
是否出现某一类流优先成功、另一类流明显失败的情况

很多平台单测直播没问题，但直播与录像混合后就会暴露调度不合理、缓存冲突或资源分配不均的问题。

场景 6：AOV 状态下拉流

AOV 这类特殊工作状态，往往意味着设备行为和常规在线状态不同。

这个场景重点看：

建流成功率是否下降
建流时间是否变长
流建立后是否稳定
停流后是否正常回收
与常规状态相比是否存在明显差异

这种场景的价值不在于"量大"，而在于它能暴露出设备状态与平台链路之间的兼容性问题。

六、监控平台到底要看什么

在行车记录仪性能测试里，监控平台不是可有可无，而是关键依据之一。

建议重点关注以下字段：

状态概览

在线流数
当前观众
CPU / 内存
网络收发速度
线程负载

连接管理

HTTP 会话连接
设备侧音视频会话
本地 IP / 远端 IP
连接端口
残留连接情况

视频管理

应用名
流 ID
协议
类型
观众数
在线时长
码率
轨道信息
停止操作后的下线情况

这些字段可以帮助测试人员回答几个关键问题：

流有没有真正建起来？
是哪一路流？
有多少人在消费？
是否持续稳定？
停流后有没有释放？

七、指标设计要避免"空泛"

很多性能测试报告的问题在于指标写得很漂亮，但没有口径。

建议至少明确这些指标：

接口层

开流成功率
停流成功率
P95 响应时间

业务层

建流成功率
双摄切换成功率
直播/录像混合成功率
AOV 场景建流成功率

媒体层

异常断流率
在线流数偏差
观众数偏差
停流后流释放时长

资源层

CPU 峰值
内存趋势
网络发送速率趋势

只要这些指标定义清楚，测试结论就会有支撑，而不是泛泛地说"性能正常"。

八、几个特别容易忽略的问题

1. 返回播放地址不等于拉流成功

接口返回 URL，只能说明控制面基本完成，不能证明流已经稳定存在。

2. 双摄切换一定要验证旧流释放

很多系统的毛病不在切不过去，而在切过去之后旧流没清理掉。

3. 混合场景比单场景更能暴露问题

单独直播、单独录像都正常，不代表混合时也正常。

4. 特殊状态一定单独测

AOV、低功耗、驻车等状态下，设备和平台的行为很可能跟常规模式不同。

5. 停流场景不能省

如果不测停流回收，后面的稳定性结论通常都不完整。

九、最后总结

行车记录仪拉流性能测试，本质上是一个控制面 + 媒体面 + 设备面 + 监控面 共同组成的系统性测试工作。

它的难点不在于压测工具本身，而在于你是否把真实业务链路拆清楚了。

一套真正有价值的方案，应该至少回答下面几个问题：

并发建流能不能成功？
双摄切换稳不稳定？
直播和录像混合时会不会互相影响？
特殊状态下还能不能稳定拉流？
停流后资源能不能正确释放？
监控平台能不能证明你的判断？

如果这些问题都能被量化回答，那这套测试方案就不仅仅是"跑了一次压测"，而是真正形成了可以复用的方法论。

结语

对于车载终端测试来说，性能测试不是功能测试的放大版，而是一套独立的方法体系。

尤其是涉及音视频、双摄、混合流和特殊设备状态时，测试设计比执行本身更重要。

如果你也在做类似项目，我的建议是：

先把链路画清楚，再把场景分清楚，最后才是写脚本和压系统。

这样做出来的结果，才经得住复盘。