刚拿到“吗问记忆”这期项目复盘的时候团队里都在讨论一个数字测试用例生成智能体的采纳率做到90%。这个数字在圈内意味着什么做过测试提效的人都懂——大多数AI生成测试用例的项目能稳定达到60%就算不错大量生成的用例要么格式不可用要么覆盖点不对最终沦为“demo级成果”。我们做这个智能体不是为了刷一个好看的数字而是真要让测试团队把这套工作流用起来。目前跑完三个迭代后结论是可行且具备复制性。这篇就把整个实践过程、关键设计、选型思考、踩坑记录都拆开讲。1. 为什么最终选择做智能体而不是继续“调提示词”我们在启动这个项目之前其实已经在大模型对话框里做过很长时间的测试用例生成试验。最初的效果大家都清楚你把一段需求描述丢给模型它确实能生成一批看起来有模有样的用例。但真要拿到测试评审会上问题立刻暴露——格式不统一有的人用编号、有的人用等级术语飘忽不定前置条件写得像散文步骤和预期结果常常对不上。试了非常多的提示词模板包括业界流传的各种“把角色设置为资深测试专家”之类的方式效果确实有所提升但天花板很明显。核心问题在于每次通过对话框生成都是一次独立的“临时会话”没有上下文连续性没有团队知识沉淀更没有一套可干预、可观测、可追溯的流程。用例格式靠提示词约束模型发挥不稳定覆盖点靠模型自由猜测缺乏结构化支撑。一旦需求文本超过几千字模型就开始“挑重点”看丢失细节。这个阶段持续了一两个月我们意识到一个关键点单纯放大模型的能力不是出路把“生成用例”这回事从一次性问答变成一条标准化生产线才是出路。智能体和普通AI输入的差异本质不是“能不能”的问题而是“可不可控、可不可复用、可不可回溯”的问题。智能体能承载工作流能绑定知识库能串接多轮校验能把“生成”这个动作嵌入到测试资产的业务流程里。这正是我们在做的“但问记忆”项目的起点。总结一句如果你只是偶尔生成几个用例看看思路提示词完全够用如果你想让生成用例变成测试团队每天都会用的“生产工具”那就必须往智能体方向走。2. 整体架构与技术选型为什么在Dify上做二次开发智能体的技术路线选择一开始就面临岔路自研全套框架、直接用Coze这类平台、还是基于Dify等开源平台做二次开发。我们当时列了几组对比最终选定了Dify。这里把选型逻辑讲清楚方便大家在做类似决策时参考。2.1 四类方案的对比分析方案学习成本流程编排能力私有化部署二次开发友好度适合场景自研框架LangChain/LlamaIndex起步高自由但需全部自己搭完全自控高但成本高团队有强AI工程能力Dify平台中可视化工作流编排直观支持高可接入自定义组件快速搭建企业级智能体Coze平台低节点拖拽偏C端玩法受限中个人玩家、轻量场景直接调用大模型API低无纯代码硬写取决于实现中一次性工具不适合流程化我们选择Dify的一个决定性因素是“可控性和透明性”。测试用例生成不是一次性输出就完事它需要把需求文档、历史用例库、缺陷数据、评审反馈串起来。Dify的知识库管理、工作流编排和日志追踪能覆盖这些需求而且它支持pipeline式的节点编排我们可以把“需求解析—测试点抽取—用例生成—自检校验”串成一条明确的链路每一个节点都能单独观测。另外我们内部也对比了直接基于LangChain自研。自研方案自由度最高但意味着从Prompt管理、向量检索、状态维护、前端工作台全部要造轮子。对于一个以“验证测试提效可行性”为核心目标的项目来说这不符合我们“快速跑通、小步迭代”的路线。2.2 我们的整体架构视图从功能视角看智能体由四层构成接入层测试团队上传需求文档或粘贴需求文本进入智能体工作区。处理层工作流编排的核心节点包括需求预处理器、测试点抽取器、用例生成器、自检校验器。知识层向量化后的历史用例库、测试规范库、缺陷关键词库。输出层生成候选用例列表每一份都附带溯源信息和覆盖标签直接对接评审流转。每一层都不是孤立的。最关键的还是“处理层”和“知识层”之间的协同——测试点抽取器不直接从大模型拿结果而是先检索知识库中相似模块的历史测试点再结合当前需求生成候选集。用例生成器则严格基于测试点展开避免模型“自由发挥”。3. 采纳率90%的核心设计从“生成用例”变成“生成测试点再展开”很多人把AI生成测试用例失败的原因归结于“模型能力不够”但我们的经验是模型能力只是一部分更核心的问题出在生成策略上。3.1 为什么直接生成完整用例会翻车直接让模型“根据需求生成测试用例”模型往往会生成“大而全”的东西——一个登录需求能给你列出30条用例从功能到性能、从兼容性到安全性全覆盖。表面看很全面但实际投入到评审中就不可能全被采纳原因很简单没有优先级区分正常测试工作是有侧重的核心业务逻辑和边界条件的优先级应该远高于一些外围场景。但模型生成的用例往往一视同仁全部平铺。与现有用例库重叠团队长期测试积累了大量回归用例模型不知道这些生成的用例经常和已有用例重复甚至会互相冲突。粒度不统一有的用例是一个完整场景有的用例只是一个断言点。评审时很难直接套用。3.2 我们的解法先把需求拆成测试点调整后的流程是这样的第一步需求解析将原始需求拆成“功能条目”和“约束条件”每个条目附带编号。第二步测试点抽取针对每个功能条目结合知识库中同模块的历史测试点生成当前需求的候选测试点集合。测试点的粒度控制在“一个可验证的行为断言”例如“验证未登录状态下点击购买跳转登录页”。第三步用例展开大模型只负责把测试点展开成完整用例补上测试步骤、前置条件、测试数据、预期结果等固定字段。第四步自检验证规则校验器逐个检查生成用例是否满足团队规范。这个流程最大的改变是大模型不再负责“从零到一”的用例设计而是负责“从测试点到用例”的结构化展开。测试点的设计由“知识库检索需求特征提取”决定这样就确保覆盖度来自历史沉淀和规范约束而不是模型的想象力。从数据上看这个改动是决定性的。第一版用“直接生成用例”的方式内部评测采纳率大概在45%左右改造成“测试点先行”之后采纳率直接跳到80%以上。后面再加上知识库扩充和自检规则优化才逐步稳定到90%。4. 测试知识库的构建这是智能体的“长期记忆”如果说工作流是智能体的骨架那么知识库就是它的长期记忆。在“但问记忆”这个项目里知识库的质量直接决定了测试点抽取的准确度。4.1 不是所有历史用例都适合进知识库很多人一上来就想着“把所有历史用例都丢进去”这是一个误区。我们的历史用例库里有好几万条用例但其中包含大量早已废弃的老功能、临时性的补丁用例、以及格式混乱的历史记录。如果全量灌入知识库检索出来的结果噪声极大。我们做了一次体系化的清洗。清洗规则有几条只保留当前活跃产品线的用例废弃模块的数据会干扰检索相关性。统一用例格式所有进入知识库的用例必须包含前置条件、测试步骤、预期结果三个核心字段缺失的补全或丢弃。打上标签每个用例都标注所属模块、功能点、测试类型功能/边界/异常/兼容性、优先级。关联缺陷数据如果某类用例曾经发现过线上重大问题会额外标注“高价值”标签。清洗完之后实际进入知识库的用例人数大幅缩减但检索命中质量和生成质量反而明显上升。4.2 知识检索与测试点生成的联动测试点抽取器的工作方式一句话描述就是“检索—融合—生成”。检索环节使用向量相似度召回同时叠加标签过滤。举例来说如果当前需求是“订单退款流程改造”系统会先检索知识库中与“订单”“退款”相关的用例和测试点并优先召回“高价值”标签下的内容。融合环节会把召回到的测试点与当前需求的特征做信息合并构成提示词中的参考上下文。生成环节再交给大模型去产出候选测试点。这里有一个细节值得大家注意检索到的用例不能直接堆给模型一定要做截断和去重。否则提示词上下文会越来越大模型反而容易迷失重点。我们的经验是每个功能点最多检索出的参考测试点为3至5条最佳。4.3 知识库的“飞轮”机制知识库不是建一次就完事。我们设计了一个反馈回灌机制测试人员在使用智能体生成用例时可以对每一条生成的用例进行“采纳/编辑/丢弃”操作。被采纳的用例会定期回灌到知识库成为之后生成的新参考。被大量编辑的用例也会作为“待优化样本”进入分析队列用来改进提示词或检索策略。这个机制形成了飞轮效应。使用得越久知识库就越贴近团队的实际测试习惯生成结果也越来越贴合团队的风格。这也是“但问记忆”这个名字的由来——智能体像人一样在使用过程中慢慢积累记忆而不是每次从头开始。5. 工作流中最容易被忽略的自检环节规则校验器很多人做AI生成用例把工作流设计到“生成完”就收了。实际上生成只是起点校验才是决定采纳率的关键。90%的采纳率很大一部分功劳来自生成后的那一道“自动化质检”。5.1 规则校验器的设计思路规则校验器不依赖大模型它是用一系列可执行的规则去过滤生成结果。我们最开始觉得“校验这步让模型自己检查一下就行”实测下来效果非常不稳定——模型自己检查自己等于让考生自己改自己的卷子很难发现深层次问题。后来改成确定性规则校验稳定多了。校验规则覆盖了几个层面规则类别检查内容判定方式格式规则用例编号是否唯一、字段是否完整、优先级是否合法硬校验不通过直接打回逻辑规则预期结果是否与测试步骤对应、前置条件是否充分关键词模型复核重复规则与已有用例库是否存在语义重复向量余弦相似度阈值规范规则断言是否具体避免“无异常”“正常”这类模糊断言关键词黑名单打回的情况不会直接丢弃而是进入“二次改写”环节由模型按提示词重新生成一次再走一遍校验。这个重试机制后面再细讲它在提升通过率上的贡献非常大。5.2 自检的“硬校验”和“软校验”双通道硬校验是规则明确的直接代码硬判定软校验则是需要模型做语义判断的比如“预期结果是否与用户操作逻辑匹配”。软校验其实存在一定的误报率但我们保留了它因为对于测试用例来说一个错误比对不上预期的用例被评审打回的成本要远高于一次多余的重新生成。在校验环节我们还做了一个评分卡每个用例在通过校验后会获得一个质量分从覆盖度、清晰度、规范度、复用度四个维度打分。质量分低于阈值的用例会进入“人工复核”列表而不是直接进入输出区。这样既保证输出整体质量也保留了人工介入的入口不至于让智能体变成黑盒。6. 采纳率是怎么统计的以及“90%”到底是什么口径讲到这里必须把“采纳率90%”这个数字的统计口径说清楚。因为如果口径定义不清楚任何数字都可能变成某种“刷指标”的产物。6.1 我们的统计口径在“但问记忆”项目中采纳率的定义是采纳率 测试人员在评审后“直接采纳”和“小幅修改后采纳”的用例数 / 智能体生成的候选用例总数“直接采纳”是指用例不做修改即可进入测试执行“小幅修改后采纳”是指需要修改测试数据或补充个别步骤但核心覆盖点不变。被丢弃的、需要大篇幅重构的都不算采纳。这个口径是比较严格的。因为我们实际内部也讨论过要不要把“编辑后采纳”也算进去后来觉得不能算因为如果编辑幅度超过30%那说明智能体生成的测试点方向有问题只是借了个壳而已。6.2 真实数据三个迭代周期的变化我们以某电商系统的订单模块作为试点前后跑了三个迭代周期数据如下迭代周期生成用例数直接采纳小幅修改后采纳丢弃采纳率第一版直接生成12035196645%第二版测试点先行15078423080%第三版知识库扩充自检规则14594361590%可以看到提升不是一次性到位的是逐步调出来的。第一版到第二版的变化最大本质是生成策略的改变。第二版到第三版的提升则来自知识库和校验规则的打磨。6.3 只看采纳率会有的盲区必须提醒一下采纳率高不等于测试效果好这个数字需要结合其他指标一起看。我们同时关注了另外几个口径需求覆盖率需求文档中的关键功能条目是否都有对应的测试点。缺陷检出率该模块新上的用例发现了多少个真实缺陷。这个指标最终还是要回到测试本质——用例是为了找bug不是为了“看起来有用”。生成耗时一个中等复杂度的需求从提交到生成用例我们要求控制在5分钟以内。实际大概在3分钟左右。跑完三个周期我们的结论是90%的采纳率是一个真实可用的成果但更应该把它理解为一个“流程收敛”的信号——说明生成策略、知识库、自检机制这三者已经比较匹配团队的实际测试习惯。7. 实操中的踩坑记录5个最影响采纳率的问题最后分享一下这个项目里踩过的坑。有些问题从文档和理论上根本看不出来只有实际用起来才会发现。7.1 上下文窗口被参考用例撑爆知识库检索出来的参考内容如果直接全塞给模型很快就会超出上下文窗口限制。我们早期经常出现“生成结果答非所问”的情况排查下来就是参考内容太多了模型把主要精力都放在处理参考用例上反而把当前需求的任务给忽略了。后来我们做的处理是将参考用例先做摘要压缩只保留“功能点测试点摘要高价值标签”全文内容不进提示词。这一步让生成结果的稳定性和准确度都明显提升。7.2 模型“角色扮演”的术语漂移我们为了让模型更懂业务在提示词里写了“你是一名资深测试工程师”结果模型生成的用例反而总喜欢用一些花哨的术语什么“作断言”“校验界面元素”这种词混着用和团队的术语习惯不一致。问题的根源是提示词里的角色设定太宽泛。我们后来改成不给模型设定抽象角色而是直接给它具体的“输出规范”字段名称必须是固定的、断言描述必须使用“验证xx”句式、术语必须对齐词表。测试用例生成不是一个需要创意和想象力的任务它是一个需要高度约束的结构化任务提示词要围绕约束写而不是围绕角色写。7.3 知识库的“脏数据”污染早期我们把一批格式不统一的历史用例直接导入知识库结果生成出来的测试点也带着旧用例的坏习惯——比如断言模糊、步骤描述不完整。这就像你让一个新员工模仿老同事的文档习惯老同事的文档如果有问题新员工有样学样。知识库清洗这件事没有捷径必须花人力做一轮彻底的规则化处理。我们的经验是宁可少不可脏。8000条高质量用例的效果远比30000条混杂用例要好。7.4 重试机制不加约束耗时翻倍自检失败后的二次改写我们一开始设计成“最多重试3次”结果大部分用例都在2到3次重试后才通过。单条用例生成时间从原来的几秒拉长到几十秒整体体验严重下降。后面我们把重试策略优化成“只针对明确错误重试”即只有格式错误、字段缺失这类可修复的问题才触发重试逻辑性错误直接标记为人工复核。这样重试比例降了很多生成速度恢复到可接受水平。7.5 人工评审反馈没有闭环还有一个容易忽略的坑如果测试人员改了智能体生成的用例但修改没有回流到知识库和提示词策略里那智能体永远不会变得更聪明。最开始我们跑了一周发现采纳率没有变化才意识到“评审即训练”的机制没建立起来。现在系统里每次评审修改都会记录一个“修改原因”分类标签定期统计这些标签用来反哺知识库关键词和提示词约束。闭环对采纳率的长期稳定至关重要。8. 关于更远一点的扩展和一些个人体会“但问记忆”这个项目做到现在除了测试用例生成本身我们还在探索两条延伸线。一条是在需求变更场景下基于已有用例自动补充回归测试用例减少变更回归遗漏另一条是从“生成用例”走向“生成测试计划”让智能体根据需求规模和风险评估自动建议测试分层与资源配比。从个人实操角度看我最大的体会是做AI测试用例生成智能体技术难度并不在“如何调大模型”而在“如何定义清楚流程边界”。知道什么环节该让模型发挥、什么环节该用规则硬卡、什么环节必须保留人工入口这比任何提示词技巧都重要。大模型在流程里是整个生产线上的一个环节而不是生产线的全部。如果你们团队也准备做类似的智能体我的建议是从一个业务模块开始试点先定义清楚“采纳率”的口径再逐步打磨知识库和校验规则。不要一上来就追求大而全让智能体先在一个小范围里形成正循环再往更多产品线复制。这个路径我们在实际项目中已经反复验证过了。
