qa-write-test-cases

测试用例与检查清单生成器

根据用户提供的上下文，生成软件测试用例和检查清单。

参考资料：

• 测试用例格式 — 套件、测试和步骤的 Markdown 格式（兼容 Testomat.io）
• 编写规则 — 关于套件、测试、前置条件、步骤以及应避免的 AI 写作模式的规则
• Testomat.io TMS 指南 — Testomat.io 约定和 MCP 工具

前置条件

• 已通过 /scan-automation-project 技能检查项目结构（源代码、端到端测试、测试用例）。
• 已通过 /sync-test-cases-with-tms 技能获取现有 Testomat.io 测试。
• 在访谈步骤中，如有条件，请启用 PLAN 模式。

用户交互

• 始终先生成检查清单，再生成测试用例，即使用户直接要求生成测试用例。
• 不要跳过步骤。每个关卡都必须获得用户批准，才能进入下一步。
• 严格建议使用 PLAN 模式。仅在最后一步（将测试用例写入 md 文件）切换到 Edit 模式。
• 如有条件，请使用 Ask 工具提供选项。
• 询问用户输入时，请在输入字段中填写建议。
• 使用 ❓ 标记问题，并为选项编号：

❓ Do you want to:

1. action 1
2. action 2
3. type something else

工作流

1. 收集上下文并展示来源 — 审批关卡
2. 询问覆盖范围 — 审批关卡
3. 如果此功能已有测试用例，则询问角色；冒烟测试始终跳过此步骤
4. 生成检查清单 — 审批关卡
5. 生成详细测试用例
6. 展示摘要

第 1 步：收集上下文

了解：

• 正在测试的功能及其业务目标
• 主要测试流程和用户旅程
• 需要重点关注的具体方面

信息来源：

• 用户提示
• 任务跟踪系统（Jira 等）
• 需求文档（Confluence 等）
• 设计原型（Figma、Miro 等）
• 现有测试用例（TestRail、Testomat.io 等）
• 源代码：
  • 手动测试文件：.test.md，或 test-cases、tests、manual、qa、spec 等目录中的 .md 文件
  • 自动化测试文件（spec、test、cy 文件等）
  • 项目结构

来源可以是粘贴的文本、链接或 MCP 工具。如有需要，请向用户索取 MCP 配置。

分析源代码：

• 通常，此技能会在没有应用代码的自动化项目中运行。请先确认属于哪种情况。
• 仅有自动化的项目：快速扫描，重点查看测试文件。
• 应用与自动化并存的项目：全面扫描应用代码；除非用户要求，否则无需深入分析单元测试。

Testomat.io TMS 检测

检测项目是否使用 Testomat.io。两种方式：

方式 1 — MCP。如果 testomatio MCP 可用，请收集上下文：

• suites_list、suites_search — 现有结构
• tests_search、tests_list — 现有测试，避免重复
• steps_list、steps_search — 可复用的共享步骤
• tags_list、labels_list — 项目约定

方式 2 — sync-test-cases-with-tms 技能（使用 check-tests lib）。运行该技能并使用 pull 操作，然后分析下载的文件，了解：

• 现有结构和套件
• 当前测试用例（避免重复）
• 项目约定（标签、优先级）

如果现有测试用例与正在测试的功能有关联，请向用户报告，并建议扩展这些用例或创建新套件。

审批关卡

仅展示来源名称（不显示内容），并提问：

I've gathered information from the following sources:

- Jira issue ABC-123
- Confluence
- Figma

❓ Do you want to:

1. ➡️ Go to next step
2. ✏️ Type changes

Step 2: 询问覆盖范围

范围决定初始检查清单的规模；用户仍可在 Step 4 中进一步调整。

• 根据 Step 1 的分析估算各层级的大致测试数量。不要使用通用或硬编码的范围——数字必须反映正在测试的具体功能。
• 如果无法合理估算（功能过于模糊、上下文太少），请说明，并省略数字或返回 Step 1。
• 如果用户选择 ✏️ Other，请接受数字（“大约 10 个”）或自由描述（“只测 API 契约，不测 UI”），并据此确定检查清单的规模。

将每个选项显示为一个区块：第一行显示粗体标签和测试数量，下一行显示描述。将 <N> 替换为估算值：

❓ **How much coverage do you want?**

**1. 🚀 Smoke** ~<N> tests
Critical-path only

**2. ⚖️ Balanced** ~<N> tests
Happy path, key negative and common edge cases

**3. 🧨 Exhaustive** ~<N> tests
Full coverage incl. error states, boundaries, and security/perf/i18n where relevant

**4. ✏️ Other**
Type a number of tests, or describe scope in your own words

Step 3: 询问角色

只有当 Step 1 发现了正在测试功能的现有测试用例时，才询问角色。基本内容已经覆盖，用户可能希望从特定角度进行测试。

对于“smoke”范围，也跳过此步骤。

如果用户已经指定了角色或关注点（在提示词中，或通过 Step 2 的 ✏️ Other 指定，例如“安全边界情况”），无需询问，直接应用匹配的角色。

询问角色时：

