前言

之前的教程我们已经知道了如何设计一个 SKILL 去完成我们的接口自动化测试工作，但很多星球的小伙伴都反馈，能够给大模型生成自动化测试代码的手工步骤要怎么生成。 也就是从需求文档中生成测试用例， 要怎么样做效果才好。 这个内容我在上周的直播中也讲过。 这里我再写一个文字版本。 首先， 大家可以进入星球先下载我提前做好的 skills 包 demo：

接下来我们看看，要想生成的测试用例足够好， 都要怎么做。

要如何设计知识库

知识库是从需求文档中生成测试用例最重要的东西。 之前的帖子中我们讲过知识库要遵循渐进式设计。这里我就不再赘述，我们先单纯的说明一下要给大模型什么样的知识， 才能让用例生成的更加完善。

知识库中需要有什么东西

• 当前产品的全量功能描述文档（如果没有全量的，跟你自己负责的模块有关的文档也可以）：我们在设计测试用例的时候，最重要的是考虑新需求，新改动是否影响了其他的模块。所以我们需要给大模型其他模块的功能描述文档。这样大模型才能结合产品其他功能进行深度思考。如图：
• 需求和用例分析时的通用规则：这些规则是什么呢？这些就是从测试人员角度，去分析需求的经验或者规则。 比如新需求修改了数据库中的字段，但却没提用户历史数据要怎么迁移。 这时候我们的大模型需要识别出来并进行提醒。又或者字段填写非法的时候应该是什么反应。 如图：
• 业务特点的规则：上面的第二点算是通用的设计和分析规则，属于不管哪些产品都能用的上的。但是我们总会有业务上的一些规则。 我举个例子，在我负责的产品中，有一个模块叫操作日志。我们在应用中某些关键的配置更改，数据下载等操作都要记录下来（企业要求数据安全，操作要留痕）。但一些不是很重要的操作，就不会记录这个日志。所以我在 skill 的业务规则里会写一条：需求中新增了应用的任何配置，都需要确认该配置是否要添加到操作日志里。 又比如，我们有一个模型广场的模块，用户可以在这里新建自定义模型。 熟悉大模型的同学都知道有的模型支持深度思考开关，有的不支持。 支持深度思考开关的还区分了是否支持开启二级参数（high，midem，low）。所以我在业务规则里就会写：凡是新需求中涉及到新增模型，都需要确认是否支持深度思考开关，是否支持二级开关。
• 产品当前的测试用例/自动化测试用例：这部分也是让大模型进行参考，从历史用例中，大模型也能学习到很多逻辑，帮助生成测试用例。所以我也一直说 ：everything in git 是一个好的设计。大模型可以充分参考各种知识来源。

结合一下我得 skill 包，可以看一下：

很多同学觉得需求生成测试用例的效果不好，可能就是给的知识没有到位。使用 AI，心态是一个很重要的因素。 不能指望把需求文档丢给它，让它自己发挥。我们需要用工作流和知识库来引导大模型。这是一个需要耐心和时间的活。不是可以速成的。

skill 中的工作流

我们这里再看一下工作流。

• 需求评审：先评审需求，按照知识库中的内容，先让大模型分析需求是否完善，那些不确定的东西需要向产品经理确认。
  • 第一步：查询现有产品相关的功能：让大模型进行语义检索功能文档， 找到跟当前需求相关联的功能。PS：语义检索是每个 AI 代码工具都有的功能（比如 curosr，codex，等）
  • 第二步：根据查询到的内容，再去查询业务规则和通用规则，评估当前需求中还有哪些细节是有问题的。
  • 第三步：输出需求评估报告。 等到产品确认细节后，再给大模型，反复到需求评审通过。
• 测试用例生成：当需求评审完毕后， 测试用例生成也就是水到渠成的了。

下面给出需求评审的工作流 markdown 片段：

# 需求评审 Skill（轻量版）

## 什么时候使用

测试人员拿到新需求，希望从测试视角挑战需求文档、识别与已有功能的潜在冲突、找出边界不清的地方。

## 唯一产出

**一份 markdown 报告**，写在用户指定的路径（默认 `docs/req-review/<slug>-review.md`）。

不产出任何 JSON、不创建任务工作空间、不做 schema 校验、不做归档。

## 工作流（3 步）

### 第 1 步：理解输入

接收两种形态之一：

- **文件路径**：用户给一个本地 md 文件路径
- **粘贴文本**：用户直接粘贴需求描述

主 Skill 用 `read_file` 读入内容（如果是路径），或直接使用粘贴文本作为需求原文。

从需求标题或第一段提炼一个 slug（去空格、转小写、保留 ASCII），用于默认输出文件名。如果用户已指定输出路径，使用用户指定的。

### 第 2 步：调用 `req-review-associator`（关联分析）

加载子 Skill：`use_skill("req-review-associator")`

把以下信息传给子 Skill：

- 需求原文
- 输出路径预期

子 Skill 完成关联分析后，**在对话中返回一段 markdown 片段**（包含"关联模块清单 + 关联原因 + 受影响的现有自动化用例清单"），不落盘任何中间产物。

主 Skill 收到这段 markdown 后保存在内存，传给第 3 步。

### 第 3 步：调用 `req-review-challenger`（审查挑战 + 生成最终报告）

加载子 Skill：`use_skill("req-review-challenger")`

把以下信息传给子 Skill：

- 需求原文
- 第 2 步返回的关联分析 markdown 片段
- 最终输出文件路径

子 Skill 内部完成：

1. 加载 `../req-review/references/requirement_types.md` 识别需求类型（表为空时识别为 `other`）
2. 加载 `../req-review/references/review_checklist_common.md`（永远加载）
3. 按识别到的类型加载 `../req-review/references/review_checklist_by_type/<type>.md`（表为空时不加载专项）
4. 用 checklist 挑战需求，把关联分析片段合并到最终报告
5. 直接 `write_to_file` 把组装好的 markdown 写到用户指定路径

结尾

更多内容可以看 skill 包内容和我上周的直播内容。 这里再宣传一下星球：