| name | testany-case-writing |
| description | Testany platform case 编写助手 - 将传统测试场景拆解为 Testany platform cases，并生成可注册的 case packages |
| argument-hint | [需求描述]，如：根据 test spec 拆解登录场景、把订阅流程写成可上传到 Testany 的 cases |
Testany Platform Case Writing
将传统测试场景拆解为 Testany platform cases，并生成可注册到 Testany 平台的脚本、metadata 和 ZIP 包。
用户输入: $ARGUMENTS
宿主能力适配
- 如果宿主支持 slash command，可把
testany-case 作为推荐注册入口，把 testany-pipeline 作为推荐编排入口。
- 如果宿主不支持 slash command，则直接在当前线程继续对应 workflow。
上游输入优先级
按以下优先级选择输入模式：
- Primary：approved Test Spec +
Testany Automation Handoff
- 来自
testany-eng
Testany Automation Handoff.status = ready | partial- 这是本 skill 的首选输入
- Secondary：approved Test Spec，但没有 handoff
- 可以继续，但需要自己补做 scenario grouping / executor / split decisions
- Fallback：用户自然语言 / 现有测试设计文档
如果输入来自 Test Spec，优先参考：
../../../testany-eng/references/testany-automation-handoff-contract.mdTestany Automation Handoff section 中的 scenario_groupssource_case_ids、recommended_executor、platform_case_strategy
若输入 Test Spec 仍是 draft / in_review：
- 默认不要直接把它当正式自动化基线
- 应先建议用户完成
testany-eng 的 /test-reviewer
- 只有当用户明确接受 exploratory / 草案态自动化拆分时，才继续，并显式标注为低置信度
先统一心智模型
在开始之前，先按 automation-model.md 理解对象边界：
- 用户给出的通常是 traditional test scenario，也就是完整测试场景/业务验证目标。
- 本 skill 产出的是 Testany platform case，也就是可复用的原子自动化步骤包。
- pipeline 才是 Testany 的执行与编排单元。
- trigger 是
Plan / Manual Trigger / Gatekeeper，作用于 pipeline，而不是 case。
重要结论：
- 不要默认把“一个传统测试场景”直接写成“一个 Testany case”。
- 先判断该场景需要拆成几个 platform cases，再写脚本和 ZIP。
职责
- 消费传统测试场景输入：approved
test-spec、Testany Automation Handoff、用户自然语言、现有测试设计文档
- 判断一个场景要拆成几个 Testany platform cases
- 为每个 platform case 选择合适的 Executor
- 生成每个 platform case 的 metadata、脚本和 ZIP 包
- 产出面向下游的 automation design / decomposition summary
不负责的事情
- 不负责把 case 注册到 Testany 平台；这属于
testany-case
- 不负责创建/更新 pipeline；这属于
testany-pipeline
- 不负责配置 Plan / Manual Trigger / Gatekeeper；这属于
testany-trigger
工作流程
Phase 0: 判定输入模式与可信度
如果输入来自 Test Spec，先检查：
- Test Spec 是否为
approved
- 是否存在
Testany Automation Handoff
Testany Automation Handoff.status 是 ready、partial 还是 not_planned
处理规则：
ready：把 handoff 当作第一优先输入partial：把 handoff 当作基线，并集中追问 open_questionsnot_planned：默认不要继续；只有用户明确要求覆盖该决定时才继续- section 缺失：降级为 Secondary 模式，从 Test Spec 正文补做 decomposition
Phase 1: 理解输入场景
优先收集以下信息：
- 场景目标：要验证什么业务行为或系统行为
- 输入来源：来自 approved
test-spec、Testany Automation Handoff、用户口述，还是已有测试文档
- 技术约束：API / UI / Java / Python / Postman / Playwright
- 关键依赖：登录态、创建资源、清理动作、失败分支、回滚动作
Phase 2: 先做 decomposition，再写代码
必须先判断一个传统测试场景在 Testany 平台上应拆成几个 platform cases。
若上游已经给出 Testany Automation Handoff：
- 优先沿用
scenario_groups
- 优先沿用
recommended_executor
- 优先沿用
platform_case_strategy
- 只有当 handoff 与 Test Spec 正文明显冲突时，才回退到人工重新分解，并把冲突显式回报给用户
优先拆成多个 platform cases 的情况：
- 某一步会产出 relay 输出给下游复用
- 某一步本身是可复用前置条件，例如登录、创建资源、清理资源
- 不同步骤需要不同 executor / runtime
- 存在条件分支、失败分支或
expect: fail
- 你希望主流程、校验流程、清理流程分开维护
可以保持为单个 platform case 的情况：
- 整个动作天然原子
- 不需要 relay 给下游
- 不需要条件分支或跨 case 依赖
- 单一 executor 即可稳定表达
Phase 3: 为每个 platform case 产出 package
每个 platform case 至少要产出：
namedescriptioncase_labelsexecutorpath 或 commandenvironment_variables- 如需 relay：
type=output 的输出变量
- 代码文件
- ZIP 包
Phase 4: 明确 downstream handoff
完成 case package 后，必须显式说明：
- 本次共拆出多少个 platform cases
- 每个 case 的职责、输入、输出、executor
- 每个 case 对应的
source_case_ids
- 哪些 case 之间存在依赖
- 是否需要 relay
- 是否需要
testany-pipeline 继续编排
强制规则：
- 如果存在依赖、relay、条件分支、清理分支、失败分支，必须产出“需要后续 pipeline 编排”的结论，不能停在 ZIP。
- 即使只有一个 platform case，只要用户要的是“可执行资产”，也应明确说明后续仍需要一条 pipeline 才能在 Testany 中运行。
Phase 5: 引导下游 workflow
- 如果用户要把 package 注册到平台：切到
testany-case
- 如果用户要形成可执行链路：继续到
testany-pipeline
- 如果用户要配置执行入口：再继续到
testany-trigger
推荐输出结构
1. Scenario Summary
2. Platform Case Inventory
对每个 platform case 给出：
- 别名 / 本地文件名
source_case_ids- 目标动作
- executor
- 输入变量
- 输出变量
- ZIP 包路径
3. Automation Design Summary
single-case runnable?：是否只是单个原子步骤pipeline required：默认 yesdependencies：A -> B -> Crelay map：例如 LOGIN.AUTH_TOKEN -> SUBSCRIBE.AUTH_TOKENbranching：是否存在 whenFailed / expect: fail
4. Next Step
- 注册这些 platform cases →
testany-case
- 组装 pipeline →
testany-pipeline
Executor 选择决策树
Platform case 类型
├─ API 调用 / Python 优先 → PyRes ✓
├─ API 调用 / 不想写代码 → Postman
├─ UI / E2E 步骤 → Playwright
└─ Java 项目测试 → Maven 或 Gradle
根据选择的 Executor，参考对应模板：
注意：executor 是后端严格字符串。本 skill 涉及的取值为：pyres, postman, playwright, maven, gradle（平台还支持 python, jmeter）。
环境变量类型（case_meta.environment_variables.type）
| 类型 | 用途 | 示例 |
|---|
env | 输入/普通配置（包括 relay 输入） | API_BASE_URL, AUTH_TOKEN |
output | Relay 输出 | ACCESS_TOKEN, USER_ID |
secrets | 引用 workspace Credential Safe 条目 | PASSWORD, API_KEY |
约束（与平台校验一致）：
type 支持 env / output / secretsname 必须以大写字母开头，只能包含大写字母、数字、下划线；同一 case 内必须唯一env / output：name/value 不能为空或仅空白字符；如需表达"空值"，请显式填 -secrets：必须填 secret_ref: { workspace_key, credential_safe_key, credential_key }，禁止填 value；脚本里直接读同名环境变量即可（如 os.getenv("PASSWORD")）secrets 的 credential_safe_key / credential_key 如果未知，在注册阶段（testany-case skill）用 testany_list_credential_safes → testany_list_credential_keys 查询（两个工具都需要 runtime_uuid，返回签名 curl 由 agent 代为执行）；详细流程见 testany-case/references/executors.mdsecrets 读回时附带只读字段 status（valid / blocked / invalid）和 status_reasons[]；写入时不要传
Output Relay 关键规则
Relay 是 pipeline 层编排 + case 层输出配置 的组合能力。只有同时满足两端约束才有效。
Output Case
- 在 case metadata 中声明
type: output 的变量
- 在代码中把同名 key POST 到
TESTANY_OUTPUT_RELAY_SERVICE
Input Case
- 在 case metadata 中声明
type: env 的变量
- 在代码中作为环境变量读取
编排层
- 由
testany-pipeline 在 pipeline YAML 中配置 relay.key 与 relay.refKey
- 只有 passed 的上游 case 才能提供 relay 数据
如果你已经识别出 relay 需求，必须在输出中明确告诉下游：
- 哪个 case 产出什么变量
- 哪个 case 消费该变量
- 后续需要
testany-pipeline 进行 relay 编排
完成后
交付时必须告诉用户：
- 本次传统测试场景被拆成了几个 platform cases
- 已生成的文件列表和 ZIP 包位置
- 哪些 case 需要注册到 Testany
- 是否必须继续到
testany-pipeline
- 如宿主支持 slash command，可建议
/testany-case 和 /testany-pipeline
- 若本次输入来自 Test Spec，应明确回显所消费的
source_case_ids 与 scenario_groups
参考文档
本地 References
文档（兜底）
如果本地 references 不足以解决问题，请查阅 Testany 文档中心；当本 skill 的示例与文档不一致时，以文档为准：
