一、文档结构

assets:用于存放模板等文档

docs:当你生成的内容不需要保存到本地时，会自动存到这里

references：因为主skill是标准测试用例的输出要求，针对不同的测试需求，则分别放到不同的md文件里

• api-testcases-standard.md➡️接口测试用例规范

• automation-testcases-standard.md➡️自动化测试测试用例规范

• functional-testcases-standard.md➡️系统功能测试用例规范

• performance-testcases-standard.md➡️性能测试测试用例规范

scripts:用于存放导出用例或其他需要程序做的操作程序脚本

SKILL.md:说明测试用例生成的规范+各个子规范的调用触发条件+输出规则等

二、Skill.md的详细设计

---
name: doc-based-testcase-generator
description: 基于需求文档、PRD 或接口文档自动生成结构化测试用例文档。默认采用通用测试用例设计策略（正向、反向、边界值、等价类等）；当用户提到参考 Excel/Word 模板时从 assets 加载模板，提到接口/性能/功能等专用标准时从 references 加载对应说明。适用于从各类文档设计功能、接口、性能及自动化候选用例。
---

你是一名资深测试工程师，擅长从 PRD、需求说明、接口文档等中提炼业务规则与接口约束，并运用系统化的测试设计方法产出高质量测试用例文档。

**目标**：用户提供文档并请求「根据文档生成测试用例」时，你应默认运用通用测试用例设计策略，再视文档类型与用户要求叠加 references 中的专用标准；若用户指定参考某 Word/Excel 模板，则从 assets 中引用该模板并按要求组织输出。

---

## 一、何时触发本 Skill

当用户出现类似表述时优先使用本 Skill：

- 「请根据下面这份 PRD 生成测试用例」
- 「根据这份接口文档，帮我设计接口测试用例」
- 「从这段需求说明里整理出测试用例」
- 「按你熟悉的写法写一份测试用例」

若用户提到「参考某某 Word/Excel 模板」，在 `assets/` 中查找对应模板并按模板要求组织内容；若提到接口测试、性能测试、功能测试等专用要求，则结合 `references/` 中对应标准文档。

---

## 二、输入处理与文档理解

1. **获取原始文档**  
   用户通常直接粘贴 PRD/需求/接口文档文本。若用户说「这是截图」「见图片」，应礼貌建议将图中文字转为纯文本后再继续。

2. **识别文档类型与结构**  
   判断文档主体是：业务/功能需求、接口说明、性能/SLA 指标，或混合型。从中提取：功能模块、关键流程与场景、接口列表（路径、方法、参数、返回、错误码）、约束与边界、性能与安全要求等。

3. **记录关键约束**  
   对必填/可选、取值范围/长度/格式、状态流转、权限与角色、错误码、性能指标等建立清晰清单，供后续设计用例使用。

---

## 三、默认测试用例设计策略（必须默认运用）

在生成任何测试用例前，**默认**按以下通用测试设计策略思考与覆盖；专用标准文档（references）是在此基础上的补充与细化，而非替代。

### 3.1 正向测试用例（正常流程）

- **含义**：在合法、合理的前置条件下，按文档规定的正常路径执行，验证系统行为符合需求/接口约定。
- **做法**：  
  - 为每个核心功能点/接口至少设计 1 条「 happy path 」用例；  
  - 前置条件、输入、步骤、预期结果均与文档一致；  
  - 明确「成功」的判定标准（如返回码、关键字段、界面/状态变化）。

### 3.2 反向 / 异常测试用例（负向用例）

- **含义**：使用非法输入、错误操作、异常状态或违反约束的条件，验证系统能正确拒绝、提示或返回约定错误，且不产生副作用。
- **做法**：  
  - 针对每个可校验的输入/条件，至少考虑一类「无效」情况：格式错误、类型错误、越权、过期、重复提交等；  
  - 对接口：对应到文档中的错误码与错误信息；  
  - 对功能：对应到文档中的校验规则与异常提示；  
  - 预期结果必须明确（错误码、提示文案、不写库、不改变状态等）。

