需求条目化与RAG：让大模型生成测试用例真正可用的两把钥匙

一、直接用大模型生成测试用例，为什么会失败

把需求文本直接喂给大模型生成测试用例，在简单场景下效果不错，但放到真实项目中会暴露两个根本性问题：

问题一：需求质量参差不齐。 需求管理系统里的需求有的是大段流水账，有的是一句话了事，大量业务细节靠口头共识传递。这种输入质量直接决定了大模型输出的上限。

问题二：大模型不了解系统存量逻辑。 每次新需求只描述变更部分，不会把整个系统的历史约束重新写一遍。大模型只看到当前需求，生成的测试用例自然会漏掉大量已有业务规则的验证点。

这两个问题的解法分别是：需求条目化（解决输入质量）和 RAG（补充历史上下文）。

二、需求条目化：把模糊需求变成可测清单

需求条目化的本质是把一段模糊描述拆解成结构化的、每条都可独立验证的条目。操作分三步：

第一步：写整体目标。 一句话说清这个需求要实现什么。

第二步：拆分子条目。 按输入、处理、输出、异常等维度拆分，每条用 1-2 句话说清"做什么、怎么做"。

第三步：为每条附上验收条件（Acceptance Criteria）。 这是条目化质量的核心。推荐使用 Gherkin 格式（Given-When-Then）：

Given：前置条件
When：触发操作
Then：预期结果

以"发放激活码"需求为例，条目化后的格式：

复制代码

# 需求31：发放激活码，发码时从库随机取一个码发给玩家，并立即从库删除。

## 验收条件1：
Given 玩家中奖，When 系统发放码，Then 码发送成功，库中该码已删除。

## 验收条件2：
Given 库中无码，When 尝试发放，Then 报错"库存不足"，不发送无效码。

## 验收条件3：
Given 同一玩家重复中奖请求，When 处理，Then 仅发一次码，日志记录防刷。

这种格式的优势：语义清晰、边界明确、每条验收条件可以直接映射为一个测试用例。无论是否使用大模型，条目化本身就是值得在团队中推广的工程实践。

三、提示词工程：Chain Prompts 与思维链

在条目化之前，作者也探索了纯提示词方案，有两种值得参考的技术：

思维链（Chain of Thought）：在提示词中明确要求大模型按步骤推理。以因果图测试用例设计为例，提示词分三步输出：step1 分析因果关系画因果图，step2 建立判定表，step3 将判定表转换为测试用例。这种方式强制大模型显式推理，减少跳步导致的遗漏。

Chain Prompts（链式提示）：将前一个大模型的输出作为下一个提示的输入。以正交试验法为例：

第一个 Prompt：让大模型为每个参数生成边界值，返回字符串数组
第二个 Prompt：用第一步返回的参数数量和水平数，让大模型计算正交表，返回二维数组
最后用正交表替换参数值，得到测试用例

python 复制代码

# 第一步：生成边界值
prompt = f"设计参数的边界值: {desc}，边界值要包含满足要求和不满足要求的内容，直接返回字符串数组"

# 第二步：用边界值结果计算正交表
prompt = f"计算一个正交表，因素数是{len(levels)}，第1个因素水平数是{levels[0]}...强度是2，只返回二维数组"

这两种方法解决了测试设计方法的覆盖问题，但无法解决业务上下文缺失的问题------这需要 RAG 来补。

四、RAG 补充历史上下文：让大模型"知道"系统已有的约束

将所有已条目化的历史需求向量化存入知识库，每次生成测试用例时，先用当前需求检索相关历史需求，将检索结果一并送入大模型。这样大模型在生成测试用例时，能看到系统已有的业务约束，不再只依赖当前需求描述。

实现路径（以 Dify 为例）：

将历史需求整理为 Markdown 格式（每条需求含 Given-When-Then 验收条件）
在 Dify 中创建知识库，导入需求文档，配置 chunk 和索引策略
创建智能应用，关联知识库，配置系统提示词

系统提示词的核心逻辑分两阶段：

阶段一：补充完善需求。 结合检索到的历史需求，从明确性、具体性、可测性、完整性等维度补全当前需求（不输出中间结果）。

阶段二：生成测试用例。 基于补全后的需求，综合运用等价类划分、边界值分析、因果图、状态转换、场景法等设计方法，输出包含"用例名称、前置条件、输入数据、操作步骤、预期结果"的测试用例表格。

⚠️ 重要提醒：公司内部保密数据不要上传到公网大模型服务。如需使用 RAG，优先考虑本地部署的 Dify + 本地大模型（如通过 Ollama 运行）。

五、整体流程与效果

完整的落地流程：

历史需求条目化 → 整理为 Given-When-Then 格式的 Markdown 文件
建立向量知识库 → 导入 Dify，配置 embedding 和检索策略
新需求条目化 → 当前需求同样整理为条目化格式
RAG 检索 + 大模型生成 → 检索相关历史需求，补全当前需求，生成测试用例

这套流程的核心价值不只是自动化，而是把"需求质量"和"历史上下文"两个长期被忽视的问题系统性地解决了。条目化本身就能减少需求理解偏差，RAG 让大模型不再"失忆"。实践数据显示，这套组合可以提升约 20% 的测试效率。