momentic-maintain

维护 Momentic 测试

找出运行最早进入异常状态的时点，根据证据判定原因；适合通过持久化测试变更解决时，修复测试。使用 MCP 进行有针对性的调查，使用 momentic ai classify 获取最新的分类器判定，并使用 momentic ai triage 自动修复和验证。

不要通过弱化测试来掩盖应用程序缺陷、缺失的 fixture、无效凭据、服务中断或 Momentic 缺陷。应报告这些原因，而不是修改测试使其通过。

常见工作流

• 我的分支上发生了什么？ 使用准确的 gitBranchName 和有界的 start/end 调用 momentic_list_runs。先不指定状态筛选条件，然后再缩小范围到 FAILED、CANCELLED 或 recovered=true。打开准确的候选运行；只有在需要回答具体的跨分支问题时，才与 main 比较。
• 为什么 main 上有失败？ 在故障时间段内，列出实际 main 分支上的 FAILED 运行，并翻阅完成论证所需的所有页面。调查已知类别时，可使用 failureCategory 缩小范围；但只有在检查代表性运行和步骤证据之后，才能归纳症状。阅读每个准确运行已保存的分类，然后再决定是否重新分类。
• 减少不稳定性并缩短恢复延迟。 使用 momentic_quarantine_list 查找已隔离的测试，使用 recovered=true 查找需要恢复才成功的运行，并使用 minAttempts 查找重试次数较多的运行（2 表示至少重试一次；3 表示至少重试两次）。检查更早的尝试，优先处理重复出现的同一意图失败，修复最早出现的不稳定后置条件，然后再次测量。

了解发现范围的限制：

• momentic_list_runs 可按测试、分支、状态、隔离、恢复、有效失败类别、总尝试次数下限和时间进行筛选。failureCategory 在存在手动分类时使用手动分类，否则使用自动分类。
• momentic_quarantine_list 按隔离日期筛选，并返回每个仍在隔离中的测试最近一次保留的失败 CLI 运行。它不按分支或分类筛选。
• 按类别或重试次数阈值筛选的结果仍可能跨越多个页面。只有翻阅了所需的全部 pageCount 页面后，才能称清单已完整。

维护工作流

1. 从准确的运行、分支、运行组、提交或本地结果目标开始。
2. 首先检查现有的自动/手动分类和修复状态。
3. 使用 MCP 和必要的运行历史重建确切的失败情况。
4. 编辑之前，说明最早的偏离情况和未满足的后置条件。
5. 仅在有用时重新分类；只有在收到请求时才保存判定。
6. 准备好准确的应用和 fixture，适合修复时再进行分诊。
7. 检查差异和重放证据；对结论不明确的修复重新运行。
8. 报告诊断、修复、验证、交付情况和剩余阻碍。

检查现有分类

如果有 API 密钥，在使用 MCP 调查之前先获取原始运行元数据：

RUN_ID="<run-id>"
MOMENTIC_SERVER_URL="${MOMENTIC_SERVER:-https://api.momentic.ai}"
RUN_INSPECTION_DIR="$(mktemp -d)"

curl --fail --silent --show-error \
  -H "Authorization: Bearer ${MOMENTIC_API_KEY:?Set MOMENTIC_API_KEY}" \
  "${MOMENTIC_SERVER_URL}/v1/runs/${RUN_ID}/metadata" \
  -o "${RUN_INSPECTION_DIR}/metadata.json"

jq '{
  runId: .id,
  status,
  failureReason,
  classification: .failureDetails.classification,
  manualClassification: .failureDetails.manualClassification,
  healStatus,
  healDetails
}' "${RUN_INSPECTION_DIR}/metadata.json"

在针对准确运行和组织的元数据请求成功之前，不要因为某个字段缺失就断定无人审查过该失败。不要回显、记录或提交 API 密钥。将下载的元数据和已签名的资源 URL 视为敏感运行数据。

momentic_get_run 会有意从返回的证据中移除先前的分类和修复字段，避免新调查受到旧判定的影响。使用元数据端点或仪表板查看现有判定，再使用 MCP 检查底层证据。

