Android稳定性-21-Monkey 工具二次封装：参数模板、异常捕获与复现命令

Monkey 的价值不是“随机乱点”，而是在可控制的随机输入下暴露生命周期、窗口、权限、焦点和异常恢复问题。二次封装的目标也不是把命令包得看不懂，而是让参数模板可复用、异常捕获可解释、复现命令可复制。
这篇文章从稳定性测试视角展开，不把它写成工具说明书，而是把问题背景、测试位置、平台设计、命令入口、案例复盘和输出模板放在同一条链路里。
读完后，应该能直接拿去设计任务、评审失败、补齐日志和提交缺陷。

一、具体问题背景：先把这类问题放到稳定性语境里

原生命令适合临时验证，但不适合团队长期使用。缺少模板时，不同同学会用不同 seed、throttle、包名和忽略开关，结果很难比较。
Monkey 失败最怕只留下最后几行日志。真正有价值的是 seed、事件数、执行阶段、崩溃前窗口、ANR trace、屏幕截图和完整复现命令。
二次封装要尊重 Monkey 的边界：它发现稳定性问题，不验证复杂业务正确性。

从稳定性视角看，这里要先回答三个问题：

• 这个能力解决的是准入、执行、监控、恢复还是归档。
• 它的失败是否会污染后续任务。
• 它留下的证据能不能支持别人复盘。

二、它在稳定性测试中的位置

建议把它放在下面这些测试位置：

• 新版本冒烟：小事件数快速扫 crash、权限弹窗和启动问题。
• 夜间长稳：固定 seed 策略加长事件数，配合资源监控。
• 专项回归：针对某包、某页面或某权限状态复跑。
• 问题复现：保留原 seed、事件配比、throttle 和前置状态。

位置定义清楚后，测试目标才不会漂移。比如准入任务追求快速发现阻塞问题，长稳任务追求长时间趋势和偶现故障，回归任务追求同条件复现。

三、测试对象和边界要先写清楚

Monkey 二次封装 的边界必须在任务启动前写清楚。边界不是一句“跑稳定性”，而是明确哪些现象归产品问题，哪些现象归环境问题，哪些现象只作为观察信号。

建议把测试对象拆成四层：

• 被测版本：system、vendor、boot、apk、配置文件和测试数据。
• 被测设备：型号、内存规格、屏幕规格、网络形态、root 状态和实验室机位。
• 被测动作：启动、切换、输入、压力、恢复、采样。
• 判定规则：通过、失败、阻塞、环境异常、需人工复核。

对于 Monkey 二次封装，最危险的不是少跑一个命令，而是没有定义“这个命令的结果如何影响结论”。例如同样是超时，可能代表产品卡死，也可能代表设备离线、host 磁盘阻塞或网络不可用。脚本必须把这些状态分开记录。

落地时可以给每个任务增加 scope.yaml，里面写清楚目标、前置条件、排除项和失败等级。这样后续接入平台、复跑和评审时不会反复解释同一个问题。

四、工具或平台的最小设计

Monkey 二次封装 的平台设计要从最小闭环开始，不要第一天就追求完整大屏。一个可用闭环至少包含采集层、执行层、判定层和归档层。

最小设计可以这样拆：

• Agent：运行在 host 上，负责 adb、日志采集、心跳和本地缓存。
• Runner：读取任务配置，控制阶段流转，处理超时和中断。
• Collector：按失败类型抓取证据，不参与业务判断。
• Analyzer：从日志和结构化结果中提取失败类型。
• Reporter：生成 Markdown、JSON 和可提交缺陷摘要。

平台内部要避免隐式状态。每个阶段都要能从磁盘上的 manifest 恢复：任务参数、设备 serial、开始时间、当前阶段、已采集证据和最后一次心跳。长稳任务经常跨夜，进程重启或 host 短暂异常不应该让整轮结果完全丢失。

如果团队规模较小，可以先不做中心服务，但目录结构和 JSON schema 必须先稳定下来。后面从本地脚本升级到 Web 平台时，成本主要在界面和调度，不会重新定义证据格式。

五、任务生命周期如何组织

