根据 PRD 生成测试用例

任务背景

使用本技能将用户指定路径下的 PRD 转换为结构化测试用例文件。输出内容必须能够追溯到 PRD，不能把 PRD 未说明的信息写成确定性预期。

生成测试用例前必须确认 PRD 文件路径和功能类型：功能类型只能是“新功能”或“已有功能”。新功能的待确认项需要给出推荐方案；已有功能的待确认项需要结合项目代码给出现有实现，但测试用例文件中应尽可能少提及代码和 DB 细节，只保留测试执行真正需要的信息。

测试用例文件必须使用 需求-用例追踪矩阵 章节，用矩阵说明 PRD 原子需求与测试用例的覆盖关系；测试用例 章节下必须按用例分层组织为 冒烟集、主流程集、边界集、回归集 四个子集，并在 用例结果汇总 中统计各分层集的用例数量。

任务步骤

1. 检查用户消息中是否明确提供 PRD 文件路径；没有路径时停止执行，并要求用户补充路径。
2. 确认用户是否明确说明功能类型为“新功能”或“已有功能”；未说明时停止执行，并要求用户确认功能类型。
3. 定位并读取用户提供的 PRD 文件。
4. 如果 PRD 引用了 UI 图片或同目录辅助文件，且这些文件会影响路由、页面、按钮、字段或交互理解，则读取并分析对应文件。
5. 如果功能类型为“已有功能”，依据 PRD 中的功能位置、路由、菜单路径和图片信息依次查找前端代码，再根据最终页面代码反向定位接口、服务和关键实现，用于识别现有行为与待确认项。
6. 写入前先检查目标 output 目录，了解项目中已有的命名和目录惯例。
7. 从 PRD 中提取需求点：

- 功能标题和需求版本； - 功能位置、路由或菜单路径； - 用户角色、权限控制和数据可见范围； - 正常流程、异常流程、边界规则和状态流转； - 字段规则、按钮状态、弹窗、提示、导入导出、下载内容和数据影响； - 升级、迁移、定时任务、日志、审计和权限初始化规则。

1. 将需求点拆分为可验证的原子需求，生成稳定需求编号（例如 REQ-<领域前缀>-001），并保留 PRD 位置、需求点摘要和不明确事项。
2. 将原子需求转换为测试场景，再转换为可执行测试用例；每条测试用例只覆盖一个独立功能点，不得把多个功能点整合到同一个用例中。
3. 为每条测试用例分配唯一用例分层：冒烟集、主流程集、边界集、回归集；同一条测试用例只能归入一个分层集，不得跨分层重复出现。
4. 生成 需求-用例追踪矩阵 章节；矩阵需体现需求编号、PRD 位置、需求点摘要、覆盖用例、覆盖状态和备注。
5. 生成 待确认项 章节：新功能写明推荐方案；已有功能写明从项目代码识别到的现有实现。
6. 在测试用例文件末尾生成 用例结果汇总 章节，汇总需同时体现用例总数、各分层集数量、各级别数量及编号、待确认项数量。
7. 将测试用例文件写入项目 output 目录。
8. 重新读取生成文件或检查文件元数据，确认路径和核心结构正确。
9. 最终回复提示用户：确认待确认项后，可以增量修订当前测试用例文件，并在原 PRD 中新增 测试用例补充点 章节同步补充确认结论。

任务要求

必填输入

• 用户必须在使用本技能时明确提供 PRD 文件路径。
• 如果用户没有提供 PRD 路径，立即停止执行后续流程，并回复用户补充 PRD 路径。不要自行搜索 PRD 文件，不要根据历史上下文猜测路径，不要继续生成测试用例。
• 用户必须明确确认功能类型为“新功能”或“已有功能”。
• 如果用户没有确认功能类型，立即停止执行后续流程，并回复用户确认是新功能还是已有功能。不要根据 PRD 内容或历史上下文猜测功能类型。
• 可接受的路径形式包括：

- Windows 绝对路径，例如 C:\Users\86182\Desktop\RIM\PRD\v3.0.6.6\功能名称\功能名称.md。 - 项目相对路径，例如 PRD/v3.0.6.6/功能名称/功能名称.md。

输出位置

• 如果用户没有指定其他格式，优先使用以下路径：

<项目根目录>/output/test/case/<需求版本号>/<功能标题>/<功能标题>_测试用例.md

• 优先从 PRD 路径或 PRD 内容中推断版本号。如果两者都无法推断，则使用 unknown-version，并在最终回复中说明。
• 优先从类似 # 功能标题：... 的标题中提取功能标题；如果不存在，则使用 PRD 文件名去掉扩展名后的名称。

测试用例结构

• 默认生成 Markdown 文件，使用以下结构：

# <功能标题>测试用例

- PRD来源：`<尽量使用相对路径>`
- 适用版本：`<版本号>`
- 用例级别：`P0 / P1 / P2 / P3 ...`
- 功能类型：`新功能 / 已有功能`

