Android稳定性-46-Android 稳定性测试报告怎么写才有决策价值

稳定性测试报告不是日志包目录，也不是缺陷列表截图，更不是把 Monkey 时长、Crash 数、ANR 数拼在一起的周报。它最终要回答一个版本问题：当前构建能不能继续流转，能不能灰度，能不能量产，不能的话阻断在哪里，能的话还带着哪些风险。报告写不出这个判断，测试做得再辛苦，也很难在评审会上产生决策价值。

Android 稳定性报告尤其容易写散。因为输入材料太多：长稳结果、专项结果、Monkey、业务遍历、功耗、温升、内存、I/O、重启、ANR、Crash、Native Crash、Watchdog、Top Issue、设备离线、脚本失败、日志缺失、修复验证。每一块都有数据，但评审会关心的不是数据总量，而是这些数据能否支持版本结论。

这篇文章讲稳定性测试报告该怎么组织。重点是报告结构、风险分级、证据摘要、指标口径、完整案例、命令、表格、常见误判、检查清单、输出物模板和小结。写报告不是文字工作，它是稳定性测试最后一次把事实、风险和行动项对齐的工程动作。

一、报告读者不同，信息层级也不同

稳定性报告至少有四类读者。项目负责人关心能不能按计划发布，风险是否可控。研发负责人关心哪些模块需要修，修复优先级是什么。测试负责人关心覆盖是否足够，结论是否可信。管理者关心质量趋势、资源投入和发布建议。把所有日志细节放在第一页，会让每个人都找不到自己需要的信息。

报告应该分层。第一页给版本结论和阻断风险；第二层给指标概览、覆盖范围和趋势；第三层给 Top Issue、根因进展和修复验证；最后才是详细证据、命令输出、日志路径和附件。这样读者可以按需要下钻，而不是被迫在几十页材料里找结论。

报告语言也要区分事实和判断。事实是“20 台设备运行 72 小时，3 台出现 system_server Watchdog，发生在版本 V2026.04.02”。判断是“该问题影响整机可用性，复现率 15%，当前无修复，不建议准入通过”。很多报告把事实写很多，判断写得很弱，评审会就会继续追问。

如果测试负责人对结论没有把握，也要明确写出不确定性来自哪里：日志缺失、复现不足、设备样本少、修复未合入、基线数据不足。模糊不是问题，隐藏模糊才是问题。

二、报告首页应该回答的六个问题

稳定性报告首页建议只放六个问题的答案。第一，测了哪个版本，覆盖哪些设备和场景。第二，测试完成度是多少，有没有无效样本。第三，关键指标相对基线是改善、持平还是退化。第四，当前阻断项有哪些。第五，遗留风险有哪些，是否有规避或灰度观察方案。第六，测试建议是什么。

这六个问题决定报告是否能用于决策。比如“长稳通过率 95%”听起来不错，但如果失败的 5% 是 Watchdog 重启，结论可能仍然是阻断；“Crash 数 0”也不代表稳定，如果功耗待机掉电退化三倍，同样可能影响灰度。

首页不要堆命令输出。可以用一个摘要表承载核心信息：

项目	结果	基线对比	结论
长稳 72h	20 台完成 18 台，2 台 Watchdog	基线 0 台	阻断
Monkey 12h	Crash 0，ANR 1	持平	通过但跟踪
功耗待机 8h	掉电 11%	基线 4%	阻断
相机专项	录像保存失败 3/50	新增	高风险
设备离线	1 台 USB 断连	环境问题	样本剔除

摘要表后面接一句清楚建议：当前版本不建议进入灰度，需修复 Watchdog 和待机功耗退化，并完成同条件复测。这样的首页比二十页截图更有力量。

三、指标口径要写得能复算

报告里的每个指标都要能复算。Crash 率的分母是什么，是设备数、小时数、用例次数还是用户会话？ANR 是系统 ANR、应用 ANR，还是测试脚本超时？长稳通过率是否剔除了设备离线和脚本异常？功耗掉电是系统电量百分比还是电源仪？温升取哪个传感器？帧率统计是平均 FPS 还是 P95 帧耗时？