建议把 Monkey 二次封装 的每次执行都拆成固定生命周期：precheck、prepare、execute、monitor、collect、recover、report。这些阶段不是形式主义，而是为了让失败发生时可以准确落点。

各阶段职责如下：

• precheck：确认设备、版本、网络、供电、磁盘空间和 adb 状态。
• prepare：安装包、授权、清日志、设置系统状态和写入任务参数。
• execute：执行核心测试动作，只做必要控制。
• monitor：采集心跳、异常关键字、资源和环境指标。
• collect：失败或结束后固化证据。
• recover：按策略恢复设备或隔离设备。
• report：输出结构化结果和人工可读报告。

稳定性脚本最容易出问题的地方，是在 execute 里顺手做了采集和恢复，在 collect 里又顺手改了设备状态。这样一旦失败，现场被谁改变过很难说清。阶段拆开后，日志会稍微多一些，但复盘成本会明显下降。

每个阶段都应记录开始时间、结束时间、耗时、输入、输出和状态。即使阶段失败，也要写出阶段级结果，而不是直接让脚本退出。

六、关键命令和日志入口

下面这些命令是排查和平台封装时最常用的入口。实际使用时要统一增加 serial、timeout、返回码记录和输出文件路径。

adb -s <serial> shell monkey -p <package> --throttle 300 -s 10086 -v -v 50000
adb -s <serial> shell monkey -p <package> --pct-touch 45 --pct-motion 20 --pct-nav 5 --pct-majornav 10 --pct-appswitch 5 --pct-syskeys 0 --throttle 200 -s <seed> -v 100000
adb -s <serial> logcat -b all -v threadtime
adb -s <serial> shell dumpsys activity top
adb -s <serial> shell dumpsys window windows
adb -s <serial> shell cat /data/anr/traces.txt
adb -s <serial> bugreport ./bugreport-monkey.zip

命令输出不要只打印在终端里。每条关键命令都应该保存 stdout、stderr、exit code 和耗时，便于后续判断是设备异常、命令异常还是产品异常。

七、结果目录和证据归档

证据归档建议至少包含这些文件或目录：

• monkey_stdout.txt：Monkey 原始输出，包含 seed、event count、crash/ANR 提示。
• logcat_all.txt：从任务开始到失败后的完整日志。
• anr_traces.txt：ANR 时主线程和关键线程堆栈。
• window_state.txt：失败时焦点窗口、当前 Activity、输入焦点。
• reproduce.sh：封装后的最小复现命令。

日志入口要和报告中的结论互相引用。报告里写“发生 ANR”，就必须能跳到对应 logcat、traces、时间点和设备状态。

八、表格化拆解核心差异

模板	适用场景	关键参数
smoke	版本冒烟	1000 到 5000 事件、较大 throttle、快速失败
nightly	夜间长稳	50000 以上事件、固定 seed、完整日志
stress	输入压力	低 throttle、提高 touch/motion 比例
navigation	页面切换	提高 app switch 和 major nav，禁用 syskeys
regression	问题回归	复用原 seed、原事件数、原前置状态

表格的意义是帮助评审快速判断职责边界。稳定性结论经常跨 App、Framework、vendor、环境和脚本，表格化拆解能减少口头争论。

九、完整案例：从现象到结论

某版本 Monkey 8 万事件后出现 ANR。原始报告只有“ANR in com.demo”。封装后重新执行同 seed，任务在失败时抓到 dumpsys window 显示权限弹窗覆盖目标 Activity，logcat 中 ActivityTaskManager 正在频繁切换前后台，traces 显示主线程等待同步初始化。最终确认不是 Monkey 随机性问题，而是应用在权限弹窗返回后重复初始化资源导致主线程锁等待。复现命令固定 seed 后三次复现两次，满足提交缺陷条件。

这个案例的关键不在于最后归因，而在于证据链完整：现象、时间线、设备状态、日志入口、复现条件和排除项都能对上。稳定性问题只要缺少其中一环，就容易退回“偶现待观察”。

十、常见误判和排除顺序

常见误判包括：