有用的 MCP 工具

momentic_get_run - 返回运行元数据和完整结果树的摘要。 使用它来确定尝试次数、失败部分、失败步骤和嵌套的父级链。如果当前运行已加载，仅在需要查看其他尝试或缺失数据时才再次调用。

momentic_list_runs - 列出该测试最近的运行。目标运行存在 gitBranchName 时，务必传入，以便更有可能使用相同的测试版本进行比较。只有在跨分支历史能回答特定问题时，才省略该参数。传入 recovered=true 可检查已恢复的运行。 传入 failureCategory 可选择有效的手动／自动分类；传入 minAttempts: 2 或更高值可查找重试过的运行。

momentic_quarantine_list - 列出当前有效的本地测试隔离项，以及每个测试最近一次保留的失败 CLI 运行。使用有界的隔离日期范围。

momentic_get_step_result - 返回一个步骤的命令详情、前后截图，以及可选的完整跟踪。对嵌套步骤传入 parentStepIdChain。仅当截图和常规字段无法解答问题时，才请求 includeTrace=true。

momentic_get_test_steps_for_run - 返回某次运行中记录的简化测试定义。当测试意图仍不明确，或需要比较不同运行之间编写的测试是否发生变化时使用。

momentic_submit_result_classification - 持久化手动 MCP 分类。仅当调查已完成且用户要求记录判定结果时调用。对于同一结论，不要同时调用此工具和 ai classify --save。

调查工作流

先从当前运行着手，再参考历史记录。

1. 调用 momentic_get_run，确定失败的尝试、部分（beforeSteps、主步骤或 afterSteps）、失败步骤以及任何 parentStepIdChain。
2. 获取失败步骤的结果，包括截图和跟踪。如果该步骤是嵌套的，也要获取最近的父容器或模块结果。
3. 判断该步骤的前置截图是否是该操作的正确基线。如果截图中的状态已经不正确，就沿当前运行向前回溯，直到找到产生该错误状态的步骤／容器。
4. 对于重复的模块或重复的工作流，先比较当前运行中的各次调用，再比较较早的运行。后续失败通常是由先前成功、恢复过或留下无效后置条件的调用导致的。
5. 对于包含失败或已恢复子步骤的成功容器，在检查容器最终的后置截图和 URL 之前，都应视为部分失败。
6. 只有在了解当前运行的行为后，才针对具体的比较问题使用历史运行。

分类之前，确保能够回答：

• 测试的预期行为是什么？
• 最早出现偏差的步骤／容器是什么？
• 该步骤原本打算做什么？
• 它实际与哪个元素／状态进行了交互或观察？
• 该步骤之后，截图、URL、DOM、跟踪或恢复日志发生了什么变化？
• 为什么后续失败是由先前的偏差导致的？

避免使用“设置不可靠”或“页面状态不对”之类含糊的根因描述。应明确指出被破坏的后置条件，例如：“点击了行级加号按钮，但应用仍停留在父页面，没有打开子页面编辑器；后续针对全局 Add to 的断言错误地匹配了无关页面文本，因此未指定目标的输入步骤从未输入子页面标题。”

证据标准

• 截图是判断页面状态的默认依据。使用跟踪字段和 DOM/HTML 说明截图为何发生或未发生变化。
• 核实每一项因果判断。除非相关的前后截图、URL 或 DOM 能证明，否则不要声称存在覆盖层、侧边预览、模态框或菜单。
• 区分“目标现在不存在”和“浏览器处于目标本应存在的状态”。目标缺失通常是更早的操作失败所导致的症状。
• 对于点击、输入和操作步骤，记录预期操作、实际交互的元素（如有）、操作前后的 URL，以及预期的 UI 状态是否出现。
• 对于断言，检查其范围是否足以证明预期状态。宽泛的页面内容断言可能会因无关文本而通过。
• 对于恢复操作，同时检查失败的子步骤和恢复后的容器最终状态。重试后的断言可能通过，但留下的状态仍可能与后续步骤的预期不符。

