关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集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 测试智能体如何真正干活”讲清楚。