• seed 相同就一定复现：前置状态、版本、权限、数据、温度和网络也必须一致。
• –ignore-crashes 可以提高稳定性：它只会让任务继续跑，不能让 crash 不存在。
• 事件数越大越好：没有阶段日志和资源监控时，超大事件数会降低定位效率。
• 看到 ANR 就一定是 App 问题：输入系统、窗口焦点、系统负载也可能导致应用无响应。

排除顺序建议从环境和脚本开始，再看产品日志。这样不是降低产品问题优先级，而是避免把不可复现的环境噪声提交给开发。

十一、检查清单

执行前和提交报告前，可以逐项检查：

• 每次执行记录 seed、事件数、throttle、pct 参数和目标包。
• 执行前固定前置状态：清数据或保留数据必须明确。
• 失败时自动停止继续注入，先采集现场。
• 复现命令不依赖平台内部变量，开发能直接运行。
• 模板参数有版本管理，报告引用模板版本。
• 忽略 crash/timeout/security-exception 的开关必须显式写入报告。

检查清单最好放进仓库，跟随脚本一起评审。只放在个人笔记里的清单，很快会和实际平台脱节。

十二、输出物模板

建议输出物模板如下：

Monkey 输出物：config.yaml、monkey_stdout.txt、logcat_all.txt、failure_summary.md、reproduce.sh、artifacts_index.json、screen.png、dumpsys_activity.txt、dumpsys_window.txt、anr_traces.txt。

模板字段可以按团队情况扩展，但不要删除版本、设备、任务、时间、判定、证据和复现方式这些核心字段。

十三、和其他稳定性能力的配合

Monkey 二次封装 不应该单独存在。它通常要和 Monkey、UI Automator、资源监控、无人值守环境、兼容性准入和缺陷管理配合。

典型组合方式：

• Monkey 负责随机输入压力，资源监控负责解释失败前系统状态。
• UI Automator 负责进入业务场景和恢复页面，底层工具链负责采集证据。
• 多设备调度负责扩大样本，结果归档负责避免证据丢失。
• CTS/VTS 负责确认基础契约，长稳任务负责验证真实使用时序。
• 无人值守环境负责区分产品失败和供电、网络、散热问题。

组合时要注意一个原则：每个工具只做自己擅长的事。不要让 UI 自动化承担资源分析，不要让资源采样脚本决定业务成败，也不要让调度器直接解释 crash 根因。职责清楚后，平台才容易扩展。

报告里建议保留“关联能力”小节，列出本次任务是否启用了资源监控、环境监控、兼容性准入和自动恢复。这个信息对复盘非常关键。

十四、落地时的分阶段路线

落地 Monkey 二次封装 可以分三阶段。

第一阶段是脚本可用：

• 固定目录结构。
• 固定命令封装。
• 固定 result.json。
• 每次失败能留下最小证据。

第二阶段是批量可靠：

• 多设备并发不互相覆盖日志。
• 任务有超时和心跳。
• 失败能自动分类为产品、环境、脚本和未知。
• 报告能按版本、设备和任务聚合。

第三阶段是平台治理：

• 指标趋势可查询。
• 历史失败可对比。
• 缺陷提交有模板。
• 设备健康度参与调度。
• 高风险模块有准入门禁。

不要跳过第一阶段直接做第三阶段。没有稳定的本地证据结构，平台只会把混乱放大。

十五、评审口径和缺陷提交标准

评审 Monkey 二次封装 的结论时，建议采用固定口径。缺陷提交不能只写现象，要包含触发条件、影响范围、证据链和复现方式。

一个问题达到提交标准，至少满足下面条件之一：

• 同一版本同一任务可复现，或多设备出现同类异常。
• 有明确 crash、ANR、tombstone、watchdog、kernel panic 或进程异常重启证据。
• 资源趋势显示持续恶化，并和业务失败时间对齐。
• CTS/VTS 或系统接口用例能把问题收敛到具体契约。
• 环境监控排除了供电、网络、散热和 host 异常。

缺陷描述建议使用“现象 + 证据 + 判断 + 复现命令”的顺序。不要先写猜测根因，也不要把多个不相关失败塞进一个问题单。稳定性问题本来就复杂，提交时更要让信息结构简单。