运行 AI 分类

momentic ai classify 会在失败的运行上运行 Momentic 的结果分类 Agent。它会读取运行产物，使用相关的运行历史记录和仓库上下文，并返回类别、可恢复性、置信度、推理过程和引文。它会解释失败原因，但不会编辑测试。

每条命令使用一个选择器：

npx momentic ai classify --run-id "$RUN_ID" --output-format json
npx momentic ai classify --run-group-id "<run-group-id>"
npx momentic ai classify --git-commit "<commit-sha>"

• 诊断性地重新分类时，省略 --save。只有在新判定应替换本地归档或云端运行中保存的分类时，才添加 --save。
• 当怀疑现有的缓存分类器结果已过时，且用户明确需要全新分析时，使用 --no-cache。
• 恢复批处理时，使用 --skip-classified，以跳过已保存分类的运行。
• 使用 --output-format json 进行自动化和多运行记录管理。
• 在有用时，将多个相关运行 ID 一并分类，但要将每个结果对应到其准确的运行。

在真实终端中处理单次运行时，保持分类器对话开启：

npx momentic ai classify --run-id "$RUN_ID" --interactive

通过聊天询问它为何选择该类别、依据了哪些证据、当前运行与先前运行有何不同，或需要怎样才能进行持久修复。 交互式分类仅支持单次运行，需要 stdin 为 TTY，且不能与 JSON 输出结合使用。

准备分诊

将应用就绪状态视为硬性前提。分诊会在真实浏览器中重放测试；它无法修复针对不可用应用、缺失的固定数据、错误的环境、未初始化的数据库、无效账号或尚未预热的编译器的测试。

分诊前：

1. 阅读 momentic.config.yaml、目标测试及其设置模块、仓库脚本，以及通常运行该测试的 CI 工作流。使用相同的 URL、环境、凭据、标头、文件、服务和数据固定项。
2. 确认 MOMENTIC_API_KEY、项目配置、依赖项和所请求的浏览器均可用。
3. 检查 git status 并保留无关工作。在运行命令前确定修复交付方式；不要让未知的仪表板默认设置意外创建拉取请求或提交。
4. 在开始分诊前构建应用。优先使用生产构建或其他预编译构建，以及稳定的服务，而不是会增量编译路由的 Next.js、webpack、Vite 或其他开发服务器。
5. 启动所有必需服务，并等待实际就绪 URL。预热任何无法避免的仅用于开发的编译路径，并确认相关路由不再显示编译／加载屏幕，或不会出现较长的首次请求耗时。
6. 必要时运行一次有针对性的冒烟测试或失败测试，以证明应用、固定数据、身份验证和浏览器均已就绪。先修复设置问题，再判断是否是分诊导致的问题。
7. 从 --parallel 1 开始。只有在机器有足够的 CPU 和内存，能够为每个工作进程提供一个浏览器和应用工作负载时，才提高并行度。

如果仓库提供稳定的服务启动命令，可以单独启动，也可以通过 --start 和 --wait-on 让分诊负责启动：

# Build first; use the repository's actual commands and readiness URL.
pnpm build
npx momentic ai triage --run-id "$RUN_ID" \
  --start "pnpm start" \
  --wait-on "http://localhost:3000/health" \
  --parallel 1 \
  --yes \
  --on-heal-success nothing

不要盲目照抄这些示例命令。应从仓库和 CI 配置中查明实际的构建、启动和就绪条件。

运行 AI 分诊

momentic ai triage 会根据共同的根本原因对失败进行分组，判断哪些失败可以修复，编辑相关测试，在浏览器中重新运行，并且只接受通过验证的修复。它可以将更改保留在本地、生成补丁、提交更改或创建拉取请求。它无法通过更改测试来修复应用程序错误、外部服务中断或缺少测试夹具。

如果用户希望获得明确的诊断，请先运行分类，再将相同的目标传递给分诊：

