基于Dify工作流与知识库的AI测试用例生成流水线搭建实践

1. 为什么要搭这么一条流水线1.1 传统测试用例编写方式的痛点做了几年软件测试我最大的感受是写测试用例这件事本身重复性极高但脑力消耗一点也不低。你拿到一份需求文档无论是几十页的 PRD还是一个 ERP 系统的更新说明都要一步步拆功能点、理业务流程、列正常路径和异常路径、再考虑边界条件和权限场景。这个过程极其依赖个人经验新人写出来的用例往往是主流程能跑通的版本老手则会下意识补出各种犄角旮旯的异常场景。更麻烦的是需求文档永远不会是写完就定稿的。今天产品经理改个字段明天业务方提个新规则你之前写好的用例就得跟着改。如果靠手工维护一个中等规模项目的用例维护成本通常占整个测试周期的三成以上。我见过很多测试团队花了大把时间写用例结果需求一变用例文档就躺在那里没人更新最后沦为形式化产物。用 AI 生成测试用例其实不算新鲜事ChatGPT 刚出来的时候就有人拿需求让 GPT 直接写用例。但直接对话式生成有几个硬伤一是你能贴进去的上下文有限大模型记不住几十页的需求二是输出格式不稳定每次生成的用例结构都不一样无法直接对接到用例管理工具三是没有团队知识沉淀同一个业务领域的历史用例经验无法复用。这三个问题恰恰是 Dify 这类平台能解决的。1.2 为什么我选了 Dify 而不是纯代码或纯提示词最早我试过两种方案。第一种是直接用 ChatGPT / Claude 网页版把需求文档复制粘贴进去让它生成用例。这种方案只适合小需求文档一长就超出上下文窗口而且每次都要手工粘贴、手工整理本质上还是手工活。第二种是自己写 Python 脚本调用大模型 API配合 LangChain 之类的框架做文档切分、向量检索、提示词拼接。这个方案灵活但工程成本不低你需要自己处理文档解析、切片策略、向量库选型、检索逻辑、流控和重试还要写个前端页面给团队用。一个人维护这么一套系统说实话有点重。Dify 恰好卡在中间它是一款开源的 LLM 应用开发平台把大模型对话应用、工作流编排、知识库RAG这些能力都封装成可视化的积木。你要做的不是写代码而是拖节点、配置参数、写提示词。我最终选择 Dify 的核心原因有三个知识库能力内置需求文档上传后自动切分、向量化工作流里可以直接挂一个知识库检索节点相当于给大模型装上了可搜索的长期记忆解决长文档记不住的问题。工作流编排灵活可以定义清晰的流程——先解析需求、再检索补充上下文、再生成用例、最后格式化输出。每一步的输入输出都可以精确控制不像普通对话那样不可控。部署方便、可团队共享Dify 能通过 Docker Compose 一键部署在局域网服务器上团队里任何人都能打开网页使用也能暴露 API 给自动化测试平台调用。如果你只是自己偶尔生成一次用例纯提示词就够用了。但如果你想让这个流程成为团队的基础设施、被反复使用和迭代Dify 的性价比确实高。下面我把整个搭建过程完整梳理一遍。2. 流水线的整体设计思路2.1 核心流程需求进用例出这条流水线表面上只做一件事你粘贴一段需求描述或者上传一份需求文档点一下运行就得到一份结构化、可直接落地的测试用例。但自动化不等于把文档丢给大模型让它一次性输出。真正能稳定产出高质量用例的流水线内部必须分步骤。我最终设计的流程分为五个阶段需求输入支持两种方式。第一种是直接在输入框粘贴需求文本适合几十到几百行的中小型需求第二种是上传需求文档到知识库然后在输入框里指定“本次变更涉及的功能模块”平台会先从知识库里检索相关章节拼接成上下文。需求结构化解析大模型第一轮不直接写用例而是先把需求整理成结构化描述——涉及的功能点列表、业务规则、权限要求、数据约束、上下游依赖。这一步非常关键后续所有用例都基于这个结构生成。知识补充检索从 Dify 知识库中检索与该需求最相关的历史需求描述和历史用例片段作为生成用例的参考上下文。这一步是为了让新用例的风格、覆盖深度和团队既有积累一致。测试用例生成基于结构化需求 知识库补充上下文按功能点逐条生成测试用例包括用例编号、前置条件、操作步骤、预期结果、优先级、类型功能/边界/异常/权限。格式校验与输出大模型输出的结果通过一个代码节点做 JSON 解析和必填字段校验不合格的字段自动重试一次最终输出完整的 Markdown 表格方便直接复制到 Excel 或用例管理平台。2.2 工作流节点的选型和衔接Dify 工作流的每个节点都有明确职责。我用的核心节点不多但每个节点都做了参数调优开始节点定义两个输入变量。一个是requirement_text用来接收用户粘贴的需求原文另一个是module_name用来标识本次需求涉及的功能模块比如“登录”、“订单退款”这个变量会同时参与知识库检索和提示词拼接。知识检索节点使用 Dify 内置的知识检索能力。query 参数我设计成module_name 需求关键词的组合而不是把整段需求文本都作为检索条件。原因后面细说。LLM 节点一需求解析这个节点负责把原始需求转成结构化的功能点和规则清单。我给它设置了较长的 max_token并为它定义了严格的输出格式JSON 结构。LLM 节点二用例生成这个节点的输入是节点一的输出加上知识库检索结果。它要完成的工作量最大——在同一轮输出中为多个功能点生成用例。代码节点格式化Dify 的代码节点支持 Python。我在这个节点里对上游 LLM 节点的输出做json.loads、检查关键字段是否缺失、并转成最终 Markdown。如果解析失败会抛出一个自定义错误并配置重试机制。结束节点把格式化后的 Markdown 输出给用户。同时在输出变量里附带一个覆盖统计字段显示本次生成了多少条用例、涉及哪些功能点。这条链路的逻辑在于先让大模型读懂需求再基于读懂的内容生成用例而不是让大模型一次性边读边写。我实际对比过分步生成相对于一步到位的生成方式用例的遗漏率低了大概三成。3. 实操搭建从部署到跑通第一份用例3.1 Dify 部署与基础环境准备Dify 的部署方式非常成熟官方推荐 Docker Compose 一键部署。我的环境是一台 Ubuntu 22.04 服务器配置要求不高4 核 8GB 内存就能跑得很流畅。大模型推理如果走云端 API本地就不需要 GPU。部署过程不再赘述直接给几个关键建议版本选择Dify 的社区版迭代很快新版本可能引入工作流节点变更、数据库迁移等行为变化。我在生产环境固定使用 1.x 某个稳定版本没有频繁追新。如果你打算二开或深度定制一定盯住版本发布日志再决定要不要升级。模型配置在 Dify 的设置 → 模型供应商里配置你的模型 API Key。我主力使用 GPT-4o 系列效果最稳也测试过开源模型如 Qwen 系列通过 Ollama 接入能用但在长文本的结构化输出上明显不如 GPT-4o 稳定。关键参数建议Temperature 设置为 0.2 或更低。生成测试用例是确定性任务不需要模型发挥创意温度越低输出越稳定。Max Token 设置至少 4000。一份包含多条用例的 JSON 输出可能超过 2000 token设置太短会被截断。打开输出 JSON模式如果模型支持。部分 Dify 版本支持结构化输出格式约束能大幅降低非法 JSON 的概率。启动完成后用管理员账号登录 Dify 后台创建应用选择工作流类型Workflow就进入了搭建画布。3.2 知识库搭建把历史需求文档变成可检索记忆知识库是 RAG检索增强生成的基础。我建议不要一上来就把所有历史需求一股脑导入而是按业务模块分类建多个知识库登录认证库包含账号体系、SSO、权限控制等历史需求与用例。订单交易库下单、支付、退款、售后等流程文档。ERP 业务库采购、库存、财务对账等模块的需求和规则说明。每个知识库单独设置索引参数。对于需求文档而言我常用的分段设置是分段标识符\n\n按段落切分最大分段长度500 token分段重叠长度50 token这个配置能让切出来的文本块大小适中保留段落语义的同时又不至于太大导致检索精度下降。召回模式我选的是向量召回没有开全文混合检索因为纯需求文档的术语专有性强向量召回对语义相似匹配效果好。这里有个实践禁忌不要把测试用例本身也当成知识文档混在同一个知识库里除非你明确训练过模型去参考旧用例的风格。因为旧用例可能已经过时混入后会诱导大模型生成过时的步骤描述。3.3 工作流画布节点连接与参数传递细节Dify 工作流的搭建是拖拽式的。你从左侧节点面板拖入开始、“知识检索”、两个LLM、“代码”、“结束”节点然后用连线按顺序连起来。看起来简单真正需要花心思的是节点参数。开始节点的变量设置requirement_text类型为段落paragraph因为用户粘贴的需求可能很长。module_name类型为单行文本text-input用于指定功能模块。知识检索节点的配置关联知识库选择对应业务的库如登录认证库。检索 Query我在这里输入{{module_name}}拼上{{#sys.query#}}的部分需求关键词。实际操作中我没有把整段 requirement 作为查询条件——因为 Dify 知识检索默认会只用 query 向量化长文本会让向量检索的准确性下降。正确的做法是让用户自己定义一个短查询或者用 LLM 节点先从需求里提炼出 3-5 个关键词再交给知识检索节点。TopK我设置为 4。这个值不宜太大否则召回的内容太杂会稀释重点信息。LLM 节点一需求解析的配置模型选择 GPT-4o 或你配置好的模型。Temperature0.2。Max Token2000。系统提示词要求模型扮演资深测试架构师将用户输入的需求文本解析成功能点清单、“业务规则”、“数据约束”、“权限要求”四个结构化字段。用户提示词拼接{{#start#.requirement_text#}}。输出变量struct_requirement格式为 JSON。LLM 节点二用例生成的配置模型与参数同上。系统提示词要求模型基于结构化需求和参考知识生成完整测试用例。用户提示词把{{#llm_node_1.text#}}和{{#knowledge_retrieval.result#}}组装成输入。输出变量temp_cases格式为 JSON。代码节点的 Python 脚本这个节点做的事就是清洗——把大模型输出里的 JSON 取出来确保有cases键然后按模块名生成编号并把整个 JSON 整理成 Markdown 表格字符串。代码大概长这样import json def main(raw_text: str, module: str) - dict: # 提取JSON部分 start_idx raw_text.find([) end_idx raw_text.rfind(]) 1 if start_idx -1 or end_idx 0: raise ValueError(No JSON array found in LLM output) cases json.loads(raw_text[start_idx:end_idx]) # 规范字段并生成编号 normalized [] for i, item in enumerate(cases, 1): normalized.append({ case_id: f{module.upper()}_{i:03d}, case_title: str(item.get(title, )).strip() or f用例{i}, precondition: str(item.get(precondition, )).strip(), steps: str(item.get(steps, )).strip(), expected: str(item.get(expected, )).strip(), priority: str(item.get(priority, P2)).strip(), category: str(item.get(category, 功能)).strip(), }) # 生成Markdown表格 lines [| 用例编号 | 用例标题 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | 类型 |, | --- | --- | --- | --- | --- | --- | --- |] for c in normalized: lines.append(f| {c[case_id]} | {c[case_title]} | {c[precondition]} | {c[steps]} | {c[expected]} | {c[priority]} | {c[category]} |) return { markdown_table: \n.join(lines), case_count: len(normalized), module_name: module }这个节点在 Dify 里的输入变量名需要和脚本参数对应上。Dify 代码节点支持多输入你需要在界面上把上游 LLM 节点的输出文本映射到raw_text把开始节点的module_name映射到module。结束节点输出markdown_table、case_count、module_name三个变量。这样用户运行工作流后能在结果页直接看到测试用例表格也能拿到 JSON 格式进一步处理。3.4 第一次运行用一个实际需求验证全链路配置完成后我在运行调试框里输入了一段模拟的登录需求文本用户输入手机号和密码登录。手机号需要是 11 位密码需要 6-20 位包含字母和数字。如果连续输错 5 次密码账号锁定 30 分钟。支持手机号验证码登录验证码有效期 5 分钟。module_name 填login。第一次跑出来的结果整体完整但有几个问题暴露出来用例条数偏少只生成了 8 条缺少验证码重复使用、“密码包含特殊字符”、“账号锁定临界值第5次之前”这类边界场景。部分步骤描述过于笼统比如输入错误密码没有说明是输入正确格式但错误密码还是输入格式错误的密码。这些问题不是流水线本身不行而是提示词约束不够。我把 LLM 节点二的系统提示词改成了更强的约束版本并要求生成用例数量下限为 15 条且必须包含等价类、边界值、异常场景、权限场景四个维度。调整后测试同样的需求生成了 22 条用例结构明显完整了。4. 提示词细节与格式约束核心难点全在这里4.1 需求解析阶段的提示词设计如果说 Dify 工作流是这副骨架那么提示词就是血液。大部分人的AI 生成测试用例不好用问题根源都在提示词写得不够具体。需求解析节点LLM 节点一的作用是让大模型把散乱的业务描述转成结构化清单。我的系统提示词里要求模型输出一个 JSON 结构{ summary: 一句话需求概述, functional_points: [功能点1, 功能点2], business_rules: [规则1, 规则2], data_constraints: [数据约束1], permission_requirements: [权限说明], related_modules: [关联模块] }关键的设计是分类要足够细。业务规则和数据约束分开非常重要——测试用例的边界条件和业务规则往往都藏在数据约束里而业务规则则决定正常路径的状态流转和条件判断。如果合在一起模型容易漏掉边界值分析。4.2 用例生成阶段的提示词模板LLM 节点二的系统提示词是整个流水线的灵魂。我贴出我自己优化后的参考版本你可以按需修改你是一名资深测试架构师请基于【结构化需求】和【参考知识库】为指定功能模块编写完整的测试用例。 设计要求 1. 用例必须覆盖以下维度 - 正常流程happy path至少2条 - 边界值分析针对所有输入字段的长度、格式、取值范围设计 - 等价类划分有效等价类和无效等价类都要覆盖 - 异常场景网络中断、超时、重复提交、数据不存在、状态冲突 - 权限场景未登录、已登录但无权限、不同角色操作 2. 每条用例必须包含字段 json { title: 用例标题, precondition: 前置条件, steps: 操作步骤用号分隔, expected: 预期结果, priority: P0/P1/P2/P3, category: 功能/边界/异常/权限 }输出为 JSON 数组禁止输出任何解释文字。用例数量不得少于15条不多于40条。提示词里强调禁止输出任何解释文字非常关键。大模型经常会在 JSON 前后追加以下是用例之类的说明直接把代码节点的 JSON 解析搞崩。如果你发现输出总有杂质就在提示词里把这句话加上并在代码节点里做好从第一个 [ 到最后一个 ] 的截取逻辑双保险。 ### 4.3 格式约束让大模型输出规矩的 JSON 前面提到 Dify 部分版本对大模型输出有一定格式约束能力但我还是把重点放在代码节点兜底上。 代码节点里我先用 find([) 和 rfind(]) 找到 JSON 数组的起止位置再 json.loads 解析。这一步能过滤掉绝大多数前缀后缀污染。 另一个兜底策略是给结束节点同时输出原始文本和格式化后的表格两个字段。如果代码节点解析失败用户依然能看到 LLM 节点二输出的原文不会因为格式化失败就完全拿不到结果。在 Dify 工作流里可以用分支节点实现代码节点成功走正常输出失败则走另一个分支直接输出原文。不过多数情况下结合提示词约束 截取逻辑已经足够。 ### 4.4 模型选择对输出的影响 我用本地开源模型和 GPT-4o 做了一组对比同样是 500 字的需求文本本地 7B 模型输出 JSON 结构的合法率大概在 60% 左右GPT-4o 能达到接近 100%。这意味着如果你用本地开源模型代码节点的容错逻辑必须写得更健壮甚至要考虑解析失败后自动降级为文本输出。 如果你的运行环境不允许调用外部 API必须用本地模型我建议选择至少 14B 以上的模型并开启模型本身的 JSON 输出模式例如 Qwen 系列的 ResponseFormat.JSON。Dify 接入 Ollama 模型时可以在模型配置里找到相关设置项。 ## 5. 跑通之后优化效果与几个高频问题排查 ### 5.1 知识库检索不准怎么办 知识检索节点经常被忽略但它直接影响用例质量。如果你发现生成的用例和领域规则不匹配比如登录模块的用例中出现了数据库字段名错误多半是知识检索召回的内容不准。 我的排查经验是 1. 打开 Dify 的标注功能查看检索结果确认检回的内容是否与 query 语义关联。 2. 如果召回内容不相关尝试把检索 query 从整段需求改成一个短句比如 module_name 关键规则。 3. 调整知识库的分段长度。太长的段落在向量化后信息分散太短的段落会丢失上下文。需求文档用 500 token 分段比较合适。 4. 开启 TopK 后配合重排序RerankDify 有内置的 rerank 节点或者接入 Cohere Rerank。重排序能显著提升召回精度代价是增加一点延迟。 ### 5.2 生成结果格式经常变怎么办 这是使用 Dify 工作流跑 LLM 最常见的坑即使提示词明确要求 JSON模型偶尔还是会在 JSON 前面加一句好的以下是...或者把数组包在对象里。 我的处理经验 - 提示词里加禁止解释只输出JSON数组。 - 代码节点里做健壮的截取和解析找 [ 和 ]并在 json.loads 失败时尝试去掉控制字符。 - 优先选择对结构化输出支持好的模型比如 GPT-4o、Claude或者开启模型的 JSON mode。 - 在 Dify 节点设置里把重试次数配置为 2 次模型输出异常时自动重新调用。 ### 5.3 长需求文档超出上下文怎么办 如果用户粘贴的需求文本有几千字LLM 节点二的输入会超过模型的上下文窗口或者因为 token 过高导致费用飙升。我的解决方案是 - 在开始节点不做任何处理直接把长文本交给需求解析节点。 - 需求解析节点把长文本压缩成结构化的 JSON 摘要这一步 token 消耗大但两三千字的需求摘要后只有几百 token。 - 用例生成节点只拿摘要 知识库检索结果作为输入整体 token 大幅下降。 这样设计后一份 3000 字的需求文档跑完整条流水线的消耗可以从 6000 token 降到 2000 token 左右成本节省三分之二输出质量反而更稳定因为模型没被无关信息干扰。 ### 5.4 Dify 工作流调试的通用技巧 Dify 工作流调试时有个非常好用的功能每个节点运行后都可以查看该节点的完整输入输出。我建议每次跑完一条完整链路先点开 LLM 节点二看模型真实的输出内容——很多问题都出在提示词和实际输入内容的匹配上而不是模型能力不行。 还有就是善用变量引用。Dify 里 LLM 节点输入框的变量插值语法是 {{#node_id.output#}}。如果你在提示词里写错了变量名比如把 #node_1.text# 写成了 #node1.text#工作流不会报错但模型会看到一段原始变量名输出自然是乱的。遇到生成质量莫名变差先检查变量引用是否准确。 ## 6. 后续可以扩展的方向 现在这条流水线在我的日常工作中已经稳定跑了大半年除了登录、订单这类通用模块我还为 ERP 系统的采购入库、库存盘点、对账流程建了独立知识库每次产品经理发来更新文档我直接把更新部分粘贴到流水线里跑完就能生成一份覆盖新需求和老规则回归的用例初稿。一般来说初稿的可用程度在 70% 到 80%剩下二成场景尤其是涉及多系统联调和历史数据兼容的部分需要人工补充。 如果你也想搭一条类似的流水线我的建议是不要一上来就追求全自动化。先把手头最痛苦、最重复的一个模块比如登录注册跑通体验一下从需求到用例的全流程再慢慢积累知识库素材和提示词模板。测试用例生成这件事终极目标不是替代测试工程师而是把那些机械劳动压缩到最短让你把精力花在真正需要判断力的地方——探索性测试和业务风险分析上。 根据我个人经验这类 AI 辅助测试基建最值得投入的下一步是把生成的用例通过 Dify 的 API 自动推送到 TestRail 或禅道这类用例管理平台再把执行结果抓回来回流到知识库。当用例知识形成闭环后你会发现流水线的价值不再是省时间而是团队经验本身在持续复用和增值。