第49章性能测试

课程目录第49章性能测试

49、性能测试：基准测试（Benchmark）、压力测试、稳定性测试、性能回归测试

性能测试这个话题，说实话，很多团队把它当成「上线前跑一遍就完事」的流程。但我做了这么多年系统优化，可以负责任地告诉你——性能测试不是一道菜，而是一整套厨房管理体系。你想想看，如果连菜品的咸淡都没标准，那后面再怎么优化都是瞎忙活。

今天咱们就把这四种测试类型掰开揉碎了讲清楚。我个人习惯把它们分成两个维度：「测什么」和「怎么测」。基准测试告诉你「现在有多快」，压力测试告诉你「极限在哪」，稳定性测试告诉你「能不能扛住」，回归测试告诉你「有没有变差」。四者缺一不可。

  核心观点： 没有基准的优化是盲目的，没有压力的上线是危险的，没有稳定性的发布是赌博，没有回归的迭代是倒退。

一、基准测试（Benchmark）—— 给系统画个「刻度尺」

基准测试，说白了就是给系统性能定个「锚点」。我见过太多团队，上来就优化，优化完说「感觉快了」，但快了多少？不知道。这就像你跑步减肥，不称体重，光凭感觉说「瘦了」——不靠谱。

基准测试的核心目标就两个：

建立基线：记录当前系统的性能数据，作为后续对比的参照
量化对比：用数据说话，而不是凭感觉

在Android系统层面，我们常用的基准测试包括：

测试类型	关注指标	常用工具
CPU基准	运算速度、指令吞吐	Geekbench、SPEC
GPU基准	帧率、渲染延迟	GFXBench、3DMark
内存基准	带宽、延迟、分配速度	MBW、lmbench
存储基准	顺序/随机读写、IOPS	AndroBench、fio
综合基准	整体系统性能	安兔兔、PCMark

我的经验： 基准测试一定要在「干净环境」下跑。我曾经有一次测出来的数据忽高忽低，查了半天，原来是后台有个App在偷偷做数据同步。所以，跑基准前记得关掉所有非必要进程，最好重启一次设备。

二、压力测试（Stress Test）—— 把系统逼到极限

压力测试，就是故意给系统「找麻烦」。你想想看，平时用户可能只是刷刷微信、看看视频，但万一有人同时开10个App、后台跑着下载、前台还在玩大型游戏呢？系统扛不扛得住？

压力测试的核心思路是：不断增加负载，直到系统崩溃或性能出现断崖式下降。这个「断崖点」就是系统的极限。

常见的压力测试场景：

CPU满载：同时启动多个计算密集型任务，观察系统是否卡顿、过热、降频
内存压力：不断分配内存直到触发LMK（Low Memory Killer），观察系统能否优雅回收
IO风暴：同时进行大量文件读写，观察IO调度是否公平、前台App是否受影响
多任务并发：模拟用户同时打开20+个App，观察切换流畅度和后台保活情况

# 一个简单的CPU压力测试脚本（使用stress工具）
# 启动4个CPU密集型进程，持续60秒
stress --cpu 4 --timeout 60

# 同时监控CPU频率和温度
while true; do
  cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
  cat /sys/class/thermal/thermal_zone0/temp
  sleep 1
done

注意： 压力测试不是「跑一次就完事」。我曾经在项目里遇到过一个问题：压力测试跑了30分钟一切正常，但跑到45分钟时突然触发了一个隐藏的内存泄漏。所以，压力测试的时间要足够长，至少覆盖一个完整的使用周期。

三、稳定性测试（Stability Test）—— 看系统能不能「长期作战」

稳定性测试和压力测试的区别在哪？我打个比方：压力测试是「你一口气能做多少个俯卧撑」，稳定性测试是「你能不能连续做30天俯卧撑而不受伤」。说白了，稳定性测试关注的是长时间运行下的可靠性。

在Android系统层面，稳定性测试通常包括：

