testany-case-writing
installsforks
How to install testany-case-writing?
testany-io/testany-agent-skills/testany-case-writing
$npx -y skills add TestAny-io/testany-agent-skills --skill testany-case-writingTestany platform case 编写助手 - 将传统测试场景拆解为 Testany platform cases，并生成可注册的 case packages
SKILL.md
| 1 | # Testany Platform Case Writing |
| 2 | |
| 3 | 将传统测试场景拆解为 **Testany platform cases**，并生成可注册到 Testany 平台的脚本、metadata 和 ZIP 包。 |
| 4 | |
| 5 | 用户输入: $ARGUMENTS |
| 6 | |
| 7 | --- |
| 8 | |
| 9 | ## 宿主能力适配 |
| 10 | |
| 11 | - 如果宿主支持 slash command，可把 `testany-case` 作为推荐注册入口，把 `testany-pipeline` 作为推荐编排入口。 |
| 12 | - 如果宿主不支持 slash command，则直接在当前线程继续对应 workflow。 |
| 13 | |
| 14 | --- |
| 15 | |
| 16 | ## 上游输入优先级 |
| 17 | |
| 18 | 按以下优先级选择输入模式： |
| 19 | |
| 20 | 1. **Primary：approved Test Spec + `Testany Automation Handoff`** |
| 21 | - 来自 `testany-eng` |
| 22 | - `Testany Automation Handoff.status = ready | partial` |
| 23 | - 这是本 skill 的首选输入 |
| 24 | 2. **Secondary：approved Test Spec，但没有 handoff** |
| 25 | - 可以继续，但需要自己补做 scenario grouping / executor / split decisions |
| 26 | 3. **Fallback：用户自然语言 / 现有测试设计文档** |
| 27 | - 仅在前两者都没有时使用 |
| 28 | |
| 29 | 如果输入来自 Test Spec，优先参考： |
| 30 | |
| 31 | - `../../../testany-eng/references/testany-automation-handoff-contract.md` |
| 32 | - `Testany Automation Handoff` section 中的 `scenario_groups` |
| 33 | - `source_case_ids`、`recommended_executor`、`platform_case_strategy` |
| 34 | |
| 35 | 若输入 Test Spec 仍是 `draft` / `in_review`： |
| 36 | |
| 37 | - 默认不要直接把它当正式自动化基线 |
| 38 | - 应先建议用户完成 `testany-eng` 的 `/test-reviewer` |
| 39 | - 只有当用户明确接受 exploratory / 草案态自动化拆分时，才继续，并显式标注为低置信度 |
| 40 | |
| 41 | --- |
| 42 | |
| 43 | ## 先统一心智模型 |
| 44 | |
| 45 | 在开始之前，先按 [automation-model.md](../testany-guide/references/automation-model.md) 理解对象边界： |
| 46 | |
| 47 | - 用户给出的通常是 **traditional test scenario**，也就是完整测试场景/业务验证目标。 |
| 48 | - 本 skill 产出的是 **Testany platform case**，也就是可复用的原子自动化步骤包。 |
| 49 | - **pipeline** 才是 Testany 的执行与编排单元。 |
| 50 | - **trigger** 是 `Plan / Manual Trigger / Gatekeeper`，作用于 pipeline，而不是 case。 |
| 51 | |
| 52 | **重要结论**： |
| 53 | - 不要默认把“一个传统测试场景”直接写成“一个 Testany case”。 |
| 54 | - 先判断该场景需要拆成几个 platform cases，再写脚本和 ZIP。 |
| 55 | |
| 56 | --- |
| 57 | |
| 58 | ## 职责 |
| 59 | |
| 60 | - 消费传统测试场景输入：approved `test-spec`、`Testany Automation Handoff`、用户自然语言、现有测试设计文档 |
| 61 | - 判断一个场景要拆成几个 Testany platform cases |
| 62 | - 为每个 platform case 选择合适的 Executor |
| 63 | - 生成每个 platform case 的 metadata、脚本和 ZIP 包 |
| 64 | - 产出面向下游的 **automation design / decomposition summary** |
| 65 | |
| 66 | --- |
| 67 | |
| 68 | ## 不负责的事情 |
| 69 | |
| 70 | - **不**负责把 case 注册到 Testany 平台；这属于 `testany-case` |
| 71 | - **不**负责创建/更新 pipeline；这属于 `testany-pipeline` |
| 72 | - **不**负责配置 Plan / Manual Trigger / Gatekeeper；这属于 `testany-trigger` |
| 73 | |
| 74 | --- |
| 75 | |
| 76 | ## 工作流程 |
| 77 | |
| 78 | ### Phase 0: 判定输入模式与可信度 |
| 79 | |
| 80 | 如果输入来自 Test Spec，先检查： |
| 81 | |
| 82 | 1. Test Spec 是否为 `approved` |
| 83 | 2. 是否存在 `Testany Automation Handoff` |
| 84 | 3. `Testany Automation Handoff.status` 是 `ready`、`partial` 还是 `not_planned` |
| 85 | |
| 86 | 处理规则： |
| 87 | |
| 88 | - `ready`：把 handoff 当作**第一优先输入** |
| 89 | - `partial`：把 handoff 当作基线，并集中追问 `open_questions` |
| 90 | - `not_planned`：默认不要继续；只有用户明确要求覆盖该决定时才继续 |
| 91 | - section 缺失：降级为 Secondary 模式，从 Test Spec 正文补做 decomposition |
| 92 | |
| 93 | ### Phase 1: 理解输入场景 |
| 94 | |
| 95 | 优先收集以下信息： |
| 96 | 1. 场景目标：要验证什么业务行为或系统行为 |
| 97 | 2. 输入来源：来自 approved `test-spec`、`Testany Automation Handoff`、用户口述，还是已有测试文档 |
| 98 | 3. 技术约束：API / UI / Java / Python / Postman / Playwright |
| 99 | 4. 关键依赖：登录态、创建资源、清理动作、失败分支、回滚动作 |
| 100 | |
| 101 | ### Phase 2: 先做 decomposition，再写代码 |
| 102 | |
| 103 | 必须先判断一个传统测试场景在 Testany 平台上应拆成几个 platform cases。 |
| 104 | |
| 105 | 若上游已经给出 `Testany Automation Handoff`： |
| 106 | |
| 107 | - 优先沿用 `scenario_groups` |
| 108 | - 优先沿用 `recommended_executor` |
| 109 | - 优先沿用 `platform_case_strategy` |
| 110 | - 只有当 handoff 与 Test Spec 正文明显冲突时，才回退到人工重新分解，并把冲突显式回报给用户 |
| 111 | |
| 112 | 优先拆成多个 platform cases 的情况： |
| 113 | - 某一步会产出 relay 输出给下游复用 |
| 114 | - 某一步本身是可复用前置条件，例如登录、创建资源、清理资源 |
| 115 | - 不同步骤需要不同 executor / runtime |
| 116 | - 存在条件分支、失败分支或 `expect: fail` |
| 117 | - 你希望主流程、校验流程、清理流程分开维护 |
| 118 | |
| 119 | 可以保持为单个 platform case 的情况： |
| 120 | - 整个动作天然原子 |
| 121 | - 不需要 relay 给下游 |
| 122 | - 不需要条件分支或跨 case 依赖 |
| 123 | - 单一 executor 即可稳定表达 |
| 124 | |
| 125 | ### Phase 3: 为每个 platform case 产出 package |
| 126 | |
| 127 | 每个 platform case 至少要产出： |
| 128 | - `name` |
| 129 | - `description` |
| 130 | - `case_labels` |
| 131 | - `executor` |
| 132 | - `path` 或 `command` |
| 133 | - `environment_variables` |
| 134 | - 如需 relay：`type=output` 的输出变量 |
| 135 | - 代码文件 |
| 136 | - ZIP 包 |
| 137 | |
| 138 | ### Phase 4: 明确 downstream handoff |
| 139 | |
| 140 | 完成 case package 后，必须显式说明： |
| 141 | - 本次共拆出多少个 platform cases |
| 142 | - 每个 case 的职责、输入、输出、executor |
| 143 | - 每个 case 对应的 `source_case_ids` |
| 144 | - 哪些 case 之间存在依赖 |
| 145 | - 是否需要 relay |
| 146 | - 是否需要 `testany-pipeline` 继续编排 |
| 147 | |
| 148 | **强制规则**： |
| 149 | - 如果存在依赖、relay、条件分支、清理分支、失败分支，**必须**产出“需要后续 pipeline 编排”的结论，不能停在 ZIP。 |
| 150 | - 即使只有一个 platform case，只要用户要的是“可执行资产”，也应明确说明后续仍需要一条 pipeline 才能在 Testany 中运行。 |
| 151 | |
| 152 | ### Phase 5: 引导下游 workflow |
| 153 | |
| 154 | - 如果用户要把 package 注册到平台：切到 `testany-case` |
| 155 | - 如果用户要形成可执行链路：继续到 `testany-pipeline` |
| 156 | - 如果用户要配置执行入口：再继续到 `testany-trigger` |
| 157 | |
| 158 | --- |
| 159 | |
| 160 | ## 推荐输出结构 |
| 161 | |
| 162 | ### 1. Scenario Summary |
| 163 | |
| 164 | - 原始传统测试场景是什么 |
| 165 | - 为什么这样拆分 |
| 166 | |
| 167 | ### 2. Platform Case Inventory |
| 168 | |
| 169 | 对每个 platform case 给出： |
| 170 | - 别名 / 本地文件名 |
| 171 | - `source_case_ids` |
| 172 | - 目标动作 |
| 173 | - executor |
| 174 | - 输入变量 |
| 175 | - 输出变量 |
| 176 | - ZIP 包路径 |
| 177 | |
| 178 | ### 3. Automation Design Summary |
| 179 | |
| 180 | - `single-case runnable?`：是否只是单个原子步骤 |
| 181 | - `pipeline required`：默认 `yes` |
| 182 | - `dependencies`：A -> B -> C |
| 183 | - `relay map`：例如 `LOGIN.AUTH_TOKEN -> SUBSCRIBE.AUTH_TOKEN` |
| 184 | - `branching`：是否存在 `whenFailed` / `expect: fail` |
| 185 | |
| 186 | ### 4. Next Step |
| 187 | |
| 188 | - 注册这些 platform cases → `testany-case` |
| 189 | - 组装 pipeline → `testany-pipeline` |
| 190 | |
| 191 | --- |
| 192 | |
| 193 | ## Executor 选择决策树 |
| 194 | |
| 195 | ``` |
| 196 | Platform case 类型 |
| 197 | ├─ API 调用 / Python 优先 → PyRes ✓ |
| 198 | ├─ API 调用 / 不想写代码 → Postman |
| 199 | ├─ UI / E2E 步骤 → Playwright |
| 200 | └─ Java 项目测试 → Maven 或 Gradle |
| 201 | ``` |
| 202 | |
| 203 | 根据选择的 Executor，参考对应模板： |
| 204 | |
| 205 | | Executor | 模板文件 | 适用场景 | |
| 206 | |----------|---------|---------| |
| 207 | | PyRes | [pyres.md](./references/executors/pyres.md) | Python API 测试（推荐） | |
| 208 | | Postman | [postman.md](./references/executors/postman.md) | 快速 API 验证 | |
| 209 | | Playwright | [playwright.md](./references/executors/playwright.md) | UI |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
