别再让AI瞎编用例了，给它一张"地图"，它自己就能走对路
大家好，我是某互联网公司的测试架构师。
去年下半年，我们团队做了一个项目——用AI自动生成测试用例。
刚开始的想法很简单：把PRD丢给大模型，让它自己生成用例。结果第一批用例出来，测试组长看了一眼就沉默了。
为什么？AI生成的用例里，有一条是"用户点击'删除账户'按钮后，系统应提示'删除成功'"——但我们的系统根本没有"删除账户"这个功能。
AI在编。
后来我们又试了RAG——把文档塞进知识库，让AI先检索再生成。效果好了一些，但新问题又来了：RAG只能召回"关键词匹配"的片段，理解不了业务关系。比如"订单"和"退款"在文档里隔了二十页，RAG搜"订单"就搜不到"退款"，生成的用例永远缺一半。
直到我们引入了知识图谱。
半年后，这个智能体已经能稳定输出覆盖正常流程、边界值、异常场景的完整用例集，人工审核通过率从最初的32%提升到了89%。
这篇文章，我把整个实战过程完整记录下来。
一、先搞清楚：为什么纯RAG不够用？
在讲方案之前，得先搞清楚一个问题：为什么市面上大多数AI测试用例生成工具，生成的用例总是不完整？
大部分人第一次看到AI生成测试用例，会产生一个误解：AI理解了你的系统。但实际上，大部分AI测试工具的工作方式是：AI在帮你查文档。
典型流程是：AI在知识库中搜索需求文档，把搜索结果和提示词一起发给大模型，大模型根据这些内容生成用例。
这个流程看起来合理，但有两个致命问题。
问题一：搜索结果不完整
RAG的核心是向量相似度搜索。如果需求文档被拆成多个部分——登录流程、登录安全策略、权限校验、用户状态——RAG可能只召回其中一部分。结果就是AI生成的测试用例缺少关键场景。
问题二：无法理解业务关系
比如"订单取消"和"库存回滚"在文档里可能隔了十几页，RAG搜"订单取消"就搜不到"库存回滚"的相关片段。但业务上这两个概念紧密相关——取消订单必须触发库存回滚。AI不知道这个关系，生成的用例就永远缺一半。
这就是为什么行业开始重新关注知识图谱。RAG解决的是"检索"问题，知识图谱解决的是"关联"问题。两者结合，才是完整的方案。
二、核心思路：RAG负责"找"，知识图谱负责"连"
用一个比喻来理解这两者的关系。
RAG像一个"图书馆管理员" 。你问它一个问题，它去书架上翻书，找到相关段落拿给你。但它不知道书和书之间有什么关系——不知道《订单管理》和《库存管理》其实是同一套系统的不同章节。
知识图谱像一张"概念地图" 。它不存文档原文，存的是概念和概念之间的关系——"订单"和"退款"是什么关系？"用户"和"订单"是什么关系？
RAG + 知识图谱 = 管理员拿着地图去找书。管理员知道去哪本书里找、也知道这本书和那本书之间有什么关联。
具体到测试用例生成场景，我们的架构是这样的：
知识图谱层：从需求文档、API文档、历史用例中提取实体（模块、功能、字段、规则）和关系（依赖、互斥、包含、触发），存入图数据库
RAG检索层：用户输入需求时，先从向量数据库检索相关文档片段，同时从知识图谱检索相关实体和关系
生成层：把检索结果和知识图谱子图一起喂给大模型，生成结构化的测试用例
用一句话说：RAG让AI"有东西可查"，知识图谱让AI"知道怎么查" 。
三、实战：四步搭建测试用例生成智能体
下面是我们实际落地的完整步骤。
第一步：构建知识图谱（最核心，最花时间）
这是整个系统的基础，也是最容易出错的一步。
收集数据源：把产品PRD、API文档（OpenAPI/Swagger）、历史用例库、设计稿说明全部收集起来。不要求一次完美，但至少要覆盖核心业务模块。
提取实体和关系：用大模型辅助从文档中提取结构化信息。
实体包括：模块（订单模块、支付模块）、功能（下单、退款、查询订单）、字段（订单号、金额、状态）、规则（满100减20、VIP用户免运费）。
关系包括：依赖（下单依赖库存）、互斥（折扣券和满减券不能叠加）、触发（支付成功触发发货）、包含（订单包含订单明细）。
存入图数据库：我们用的是Neo4j。一条典型的Cypher创建语句是这样的：
CREATE (o:Module {name: "订单模块"})
CREATE (r:Rule {name: "取消订单规则", description: "已支付订单可取消，已发货不可取消"})
CREATE (o)-[:HAS_RULE]->(r)
这一步为什么重要？ 因为有了这张"概念地图"，AI才知道"订单"和"库存"之间有关系、知道测"取消订单"的时候必须同时测"库存回滚"。
避坑提醒：不要试图一次性构建完美图谱。从核心业务模块开始，边用边补。我们第一批只建了订单和支付两个模块的图谱，跑了两个月才扩展到全系统。
第二步：搭建RAG检索层
知识图谱解决了"关系"问题，RAG解决"检索"问题。
切分文档：把长文档切分成小的文本片段。切分粒度很关键——太粗了检索不准，太细了丢失上下文。我们按"章节+功能点"的粒度切，每个片段200-500字。
向量化存储：用嵌入模型把每个片段转成向量，存入向量数据库。我们用的BGE嵌入模型+ChromaDB向量数据库。
双路召回：用户输入需求时，系统同时做两件事——在向量数据库里找相关文档片段，在知识图谱里找相关实体和关系。然后把两路结果合并，形成"文档片段+关联关系"的完整上下文。
第三步：设计智能体工作流
这是把RAG和知识图谱串起来的"大脑"。
我们的智能体工作流分为四个阶段：
阶段一：需求解析。用户输入测试需求（"帮我生成订单取消功能的测试用例"），Agent解析出关键实体（订单、取消）和测试范围。
阶段二：知识检索。Agent去向量数据库检索相关文档片段，同时去知识图谱检索"订单"和"取消"相关的实体、规则和关系。
阶段三：用例推理生成。Agent把检索结果和知识图谱子图一起喂给大模型，生成结构化用例。覆盖正常流程、边界值、异常场景、关联影响。
阶段四：自检与验证。Agent对照知识图谱检查生成的用例是否覆盖了所有关联实体和规则。如果发现遗漏，自动补充。
第四步：提示词工程
有了知识图谱和RAG，最后一步是把它们"喂"给大模型的方式设计好。
我们最终稳定的Prompt模板是这样的：
你是一名资深测试工程师。请根据以下信息生成测试用例。
【测试需求】：{user_input}
【参考文档】：{retrieved_docs}
【业务关系图】：{knowledge_graph_subgraph}
【生成要求】：
- 覆盖正常流程、边界值、异常场景
- 特别关注知识图谱中标注的依赖关系和互斥关系
- 输出格式：Markdown表格，含用例编号、前置条件、测试步骤、预期结果、关联模块
- 如果发现知识图谱中有相关规则未被用例覆盖，自动补充
关键点：把知识图谱子图放在Prompt里，AI就能"看到"业务关系，而不是只看到零散的文档片段。
四、真实效果：从32%到89%
系统上线半年后，我们统计了一组数据：
指标
纯大模型
RAG+大模型
RAG+知识图谱+智能体
用例人工审核通过率
32%
58%
89%
关联场景覆盖率
41%
63%
94%
单次生成耗时
30秒
45秒
90秒
人工补充工作量
高
中
低
最关键的变化：以前测试同学拿到AI生成的用例，第一反应是"这里不对、那里漏了"。现在变成"整体OK，只需要微调两三处"。
有研究也印证了这个趋势：结合自主AI Agent与混合向量-图谱知识系统，测试用例生成的准确率可以从65%提升到94.8%。
五、避坑指南
坑一：知识图谱建得太"大"
一上来就想覆盖全系统，结果建了三个月还没建完，项目直接烂尾。
解法：从核心业务模块开始。先建订单、支付、用户三个最核心的模块图谱，跑通流程后再逐步扩展。
坑二：RAG和知识图谱各跑各的
两套系统独立工作，检索结果和图谱结果没有融合，AI收到的还是"两份独立的信息"。
解法：在检索层做融合检索——向量检索的结果和图谱检索的结果合并成一张"带上下文的子图"，再喂给大模型。
坑三：忽略了知识图谱的"自进化"
图谱建完就不管了，业务变了图谱没变，生成的用例越来越不准。
解法：建立反馈闭环——测试同学审核用例时标记"漏掉的场景"和"错误的关系"，定期用这些反馈更新知识图谱。
坑四：认为AI能100%替代人工
这是最大的误解。AI生成的是"初稿"，不是"终稿"。我们的流程永远是"AI生成初稿→人工审核补充→确认入库"。AI负责把80%的基础工作做完，人负责那20%需要业务判断的部分。
最后
测试工程师做用例生成，过去的路径是这样的：
啃PRD → 画脑图 → 写用例 → 补场景 → 反复修改——一个模块至少2-3天。
现在的路径是这样的：
搭建知识图谱（一次性投入）→ 接入RAG检索 → 输入需求 → AI生成初稿——10分钟出初稿，1小时审核定稿。
核心变化不是"AI代替人写用例"，而是"AI帮人把'想场景'这件事系统化了"。
以前测试工程师靠经验"拍脑袋"想场景，想到哪算哪。现在知识图谱把业务关系固化下来，AI照着地图走，不会漏、不会偏。
你不需要再记住所有业务规则了。把规则存在图谱里，让AI替你记住、替你组合、替你生成。
这就是RAG+知识图谱+智能体这套组合的真正价值——它不是让你"少干活"，而是让你"把活干对"。