Monkey测试：随机发送用户事件（点击、滑动、按键等），看系统会不会崩溃
长时间运行测试：让系统持续运行24小时、48小时甚至一周，观察内存泄漏、资源耗尽等问题
异常恢复测试：模拟系统突然断电、网络断开、存储空间满等异常场景，看系统能否优雅恢复

嗯，这里要特别提一下Monkey测试。很多人觉得Monkey就是「乱点一通」，其实不然。好的Monkey测试应该是有策略的：

# 一个更「聪明」的Monkey测试命令
adb shell monkey -p com.example.app \
  --throttle 200 \          # 每次事件间隔200ms，模拟真实操作节奏
  --pct-touch 40 \          # 触摸事件占比40%
  --pct-motion 25 \         # 滑动事件占比25%
  --pct-appswitch 10 \      # App切换事件占比10%
  --pct-anyevent 5 \        # 其他事件占比5%
  -v -v \                   # 详细日志
  100000                    # 发送10万次事件

避坑指南： 我曾经在Monkey测试中发现一个诡异的问题——每次跑到第3万次事件左右，系统就会重启。查了三天，最后发现是一个驱动在特定时序下触发了内核panic。所以，稳定性测试不仅要看「崩没崩」，还要看「什么时候崩」——崩溃的时间点往往藏着线索。

四、性能回归测试（Performance Regression Test）—— 守住优化的「底线」

回归测试，是我个人认为最容易被忽视但又最重要的一环。你想想看，辛辛苦苦优化了一个模块，结果下一个版本因为别人的代码改动，性能又回去了——这种事我见过太多次了。

性能回归测试的核心就是：每次代码变更后，自动跑一遍基准测试，对比结果，如果性能下降超过阈值，就报警。

具体怎么做？我建议这样：

建立性能基线库：把每次发布的性能数据存起来，形成历史曲线
设定阈值：比如「启动时间增加超过5%」或「帧率下降超过3fps」就触发告警
自动化集成：把回归测试集成到CI/CD流水线中，每次提交代码自动触发
分级告警：小波动发邮件通知，大波动直接阻断合并

  关键点： 回归测试的「阈值」不是拍脑袋定的。我习惯先跑10次基准测试，取平均值和标准差，然后以「均值±3σ」作为正常波动范围。超过这个范围的，才认为是真正的回归。

五、四种测试的关系与落地

这四种测试不是孤立的，它们构成了一个完整的性能保障体系。我画了一张图来展示它们之间的关系：

从这张图可以看出，四种测试形成了一个闭环：基准测试提供基线 → 压力测试暴露问题 → 稳定性测试验证修复 → 回归测试守住底线。每次迭代，基线都会更新，系统性能也会逐步提升。

六、落地建议

最后，我给出一些实际落地的建议：

不要追求「完美」的基准测试：基准测试本身也有误差，关键是保持测试环境的一致性。我习惯在同一个设备、同一个系统版本、同一个温度环境下跑。
压力测试要「有目的」：不要为了跑而跑。每次压力测试前，先问自己：「我想验证什么？」是CPU降频策略？还是内存回收机制？
稳定性测试要「有耐心」：有些bug需要跑十几个小时才会出现。我见过一个内存泄漏，跑了8小时才触发——因为那个泄漏和某个定时任务有关。
回归测试要「自动化」：手动跑回归测试，一次两次还行，长期下来根本坚持不住。一定要集成到CI/CD里，让机器替你盯着。

最后提醒一句： 性能测试不是「一次性投入」，而是「持续投入」。你花在测试上的每一分钟，都会在线上少花一个小时去排查问题。这个账，怎么算都划算。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

49、性能测试：基准测试（Benchmark）、压力测试、稳定性测试、性能回归测试

一、基准测试（Benchmark）—— 给系统画个「刻度尺」

二、压力测试（Stress Test）—— 把系统逼到极限

三、稳定性测试（Stability Test）—— 看系统能不能「长期作战」

四、性能回归测试（Performance Regression Test）—— 守住优化的「底线」

五、四种测试的关系与落地

六、落地建议