Android稳定性-17-Android 兼容性与稳定性：CTS、VTS 和 Trade Federation 应该怎么理解

做 Android 系统稳定性测试时，CTS、VTS 和 Trade Federation 经常被放在“认证测试”的抽屉里，等到出货前才集中跑一轮。这个做法会错过它们对稳定性工程最有价值的部分：标准化环境、可复跑任务、可归档结果和跨设备执行模型。
这篇文章从稳定性测试视角展开，不把它写成工具说明书，而是把问题背景、测试位置、平台设计、命令入口、案例复盘和输出模板放在同一条链路里。
读完后，应该能直接拿去设计任务、评审失败、补齐日志和提交缺陷。

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

CTS 关注应用兼容性和 CDD 约束，VTS 关注 vendor、HAL、kernel 接口的稳定契约，Trade Federation 则提供设备发现、模块调度、日志收集和结果组织的执行框架。
稳定性团队不一定要把自己的长稳平台做成另一个 CTS，但应该理解 CTS/VTS 如何定义测试边界、如何隔离设备状态、如何把一次失败变成可复现的问题单。
很多“偶现稳定性问题”最后会落到接口契约变化、系统服务状态污染、vendor 实现不稳定或测试环境不可重复。CTS/VTS 的思路正好能补齐这些短板。

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

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

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

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

• 出货认证前的兼容性基线：确认 build 是否满足最低兼容要求。
• 版本分支合入后的冒烟：用小集合模块发现 Framework 或 HAL 行为回退。
• 长稳压测前的准入：先排除明显的兼容性失败，避免把基础错误带入 24 小时压测。
• 问题修复后的复测：用 Tradefed 的 module、test、retry 机制固定复现范围。

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

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

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

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

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

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

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

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

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

最小设计可以这样拆：

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

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

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

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

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

各阶段职责如下：

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

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

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

六、关键命令和日志入口

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

cts-tradefed
run cts -m CtsWindowManagerDeviceTestCases
run cts -m CtsAppTestCases -t android.app.cts.ActivityManagerTest#testProcessState
run retry --retry <session_id>
vts-tradefed
run vts -m VtsHalCameraProvider_TargetTest
lshal
adb shell getprop ro.build.fingerprint
adb logcat -b all -v threadtime
adb bugreport ./bugreport-cts.zip

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

七、结果目录和证据归档

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

• /tmp/Tradefed/logs 或配置的 log root：Tradefed 主日志和 invocation 日志。
• android-cts/results//test_result.xml：模块、用例、失败原因和设备信息。
• android-cts/results//logs/：logcat、bugreport、host log、截图等证据。
• bugreport 中的 dumpsys activity、dumpsys window、dumpsys package、tombstones 和 kernel log。
• VTS 失败时重点看 HAL service、binderized HAL、hidl/aidl service 注册和 vendor log。

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

八、表格化拆解核心差异

对象	主要验证	稳定性价值
CTS	Framework API、应用行为、权限、窗口、媒体等兼容性	发现系统行为偏离 Android 预期
VTS	HAL、vendor interface、kernel/vendor 边界	发现底层接口不稳定或实现不一致
Tradefed	设备调度、模块执行、日志归档、重试	给自研稳定性平台提供工程模型
长稳平台	业务场景、压力、异常恢复、资源趋势	发现真实使用中的可靠性问题

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

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

某系统版本在 48 小时长稳中偶发相机打不开，业务脚本只看到 Camera App 启动失败。补跑 VTS camera provider 模块后，发现 provider 在多次 open/close 后返回状态不一致；再跑 CTS Camera2 相关模块，确认 Framework 层也能触发同类失败。最终定位到 vendor HAL 在高温后状态机没有恢复，长稳报告引用了 VTS 失败模块、CTS 失败用例、温度曲线和 CameraService 日志，问题从“偶现打不开”升级为可复现接口契约问题。

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

十、常见误判和排除顺序

常见误判包括：

• 把 CTS 失败都当稳定性缺陷：有些是配置、区域、GMS 或测试环境问题，必须先做环境确认。
• 只看 failed 数量：一个核心模块失败可能比几十个非目标模块失败更严重。
• VTS 失败就直接甩给驱动：还要确认 vendor image、kernel、manifest、sepolicy 和测试设备状态。
• Tradefed retry 通过就认为问题消失：retry 只能说明当前条件下未复现，不能覆盖长稳时序。

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