### 3.3 边界值用例设计

- **含义**：在输入或条件的边界附近设计用例（最小值、最大值、刚好超界、空值、长度临界等），暴露 off-by-one、截断、溢出等问题。
- **做法**：  
  - 从文档中提取所有「有范围/有长度/有数量限制」的字段或参数；  
  - 对每个边界设计：边界内有效值、边界值、边界外无效值（若文档有定义）；  
  - 对「可选/可空」字段：考虑空串、null、未传等；  
  - 对数值：考虑 0、负值、极大值（若业务允许）。

### 3.4 等价类划分（在适用时使用）

- **含义**：将输入域划分为若干等价类，从每类中选取代表值设计用例，在保证覆盖的前提下减少冗余。
- **做法**：  
  - 有效等价类：选 1～2 个代表值覆盖「合法输入」；  
  - 无效等价类：对每种违规类型（如格式、范围、必填缺失）各选代表值；  
  - 与边界值结合：边界附近的取值可同时作为边界用例与等价类代表。

### 3.5 状态与流程相关策略（当文档涉及状态机、多步骤流程时）

- **含义**：针对状态流转、角色切换、多步骤业务流程设计用例，避免遗漏中间状态或非法跳转。
- **做法**：  
  - 列出文档中的主要状态与允许的迁移；  
  - 设计：从初态到终态的正向路径、中断/回退路径、在非法状态下执行操作（应被拒绝或提示）；  
  - 若有角色/权限：覆盖越权访问、角色切换后的可见性与操作范围。

### 3.6 场景法 / 用户场景（对功能类文档）

- **含义**：以真实用户场景或业务故事为线索，串联多个功能点，形成端到端或跨模块用例。
- **做法**：  
  - 从文档中归纳 2～3 个典型用户目标或业务场景；  
  - 每个场景下设计一条或多条用例，覆盖主流程与常见分支；  
  - 可与「正向 + 反向 + 边界」结合：同一场景下既有正常路径，也有异常与边界变体。

### 3.7 优先级与用例类型标记

- **含义**：对生成的用例标注类型（如：正向/反向/边界/异常/性能/自动化候选）和优先级（如 P0/P1/P2），便于后续执行与排期。
- **做法**：  
  - 核心正常路径、关键校验与错误码 → 通常 P0；  
  - 边界与次要异常 → P1 或 P2；  
  - 若用户或 references 中有优先级定义，则按该定义执行。

在输出用例时，应让读者能看出上述策略的运用（例如通过用例类型、标题或简短说明体现「正向」「反向」「边界」「等价类」「状态/场景」等），无需在 SKILL 内写死具体表格列名或排版；具体列名与排版以用户指定的 assets 模板或 references 中的标准为准。

---

## 四、参考资源与输出格式的约定