• 显示角色（包含名称和简短描述的 Markdown 表格），并请用户选择。根据上下文以及现有测试用例尚未覆盖的内容，推荐一个角色。
• 如果用户未指定角色，则使用 ⚙️ default。
• 如果用户选择 🔧 other，请让他们定义自定义角色。
• 如果只显示部分角色，请添加“显示所有可用角色”选项：

❓ Choose role:

1. default (or recommended role based on context)
2. ☰ Show all available roles
3. ✏️ Type role name

角色

角色	描述
⚙️ default	均衡的方式
🌈 optimist	正向流程、顺利路径
🤓 nerd	细节、依赖项、追求完美
🔪 psycho	边界情况
🔐 pentest	安全
🎨 picasso	UI/UX
⚖️ lawyer	文本、错误消息、拼写错误等
🌐 polyglot	本地化、翻译
📈 performance	性能、负载、压力等
🔧 other	指定自己的角色

Step 4: 生成检查清单

根据收集到的上下文，创建分层、分类的检查清单。

根据 Step 2 中的层级确定规模：

• 🚀 smoke——仅包含关键路径
• ⚖️ balanced——顺利路径、关键负向情况、常见边界情况
• 🧨 exhaustive——全面覆盖
• ✏️ other——遵循用户的描述

示例：

- Signup
  - Signup with valid email
  - Signup with valid phone number

- Login
  - Login with valid email
  - Login with valid phone number
  - Login with invalid password

审批环节

• 如果有多选/复选框 Ask 工具：将叶子项显示为复选框，并在前面加上其类别（例如 Login: valid email），同时预先勾选所选层级推荐的子集。勾选的项目将成为 Step 5 中的测试用例。
• 否则：显示 Markdown 检查清单，并请用户添加、删除或更改项目。

务必询问测试用例数量 / 详细程度：

❓ Do you want to:

1. 👍 Keep as is
2. ➖ Less details
3. ➕ More details
4. ✏️ Type anything you want to change

• 需要更多细节 → 启用 🤓 nerd 角色。
• 用户修改检查清单 → 重新生成（Step 4）。
• 用户不满意 → 返回 Step 1 获取更多上下文。
• 已批准 → 进入 Step 5。

步骤 5：生成详细测试用例

如果用户最初只要求生成检查清单，请先询问：“是否要为此检查清单生成测试用例？”

测试用例的存放位置：

• 工作区为空或仅包含手动测试 → 项目根目录
• 端到端测试项目 → test-cases/ 目录
• 其他情况 → .testeiya/test-cases/（确保 .testeiya/ 存在且已加入 Git 忽略列表）

生成规则：

• 文件名使用 feature-name.test.md（扩展名始终为 .test.md）。
• 多个功能或整个产品 → 每个功能对应一个文件。
• 不要更改用户的源代码。只生成 *.test.md 文件。
• 保持范围不变：只测试待测功能；除非用户明确要求，否则不要测试相关联的功能。

格式规则：

• 严格遵循 测试用例格式 中关于测试套件、测试和步骤的要求。唯一例外：用户在提示词中指定了自己的格式。
• 严格遵循 编写规则 中关于测试套件/测试描述、前置条件、步骤、预期结果和反模式的要求。
• 按照 Testomat.io TMS 指南 中的约定（优先级、标签、标记）编写，尤其是在使用 testomatio MCP 时。
• 将测试用例放在 和 块中。
• 如有需要，请将 tags: 和 labels: 放在每个 `` 元数据块中（参见测试元数据），而不只是放在测试套件块中。
• 复用通过 MCP 获取或从其他测试用例中发现的现有标记和标签。
• 如果不了解现有标签，请勿使用标签。
• 如果合理，可根据分析的上下文添加测试元数据（优先级、前置条件、测试数据、标签、标记）。
• 使用具体、可执行的值。**首次生成时，切勿引入 ${...} 占位符。**只有确实需要复用或由数据驱动的值才使用参数化；格式为反引号包裹的 ${variable}。
• 绝不生成任何类型的测试或测试套件 ID：
  • 不要包含 Testomat.io ID（id: @T*、id: @S*，例如 @T12345678、@S380c64db）。
  • 不要在 id: 字段、标题或其他任何位置包含自定义/随机 ID（例如 TC-001、TC-R001、SUITE-01）。
  • Testomat.io ID 由服务器生成，并在用户运行带有 --update-ids 的 check-tests push（或通过 sync-test-cases-with-tms 技能）时分配。生成时切勿添加 ID。

匹配现有测试用例格式

当用户提供现有测试用例示例或要求生成“类似”的测试用例时：

请匹配：

• 写作风格和详细程度
• 字段结构（优先级、前置条件、类型、测试数据等）
• 标签和标记等其他字段
• 原始用例所用语言

不要复制：

• 示例中的任何 ID——包括 Testomat.io ID（@T...、@S...）和自定义前缀（例如 TC-R001、TC-001）
• 原测试用例的意图

步骤 6：展示摘要

• 展示简明摘要（可使用 Markdown 表格）：测试用例和测试套件数量、生成的文件、目标文件夹。
• 请用户检查文件，并在需要时提出修改要求。
• 建议通过 sync-test-cases-with-tms 技能将测试用例上传到 Testomat.io。