testany-case

Testany Platform Case Registration & CRUD

本 skill 通过 Testany MCP 工具管理 Testany 平台上的 platform cases。 所有操作都是对 Testany 平台的远程 API 调用，不涉及本地文件系统。

关键前提：

• Testany case 是可复用原子自动化步骤包
• Testany 不支持直接执行单条 case
• 如果用户要真正执行，后续仍需要 testany-pipeline

用户输入: $ARGUMENTS

---

宿主能力适配

• 优先使用宿主提供的结构化提问工具（如 AskUserQuestion）一次性收集缺失信息。
• 如果宿主不支持该工具，则用一条普通消息集中提问相同问题；低风险字段可给出默认值建议。
• 如果宿主支持 slash command，可推荐相关 workflow 的命令入口；否则直接在当前线程继续对应 workflow。

---

先统一心智模型

使用本 skill 前，先按 automation-model.md 理解边界：

• 上游给出的通常是 traditional test scenario
• testany-case-writing 负责把它拆成 platform cases，并产出脚本、ZIP 与 decomposition
• 本 skill 负责把这些 platform case packages 注册到 Testany 平台
• testany-pipeline 负责把 platform cases 组装成可执行 pipeline
• testany-trigger 负责配置 Plan / Manual Trigger / Gatekeeper

重要结论：

• 本 skill 的主路径不应该是“现场理解业务场景并写 case”
• 本 skill 的主路径应该是“消费上游已准备好的 package / metadata / decomposition，完成平台注册与生命周期管理”

---

职责

• 注册 testany-case-writing 已产出的 platform case packages
• 创建 case shell、补齐 case metadata、上传脚本 ZIP
• 查询、更新、批量更新、删除平台上的 platform cases
• 在变更后提醒用户检查下游 pipeline 影响面
• 在可行时触发 dry run 验证 case 是否 ready

不负责的事情

• 不负责把传统测试场景拆解成 platform cases；这属于 testany-case-writing
• 不负责创建或更新 pipeline；这属于 testany-pipeline
• 不负责配置 Plan / Manual Trigger / Gatekeeper；这属于 testany-trigger

---

操作速查

用户意图	操作类型	工具
注册新的 platform case	Create	testany_create_case → testany_update_case → testany_update_case_script
查看 case 详情	Read	testany_get_case
查看 case 脚本内容	Read	testany_get_case_script
搜索/列出 cases	Read	testany_list_cases
列出我的 cases	Read	testany_list_my_cases
更新 metadata / script	Update	testany_update_case / testany_update_case_script
删除 case	Delete	testany_delete_case
批量更新 cases	Bulk Update	testany_bulk_update_cases
批量删除 cases	Bulk Delete	testany_bulk_delete_cases
dry run 验证	Validate	testany_dry_run_case → testany_get_dry_run_result

---

Create（注册新的 platform case）

Phase 0: 先判断输入模式

按以下优先级选择输入模式：

1. Primary：已有 platform case package

   • 来自 testany-case-writing
   • 已准备好脚本、ZIP、metadata、executor 选择
   • 最适合本 skill

2. Secondary：已有脚本/ZIP，但 metadata 不完整

   • 可以在本 skill 中补齐名称、可见性、labels、case_meta 等字段

3. Fallback：只想先创建草稿 shell case

   • 仅当用户明确要求占位、预留 key、先建空壳时使用
   • 不能把它包装成“已经完成自动化落地”

如果用户只有传统测试场景，没有脚本、ZIP、decomposition：

• 停止直接创建
• 切到 testany-case-writing

Phase 1: 准备可选项

并行获取：

• testany_filter_case_runtimes
• testany_get_my_workspaces

如涉及 labels，先：

• testany_list_labels
• 如缺失再 testany_create_label

Phase 2: 收集注册所需字段

优先一次性收集以下内容：

字段	必填	说明
name	是	platform case 名称
runtime_uuid	是	运行环境 UUID，推荐 cloudprime
is_private	是	Global / Private
workspace_keys	条件必填	私有 case 需要
description	建议	说明该 platform case 的原子职责
case_labels	建议	用于目录视图和检索
case_meta	条件必填	运行所需配置，具体字段见 executors reference
ZIP / 脚本包	条件必填	若目标是注册 runnable case，通常需要

收集原则：

• 主路径假设用户已经有 package；本 skill 只做“平台注册与补齐元数据”
• 如果用户明确只要草稿 case，可暂不上传 ZIP，但必须明确这是占位资产，不可直接执行

Phase 3: 创建 shell case

调用 testany_create_case：

• name
• runtime_uuid
• is_private
• workspace_keys

Phase 4: 补齐 metadata / 运行配置

调用 testany_update_case 设置：

• description
• case_labels
• environments
• owned_by
• case_version
• case_meta