npx momentic ai classify --run-id "$RUN_ID" --output-format json
npx momentic ai triage --run-id "$RUN_ID" \
  --parallel 1 \
  --yes \
  --on-heal-success nothing

对于本地运行组，请改为传递结果目录：

npx momentic ai triage ./test-results \
  --parallel 1 \
  --yes \
  --on-heal-success nothing

最佳实践：

• 在一个 --run-id 后传递多个相关的运行 ID，以便分组 Agent 能够归纳共同原因。不要针对每次运行分别启动相互竞争的分诊命令。
• 明确设置 --on-heal-success：本地审查使用 nothing，生成便于移植的差异使用 patch，仅当用户要求以该方式交付时才选择拉取请求或提交行为。
• 只有在确认环境和交付方式后才传递 --yes，以免依赖项提示阻塞自主运行。
• 使用 --dry-run --no-save 查看分组结果，而不编辑测试或保存分诊元数据。试运行并不代表尝试修复。
• 仅当缓存的修复已过期或失败，且需要从头生成新修复时，才使用 --regenerate-heal。
• 保持命令持续运行，并监控推理、工具调用、浏览器进度、CPU 和内存。浏览器进度停滞数分钟，可能表示应用程序正在启动、正在进行冷编译、资源紧张或缺少测试夹具。
• 检查每一处生成的差异。不要接受删除断言、放宽检查、随意添加休眠时间，或仅仅掩盖根本原因的更长超时时间。
• 不要仅仅因为分诊生成了补丁就移除隔离标记。先重新运行修复后的测试。

如果用户希望向修复 Agent 提问，请使用交互式分诊：

npx momentic ai triage --run-id "$RUN_ID" \
  --parallel 1 \
  --yes \
  --on-heal-success nothing \
  --interactive

交互式分诊需要 TTY，不能与 --json 搭配使用，且仅当命令运行分组 Agent 时可用。可用它询问为何接受或拒绝某项修复、观察到哪些设置，以及还有哪些证据未解决。

手动下载运行产物

常规检查优先使用 MCP，因为 momentic_get_run 会自动下载并解压云端尝试记录。当 MCP 输出缺失、需要对原始文件进行 grep 搜索，或需要独立验证 Agent 时，请使用 API。

导出端点会返回运行元数据，以及每次尝试各自的一个短时有效签名 ZIP URL；它不会返回一个合并后的运行 ZIP。下载并解压时不要打印这些 URL：

RUN_ID="<run-id>"
MOMENTIC_SERVER_URL="${MOMENTIC_SERVER:-https://api.momentic.ai}"
RUN_INSPECTION_DIR="$(mktemp -d)"

curl --fail --silent --show-error \
  -H "Authorization: Bearer ${MOMENTIC_API_KEY:?Set MOMENTIC_API_KEY}" \
  "${MOMENTIC_SERVER_URL}/v1/runs/${RUN_ID}/export" \
  -o "${RUN_INSPECTION_DIR}/export.json"

jq '.run' "${RUN_INSPECTION_DIR}/export.json" \
  > "${RUN_INSPECTION_DIR}/metadata.json"

jq -r '.attemptZipUrls | to_entries[] | select(.value != null) |
  [(.key + 1), .value] | @tsv' "${RUN_INSPECTION_DIR}/export.json" |
  while IFS=$'\t' read -r attempt url; do
    mkdir -p "${RUN_INSPECTION_DIR}/attempts/${attempt}"
    curl --fail --silent --show-error "$url" \
      -o "${RUN_INSPECTION_DIR}/attempt-${attempt}.zip"
    unzip -q "${RUN_INSPECTION_DIR}/attempt-${attempt}.zip" \
      -d "${RUN_INSPECTION_DIR}/attempts/${attempt}"
  done

检查 metadata.json、每次尝试的 metadata.json、屏幕截图、DOM 快照、控制台日志、HAR 日志、视频、资源使用情况和崩溃归档。保留尝试编号不变。不要提交导出响应、运行产物、签名 URL、凭据或客户数据。调查完成后删除临时目录。

背景

测试运行结果结构