口径不清会导致评审争议。研发可能认为某台设备 USB 断连不应计入失败，测试可能认为它导致场景中断必须计入风险。项目可能看到“通过率 90%”以为可以放行，但实际失败项全是重启。报告要把口径写在指标旁边，而不是放到没人看的附录。

下面这张口径表可以作为稳定性报告固定章节：

指标	分母	失败定义	剔除规则	数据来源
长稳通过率	有效设备数	Crash、ANR、重启、卡死、关键用例失败	明确硬件/线缆故障可剔除	平台任务记录、日志
Crash 数	进程崩溃事件	Java/Native 崩溃	预置已知三方崩溃单列	logcat、tombstone
ANR 数	ANR 事件	系统生成 ANR	脚本等待超时不直接计入	traces、dropbox
重启数	非预期重启	kernel panic、watchdog、userspace reboot	手动重启剔除	pstore、reboot reason
功耗退化	同条件测试轮次	超过基线阈值	条件不一致重测	batterystats、电源仪

能复算的报告更容易被信任。即使结论严厉，研发也知道如何验证；即使结论放行，项目也知道风险边界。

四、覆盖范围要写真实，不要写漂亮

很多报告喜欢写“已完成全量稳定性测试”，但真正追问时才发现某些设备没跑满，某些场景跳过，某些日志缺失，某些失败样本被算作环境问题。覆盖范围写得漂亮但不真实，会直接伤害报告可信度。

覆盖范围要包括设备、版本、场景、时长、脚本、数据集、网络、账号、特殊配置。比如 20 台设备跑 72 小时，其中 18 台有效，1 台 USB 断连，1 台刷机失败；相机专项覆盖拍照、录像、前后台切换、低存储，但没有覆盖弱网云同步；功耗专项覆盖灭屏待机和视频播放，没有覆盖导航。

报告里可以用覆盖矩阵：

场景	设备数	时长/次数	有效样本	未覆盖原因	结论
72h 长稳	20	1440 设备小时	18 台	2 台环境无效	有阻断
Monkey	10	每台 12h	10 台	无	通过
相机专项	5	50 轮	5 台	无	高风险
灭屏待机	6	8h	6 台	无	阻断
弱网导航	0	0	0	实验室排期冲突	未评估

“未覆盖”不是丢脸的信息。它能帮助版本评审决定是否补测、灰度观察还是接受风险。真正危险的是未覆盖却写成已通过。

五、Top Issue 要按版本风险排序

Top Issue 不是缺陷系统里优先级最高的前几个单子，而是对版本决策影响最大的风险列表。一个偶发 UI 文案崩溃可能优先级高，但不一定阻断；一个 2/20 的 Watchdog 重启可能复现率不高，却足以阻断准入。报告要按影响范围、严重程度、复现概率、修复状态、验证状态和规避方案排序。

建议 Top Issue 表包含这些字段：

ID	问题	严重程度	复现	影响范围	当前状态	版本建议
STAB-1024	system_server Watchdog	S0	3/20	整机不可用	定位中	阻断
STAB-1031	灭屏待机掉电 11%	S1	6/6	续航退化	修复待验证	阻断
STAB-1040	消息列表滑动掉帧	S2	8/10	高频路径	已修复	回归中
STAB-1046	相机保存失败	S1	3/50	相机核心场景	有规避	灰度限制

每个 Top Issue 后面都要有简短证据摘要，而不是只贴链接。评审者不一定会点开每个缺陷单，报告要让他在一页内知道为什么这个问题排在这里。

Top Issue 还要维护变化。上一轮阻断项是否关闭，新问题是否新增，修复是否引入回归，风险是否从阻断降为灰度观察。没有变化信息，报告就无法呈现版本质量是否收敛。

六、完整案例：一份报告如何改变发布结论

某项目原计划周五进入 5% 灰度。周三晚上稳定性测试完成后，初版报告只写了“长稳完成 90%，Crash 0，ANR 2，问题跟踪中”，项目经理倾向按计划灰度。测试负责人复查原始数据后发现，这个结论太粗：两台未完成设备并不是普通失败，其中一台发生 Watchdog 重启，另一台在低存储场景 system_server 无响应；同时功耗专项显示灭屏 8 小时掉电从基线 4% 退化到 11%。

