每个做测试的人应该都经历过这种时刻需求文档翻了三遍用例写到一半突然发现某个状态组合没覆盖产品临时改了规则几十条用例要跟着调整版本一迭代历史用例里沉淀的边界条件又得重新人工梳理一遍。过去半年我开始系统性地尝试用“测试用例生成智能体”来解决这些问题把一个电商订单退款场景完整跑了一遍顺便把当前Agent开发常用的技术栈都过了一遍。这篇博客不聊虚的就是一个真实案例从零到落地的全过程包括我用到的工具、踩过的坑以及为什么每一步要这么选。如果你是测试开发、质量保障工程师或者正在研究AI智能体怎么落地到具体业务这篇文章应该能帮你省掉不少摸索时间。里面不会有“一键生成完美用例”的吹嘘更多的是怎么把一个只能“聊天”的AI变成一个真正能出活、结果可复用的用例生成工具。1. 先搞清楚测试用例生成智能体到底在解决什么问题1.1 传统测试用例编写为什么越来越跟不上节奏很多团队到现在还在用Excel维护测试用例遇到工期紧的时候测试人员把需求文字复制一遍照着流程写正向场景和两三个反向场景就收工了。这种模式不是不能用问题是它在面对复杂业务时效率太低。举个例子一个电商的“退款申请”功能常见的规则就有这么多已发货订单申请退款必须填写退货原因和物流单号。未发货订单可以直接退款不需要物流信息。退款金额超过1000元必须走人工审核。退款后需要同步更新库存和订单状态。这些规则互相组合之后会产生非常多的分支。人工编写时很容易漏掉“金额刚好等于1000元”“物流单号填写后又撤销申请”“退款失败但库存已扣减”这类边界场景。传统用例设计方法像等价类、边界值、判定表本身是有效的但门槛高写起来慢而且依赖个人的经验水平。我在团队里看过太多“看起来写了几百条一上线还是漏”的案例。1.2 用智能体生成测试用例核心思路是什么所谓测试用例生成智能体不是简单地在聊天框里输入“帮我生成测试用例”然后复制粘贴结果。它的核心差别在于“结构化”和“可执行”。我把智能体定义为一个能自动完成“需求理解—规则提取—用例设计—结果校验—输出到管理平台”的完整工作流。它需要做到三件事能读懂需求描述和接口定义。能调用外部工具比如查订单状态、读取历史缺陷、访问用例管理平台。能根据反馈修正自己的输出而不是一次性生成就算了。在实际实现中这需要把大模型能力和业务规则做一层“焊接”。大模型负责理解语义、生成自然语言描述和边界条件规则引擎和工具调用负责保证逻辑的确定性最终输出一份符合团队模板的测试用例。我当时选择“订单退款”作为案例是因为这个场景足够典型带有状态流转、金额阈值、异常分支和外部依赖非常适合用来验证智能体方案的完整度。如果一个智能体能把这个场景跑明白换到其他大多数业务场景都不会有太大问题。1.3 从整体看这个案例用到了哪些技术组件在真正动手之前我先梳理了要实现的能力地图需求录入能接收产品经理写的需求描述也支持结构化输入。规则解析从非结构化文本中抽取测试要点和业务规则。用例生成生成包含前置条件、操作步骤、预期结果的用例。边界补充根据等价类和边界值策略补全极端场景。去重与排序过滤重复用例按优先级排列。结果导出把用例同步到Jira或者禅道。每一项能力都不是单独靠一个提示词能搞定的。我在技术选型时把这些能力拆成了“大模型调用层”“工作流编排层”“工具调用层”“数据存储层”这也是现在主流的Agent技术栈分层方式。2. 技术栈选型解析从大模型能力到Agent编排2.1 核心框架选择直接编码还是用平台化工具现在做Agent开发大致有两条路径。一种是基于LangChain、LlamaIndex这类框架纯代码开发灵活度高适合需要深度定制和二次开发的团队另一种是使用Dify、Coze这类平台化工具通过可视化方式编排Prompt、工具调用和知识库开发效率高适合快速验证想法。我这次选的是平台化工具做原型、代码做后期补强的方式原因有三点项目时间紧张可视化编排能省掉大量前后端联调成本。用例生成的核心不是复杂逻辑而是工作流的设计平台在这些方面处理得已经很成熟。后续如果要做私有化部署Dify这类平台支持导出DSL和API接入不会把自己锁死。要注意的是平台化不代表不需要懂技术。真正上线的时候免不了要写Python脚本处理数据格式或者用Webhook把Webhook系统对接进来。所以我的建议是预算充足验证优先用平台想要极致的定制化就要做好代码开发的准备。2.2 大模型选择不能只盯着一个模型测试用例生成任务对模型的要求集中在“指令跟随”“长文本理解”“逻辑推理”三个能力上。目前主流的商用大模型和开源模型在基础能力上差距已经不大差异主要体现在上下文窗口能不能一次处理完整的接口文档。结构化输出能不能稳定返回JSON或者表格。对中文需求的理解对不同表达方式的鲁棒性。我在案例里同时配置了多个模型做对比包括通用对话模型和一个偏代码理解的模型。实际跑下来不同模型的输出风格差异很大。有的模型生成的用例偏“教科书”覆盖全面但不够贴业务有的模型则会主动结合自己训练时见过的电商案例生成的内容更接近实际用户的习惯。我在工作流里专门做了一个“模型选择”参数方便不同场景切换。一般判断标准是如果业务场景偏通用用智能程度更高的商用模型如果场景里全是专业术语和私有规则明显需要把规则库做好而不是频繁换模型。2.3 工作流编排的必要性只给大模型一段Prompt让它生成用例最直接的问题是输出不稳定。好几次我拿到初版结果发现用例编号重复前置条件和操作步骤没有对齐甚至有些用例对同一个业务规则的理解前后矛盾。最根本的原因是无状态单次调用缺少“纠错”环节。引入工作流之后我把它分成了五个阶段输入解析提取需求中的主体、规则、约束条件生成结构化要点。规则确认让智能体把识别出的测试规则列出来与预设规则库做比对不明确的先不急着生成。用例生成基于确认后的规则生成主流程用例。补充扩展按边界值、异常流、幂等等维度生成补充用例。自检修正把所有用例重新过一遍检查是否覆盖全部规则剔除重复项。这个分阶段设计能让问题提前暴露。如果直接一步生成一旦后面的结果有错误想定位是哪条规则被模型理解错了会非常麻烦。2.4 工具调用与数据存储不能把所有内容都塞进提示词测试用例生成智能体和普通对话机器人的一个重要区别是它需要“做事”。做事就要调用工具。我在这套系统里挂了几个工具订单状态查询接口给定订单号像真实系统一样返回不同状态用来模拟数据流。库存查询服务确认退款后哪些逻辑会影响库存扣减。用例管理平台API把最终生成的用例自动同步到项目里。工具调用的本质是让模型有“手”和“眼”能在生成用例时确认业务数据不是凭空想象。同时为了不把几十条规则硬塞进上下文里我把规则库放到了知识库中用向量检索按需取出相关规则。这个做法和RAG检索增强生成是一个思路在需要的时候让模型看到最相关的信息。2.5 本案例的技术栈清单这是我的完整清单不一定适用于所有场景但对测试用例生成智能体来说足够有代表性。层选型作用大模型底座商用API为主结合企业私有化模型做备用负责语义理解和文本生成Agent编排框架Dify、Coze平台 自定义Python服务负责流程状态控制和节点编排工作流设计显式分阶段流程配合节点条件分支保证生成过程可控工具调用HTTP API封装、Webhook打通状态查询和用例同步知识库向量数据库如Milvus 文件解析存储产品规则和历史用例数据存储MySQL/PostgreSQL保存生成记录和用户反馈前端低代码页面或适配已有的内部平台提供人工审核入口很多刚接触Agent开发的人会问“是不是会写Prompt就够了”从我的实践看Prompt只是最后一道工序前面的流程编排、工具接入、数据回流才是大头。3. 实战拆解从零搭建一个测试用例生成智能体3.1 明确输入和输出这是最容易被忽略的一步动手之前我先定了一个输入模板。因为智能体并不能百分之百理解散乱的自然语言需求所以我设计了下面这样的需求输入方式{ module_name: 订单退款申请, requirement_id: REQ-2024-001, user_role: 已登录用户, business_rule: [ 已发货订单申请退款必须填写退货原因和物流单号, 未发货订单可直接退款无需填写物流单号, 退款金额大于1000元需要人工审核, 退款成功后自动更新订单状态为已退款 ], priority: P0 }这个模板的意义是把需求拆成结构化字段方便后续工作流做规则提取也让模型不用自己猜哪些是规则、哪些是背景描述。输出端我也规定了标准格式每条用例必须包含以下字段字段要求用例编号统一格式TC_模块名_序号用例标题一句话说清验证目的前置条件必须独立于操作步骤测试数据金额、订单状态等参数操作步骤数字序号编号不允许出现模糊描述预期结果和规则一一对应优先级P0/P1/P2关联需求必须带上需求编号输出格式确定后工作流的设计和校验规则才有参照物。这一步省了后面内容满天飞根本没法自动化。3.2 工作流编排把流程变成组装车间在Dify里我建了一个名为“测试用例生成器”的应用工作流节点如下开始节点接收JSON格式的需求输入。变量提取节点调用大模型把输入拆成“参与角色”“触发条件”“业务规则”“约束限制”四个变量。规则检索节点在知识库中检索相似历史用例和规则补全建议。主用例生成节点综合变量和检索结果生成正向、反向流程用例。边界补充节点选择“金额边界”“状态组合”“接口异常”三个维度生成额外的用例。用例清洗节点使用大模型自查删除重复用例检查是否存在漏测规则。输出节点格式化输出为JSON列表。工作流中有一个关键细节是我把“确认规则”单独放到了“生成用例”前面。第一次跑的时候我发现模型经常会自己脑补一些系统中不存在的规则比如“退款申请超过3次拒绝后不能再申请”。这在产品需求中根本没提过。加了确认节点后我会在界面里看到它从需求中识别出的规则列表人工确认无误再继续生成避免了模型幻觉被放大。这里还要注意两个容易出错的地方。第一个是模型在做结构化输出时偶尔会漏掉某个字段我就在变量提取和大模型输出里都设置了JSON Schema校验格式不对直接让它重新生成自动重试最多三次。第二个是条件分支的阈值判断比如金额大于1000元这个规则不要让模型自己判断“是否大于”而是用代码节点让Python脚本去解析金额字段再把判断结果作为后续节点的输入。3.3 核心角色的提示词设计虽然我强调工作流比Prompt重要但Prompt仍然是整个链条里最容易出效果的优化点。我写好的一套“用例生成智能体主Prompt”拆成了几个层次系统角色的设定是你是一名资深的测试设计专家擅长等价类划分、边界值分析和场景法。你的任务是根据业务需求生成高质量、可执行的测试用例。你必须基于给定的业务规则不要凭空增加规则。如果发现业务规则之间存在冲突或遗漏请在“问题反馈”字段中说明。在生成用例的指令里我给模型定义了一套“三步法”第一步识别实体和状态。明确涉及的对象订单、用户、物流单以及每个对象的状态集合。第二步穷举状态流转路径。比如“未发货状态申请退款→系统直接退款”“已发货状态申请退款→需要填写物流信息”两条路径覆盖正向场景。第三步对每个判定条件扩展边界值。金额条件取“小于1000”“等于1000”“大于1000”三个值分别设计用例。这套写法看上去很朴素但效果比只让模型“尽可能全面地设计用例”要稳定得多。它会产出许多测试人员第一反应想不到的用例。比如我原以为正常退款已经发货的流程只要一条用例模型分出了“已发货用户输入物流单号格式错误”“用户填写退货原因后又修改”“退款中关闭页面再次进入”等多种变体对后续自动化和探索性测试都有参考价值。3.4 代码节点的作用把不可控的变成可控的工作流里我喜欢用“代码节点”处理规则判断。比如判断哪些用例属于“边界值补充”不是在提示词里让模型自觉思考而是直接写一个Python函数from typing import List, Dict def generate_boundary_data(rule: Dict) - List[Dict]: 根据金额阈值生成边界测试数据 threshold rule.get(threshold, 1000) return [ {value: threshold - 1, type: below}, {value: threshold, type: exact}, {value: threshold 1, type: above}, ]这段代码解决的问题是让模型不要在产品规则的数字上“自由发挥”。大模型的价值更多体现在识别哪个字段需要做边界分析而不是去做精确计算。一个金额阈值模型的输出有时是999.99有时是1000.01尽管也正确但不够规范测试人员拿去执行时容易对不上真实数据。用代码节点统一生成可以保证一致性。这个案例里我还写了两个类似的代码函数一个用于生成订单状态组合一个用于生成物流单号校验规则整体的复杂度都不高但属于把工程确定性和AI生成能力结合的关键动作。3.5 跑通一个真实需求从输入到输出的完整记录我把这个需求输入给智能体需求名称用户申请退款。业务规则见3.1的JSON。智能体经过规则确认后生成的结果包含以下几类用例用例类型示例对应的规则点正向主流程未发货订单提交退款申请系统自动退款未发货直接退款分支流程已发货订单填写退货物流单号后提交已发货需填写物流单号边界条件退款金额999.99元时可直接退款金额小于等于阈值时走自动退款边界条件退款金额1000元时转人工审核金额大于阈值转人工异常流程已发货订单未填物流单号直接提交缺少必填项拦截系统交互退款成功后查询订单状态同步更新状态总共生成42条用例覆盖了我人工经验粗粗输出时容易遗漏的6条边界场景。当然42条不是越多越好有的用例其实可以合并我特意在清洗节点里加了一个规则同一步骤、同一个预期结果的用例合并并将优先级从P0到P2分别标注。从输入到输出整个过程大约两分钟。中间还出现了一次知识库检索超时和一次模型输出JSON格式不合法我在下一章统一说这些问题的排查经验。4. 这个案例里用到的Agent开发全技术栈拆解4.1 不只是“AI工程师”需要懂技术栈这个话题是热词“Agent开发需要哪些技术栈”背后真正想问的。通过这个案例我认识到Agent开发需要的不是某一种单一技术而是跨了AI应用开发、后端服务和前端界面三块。从角色视角拆分提示词工程师要能把业务规则转化成精确指令同时设计可靠的输出格式。后端工程师需要处理API集成、鉴权、数据存储、异步任务。算法工程师要理解向量检索、模型选型、效果评估指标。测试开发工程师在这个场景里反而要负责定义“什么叫生成质量好”。如果是个人独立开发一个Agent应用很难做到“全栈”精通但一定要具备快速理解其他模块的能力。我在学语言模型调用时发现很多后端开发者并不熟悉函数调用参数怎么定义而很多AI应用开发者又容易忽略数据安全和权限控制。实际落地时这类问题才是最大的瓶颈。4.2 最小可用的Agent技术栈组合如果现在有人想从零入门做Agent我建议先从这四个方向入手不用一上来就研究特别复杂的内容大模型API调用掌握ChatCompletion接口、消息格式、温度和Top_p参数的作用。提示词工程学会角色设定、上下文少样本示例、思维链和结构化输出。工作流编排理解如果利用平台的条件分支和变量去处理多步骤任务。工具调用先把一个HTTP API封装给Agent用再考虑接多个工具。以这个测试用例生成智能体为例最简版本是“Prompt API Agent 规则代码节点”的组合。先花一个下午时间在平台里搭出原型跑通一个最核心的需求场景再逐步加入知识库、模型切换、结果审核界面这些增强功能。4.3 从热词看行业趋势智能体正在“岗位化”我在整理技术栈时观察到一个明显的趋势现在的智能体不再停留在“助手”层面而是开始往“能独立干活的数字员工”方向发展比如销售智能体、时序智能体、多智能体协作等概念本质上都是把某一类重复性高、规则相对清晰的岗位流程自动化。测试用例生成属于“专业内容生成”领域的典型场景。相比销售智能体它的好处是输出质量判定标准相对客观用例是否覆盖所有需求规则边界值设计是否充分这些都是可以用自动化方式去评估的。这意味着它更容易进入企业生产流程。后面如果要扩展可以把它从“生成用例”推进到“生成自动化测试脚本”再进一步结合回归测试结果来动态修正用例的优先级。5. 实战中踩过的坑与排查技巧5.1 输出不稳定同一份需求生成两次结果不一样第一次跑通流程时我连续调用了三轮结果发现第二次生成的用例数量少了将近三分之一。原因是大模型生成过程本身就是有随机性的平台默认配置了较高的随机采样参数。在排查这类问题的时候我的策略是在平台里把模型的Temperature参数从默认值降到0.1输出稳定性明显提升。对涉及规则判断的关键节点增加一个“规则覆盖确认”的子任务要求模型把已经覆盖的需求规则逐条列出。在最终节点增加用例数量范围校验如果少于预先设定的数量自动触发重试。大模型的随机性并不完全是坏事。如果目标是探索业务未知边界反而需要把随机参数调高一些用来生成更多样的探索性测试用例。5.2 工具调用传参格式不对在让智能体调用订单状态查询服务时接口要求入参是JSON格式包含“order_id”和“env”两个字段但是模型输出的参数名有时是“orderId”有时是“id”导致后端服务报错。后来我在工具定义里加了严格的参数说明用中文注明“字段名必须为order_id不要自己修改”并提供了一个示例{ order_id: ORDER_123456, env: test }这个问题提醒我工具调用不等于让Agent自己猜参数。我们要把接口当成一个严谨的API去约束它能做成选择题的不要做填空题。比如可以给“env”字段设置枚举值“test、staging、production”让模型只能在这些值中选择。这种前端表单的设计思路放在Agent里同样管用。5.3 知识库规则检索命中率低我在知识库里放了三类内容产品文档、历史优秀测试用例、常见业务规则。但实测下来由于这三类数据是混在同一个知识库集合里的查询“退款金额校验”时偶尔会匹配到与库存相关的内容。后来我把知识库按用途拆分成了两个集合规则库只放相对稳定的业务规则和边界约定。用例库存放经过评审标记为优秀的历史测试用例。因为RAG检索的质量和数据的纯度强相关一个集合里的内容话题越集中检索效果越好。如果内容过于混杂模型抽取出的信息噪声就会变大最后生成的用例质量自然受影响。5.4 缺少反馈闭环时Agent无法自我进化我前几次搭建智能体止步于“生成→输出”。用了一段时间后发现生成结果里有一些明显的行业常识错误但Agent并不会主动修正。这就是热词里“智能体学习进化”的关键点——需要一个反馈机制。我在案例里加了一个“测试人员反馈”字段实际执行结果通过。实际执行结果失败原因是用例设计错误。实际执行结果失败原因是发现了产品缺陷。用户提交后系统会把标记为“用例设计错误”的记录自动回流到知识库中备查下一次生成时会尽量避免同类问题。这种做法本质上是用人类反馈做强化学习的数据雏形对大多数中小团队来说比微调模型要经济得多。5.5 问题排查速查表现象可能原因处理方向生成的用例数量忽多忽少大模型随机性高缺少规则覆盖校验调低Temperature增加覆盖确认节点规则被脑补没有独立规则确认环节拆出“规则确认”节点人工或自动校验JSON结构不完整输出格式约束不足设置JSON Schema校验失败自动重试工具调用报参数错误参数命名和类型未严格定义在工具定义中详细写明参数说明和枚举值检索到无关规则知识库内容混合按用途拆分知识库集合模型不懂得基于团队模板输出缺少必要的少样本示例在Prompt中提供两三条优秀的参考用例这套排查方法不只适用于测试用例生成智能体遇到其他Agent项目完全可以直接套用因为它们的问题基本都出在这几个层面。6. 写在最后几点个人心得测试用例生成智能体这件事做起来比听上去要复杂一截。它不是一个Language Model调用能搞定的要把工作流、工具调用、规则库、输出校验全部串起来工程上的琐碎程度比我一开始想的高很多。但也正因如此它非常适合作为Agent开发入门的学习案例——场景边界清晰、判优客观、牵扯的技术栈广一套下来基本能理解当下“智能体技术栈”这个词的真实内涵。我个人这半年下来最深的体会是把预期目标定得保守一点效果反而更容易超出预期。不要指望它能完全替代测试工程师它在多数时候给出的高质量草稿和边界提示能让人把时间花在更有创造力的探索性测试和线上质量分析上这已经是很好的回报。如果以后要再往前进一步我会尝试把生成的用例直接转成自动化脚本再和CI流程串起来做智能回归筛选。现阶段建议刚上手的朋友先用一个自己熟悉的业务场景跑通这个流程把边界值、状态流转、工具调用都体验一遍你会对AI智能体到底能做到什么程度有更真实的认知。