这里的 case_meta 后端字段名仍然是 trigger_method，但它表示的是 case 级运行入口配置：

• executor
• trigger_path
• trigger_command

它不等于 Plan / Manual Trigger / Gatekeeper 这类 pipeline trigger。

详细字段规则见：

• Case 元数据规范
• Executor 配置详解

Phase 5: 上传脚本 ZIP

如果用户已经准备好脚本包，调用 testany_update_case_script 上传。

如脚本中包含以下能力，提醒用户同步补齐配置：

• Relay 输出
• Secure key / credential 引用

Phase 6: 可选 dry run

如用户要求验证，或刚补齐了必填字段：

1. testany_dry_run_case
2. testany_get_dry_run_result

Phase 7: 明确 downstream handoff

创建完成后，必须显式说明：

• 这是已注册的 platform case
• 如果用户要形成可执行链路，下一步需要 testany-pipeline
• 即使只有一个 case，要在 Testany 中执行也仍需一条 pipeline

---

Read（查询）

场景	工具	说明
获取单个 case 详情	testany_get_case	传入 case key
获取 case 脚本内容	testany_get_case_script	下载 ZIP 并返回文件内容
搜索所有 cases	testany_list_cases	支持 workspace / keyword / page 等过滤
列出我的 cases	testany_list_my_cases	适合个人资产盘点

---

Update（更新）

可更新的字段

字段	说明
name	case 名称
description	原子职责说明
is_private	可见性
workspace_keys	私有 case 的工作空间列表
environments	环境标签
case_labels	分类标签
case_version	版本号
owned_by	所有者
case_meta	运行配置
脚本 ZIP	通过 testany_update_case_script 上传

更新流程

1. testany_get_case 获取当前配置
2. 确认要修改的字段
3. testany_update_case 提交 metadata 更新
4. 如需替换脚本，再 testany_update_case_script

必须提醒用户检查下游 pipeline 的情况

如果修改了以下内容，必须提示用户同步检查相关 pipeline：

• executor 相关配置
• 脚本入口或运行命令
• Relay 输出变量
• 输入环境变量名称
• 脚本内部行为导致的输入/输出变化

原因：

• pipeline 可能依赖该 case 的 relay、顺序或输入输出约定
• 平台 case 是可复用资产，case 变更可能影响多个 pipeline

如果用户下一步就要修这些引用关系，切到 testany-pipeline。

---

Delete（删除）

单个删除

调用 testany_delete_case 前，必须先明确告知用户：

• 如果该 case 已被编排到一个或多个 pipeline 中，平台会返回 409
• 需要先把该 case 从相关 pipeline 中移除，才能删除
• 如果该 case 是 Git 导入资产，也可能无法手动删除

当前限制：

• 如 MCP 侧没有现成的 “used by pipeline” 查询工具，则无法在删除前完全自动 preflight
• 因此应把删除结果视为“可能失败的受约束操作”，而不是无条件直删

如果删除失败并返回 409：

• 明确向用户解释原因
• 建议先去 testany-pipeline 解除组装关系，再重试

批量删除

testany_bulk_delete_cases 同样受上述约束：

• 任何已被 pipeline 组装的 case 都会导致删除受阻
• 先提醒风险，再执行

---

Labels 与目录视图

Testany 使用 case_labels 实现虚拟目录结构：

• 一个 case 可以有多个 labels
• Labels 必须先存在，才能在 case 上引用

典型流程：

1. testany_list_labels
2. 如缺失，testany_create_label
3. testany_update_case / testany_bulk_update_cases / testany_bulk_append_cases

---

Dry Run（验证）

dry run 只验证 case 本身是否 ready，不替代 pipeline 编排验证。

流程：

1. testany_dry_run_case
2. testany_get_dry_run_result

典型用途：

• 新上传脚本后确认 case 已可运行
• 更新必填字段后确认配置完整

---

常见问题处理

场景	处理方式
用户只有传统测试场景，没有 package	先去 testany-case-writing
用户要注册多个原子步骤	按 package inventory 逐个创建/更新 case
用户希望形成可执行链路	case 注册后继续到 testany-pipeline
用户想删除 case	先提醒 pipeline 组装约束与 409 风险
用户更新了 relay / 输入输出相关字段	提醒同步检查相关 pipeline

---

返回格式

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

• Case Key（如 A1B2C3D4）
• Case 名称
• 该 case 的原子职责
• 是否已上传脚本 ZIP
• 可见性（Global / Private + 工作空间列表）
• 是否已 dry run
• 下一步建议：
  • 注册完成但尚未可执行 → 去 testany-pipeline
  • 已有 pipeline 但缺执行入口 → 去 testany-trigger

---

参考文档

• Testany 自动化对象模型
• Case 元数据规范
• Executor 配置详解
• 核心概念