## 需求-用例追踪矩阵

| 需求ID | PRD位置 | 需求点摘要 | 覆盖用例 | 覆盖状态 | 备注 |
|---|---|---|---|---|---|
| REQ-<领域前缀>-001 | <PRD中从一级标题到条目序号的全路径> | <可验证的原子需求摘要> | TC-<领域前缀>-001 | 完全覆盖/部分覆盖/待确认/未覆盖 | <必要说明；没有则写“无”> |

## 测试用例

### 冒烟集

#### TC-<领域前缀>-001 <用例名称>
- 用例级别：<P0/P1/P2/P3>
- 覆盖需求：<REQ 编号；多个编号用顿号分隔>
- 前置条件准备提示：
  1. <按相同编号和顺序对应“前置条件”第 1 项，先概括该前置条件，再说明该条件在现有系统或测试环境中如何准备，例如通过哪个页面入口、权限集、配置项、业务数据、历史数据、邮件/日志查看方式实现；已有功能可参考现有文档和代码判断，但只保留测试执行必要信息>
- 前置条件：
  1. <只写执行前必须存在的状态>
- 操作步骤：
  1. <具体的用户动作或系统动作>
- 预期结果：
  1. <可观察、可验证的预期结果>

### 主流程集

#### TC-<领域前缀>-002 <用例名称>
<用例内容同上>

### 边界集

#### TC-<领域前缀>-003 <用例名称>
<用例内容同上>

### 回归集

#### TC-<领域前缀>-004 <用例名称>
<用例内容同上>

• 测试用例编号要稳定且易读。根据功能选择简短领域前缀，例如回收站可使用 RB，登录可使用 LOGIN，订单可使用 ORDER。
• 文件末尾必须追加以下结构：

## 待确认项

1. <待确认项描述>
   - 影响用例：<TC 编号>
   - 新功能推荐方案：<功能类型为新功能时填写>
   - 已有功能现有实现：<功能类型为已有功能时填写>

## 用例结果汇总

- 用例总数：<数量>
- 各分层集用例数量：冒烟集 <数量>，主流程集 <数量>，边界集 <数量>，回归集 <数量>
- 各级别用例数量及编号：
  - P0 <数量>: <TC 编号列表；没有则写“0，无”>
  - P1 <数量>: <TC 编号列表；没有则写“0，无”>
  - P2 <数量>: <TC 编号列表；没有则写“0，无”>
  - P3 <数量>: <TC 编号列表；没有则写“0，无”>
- 待确认项数量：<数量>

编写规则

• 必须生成 需求-用例追踪矩阵；测试数据、角色、权限、配置、业务数据和验证工具等准备方式应写入每条用例的 前置条件准备提示。
• 需求编号必须稳定且易读，格式建议为 REQ-<领域前缀>-001；每个需求编号只描述一个可验证的原子需求，禁止把入口、权限、保存、下载结果等多个规则合并为一个需求点。
• 需求-用例追踪矩阵 必须以需求为主视角，列出 需求ID、PRD位置、需求点摘要、覆盖用例、覆盖状态、备注；覆盖状态只能使用 完全覆盖、部分覆盖、待确认、未覆盖。
• 每条测试用例都必须填写 覆盖需求，并与 需求-用例追踪矩阵 中的 覆盖用例 双向一致；一个用例可覆盖多个强相关需求，但不得因此变成综合用例。
• 确保每条测试用例都能对应到 PRD 中的一个或多个需求点。
• 每条测试用例必须针对一个独立功能点，不得将入口、查询、提交、校验、权限、导出等多个独立功能点合并成一个综合用例。
• 测试用例 章节下必须固定包含 冒烟集、主流程集、边界集、回归集 四个子标题；无用例的分层集也必须保留标题并写明“本集暂无用例”。
• 每条测试用例必须且只能归入一个分层集：冒烟集用于最小可用路径和发布阻断验证，主流程集用于核心正常业务链路，边界集用于边界值、异常、权限、校验和极端状态，回归集用于历史能力、兼容性、跨功能影响、升级迁移和非本功能主路径验证。
• 每条测试用例都必须包含 前置条件准备提示，并逐项说明 前置条件 中每个条件的数据或状态如何准备。
• 前置条件准备提示 必须与 前置条件 一一对应：编号数量、编号顺序应保持一致；如果一个前置条件包含多个并列状态，应拆成多条前置条件，避免一个提示项解释多个不同来源。
• 前置条件准备提示 每一项必须写成“前置条件 + 实现/准备方式”的形式，例如“登录账号具备邮箱服务配置编辑权限：在现有管理端通过权限集为测试账号勾选……权限；具备权限后可从……入口进入页面。”不要只写“来自 PRD”“来自测试数据准备”“由测试环境提供”这类无法执行的来源说明。
• 对已有功能，编写 前置条件准备提示 时必须结合现有文档和代码反向判断前置条件如何实现：权限类说明现有权限集、菜单入口或权限编码；配置类说明现有页面或接口保存后的回显方式；业务数据类说明可通过哪个已有业务入口创建或触发；邮件、日志、审计类说明可通过哪个现有页面、邮件捕获方式、审计日志入口或服务日志方式验证。
• 前置条件准备提示 可以少量提及对测试准备有直接帮助的权限编码、路由、接口或日志类型，但应使用业务化语言表达，不展开无关代码路径、方法名、SQL 或表结构；只有验证手段必须依赖 DB 时才写数据库准备方式。
• 生成 前置条件准备提示 前，先确定每条 前置条件 是否足够原子化；如果无法为某条前置条件写出明确准备方式，应将该不明确点写入 待确认项，而不是用泛化描述糊过去。
• 将执行前必须存在的状态写入 前置条件，将用户或系统实际执行的动作写入 操作步骤。
• 预期结果 必须可通过界面、接口响应、导出文件、数据库状态、日志或审计记录验证。
• 每条测试用例都必须标注 用例级别；默认按照 P0、P1、P2、P3 等级区分。
• 根据 PRD 内容尽量覆盖以下类型：

