Skill实战：需求文档自动生成测试点
·
Skill实战：需求文档自动生成测试点
文章目录
注意，这篇博客编写的 Skill，它的开发，测试和使用，涉及到python，需要你 提前安装 python 编辑器。
python的安装，网上的教程很多，AI也能一步一步教你，我也就不在这里介绍了。
开发环境：Vs Code
使用Skill的Agent应用：Codex
1. skill-creator 的介绍：
Codex 可以通过 Skill 扩展自身的能力，我们可以使用 skill-creator 来创建、编辑、改进和审计 AgentSkills，也可以使用它来创建我们自己的 Skill。
skill-creator 能力说明
| 场景 | 功能 |
|---|---|
| 创建新 skill | 从 0 开始创建一个完整的 skill |
| 改进现有 skill | 优化 SKILL.md 或调整目录结构 |
| 代码审查 | 验证 skill 是否符合 AgentSkills 规范 |
| 整理清理 | 移动文件到 references/ 或 scripts/，删除过时内容 |
2. 需求说明
我们将开发一个名为 requirement-testcase-generator 的 Skill，满足以下需求：
用户上传一份软件需求文档后，自动分析需求内容，将需求中的功能模块和业务需求拆分为具体的功能测试点，并生成结构化的 Markdown 测试文档。
当前版本不使用知识库和 RAG 技术，直接根据用户上传的需求文档进行测试点分析和拆分。
核心需求
- 需求文档读取：读取用户上传的需求文档，并获取其中的需求内容。
- 需求分析：分析需求文档中的功能模块、用户操作、业务规则、输入条件、输出结果、异常情况和限制条件等内容。
- 功能模块拆分：根据需求内容识别系统中的功能模块，并按照功能模块进行分类。
- 测试点拆分：针对每个功能模块，将需求进一步拆分成具体的功能测试点。
- 测试场景分析：根据需求内容，分析正常场景、异常场景、边界场景以及参数校验等测试场景。
- 预期结果生成：为每个测试点生成对应的预期结果，确保预期结果与需求内容保持一致。
- 需求追踪：建立需求与测试点之间的对应关系，方便检查需求是否得到测试覆盖。
- 需求覆盖检查：测试点生成完成后，重新检查需求文档，确认是否存在功能遗漏或测试点覆盖不足的情况。
- 测试文档生成：将最终的测试点整理成 Markdown 格式测试文档。
- 结果约束：测试点必须基于需求文档生成，不能在需求没有描述的情况下随意增加不存在的业务功能。
3. Skill 开发流程
3.1 生成需求文档
指令：
我想创建一个叫 requirement-testcase-generator 的 skill。
该技能的主要功能是：用户上传一份软件需求文档后，自动分析需求内容，将需求中的功能模块和业务需求拆分为具体的功能测试点，并生成结构化的 Markdown 测试文档。
目前不使用知识库和 RAG 技术，直接根据用户上传的需求文档进行分析。
以下是具体的功能列表：
1. 需求文档读取：读取用户上传的需求文档，并获取其中的需求内容。
2. 需求分析：分析需求文档中的功能模块、用户操作、业务规则、输入条件、输出结果、异常情况和限制条件等内容。
3. 功能模块拆分：根据需求内容识别系统中的功能模块，并按照功能模块进行分类。
4. 测试点拆分：针对每个功能模块，将需求进一步拆分成具体的功能测试点。
5. 测试场景分析：根据需求内容，分析正常场景、异常场景、边界场景以及参数校验等测试场景。
6. 预期结果生成：为每个测试点生成对应的预期结果，确保预期结果与需求内容保持一致。
7. 需求追踪：建立需求与测试点之间的对应关系，方便检查需求是否得到测试覆盖。
8. 需求覆盖检查：测试点生成完成后，重新检查需求文档，确认是否存在功能遗漏或测试点覆盖不足的情况。
9. 测试文档生成：将最终的测试点整理成 Markdown 格式测试文档。
10. 结果约束：测试点必须基于需求文档生成，不能在需求没有描述的情况下随意增加不存在的业务功能。
请基于以上需求，输出一份清晰、结构化和可操作的需求文档，命名为：
requirement-testcase-generator requirements.md
请注意：
1. 需求文档应避免讨论具体技术实现。
2. 测试点必须以用户上传的需求文档为依据。
3. 不需要使用知识库和 RAG。
4. 如果需求文档没有明确描述某项功能，不应该自行编造。
格式参考：
1. 概述
2. 功能需求
2.1 需求文档读取
2.2 需求分析
2.3 功能模块拆分
2.4 测试点拆分
2.5 测试场景分析
2.6 需求覆盖检查
2.7 测试文档生成
输出完成后，可继续与 Codex 对话修改，也可以手动编辑需求文档。
输出的需求文档的存放位置，可以从这里查看：
参考的需求文档：
我生成了一份这样的需求文档，可以供你参考一下：
# requirement-testcase-generator 需求文档
| 项目 | 内容 |
| --- | --- |
| 文档名称 | requirement-testcase-generator 需求文档 |
| 版本 | v1.0 |
| 日期 | 2026-08-25 |
| 状态 | 草稿 |
## 1. 概述
本技能面向软件测试场景。用户上传一份软件需求文档后，技能自动分析需求内容，识别系统中的功能模块，将需求拆分为具体的功能测试点，分析正常、异常、边界和参数校验等测试场景并生成预期结果，最终输出结构化的 Markdown 测试文档。
核心目标：
- 以用户上传的需求文档为唯一依据，自动生成功能测试点。
- 按功能模块分类，并建立需求与测试点之间的对应关系。
- 输出结构化 Markdown 测试文档，便于测试执行与需求覆盖评审。
关键原则：
- 所有测试点必须基于需求文档生成，需求中未描述的内容不得自行编造。
- 不使用知识库和 RAG，不依赖需求文档以外的资料。
- 本需求文档只描述业务能力和行为结果，不讨论具体技术实现。
## 2. 功能需求
### 2.1 需求文档读取
功能描述：读取用户上传的需求文档，获取其中的需求内容。
输入：用户上传的需求文档。
处理要求：
- 完整读取文档内容，获取需求正文及文档中的结构化需求信息。
- 文档无法读取或内容为空时，给出明确提示并终止后续流程。
输出：提取后的需求内容，作为后续分析的唯一依据。
### 2.2 需求分析
功能描述：分析需求文档中的功能模块、用户操作、业务规则、输入条件、输出结果、异常情况和限制条件等内容。
处理要求：
- 从需求内容中提取上述要素，并保留对应需求出处，便于后续需求追踪。
- 对需求中未明确描述的要素，不进行推测补充，应标注为“需求未明确描述”。
输出：结构化需求分析结果。
### 2.3 功能模块拆分
功能描述：根据需求分析结果识别系统中的功能模块，并按功能模块进行分类。
处理要求：
- 优先依据需求文档中明确描述的结构、章节或功能标题识别功能模块。
- 模块划分应与需求文档描述保持一致，需求中不存在的内容不得新增为功能模块。
输出：功能模块清单，以及各功能模块对应的需求条目。
### 2.4 测试点拆分
功能描述：针对每个功能模块，将需求拆分为具体、可验证的功能测试点，并为每个测试点生成预期结果。
处理要求：
- 每个测试点应能追溯到对应的需求条目。
- 测试点应覆盖需求中描述的用户操作、业务规则、输入条件、输出结果和异常情况等可测试内容。
- 测试点粒度应保证可执行、可验证。
- 每个测试点至少包含：测试点编号、所属功能模块、对应需求来源、测试场景类型、前置条件、输入条件、操作步骤、预期结果。
- 前置条件和输入条件仅在需求中明确描述时填写，需求未描述时不得自行补充。
- 预期结果必须与需求内容保持一致；需求未描述预期结果时，应标注为“需求未明确描述”。
输出：功能测试点列表。
### 2.5 测试场景分析
功能描述：根据需求内容分析测试场景，识别正常场景、异常场景、边界场景和参数校验等场景类型。
处理要求：
- 正常场景：根据需求描述的主流程和正常操作生成。
- 异常场景：根据需求中明确描述的异常情况、失败处理生成；需求未描述时不得自行设计。
- 边界场景：根据需求中明确描述的边界值、上下限或临界条件生成。
- 参数校验：根据需求中明确描述的输入条件、必填项、格式要求或取值范围生成。
- 每个测试点应标注其场景类型。
输出：带场景类型标注的测试点。
### 2.6 需求覆盖检查
功能描述：建立需求与测试点之间的对应关系，并在测试点生成完成后重新检查需求文档，确认是否存在功能遗漏或测试点覆盖不足的情况。
处理要求：
- 需求追踪：为每个测试点关联需求来源，形成需求条目与测试点的对应关系。
- 覆盖检查：重新核对需求文档中的需求条目是否都有对应测试点，识别未覆盖或覆盖不足的需求。
- 输出未覆盖需求清单或覆盖情况说明；覆盖不足时不得自行编造测试点。
输出：需求覆盖情况，包括已覆盖需求和未覆盖、覆盖不足需求清单。
### 2.7 测试文档生成
功能描述：将最终测试点整理为结构化 Markdown 测试文档。
处理要求：
- 文档应包含：文档概述、需求来源信息、功能模块与测试点列表、需求覆盖情况。
- 测试点列表应包含测试点编号、所属模块、场景类型、操作步骤、预期结果、需求来源等字段。
- 输出格式为 Markdown，结构清晰、便于阅读。
输出：Markdown 格式测试文档。
## 3. 结果约束
- 测试点必须基于用户上传的需求文档生成。
- 需求文档未明确描述的功能、操作、规则、输入输出或异常情况，不得随意增加。
- 需求描述缺失或模糊时，应在测试文档中标注“需求未明确描述”，而不是编造内容。
- 不使用知识库和 RAG，不依赖需求文档以外的资料。
3.2 设计方案（技术文档）
下面的指令，需要你提供刚刚生成好的需求文档，所以，你要让 Codex能够准确的找到，有两种方式
- 使用指令之前，把你找到的需求文档，拖拽到Codex的聊天框中
- 把需求文档在你本地的存储位置，提供给 Codex
我使用的是第一种。
指令：
请根据提供的需求文档，输出该 Skill 的技术方案（技术文档）。
技术方案应包括：
1. 清晰的 Skill 文件结构
2. SKILL.md 的职责
3. references 目录的职责
4. scripts 目录的职责
5. 核心模块的划分
6. 各模块之间的执行流程
请注意：
1. 不需要编写具体业务逻辑。
2. 请确保内容清晰、结构化，并且具有可操作性。
3. 当前版本不使用 RAG 和知识库。
4. 主要根据用户上传的需求文档进行测试点分析。
5. 最终需要生成 Markdown 格式的测试文档。
具体要求如下：
1. 使用 Python 开发辅助脚本。
2. Skill 负责读取和分析用户上传的需求文档。
3. 根据需求文档拆分功能模块。
4. 根据功能模块生成测试点。
5. 对测试点进行正常、异常、边界等场景分析。
6. 生成测试点对应的预期结果。
7. 建立需求与测试点之间的对应关系。
8. 最后生成结构化 Markdown 测试文档。
技术方案生成后，可以继续使用 Codex 对方案进行修改和完善。
技术文档生成后，存放的位置，也是同样的方法进行查看：
参考的技术文档：
我生成了一份这样的需求文档，可以供你参考一下：
# requirement-testcase-generator 技术方案
| 项目 | 内容 |
| --- | --- |
| 文档名称 | requirement-testcase-generator 技术方案 |
| 版本 | v1.0 |
| 日期 | 2026-08-25 |
| 状态 | 草稿 |
| 关联文档 | requirement-testcase-generator requirements.md |
## 1. 方案概述
本方案描述 requirement-testcase-generator Skill 的整体设计。技能的使用方式为：用户上传一份软件需求文档，技能读取并分析需求内容，拆分功能模块，生成功能测试点，分析测试场景并生成预期结果，建立需求与测试点之间的追踪关系，最后输出结构化 Markdown 测试文档。
设计原则：
- 当前版本不使用 RAG 和知识库，只依据用户上传的需求文档进行分析。
- 需求语义分析由 Skill 主流程完成，Python 脚本只承担文本提取、覆盖检查、文档渲染和结果校验等确定性辅助工作。
- 阶段之间通过 JSON 中间文件传递数据，保证流程可检查、可回溯。
- 测试点必须基于需求文档生成，需求未描述的内容不自行编造。
## 2. 总体架构
技能采用两层结构：
| 层次 | 组成 | 职责 |
| --- | --- | --- |
| Skill 编排层 | `SKILL.md`、`references/` | 定义执行流程、分析规则、输出规范，指导模型完成需求分析与测试点生成 |
| Python 脚本层 | `scripts/` | 提供确定性的辅助能力，包括文档读取、覆盖检查、Markdown 渲染和输出校验 |
整体流程如下：
```text
用户上传需求文档
│
▼
[scripts/extract_document.py] ──► requirements_raw.json
│
▼
[模型] 需求分析 ──► requirements_analysis.json
│
▼
[模型] 功能模块拆分 ──► modules.json
│
▼
[模型] 测试点生成（含场景分析与预期结果） ──► test_cases.json
│
▼
[scripts/check_coverage.py] ──► coverage.json
│
▼
[scripts/render_markdown.py] ──► 最终测试文档.md
│
▼
[scripts/validate_output.py] ──► 校验通过后交付
```
## 3. Skill 文件结构
```text
requirement-testcase-generator/
├── SKILL.md
├── references/
│ ├── test-document-template.md
│ ├── scenario-types.md
│ ├── field-definitions.md
│ └── analysis-example.md
└── scripts/
├── extract_document.py
├── check_coverage.py
├── render_markdown.py
├── validate_output.py
└── requirements.txt
```
说明：
- `SKILL.md` 是技能入口，定义完整执行流程和规则。
- `references/` 存放模板、字段定义、场景分类标准和示例。
- `scripts/` 存放 Python 辅助脚本及其 Python 依赖清单。
- 中间 JSON 文件和最终测试文档生成在用户当前工作目录中，不写入 Skill 目录。
## 4. 目录职责
### 4.1 SKILL.md
`SKILL.md` 的职责：
- 定义技能定位、适用场景和启动方式。
- 描述从需求文档读取到测试文档生成的全流程。
- 给出需求分析规则，明确需要识别功能模块、用户操作、业务规则、输入条件、输出结果、异常情况和限制条件。
- 给出测试点生成规则、测试场景分类规则和预期结果生成规则。
- 说明需求追踪与覆盖检查的执行方式。
- 指定最终 Markdown 测试文档的结构和字段。
- 声明结果约束：不使用 RAG 和知识库、不编造需求中不存在的功能、未明确描述时标注“需求未明确描述”。
- 明确各 Python 脚本的调用时机、输入文件和输出文件。
- 不包含具体业务逻辑实现。
### 4.2 references/
`references/` 的职责：
- 提供最终测试文档的结构模板，保证输出格式统一。
- 提供测试点字段定义，保证字段含义一致。
- 提供正常、异常、边界、参数校验等场景类型的定义和判断标准。
- 提供分析示例，帮助模型理解输出形式。
- 所有参考资料仅用于规范和格式参考，不作为需求来源，不能将示例中的功能混入真实测试点。
### 4.3 scripts/
`scripts/` 的职责：
- 提供确定性的 Python 辅助脚本，每个脚本职责单一。
- 脚本通过命令行参数或标准输入输出接收数据，不参与需求语义判断。
- 脚本输出结构化的 JSON 或 Markdown 文件，便于主流程继续处理。
- 脚本运行失败时返回明确的错误信息，主流程根据错误决定继续或终止。
脚本清单：
| 脚本 | 职责 | 输入 | 输出 |
| --- | --- | --- | --- |
| `extract_document.py` | 读取用户上传的需求文档并提取文本 | 需求文档文件路径 | `requirements_raw.json` |
| `check_coverage.py` | 核对需求条目与测试点的对应关系，输出覆盖情况 | `requirements_analysis.json`、`test_cases.json` | `coverage.json` |
| `render_markdown.py` | 按模板渲染最终测试文档 | `test_cases.json`、`coverage.json`、模板 | 最终 Markdown 测试文档 |
| `validate_output.py` | 校验最终文档结构与字段完整性 | 最终 Markdown 测试文档 | 校验结果 |
## 5. 核心模块划分
| 序号 | 模块 | 职责 | 输入 | 输出 | 承担层 |
| --- | --- | --- | --- | --- | --- |
| 1 | 文档读取模块 | 读取需求文档并提取文本；无法读取或内容为空时给出错误 | 用户上传的需求文档 | `requirements_raw.json` | Python 脚本 |
| 2 | 需求分析模块 | 识别功能模块、用户操作、业务规则、输入条件、输出结果、异常情况、限制条件 | `requirements_raw.json` | `requirements_analysis.json` | 模型按 `SKILL.md` 执行 |
| 3 | 功能模块拆分模块 | 按需求文档结构识别功能模块并分类 | `requirements_analysis.json` | `modules.json` | 模型按 `SKILL.md` 执行 |
| 4 | 测试点生成模块 | 将每个功能模块的需求拆分为可执行、可验证的测试点 | `modules.json`、`requirements_analysis.json` | `test_cases.json` | 模型按 `SKILL.md` 执行 |
| 5 | 测试场景分析模块 | 为测试点标注正常、异常、边界、参数校验场景类型 | `test_cases.json` | 补充场景类型后的 `test_cases.json` | 模型按 `SKILL.md` 执行 |
| 6 | 预期结果生成模块 | 为每个测试点生成与需求一致的预期结果 | `test_cases.json` | 补充预期结果后的 `test_cases.json` | 模型按 `SKILL.md` 执行 |
| 7 | 需求追踪与覆盖检查模块 | 建立需求条目与测试点对应关系，识别未覆盖或覆盖不足 | `requirements_analysis.json`、`test_cases.json` | `coverage.json` | Python 脚本 |
| 8 | 测试文档生成模块 | 将测试点与覆盖情况渲染为结构化 Markdown 并校验 | `test_cases.json`、`coverage.json`、模板 | 最终测试文档、校验结果 | Python 脚本 |
说明：
- 模块 2 至 6 属于语义分析阶段，由模型根据 `SKILL.md` 和 `references/` 中的规则执行，可以在一次分析中连续完成，但数据上仍分阶段落盘，便于检查。
- 模块 1、7、8 属于确定性处理，由 Python 脚本执行。
## 6. 模块间执行流程
1. 用户上传需求文档，技能确认文档存在。
2. 调用 `extract_document.py` 提取需求文本，写入 `requirements_raw.json`。
3. 如果文档无法读取或内容为空，向用户提示错误并终止流程。
4. 模型按 `SKILL.md` 分析需求，输出 `requirements_analysis.json`。
5. 模型拆分功能模块，输出 `modules.json`。
6. 模型针对每个功能模块生成测试点，并完成场景分析和预期结果生成，输出 `test_cases.json`。
7. 调用 `check_coverage.py`，核对每个需求条目是否都有对应测试点，输出 `coverage.json`。
8. 如果存在未覆盖或覆盖不足的需求，在最终文档中输出清单，不自动编造测试点。
9. 调用 `render_markdown.py` 生成最终 Markdown 测试文档。
10. 调用 `validate_output.py` 校验文档结构和字段，校验通过后交付给用户。
## 7. 数据文件约定
| 文件 | 内容 | 生成方 | 消费方 |
| --- | --- | --- | --- |
| `requirements_raw.json` | 从需求文档提取的文本及提取状态 | `extract_document.py` | 需求分析模块 |
| `requirements_analysis.json` | 结构化需求要素及需求条目清单 | 需求分析模块 | 拆分、生成、覆盖检查 |
| `modules.json` | 功能模块清单及对应需求条目 | 功能模块拆分模块 | 测试点生成模块 |
| `test_cases.json` | 测试点完整数据，包含场景类型与预期结果 | 测试点生成、场景分析、预期结果模块 | 覆盖检查、文档生成 |
| `coverage.json` | 已覆盖、未覆盖、覆盖不足需求清单 | `check_coverage.py` | `render_markdown.py` |
| 最终测试文档.md | 结构化 Markdown 测试文档 | `render_markdown.py` | 用户 |
测试点字段约定：
| 字段 | 说明 |
| --- | --- |
| `test_case_id` | 测试点编号 |
| `module` | 所属功能模块 |
| `requirement_ref` | 对应需求来源 |
| `scenario_type` | 场景类型：正常、异常、边界、参数校验 |
| `precondition` | 前置条件，仅在需求明确描述时填写 |
| `input_condition` | 输入条件，仅在需求明确描述时填写 |
| `steps` | 操作步骤，基于需求中的用户操作 |
| `expected_result` | 预期结果，与需求内容保持一致 |
| `note` | 备注，如“需求未明确描述” |
## 8. 约束与边界
- 当前版本不使用 RAG 和知识库，不依赖需求文档以外的资料。
- 测试点必须基于用户上传的需求文档生成。
- 需求未明确描述的功能、操作、规则、输入输出或异常情况，不得自行编造。
- 需求描述缺失或模糊时，在测试文档中标注“需求未明确描述”。
- 覆盖不足时只输出未覆盖需求清单，不自动补充测试点。
- 本方案不包含具体业务逻辑实现，脚本的内部函数、依赖库和异常处理细节在实现阶段细化。
3.3 代码实现
下面的指令，需要你提供刚刚生成好的 需求文档&技术文档，所以，你要让 Codex 能够准确的找到，有两种方式
- 使用指令之前，把你找到的 需求文档&技术文档，拖拽到Codex的聊天框中
- 把 需求文档&技术文档 在你本地的存储位置，提供给 Codex
我使用的是第一种。
指令：
请根据上一步提供的需求文档、设计文档，逐个编写核心模块，进行代码实现。
1. 根据设计文档创建完整的 Skill 目录结构。
2. 编写 SKILL.md，明确该 Skill 的使用场景、执行流程、测试点拆分规则以及测试文档输出格式。
3. 根据设计文档创建 references 目录，并将测试点生成规则、测试文档格式等内容进行合理拆分。
4. 如果设计方案中存在需要使用 Python 实现的辅助功能，请根据设计方案完成代码实现。
5. 在编写每个模块时，添加必要的注释，以便后续维护。
6. 完成每个模块后，进行必要的测试，确保代码的正确性和稳定性。
7. 如测试中发现 bug，请分析原因、修复代码，并重新测试直至通过。
8. 完成所有模块的实现和测试后，汇总整体执行情况。
9. 请特别检查测试点生成逻辑，确保测试点来源于用户上传的需求文档，不要在需求没有描述的情况下随意扩展业务功能。
10. 最终确认生成的测试文档符合设计文档中规定的 Markdown 格式。
如果修改了需求文档或技术文档，需要重新读取文档再实现：
我对文档进行了调整，请重新读取技术文档 XXXX.md，并根据最新的技术文档进行代码实现。
请注意：
1. 以最新版本的技术文档为准。
2. 如果之前的实现与最新文档存在冲突，请按照最新文档进行修改。
3. 修改完成后重新进行测试。
Skill 开发过程中，可以持续通过 Codex 对话进行修改、调试和迭代。
这个Skill开发好了之后，找到这个 Skill 的路径，然后让 Codex 对 Skill 进行测试，或者复查。
我这边存放的路径是：C:\Users\用户名\Documents\New project
在这里插入图片描述
参考的Skill
这个 Skill 的文件夹，我上传到我的 gitee 上面，你可以从那里下载这个Skill：
gitee链接：https://gitee.com/mrbgvhbhjv/skill-development/tree/master/skills/requirement-testcase-generator
4. Skill测试
指令：
请对你刚刚完成的这个 skill 进行完整的模块化测试，并执行以下步骤：
1. 需求文档读取模块：
验证是否能够正确读取用户上传的需求文档，并获取完整的需求内容。
2. 需求分析模块：
验证是否能够正确识别需求文档中的功能、业务规则、输入条件、输出结果、异常情况和限制条件。
3. 功能模块拆分：
验证是否能够根据需求内容正确划分功能模块，是否存在功能遗漏。
4. 测试点拆分：
验证是否能够根据每个功能模块生成对应的功能测试点，并检查正常场景、异常场景、边界场景和参数校验等情况。
5. 预期结果：
检查每一个测试点是否具有对应的预期结果，并确认预期结果没有脱离原始需求。
6. 需求追踪：
检查测试点是否能够对应到原始需求，确保重要需求都有对应的测试点。
7. 测试文档输出：
检查最终生成的 Markdown 测试文档格式是否正确，包括标题、表格、测试点编号、预期结果等内容。
8. 编码一致性：
全面检查需求文档、测试文档以及相关输出内容的编码，确保使用 UTF-8，避免出现乱码和字符错误。
9. 需求覆盖检查：
重新读取最初的需求文档，对照当前生成的测试点，检查是否存在遗漏的功能、业务规则或者异常场景。
10. 防止需求扩展：
检查 Skill 是否存在脱离需求文档、自行编造业务功能或测试规则的情况。
问题处理要求：
1. 测试过程中如发现任何问题，请立即进行修复。
2. 对于每个发现的问题，请记录问题现象、原因分析及修复方法。
3. 修复完成后重新执行相关测试。
4. 直到测试通过后再进行最终汇总。
需求对齐要求：
1. 请对照最初的需求文档，检查当前 Skill 的实现是否与需求一致。
2. 如发现存在不一致或遗漏的功能点，请一并修改完善。
3. 确保最终生成的测试点能够覆盖需求文档中的主要功能和业务规则。
4. 确保测试点没有明显超出需求文档的范围。
测试完成后，请向我输出一份简洁的测试报告，说明：
1. 每个模块的测试结果。
2. 发现的问题。
3. 问题原因。
4. 修复方法。
5. 最终测试结果。
6. 需求对齐情况。
Skill 的路径是：C:\Users\用户名\Documents\New project\requirement-testcase-generator
Codex 自主测试完成之后，我们在 Codex 安装这个 Skill，手动测试一下。
5. 安装Skill
第一种方式：复制目录
我们可以直接将开发好的 SKill目录，放到这个文件夹下：
这种方式，适合你清楚地知道，Codex 的skill目录在哪的情况，Codex扫描 Skill目录 的时候，能够直接识别这个Skill。
第二种方式：对话安装
打开 Codex，和他对话：
帮我安装 XXXX 下的Skill
示范：
帮我安装这个路径下的 Skill，路径：C:\Users\用户名\Documents\New project\requirement-testcase-generator
这里的路径，需要换成你自己的Skill文件夹的实际路径，注意，一定是进入这个Skill文件夹之后的路径。
检验是否安装成功：
1. 查看 Codex 的skills目录
Codex 的skills目录，在这里：
C:\Users\用户名\.codex\skills
如果已经存在了你开发的 Skill，就表示安装完成了。
2. 对话检验：
可以和 Codex，对话，问它：
列一下，你现在有哪些Skill
这样，就算是安装好了
6. 使用 Skill
6.1 使用教程
此时，我们和 Codex 对话：
先将需求文档（支持.md、.txt、.docx、.pdf），拖拽到窗口，或者提供具体的文件路劲给 Codex
请你根据这个需求文档（可填文件路径），将功能点进行拆分，生成一篇md格式的文档，并告知我生成的文档的存放位置
执行过程中，我们也是可以看到这个 SKill 的执行步骤的：
如果可以生成测试功能点的文档（md格式），并且点击进去，不是乱码，的的确确是有内容的，说明这个 Skill 是可以运行的了，是没有问题的。
这样的功能，实际是需要 使用知识库和 RAG 技术，因为在企业当中，很多需求，其实是存在关联的。
设计测试功能点的时候，需要结合到其他的需求文档，一起进行设计，这样才能使得测试功能点的覆盖率尽可能的高。
6.2 生成结果：
那么，生成的测试文档，找到生成的具体位置，打开之后：
可以看到，格式、内容等不是最完美的，需要慢慢的根据使用反馈，进行调试。
这是我根据我上传的需求文档，生成的 md文档（测试点）：
# 网页版聊天系统功能测试点
## 1. 文档概述
本文档基于《网页版聊天系统软件需求规格说明书》V1.0 生成功能测试点，覆盖用户管理、主界面、好友管理、会话管理、消息管理和在线状态管理。所有测试点均以需求文档描述为依据。
## 2. 需求来源
- 需求文档：E:\比特教学\项目课\网页聊天室\需求文档\网页版聊天系统软件需求规格说明书.docx
- 生成日期：2026-08-25
## 3. 功能模块与测试点
### 3.1 功能模块概览
| 功能模块 | 对应需求 | 测试点数量 |
| ------------ | ------------------------------------------------------------ | ---------- |
| 主界面 | SS-001, UI-001, UI-002, UI-003 | 9 |
| 会话管理 | MSG-001, MSG-003, SS-001, SS-002, SS-003 | 5 |
| 在线状态管理 | ONLINE-001, ONLINE-002 | 3 |
| 好友管理 | FR-001, FR-002, FR-003, FR-004, FR-005, REQ-002, REQ-004, REQ-005 | 15 |
| 消息管理 | MSG-001, MSG-002, MSG-003, MSG-004, REQ-001, REQ-006 | 14 |
| 用户管理 | ONLINE-003, REQ-003, UR-001, UR-002, UR-003 | 9 |
### 3.2 测试点列表
| 测试点编号 | 所属功能模块 | 对应需求来源 | 测试场景类型 | 前置条件 | 输入条件 | 操作步骤 | 预期结果 | 备注 |
| ---------- | ------------ | ------------------ | ------------ | ------------------------------ | -------------------------- | -------------------------------------- | ------------------------------------------------------------ | -------------------------------------------------- |
| TC-001 | 用户管理 | UR-001 | 参数校验 | 用户进入注册页面 | | 打开注册页面，检查页面元素 | 注册页面提供用户名输入框和密码输入框 | |
| TC-002 | 用户管理 | UR-001 | 正常 | 用户名未被注册 | 用户名、密码 | 输入用户名和密码，提交注册 | 系统处理注册请求，提示注册成功，并跳转至登录页面 | |
| TC-003 | 用户管理 | UR-001 | 异常 | | 注册信息 | 提交注册信息 | 提示注册失败 | 文档未细分注册失败原因 |
| TC-004 | 用户管理 | UR-002 | 正常 | 已注册账号 | 正确的用户名和密码 | 输入用户名和密码，提交登录 | 验证身份成功，进入系统主页面 | |
| TC-005 | 用户管理 | UR-002 | 异常 | | 错误的用户名或密码 | 提交登录 | 提示登录失败 | 对应异常场景 EX001 |
| TC-006 | 用户管理 | UR-002, ONLINE-003 | 异常 | 账号已在其他位置登录 | 用户名和密码 | 再次提交登录 | 提示登录失败，不允许重复在线 | 对应异常场景 EX002 / 9.3 重复登录限制 |
| TC-007 | 用户管理 | UR-002, REQ-003 | 异常 | 用户未登录 | | 直接访问需要登录状态的聊天功能 | 不允许使用相关功能 | 对应异常场景 EX003 |
| TC-008 | 用户管理 | UR-003 | 正常 | 用户已登录 | | 登录后进入主页面，查看顶部用户区域 | 显示当前用户昵称/用户名；可获取当前用户 ID；密码等敏感信息不显示 | |
| TC-009 | 用户管理 | UR-003 | 异常 | 用户已登录，获取用户信息失败 | | 进入主页面触发用户信息加载 | 提示获取失败 | 对应异常场景 EX004 |
| TC-010 | 主界面 | UI-001 | 正常 | 登录成功 | | 进入聊天主页面，检查页面布局 | 主页面包含用户/顶部区域、会话/好友列表、消息区域和消息输入区域 | |
| TC-011 | 主界面 | UI-002 | 正常 | 当前用户存在多个会话 | | 页面加载后查看会话列表 | 获取当前用户会话列表，并按最近访问时间排序 | |
| TC-012 | 主界面 | UI-002 | 正常 | | | 查看会话列表中的会话项 | 会话显示聊天对象和最后一条消息 | |
| TC-013 | 主界面 | UI-002 | 边界 | 存在最后一条消息较长的会话 | 过长的最后一条消息 | 查看该会话 | 过长的最后一条消息可以截断显示 | |
| TC-014 | 主界面 | UI-002 | 正常 | | | 点击会话列表中的某个会话 | 进入对应聊天窗口，该会话被选中 | |
| TC-015 | 主界面 | UI-001 | 正常 | | | 点击会话标签和好友标签 | 显示对应列表，实现会话列表和好友列表切换 | |
| TC-016 | 主界面 | UI-003 | 正常 | 页面加载完成 | | 查看好友列表并点击好友 | 好友列表显示好友名称，点击好友后进入对应聊天会话 | |
| TC-017 | 主界面 | UI-003, SS-001 | 正常 | 目标好友不存在对应会话 | | 点击该好友 | 创建新的会话并进入聊天窗口 | |
| TC-018 | 主界面 | UI-003 | 异常 | 获取好友列表失败 | | 页面加载好友列表 | 提示获取失败 | 对应异常场景 EX005 |
| TC-019 | 好友管理 | FR-001 | 正常 | | 用户名关键字 | 输入关键字并搜索 | 系统按用户名模糊匹配，显示匹配用户 | |
| TC-020 | 好友管理 | FR-001, REQ-004 | 正常 | 当前用户账号与关键字匹配 | 包含当前用户用户名的关键字 | 搜索后检查结果 | 搜索结果不包含当前用户自己 | |
| TC-021 | 好友管理 | FR-001, REQ-005 | 正常 | 目标用户已是当前用户好友 | 好友用户名 | 搜索好友用户名 | 已是好友的用户不出现于搜索结果 | |
| TC-022 | 好友管理 | FR-001, FR-002 | 正常 | 搜索结果包含非好友用户 | | 在搜索结果中选择目标用户并发起好友申请 | 可对目标用户发起好友申请 | |
| TC-023 | 好友管理 | FR-002 | 正常 | 目标用户不是当前用户且非好友 | 目标用户、验证消息 | 输入验证消息并提交好友申请 | 系统保存好友申请 | |
| TC-024 | 好友管理 | FR-002, REQ-002 | 边界 | | 100 字符的验证消息 | 提交好友申请 | 好友申请可正常提交并保存 | 需求定义验证消息长度最多 100 个字符 |
| TC-025 | 好友管理 | FR-002, REQ-002 | 边界 | | 超过 100 字符的验证消息 | 输入并提交好友申请 | 需求未明确描述（文档仅定义上限 100 字符，未说明超限处理） | 不臆造超限校验行为 |
| TC-026 | 好友管理 | FR-002 | 正常 | 目标用户在线 | | 发送好友申请 | 目标用户实时收到好友申请 | |
| TC-027 | 好友管理 | FR-002, FR-003 | 正常 | 目标用户不在线 | | 发送好友申请 | 好友申请被保存，目标用户后续登录后可查看历史好友申请 | |
| TC-028 | 好友管理 | FR-002 | 异常 | 发送好友申请失败 | | 提交好友申请 | 提示添加好友失败 | 对应异常场景 EX008 |
| TC-029 | 好友管理 | FR-003 | 正常 | 存在好友申请 | | 打开好友申请查看 | 显示申请人、验证消息、接受按钮和拒绝按钮；重新登录后仍可查看离线期间收到的申请 | |
| TC-030 | 好友管理 | FR-004 | 正常 | 存在好友申请 | | 点击接受 | 删除对应申请记录、建立双方好友关系、好友列表更新、申请提示移除；申请人在线时收到通过通知 | |
| TC-031 | 好友管理 | FR-004 | 异常 | 接受申请处理失败 | | 点击接受 | 提示处理失败 | 对应异常场景 EX009 |
| TC-032 | 好友管理 | FR-005 | 正常 | 存在好友申请 | | 点击拒绝 | 删除对应申请记录、申请提示移除、不建立好友关系 | |
| TC-033 | 好友管理 | FR-005 | 异常 | 拒绝申请处理失败 | | 点击拒绝 | 提示处理失败 | 对应异常场景 EX010 |
| TC-034 | 会话管理 | SS-001 | 正常 | 与好友已经存在会话 | | 点击该好友进入聊天 | 直接进入已有会话，不重复创建会话 | |
| TC-035 | 会话管理 | SS-001 | 正常 | 与好友不存在会话 | | 点击好友创建会话 | 创建包含当前用户和目标好友的新会话，返回会话 ID，新会话出现在会话列表 | |
| TC-036 | 会话管理 | SS-001 | 异常 | 创建会话失败 | | 触发创建会话 | 提示创建失败 | 对应异常场景 EX006 |
| TC-037 | 会话管理 | SS-003, MSG-001 | 正常 | 存在会话 | | 选择会话 | 会话被选中，聊天区域切换至对应会话，加载该会话历史消息，顶部显示当前会话名称 | |
| TC-038 | 会话管理 | SS-002, MSG-003 | 正常 | 存在多个会话，目标会话不在顶部 | | 目标会话产生新消息后查看会话列表 | 对应会话移动到会话列表顶部 | |
| TC-039 | 消息管理 | MSG-001 | 正常 | 会话存在历史消息 | | 查看历史消息 | 消息按照时间顺序展示 | |
| TC-040 | 消息管理 | MSG-001 | 正常 | | | 查看历史消息详情 | 每条消息包含消息 ID、发送者、所属会话、消息内容和消息时间，并显示发送者名称、发送时间和消息正文 | 需求要求消息数据包含消息 ID，未要求前端展示消息 ID |
| TC-041 | 消息管理 | MSG-001 | 正常 | 会话包含自己和对方发送的消息 | | 查看聊天区域 | 自己发送的消息和对方发送的消息进行区分 | |
| TC-042 | 消息管理 | MSG-001 | 正常 | 历史消息加载完成 | | 打开会话查看聊天区域 | 加载完成后聊天区域自动滚动到最新消息位置 | |
| TC-043 | 消息管理 | MSG-001 | 异常 | 查询历史消息失败 | | 打开会话 | 提示获取失败 | 对应异常场景 EX007 |
| TC-044 | 消息管理 | MSG-002 | 正常 | 已选择聊天会话 | 非空消息内容 | 输入消息并点击发送 | 消息发送至服务器并保存，关联当前会话，记录发送者和发送时间；发送成功后输入框清空 | |
| TC-045 | 消息管理 | MSG-002, REQ-006 | 参数校验 | | 空输入框 | 不输入内容直接点击发送 | 不发送消息 | |
| TC-046 | 消息管理 | MSG-002, REQ-001 | 边界 | | 2048 个字符的消息 | 发送该消息 | 消息可发送并保存 | 需求定义消息正文长度最多 2048 个字符 |
| TC-047 | 消息管理 | REQ-001 | 边界 | | 2049 个字符的消息 | 输入并发送 | 需求未明确描述（文档仅定义上限 2048 字符，未说明超限处理） | 不臆造超限校验行为 |
| TC-048 | 消息管理 | MSG-003 | 正常 | 接收方在线 | | 发送方发送消息 | 接收方实时收到消息，发送者本人也收到；更新会话最后一条消息并置顶 | |
| TC-049 | 消息管理 | MSG-003 | 正常 | 当前正在查看该会话 | | 新消息到达 | 聊天区域立即显示新消息 | |
| TC-050 | 消息管理 | MSG-003 | 正常 | 当前未查看该会话 | | 新消息到达后切换回该会话 | 新消息仍保存在系统中 | 未读消息提示属后续规划功能，需求未要求 |
| TC-051 | 消息管理 | MSG-004 | 正常 | 接收方不在线 | | 发送方发送消息 | 消息仍然保存、不实时推送；接收方重新登录后可通过历史消息查看 | |
| TC-052 | 消息管理 | MSG-002 | 正常 | | | 发送消息后查看消息时间 | 消息记录服务器时间 | |
| TC-053 | 在线状态管理 | ONLINE-001 | 正常 | | | 建立聊天连接 | 系统将用户记录为在线状态 | |
| TC-054 | 在线状态管理 | ONLINE-002 | 正常 | 用户在线 | | 关闭连接 | 系统将用户设置为离线状态 | |
| TC-055 | 在线状态管理 | ONLINE-002 | 异常 | 用户在线，连接出现异常 | | WebSocket 连接异常 | 更新用户在线状态 | 对应异常场景 EX011 |
## 4. 需求覆盖情况
共 27 条需求，已覆盖 27 条（100.0%），未覆盖 0 条。
### 4.1 未覆盖需求
所有需求均已覆盖。
7. 源码 & 需求文档获取
源码：
完整的Skill文件夹获取，可以从我的gitee中下载：
gitee链接：https://gitee.com/mrbgvhbhjv/skill-development/tree/master/skills/requirement-testcase-generator
需求文档：
很多同学可能没有需求文档哈~
你可以从我的gitee上面下载两份下来，自己玩玩这个Skill。
gitee链接：需求文档 · 何先生/Skill开发 - 码云 - 开源中国
葡萄城是专业的软件开发技术和低代码平台提供商，聚焦软件开发技术，以“赋能开发者”为使命，致力于通过表格控件、低代码和BI等各类软件开发工具和服务，一站式满足开发者需求，帮助企业提升开发效率并创新开发模式。
更多推荐
5
0- 0
已为社区贡献2条内容
所有评论(0)