十六、小结

Monkey 二次封装 的核心不是工具名字，而是工程闭环。稳定性测试真正要交付的不是一串命令输出，而是可信的结论：在什么版本、什么设备、什么场景、什么环境下，发生了什么问题，证据在哪里，下一步应该怎么复现或排除。

如果只能记住三点，可以记住：

• 先定义边界，再执行任务。
• 先固化证据，再恢复现场。
• 先区分环境和产品，再提交缺陷。

做到这三点，Monkey 二次封装 才能从个人经验变成团队能力。

十七、附录：建议的目录结构

artifacts/
  <run_id>/
    manifest.json
    summary.md
    devices/
      <serial>/
        device.json
        task.log
        adb.log
        logcat_all.txt
        dumpsys/
        screenshots/
        result.json

这个目录结构的重点是每台设备独立、每个 run 独立、原始证据和汇总报告分开。只要目录结构稳定，后续接入数据库或对象存储会简单很多。

十八、附录：result.json 示例

{
  "run_id": "run_20260217_203000",
  "serial": "R58N0000000",
  "topic": "Monkey 二次封装",
  "status": "failed",
  "failure_type": "product_or_system",
  "first_error_time": "2026-02-17T23:18:42+08:00",
  "evidence": ["logcat_all.txt", "bugreport.zip", "screen.png"],
  "reproduce_command": "bash run_task.sh --from result.json"
}

JSON 示例不是为了限制实现语言，而是为了让平台、脚本和报告共享同一套事实。Markdown 写给人看，JSON 写给系统处理，两者都需要。

十九、场景矩阵怎么设计

Monkey 封装 的场景矩阵要覆盖正常路径、压力路径、异常路径和恢复路径。矩阵不是为了凑用例数量，而是为了让每个失败都能回到明确的场景坐标。

• 场景 01：围绕 seed 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 01 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 01 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 02：围绕 throttle 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 02 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 02 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 03：围绕 event count 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 03 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 03 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 04：围绕 pct-touch 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 04 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 04 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 05：围绕 pct-motion 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 05 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 05 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 06：围绕 ignore-crashes 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 06 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 06 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 07：围绕 monkey stdout 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 07 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 07 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 08：围绕 reproduce.sh 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 08 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 08 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。

二十、关键字段命名建议

字段命名稳定，比字段数量更重要。命名一旦进入脚本、报告、数据库和缺陷平台，就不要频繁变化。

• run_id：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。
• task_id：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。
• serial：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。
• build_fingerprint：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。
• device_model：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。
• lab_slot：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。
• stage：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。
• start_time：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。
• end_time：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。
• status：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。
• failure_type：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。
• evidence_path：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。
• reproduce_command：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。
• owner：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。
• retry_of：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。
• environment_status：用于把 Monkey 封装 的一次执行和后续复盘连接起来，必须在 JSON 和 Markdown 中保持同名。

二十一、日志关键字和触发动作

关键字不能只做字符串匹配，还要绑定触发动作。命中后应该知道抓什么、停什么、恢复什么。

• 看到 ANR 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• ANR 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• ANR 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 Crash 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• Crash 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• Crash 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 permission dialog 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• permission dialog 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• permission dialog 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 focused window 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• focused window 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• focused window 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 input event 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• input event 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• input event 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 Activity switch 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• Activity switch 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• Activity switch 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 traces 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• traces 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• traces 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 logcat slice 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• logcat slice 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• logcat slice 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。

二十二、失败分级建议

• P0：设备重启、system_server watchdog、kernel panic、核心功能不可恢复。在Monkey 封装 报告中要写清楚为什么归到这个等级。
• P0 评审时要同时看影响范围、复现概率、证据完整度和是否阻塞下一轮测试。
• P1：可稳定复现的 Crash、ANR、关键服务异常或长稳中断。在Monkey 封装 报告中要写清楚为什么归到这个等级。
• P1 评审时要同时看影响范围、复现概率、证据完整度和是否阻塞下一轮测试。
• P2：偶现但证据完整的业务失败、资源趋势异常、自动恢复后继续运行。在Monkey 封装 报告中要写清楚为什么归到这个等级。
• P2 评审时要同时看影响范围、复现概率、证据完整度和是否阻塞下一轮测试。
• P3：脚本兼容性、环境波动、日志缺失导致的待观察问题。在Monkey 封装 报告中要写清楚为什么归到这个等级。
• P3 评审时要同时看影响范围、复现概率、证据完整度和是否阻塞下一轮测试。

