Android稳定性-18-多设备并发稳定性测试：设备管理、任务调度与结果归档

单设备稳定性测试验证的是脚本能不能跑，多设备并发稳定性测试验证的是平台能不能承受真实实验室。设备会掉线、序列号会变化、任务会抢资源、日志会互相覆盖，最后如果没有归档规范，几十台设备跑出来的结果反而比一台设备更难判断。
这篇文章从稳定性测试视角展开，不把它写成工具说明书，而是把问题背景、测试位置、平台设计、命令入口、案例复盘和输出模板放在同一条链路里。
读完后，应该能直接拿去设计任务、评审失败、补齐日志和提交缺陷。

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

多设备并发的核心不是把同一条 adb 命令开多个终端执行，而是建立设备身份、任务生命周期、日志目录和结果状态机。
当设备数超过 5 台后，人工盯屏和手工复制日志就会失效；当设备数超过 20 台后，调度公平性、失败隔离和批量恢复会成为主要成本。
稳定性测试的结论必须能回答“哪台设备、哪个版本、哪个任务、哪一轮、哪个时间点、哪些证据”。缺任何一个维度，结果都很难复盘。

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

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

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

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

• 版本冒烟后的批量长稳：同版本多设备同时跑，观察一致性。
• 硬件差异验证：不同内存、不同屏幕、不同射频配置设备分组执行。
• 专项压力矩阵：Monkey、业务遍历、资源监控、网络切换等任务并行。
• 回归池：修复后按风险标签自动选设备和任务。

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

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

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

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

• 被测版本：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> shell getprop ro.product.model
adb -s <serial> shell getprop ro.build.fingerprint
adb -s <serial> shell dumpsys battery
adb -s <serial> shell dumpsys thermalservice
adb -s <serial> logcat -b all -v threadtime
adb -s <serial> bugreport ./artifacts/<serial>/bugreport.zip
adb reconnect offline
adb kill-server
adb start-server

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

七、结果目录和证据归档

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

• device_registry.json：设备静态身份、标签、机位、供电口和负责人。
• run_manifest.json：一次批量执行的任务、版本、参数、开始时间和调度策略。
• artifacts///：每台设备独立目录，避免日志覆盖。
• worker.log：host 侧调度、adb 异常、超时和重试记录。
• result.json：设备级状态、任务级状态、失败分类和关键证据路径。

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

八、表格化拆解核心差异

维度	单设备做法	多设备平台做法
设备身份	看 adb serial	serial + model + fingerprint + lab slot + tags
任务执行	手动起脚本	队列、锁、超时、心跳、失败隔离
日志归档	当前目录随手放	run_id/serial/task/stage 固定结构
失败处理	人工重跑	自动 retry、隔离设备、生成复现包
结论	一句通过失败	按设备、版本、任务和失败类型聚合

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

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

一次 30 台设备的夜间长稳中，第二天有 8 台显示失败。最初看像是同一个 App ANR，但按设备时间线展开后发现 3 台是 USB hub 掉线导致日志中断，2 台是低电量降频导致脚本超时，只有 3 台是真正的 App 主线程卡死。平台把 host worker.log、dumpsys battery、logcat ANR、设备离线时间分开归档后，测试结论从“8 台失败”修正为“3 台产品问题、5 台环境问题”。

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

十、常见误判和排除顺序

常见误判包括：

• 把 offline 当作设备缺陷：先看 host USB、hub、电源和 adb server 日志。
• 把任务超时都算失败：要区分脚本卡死、设备卡死、资源争用和网络等待。
• 只按 serial 归档：换板、刷机或 Wi-Fi ADB 可能让 serial 不足以表达机位。
• 并发越高越好：host CPU、USB 带宽、磁盘写入和网络都会成为瓶颈。

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

十一、检查清单

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

• 每台设备有唯一 registry 记录，包含物理位置和标签。
• 每个任务有 run_id，设备日志不会写到共享文件。
• 调度器有设备锁，禁止两个任务同时控制同一台设备。
• worker 心跳、任务超时、adb 超时分别记录。
• 失败设备自动保留现场：logcat、bugreport、截图、dumpsys。
• 汇总报告能按设备、任务、版本、失败类型筛选。

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

十二、输出物模板

建议输出物模板如下：

批量执行报告：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：围绕 device registry 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 01 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 01 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 02：围绕 scheduler 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 02 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 02 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 03：围绕 worker 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 03 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 03 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 04：围绕 run_id 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 04 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 04 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 05：围绕 serial 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 05 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 05 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 06：围绕 lab slot 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 06 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 06 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 07：围绕 queue 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 07 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 07 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 08：围绕 artifact root 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 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 中保持同名。

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

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

• 看到 offline 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• offline 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• offline 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 unauthorized 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• unauthorized 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• unauthorized 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 USB hub 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• USB hub 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• USB hub 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 host load 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• host load 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• host load 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 battery 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• battery 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• battery 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 thermal 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• thermal 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• thermal 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 task timeout 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• task timeout 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• task timeout 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 result merge 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• result merge 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• result merge 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。

二十二、失败分级建议

• 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:
  - "device registry"
  - "scheduler"
  - "worker"
  - "run_id"
  - "serial"
judge:
  fail_on: [crash, anr, reboot, offline_timeout, evidence_missing]

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

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

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

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

• 示例 1：[多设备并发] device registry 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 1 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 2：[多设备并发] scheduler 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 2 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 3：[多设备并发] worker 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 3 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 4：[多设备并发] run_id 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 4 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 5：[多设备并发] serial 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 5 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 6：[多设备并发] lab slot 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 6 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。

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

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

二十八、团队协作分工

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

二十九、长期维护指标

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

三十、最后的落地提醒

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