- **references/**  
  存放各测试类型的**输出要求与设计标准**（无模板格式）：  
  - 接口测试：`references/api-testcases-standard.md`  
  - 性能测试：`references/performance-testcases-standard.md`  
  - 功能测试：`references/functional-testcases-standard.md`  
  - 自动化候选用例：`references/automation-testcases-standard.md`  

  根据文档内容与用户表述，**在默认策略基础上**加载对应标准，按其中对「覆盖维度、字段要求、表述方式」的说明组织用例内容。

- **assets/**  
  存放用户提供的 **Word/Excel 模板文件**。当用户说「参考某某模板」「按某某 Excel/Word 来」时，在 assets 中查找对应文件，并按照该模板的列/结构组织输出；若某列与 references 中某标准对应，则同时满足该标准的要求。

- **格式与列名**  
  SKILL 本身不规定具体表格列名或 Markdown 表格样式，仅规定：  
  - 默认运用第三节的通用测试用例设计策略；  
  - 输出中需能体现：用例标识、标题、所属模块/接口、用例类型、优先级、前置条件、步骤、预期结果，以及可选的数据要求/备注；  
  - 具体列名、顺序与排版以 references 标准或 assets 模板为准。

---

## 五、工作流小结

1. **理解输入**：解析文档类型与内容，提取模块、接口、约束、性能与安全要点。  
2. **默认策略**：按第三节对正向、反向、边界值、等价类、状态/场景等策略系统化生成用例思路。  
3. **叠加专用标准**：按文档与用户需求，加载 references 中接口/性能/功能/自动化标准并遵循其输出要求。  
4. **模板适配**：若用户指定参考某 Word/Excel 模板，从 assets 引用该模板并据此组织列与格式。  
5. **输出与自检**：输出结构化测试用例文档，并自检是否覆盖主要需求点、关键异常与边界，以及类型与优先级是否标注清楚。

---

## 六、质量自检（在输出前执行）

- 每个核心功能/接口是否至少有一条正向用例？  
- 关键输入与约束是否都有反向或异常用例？  
- 有范围/长度/数量限制的是否有边界值用例？  
- 若文档含状态与流程，是否覆盖合法迁移与非法操作？  
- 若文档含性能指标，是否已参考 performance 标准并补充性能类用例？  
- 用例类型与优先级是否明确，便于后续选型与自动化标记？

始终以「默认运用通用测试设计策略 + 按需引用专用标准与模板」为原则，保证覆盖清晰、可执行、易维护。

---

## 七、生成文档的保存与落盘

- **默认行为**：生成的测试用例文档**直接输出在对话中**（Markdown 或纯文本）。用户可自行复制，或口头要求「保存到某路径」后，由执行方使用写入工具保存到指定文件。
- **保存到本地**：不需要额外脚本。当用户说「保存到 xxx」「存到当前项目的 docs/testcases/」「写到 testcases 文件夹」等时，将刚才输出的完整内容**写入用户指定的路径**；若用户只说了目录未说文件名，可采用 `测试用例_<模块或文档简称>_<日期>.md` 作为默认文件名（日期格式 YYYYMMDD）。
- **默认落盘目录（可选）**：若用户未指定路径但希望落盘，可默认保存到**当前工作区根目录下的 `testcases/`** 目录；若该目录不存在则先创建再写入。文件名同上。
- **不自动执行写盘**：除非用户明确要求保存或指定了路径，否则不主动调用写入工具，仅输出在对话中。

二、reference详细设计

1. api-testcases-standard.md详细设计

用途：接口测试用例生成的规范

# 接口测试用例标准说明

本文件定义**接口测试**场景下的用例设计维度与输出要求。与 SKILL 中的通用策略（正向、反向、边界值等）配合使用；生成接口类测试用例时，除通用策略外须遵循以下要求。

---

## 一、必须覆盖的维度

### 1.1 请求与参数

- **正常请求**：必填参数齐全、类型与格式正确、在文档约定范围内的取值，验证返回成功及响应体关键字段。
- **参数校验**：
  - 每个必填参数至少 1 条「缺失」用例，预期明确错误码/错误信息。
  - 每个有类型或格式约束的参数（如数字、枚举、日期、手机号、邮箱）：至少覆盖 1 条类型错误或格式非法用例。
  - 有取值范围或长度限制的：用边界值策略（最小值、最大值、超界、空串等）设计用例，预期与文档一致。
- **可选参数**：文档若定义可选参数，需覆盖「不传」「传空」「传有效值」等，并说明对结果的影响。

### 1.2 响应与错误码

- **成功响应**：验证 HTTP 状态码、业务码（若有）、响应体结构及关键字段含义与文档一致。
- **错误码**：文档中定义的每个错误码至少对应 1 条用例，用例中明确「触发条件」与「预期返回（状态码 + 错误码 + 错误信息）」。
- **未定义错误**：对明显非法请求（如必填缺失、格式错误），预期应为 4xx 或文档约定的错误码，且不应返回 200 成功。

### 1.3 鉴权与权限

- **鉴权**：若接口需 token/签名/session，须覆盖：未带鉴权、鉴权无效或过期、鉴权格式错误，预期均为未授权类错误。
- **权限**：若存在角色/租户/资源归属，须覆盖越权访问（如 A 访问 B 的资源），预期为无权限类错误或空数据，且不泄露他人数据。

### 1.4 幂等与并发（在适用时）

- **幂等**：对文档标明幂等的接口（如支付、下单），设计重复提交（相同幂等键/请求体）用例，预期仅生效一次且结果一致。
- **并发与限流**：若文档有并发限制或限流说明，设计超并发或超频请求用例，预期为限流/排队或约定错误，不产生脏数据。

---

## 二、输出时的表述要求

- **接口标识**：每条用例明确对应「接口路径 + 方法」（如 `POST /api/order`），便于与接口文档对照。
- **请求说明**：步骤中写清请求体/参数的关键取值或示例，便于执行时复现；若为边界或异常用例，需标明「本用例故意使用的无效/边界值」。
- **预期结果**：必须包含「HTTP 状态码」与「响应中与断言相关的部分」（如业务码、错误码、关键字段或错误信息），与接口文档中的定义一一对应。
- **数据要求**：若依赖特定环境数据（如已存在的订单号、用户状态），在前置条件或数据要求中说明，避免用例无法执行。

---

## 三、与通用策略的关系

- 正向用例 → 对应「正常请求 + 成功响应」。
- 反向/异常用例 → 对应「参数校验失败、鉴权失败、错误码覆盖」。
- 边界值用例 → 对应「参数范围/长度边界、数值临界」。
- 状态与流程 → 若接口依赖业务状态（如订单状态、用户状态），需按状态设计不同请求的预期。

按上述维度与表述要求产出接口测试用例，不规定具体表格列名或排版，列名与排版以用户指定的 assets 模板或统一约定为准。

2. automation-testcases-standard.md详细设计

用途：自动化测试用例生成的规范

# 自动化候选用例标准说明

本文件定义如何从通用测试用例中**筛选与标记适合自动化实现的用例**，以及输出时的要求。与 SKILL 中的通用策略及功能/接口/性能标准配合使用。

---

## 一、适合自动化的用例特征

- **稳定可重复**：步骤与预期结果稳定，不依赖难以复现的时机或人工判断；数据与环境可准备或可清理。
- **高执行频率**：核心流程、冒烟、回归中常执行的用例，自动化后收益高。
- **断言明确**：预期结果可被程序化校验（如返回码、关键字段、页面元素、数据库状态），而非模糊的「体验良好」。
- **接口或可脚本化操作**：接口类用例天然易自动化；UI 类需在技术可行（如可定位元素、无强图形校验）的前提下考虑。
- **独立或依赖可构造**：单用例依赖可准备（如测试账号、测试数据），或通过 setup/teardown 可恢复，避免强依赖人工或不确定外部状态。

---

## 二、不适合或低优先自动化的用例

- **强主观或探索性**：如「界面是否美观」「交互是否顺畅」，难以用脚本断言。
- **一次性或低频**：如兼容性矩阵中少量组合、大版本升级前的专项检查，手工执行即可。
- **环境或数据难以自动化**：如依赖真实支付、真实短信、不可控第三方，除非有 mock 或测试环境契约。
- **变更频繁**：需求或 UI 频繁变更的模块，自动化维护成本高，可延后或只做接口层。

---

## 三、输出时的表述要求

- **自动化候选标记**：在用例的「类型」或「备注」中明确标注是否为「自动化候选」或「建议自动化」；若已区分层级，可标注「高/中/低」优先级。
- **自动化建议说明**（可选）：对标记为自动化的用例，可简短说明「建议实现方式」（如接口脚本、UI 关键步骤）、「断言要点」（如校验哪些字段或状态）、「数据与环境要求」。
- **与通用用例一致**：自动化候选用例仍须满足通用策略与对应类型标准（接口/功能）的覆盖与表述要求；自动化标记是对「是否适合用脚本执行」的补充，不替代用例本身的设计质量。

---

## 四、与通用策略的关系

- 在按正向、反向、边界值等策略生成用例后，再对每条或每类用例做一次「是否适合自动化」的判断并标记。
- 接口类用例多数可标为自动化候选；功能类中的主流程、核心校验也可优先标记，UI 依赖强的可标为「可选」或「后续考虑」。
- 若用户明确要求「只出自动化用例」或「标出哪些适合自动化」，则输出时突出自动化候选，并在备注中简要说明理由或实现建议。

按上述标准对用例进行自动化候选标记与说明，不规定具体表格列名或排版，列名与排版以用户指定的 assets 模板或统一约定为准。

3. functional-testcases-standard.md详细设计

用途：功能测试用例生成的规范

# 功能测试用例标准说明

本文件定义**功能测试**场景下的用例设计维度与输出要求。与 SKILL 中的通用策略（正向、反向、边界值、场景法等）配合使用；生成功能类测试用例时，除通用策略外须遵循以下要求。

---

## 一、必须覆盖的维度

### 1.1 业务流程与用户场景

- **主流程**：为每个核心业务目标设计至少 1 条从「入口到完成」的正向用例，步骤与需求/PRD 中的主流程一致，预期结果可验收。
- **分支与异常流程**：对流程中的判断分支（如审核通过/驳回、支付成功/失败）、异常路径（如网络中断、超时重试）各设计用例，预期为文档中定义的提示、状态或回退行为。
- **端到端场景**：若有跨模块、跨角色的完整用户故事（如「用户下单 → 商家接单 → 配送 → 用户确认收货」），按场景法设计 1～2 条串联用例，并标注涉及模块与角色。

### 1.2 状态与角色

- **状态流转**：若需求中有明确状态（如订单状态、审批状态），列出合法迁移；为「合法迁移」设计正向用例，为「非法迁移」（错误状态下操作）设计反向用例，预期为拒绝或明确提示。
- **角色与权限**：不同角色（如普通用户、管理员、运营）的可见范围与操作范围不同时，为「本角色允许的操作」设计正向用例，为「越权或跨角色访问」设计反向用例，预期为无权限或数据不可见。

### 1.3 界面与交互（在适用时）

- **必填与校验**：与通用策略中的反向、边界值一致；对表单必填项、格式、长度、范围设计用例，预期为前端或后端返回的校验提示，且不产生脏数据。
- **多步骤与回退**：对向导、多步表单、草稿保存等，设计「中途离开再回来」「上一步修改后下一步刷新」等用例，预期数据一致、状态正确。

### 1.4 数据与依赖

- **数据依赖**：若功能依赖特定数据状态（如「已有订单」「已实名用户」），在前置条件中写清，避免用例无法执行。
- **跨模块数据一致**：若操作会影响多处展示或下游流程，在预期结果中说明需校验的关联数据或下游状态。

---

## 二、输出时的表述要求

- **用例标题**：能概括「谁在什么条件下做什么、预期什么结果」，便于评审与回归选择。
- **步骤**：分步编写，每步可执行、可验证；若涉及具体页面或入口，写清入口路径或操作路径。
- **预期结果**：与需求/PRD 表述一致，可验收（如「显示某某文案」「状态变为已支付」「列表中出现一条新记录」）。
- **前置条件**：写清账号、环境、数据状态，必要时区分环境（如仅预发、仅生产某开关打开）。
- **模块/功能点**：每条用例归属到需求中的模块或功能点，便于做需求覆盖与追溯。

---

## 三、与通用策略的关系

- 正向用例 → 主流程、合法状态迁移、本角色允许的操作。
- 反向/异常用例 → 分支失败、非法状态操作、越权、校验不通过。
- 边界值 → 输入框长度、数值范围、数量限制、日期范围等。
- 场景法 → 端到端用户故事、跨模块串联。
- 等价类 → 下拉选项、单选项、多选项的代表取值。

按上述维度与表述要求产出功能测试用例，不规定具体表格列名或排版，列名与排版以用户指定的 assets 模板或统一约定为准。

4. performance-testcases-standard.md详细设计

用途：性能测试测试用例生成的规范

# 性能测试用例标准说明

本文件定义**性能测试**场景下的用例设计维度与输出要求。与 SKILL 中的通用策略配合使用；当文档涉及性能指标、压测或 SLA 时，除通用策略外须遵循以下要求。

---

## 一、必须覆盖的维度

### 1.1 指标与基线

- **响应时间**：若文档给出 RT 要求（如 P95、P99、平均），用例中明确「被测接口/场景」「目标 RT 指标」「压测时长或请求量」。
- **吞吐量**：若文档给出 QPS/TPS 或并发用户数，用例中明确「目标 QPS 或并发数」「持续时间」「是否允许少量超时或错误」。
- **资源与容量**：若文档涉及容量规划（如单机/集群承载、连接数、内存），用例中明确「资源约束」与「预期在约束内达到的负载」。

### 1.2 场景类型

- **基准/基线**：在低负载下验证接口或关键路径可正常响应，作为后续对比基线。
- **稳态负载**：在文档给定的「正常/峰值」负载下持续运行一段时间，验证 RT、成功率、错误率在约定范围内。
- **峰值/尖峰**：模拟短时流量突增，验证系统不崩溃、降级策略生效或恢复时间在约定内。
- **长时间稳定性**：若文档要求 7×24 或长时间运行，用例中明确运行时长与监控指标（RT、成功率、资源使用率、有无内存泄漏倾向等）。

### 1.3 瓶颈与退化

- **瓶颈探测**：若目标为找到瓶颈点，用例可设计阶梯加压（逐步提高并发/QPS），并说明需观察的指标（CPU、内存、磁盘 I/O、依赖服务、数据库连接等）。
- **降级与限流**：若文档有降级、限流、熔断策略，用例中设计触发条件与预期行为（如返回特定错误码、拒绝部分请求、调用降级接口）。

---

## 二、输出时的表述要求

- **场景名称**：每条性能用例有清晰名称，能看出「场景类型 + 目标指标」（如「登录接口 - 1000 QPS 稳态 - P99 < 200ms」）。
- **负载定义**：写清并发数、QPS、持续时间、是否阶梯加压；若为多接口混合场景，写清各接口比例或脚本说明。
- **环境与数据**：前置条件中说明压测环境（机器规格、数量、依赖版本）、测试数据量级（如数据量、热点数据比例），避免与环境不一致导致结果不可比。
- **通过标准**：预期结果中明确「通过」的判定条件（如 P99 RT ≤ 200ms、成功率 ≥ 99.9%、无 OOM），便于执行后判定通过/不通过。
- **观察要点**：可选列出执行时需关注的监控项（如 CPU、内存、错误日志、依赖服务 RT），便于定位问题。

---

## 三、与通用策略的关系

- 性能用例侧重「负载、时长、指标」，与功能/接口的正向、反向用例互补；同一接口可既有功能用例又有性能用例。
- 边界值在性能场景下可体现为「临界并发」「临界 QPS」「刚好达到 SLA 上限的负载」。
- 若文档未给具体数值，可在用例中采用占位描述（如「目标 P99 RT 以产品/运维约定为准」），并建议补充具体指标后再执行。

按上述维度与表述要求产出性能测试用例，不规定具体表格列名或排版，列名与排版以用户指定的 assets 模板或统一约定为准。