报告被重写成决策版。首页明确写：当前版本不建议灰度，理由是两个阻断风险未关闭。第一，Watchdog 重启 1/20，pstore 指向 system_server 主线程等待，根因未确认。第二，灭屏待机掉电 6/6 超阈值，batterystats 指向后台同步持锁，修复未合入。Crash 0 和大部分长稳完成被保留为事实，但不再作为放行结论。

重写后的报告还补了覆盖矩阵：20 台长稳中 18 台有效，2 台环境问题剔除；Watchdog 发生在有效样本中，不可剔除。功耗专项条件写清楚：25°C，Wi-Fi，插 SIM，刷机静置 2 小时，基线同台对比。Top Issue 表给出责任 owner、下一步动作和复测要求。

发布评审最终决定推迟灰度 2 天。研发当天修复后台同步持锁，系统团队继续排查 Watchdog；测试完成 24 小时冒烟和 8 小时待机复测后，功耗恢复，Watchdog 未复现，但因样本时长不足，灰度从 5% 改为 1%，并加入重启率和待机掉电监控。这个案例说明，报告不是形式文档，它会直接改变发布策略。

七、命令和证据包要可追溯

报告正文不需要塞满命令输出，但证据包必须可追溯。每个结论都应该能找到原始日志、采集命令、设备编号、时间窗口和分析脚本版本。否则修复验证时很难比较，复盘时也无法确认当时判断是否合理。

建议证据目录结构如下：

stability_report_V2026.04.02/
  summary.md
  devices.csv
  metrics/
    longrun_result.csv
    power_standby.csv
    jank_framestats.csv
  issues/
    STAB-1024_watchdog/
      timeline.md
      logcat.txt
      bugreport.zip
      pstore/
    STAB-1031_power/
      batterystats.txt
      temp_curve.csv
      condition.md
  scripts/
    collect_version.txt
    parser_version.txt

常用采集命令也可以放在报告附录，方便复测同学复用。

adb shell getprop ro.build.fingerprint
adb shell getprop ro.boot.bootreason
adb shell logcat -b all -v threadtime -d
adb bugreport bugreport.zip
adb shell dumpsys batterystats
adb shell dumpsys meminfo
adb shell dumpsys cpuinfo
adb shell ls -lt /data/anr /data/tombstones /data/system/dropbox 2>/dev/null

证据包命名要避免“新建文件夹”“日志1”这种不可追溯名称。推荐使用版本、设备、场景、时间和问题 ID。报告里引用证据时写相对路径，评审后也能查到。

八、常见误判

误判	后果	修正方式
Crash 0 就建议放行	忽略重启、功耗、卡死、温升	首页按风险而不是单指标下结论
把环境失败全部剔除	通过率虚高	写明剔除理由和证据
缺陷列表等于报告	没有版本判断	增加风险摘要和发布建议
只写当前结果不写基线	无法判断退化	固定同条件对比
附件很多但正文没证据	评审无法快速判断	每个结论写 2 到 4 条关键证据
遗留问题没有 owner 和日期	风险无法闭环	给出责任人、动作和验证条件

这些误判会让报告看起来完整，实际无法用于决策。稳定性报告最重要的不是页数，而是结论、证据和行动项之间是否闭合。

九、检查清单

• 首页是否明确写出发布建议。
• 是否列出版本、设备、场景、时长和有效样本。
• 是否说明指标口径、剔除规则和数据来源。
• 是否给出基线对比和趋势变化。
• 是否按版本风险排序 Top Issue。
• 每个阻断项是否有证据摘要、owner、下一步和复测要求。
• 遗留风险是否有灰度监控或规避方案。
• 未覆盖场景是否被显式列出。
• 证据包路径是否可追溯。
• 报告结论是否能被另一名同学按原始数据复算。

这份清单适合在报告发出前自查。尤其是“未覆盖场景”和“剔除规则”，很多争议都来自这两个地方。

十、输出物模板

# Android 稳定性测试报告

