2、稳定性测试基础理论：压力测试定义、稳定性指标、测试生命周期
各位好，我是老张。在座舱系统这个行当摸爬滚打了十几年，今天咱们来聊聊稳定性测试里最核心的几个概念。说实话，很多人做了好几年测试，对「压力测试」和「稳定性测试」的区别还是模模糊糊的。我见过不少团队，把跑个Monkey Test就当成压力测试了，结果一上量产车就出问题。
这一节，咱们把基础打扎实。我会结合MTK8676这颗芯片的特性，把压力测试的定义、关键指标、还有整个测试生命周期掰开揉碎了讲清楚。
2.1 压力测试到底测什么？
先问大家一个问题：你觉得压力测试和负载测试是一回事吗？
我个人的理解是这样的——负载测试是看系统在「正常预期」的高负载下能不能稳定运行。而压力测试，说白了就是「往死里怼」，看看系统到底在什么临界点会崩掉。
举个例子。MTK8676这颗芯片，官方标称支持三屏异显。负载测试就是同时开三个屏幕，导航、音乐、视频各跑各的，看看卡不卡。压力测试呢？我会同时开四个屏幕，或者把三个屏幕的分辨率都拉到4K，再叠加一个后台录像，看看系统什么时候开始丢帧、什么时候直接黑屏重启。
我习惯把压力测试分成两类：
- 资源型压力：CPU跑满、内存吃光、IO带宽打满。比如在8676上同时跑8个4K视频解码，再开一个安兔兔跑分。
- 并发型压力：短时间内大量操作。比如1秒内连续点击屏幕100次，或者同时启动所有预装App。
核心观点：压力测试不是为了证明系统「能用」，而是为了找到系统「什么时候不能用」。这个临界点，就是我们要找的「性能拐点」。
2.2 稳定性指标——拿什么衡量？
指标这东西，说起来简单，但坑特别多。我刚开始带项目的时候，就吃过「只看平均值」的亏。
当时测一个8676的项目，CPU平均占用率才45%，内存占用60%，看起来一切正常。结果用户一上车，导航+音乐+蓝牙电话同时开，系统直接卡死。后来一查日志，发现CPU占用率在某个瞬间飙到了98%，持续了3秒。平均值骗了我们。
所以我现在看稳定性指标，重点看这几个：
| 指标类别 | 具体指标 | MTK8676上的典型阈值 |
|---|---|---|
| CPU | 峰值占用率、平均占用率、波动幅度 | 峰值不超过85%，波动幅度不超过20% |
| 内存 | 总占用、泄漏速率、OOM频率 | 总占用不超过70%，泄漏速率小于1MB/h |
| 帧率 | 平均FPS、最低FPS、帧间隔抖动 | 平均不低于30fps，最低不低于24fps |
| 温度 | SoC温度、外壳温度、温升速率 | SoC不超过85℃，温升速率不超过5℃/min |
| 稳定性 | 无故障运行时间、重启次数、ANR次数 | 连续72小时无重启，ANR次数为0 |
这里我特别想强调一下帧间隔抖动这个指标。很多人只看平均帧率，觉得30fps就合格了。但你想想看，如果前一帧用了20ms，后一帧突然用了50ms，中间这30ms的延迟，人眼是能感知到的。这就是所谓的「卡顿感」。
我的经验：在8676上做压力测试时，我会把帧间隔抖动的阈值设在5ms以内。超过这个值，用户就能感觉到「不跟手」了。
2.3 测试生命周期——从计划到收尾
一个完整的稳定性测试，不是上来就跑脚本。我把它分成五个阶段，每个阶段都有明确的目标和产出。
第一阶段：需求分析与计划
这个阶段要搞清楚三件事：
- 系统要支持的最大并发场景是什么？（比如三屏同时导航+音乐+蓝牙电话）
- 用户最常用的操作路径是什么？（比如从主界面进入导航，再切回音乐）
- 系统允许的性能底线在哪里？（比如启动时间不超过3秒，切换动画不卡顿）
我习惯在这个阶段就拉上开发一起过一遍。因为很多性能瓶颈，开发心里是有数的。比如8676的GPU在4K分辨率下性能会下降，这个信息越早知道越好。
第二阶段：测试环境搭建
环境搭建最容易被忽视。我见过有人直接在开发板上跑压力测试，结果散热条件跟量产车完全不一样，测出来的数据根本不能用。
对于8676来说，我建议：
- 使用量产版本的硬件（散热、电源都要一致）
- 安装完整的座舱系统软件栈（包括中间件、HMI、服务层）
- 模拟真实的网络环境（4G/5G信号强度、WiFi延迟）
- 接入真实的传感器数据（GPS信号、摄像头输入）
注意：千万不要在「裸板」上做压力测试。裸板的散热和电源供应跟实际座舱环境差太多，测出来的结果没有参考价值。我曾经就因为这个吃过亏，裸板上跑了48小时没问题，装到车里半小时就过热降频了。
第三阶段：测试执行
执行阶段，我一般会跑三类测试：
- 基准测试：在无负载情况下，记录CPU、内存、帧率的基线数据。
- 递增压力测试：逐步增加负载，比如从1个视频流增加到4个，记录每个阶段的性能数据。
- 长时间稳定性测试：在最大负载下，连续运行72小时以上，监控各项指标。
这里有个小技巧——我会在测试脚本里加入「随机操作」。因为用户的操作不是线性的，有时候会突然切后台，有时候会快速滑动列表。这些随机操作往往能触发一些隐藏的bug。
第四阶段：数据收集与分析
数据收集不是简单地看几个数字。我习惯把数据可视化，画成趋势图。比如CPU占用率随时间的变化曲线，帧率随温度的变化曲线。这样能一眼看出问题。
分析的时候，重点关注几个「异常点」：
- CPU占用率突然飙升的时刻
- 帧率突然下降的时刻
- 温度超过阈值的时刻
- 内存占用持续上升（泄漏）的趋势
第五阶段：问题定位与回归
发现问题只是第一步，定位问题才是关键。我一般会：
- 查看系统日志（logcat、kernel log）
- 抓取trace文件（分析CPU/GPU调度情况）
- 复现问题（用同样的压力场景再跑一次）
- 跟开发一起分析代码（有时候是驱动问题，有时候是应用层问题）
问题修复后，一定要做回归测试。而且回归测试的压力场景要比原来更严苛一些。为什么？因为修复了一个bug，往往可能引入新的bug。这个教训，我是用几个通宵换来的。
总结一下：稳定性测试不是一次性的工作，而是一个持续迭代的过程。每次发现问题、修复问题、回归验证，系统的稳定性就会提升一个台阶。说白了，这就是一个「磨」的过程。
好了，这一节的内容就到这里。下一节咱们会深入讲MTK8676的硬件架构，看看这颗芯片的「体质」到底怎么样，哪些地方容易成为性能瓶颈。到时候我会分享一些具体的调试工具和方法，敬请期待。
课后思考：如果你现在手头有一个8676的项目，你会先跑哪个压力场景？为什么？欢迎在评论区跟我交流。