通过 CLI 运行 momentic 测试时，结果会存储在一个“运行组”中。此运行组的数据存储在 momentic 项目中的单个目录内。默认目录名为 test-results，但可以在 momentic 项目设置中更改，也可以在单次运行运行组时更改。运行组结果文件夹的结构如下：

test-results/
├── metadata.json         data about the run group, including git metadata and timing info.
└── runs/                 On zip for each test run in the run group.
    ├── <runId_1>.zip         a zipped run directory containing data about this specific test run.  Follows the structure described below.
    └── <runId_2>.zip

解压后，运行目录的结构如下：

<runId>/
├── metadata.json           run-level metadata.
└── attempts/<n>/           one folder per attempt (1-based n).
    ├── metadata.json       attempt outcome and step results.
    ├── console.json        optional browser console output.
    └── assets/
        ├── <snapshotId>.jpeg     before/after screenshot for each step (see attempt metadata.json for snapshot ID).
        ├── <snapshotId>.html     before/after DOM snapshot for each step (see attempt metadata.json for snapshot ID).
        ├── har-pages.log         HAR pages (ndjson).
        ├── har-entries.log       HAR network entries (ndjson).
        ├── resource-usage.ndjson CPU/memory samples taken during the attempt.
        ├── <videoName>           video recording (when video recording is enabled).
        └── browser-crash.zip     browser crash dump (only present on crash).

通过 momentic MCP 获取运行结果时，momentic_get_run 等工具会返回 MCP 工作目录（默认为 .momentic-mcp）的链接。此目录包含已解压的运行结果文件夹，其结构如上所示，名称为 run-result-<runId>。

元素定位器

某些与元素交互的步骤类型具有一个“目标”属性（即定位器），用于指定该步骤应与哪个元素交互。

定位器缓存

定位器会将页面状态 HTML/XML 和屏幕截图发送给大模型，以识别页面上的元素。大模型会识别用户指的是页面上的哪个元素。Momentic 会尝试“缓存”大模型给出的答案，这样后续运行就无需调用 AI。后续运行时，系统会将页面状态与缓存的元素进行比对，以确定该元素是否仍可用，或页面是否发生了足够大的变化，需要再次调用 AI。

定位器缓存可能因多种原因失效：

• 元素描述已更改，此时缓存总会失效
• 在当前页面状态中找不到缓存的元素
• 在页面状态中找到了缓存的元素，但未通过缓存条目中指定的某些检查，例如要求元素处于特定位置、形状或内容

只有明确请求 includeTrace=true 时，才能在某个步骤结果的 trace 属性中找到 cacheBustReason。结果中也会列出 cache 属性，其中包含为该元素保存的完整缓存。

识别错误缓存

有时，缓存的元素并非用户原本想要定位的元素。这可能导致测试失败或出现意外行为。在这种情况下，核实最初为何保存了错误的缓存会很有帮助。仅在调试此类缓存问题或怀疑 Momentic 执行数据不正确时，才请求 includeTrace=true。使用错误缓存中 targetUpdateLoggerTags 的 runId 属性获取原始运行的详细信息，并调用 momentic_get_run，传入此 runId。这会返回缓存目标被更新时对应的运行记录。

模块缓存

当模块缓存键和解析后的输入未发生变化时，缓存模块会跳过其步骤的执行，并复用模块上一步的缓存返回值。

身份验证模块还可以通过模块缓存保存和恢复浏览器身份验证状态，包括 Cookie、localStorage 和 IndexedDB。恢复身份验证状态后，它们可能会检查页面内容，以判断缓存是否仍然有效。

文件上传

文件上传步骤会为下一个原生文件选择器准备一个文件，因此必须在打开选择器的操作之前运行。

来源可以是远程 URL、指向先前下载内容的 file:// 引用、CLI 本地路径或用户上传的文件。此步骤还可以覆盖显示的文件名，Momentic 会将准备好的文件接入浏览器的文件选择器处理流程。

使用过往运行记录

