2026年4月13日 · 阅读 —
需求/PRD → XMind 测试用例
description: 根据需求文档或 PRD 生成可导入 XMind 的测试用例思维导图大纲。可从本 Skill 的 requirements 目录读取需求文件（PRD/PDF 等），或根据用户提供的路径/粘贴内容生成。按功能/模块拆分，每项下挂测试点（标题+简要步骤/预期）。未提及接口/性能时默认按通用测试规范（边界值、等价类、场景法等）生成；提及接口/性能测试时加载 references 内对应规范。当用户说「读取需求文件并生成测试用例」「生成思维导图测试用例」等时使用。支持 .docx、.pdf、.txt、.md。
---
# 需求/PRD → XMind 测试用例
根据需求文档或 PRD 生成**可直接导入 XMind** 的测试用例大纲，保证覆盖全、结构清晰、格式省事。
## 需求文档目录
本 Skill 提供**需求文档目录** `requirements/`：用户可将 PRD、PDF 等需求文件放入该目录，通过指令让 Skill 读取并生成测试用例。
- **路径**：与 SKILL.md 同级的 `requirements/` 文件夹。
- **支持格式**：PRD/需求类文字文档——`.docx`、`.pdf`、`.txt`、`.md`。
- **指令示例**：「读取 requirements 里的需求文件并生成测试用例」「根据 requirements 下的 PRD 生成思维导图测试用例」。若未指定具体文件，先列出 `requirements/` 下符合格式的文件供用户选择，再按用户选择读取并生成。
## 工作流
1. **获取输入**：
- **方式 A**：用户指示从 `requirements/` 读取（如「读取需求文件并生成测试用例」）→ 解析该目录下的 .docx / .pdf / .txt / .md，若未指定文件则先列出再选。
- **方式 B**：用户提供需求文档的**任意文件路径**或直接粘贴正文。
若做接口测试、性能测试等专项，按需加载 `references/` 下对应规范。
2. **读取内容**：按路径读取；若环境无法解析 .docx/.pdf（如为二进制无法提取文本），则提示用户将正文复制到对话或提供 .txt 导出。
3. **解析功能/模块**：从文档中识别**全部**功能/模块，不遗漏；若有 references 中的测试规范，结合规范细化测试类型（功能/接口/性能等）。
4. **生成大纲**：按 [references/testcase-structure.md](references/testcase-structure.md) 的层级与字段生成测试用例；格式严格遵循 [references/xmind-outline-format.md](references/xmind-outline-format.md)。**输出为 Markdown (.md)**，因 XMind 不支持 .txt 导入与文本粘贴，仅支持 .md / OPML 等格式导入。
5. **交付**：输出完整 .md 内容并保存为 .md 文件（如存于 `requirements/` 下），并说明「XMind → 文件 → 导入 → Markdown → 选择该 .md 文件」即可导入。
## 格式与结构
- **层级与字段**：见 [references/testcase-structure.md](references/testcase-structure.md)（功能/模块 → 测试点 → 标题 + 简要步骤/预期）。
- **XMind 导入格式**：见 [references/xmind-outline-format.md](references/xmind-outline-format.md)。输出为 **Markdown (.md)**（# / ## / ### / #### 与 - 列表），XMind 通过「文件 → 导入 → Markdown」导入；不支持 .txt 导入与文本粘贴。
## 测试用例设计规范（按需加载）
- **未提及接口测试或性能测试**：**默认**按 [references/general-testcases-standard.md](references/general-testcases-standard.md) 生成测试点，运用通用软件测试策略（正向、反向、边界值、等价类、场景法、状态与流程等），保证覆盖全。
- **明确要求接口测试**：加载 [references/api-testcases-standard.md](references/api-testcases-standard.md)，在保持「按功能/模块 + 测试点」的前提下，按接口测试维度（请求/参数、响应/错误码、鉴权/权限、幂等/并发等）补充或调整测试点。
- **明确要求性能测试**：加载 [references/performance-testcases-standard.md](references/performance-testcases-standard.md)，按性能测试维度（指标/基线、场景类型、瓶颈/降级等）补充或调整测试点。
## 一、必须覆盖的维度
### 1.1 请求与参数
- **正常请求**：必填参数齐全、类型与格式正确、在文档约定范围内的取值，验证返回成功及响应体关键字段。
- **参数校验**：
- 每个必填参数至少 1 条「缺失」用例，预期明确错误码/错误信息。
- 每个有类型或格式约束的参数（如数字、枚举、日期、手机号、邮箱）：至少覆盖 1 条类型错误或格式非法用例。
- 有取值范围或长度限制的：用边界值策略（最小值、最大值、超界、空串等）设计用例，预期与文档一致。
- **可选参数**：文档若定义可选参数，需覆盖「不传」「传空」「传有效值」等，并说明对结果的影响。
### 1.2 响应与错误码
- **成功响应**：验证 HTTP 状态码、业务码（若有）、响应体结构及关键字段含义与文档一致。
- **错误码**：文档中定义的每个错误码至少对应 1 条用例，用例中明确「触发条件」与「预期返回（状态码 + 错误码 + 错误信息）」。
- **未定义错误**：对明显非法请求（如必填缺失、格式错误），预期应为 4xx 或文档约定的错误码，且不应返回 200 成功。
### 1.3 鉴权与权限
- **鉴权**：若接口需 token/签名/session，须覆盖：未带鉴权、鉴权无效或过期、鉴权格式错误，预期均为未授权类错误。
- **权限**：若存在角色/租户/资源归属，须覆盖越权访问（如 A 访问 B 的资源），预期为无权限类错误或空数据，且不泄露他人数据。
### 1.4 幂等与并发（在适用时）
- **幂等**：对文档标明幂等的接口（如支付、下单），设计重复提交（相同幂等键/请求体）用例，预期仅生效一次且结果一致。
- **并发与限流**：若文档有并发限制或限流说明，设计超并发或超频请求用例，预期为限流/排队或约定错误，不产生脏数据。
---
## 二、输出时的表述要求（思维导图节点）
- **接口标识**：每条用例对应「接口路径 + 方法」（如 `POST /api/order`），可在测试点标题或子节点中体现。
- **请求说明**：步骤中写清请求体/参数的关键取值或示例；边界或异常用例标明「故意使用的无效/边界值」。
- **预期结果**：包含「HTTP 状态码」与「响应中与断言相关的部分」（业务码、错误码、关键字段或错误信息），与接口文档定义一致。
- **数据要求**：若依赖特定环境数据，在前置条件或子节点中说明。
---
## 三、与通用策略的关系
- 正向用例 → 正常请求 + 成功响应。
- 反向/异常用例 → 参数校验失败、鉴权失败、错误码覆盖。
- 边界值用例 → 参数范围/长度边界、数值临界。
- 状态与流程 → 若接口依赖业务状态，按状态设计不同请求的预期。
按上述维度与表述要求产出接口测试点，在思维导图中仍保持「功能/模块 → 测试点 → 步骤/预期」的层级结构。
---
## 二、必须覆盖的测试设计策略
### 2.1 正向测试（正常流程）
- **含义**：在合法前置条件下，按需求规定的正常路径执行，验证系统行为符合文档约定。
- **做法**：为每个核心功能点至少设计 1 条「正常流程」用例；步骤与预期与需求一致，明确「成功」的判定标准（如界面变化、状态、关键数据）。
### 2.2 反向 / 异常测试（负向用例）
- **含义**：使用非法输入、错误操作或违反约束的条件，验证系统能正确拒绝、提示或返回约定错误，且不产生副作用。
- **做法**：针对每个可校验的输入/条件，至少考虑一类无效情况（格式错误、必填缺失、越权、重复提交等）；预期结果明确（提示文案、错误码、不写库、不改变状态）。
### 2.3 边界值设计
- **含义**：在输入或条件的边界附近设计用例（最小值、最大值、刚好超界、空值、长度临界等），暴露截断、溢出等问题。
- **做法**：从需求中提取所有「有范围/有长度/有数量限制」的字段；对每个边界设计：边界内有效值、边界值、边界外无效值（若需求有定义）；对可选/可空字段考虑空串、未传等；对数值考虑 0、负值、极大值（若业务允许）。
### 2.4 等价类划分（在适用时）
- **含义**：将输入域划分为若干等价类，从每类中选取代表值设计用例，在保证覆盖的前提下减少冗余。
- **做法**：有效等价类选 1～2 个代表值；无效等价类对每种违规类型（格式、范围、必填缺失）各选代表值；可与边界值结合。
### 2.5 场景法 / 用户场景
- **含义**：以真实用户场景或业务故事为线索，串联多个功能点，形成端到端或跨模块用例。
- **做法**：从需求中归纳 2～3 个典型用户目标或业务场景；每个场景下设计一条或多条用例，覆盖主流程与常见分支；可与正向、反向、边界结合。
### 2.6 状态与流程（当需求涉及状态机、多步骤流程时）
- **含义**：针对状态流转、角色切换、多步骤业务流程设计用例，避免遗漏中间状态或非法跳转。
- **做法**：列出主要状态与允许的迁移；设计从初态到终态的正向路径、中断/回退路径、在非法状态下执行操作（应被拒绝或提示）；若有角色/权限，覆盖越权与角色切换后的可见性。
---
## 三、在思维导图中的体现
- **L1 功能/模块**：与需求文档一一对应，不遗漏。
- **L2 测试点**：每条测试点对应上述某类策略（可在标题或子节点中体现「正向」「反向」「边界」「场景」「状态」等），避免只写「正常流程」而忽略异常与边界。
- **L3 步骤/预期**：简要写出步骤与预期，便于在 XMind 中一眼看懂。
未指定专项时，**不得**仅输出少量「正常流程」用例，须按本规范覆盖边界值、场景法、反向与状态等策略。 性能测试用例标准说明
本文件定义**性能测试**场景下的用例设计维度与输出要求。当用户**明确要求按性能测试**生成思维导图测试用例时加载本规范；与通用策略配合使用，当文档涉及性能指标、压测或 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 以产品/运维约定为准」），并建议补充具体指标后再执行。
按上述维度与表述要求产出性能测试点，在思维导图中仍保持「功能/模块 → 测试点 → 步骤/预期」的层级结构。# 测试用例思维导图结构规范
保证**覆盖全**、**结构清晰**：按功能/模块划分，每个功能下挂若干测试点，每个测试点包含标题与简要步骤/预期。
## 层级结构
| 层级 | 含义 | 说明 |
|------|------|------|
| L0 | 根主题 | 建议为「测试用例」或「[产品/项目名] 测试用例」 |
| L1 | 功能/模块 | 与需求/PRD 中的功能或模块一一对应，不遗漏 |
| L2 | 测试点 | 该功能下的单条测试场景（标题即用例名） |
| L3 | 步骤/预期（可选） | 每条测试点下可挂「步骤」「预期」等子节点，简要描述即可 |
## 功能/模块（L1）提取原则
- 从需求文档或 PRD 中**完整识别**所有功能模块、特性或用户故事，不遗漏。
- 若文档有章节/目录，可与之对齐；若没有，按「用户可感知的功能块」或「开发/产品提到的模块」划分。
- 命名与文档中用语一致，便于追溯。
## 测试点（L2）编写原则
- **标题**：一句话概括场景，如「正常登录-正确账号密码」「订单提交-必填项缺失时提示」。
- **覆盖类型**：见下方「规范选择」；每条测试点下可用 L3 补充「步骤」「预期」，保持简短。
## 规范选择（默认 vs 专项）
- **未提及接口测试或性能测试**：按 [general-testcases-standard.md](general-testcases-standard.md) **通用规范**生成测试点，必须运用：正向、反向/异常、**边界值**、**等价类**、**场景法**、状态与流程等策略，不得仅写少量「正常流程」用例。
- **用户明确要求接口测试**：加载 [api-testcases-standard.md](api-testcases-standard.md)，在保持「功能/模块 → 测试点」层级的前提下，按接口维度（请求/参数、响应/错误码、鉴权/权限、幂等/并发等）设计测试点。
- **用户明确要求性能测试**：加载 [performance-testcases-standard.md](performance-testcases-standard.md)，按性能维度（指标/基线、场景类型、瓶颈/降级等）设计测试点。
接口/性能规范与通用规范可叠加（如接口测试时仍可含边界值、场景等）。
## 示例（对应 XMind 大纲）
根 → 登录模块 → 测试点1「正常登录」→ 子节点「步骤」「预期」；测试点2「错误密码」→ 子节点「步骤」「预期」。
根 → 订单模块 → 测试点1「创建订单-必填项完整」→ 步骤/预期；测试点2「创建订单-缺少必填项」→ 步骤/预期。
XMind **不支持 .txt 文档导入**，也**不支持将纯文本复制粘贴**为大纲。请使用以下两种方式之一导入思维导图。
---
## 推荐：Markdown (.md) 格式
XMind 桌面版支持 **导入 Markdown 文件**，将标题与列表转换为思维导图节点。
### 层级对应关系
| Markdown 语法 | XMind 节点 |
|---------------|------------|
| `# 标题` | 中心主题（根节点） |
| `## 标题` | 一级分支 |
| `### 标题` | 二级分支 |
| `#### 标题` | 三级分支 |
| `- 列表项` 或 `* 列表项` | 该上级标题下的子节点 |
### 格式规则
1. **仅用 `#`～`####` 和 `-`/`*` 表示层级**，不要混用其他符号。
2. **`#` 与标题之间保留一个空格**，如：`## 用户登录`。
3. **列表项 `-` 必须出现在某个 `####` 标题之下**，表示该测试点下的「步骤」「预期」等子节点。
4. **文件编码**：保存为 **UTF-8**。
### 示例
```markdown
# 测试用例-XX产品
## 登录模块
### 用户登录
#### 正向-正确账号密码
- 步骤：输入账号密码点击登录
- 预期：进入首页
#### 反向-错误密码
- 步骤：输入错误密码
- 预期：提示密码错误且不跳转
```
导入后：中心为「测试用例-XX产品」→ 一级分支「登录模块」→ 二级「用户登录」→ 三级为各测试点，其下为步骤/预期子节点。
### 用户导入步骤（Markdown）
1. 将 Skill 生成的 **.md 文件**保存到本地（或直接使用 `requirements/` 下生成的 .md）。
2. 打开 XMind → **文件** → **导入** → 选择 **Markdown**。
3. 选中该 .md 文件，确认导入即可。
---
## 备选：OPML 格式
XMind 也支持 **OPML**（Outline Processor Markup Language）。若需 OPML 输出，可在对话中说明「请输出为 OPML 格式」，再按 XMind 的 OPML 导入入口导入。
---
## 避免的写法
- 依赖 .txt + Tab 缩进导入（XMind 当前版本不支持）。
- 依赖「复制整段文本粘贴到 XMind」（不支持）。
- 在 .md 中用 `1.`、`2.` 等有序列表做层级（可能无法正确映射为节点）。