二十三、复跑策略

复跑不是简单再跑一次。复跑要回答原问题是否在同等条件下再次出现，以及修复是否引入新的环境差异。

• 复跑步骤：固定版本。如果这一步发生变化，报告中必须显式说明。
• 复跑步骤：固定设备。如果这一步发生变化，报告中必须显式说明。
• 复跑步骤：固定任务参数。如果这一步发生变化，报告中必须显式说明。
• 复跑步骤：固定前置状态。如果这一步发生变化，报告中必须显式说明。
• 复跑步骤：固定网络条件。如果这一步发生变化，报告中必须显式说明。
• 复跑步骤：固定日志采集。如果这一步发生变化，报告中必须显式说明。
• 复跑步骤：固定超时阈值。如果这一步发生变化，报告中必须显式说明。
• 复跑步骤：固定判定规则。如果这一步发生变化，报告中必须显式说明。
• 复跑步骤：记录差异。如果这一步发生变化，报告中必须显式说明。
• 复跑步骤：保留 retry 关联。如果这一步发生变化，报告中必须显式说明。

二十四、平台配置示例

下面的配置片段表达的是结构，不要求团队照搬字段名。重点是把设备、任务、采集和判定分开。

task:
  name: "Monkey 封装"
  duration: "24h"
  stages: [precheck, prepare, execute, monitor, collect, recover, report]
device:
  serial: "${SERIAL}"
  require_state: "device"
collector:
  - "seed"
  - "throttle"
  - "event count"
  - "pct-touch"
  - "pct-motion"
judge:
  fail_on: [crash, anr, reboot, offline_timeout, evidence_missing]

二十五、人工评审时要问的问题

• 这个失败是否有明确第一现场。如果答案是否定的，Monkey 封装 的结论就要降级或补证据。
• 失败时间是否能和任务阶段对齐。如果答案是否定的，Monkey 封装 的结论就要降级或补证据。
• 设备状态是否可信。如果答案是否定的，Monkey 封装 的结论就要降级或补证据。
• 环境监控是否正常。如果答案是否定的，Monkey 封装 的结论就要降级或补证据。
• 脚本是否可能误判。如果答案是否定的，Monkey 封装 的结论就要降级或补证据。
• 是否有可复制命令。如果答案是否定的，Monkey 封装 的结论就要降级或补证据。
• 是否需要同设备复跑。如果答案是否定的，Monkey 封装 的结论就要降级或补证据。
• 是否需要换设备复跑。如果答案是否定的，Monkey 封装 的结论就要降级或补证据。
• 是否影响出货准入。如果答案是否定的，Monkey 封装 的结论就要降级或补证据。
• 是否已有历史相似问题。如果答案是否定的，Monkey 封装 的结论就要降级或补证据。
• 是否能归到明确责任域。如果答案是否定的，Monkey 封装 的结论就要降级或补证据。
• 是否需要补采 bugreport。如果答案是否定的，Monkey 封装 的结论就要降级或补证据。

二十六、面向缺陷系统的摘要写法

缺陷摘要要短，但信息密度要高。建议固定为“模块 + 场景 + 现象 + 影响”。

• 示例 1：[Monkey 封装] seed 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 1 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 2：[Monkey 封装] throttle 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 2 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 3：[Monkey 封装] event count 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 3 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 4：[Monkey 封装] pct-touch 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 4 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 5：[Monkey 封装] pct-motion 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 5 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 6：[Monkey 封装] ignore-crashes 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 6 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。

二十七、如何避免报告变成流水账

