4. 稳定性测试核心指标
做固件升级稳定性测试，说白了就是回答一个问题：这版固件到底能不能放心地推出去？我见过太多团队，功能测试跑得欢，一上大规模升级就翻车。为什么？因为稳定性不是靠感觉，是靠指标说话的。
这一章，我把最关键的五个指标掰开揉碎讲清楚。每个指标背后，都有我踩过的坑。
4.1 成功率——最基础也最容易被骗的指标
成功率 = 成功升级的设备数 / 总升级设备数 × 100%。听起来简单吧？但这里有个陷阱：你统计的是「最终成功」还是「一次成功」？
我个人习惯把成功率分成两级：
- 一次成功率：设备从开始升级到结束，中间没有重试、没有断点续传，一把过。
- 最终成功率：允许重试、允许断点续传，只要最终版本号对了就算成功。
我在项目中遇到过一件事：某次OTA测试，最终成功率99.8%，看起来很美。但一查日志，发现30%的设备都重试过至少一次。用户感知呢？升级过程中卡住、重启、进度条不动——体验极差。所以我现在要求团队：一次成功率低于95%，直接打回。
一次成功率 ≥ 98% （实验室环境）
一次成功率 ≥ 95% （外场弱网环境）
最终成功率 ≥ 99.5%
4.2 中断恢复率——考验升级鲁棒性的硬指标
升级过程中断，是家常便饭。断电、断网、用户强制重启、蓝牙断开……你想想看，如果设备在升级到一半时断电，重启后变砖了，这锅谁背？
中断恢复率衡量的就是：在各种异常中断后，设备能否恢复到可用状态。注意，不是「恢复到升级前」，而是「可用状态」——有时候升级前版本有bug，恢复回去反而更糟。
我一般把恢复场景分成三类：
| 中断类型 | 期望行为 | 测试方法 |
|---|---|---|
| 断电中断 | 上电后进入recovery模式，可重新升级 | 升级过程中随机断电，重复500次 |
| 通信中断 | 网络恢复后自动续传，或提示用户重试 | 升级过程中切断Wi-Fi/BLE，等待后恢复 |
| 存储写失败 | 回滚到上一版本，不丢失用户数据 | 模拟flash写错误，注入坏块 |
4.3 异常场景覆盖率——你的测试够「脏」吗？
很多团队的测试用例太「干净」了。网络永远满格，电量永远100%，存储空间永远够用。但真实世界呢？
异常场景覆盖率 = 已覆盖的异常场景数 / 所有可能异常场景数。这个指标很难做到100%，但至少要覆盖以下维度：
- 网络异常：弱网、断网、高延迟、丢包、DNS劫持、CDN回源失败
- 设备状态异常：低电量、存储满、CPU高负载、温度过高、多任务并发
- 固件本身异常：签名校验失败、版本号冲突、分区表损坏、镜像大小超限
- 用户行为异常：升级过程中强制重启、切换App后台、拔掉外设
我建议用矩阵法来设计异常场景。举个例子：
异常场景矩阵（部分）
┌──────────────┬──────────┬──────────┬──────────┐
│ 网络状态 │ 低电量 │ 满电量 │ 充电中 │
├──────────────┼──────────┼──────────┼──────────┤
│ Wi-Fi稳定 │ 场景A │ 场景B │ 场景C │
│ Wi-Fi弱网 │ 场景D │ 场景E │ 场景F │
│ 4G弱网 │ 场景G │ 场景H │ 场景I │
│ 无网络 │ 场景J │ 场景K │ 场景L │
└──────────────┴──────────┴──────────┴──────────┘每个交叉点都是一个测试用例。嗯，这里要注意：不是所有组合都有意义。比如「无网络+充电中」这种组合，重点测的是超时处理，而不是网络传输。
4.4 升级耗时分布——别让用户等崩溃
升级耗时，不只是「平均耗时」那么简单。我见过一个产品，平均升级耗时3分钟，但P99耗时达到了45分钟。你想想看，那1%的用户是什么体验？
我习惯用以下指标来描述耗时分布：
- P50（中位数）：一半用户在这个时间内完成
- P95：95%的用户在这个时间内完成
- P99：99%的用户在这个时间内完成
- 最大值：最慢的那个倒霉蛋等了多久
另外，我习惯把升级过程拆成几个阶段来统计耗时：
- 下载阶段：从开始下载到下载完成
- 校验阶段：签名校验、CRC校验、版本兼容性检查
- 写入阶段：把固件写入flash/存储
- 重启阶段：设备重启、加载新固件、初始化
每个阶段的耗时分布都要单独看。我在项目中遇到过，下载阶段只占20%的时间，但校验阶段占了60%——因为用了软件CRC，没开硬件加速。换用硬件CRC后，整体耗时直接砍半。
4.5 资源消耗监控——升级不能拖垮系统
升级过程本身也是要消耗资源的。如果升级把CPU吃满、内存占光、电量耗干，那就算升级成功了，用户也会骂娘。
我一般监控以下资源：
| 资源类型 | 监控指标 | 警戒线 |
|---|---|---|
| CPU | 升级进程CPU占用率、系统总CPU占用率 | 峰值不超过80%，平均不超过50% |
| 内存 | 升级进程RSS、系统可用内存 | 系统可用内存不低于总内存的20% |
| 存储 | 临时文件占用、下载缓存占用 | 不超过可用存储的30% |
| 电量 | 升级期间电量消耗速率 | 不超过正常待机的3倍 |
| 网络 | 瞬时带宽占用、连接数 | 不抢占其他业务的带宽 |
这里有个容易被忽略的点：资源释放。升级完成后，临时文件删了吗？缓存清了吗？网络连接关了吗？我见过一个案例，升级完成后内存没释放，导致系统越来越卡，最后用户只能重启。
在测试脚本中嵌入资源采集点，每100ms采样一次，生成时间序列图。重点关注「升级开始瞬间」和「校验阶段」的峰值。
4.6 核心指标关系图
这五个指标不是孤立的。它们之间的关系，我用一张图来展示：
4.7 指标之间的权衡
你可能会问：这五个指标，是不是越高越好？不一定。举个例子：
- 为了提高成功率，你加了5次重试机制。结果呢？P99耗时从5分钟飙到了30分钟。
- 为了提高中断恢复率，你做了双备份分区。结果呢？存储占用翻倍，低端设备装不下。
- 为了提高异常场景覆盖率，你写了2000个测试用例。结果呢？测试周期从3天变成了3周。
所以，指标之间要平衡。我个人习惯的做法是：先定底线，再优化上限。比如：
- 成功率必须 ≥ 99%，这是红线
- 中断恢复率必须 ≥ 99.9%，这是红线
- 在满足前两条的前提下，P99耗时不超过P50的2倍
- 在满足前三条的前提下，资源消耗尽量低
这样排优先级，测试工作才不会跑偏。