with one click
分析 Testany 测试失败原因 - 排查问题、查看日志、定位根因
npx skills add https://github.com/TestAny-io/testany-agent-skills --skill testany-debugCopy and paste this command into Claude Code to install the skill
分析 Testany 测试失败原因 - 排查问题、查看日志、定位根因
npx skills add https://github.com/TestAny-io/testany-agent-skills --skill testany-debugCopy and paste this command into Claude Code to install the skill
从 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诊断完成后,向用户汇报:
详细概念请参考: