测试用例生成智能体实战：一个案例搞懂全部技术栈

关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

从需求文档到结构化用例，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写完了还自己检查一遍作业。 ”

七、一张图看懂全部技术栈
把上面五站串起来，就是一套完整的测试用例生成智能体技术栈：

环节
技术栈
做什么
文档解析
PDF/Word解析器 + LLM
把自然语言需求变成结构化信息
知识图谱
关系抽取 + Neo4j
把实体关系建成“概念地图”
RAG检索
Embedding + 向量数据库
双路召回文档片段和关联关系
智能体推理
LLM + 结构化Prompt
基于所有信息生成测试用例
自检闭环
规则引擎 + 图谱遍历
检查覆盖完整性，自动补充遗漏
一句话总结：RAG负责“找”资料，知识图谱负责“连”关系，智能体负责“想”和“写”，自检负责“查漏补缺”。

八、避坑指南
坑一：知识图谱一次想建全
一上来就想覆盖整个系统，结果建了两个月还没建完，项目直接烂尾。

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

坑二：RAG和知识图谱各跑各的
两套系统独立工作，检索结果和图谱结果没有融合。

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

坑三：忽略知识图谱的“自进化”
图谱建完就不管了，业务变了图谱没变。

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

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

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

行业大模型特性与能力测评
智能体工具与 Harness 工程
Skill、CLI、MCP 工具体系
RAG 检索增强生成与知识图谱
测试用例生成智能体实战
最终会落到一个测试人最熟悉的场景：

测试用例智能生成
不是只教你写几个 Prompt。

而是带大家真正理解：

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

9月1日、3日晚20:00，免费开放
本次分享嘉宾：

思寒｜测吧 CTO、资深测试架构师
15年+ 测试开发从业经验，长期从事测试开发、测试平台及 AI 测试体系建设，曾就职于阿里、百度等企业。

训练营时间
9月1日、9月3日 20:00

公益训练营，免费参加
如果你也在关注：

AI 测试、Agent、MCP、RAG、测试智能体

或者还停留在：

“让 AI 帮我写几条测试用例”

这次训练营都值得来听一听。

👇

扫描下方海报二维码
图片

免费进入训练营群
直播入口、开课提醒及相关学习信息，会在群内统一同步。

9月1日、3日晚20:00，我们直播间见。

最后
测试工程师写用例，过去的路径是这样的：

啃PRD → 画流程图 → 梳理关系 → 写用例 → 补漏——一个模块至少1-2天。

现在的路径是这样的：

上传文档 → 智能体自动走完五站 → 输出用例初稿 → 人工审核补充——15分钟出初稿，1小时定稿。

核心变化不是“AI代替人写用例”，而是“AI帮人把‘想场景’这件事系统化了” 。

以前测试工程师靠经验“拍脑袋”想场景，想到哪算哪。现在知识图谱把业务关系固化下来，RAG把文档碎片串起来，智能体照着地图走，不会漏、不会偏。

研究数据也印证了这个趋势：结合自主AI Agent与混合向量-图谱知识系统，测试用例生成的准确率可以从65%提升到94.8% 。

下一次你拿到一份需求文档，别从零开始写了。让它走完这五站。

15分钟后，你会看到一份比你想象中更全的用例列表。

关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。