根据 PRD 生成测试用例

任务背景

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

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

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

任务步骤

检查用户消息中是否明确提供 PRD 文件路径；没有路径时停止执行，并要求用户补充路径。
确认用户是否明确说明功能类型为“新功能”或“已有功能”；未说明时停止执行，并要求用户确认功能类型。
定位并读取用户提供的 PRD 文件。
如果 PRD 引用了 UI 图片或同目录辅助文件，且这些文件会影响路由、页面、按钮、字段或交互理解，则读取并分析对应文件。
如果功能类型为“已有功能”，依据 PRD 中的功能位置、路由、菜单路径和图片信息依次查找前端代码，再根据最终页面代码反向定位接口、服务和关键实现，用于识别现有行为与待确认项。
写入前先检查目标 output 目录，了解项目中已有的命名和目录惯例。
从 PRD 中提取需求点：
- 功能标题和需求版本；
- 功能位置、路由或菜单路径；
- 用户角色、权限控制和数据可见范围；
- 正常流程、异常流程、边界规则和状态流转；
- 字段规则、按钮状态、弹窗、提示、导入导出、下载内容和数据影响；
- 升级、迁移、定时任务、日志、审计和权限初始化规则。
将需求点拆分为可验证的原子需求，生成稳定需求编号（例如 REQ-<领域前缀>-001），并保留 PRD 位置、需求点摘要和不明确事项。
将原子需求转换为测试场景，再转换为可执行测试用例；每条测试用例只覆盖一个独立功能点，不得把多个功能点整合到同一个用例中。
为每条测试用例分配唯一用例分层：冒烟集、主流程集、边界集、回归集；同一条测试用例只能归入一个分层集，不得跨分层重复出现。
生成 需求-用例追踪矩阵 章节；矩阵需体现需求编号、PRD 位置、需求点摘要、覆盖用例、覆盖状态和备注。
生成 待确认项 章节：新功能写明推荐方案；已有功能写明从项目代码识别到的现有实现。
在测试用例文件末尾生成 用例结果汇总 章节，汇总需同时体现用例总数、各分层集数量、各级别数量及编号、不可自动化用例数量及编号、待确认项数量。
将测试用例文件写入项目 output 目录。
重新读取生成文件或检查文件元数据，确认路径和核心结构正确。
最终回复提示用户：确认待确认项后，可以增量修订当前测试用例文件，并在原 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 | <章节/条目> | <可验证的原子需求摘要> | 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，无”>
- 不可自动化用例数量及编号：<数量>（<TC 编号列表；没有则写“0，无”>）
- 待确认项数量：<数量>

编写规则

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

检查要求

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