过往运行记录是用于比对的依据，不能替代对当前运行情况的还原。当当前运行无法回答以下问题时，请使用过往运行记录：

• 此测试从什么时候开始失败？
• 与上一次通过的运行相比，有什么不同？
• 同一操作在之前的运行中是否表现不同？
• 这是测试薄弱、应用发生变化、应用存在真实缺陷，还是暂时变慢？

使用过往运行记录中的步骤结果和屏幕截图来回答这些问题。不要仅依靠 momentic_get_run 或 momentic_list_runs 的摘要来了解测试运行中发生了什么。在引用过往运行记录作为依据之前，请查看具体的运行详情，包括步骤结果和屏幕截图。

查看过往运行记录时，请按以下工作流操作：

1. 调用 momentic_list_runs 工具，确定需要进一步查看的运行记录。如果相关运行记录中有 gitBranchName，务必传入该参数。需要查看其他分支的运行记录时，则省略此参数。
2. 调用 momentic_get_run，获取该次运行的详细信息。
3. 调用 momentic_get_step_result，查看要比对的相同步骤／容器，或最接近的等效步骤／容器，尤其是屏幕截图。

如果当前运行已能证明根本原因，导致过往运行记录无关紧要，请简要说明，而不要勉强引用历史依据。

多次尝试的运行

当 momentic_list_runs 显示某次运行通过，但 attempts > 1 时，应将其视为值得调查的部分失败，而不是干净的通过。使用 attemptNumber 参数获取该次运行先前失败的尝试结果，以了解重试成功前出现了什么问题。

不稳定性和间歇性失败

• 只有当同一应用和测试行为间歇性失败时，才将测试称为不稳定。仅一次失败不足以得出结论；在根据运行证据将这种模式归因于不稳定之前，请先排除应用和测试发生变化的可能。

测试的时效性

• 过去的结果不一定与今天的测试文件相符。测试可能已经更改，这意味着该结果对应的是不同版本的测试。
• 你可以调用 get_test_steps_for_run 来帮助判断测试本身是否在不同运行之间发生了变化，但请注意，该工具返回的是每个测试步骤的_摘要_。如果你怀疑某些步骤的具体细节在不同测试运行之间发生了变化，momentic_get_step_result 的响应中包含完整的步骤详情；只有在这些字段和截图仍不足以判断时，才请求 includeTrace=true。

需要留意的常见失败模式

• 设置模块看似通过，却留下了错误的页面、叠加层、筛选器、搜索、选中行或侧边预览窗格。应根据导致错误后置条件的步骤或容器进行分类，而不只是看下一个失败的步骤。
• 点击报告成功，且目标是预期元素，但应用并未转换到预期状态。请验证后置状态；不要因为定位器正确就假定点击成功。
• 较弱的全局断言（例如“页面包含 X”）可能因页面上无关文本匹配而通过。这样一来，下一步就可能在错误的上下文中输入或点击。
• 如果前一个操作未能聚焦预期字段，不带特定目标的输入步骤可能会悄无声息地输入到无用位置。
• 定位器或缓存可能在技术上有效，但在语义上错误。请检查交互的元素；对于错误的缓存，请检查 targetUpdateLoggerTags.runId 指向的原始缓存更新运行。
• 恢复后的步骤可能会掩盖首次失败。请检查恢复模块中失败的子步骤，并将恢复后的最终状态与下一步的预期基线进行比较。
• 超时并不自动意味着 INFRA。请先排除缺少数据、页面状态错误、应用流程已变更、定位器或断言错误，以及设置失败。

识别相关与不相关的问题

• 根据测试名称、描述和简化步骤判断意图。测试意图之外的失败（包括大多数设置／清理失败）都应视为不相关。相关性会影响对错误和变更的判断，但不会将 INFRA 失败变成其他类别。

错误与变更

• 错误：明显出现了本不该发生的问题，例如显示了错误消息。只需查看一两个步骤，就能看出这是错误。
• 变更：应用行为发生了明确变化，而且可以通过截图证明。

可恢复性

除类别外，还要确定一个可恢复性值：

