开头我先说个真事。前几天有朋友问我说他们测试组天天手工写用例一个版本几十条用例写到吐问我能不能用 AI 直接把这事儿干了。我当时就给了一句结论能但你别指望拿个 ChatGPT 网页版就去点真正能落地的是把它做成一个测试用例生成智能体——你甩给它一个需求描述它自己会去查业务规则、按规范拆场景、套边界条件最后吐出一张可以直接用的标准用例表。这篇我就拿一个完整的案例从需求拆解到技术选型再到提示词设计、流程编排、问题排查把整套技术栈从头到尾捋一遍。不管你是测试工程师想提效还是开发想搞 Agent 应用只要跟着这个案例走一遍你基本就能摸清智能体落地这件事的门道了。1. 案例定位与需求拆解先搞清楚智能体到底要干啥1.1 从一条需求到一张用例表中间发生了什么先说清楚咱们这个案例要解决的业务问题。我选了一个非常典型但又不过于复杂的模块用户登录 订单查询。这个功能几乎是所有业务系统的标配它既有输入校验、权限控制又有数据返回、状态流转边界条件丰富非常适合用来演示测试用例生成的完整逻辑。传统的做法是测试工程师拿到 PRD自己脑补场景手动写用例再拉产品评审。这个流程最大的问题是用例质量完全取决于个人经验产品对需求的理解偏差会导致漏测而且写用例本身占用大量时间。智能体要替代的就是这条链路里从需求到用例这一段。咱们这个智能体的输入很简单就一段自然语言描述比如用户登录功能用户输入账号密码验证通过后进入订单查询页 账号错误或密码错误均提示账号或密码错误连续失败5次锁定账号30分钟 订单查询支持按订单号精确查询、按状态筛选列表订单状态有待支付、已支付、已发货、已完成、已取消五种。智能体要输出的是一张结构化的测试用例表包含用例编号、模块、前置条件、操作步骤、输入数据、预期结果、优先级这些字段。这个输出要能被复制到 Excel 或者直接导入禅道、Jira而不是给你一段没法用的叙述文。1.2 功能拆解智能体的三层能力模型要实现上面这个效果光靠调用一次大模型是不够的。为什么这么说因为大模型本身就像一个记忆力超强但容易自由发挥的新人——你直接问它请给登录功能写测试用例它当然能写出来但你没法保证质量问题场景覆盖不全、预期结果写得含糊、边界值漏测、输出格式飘忽不定。这些问题单靠提示词是压不住的得靠工程手段去兜底。所以这个案例里的智能体我把它拆成了三层能力需求解析层把自然语言的需求描述结构化地提取出功能点、输入项、业务规则、状态流转等要素。这一层决定了后面用例生成的覆盖面。场景生成层基于提取到的要素按照测试设计方法等价类、边界值、状态迁移、异常场景等生成候选场景集合。这一层相当于一个测试设计专家在规划思路。格式化输出层把场景转化为符合规范的用例条目补充前置条件、步骤描述、预期结果并设置优先级。这一层是关键它保证输出不是一堆人话而是可以直接使用的工程产物。这三层能力如果都塞进一次 Prompt 调用里模型负担太重容易出现顾此失彼的情况。我在实战中强烈建议拆成多个节点去执行这也是智能体和一次性问答的本质区别——智能体有流程编排、有中间产物、有状态管理它更像一条流水线而不是一个问答框。2. 技术栈选型与架构设计为什么我这么搭2.1 智能体框架选型Dify、Coze 还是自研现在市面上做智能体的框架非常多搜一下全是 Coze、Dify、LangChain、AgentScope 之类的。我自己的选型经验是先别追新先看你的团队是业务导向还是技术导向。如果你本身不是专门做 AI 开发的只是想快速给测试团队做个提效工具Dify 是我综合体验下来最稳妥的选择。它的优势在于图形化编排流程、自带知识库RAG能力、内置变量管理和日志追踪部署也简单。你不需要从零写框架代码很多能力它已经给你封装好了。Coze 也不错但它在国内版和海外版的模型选择上有限制而且更偏向对话类应用在工作流编排 结构化输出这种场景下不如 Dify 顺手。如果你追求的是极致的可控性团队也有 AI 工程能力那可以考虑 LangChain 这类框架自己在代码里编排。但我的观点很明确凡是标准业务场景能做成的不要自己造轮子。自研的成本往往被低估——你以为只是调几个 API实际上还要处理上下文管理、缓存、错误重试、数据持久化这些工作 Dify 早就帮你做完了。2.2 模型底座生成质量和运行成本的平衡模型选型这里我踩过一次坑。最开始我贪图生成质量选了当时最强的一个大模型结果单次生成测试用例要等十几秒一问价格成本还不低。如果是个人玩无所谓但要是在公司里给整个测试团队用这个成本会被迅速放大。后来我把模型做了分场景配置需求解析和场景生成这种高质量要求环节用中大型模型格式化输出这种机械性工作用小模型就能搞定。不同框架对模型切换的支持程度不同Dify 在节点级别就可以指定不同模型这一点非常方便。如果你是 0 成本起步想先验证效果直接用各大平台提供的免费模型额度也够用比如智谱、通义、DeepSeek 这些都有免费档位。先用免费模型把流程跑通再根据效果决定要不要上更强的模型这个路子是最理性的。2.3 知识库与 MCP要不要上 RAG要不要接 MCP问答里很多人提到智能体的企业知识库是存放在向量数据库中的吗这个问题特别典型。答案是要看你的智能体需不需要借用外部知识。测试用例生成这个场景如果只是输入一段需求描述就生成用例其实用不到知识库。但一旦你想让智能体读一读咱们公司的测试规范查一下历史缺陷库里的高频问题那就必须要引入 RAG——把规范文档和历史数据向量化存到向量数据库里生成用例时先检索相关规则再生成。我建议这个案例在最开始时不要上 RAG先把核心流程跑通。等到你觉得生成的用例跟你们公司的规范对不上的时候再补知识库功能这样迭代路径最清晰。至于 MCPModel Context Protocol这个热搜词最近很火但我的建议是先别为了用而用。MCP 的价值在于让智能体实时调用外部工具比如查数据库、调接口。测试用例生成这个场景除非你要让智能体实时读取接口文档去分析参数边界否则不太需要 MCP 参与。至少我做的第一版是完全没接 MCP 的效果已经够用。3. 提示词工程与核心实现智能体聪明不聪明全看这里3.1 项目提示词的核心设计思路提示词是这个智能体的灵魂。很多人觉得提示词就是你是一个测试专家请帮我写用例这样也能跑但你试几次就会发现输出质量不稳定。问题出在缺少约束、缺少方法引导、缺少输出规范。我给你看一下我在实际项目中使用的系统提示词你就明白差距在哪里了你是一名资深的软件测试工程师擅长功能测试用例设计熟悉等价类划分、边界值分析、状态迁移法、场景法等常用测试设计方法。 你将接收到用户对待测功能模块的自然语言描述请按以下流程完成任务 第一提炼测试要素 - 功能点清单当前模块涉及哪些核心功能点 - 输入项每个输入项的字段名、类型、约束条件如必填、长度、格式、取值范围 - 业务规则需求描述中涉及的所有规则特别是异常情况和处理方式 - 状态流转如果涉及状态切换列出所有状态和事件 第二基于测试要素生成测试场景清单 - 对每个功能点先覆盖主流程的正常场景 - 再覆盖异常场景包括输入非法、操作顺序错误、权限不足、数据不存在等 - 对每个有明确取值范围或长度的字段使用边界值法补充边界场景 - 如有状态流转使用状态迁移法覆盖合法迁移和非法迁移 第三将测试场景转化为标准用例输出格式如下表格 | 用例编号 | 模块 | 前置条件 | 操作步骤 | 输入数据 | 预期结果 | 优先级 | 用例编号规则模块名首字母缩写 三位数字序号如 LOGIN_001。 操作步骤请使用 1.xxx 2.xxx 的格式多条数据使用顿号分隔。 预期结果必须可验证禁止出现系统正常处理这类模糊表达。 优先级统一使用 P0/P1/P2/P3 四级。 注意事项 - 如果需求描述中没有明确说明某个输入项的限制条件请在用例中给出合理默认值并在预期结果中注明基于默认约束 - 禁止自己编造需求里不存在的业务规则 - 所有用例的总数控制在 20 至 40 条之间如场景明显较多优先保证主流程和异常分支这一段提示词我调了很多版最后总结出来的核心经验是三条给流程、给方法、给格式。给流程是让模型分步思考不要一口气乱写给方法是明确告诉它用等价类、边界值这些具体方法论而不是含糊的设计全面用例给格式是保证输出稳定可解析。3.2 结构化输出的实现表格真的能稳定生成吗很多人看到上面要求输出表格格式第一反应是大模型输出的 Markdown 表格能稳定用吗我的回答是单次生成时表头偶尔会漂移但通过框架的结构化输出能力这个问题是可以被解决掉的。Dify 的工作流模式里你可以直接定义一个输出变量在节点中指定它必须是 JSON 格式并附上 JSON Schema。这样模型输出就会被强制约束为合法的 JSON你再在后端把 JSON 转成 Excel 或导入用例管理平台比解析文本要稳定得多。我在实际项目里的做法是让格式化输出节点直接输出一个 JSON 数组每个元素包含 用例编号、模块、前置条件、操作步骤、输入数据、预期结果、优先级 这七个字段。然后在 Dify 的结束节点里做一个直接返回的配置前端拿到 JSON 渲染成表格同时支持一键导出 CSV。这个方法稳定跑了几个月没有出现过一次格式错乱。3.3 流程编排从一次生成到多节点协作这里我放一个我在 Dify 里实际配置的工作流结构你可以直接照着搭开始节点接收用户输入需求描述 → LLM节点1需求解析输出要素清单 JSON → 代码节点要素检查校验 JSON 是否包含 inputs 字段缺失则报错提示用户补充 → LLM节点2场景生成输入要素清单输出场景清单 JSON → LLM节点3用例格式化输入场景清单输出标准用例 JSON 数组 → 结束节点输出测试用例表格 下载链接你可能会问为什么中间要插一个代码节点做校验因为我发现一个很实际的问题需求描述有时候写得太简略比如客户就扔给你一句登录功能测一下这时候模型再怎么发散生成的用例也没有依据。所以我在需求解析之后加一个硬校验如果要素清单里关键字段缺失就直接中断流程返回提示需求描述过于简略请补充输入项和业务规则。这个设计大大提高了最终用例的有效率减少了看起来完整、实际没法用的虚胖输出。这个流程的核心思想就是把一个大任务拆成多个小任务每个小任务由专门的节点负责节点之间有明确的输入输出契约。这也是智能体实战和调 Prompt最根本的区别。4. 实操过程从零到一搭出你的第一个测试用例生成智能体4.1 环境搭建与基础配置我以 Dify 为例带你从零走一遍。首先你需要一个能跑 Dify 的环境本地开发的话用 Docker Compose 最省事git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d启动完成后浏览器访问http://localhost/install完成初始化设置管理员账号。然后进到控制台创建一个工作流类型应用。这里有个关键选择你要选工作流还是聊天助手。测试用例生成这个场景必须选工作流。聊天助手虽然也能跑流程但它的设计目标是人多轮交互轮次管理会干扰用例生成任务的稳定性。工作流应用则是一个确定性的流程输入需求输出表格干净利落。模型供应商配置这里Dify 支持接入 OpenAI、Anthropic、Azure、以及国内各家模型平台的 API。你在设置 → 模型供应商里填好 API Key 就能用。我用的是通义千问的 qwen-plus 做解析qwen-turbo 做格式化输出成本能打下来一大截。4.2 搭建工作流一个节点一个节点配接下来按我之前说的流程结构逐个节点配置。第一个 LLM 节点需求解析模型选主模型提示词用前面给的那一版。注意在节点设置里把输入变量绑定到开始节点的sys.query变量上这样用户在对话窗口输入的内容就会自动传给这个节点。LLM 节点的输出变量也要提前定义我把需求解析的输出变量命名为elements类型选 JSON。系统会要求你提供一个 Schema 示例你给它一个成功解析后的例子就行模型会照着这个结构输出。第二个节点是代码节点用来做校验。这里选 Python 代码核心逻辑很简单def main(elements: str) - dict: import json try: data json.loads(elements) except Exception: return {passed: False, message: 要素解析失败请重新描述需求} if not data.get(inputs) or not data.get(rules): return {passed: False, message: 关键信息缺失请补充输入项和业务规则} return {passed: True, message: ok}代码节点的输入elements来自上游 LLM 节点的输出变量输出我们定义成check_result。这个节点本身不调用模型执行速度飞快但能拦截掉大部分无效输入。第三个 LLM 节点场景生成。这个节点的作用是让模型先把用例思路理清楚但它不需要直接输出最终用例。我给它设计的提示词核心是根据以下测试要素先生成测试场景清单。 场景要区分正常流程、异常流程、边界场景、状态流转场景。 输出为 JSON 数组每个元素包含场景描述和场景类型两个字段。为什么要把场景生成单独拆一个节点因为模型在想清楚有哪些场景和写出完整用例这两个任务之间频繁切换容易互相干扰。拆开以后第二步的格式化压力小很多输出的用例质量也更稳定。第四个 LLM 节点格式化输出用前面系统提示词里模板格式就行把场景清单和要素清单同时传入让模型按照标准用例格式输出 JSON 数组。模型可以选便宜的小模型因为它的任务非常机械——把场景描述翻译成规范用例结构。最后配结束节点输出变量绑定test_cases。你可以把输出形式设置为表格这样 Dify 会自动把 JSON 数组渲染成可读表格也可以选择文本输出原始 JSON方便做后续集成。我建议先选表格因为排查问题时直观。4.3 实测效果跑通一次完整的用例生成配置完成后我拿前面登录订单查询的需求做了一次实测。这里我把真实输出截取一部分展示一下效果[ { 用例编号: LOGIN_001, 模块: 登录, 前置条件: 系统已部署登录页可访问, 操作步骤: 1.打开登录页 2.输入正确账号 3.输入正确密码 4.点击登录, 输入数据: 账号zhangsan、密码abc123456, 预期结果: 登录成功跳转至订单查询页面, 优先级: P0 }, { 用例编号: LOGIN_006, 模块: 登录, 前置条件: 系统已部署登录页可访问, 操作步骤: 1.打开登录页 2.输入账号zs 3.输入密码 4.点击登录, 输入数据: 账号zs、密码abc123456, 预期结果: 提示账号或密码错误页面停留在登录页, 优先级: P1 }, { 用例编号: ORDER_003, 模块: 订单查询, 前置条件: 已登录系统存在已创建且状态为待支付的订单, 操作步骤: 1.进入订单查询页 2.选择筛选条件为待支付 3.点击查询, 输入数据: 订单状态待支付, 预期结果: 列表仅展示状态为待支付的订单信息, 优先级: P1 } ]整体生成下来 28 条用例正常流程、异常分支、边界情况都覆盖到了跟我手动设计的比对覆盖率在 90% 上下。日志记录显示整个流程耗时约 18 秒相比一个测试工程师吭哧吭哧写半小时效率提升肉眼可见。这里多说一句生成完了不等于直接能用测试人员还是要做一遍三查查需求覆盖是否完整、查预期结果是否符合产品定义、查优先级是否跟业务影响匹配。智能体是帮你把 70% 的重复劳动干掉剩下 30% 的专家判断该人工还是得人工。5. 常见问题与排查技巧实录下面这些问题是我在开发和试跑过程中真踩过的坑整理出来你可以直接当排查手册用。5.1 生成的用例覆盖严重不均怎么办这个问题的典型表现是登录功能的正常用例写了一大堆边界值和异常流程寥寥无几订单查询部分甚至只写了一两条。原因通常是模型顺着惯性走只产出了最容易想到的场景。排查思路分两步。先检查场景生成节点的输出是不是已经存在覆盖缺口——如果是说明这步就出问题了需要加强这个节点的提示词约束。我的做法是在提示词里加了一段强制要求在生成场景清单后自检一遍 - 等价类是否覆盖了有效和无效两种情况 - 边界值是否覆盖了上边界、下边界、临界值 - 是否有遗漏的状态迁移场景 - 是否有遗漏的异常输入场景如果场景生成没问题但最终用例还是缺那就检查格式化输出节点的模型是不是太小导致它在转换时丢信息。这种情况就换回大模型再试。5.2 输出格式飘忽表格结构对不齐大模型输出 Markdown 表格时偶尔会出现列数对不齐、表头变化、多了空行之类的问题。Dify 工作流如果定义的是文本类型输出这种情况特别常见。解决方案依然是强约束为 JSON 结构化输出。你在 LLM 节点的高级设置里打开JSON 模式系统会自动在请求里加入强制 Json 输出的参数这比你在提示词里求它一定输出 JSON有效得多。注意打开 JSON 模式后模型输出里就不会再有其他文本了正好是你要的效果。如果某次输出还是坏了不要急着重新生成整条流程。Dify 工作流运行时每一步都有日志你直接看是哪个节点返回了非法内容修正对应节点的提示词或者材料即可不要每次做无差别重跑。5.3 模型幻觉出需求里没有的业务规则这是我最头疼的一个问题。模型会在生成用例时自行脑补规则比如需求里没说验证码有效期它给你写了验证码5分钟过期——看着合理但实现里根本没有这个逻辑到时候测试照着执行就是假失败。解决办法是在需求解析节点的提示词里明确加一条禁止在用例中添加需求描述中不存在的业务规则。 如确需补充默认约束必须在预期结果中注明基于默认约束。另外在代码节点里我加入了一个关键字匹配检查。严格做的话可以建一个业务规则词表看模型输出中有没有出现需求中不曾提到的规则词。简单做法是抽几个高频场景人工抽检比如每轮生成后抽查 10%-20% 的用例看有没有额外加戏的内容。前期多抽查几轮之后后面就可以慢慢降低抽查比例了。5.4 处理速度慢能不能优化如果你发现整个流程跑下来要三四十秒甚至更久可以从这几个维度优化模型降级格式化输出节点换成轻量模型速度能快不少精简上下文场景生成节点传给格式化节点的输入只保留必要字段别把完整的需求描述一并传过去上下文越短生成越快并行改造如果你的用例需求覆盖多个独立模块登录和订单查询本来就是独立的可以把场景生成之后按功能点拆成多条并行分支Dify 支持分支节点并行执行单模块生成任务并行跑整体耗时几乎能腰斩6. 关于落地扩展最后说几句我的真实体会这个案例做到这里已经能覆盖从需求文本到规范测试用例的完整链路了。但我实际推广使用时发现大家很快就想让它干更多活——让它分析历史缺陷数据、让它接入接口文档自动生成接口测试用例、让它跟 CI 流程联动在每次代码合并后自动补用例。方向都对但我的建议是克制一点先把生成结果可被信任这件事做扎实再逐层叠加能力。有一个小技巧特别值得分享把每次执行成功的用例结果都沉淀下来。跑的次数多了之后你其实积累了一个宝贵的历史用例库这时候再上 RAG 就顺理成章了——把历史用例向量化新需求进来时先检索相似旧用例做参照模型生成的用例会更贴合你们团队的口味这就是越用越聪明的实际路径。最后再强调一遍最核心的个人体会智能体项目的成败八成不取决于模型选得多强、框架追得多新而是取决于流程编排和提示词设计。你先想清楚输入是什么、输出给谁用、中间要经过哪几步逻辑、每步的验收标准是什么再去碰代码和配置。流程清晰了Dify、Coze、LangChain 这些工具对你来说就只是不同施工方式罢了。这篇文章里的案例配置和提示词你完全可以照着搭一遍。跑通第一版之后再去根据你们团队的测试规范做迭代相信你很快就能感受到从需求到用例这条链路被大幅缩短的快感。