版本：V2026.04.02
测试周期：2026-04-01 10:00 ~ 2026-04-02 18:00
测试负责人：
报告结论：不建议进入灰度

## 1. 决策摘要
阻断项：
  1. STAB-1024 system_server Watchdog，3/20，根因未确认。
  2. STAB-1031 灭屏待机掉电 11%，6/6，修复待验证。
放行条件：
  Watchdog 修复或 72h 同条件无复现；功耗修复后 3 轮 8h 待机达标。

## 2. 覆盖范围
设备、场景、时长、有效样本、未覆盖项。

## 3. 指标概览
长稳、Crash、ANR、重启、功耗、温升、帧率、离线率。

## 4. Top Issue
问题、影响、证据、owner、状态、下一步。

## 5. 遗留风险
可接受风险、灰度监控、回滚条件。

## 6. 附件
证据包路径、日志索引、采集命令、原始 CSV。

模板只是骨架，不能机械填空。每个版本的风险重点不同，报告篇幅也应该跟着变。没有阻断项时，重点写覆盖和趋势；阻断项很多时，重点写排序和行动；灰度阶段，重点写线上监控和回滚条件。

十一、小结

十二、报告里的遗留风险要可管理

很多版本最终都不是零风险发布。稳定性报告要把遗留风险写成可管理对象，而不是简单列几个“已知问题”。可管理的遗留风险至少包含影响范围、触发条件、用户后果、当前规避、线上监控、回滚条件和下一版本计划。缺少这些字段，所谓遗留只是把问题推迟到线上。

例如“相机偶发保存失败”不能作为遗留描述。更合适的写法是：低存储剩余 800 MB 以下，连续录像 20 分钟后保存失败 2/50；普通存储空间未复现；当前规避是低存储提示提前到 2 GB 并禁止继续录像；灰度监控保存失败率和低存储用户占比；若失败率超过 0.3% 或出现数据丢失投诉则回滚。这样的风险虽然未必完全修完，但项目能判断是否接受。

遗留风险还要和 owner 绑定。报告里要写清楚谁负责线上监控，谁负责下一版本修复，谁负责灰度期间每日回看，谁有权触发回滚。稳定性风险如果没有人每天看，很快就会从“可接受”变成“没人负责”。

十三、修复验证章节不能只写通过

稳定性报告里最容易被写薄的是修复验证。很多报告只写“问题已修复，复测通过”，但没有说明复测条件是否覆盖原场景、样本是否足够、是否验证副作用、是否观察足够长时间。对于重启、Watchdog、功耗、长稳后期卡顿这类问题，短时间冒烟通过不能等同于风险关闭。

修复验证建议写四件事。第一，修复内容摘要，不需要贴代码，但要说明策略变化。第二，复测覆盖，包括设备数、时长、场景、数据量和环境。第三，结果对比，包括修复前后关键指标。第四，残余风险，比如样本不足、只验证了一个型号、线上仍需观察。这样写既能支持关闭问题，也能保留必要谨慎。

如果修复还没合入，报告要把“待验证”单列，不要混在已关闭问题里。待验证问题对版本的影响取决于合入时间和复测成本。比如一个功耗修复需要 3 轮 8 小时待机验证，今天晚上才合入，就不应该在明早准入报告里写成已解决。

十四、不同阶段的报告重点不同

方案评审阶段的报告重点是覆盖设计和风险预案，准入阶段的报告重点是阻断项和覆盖完成度，灰度阶段的报告重点是线上指标和回滚条件，量产复盘阶段的报告重点是问题闭环和预防措施。用同一套模板写所有阶段，容易出现信息错位。

准入前，报告应该更严厉：样本不足、阻断项未关、关键场景未测，都要明确影响发布。灰度中，报告应该更关注趋势：崩溃率、重启率、功耗投诉、核心路径失败率是否在阈值内。量产后，报告要沉淀资产：哪些问题逃逸，哪些门禁缺失，哪些工具需要补。

因此模板只是起点。测试负责人要根据阶段删减内容，而不是机械填满所有章节。读者在准入会上最想看到的是能不能放行，在复盘会上才需要完整展开原因和改进。

