分析 Testany 测试失败原因 - 排查问题、查看日志、定位根因
npx skills add https://github.com/TestAny-io/testany-agent-skills --skill testany-debugCopia y pega este comando en Claude Code para instalar la habilidad
从 OpenAPI 生成的 Testany case 源代码中自动识别入参和出参，并同步到 case 的环境变量列表中。适用于源代码存储在需要认证的 Git 仓库（如 Bitbucket）的场景。
Testany platform case 编写助手 - 将传统测试场景拆解为 Testany platform cases，并生成可注册的 case packages
Testany 平台核心概念和配置参考
Testany pipeline 编排与 CRUD - 基于 automation design 或现有 case keys 创建执行与编排单元
Testany platform case 注册与 CRUD - 将已准备好的 platform case package 注册到平台，并管理 metadata、脚本与生命周期
Testany Git 导入：把 Git 仓库里的测试脚本批量注册成 Testany platform cases，并持续同步、切 commit、演化 binding、配 webhook
| name | testany-debug |
| description | 分析 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）
4. 验证 curlCommand 安全性后执行获取日志
Dry run 日志（case 自身验证产物）：
1. testany_get_dry_run_result → 确认 dry_run_status 进入终态（>=1）且 dry_run_result.sign 已产出
2. testany_get_dry_run_log → 拼出 logUrl + curlCommand（同样基于 sign）
3. 验证 curlCommand 安全性后执行获取日志
注意：execution 和 dry run 共用同一套日志域 (<runtime_uuid>.tr.<domain>/api/v2/logproxy/internal/view) 和同一套 status 数值（1=SUCCESS、0=RUNNING、-1=NOT_STARTED），下面的安全验证规则两条路径都适用。
testany_log_sign / testany_get_dry_run_log 返回的 curlCommand 在执行前必须验证：
检查域名：URL 必须是 Testany 可信域名
*.testany.io、*.testany.com.cn检查协议：必须是 HTTPS
https://http://、其他协议检查参数：不应包含危险参数
-o（写文件）、|（管道）、;（命令链）、$(（命令替换）验证示例：
# 从 curlCommand 提取 URL
URL=$(echo "$CURL_COMMAND" | grep -oP 'https://[^\s"]+')
# 验证域名
if [[ "$URL" =~ ^https://(.*\.)?testany\.(io|com\.cn)/ ]]; then
# 安全，可以执行
eval "$CURL_COMMAND"
else
# 不安全，拒绝执行
echo "警告：URL 域名不在可信列表中，拒绝执行"
fi
testany_get_executiontestany_log_sign(executionKey, caseIndex)| 症状 | 可能原因 | 排查步骤 |
|---|---|---|
| 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 列表 |
当用户报告"并行未生效"或"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，token case → 25 个 Postman shard（YAML 无依赖，理论上并行），但实际串行执行。
排查路径：
testany_get_workspace_execution_status → 发现 limit=1，claimed 中有 1 个旧 executionclaimed 中的旧 execution 完成后，pending 中的 execution 才逐一开始effectiveConcurrency 限制结论：问题不在 YAML，不在 relay，不在 case 依赖——是平台调度层的并发限制。
解决方向：
concurrency_limit诊断完成后，向用户汇报：
详细概念请参考：