• 先写结论，再写证据：这能让Monkey 封装 的报告在评审会上快速被理解。
• 按时间线组织异常：这能让Monkey 封装 的报告在评审会上快速被理解。
• 把环境问题单独成段：这能让Monkey 封装 的报告在评审会上快速被理解。
• 表格展示设备分布：这能让Monkey 封装 的报告在评审会上快速被理解。
• 只贴关键日志入口：这能让Monkey 封装 的报告在评审会上快速被理解。
• 长日志放附件：这能让Monkey 封装 的报告在评审会上快速被理解。
• 复现命令放固定位置：这能让Monkey 封装 的报告在评审会上快速被理解。
• 未知项明确标注：这能让Monkey 封装 的报告在评审会上快速被理解。
• 不要混合多个根因：这能让Monkey 封装 的报告在评审会上快速被理解。
• 最后写下一步动作：这能让Monkey 封装 的报告在评审会上快速被理解。

二十八、团队协作分工

• 测试执行：保证任务按配置运行并保留现场。在Monkey 封装 相关问题里，职责要写进报告而不是只在群里口头同步。
• 测试开发：维护工具链、采集器、报告和调度逻辑。在Monkey 封装 相关问题里，职责要写进报告而不是只在群里口头同步。
• 系统开发：分析 Framework、Native、HAL 或 kernel 证据。在Monkey 封装 相关问题里，职责要写进报告而不是只在群里口头同步。
• 应用开发：分析业务进程、生命周期、线程和资源。在Monkey 封装 相关问题里，职责要写进报告而不是只在群里口头同步。
• 实验室维护：处理供电、网络、散热、线材和机位。在Monkey 封装 相关问题里，职责要写进报告而不是只在群里口头同步。
• 项目负责人：确认风险等级、准入结论和修复节奏。在Monkey 封装 相关问题里，职责要写进报告而不是只在群里口头同步。

二十九、长期维护指标

• 有效运行时长：用于衡量 Monkey 封装 是否真正降低了稳定性测试成本。
• 设备在线率：用于衡量 Monkey 封装 是否真正降低了稳定性测试成本。
• 环境失败率：用于衡量 Monkey 封装 是否真正降低了稳定性测试成本。
• 产品失败率：用于衡量 Monkey 封装 是否真正降低了稳定性测试成本。
• 脚本误判率：用于衡量 Monkey 封装 是否真正降低了稳定性测试成本。
• 证据完整率：用于衡量 Monkey 封装 是否真正降低了稳定性测试成本。
• 复跑复现率：用于衡量 Monkey 封装 是否真正降低了稳定性测试成本。
• 平均定位时间：用于衡量 Monkey 封装 是否真正降低了稳定性测试成本。
• 自动恢复成功率：用于衡量 Monkey 封装 是否真正降低了稳定性测试成本。
• 历史问题重复率：用于衡量 Monkey 封装 是否真正降低了稳定性测试成本。
• 报告生成耗时：用于衡量 Monkey 封装 是否真正降低了稳定性测试成本。
• 缺陷退回率：用于衡量 Monkey 封装 是否真正降低了稳定性测试成本。

三十、最后的落地提醒

• 不要让一次临时排查命令长期留在主流程里。这条在Monkey 封装 落地时尤其容易被忽略。
• 不要把未知失败自动归为产品问题。这条在Monkey 封装 落地时尤其容易被忽略。
• 不要在采集证据前清理现场。这条在Monkey 封装 落地时尤其容易被忽略。
• 不要让多个任务共享同一个日志文件。这条在Monkey 封装 落地时尤其容易被忽略。
• 不要只保存最终报告而删除原始日志。这条在Monkey 封装 落地时尤其容易被忽略。
• 不要忽略 host 侧异常。这条在Monkey 封装 落地时尤其容易被忽略。
• 不要让阈值只存在代码里。这条在Monkey 封装 落地时尤其容易被忽略。
• 不要依赖人工记忆复现步骤。这条在Monkey 封装 落地时尤其容易被忽略。
• 不要用截图替代结构化状态。这条在Monkey 封装 落地时尤其容易被忽略。
• 不要把平台能力和测试结论混为一谈。这条在Monkey 封装 落地时尤其容易被忽略。