القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/TestAny-io/testany-agent-skills --skill testany-debugيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| 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诊断完成后，向用户汇报：
详细概念请参考：