十五、报告质量也需要复盘

稳定性问题复盘时，团队通常会复盘代码根因，却很少复盘报告质量。实际上很多发布风险不是完全没测到，而是测到了但报告没有写清楚，或者写清楚了但没有形成行动。报告复盘可以问几个问题：阻断风险是否提前出现在日报里，最终报告是否明确建议，评审是否理解风险，遗留项是否有监控，修复验证是否足够。

如果一个问题在线上爆发，而线下报告里已经有弱信号，就要检查当时为什么没有升级。是指标阈值不合理，还是报告排序不突出，还是 owner 没有动作，还是项目接受风险时没有回滚条件。把这些问题沉淀下来，下一版报告就会更有力量。

报告本身也可以平台化。指标自动生成、问题单自动关联、证据包自动索引、Top Issue 状态自动同步、遗留风险自动提醒，都能减少人工错误。但平台只能提供材料，最终的风险判断仍然需要测试负责人负责。

十六、报告评审会上怎么讲

报告写得好，还要讲得清楚。稳定性评审会通常时间有限，测试负责人不应该从第一页逐字念到最后一页，而应该先讲结论，再讲阻断项，再讲是否有放行条件。建议开场三分钟完成：当前版本建议、主要风险、需要会议决策的事项。后面的数据只在有人追问时展开。

讲阻断项时，要避免陷入技术细节过深。比如 Watchdog 问题可以先讲影响：整机不可用，3/20 复现，根因未确认，暂无规避，因此建议阻断。再讲证据：pstore、traces、时间窗口、复测状态。最后讲需要谁做什么：系统服务 owner 今天给定位结论，测试保留现场并补 24 小时复测。这样的顺序比先贴一页堆栈更适合评审。

如果报告建议条件通过，也要把条件讲成可执行条款。比如“允许 1% 灰度，但必须满足三个条件：修复包进入 rc3，完成 10 台 24 小时无重启，灰度监控重启率超过 0.05% 立即暂停”。没有条件的“建议谨慎灰度”没有实际约束力。

评审会结束后，报告要更新会议结论。哪些风险被接受，接受人是谁，灰度比例是多少，回滚阈值是什么，哪些问题改为下版本修复，都要写回报告或会议纪要。否则后续复盘时很难分清是测试没有提示，还是项目接受了风险。

十七、面向管理层的摘要不要技术化过度

稳定性报告有时需要给管理层或跨部门同步。这个版本的摘要不应充满 traces、pstore、wakelock 这些细节，而要翻译成业务影响：是否会重启，是否会明显耗电，是否影响核心场景，是否需要推迟节点，是否有回滚方案。技术证据仍然保留在正文和附件里，但摘要要让非技术读者做判断。

例如“system_server Watchdog 3/20”可以写成“整机无响应并自动重启，当前样本复现率 15%，尚无修复，不建议发布”；“partial wakelock 4h12m”可以写成“灭屏后后台服务持续唤醒，待机掉电约为基线 3 倍，预计影响续航口碑”。这样并不是降低专业性，而是把专业证据转成决策语言。

管理层摘要还要避免过度乐观。Crash 率低、用例通过率高，如果同时存在重启和功耗阻断，就不能写“整体质量良好”。可以写“基础功能稳定，但存在两个发布阻断风险”。这样的表达更准确，也能避免项目只截取好看的指标。

十八、报告中的图表要少而准

图表不是越多越好。稳定性报告里最有价值的图表通常只有几类：版本指标趋势、覆盖矩阵、Top Issue 状态、关键问题时间线、修复前后对比。每张图都应该服务一个判断。如果一张图不能改变读者对风险的理解，就可以放到附件。

趋势图要标出版本节点和修复点。比如待机掉电曲线中标出后台同步修复合入时间，Watchdog 趋势中标出系统服务补丁合入时间，帧率趋势中标出数据库优化版本。否则读者只能看到数字变化，看不到变化与工程动作的关系。

覆盖图要标出无效样本。很多报告只画完成百分比，不画日志缺失、设备离线和脚本失败，结果看起来覆盖很满，实际上有效证据不足。图表要诚实反映质量，不要只追求好看。

关键问题时间线可以一页讲清楚复杂问题：用户动作、资源变化、异常日志、线程等待、系统后果、修复验证。对于跨团队争议大的问题，这类图比长篇文字更有效。

十九、报告发出后的变更管理

稳定性报告发出以后，版本状态仍可能变化。修复包可能合入，复测可能失败，灰度比例可能调整，某个遗留风险可能被项目接受。报告如果发出后就不再更新，很快会和真实状态脱节。建议报告保留版本号或更新时间，每次关键变化后追加变更记录。

变更记录可以很简单：时间、变化内容、影响结论、责任人。例如“2026-04-02 22:30，STAB-1031 功耗修复进入 rc3，待 3 轮 8h 复测，发布建议仍为不通过”；“2026-04-03 11:00，Watchdog 复测 10 台 24h 未复现，但原问题发生在 48h 后，建议继续观察”。这种记录能避免多人手里拿着不同版本的结论。

如果报告结论从阻断改为条件通过，必须写明改变依据。是根因确认了，修复验证完成了，还是项目接受风险了？这三种含义完全不同。根因确认但未修复，不能等同于通过；项目接受风险，也不能写成质量已达标。报告要忠实记录决策依据。

二十、从报告反推测试方案

一份成熟的稳定性报告，应该能反推下一轮测试方案。哪些指标争议大，说明口径需要前置；哪些证据缺失，说明采集脚本要补；哪些问题到最后才发现，说明日报阈值不够敏感；哪些修复验证耗时长，说明准入排期要提前预留。

例如本轮报告里功耗风险花了两天才确认，是因为没有日常待机基线，下一轮就应该把 8 小时待机放进 nightly；本轮 Watchdog 缺少 pstore，是因为设备重启后继续跑覆盖了现场，下一轮就要让平台在重启后自动冻结任务；本轮卡顿争议大，是因为只有视频没有 Perfetto，下一轮就要为高频路径加轻量 trace。

报告不是测试工作的终点。它应该产出三类后续资产：测试方案调整、平台能力需求、版本准入规则更新。这样每次稳定性问题都能让体系变强，而不是下个版本重新踩同一个坑。

二十一、报告中的责任边界

稳定性报告要敢于写责任边界，但不要把责任边界写成甩锅。比如“当前证据指向后台同步持锁，Power 模块负责修复策略；测试负责提供同条件复测和灰度指标；项目负责决定是否推迟灰度”。这种边界能帮助协作。相反，如果只写“研发分析”，所有模块都可能认为不是自己。

责任边界还包括测试自己的问题。设备离线、日志缺失、脚本误判、样本不足，都应该在报告中如实说明。承认测试侧限制不会削弱报告可信度，反而能让评审知道哪些结论可靠，哪些结论需要补测。稳定性报告不是为了证明测试无错，而是为了让版本判断尽量接近事实。

当多个模块共同造成风险时，报告要写组合关系。比如低存储卡死既有产品 debug 日志过量，也有测试证据目录无限增长，还有系统低存储保护不足。只写其中一个 owner，会导致修复不完整。组合风险要拆成多个行动项，并明确谁负责总体验证。

报告还要写清楚“不做什么”。例如当前版本不再扩大 Monkey 样本，而是优先验证 Watchdog；不再追加新专项，而是保留设备复测功耗；不建议在根因未明前刷掉问题设备。排除项能减少资源被临时打散，也能让项目理解测试安排不是随意取舍。

这些取舍要写进报告正文，而不是只留在会议口头结论里，后续换人接手时才不会重新争论。

对发布节奏紧张的项目来说，清楚写出取舍本身就是风险控制的一部分。

这点很关键。

稳定性测试报告的价值不在于证明测试做了很多事，而在于帮助团队做正确的版本选择。它要把覆盖、指标、趋势、问题、证据和建议组织成一个清楚的决策链。

写报告时始终记住三点：事实要能复算，风险要能排序，建议要能执行。做到这三点，报告就不会只是项目归档材料，而会成为准入、灰度和量产评审里真正有用的质量输入。