第三章 稳定性测试基础：测试策略、测试用例设计原则、通过/失败标准

各位好，我是老张。在座舱系统这个行当摸爬滚打了十几年，今天咱们来聊聊稳定性测试的根基。说白了，这部分内容就是整个测试工作的「宪法」——没有它，你测出来的东西自己心里都没底。

我记得刚入行那会儿，带我的师傅说过一句话，我一直记到现在：「测试不是找bug，是建立信心。」嗯，这话我越琢磨越觉得有道理。你想想看，如果连测试策略和通过标准都没想清楚，你怎么敢把系统交给用户？

3.1 测试策略：先打地基，再盖楼

测试策略这东西，说白了就是「怎么测」的问题。我个人习惯把MTK8678的稳定性测试分成三个层次，就像盖房子一样：

1. 基础压力层：先让系统跑起来，看看能不能扛得住最基本的负载。比如同时开导航、放音乐、接蓝牙电话。
2. 边界冲击层：把系统往死里怼。内存用到90%以上、CPU跑满、存储空间只剩100MB——看看它会不会崩。
3. 长稳验证层：连续跑72小时甚至168小时。我在项目中遇到过，有些bug就是跑了两三天才冒出来的，短时间根本发现不了。

具体到MTK8678平台，我建议这样分配测试资源：

测试层次	测试时长	资源占比	主要关注点
基础压力层	4-8小时	20%	功能完整性、基本响应
边界冲击层	12-24小时	30%	内存泄漏、资源竞争
长稳验证层	72-168小时	50%	长时间运行稳定性

3.2 测试用例设计原则：少即是多

很多新手喜欢堆用例，一写就是上千条。但说实话，真正有价值的用例可能不到100条。为什么？因为稳定性测试讲究的是「覆盖率」而不是「数量」。

我总结了四个原则，你们可以记一下：

• 场景驱动：别凭空想用例。去跟产品经理聊，去跟用户聊，看看他们真实的使用场景是什么。MTK8678最常见的场景就是「导航+音乐+电话」三件套。
• 边界优先：80%的bug都出在边界上。比如内存阈值、温度阈值、存储阈值。我曾经因为没测存储满的情况，结果用户拷了几部电影进去，系统直接卡死了。
• 并发为王：座舱系统最怕的就是并发。多个app同时请求资源、多个传感器同时上报数据——这种场景一定要覆盖到。
• 可复现：每条用例都要能稳定复现。如果一条用例跑十次只出现一次问题，那它基本没什么用。

举个例子，一个典型的MTK8678稳定性测试用例长这样：

用例ID: ST_001
测试场景: 导航+音乐+蓝牙电话并发
前置条件: 
  - 系统已启动，内存占用50%
  - 已连接蓝牙耳机
  - 已安装高德地图和QQ音乐
测试步骤:
  1. 启动高德地图，设置导航目的地
  2. 后台播放QQ音乐
  3. 通过蓝牙拨打/接听电话
  4. 持续操作30分钟
预期结果:
  - 导航语音正常播报
  - 音乐播放无卡顿
  - 蓝牙通话清晰
  - 系统无重启、无ANR
通过标准: 连续运行3轮无异常

3.3 通过/失败标准：别模棱两可

这块是最容易扯皮的。测试说「没过」，开发说「这不算问题」——我见过太多这种争吵了。所以，通过/失败标准一定要量化，要可测量。

我个人习惯把标准分成三个等级：

• P0（致命）：系统重启、黑屏、死机、数据丢失。出现任意一条，直接判定失败，不用商量。
• P1（严重）：功能不可用、严重卡顿（帧率低于15fps）、内存泄漏持续增长。这类问题可以给48小时修复窗口。
• P2（一般）：偶发性的小问题、UI显示异常、响应时间略长。这类问题可以放到下个版本修复。

具体到MTK8678的稳定性测试，我建议这样定义通过标准：

指标项	通过标准	失败标准
系统重启	0次	≥1次
ANR	0次	≥1次
内存泄漏	增长率<5%/24h	增长率≥5%/24h
CPU占用率	平均<60%	平均≥80%
帧率	平均≥30fps	平均<20fps
温度	≤65℃	≥75℃

嗯，这里要注意一点：这些标准不是死的。比如在夏天暴晒的环境下，温度标准可以适当放宽。但放宽之前一定要有书面确认，别自己拍脑袋改。

3.4 避坑指南：我踩过的那些坑

最后跟大家分享几个我亲身经历过的坑，希望能帮你们少走弯路：

• 坑一：只看平均值不看峰值。我曾经测了一轮，CPU平均占用率才45%，觉得没问题。结果一查日志，有几次瞬间飙到了95%——这就是隐患。
• 坑二：忽略后台进程。MTK8678有很多后台服务，比如OTA升级、数据上报。这些进程平时不显眼，但一旦同时触发，系统就扛不住了。
• 坑三：测试环境太干净。很多人在实验室里测得好好的，一上车就出问题。为什么？因为车上还有别的ECU、别的信号干扰。所以，尽量在真实环境中测。

好了，这一章的内容就到这里。下一章咱们聊聊具体的测试工具和自动化方案，到时候我会分享一些我自己写的脚本，挺实用的。