从需求文档到结构化用例，AI到底经过了哪些“工序”？

大家好，我是某互联网公司的测试架构师。

上个月，团队来了个新人小陈，看了我之前写的《从0到1打造测试用例生成智能体：RAG+知识图谱实战全记录》那篇文章之后跑来问我：“哥，我看了你的文章，知道RAG和知识图谱很重要，但我还是想象不出来——一个用例从需求文档到最终生成，到底经历了什么？ ”

我想了想，说：“你打开电脑，我带你走一遍。”

两个小时之后，他完整地看到了一个需求文档是怎么被AI拆解成几十条结构化测试用例的。

这篇文章，我以一个真实案例为线索，把测试用例生成智能体的全部技术栈从头到尾串一遍。

一、先看案例：我们要生成什么用例？

假设我们拿到了一份“订单取消功能”的需求文档。

业务规则大概是这样的：

• 已支付未发货的订单，用户可以申请取消
• 取消后，订单状态变为“已取消”，库存回滚，退款原路返回
• 已发货的订单，用户不能直接取消，需要联系客服
• 取消操作需要记录操作日志
• 每个订单只能取消一次

手工场景：以前测试同学拿到这份需求，要先啃文档、画流程图、梳理业务关系，然后一条条写用例——正常取消、已发货不能取消、重复取消、退款回滚……写完整套用例至少一天。

智能体场景：把需求文档上传，AI自动完成下面所有工序，15分钟出初稿。

接下来，我们跟着这个用例，走完整套技术栈。

二、第一站：文档解析与知识抽取（NLP + LLM）

智能体的第一步，是“读懂”需求文档。

技术栈： 文档解析工具（PDF/Word解析器）+ 大语言模型（LLM）

发生了什么：

原始文档是PDF格式，里面全是自然语言描述。AI首先要做的，是把这段文字结构化。

智能体调用文档解析层，提取文本内容，然后用大模型从文本中抽取出三类核心信息：

实体（Entities） ：订单、用户、库存、退款、客服、操作日志属性（Attributes） ：订单状态（已支付/已发货/已取消）、取消次数规则（Rules） ：已支付未发货可取消、已发货不可取消、取消后库存回滚、退款原路返回、每个订单只能取消一次

这一步的输出： 一份结构化的“知识卡片”——把自然语言需求变成了机器可读的实体-属性-规则列表。

小陈看到这一步的时候说了一句：“原来AI不是直接读文档，是先把文档翻译成自己能理解的结构。 ”

三、第二站：知识图谱构建（图数据库 + 关系抽取）

结构化信息还不够。AI需要知道这些实体之间是什么关系。

技术栈： 关系抽取模型 + 图数据库（Neo4j）

发生了什么：

智能体把第一步抽取的实体和规则，进一步加工成知识图谱。

知识图谱不存文档原文，存的是概念和概念之间的关系。

从刚才的文档里，智能体构建出这样一张关系网：

(订单)-[属于]->(用户)
(订单)-[触发]->(库存回滚)
(订单)-[触发]->(退款)
(订单)-[受限于]->(取消规则)
(取消规则)-[条件]->(已支付未发货)
(取消规则)-[禁止]->(已发货)
(操作日志)-[记录]->(取消操作)

存储方式： 这些三元组（实体-关系-实体）存入图数据库（如Neo4j）。查询的时候，比如问“取消订单会影响什么”，AI能从图谱里直接读出“库存回滚”和“退款”两个关联节点。

这一步的输出： 一张“业务概念地图”——AI知道订单和库存有关系、取消和退款有关系、已发货和禁止取消有关系。

小陈看到图谱的时候说：“这个厉害。以前我写用例全靠自己脑子里记这些关系，现在AI也有了一张‘关系地图’。 ”

四、第三站：RAG检索层（向量数据库 + 双路召回）

知识图谱告诉AI“概念之间有什么关系”，但AI还需要知道“文档里具体怎么说的”。

技术栈： 嵌入模型（Embedding Model）+ 向量数据库（ChromaDB/Qdrant）+ 混合检索

发生了什么：

智能体同时做两件事：

第一路：向量检索。 需求文档被切成小片段，每个片段转成向量存入向量数据库。当用户输入“生成订单取消功能的测试用例”时，系统在向量库里找最相关的文档片段。

第二路：图谱检索。 同时去知识图谱里找“订单”“取消”相关的实体和关系，把关联的子图提取出来。

两路结果合并，形成一份“带上下文的文档片段+关联关系图” ，一起喂给下一步。

这一步的输出： 一份“文档片段 + 关系地图”的混合包——AI既有原文依据，又有关系指引。

