git:20260428.f185a53 to git:20260914.a55b8c5

---

name: testany-debug

---

# Testany 故障诊断

分析 Testany 测试失败原因，排查问题根因。

用户输入: $ARGUMENTS

## 职责范围

- 分析测试执行失败的原因

- 获取和解读执行日志

- 识别常见问题模式

- 提供修复建议

## 核心知识

### 失败类型分类

| 类型 | 特征 | 常见原因 |

|------|------|---------|

| **Assertion** | 断言失败 | 预期值与实际值不符 |

| **Timeout** | 执行超时 | 接口响应慢、死循环 |

| **Error** | 运行时错误 | 代码异常、依赖缺失 |

| **Infrastructure** | 基础设施问题 | 网络不通、服务不可用 |

| **Scheduler / Queue** | 调度/排队问题 | 并发槽位占满、execution 排队、并行未生效 |

### 日志获取流程

按日志来源分两条路径：

**Execution 日志（pipeline 真实运行产物）**：

```

1. testany_get_execution → 获取执行概览

2. testany_get_execution_case → 获取失败 case 详情

3. testany_log_sign → 获取日志签名（返回 curlCommand）

```

**Dry run 日志（case 自身验证产物）**：

```

2. testany_get_dry_run_log → 拼出 logUrl + curlCommand（同样基于 sign）

```

注意：execution 和 dry run 共用同一套日志域 (`<runtime_uuid>.tr.<domain>/api/v2/logproxy/internal/view`) 和同一套 status 数值（1=SUCCESS、0=RUNNING、-1=NOT_STARTED），下面的安全验证规则两条路径都适用。

```bash

```

## 诊断工作流

1. **获取执行信息**：`testany_get_execution`

2. **定位失败 case**：从执行详情中找到失败的 case

3. **获取日志签名**：`testany_log_sign(executionKey, caseIndex)`

6. **分析日志**：识别错误类型和位置

7. **提供建议**：给出修复方向

## 常见问题速查

| 症状 | 可能原因 | 排查步骤 |

|------|---------|---------|

| Case 创建后无法执行 | runtime 未配置 | 检查 `runtime_uuid` |

| Relay 变量未传递 | type 配置错误 | 源 case 需 `type='output'`，目标需 `type='env'` |

| Pipeline 执行卡住 | 依赖 case 失败 | 检查 `whenPassed` 依赖的 case 状态 |

| 脚本执行报错 | executor 配置不匹配 | 检查 `trigger_path` 或 `trigger_command` |

| 超时 | 接口响应慢 | 检查被测服务状态，增加超时配置 |

| YAML 是并行但执行表现串行 | 平台调度限流 | **优先检查队列状态**（见下方调度诊断） |

| Execution 长时间 NOT_STARTED | 并发槽位被占满 | 检查 workspace 队列状态 |

| 多个 execution 互相排队 | queue.limit 限制 | 检查 claimed/pending 列表 |

## 调度 / 队列诊断（Scheduler / Queue）

**当用户报告"并行未生效"或"execution 卡住不跑"时，必须优先走这条诊断路径，再去排查 YAML 和 relay。**

### 核心概念

Testany 使用 **workspace 级并发槽位**控制 execution 并行度：

| 概念 | 含义 |

|------|------|

| `limit` | workspace 的并发上限（Community=2, Paid=4, Enterprise=8，可调） |

| `claimed` | 当前正在执行的 execution 列表（已占据槽位） |

| `pending` | 排队等待槽位的 execution 列表 |

| `trigger_group` | 触发源标识（`M-`=手动触发，`G-`=Gatekeeper，Plan key=计划触发） |

### 诊断流程

```

1. testany_get_workspace_execution_status → 获取 {limit, claimed, pending}

2. 判断：

- claimed 数量 = limit？→ 槽位已满，pending 中的 execution 必须等

- claimed 中有长时间运行的旧 execution？→ 旧执行占住了槽位

- pending 列表里有你关注的 execution？→ 它在排队，不是 YAML 问题

3. 如果槽位未满但 case 仍然串行：

- 检查 pipeline YAML 版本：rule/v1.2 不支持 case 级并行，只有 rule/v1.3 支持

- 检查 workspace 是否启用了并行执行功能

- 比对 case 的 start_time / finish_time：如果 case 间有明显间隔（>数秒），说明被平台串行调度

4. 如果是 fan-out pipeline（无 whenPassed/whenFailed 依赖）仍然串行：

- 大概率是 effectiveConcurrency=1 或 workspace 并行未开启

```

### 关键字段获取

| 要看的信息 | 获取方式 |

|-----------|---------|

| workspace 队列状态 | `testany_get_workspace_execution_status` → limit/claimed/pending |

| 单个 execution 详情 | `testany_get_execution` → status, start_time, trigger_group |

| case 级时间线 | `testany_get_execution` → cases[].start_time / finish_time |

| 确认 pipeline 版本 | 查看 pipeline YAML 的 `rule/v1.3` 或 `rule/v1.2` |

### 真实案例：fan-out pipeline 表现串行

**场景**：用户编排了一条 fan-out pipeline，token case → 25 个 Postman shard（YAML 无依赖，理论上并行），但实际串行执行。

**排查路径**：

1. `testany_get_workspace_execution_status` → 发现 `limit=1`，`claimed` 中有 1 个旧 execution

2. 说明 workspace 并发上限为 1，所有 execution 都串行排队

3. 进一步确认：`claimed` 中的旧 execution 完成后，pending 中的 execution 才逐一开始

4. 同一 execution 内部的 case 启动时间也呈串行——因为 case 级并行同样受 `effectiveConcurrency` 限制

**结论**：问题不在 YAML，不在 relay，不在 case 依赖——是平台调度层的并发限制。

**解决方向**：

- 联系管理员调整 workspace 的 `concurrency_limit`

- 确认 workspace 已启用并行执行功能（rule/v1.3 + allowlist）

- 如果是 Community 版，默认并发=2，无法通过 YAML 优化绕过

## 返回格式

诊断完成后，向用户汇报：

- 失败原因分类（Assertion/Timeout/Error/Infrastructure）

- 具体错误信息

- 问题定位（哪个 case、哪一步）

- 修复建议

## 参考文档

详细概念请参考：

- [核心概念](../testany-guide/references/concepts.md)