• RECOVERABLE — 可以通过自动更新测试本身来修复失败，使后续运行通过。
  • 示例：应用发生变化，需要更新测试；可以改写含糊的定位器或断言，使测试稳定通过。
• ONE_TIME_RECOVERABLE — 可以在不持久修改测试的情况下恢复本次运行。
  • 示例：可以关闭随机出现的模态框，且不影响测试目的；发生临时延迟，通过等待或重试可能就能成功。
• NON_RECOVERABLE — 无法自动解决失败，需要人工介入。
  • 示例：缺少凭据；缺少上传所需的本地文件；第三方系统可能发生故障，而测试步骤无法解决此问题。

正式分类输出

• 只能选择一个类别 ID——不得新增标签或使用多个标签。
• 根据数据做出判断。分配类别前，务必完整调查此次运行。
• 当步骤／模块可以用通俗名称识别时，优先使用易读的引用，而不是 UUID：module create-subpage-under-parent-page、模块 <name> 的最后一次调用、子步骤 4（从 0 开始计数）、失败的设置断言等。工具调用仍需使用准确 ID，但最终的推理应易于阅读。
• 在最终输出中引用过往运行时，使用可点击的 Momentic URL，而不是直接使用 UUID：https://app.momentic.ai/runs/<runId>。不要缩短这些 URL 中的 UUID。
• 推理必须包含最早出现偏差的步骤／容器，以及由此导致的失效后置条件，不能只写最终失败步骤。

Reasoning: <a few sentences tied to the earliest divergence, screenshots/traces, past runs if used, and test intent>
Category: <one id from the list>
Recoverable: <RECOVERABLE | ONE_TIME_RECOVERABLE | NON_RECOVERABLE>
Confidence: <high | medium | low>

置信度等级：

• high — 有直接证据，例如清晰显示标签变更或崩溃的截图
• medium — 多个信号支持强推断，但没有单张决定性截图或数据点
• low — 证据模糊；分类需要大量推断，或根本原因不明确

类别 ID

逐字使用以下字符串：

• NO_FAILURE — 运行没有失败；所有尝试均已通过。
• APPLICATION_CHANGE — 测试已过时，因为应用的流程或 UI 已发生变化；更新测试以匹配新行为即可永久修复失败。
• BUG — 应用中明显发生了不应出现的问题，例如出现错误消息或预期内容未能呈现。
• TEST_AUTHORSHIP — 可以永久更新测试以避免失败，同时仍验证其原始意图，并且可以建议具体的编写方式改进，例如添加或修改步骤、重写含糊的断言，或使定位器描述更具体。如果无法提出具体改动，请选择其他类别。超时、页面加载缓慢，以及建议修复方式是“多等一会儿”或增加超时时间的任何失败，都不属于编写方式问题——应归为 INFRA，即使理论上可以修改测试以等待更久。
  • 示例：可通过添加或修改非等待／超时类步骤来修复的竞态条件（例如，将“输入并按下回车”步骤替换为明确的“从列表中选择”步骤，避免测试与应用发生竞态）；含糊的断言或定位器描述可改写得更具体。
• TEST_SETUP — 运行测试所需的数据或文件缺失，且必须由用户在测试之外采取行动才能修复。
  • 示例：文件上传步骤所需的文件缺失；测试所需的凭据缺失或不正确。
• INFRA — 失败与应用或应用代码无关，而是由基础设施故障、加载时间过长或其他外部因素导致。
  • 示例：浏览器崩溃；资源占用过高；速率限制；某个步骤或断言在等待页面或应用达到较慢但最终会达到的状态时超时。
• MOMENTIC_ISSUE — 测试执行过程中出现问题，或 Momentic 数据不正确（例如缓存错误、全局定位器重定向出现异常、AI 产生幻觉）。
  • 示例：查看运行轨迹时出现意外行为；AI 明显误读或幻觉了截图中清晰无误的数据，且不存在合理的测试替代方案来避免使用 AI 步骤。
• OTHER — 失败不属于任何其他类别。