小陈看到双路召回的逻辑时说：“如果只做向量检索，搜‘订单取消’就搜不到‘库存回滚’。但有了图谱这一路，AI就知道这两件事是一起的。 ”

五、第四站：智能体推理与用例生成（LLM + Prompt Engineering）

前面三步都是“准备食材”，这一步才是“炒菜”。

技术栈： 大语言模型（DeepSeek/Claude/GPT）+ 结构化Prompt + 思维链（CoT）

发生了什么：

智能体把前三步的所有产出——文档片段、知识图谱子图、用户需求——一起打包，通过一个精心设计的Prompt喂给大模型。

我们最终稳定的Prompt模板是这样的：

你是一名资深测试工程师。请根据以下信息生成测试用例。

【测试需求】：订单取消功能

【参考文档】：{retrieved_docs}

【业务关系图】：{knowledge_graph_subgraph}

【生成要求】：
1. 覆盖正常流程、边界值、异常场景
2. 特别关注知识图谱中标注的依赖关系（如取消→库存回滚）和禁止关系（如已发货→不可取消）
3. 输出格式：表格，含用例编号、前置条件、测试步骤、预期结果、关联模块
4. 如果发现知识图谱中有相关规则未被用例覆盖，自动补充

大模型拿到这个Prompt之后，开始“思考”：

• 正常流程：已支付未发货 → 申请取消 → 订单状态变“已取消” → 库存回滚 → 退款 → 记录日志
• 异常场景1：已发货 → 申请取消 → 提示“联系客服”
• 异常场景2：重复取消 → 提示“订单已取消”
• 边界场景：刚支付1秒就取消、支付后第59分钟取消、支付后第61分钟取消
• 关联影响：库存是否真的加回来了？退款金额是否正确？日志是否完整？

最终输出： 一份结构化的测试用例表格。

小陈看到完整用例列表的时候说：“如果我自己写，可能写20条就停了。AI一口气列了40多条，而且那些关联场景——库存回滚、退款验证、日志记录——要是我自己写，大概率会漏掉一两项。 ”

六、第五站：（可选）自检与闭环

最后一步，也是拉开差距的一步——智能体自己检查自己有没有漏。

技术栈： 规则引擎 + 图谱遍历 + 二次生成

发生了什么：

智能体生成完用例之后，会做一次“反向检查” ：遍历知识图谱里的所有关系，逐一确认“每个关系是否都被用例覆盖了”。

比如图谱里有“取消→库存回滚”这条关系，智能体会检查生成的用例里有没有“验证取消后库存是否回滚”的用例。如果没有，自动补充一条。

这一步的输出： 一份经过“自检”的最终用例集，覆盖完整性比单次生成高出30%以上。

小陈看到自检环节的时候说：“这个最狠。等于AI写完了还自己检查一遍作业。 ”

七、一张图看懂全部技术栈

把上面五站串起来，就是一套完整的测试用例生成智能体技术栈：

一句话总结：RAG负责“找”资料，知识图谱负责“连”关系，智能体负责“想”和“写”，自检负责“查漏补缺”。

八、避坑指南

坑一：知识图谱一次想建全

一上来就想覆盖整个系统，结果建了两个月还没建完，项目直接烂尾。

解法： 从最核心的业务模块开始。先建订单、支付、用户三个模块的图谱，跑通流程后再逐步扩展。

坑二：RAG和知识图谱各跑各的

两套系统独立工作，检索结果和图谱结果没有融合。

解法： 做融合检索——向量检索的结果和图谱检索的结果合并成一张“带上下文的子图”，再喂给大模型。

坑三：忽略知识图谱的“自进化”

图谱建完就不管了，业务变了图谱没变。

解法： 建立反馈闭环——测试同学审核用例时标记“漏掉的场景”和“错误的关系”，定期用这些反馈更新知识图谱。

坑四：以为AI能100%替代人工

这是最大的误解。AI生成的是“初稿”，不是“终稿” 。我们的流程永远是“AI生成初稿 → 人工审核补充 → 确认入库”。AI负责把80%的基础工作做完，人负责那20%需要业务判断的部分。

智能化测试用例生成公益训练营

这周的「智能化测试用例生成公益训练营」，我们会把整条链路串起来：

• 行业大模型特性与能力测评
• 智能体工具与 Harness 工程
• Skill、CLI、MCP 工具体系
• RAG 检索增强生成与知识图谱
• 测试用例生成智能体实战

最终会落到一个测试人最熟悉的场景：

测试用例智能生成

不是只教你写几个 Prompt。

而是带大家真正理解：

一个测试用例生成智能体，到底是怎么搭出来的。