Android稳定性-23-Android 无人值守压测环境怎么搭：供电、网络、散热、设备离线和恢复

无人值守压测失败时，最糟糕的结论是“半夜断了，不知道为什么”。Android 长稳环境必须把供电、网络、散热、设备离线和恢复动作当作测试系统的一部分，而不是实验室杂事。环境不可观测，产品稳定性结论就不可信。
这篇文章从稳定性测试视角展开，不把它写成工具说明书，而是把问题背景、测试位置、平台设计、命令入口、案例复盘和输出模板放在同一条链路里。
读完后，应该能直接拿去设计任务、评审失败、补齐日志和提交缺陷。

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

长稳测试通常跨夜、跨周末，人的响应不可能覆盖全部异常。环境设计的目标不是让设备永远不掉线，而是让每次掉线都可检测、可记录、可恢复或可隔离。
供电不足会表现成低电、降频、USB 反复断开；网络不稳会表现成业务超时；散热不足会表现成性能下降和系统杀进程。它们都容易被误判成产品缺陷。
无人值守环境应先做最小闭环：监控、告警、恢复、归档，再考虑复杂机柜和远程电源。

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

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

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

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

• 24 小时到 7 天长稳：要求环境能自动处理常见中断。
• 周末批量压测：无人值守期间必须保留现场和通知。
• 高低温或散热专项：温度、电量和任务强度联动。
• 远程实验室：设备不在身边时，恢复能力比人工操作更重要。

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

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

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

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

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

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

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

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

无人值守压测环境 的平台设计要从最小闭环开始，不要第一天就追求完整大屏。一个可用闭环至少包含采集层、执行层、判定层和归档层。

最小设计可以这样拆：

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

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

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

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

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

各阶段职责如下：

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

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

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

六、关键命令和日志入口

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

adb devices -l
adb -s <serial> get-state
adb -s <serial> shell dumpsys battery
adb -s <serial> shell dumpsys thermalservice
adb -s <serial> shell cat /sys/class/power_supply/battery/capacity
adb -s <serial> shell ip addr
adb -s <serial> shell ping -c 3 8.8.8.8
adb reconnect offline
adb -s <serial> reboot
adb usb

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

七、结果目录和证据归档

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

• environment.log：供电、电量、温度、网络、ADB 状态的周期采样。
• offline_events.jsonl：离线开始、恢复时间、恢复动作和结果。
• power_trace.csv：电量、电流、充电状态和 USB 状态。
• thermal_trace.csv：关键 thermal zone、降频状态和任务强度。
• recovery.log：重连 ADB、重启服务、重启设备、隔离设备的操作记录。

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

八、表格化拆解核心差异

风险	可观测信号	自动动作
供电不足	电量持续下降、USB disconnect、charging false	降载、换口、暂停任务、告警
网络异常	ping 失败、DNS 失败、业务接口超时	切 Wi-Fi、重连网络、标记环境失败
散热不足	温度越阈值、CPU 频率下降、thermal throttling	降低压测强度、开风扇、暂停任务
ADB 离线	offline、unauthorized、no device	reconnect、kill/start server、重插电源、隔离
设备卡死	无 shell 响应、屏幕无变化、心跳停止	保留 host 日志、硬重启、标记现场丢失

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

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

周末 40 台设备压测后，报告显示 11 台失败。环境平台回放发现其中 6 台在凌晨 2 点同一 USB hub 出现 disconnect，2 台电量从 80% 降到 5% 后进入省电，1 台温度长期超过阈值后 CPU 频率下降，只有 2 台有真实 system_server ANR。由于 offline_events 和 power_trace 独立保存，团队没有把环境故障误报给开发，而是先更换 hub、调整供电，再复跑产品问题。

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

十、常见误判和排除顺序

常见误判包括：

• 设备离线就是系统死机：USB、host、hub、线材、adb server 都可能导致离线。
• 电量没到 0 就不是供电问题：持续放电和低电量省电已经会影响结果。
• 风扇越大越好：过强风流可能改变专项温度条件，必须记录环境配置。
• 自动 reboot 可以解决所有问题：reboot 会破坏现场，应分级恢复。

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

十一、检查清单

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

• 每个机位有电源口、USB 口、hub、网络和设备 serial 映射。
• 环境监控频率独立于业务脚本，即使任务挂了也继续采样。
• 离线恢复有分级策略：reconnect、adb server、网络、电源、reboot、隔离。
• 温度和电量阈值写入任务报告。
• 恢复动作前后都记录时间和结果。
• 环境失败和产品失败在汇总中分开统计。

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

十二、输出物模板

建议输出物模板如下：

无人值守环境报告：run_id、机位表、设备在线率、离线事件、供电曲线、温度曲线、网络异常、自动恢复动作、未恢复设备、环境结论、需要人工处理项。

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

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

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

典型组合方式：

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

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

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

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

落地 无人值守压测环境 可以分三阶段。

第一阶段是脚本可用：

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

第二阶段是批量可靠：

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

第三阶段是平台治理：

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

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

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

评审 无人值守压测环境 的结论时，建议采用固定口径。缺陷提交不能只写现象，要包含触发条件、影响范围、证据链和复现方式。

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

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

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

十六、小结

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

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

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

做到这三点，无人值守压测环境 才能从个人经验变成团队能力。

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

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": "无人值守压测环境",
  "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 写给系统处理，两者都需要。

十九、场景矩阵怎么设计

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

• 场景 01：围绕 power trace 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 01 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 01 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 02：围绕 network probe 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 02 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 02 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 03：围绕 thermal trace 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 03 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 03 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 04：围绕 offline event 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 04 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 04 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 05：围绕 recovery action 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 05 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 05 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 06：围绕 lab slot 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 06 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 06 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 07：围绕 USB hub 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 07 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 07 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 08：围绕 remote power 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 08 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 08 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。

二十、关键字段命名建议

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

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

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

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

• 看到 charging state 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• charging state 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• charging state 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 battery capacity 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• battery capacity 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• battery capacity 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 ping 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• ping 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• ping 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 DNS 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• DNS 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• DNS 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 thermal throttling 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• thermal throttling 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• thermal throttling 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 adb offline 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• adb offline 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• adb offline 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 device reboot 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• device reboot 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• device reboot 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 isolation 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• isolation 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• isolation 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。

二十二、失败分级建议

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

二十三、复跑策略

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

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

二十四、平台配置示例

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

task:
  name: "无人值守压测环境"
  duration: "24h"
  stages: [precheck, prepare, execute, monitor, collect, recover, report]
device:
  serial: "${SERIAL}"
  require_state: "device"
collector:
  - "power trace"
  - "network probe"
  - "thermal trace"
  - "offline event"
  - "recovery action"
judge:
  fail_on: [crash, anr, reboot, offline_timeout, evidence_missing]

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

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

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

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

• 示例 1：[无人值守压测环境] power trace 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 1 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 2：[无人值守压测环境] network probe 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 2 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 3：[无人值守压测环境] thermal trace 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 3 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 4：[无人值守压测环境] offline event 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 4 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 5：[无人值守压测环境] recovery action 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 5 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 6：[无人值守压测环境] lab slot 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 6 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。

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

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

二十八、团队协作分工

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

二十九、长期维护指标

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

三十、最后的落地提醒

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