- 入口和访问； - 列表展示、排序、搜索和空状态； - 权限控制和数据范围； - 成功操作流程； - 校验失败、重复数据和异常拦截； - 边界值、超时和过期规则； - 数据状态变化和关联对象行为； - 导入、导出、上传、下载或生成文件内容； - 定时任务和配置变更； - 升级或迁移行为； - 日志和审计行为。

• PRD 明确给出 toast、弹窗、错误提示或警示文案时，必须使用 PRD 原文。
• PRD 只说明存在提示但没有给出具体文案时，预期结果写为“提示成功/失败且业务结果正确”，不要自行编造文案。
• 如果 PRD 未定义某个精确预期所需的规则，新增 待确认项 章节记录，不要猜测。
• 功能类型为“新功能”时，待确认项 必须给出推荐方案，推荐方案应基于 PRD 目标、通用产品逻辑和可测试性，不得写成已确认结论。
• 功能类型为“已有功能”时，待确认项 必须结合项目代码给出现有实现，描述应面向测试执行和业务行为，不要展开无关代码路径、方法名、SQL 或表结构。
• 除非 PRD 或用户明确要求，否则不要加入纯实现层检查。
• 测试用例文件中应尽可能少提及代码和 DB 内容；只有当 PRD、现有实现或验证方式确实要求时，才可用业务化语言简要说明。
• 如需数据库验证，单次查询数据不得超过 100 条。
• 生成后必须提示用户：确认 待确认项 后，可基于确认结果增量修订当前测试用例文件，并同步修订原 PRD，在原 PRD 中新增 测试用例补充点 标题和对应补充内容。

检查要求

1. 文件已保存到用户指定或按规则推断出的 output 路径。
2. 已确认 PRD 文件路径和功能类型，功能类型只能是“新功能”或“已有功能”。
3. 每条用例均包含 前置条件准备提示、前置条件、操作步骤、预期结果。
4. 每条用例的 前置条件准备提示 与 前置条件 编号数量一致、顺序一致，并且每一项都说明对应前置条件在现有系统、测试环境、角色权限、配置入口、业务数据或验证工具中如何准备。
5. 不存在仅写“来自 PRD”“来自测试数据准备”“由测试环境提供”等泛化提示而未说明可执行准备方式的 前置条件准备提示；如确实无法判断，已纳入 待确认项。
6. 每条用例只覆盖一个独立功能点，不存在把多个独立功能点整合到同一用例的情况。
7. 用例覆盖 PRD 提到的正常、异常、权限、边界、数据、升级、日志和审计场景。
8. 不存在基于猜测写出的确定性预期。
9. PRD 中不明确的内容已通过待确认项 标出；新功能待确认项包含推荐方案，已有功能待确认项包含结合项目代码识别的现有实现。
10. 文件中存在 需求-用例追踪矩阵；矩阵包含需求ID、PRD位置、需求点摘要、覆盖用例、覆盖状态和备注。
11. 每条用例均填写 覆盖需求，且 覆盖需求 与 需求-用例追踪矩阵 中的覆盖关系一致。
12. 测试用例 章节下存在 冒烟集、主流程集、边界集、回归集 四个子标题；每条用例只出现在一个分层集下。
13. 文件末尾存在 用例结果汇总，且包含用例总数、各分层集用例数量、各级别用例数量及编号、待确认项数量。
14. 测试用例文件未过度暴露代码和 DB 内容，仅保留测试执行必要信息。
15. 最终回复包含生成文件路径、简短覆盖范围说明，并提示用户确认待确认项后可增量修订当前测试用例文件及原 PRD 的 测试用例补充点。