十一、检查清单

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

• 确认设备 build fingerprint、security patch、vendor image 与测试目标一致。
• 确认测试前执行清理：恢复网络、清日志、清 recent task、确认屏幕和锁屏状态。
• 确认模块选择和稳定性目标相关，不把全量 CTS 当作每次长稳前置。
• 确认失败项有 test_result.xml、host log、device log、bugreport。
• 确认 retry 使用同一 session，并记录 retry 前后的设备状态差异。
• 确认 CTS/VTS 结论和长稳结论分开写，避免混淆认证风险和可靠性风险。

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

十二、输出物模板

建议输出物模板如下：

兼容性准入记录：build、设备、模块、失败项、失败日志、是否阻塞长稳、retry 结果、关联长稳任务、责任域判断、下一步复测命令。

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

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

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

典型组合方式：

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

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

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

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

落地 CTS、VTS 与 Trade Federation 可以分三阶段。

第一阶段是脚本可用：

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

第二阶段是批量可靠：

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

第三阶段是平台治理：

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

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

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

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

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

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

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

十六、小结

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

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

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

做到这三点，CTS、VTS 与 Trade Federation 才能从个人经验变成团队能力。

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

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": "CTS、VTS 与 Trade Federation",
  "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 写给系统处理，两者都需要。

十九、场景矩阵怎么设计

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

• 场景 01：围绕 CTS module 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 01 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 01 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 02：围绕 VTS HAL test 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 02 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 02 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 03：围绕 Tradefed session 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 03 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 03 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 04：围绕 CDD 条款 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 04 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 04 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 05：围绕 test_result.xml 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 05 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 05 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 06：围绕 retry 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 06 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 06 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 07：围绕 module plan 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 07 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 07 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。
• 场景 08：围绕 compatibility report 设计一条最小验证链路，记录输入条件、执行动作、预期信号和失败证据。
• 场景 08 的前置状态必须可重建，不能依赖上一次任务遗留的窗口、缓存、权限或网络状态。
• 场景 08 的退出条件要明确，达到失败条件后先采集证据，再进入恢复阶段。

二十、关键字段命名建议

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

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

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

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

• 看到 ActivityManager 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• ActivityManager 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• ActivityManager 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 WindowManager 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• WindowManager 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• WindowManager 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 PackageManager 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• PackageManager 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• PackageManager 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 CameraService 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• CameraService 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• CameraService 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 HAL service 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• HAL service 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• HAL service 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 vendor interface 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• vendor interface 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• vendor interface 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 sepolicy 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• sepolicy 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• sepolicy 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。
• 看到 kernel log 相关异常时，先截取前后 5 到 10 分钟日志，再补抓当前状态快照。
• kernel log 如果连续出现，要记录第一次出现时间、最后一次出现时间和出现次数。
• kernel log 不应单独决定结论，至少要和任务阶段、设备状态或资源指标交叉验证。

二十二、失败分级建议

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

二十三、复跑策略

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

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

二十四、平台配置示例

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

task:
  name: "CTS/VTS/Tradefed"
  duration: "24h"
  stages: [precheck, prepare, execute, monitor, collect, recover, report]
device:
  serial: "${SERIAL}"
  require_state: "device"
collector:
  - "CTS module"
  - "VTS HAL test"
  - "Tradefed session"
  - "CDD 条款"
  - "test_result.xml"
judge:
  fail_on: [crash, anr, reboot, offline_timeout, evidence_missing]

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

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

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

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

• 示例 1：[CTS/VTS/Tradefed] CTS module 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 1 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 2：[CTS/VTS/Tradefed] VTS HAL test 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 2 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 3：[CTS/VTS/Tradefed] Tradefed session 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 3 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 4：[CTS/VTS/Tradefed] CDD 条款 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 4 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 5：[CTS/VTS/Tradefed] test_result.xml 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 5 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。
• 示例 6：[CTS/VTS/Tradefed] retry 场景长稳中出现异常，任务中断并已附复现命令和日志包。
• 示例 6 的正文要补充版本、设备、run_id、失败时间、证据路径和复跑结果。

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

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

二十八、团队协作分工

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

二十九、长期维护指标

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

三十、最后的落地提醒

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