testany-execution（测试执行）

Testany Execution Operations

管理 Testany 平台上的 execution，包括进度观测、历史查询、状态刷新、取消和失败交接。

用户输入: $ARGUMENTS

先统一心智模型

在开始之前，先按 automation-model.md 理解边界：

• pipeline 是执行与编排单元
• trigger 负责“怎么发起执行”，包括长期入口和即时运行
• 本 skill 负责“执行发起之后怎么管理 execution”
• 失败 execution 的根因分析属于 testany-debug

重要结论：

• 本 skill 不负责创建 Plan / Manual Trigger / Gatekeeper
• 本 skill 也不负责即时发起一次执行；这属于 testany-trigger
• 本 skill 关注 execution lifecycle：看、查、刷、停、交接

职责范围

• 查看 execution 详情与 case 级结果
• 列出/搜索 execution 历史
• 刷新 execution 状态
• 轮询等待 execution 进入终态
• 取消尚未开始的 execution
• 汇总执行结果并决定是否转给 testany-debug
• 在需要时获取 execution case 详情与日志签名入口

操作速查

核心知识

执行状态

Workspace 队列状态

Testany 使用 workspace 级并发槽位（Redis semaphore）控制 execution 并行度。通过 testany_get_workspace_execution_status 可获取：

当用户的 execution 状态为 NOT_STARTED 且长时间不变时，应主动查询队列状态：

• claimed 数量 = limit → 槽位已满，该 execution 在 pending 中排队
• claimed 中有长时间运行的旧 execution → 旧执行占住了槽位

当用户问"为什么我的 execution 不跑"时，这是第一个要检查的方向，优先于检查 YAML 和 relay。

本 skill 的标准处理链

trigger 已返回 execution_key
  -> testany_get_execution / testany_refresh_execution
  -> 状态进入终态
  -> 如失败，按需 testany_get_execution_case / testany_log_sign
  -> 必要时交给 testany-debug

典型工作流

1. 查看单次执行进度

适用输入：

• execution_key
• “看这次执行跑到哪了”

处理方式：

1. testany_get_execution
2. 如状态不新鲜或用户要求刷新，testany_refresh_execution
3. 汇报当前状态、开始时间、通过/失败数量

2. 轮询等待执行完成

适用输入：

• “帮我盯着这次执行直到结束”
• 已知 execution_key

处理方式：

1. testany_get_execution
2. 若未终态，则循环 testany_refresh_execution
3. 直到进入终态或达到超时上限

轮询建议：

• 初始间隔：5 秒
• 最大间隔：30 秒
• 默认超时：10-30 分钟，按 pipeline 复杂度调整

3. 查看历史执行

适用输入：

• “看最近失败的执行”
• “列出某个 pipeline 的最近执行”
• “看某个 workspace 的执行情况”

处理方式：

1. 视条件调用 testany_filter_execution_status / testany_filter_execution_pipelines
2. testany_list_executions
3. 必要时再 testany_get_execution

常用过滤维度：

• workspace
• pipeline_key
• status
• triggered_by
• env
• exe_start_time_from / exe_start_time_to

4. 取消 execution

适用输入：

• “取消这次还没开始的执行”

处理方式：

1. testany_get_execution
2. 仅当状态仍是未开始 / pending 时，调用 testany_cancel_execution
3. 如果已经开始运行，明确告知不能取消

5. 查看队列状态 / 诊断 execution 排队

适用输入：

• "为什么我的 execution 不跑"
• "YAML 是并行的但执行串行了"
• "看一下队列状态"
• "execution 一直 NOT_STARTED"

处理方式：

1. testany_get_workspace_execution_status → 获取 limit / claimed / pending
2. 判断并报告：

- claimed 数量是否 = limit（槽位满） - 用户关注的 execution 是否在 pending 列表中 - claimed 中是否有长时间运行的旧 execution 占住槽位

1. 如果槽位未满但 case 仍串行执行：

- 提示用户检查 pipeline YAML 版本（rule/v1.2 不支持 case 级并行） - 建议查看 case 的 start_time/finish_time 确认是否被串行调度 - 如需深入分析，切到 testany-debug（调度/队列诊断分支）

6. 将失败执行交给 debug

适用输入：

• “这个执行为什么失败”
• “帮我定位失败 case”

处理方式：

1. testany_get_execution
2. 找出失败 case
3. 如只需要定位，先 testany_get_execution_case
4. 如需要根因分析与日志解读，切到 testany-debug

边界澄清

什么时候去 testany-trigger

以下场景不属于本 skill：

• 现在立刻执行一次 pipeline
• 给 pipeline 配 Plan
• 创建 Manual Trigger
• 创建 Gatekeeper

这些都应切到 testany-trigger。

什么时候去 testany-debug

以下场景应转给 testany-debug：

• 用户要看失败根因
• 用户要读取与分析日志
• 用户要判断是断言失败、超时、依赖错误还是基础设施问题

返回格式

任务完成后，向用户汇报：

• Execution Key（如 Y2K-0601-0000B）
• 所属 Pipeline
• 当前状态或终态结果
• 通过/失败/跳过数量
• 失败 case 列表（如有）
• 是否可取消 / 是否已取消
• 下一步建议：

- 需要继续触发执行 → 去 testany-trigger - 需要分析失败原因 → 去 testany-debug

参考文档

• Testany 自动化对象模型
• 核心概念