DeepSeek Harness + RAG 知识图谱：AI 测试用例生成，为什么不能只靠 Prompt？

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

9 月 1 日晚的「智能化测试·测试用例生成公益训练营」，我们从一个更贴近研发现场的问题切入：面对一个已经运行多年的业务系统，怎样让模型找到正确资料、理解规则关系，再给出能被验证、被追溯、也能持续更新的测试用例？

截至 22:01 的现场截图，已有 3025 人看过。临近结束时，评论区里有人直接追问“项目中的 flaky 用例如何定位和管理”，也有人把关注点放到上下文、知识图谱粒度、代码与文档更新、开发实现与需求不一致等真正会影响落地的问题。

AI 测试用例生成，难的从来不是“写出来”
把一份需求丢给模型，再补一句“从功能、异常、边界等维度生成测试用例”，几十秒就能得到一大段输出。

问题是，看上去很全，不等于项目里能用。

模型默认不知道：

这个业务曾经踩过哪些历史 Bug；
某个“看起来正常”的流程，在哪些角色、时间、状态下会失效；
产品原型、接口约束、研发实现、已有用例之间，哪一份才是当前可信的事实；
一个结论来自哪段需求、哪条规则，测试人员该如何复核。
所以，AI 测试用例生成不应该理解成“换一个更厉害的 Prompt”。它更像一条有输入、有检索、有推理、有验证出口的工程链路：

业务资料进入知识库 → 检索与关联规则 → 识别测试风险 → 输出结构化用例 → 人工审核与持续更新。

评论区里有两个问题，正好把这条链路的难点说透了：知识图谱里要不要放前置条件、预期结果？只做到特性级关联，能不能生成足够细的测试用例？

答案不是“图谱越大越好”，而是要让它为测试决策服务。一个可用的测试知识结构，至少要把业务对象、状态、角色、规则、前置条件、异常分支、预期结果、历史缺陷与证据来源连接起来。

如果只有“功能 A 关联功能 B”这种粗颗粒关系，模型最多写出一份泛泛的检查清单；如果能进一步定位“某角色 + 某状态 + 某个时间条件 + 某条业务规则”，它才有机会生成真正可执行的边界与异常用例。

先让 AI 看见业务，而不是让它猜业务
这场实操中，一个很关键的环节是“业务知识库建设”。它不是把 PRD 一股脑塞进对话框，而是从多个信息源还原一个业务系统：

需求文档里的业务逻辑与业务架构；
原型设计里的页面结构与交互流程；
研发代码里的业务细节、数据类型与页面结构；
对被测系统的实际探索，包括真实流程、数据和最终呈现。

这也是 RAG 在 AI 测试里的第一层价值：让模型在回答前，先从可信资料里取回证据。

但只做“相似文本检索”还不够。测试场景经常不是一句需求能解释的。例如“上下班打卡”这件事，可能同时受到早退、特殊日期、审批、设备、企业微信、补卡申请等规则影响。模型若只检索到“打卡”这一个词，很容易漏掉间接约束。

RAG 负责找证据，知识图谱负责找关系
这正是知识图谱进入测试场景的意义。

在直播实操画面里，可以看到“上下班打卡”“特殊日期打卡”“早退”等业务节点及其关联。它不是为了画一张好看的图，而是为了把散落在文档、代码和页面里的规则，变成可以被追踪、扩展和验证的关系网。

更实用的组合方式是：

RAG 先召回原始需求、接口说明、历史用例和缺陷记录，给模型可引用的事实依据；
知识图谱再补充业务对象之间的关联，帮助模型找到隐含的规则与影响范围；
Agent 按固定步骤拆解任务：识别范围、检索资料、补齐风险、生成用例、标出证据；
测试人员审核高风险边界，并把确认过的结果沉淀回用例库和知识库。
这样生成的用例，才不只是“模型觉得合理”，而是能回答三个关键问题：依据是什么？漏了什么？需求变了以后怎么更新？

DeepSeek Harness、Skill、MCP、Subagent：不是工具清单，而是工作流
这次公开课里出现的 DeepSeek Harness、Skill、CLI、MCP、RAG、Subagent，容易让人误以为测试工程师必须把所有工具都学一遍。

其实不必。

真正需要建立的是一条可控工作流：

Harness：把一次任务变成有步骤、有状态、有反馈的执行过程；
Skill / MCP / CLI：让智能体能按权限读取资料、调用检索、执行校验，而不只停留在聊天窗口；
Subagent：把检索、页面探索、用例设计、结果校验等任务适度拆开，避免一个 Agent 同时承担所有工作；
RAG 与知识图谱：把长期业务知识放在可复用、可更新的外部体系里，而不是赌模型一次会话“记得住”。
临近结束时，现场就有人追问：重复生成多个模块的用例，一旦超过上下文限制，即使用了子智能体，会不会还是丢信息？

这个问题非常专业。Subagent 不是“无限记忆外挂”。

跨任务要继承的，不该只留在某个 Agent 的聊天记录里，而要沉淀成可访问的共享资产：需求版本、规则节点、案例库、历史缺陷、检索索引、输出规范。子智能体负责的是把任务范围和职责划清；真正保证连续性的，是外部知识、引用关系和更新机制。

同样，开发提测内容和需求实现不一致时，AI 也不该替团队“猜一个答案”。更可靠的做法是让它把冲突标红：一边给出需求证据，一边给出页面或接口实际证据，并把“需要产品/研发确认”的项单独列出。AI 的价值不是掩盖不确定性，而是更早暴露不确定性。

测试工程师接下来要练的，是“让 AI 按测试思路工作”
未来的差距，可能不在于谁更快生成一百条用例，而在于谁能把下面四件事设计清楚：

知识从哪里来；
用例按什么标准生成；
模型输出如何被验证；
系统变化后如何更新。
从“让 AI 写用例”走到“让 AI 参与测试流程”，中间隔着的正是这套工程化能力。

9 月 1 日晚的分享，只是把第一步拆开：如何从业务知识出发，用 RAG、知识图谱和 Agent 思路，搭起测试用例生成的基础链路。

下一节课，继续把链路落到实操里
如果你也在关注 DeepSeek Harness、Agent、MCP、RAG、知识图谱、AI 测试用例生成，欢迎扫描文末海报二维码：

预约下一节公益训练营直播；
领取本节课后的要点整理与学习资料；
提前领取下一节课的课前学习资料和直播提醒。
9 月 3 日晚 20:00，我们继续在直播间把“AI 测试智能体如何真正干活”讲清楚。

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

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

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

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

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