1. 为什么我不建议直接用ChatGPT“复制粘贴”生成测试用例
先说说我为什么会绕这么大一圈，最终落到Dify上。
做测试的人应该都有这种体验：需求评审完，PRD一大堆，排期一看，留给写用例的时间就两天。用ChatGPT直接生吧，你得反复复制粘贴需求原文，把几十页的PRD拆成十几段扔进对话框，还得小心上下文长度超限；生成的结果要么太泛，全是“输入合法数据验证功能正常”这种废话，要么压根没读进去你的需求，把业务规则理解错了。最要命的是，同样的需求，今天生成和明天生成，格式结构完全对不上，你根本没法把它当成工程资产来沉淀。
后来我想明白一个问题：测试用例生成这件事，最大的瓶颈不在模型能力，而在“怎么把需求稳定地、结构化地喂给模型，再让模型稳定地、格式化地输出结果”。这就是编排平台该干的活。Dify正好是干这个的。
Dify是一个开源的大模型应用开发平台，你可以把它理解成一个积木拼装台：把模型、提示词、知识库、工作流这些模块像拼积木一样拼在一起，拼出一个“上传需求稿就自动出测试用例”的应用。它的价值不在于帮你少打几个字，而在于把“需求→用例”这个过程变成一条可复用、可维护、可迭代的流水线。
这篇文章我会从部署、工作流搭建、知识库设计、模板调试到实测效果，完整走一遍我的做法。适合谁看？自己做测试平台建设、想引入AI辅助的测试开发，以及被重复用例编写搞到头秃的功能测试同学。你要是对Dify完全小白也没关系，每一步我都会讲到为什么这么搭。
2. 本地部署Dify：版本选择与镜像拉取的那些坑
Dify的部署方式分几种：SaaS云服务、Docker Compose本地部署、源代码运行。做测试资产这种敏感数据，我肯定不会往云上扔，老老实实本地部署。
2.1 部署方式选型和环境准备
我选的是Docker Compose方式，这是官方主推、也是社区里资料最全的方式。总共需要的组件包括：API后端、Worker、Web前端、PostgreSQL、Redis、Weaviate（或Qdrant）向量数据库、Sandbox（代码执行沙箱）、SSRF代理等。听起来很多，但Dify官方给了一套编排好的docker-compose.yaml，你不用一个个去理解，跑起来就行。
环境方面，我用的是一台Linux服务器，8核16G内存。这个配置跑Dify社区版带知识库功能，实测下来够用。你要是想在Windows本地跑，装个Docker Desktop也行，但注意文件路径和内存分配，下文会讲。
安装过程本身不复杂，核心几步：
# 克隆代码仓库 git clone https://github.com/langgenius/dify.git # 进入docker目录 cd dify/docker # 复制环境变量配置 cp .env.example .env # 启动 docker compose up -d就这几条命令，服务就起来了。浏览器访问http://服务器IP/install，设置管理员账号，完事。
2.2 镜像拉取失败：一个高频报错的完整排查过程
第一次部署时，我在docker compose up -d这一步卡了两个小时。现象是启动到一半，镜像拉取失败，报错信息类似failed to pull image ... EOF或者dial tcp: lookup ... no such host。
这里很多人第一反应是“网络不行”，就开始反复重试。我一开始也这样，重试了四五次，偶尔能拉下来一两个镜像，但大镜像还是失败。后来我换了思路：先把所有需要的基础镜像单独拉下来，再执行compose。
# 先看compose文件里定义了哪些服务 docker compose config --services # 逐个拉取，失败的重试 docker pull langgenius/dify-api:1.17.1 docker pull langgenius/dify-web:1.17.1 docker pull postgres:15-alpine docker pull redis:6-alpine docker pull ubuntu/squid:latest # ... 其他依赖镜像类似把镜像一个个拉到本地后，再执行docker compose up -d，秒启动。这个思路的本质是：Compose批量拉取时并发高，单个镜像下载失败会导致整批回滚；手动逐个拉取能定位问题，也能利用重试机制逐个击破。
2.3 版本选择：1.17.1带来了什么
热搜词里很多人关注Dify 1.17.1这个版本。我部署时用的正是这个版本，几个值得关注的点：
一是多租户能力在社区版落地。以前社区版基本是单租户，1.17.1之后租户隔离和成员管理更加可用。对于测试团队要建“用例生成平台”的场景，这意味着不同项目组可以共用一套系统但数据隔离，实用性大增。
二是工作流节点的调试体验改进。这是我最关心的。Dify工作流里每个节点都可以单独输入测试数据跑一遍，看这个节点的输出长什么样。1.17.1之前这个调试过程偶尔有变量不同步的bug，新版顺滑很多。
三是知识库相关的检索参数有了更多可调项。这在后面讲知识库设计时会有具体体现。
提示：部署版本别盲目追新，也别用太老的版本。1.17.x目前社区反馈稳定，知识库和工作流这两个核心功能没有明显的坑，属于可以放心用的区间。
2.4 Windows本地部署的注意事项
如果你没有Linux服务器，Windows+Docker Desktop也能跑。但有几个坑我帮你先踩了：
第一，Docker Desktop必须配置WSL 2后端，老旧的Hyper-V方案在跑多容器时经常出网络问题。第二，内存至少给Docker分配6GB以上，否则Dify跑起来后经常是某个容器莫名其妙被OOM杀掉。第三，路径不要带中文和空格，我见过同事在D:\软件\测试平台\dify这种路径下部署，容器启动后各种诡异问题，换到纯英文路径就好了。
3. 搭一个“需求稿→测试用例”工作流：四个核心节点怎么设计
部署完只是第一步。真正核心的活，是在Dify里把“需求文档变成测试用例”这条工作流搭出来。
3.1 工作流的整体架构：文件上传到结果导出
我先说整体设计，再逐个节点拆解。
整条工作流包含四个核心节点：
- 文件上传与解析节点：接收用户上传的需求文档（Word、Markdown、PDF）
- 需求结构化提炼节点：从文档中提取业务规则、功能点、约束条件
- 测试用例生成节点：基于结构化需求，按规则生成用例
- 结果格式化输出节点：把用例整理成表格或JSON，供下载
用Dify的术语说，前面两个是LLM节点，中间需要一个代码节点或工具节点做数据转换，最后是一个模板节点输出报告。
3.2 难点拆解：文档内容太长，模型“读不进去”怎么办
这是整条工作流里最大的坑，我必须单独拿出来说。
Dify本身支持上传文件，文件会被“放进变量”里传给后续节点。但直接把这个变量丢给LLM节点让它生成用例，效果非常差。原因有两个：
一是上下文长度限制。一份正经的PRD动辄两三万字，就算模型支持128K上下文，你把全文塞进去，模型对“重点业务规则”的注意力会被大量说明性文字稀释，生成出来的用例反而更差。
二是费用和延迟。每轮对话都把全文塞给模型，token消耗巨大，响应时间肉眼可见地变慢。团队里几个人同时用，API账单蹭蹭往上涨。
我的解决思路是“先提炼、后生成”：先用一个LLM节点把需求文档压缩成结构化的“需求规格摘要”，包括功能清单、业务规则、异常场景、输入输出约束等；再把这份摘要作为生成用例节点的输入。
这一步的提示词模板，我调试了很多版本，稳定可用的长这样：
你是资深测试分析师。请从以下需求文档中提取测试所需的关键信息，按固定格式输出： ## 功能模块 列出文档涉及的所有功能模块，每个模块一句话描述。 ## 业务规则 列出所有明确的业务规则，每条规则用"当...时，系统应该..."的描述方式。特别注意金额计算、状态流转、权限判断、时间边界。 ## 输入输出约束 列出所有输入字段的格式要求、取值范围、必填性、边界限制。输出内容的结构化要求。 ## 异常场景 列出文档中明确提到的错误处理、异常分支、边界情况。 ## 数据依赖 列出功能运行需要的前置条件、外部数据、接口依赖。 要求：只提取文档中明确存在的信息，不要臆测补充。使用中文输出，保持条例清晰。 需求文档内容如下： {{文档内容变量}}这个模板的关键在于“只提取文档中明确存在的信息，不要臆测补充”这句话。没有这句的时候，模型经常自作主张补一堆不存在的规则，生成的用例看着挺全，实际对不上需求。加上之后，输出老实了很多。
3.3 用例生成节点：规则和模板的平衡
得到需求摘要后，第二个LLM节点负责生成用例。这里的提示词设计比第一个节点更讲究，因为它直接决定输出质量。
我踩过的坑是：一开始我把规则定得太死，要求“每个模块必须覆盖正向、反向、边界场景”，结果模型为了凑数，生成了一堆牵强的用例——比如一个“用户点击按钮”的需求，它硬是编出“用户连续点击100次”这种没有依据的边界用例。后来我把规则改成两条：
你是资深测试工程师。基于以下需求摘要设计功能测试用例。 用例设计原则： 1. 所有用例必须有明确的需求依据，在用例中标注覆盖的需求条款编号。 2. 优先覆盖：正常主流程、关键业务规则、明确列出的异常处理。 3. 对边界情况，只在需求文档明确给出边界值时设计边界用例，不要臆测。 4. 每个用例包含：用例编号、所属模块、前置条件、测试步骤、预期结果、优先级、需求依据。 需求摘要如下： {{需求摘要变量}}加了“需求依据”这一列，是我做的最值钱的一个决定。之前生成的用例没法追溯，出了问题你不知道它是根据哪条需求来的；加了之后，评审时你可以逐条核对，漏测的、臆测的，一眼就能看出来。
3.4 变量引用与数据流转：新人最容易翻车的地方
Dify工作流里，每个节点的输出都挂在节点名.输出变量名上。新手经常犯的错是：在提示词里写{{需求摘要}}，但变量名实际是LLM节点1.text，导致引用空值。
我的习惯是每搭好一个节点，先单独“运行调试”一次，在右侧调试面板里看它的输出结构，确认变量路径后再去写下游节点的引用。宁可多花两分钟看变量，也不要写完一整条工作流后一次性调试，到时候报错你都分不清是哪个环节的问题。
提示：Dify工作流里的代码节点和模板节点都可以“添加变量”，这里的变量名是自己定义的，跟上游节点的输出要通过“引用上游变量”的方式连接，别手动打变量名，拖拽引用最稳。
4. 知识库：让生成结果从“能看”到“精准”的关键一跃
如果你只是把需求文档上传、解析、生成用例，那Dify和ChatGPT比没有什么本质优势。真正拉开差距的，是知识库。
4.1 为什么需要知识库：把“一次性问答”变成“带规范的生成”
直接用单条对话生成用例，模型的唯一依据是你上传的那份需求文档。但实际测试工作中，除了PRD，你还有一堆隐性依据：
- 团队的用例编写规范（用例编号规则、优先级定义、描述格式）
- 公司常见的业务字典（比如订单状态枚举、金额精度要求）
- 历史项目中总结的典型缺陷模式（比如忘记做并发控制、时间边界少算一天）
- 接口文档片段、字段字典
这些东西你不会每次写用例时都写进提示词里，但它们确实影响着“好用例”和“烂用例”的差别。把团队规范文档、接口字段字典、历史缺陷样例传进Dify知识库，生成用例时让模型去检索相关知识，效果是从“根据单个PRD硬写”升级为“在团队规范的框架下生成用例”。
4.2 知识库结构设计：不是全塞进去就完事
知识库不是建一个、把所有文档扔进去就完事。我建了三个独立的知识库：
| 知识库名称 | 存放内容 | 用途 |
|---|---|---|
| 用例编写规范库 | 团队测试用例模板、编号规则、优先级定义、通用步骤写法 | 保证生成的用例格式和团队现有用例资产一致 |
| 业务字典库 | 订单状态机、支付渠道枚举、接口字段字典、常用数据字典 | 让用例里的测试数据符合真实业务 |
| 历史缺陷模式库 | 从缺陷管理系统中导出的典型缺陷描述及根因分析 | 提示模型在相关功能点补充分支场景 |
重点说下第三个库。这个库的素材来源是缺陷系统里那些出现频次高、二次回归成本高的缺陷。我把每个缺陷整理成“缺陷描述+根因+对应功能点”的格式，做成文档导入知识库。这样生成一个新功能的用例时，模型检索到类似功能的缺陷记录，就有较大可能自动补上“数据并发导致重复提交”这类测试场景。
4.3 知识库调参与检索命中率优化
知识库不是传完文档就自动生效的，检索参数直接影响生成质量。
Dify知识库里有几个关键参数：分段长度、检索模式、TopK召回数、相似度阈值、Rerank模型。
我实测下来的稳定配置：
- 分段长度：500个token，重叠50。太短导致语义断裂，太长导致检索粒度过粗。
- 检索模式：用向量检索+全文检索混合模式。纯向量检索对专业术语不敏感，全文检索能弥补这一点。
- TopK：4左右。太少召不回相关内容，太多会把无关内容也塞进来干扰生成。
- 相似度阈值：0.5左右。低于这个值的结果基本是噪音，建议直接丢弃。
- Rerank：有条件就开。Dify支持配置Rerank模型，它相当于在初步检索结果里再精排一遍，明显提升命中质量。
4.4 飞书云文档作为知识库数据源的接入
搜索热词里有人在问飞书云文档的授权凭证怎么获取，我顺带说下。
Dify的知识库创建时，数据源可以选择“同步飞书云文档”，这需要配置飞书应用的App ID和App Secret。步骤是：在飞书开放平台创建一个企业自建应用，在“权限管理”里开通docx:document（云文档读取）和drive:drive（云空间文件读取）这两个权限，然后发布应用，拿到凭证填到Dify里。
这里有个坑：飞书应用权限发布后生效有延迟，有时候要等几分钟，你填完凭证后同步文档报“无权限”，不一定是代码问题，单纯是权限还没生效。等两分钟再试一次就行。
5. 实测过程：从一份真实PRD到可用用例的全流程复盘
理论讲完，放一次真实的生成过程，让各位看看实际产出长什么样，以及有哪些东西需要人工兜底。
5.1 测试素材：一个带“典型隐坑”的CRM需求片段
我拿了一份CRM系统的需求文档做测试，里面有一个典型功能：“销售提交订单时，系统自动校验客户信用额度，若超额度则提示销售确认”。这个需求在文档里的描述就两句话，但实际测试时涉及大量分支：额度恰好等于订单金额、额度为0、VIP客户是否走特殊额度通道、超额度后销售强行确认的二次校验等。
我把这段需求单独截取出来，上传到Dify工作流里跑了一遍。文件格式是Markdown，约3000字，包含需求背景、术语定义、功能操作流程等。
5.2 生成结果与质量评估：哪些能用，哪些不能用
生成了12条用例，我逐条做了评估：
能直接用的（7条）：正常提交订单流程、未登录拦截、必填项校验、库存不足提示、关闭弹窗不提交等。这些用例步骤清晰，预期结果描述准确，格式也符合我们团队的模板。
需要少量修改的（3条）：信用额度校验那条用例，模型写的是“当订单金额>信用额度时弹出提示”，但它没有区分“恰好等于”和“大于”，也没覆盖“VIP客户特殊通道”——这两个点需求文档里确实没有明确写，所以我不怪模型，这是需求本身有歧义。我把这两条分支手工补上。
质量不行的（2条）：一条是模型臆造了一个“系统自动发送邮件通知销售主管”的步骤，需求文档里根本没这回事；另一条是前置条件写得太笼统，“用户已登录且具有销售权限”，没有写如何准备这个权限数据。
整体算下来，直接可用率不到60%，但胜在产出速度快——整个过程从上传文档到拿到12条用例草稿，不到3分钟。我花10分钟改一改、补一补，就能进评审了。以前同样的工作，光从空白开始写就要一小时起步。
5.3 一个被低估的应用：从“生成用例”到“评审用例”
这个工作流上线后，我发现的意外收获是：它最大的价值不是“帮你写用例”，而是帮你提前把需求文档读懂。
为什么这么说？因为模型生成用例时，你可以反向检查它遗漏了什么。如果某一条明确的业务规则，模型没有生成对应的用例，那往往不是模型笨，而是需求文档里这条规则写得不够明确——你自己读的时候也会漏掉。把“模型漏掉的规则”和“你读到的规则”对一遍，相当于做了一轮轻量级需求评审。这个价值，比我预想的10分钟换个用例草稿要大得多。
5.4 结构化输出：把用例接到自动化测试的流水线上
最后一个节点，我做的是把用例以Markdown表格和JSON两种格式输出。Dify的代码节点支持Python，我用一小段脚本把用例格式统一成标准JSON结构，方便下游解析：
import json # 假设上游节点的变量为 test_cases，是一个包含用例列表的字符串 # 这里对用例做结构化处理 cases = test_cases["raw_text"].strip().split("\n---\n") result = [] for i, case in enumerate(cases, 1): result.append({ "case_id": f"TC_{i:03d}", "title": extract_title(case), # 自定义解析函数 "precondition": extract_precondition(case), "steps": extract_steps(case), "expected": extract_expected(case), "priority": extract_priority(case), "source_requirement": extract_source(case) }) return {"json_output": json.dumps(result, ensure_ascii=False, indent=2)}这个JSON可以直接对接自动化测试平台，或者导入到测试管理工具里，不用手工复制粘贴。对于已经在做测试平台建设、想把“AI生成用例”和“自动化执行”打通的同学，这一步是必须的。
6. 典型问题排查手册：我遇到的报错和对应解法
最后把我在Dify上搭建这套东西时遇到的高频问题列个表，方便你照着排查。
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 上传文档后LLM节点报“内容为空” | 文件解析节点没有正确提取文档文字 | 检查文档格式，PDF需要OCR功能且扫描版PDF无法直接提取文字；优先用Markdown或Word源文件 |
| 生成用例全是模板化的空话 | 需求摘要节点没提炼出业务规则，LLM只能发挥 | 检查第一个LLM节点的提示词，确认业务规则提取是否严格限制“只提取文档中明确信息” |
| 知识库检索后模型还在“自由发挥” | 知识库的TopK太低没召回到，或Rerank未开启 | 调高TopK到4~6，开启Rerank，并降低相似度阈值到0.5左右 |
| 模型编造需求中不存在的功能 | 需求摘要节点没有约束“不臆测” | 在提炼节点的提示词中加强约束，并增加“未提及的信息标记为未知”的要求 |
| Docker镜像拉取失败 | 批量拉取并发导致部分镜像失败 | 手动逐个docker pull，拉完再docker compose up -d |
| 容器启动后端口无法访问 | 服务器防火墙未放行 | 检查443和80端口入站规则，Dify默认走80/443端口 |
| 知识库同步飞书文档报无权限 | 飞书应用权限发布后生效延迟 | 等待2~3分钟后再试，同时确认权限范围是“企业自建应用”而非“商店应用” |
这些问题里，最花时间的是第一个。PDF格式的需求文档，如果是从网页导出的，很多是图片型PDF，Dify自带的文本提取器读不出来，LLM节点自然拿不到内容。我的建议是：生产环境下，让业务方提供Markdown或Word格式的需求文档，谁给PDF谁自己转换。这条规定直接写在我们内部的AI测试平台使用指南里。
另外，镜像拉取失败这个问题，如果你用的是Windows Docker Desktop，还可能是磁盘空间不足。Dify全家桶镜像加起来大概需要10~15G磁盘空间，先docker system df看下占用，空间不足也会报类似拉取失败的错。
7. 工作流上线后的三点经验
这段不写技术，写点运营层面的体会。
第一，别追求100%全自动。一开始我也幻想做一套“输入PRD直接生成可执行测试用例”的全自动流水线，后来发现不现实。现在的定位是“AI生成草稿+人工评审补充”，效率提升是实打实的，但质量兜底还得靠人。如果你在做方案汇报，别把预期拉太高，否则上线后落差会很难受。
第二，模板的迭代比模型的迭代重要。同样一个模型，在我把生成节点的提示词迭代了六个版本之后，用例的可用率从40%提到了60%左右。模型能不能选更强的是另一回事，但提示词模板的优化，是你完全可控且性价比最高的提升路径。
第三，知识库的维护要有专人负责。知识库不是建完就完了，历史缺陷要定期导、业务字典要跟着版本更新。我见过太多团队建完知识库丢那里不管，三个月后文档全过期了，模型生成的内容还不如不用知识库。这块最好定一个更新频率，我目前是每月初集中更新一次。
我的实际使用感受是：Dify最让我省心的不是它有多智能，而是它把“把过程变成资产”这件事做得足够顺滑。曾经在ChatGPT里东一段西一段的对话，现在变成了一条团队里每个人都能点开、调试、改进的工作流。这份沉淀下来的东西，比省下的那几个小时值钱得多。
函数解析与‘无效会话ID’排查)
