每次版本迭代的需求评审会开完QA 团队最头疼的不是需求对不齐而是把十几页、几十页的需求文档变成几百条覆盖正常流、异常流、边界值的测试用例。这个环节工作量大、重复度高又特别依赖测试人员的细致程度——漏掉一个边界条件轻则返工重则事故上线。我一直在琢磨能不能用 Dify 这样的 AI 应用平台把“需求文档 → 测试用例”这条重复度极高的链路做成自动流水线。我最后的落地方案是用 Dify 社区版搭建一条工作流丢进去一份需求文档几分钟后拿到一套带功能点、带业务知识上下文、按测试设计方法论组织的测试用例初稿测试人员在这个基础上做评审和补充。这篇文章我会从方案选型、流水线设计、Dify 实操、提示词模板、知识库搭建到效果评估完整讲一遍给同样被用例设计压得喘不过气的测试和测试开发同学一条可以直接抄作业的路径。里面有些结论是踩坑踩出来的我会尽量把“为什么这么做”也讲清楚。1. 为什么“需求文档 → 测试用例”适合做成自动流水线1.1 需求文档里的测试点到底藏在哪很多人一开始觉得自动化生成测试用例就是把文档丢给大模型让它“读一遍然后写”。实际做起来你会发现难点不在“读”而在“找测试点”。需求文档本质上是自然语言它会把功能、规则、限制、例外描述在句子里。比如“用户可修改个人信息”这句话看起来只有一个功能点但展开后涉及哪些字段可以改、手机号是否需要重新验证、修改后数据是否即时生效、有没有频率限制、操作日志要不要记录。这些信息文档里不一定写全LLM 如果只看这句话生成的用例大概率是“点编辑按钮、改字段、保存、断言成功”套话。所以流水线不能只做“文档 → 用例”一步到位中间必须加一个“功能点拆解”环节。这一步让 LLM 把需求文本拆成一个个可以独立测试的功能点每个功能点再单独出用例。这样一方面控制单次生成的长度另一方面也方便人工在功能点列表上做审核而不是在一大坨用例里找遗漏。1.2 测试设计方法论LLM 天然适合干这活测试用例设计本身有一套成熟方法论等价类划分、边界值分析、场景法、错误推测法。这套方法论是写在几乎所有测试教材里的大模型在训练阶段早就吸收了而且吸收的样本量比任何一个测试工程师这辈子看过的用例都多。所以理论上 LLM 是“懂测试”的问题只在于怎么让它把方法论实际用出来。我的经验是直接在提示词里把方法论写死强制它按这些方法展开。比如等价类必须区分有效和无效输入边界值必须覆盖上边界和下边界场景法必须包含主成功场景、备选场景和异常场景错误推测必须补充重复提交、并发、权限不足这类常见坑。只要提示词里写清楚了LLM 输出的用例质量会明显上一个台阶。这一点也是流水线可行的核心理论基础——它生成的不只是“像用例”的文本而是真的按测试设计规则生成的用例集。1.3 方案选型为什么是 Dify 而不是 LangChain我在动手之前对比过三条路自研 Python 脚本 LangChain直接用 ChatGPT 网页版以及用 Dify 编排。自研脚本的优点是灵活缺点是开发和维护成本高每次调提示词都要改代码发版本团队里其他 QA 同学上手门槛也高。直接开一个 ChatGPT 网页版很省事但一次性贴长文档容易超出上下文限制而且每次对话都是独立会话没法沉淀出团队统一可复用的流程。Dify 的定位恰好卡在中间。它有可视化工作流编排、知识库管理、模型接入统一配置QA 自己就能调流程不用等研发。社区版可以本地部署需求文档本身属于敏感业务资料能放在内网处理这一点对很多团队来说是硬需求。下表是我当时做的对比对比维度自研脚本直接用大模型网页版Dify 社区版开发成本高需要研发配合零开发低可视化编排团队复用需要额外做系统无法统一沉淀应用可共享知识库接入自己实现基本没有内置数据安全看部署数据出网可本地部署提示词迭代改代码发版手动复制界面调整即生效最终我选了 Dify而且这个选择在后面的使用中证明是对的。它让我把精力放在“怎么设计好流程”和“怎么调好提示词”上而不是“怎么写好一个框架”。2. 流水线整体设计七个环节把文档变成用例2.1 流程总览文档进来用例出去流水线的目标很明确输入是需求文档文件输出是一份按功能点组织的 Markdown 用例集。整个链路我拆成了七个环节上传需求文档到工作流开始节点文档提取器把 Word/PDF/Markdown 解析成纯文本LLM 节点把文本拆解成功能点列表JSON 数组迭代器逐个遍历功能点对每个功能点用知识检索节点从知识库召回业务规则和历史用例将“功能点 知识库上下文”一起送入 LLM 生成用例变量聚合器汇总所有功能点的用例结果结束节点输出这七个环节在 Dify 里对应一组工作流节点后面实操部分我会逐个讲配置。整体设计上有几个刻意为之的点第一拆功能点用独立节点不跟用例生成混在一起。这样你在调试的时候能单独看“拆得准不准”而不是等整个流程跑完才发现问题。第二知识检索放在功能点级别而不是文档级别因为一个文档往往包含多个模块整体检索容易把不相关的内容带进来单个功能点检索才精准。第三用迭代器做串行处理虽然速度慢一点但稳定性好不会因为一次输入太长导致模型超时。2.2 输入规范化先治文档格式不统一需求文档的格式是个容易被低估的坑。团队里有人用 Word有人用 PDF还有人直接把飞书文档导出成 HTML。Dify 的文档提取器能处理常见的纯文本、Markdown、PDF 和 Word但不同格式解析出来的质量差别很大。我的建议是在流程之外先定一个规范产研团队提需求时优先用 Markdown 或至少是普通 Word 文档。如果是 PDF尽量导出为可复制文本的版本扫描件那种纯图片 PDF 需要先过 OCR这属于另一个领域不建议塞进流水线里硬扛。另一点需要注意的是表格。需求文档中的字段说明、状态流转规则常常是表格形式PDF 解析容易把表格拍平成杂乱的文本这时候宁可让作者提供源文件也别指望模型能从乱序文本里脑补出完整表格。如果你手头已经有大量历史 Word 文档要做验证可以在 Dify 之前加一步批量转换用 Pandoc 把 docx 转成 Markdown再作为知识库或者输入文档处理。这一步从源头上保证了解析质量流水线跑起来会顺很多。2.3 节点选型Dify 工作流的核心积木Dify 工作流里真正用到的核心节点就那么几类我把它们的作用和选用理由梳理如下文档提取器把上传的文件变成文本这是所有后续处理的前提。Dify 的文档提取器节点输入是文件变量输出是文本支持 txt、md、pdf 等。LLM 节点干所有“动脑”的活功能点拆解和用例生成都靠它。这里的关键是给不同任务配置不同的提示词和模型参数。知识检索节点从知识库召回相关内容输出是文本片段列表。它是让流水线“懂业务”的核心环节。迭代器节点对于功能点列表这种数组结构迭代器可以逐个元素处理。每个功能点单独走“检索生成”的分支最后统一汇总。变量聚合器把迭代器产生的多个用例结果收集成一个大文本避免结果被覆盖。条件分支节点按需用比如识别到文档类型是“接口需求”就走接口用例生成分支是“功能需求”就走功能用例生成分支。我的配置经验是功能点拆解节点用条件分支做一次质量校验如果拆出来的功能点数量为 0 或者格式不对直接走错误分支返回提示而不是带病继续跑。这能让整条流水线具备基本的容错能力。3. 实操在 Dify 里一步步搭出自动化流水线3.1 部署准备Dify 社区版与模型接入Dify 社区版支持 Docker Compose 一键部署环境要求 Docker Engine 20.10 和 Docker Compose v2。官方推荐的服务器配置是 2C8G 起步实际跑需求文档拆解和用例生成这类任务建议 4C16G不然多任务并行时容易卡顿。部署命令很标准git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d启动完成后访问服务器地址进入初始化页面设置管理员账号。模型接入这一步我建议你在设置 → 模型供应商里同时配置至少两个供应商一个主用一个备用。主用模型选能力强一点的比如 DeepSeek-V3 或者通义千问 Max负责功能点拆解和用例生成备用模型选便宜的比如 DeepSeek-Chat 之类的用来跑知识库文档的预处理。有一点要提醒Dify 默认的模型超时配置不一定适合长文档任务如果生成时报超时错误可以到模型供应商配置里把超时时间调大一般调到 120 秒以上同时在 LLM 节点的参数里把 max_tokens 也调高否则长用例集容易被截断。3.2 创建“需求转测试”工作流应用登录 Dify 控制台后点击“创建应用”类型选择“工作流”而不是 Chatbot。原因是我们要做的是一个一次性加工任务给文档出结果不需要多轮对话。用 Chatbot 反而会把交互复杂化还容易因为对话上下文干扰生成结果。创建完成后进入编排界面默认会有一个开始节点和一个结束节点。工作流类型的开始节点可以自定义输入变量这里添加两个变量一个是document类型选文件File用于接收上传的需求文档另一个是project_type类型选下拉或者字符串用于标识当前需求所属的项目类型比如 ERP、电商、游戏这个变量后续会拼进提示词里让模型在生成用例时更贴合业务。编排界面的右侧面板可以实时调试建议每加一个节点就点“运行”测试一次不要等全部节点配完再整体跑。实测下来这种边搭边调的方式能节省大量排查问题的时间。3.3 关键节点配置从文档提取到用例输出开始节点之后我逐个说一下我在工作流里配置的节点。第一个是文档提取器节点。输入选择开始节点里的document文件变量输出是提取后的文本。这一步通常不需要改参数但要注意如果原文档是扫描版 PDF提取出来可能是乱码或空文本这种情况在文档提交规范里就要提前规避。第二个是功能点拆解 LLM 节点。这个节点负责把文档文本变成结构化功能点列表。我用 DeepSeek-V3 来跑温度参数调到 0.2 左右保证输出稳定。系统提示词里明确要求输出 JSON 数组数组每个元素包含module所属模块和feature功能点描述两个字段。后面迭代器才能正确处理。第三个是迭代器节点。输入选择功能点列表变量迭代码里放两个节点知识检索节点和用例生成 LLM 节点。知识检索节点的 query 直接引用迭代码内的当前项item这样每个功能点都会去知识库里找对应业务规则。用例生成 LLM 节点的输入包含当前功能点、知识检索结果和系统提示词生成格式是 Markdown 表格。第四个是变量聚合器节点。迭代器每轮输出都会生成一段 Markdown 表格聚合器把这些段落拼成一个大文本作为最终输出。结束节点选择聚合器的输出作为结果。整个配置顺序如图文字版所示开始 → 文档提取器 → 功能点拆解 → 迭代码知识检索 → 用例生成→ 变量聚合器 → 结束。3.4 提示词模板把测试方法论写进 AI 的脑子提示词是整个流水线里回报率最高的优化点。我花在调提示词上的时间比调流程节点的时间多一倍都不止。这里分享两个核心提示词模板你可以直接复制改一改再用。功能点拆解节点的系统提示词你是一名资深测试分析师负责从需求文档中提取可测试的功能点。 请阅读以下需求文档内容将其拆解为独立的功能点列表。 要求 1. 每个功能点必须是一个可独立验证的测试单元 2. 输出格式必须为 JSON 数组不要输出其他内容 3. 数组元素包含两个字段 module所属模块例如用户中心 feature功能点描述一句话表述例如用户修改个人手机号时需要重新验证 4. 拆解的粒度要适中一个功能点对应一组相关的测试用例 5. 宁多勿漏吃不准的场景也尽量列出来 需求文档内容 {{document_text}}用例生成节点的系统提示词你是一名资深测试设计专家请根据功能点描述和业务上下文设计一套完整的测试用例。 严格遵循以下测试设计方法 1. 等价类划分对每个输入项覆盖有效等价类和无效等价类 2. 边界值分析对长度、数量、取值范围等边界做上下边界测试 3. 场景法覆盖主成功场景、备选场景、异常场景 4. 错误推测法补充重复点击、超时、权限不足、数据并发、注入攻击等常见错误场景 每个用例必须包含字段 用例编号 | 所属模块 | 功能点 | 用例标题 | 优先级 | 前置条件 | 测试步骤 | 预期结果 | 用例类型 输出要求 - 使用 Markdown 表格表头不变 - 用例类型注明正例或反例 - 如果功能点需要多条正例和反例请全部列出 - 不要添加任何解释性文字 功能点描述 {{feature}} 业务上下文来自知识库 {{knowledge_context}}提示词里的{{document_text}}、{{feature}}、{{knowledge_context}}在实际配置时替换成上游节点的输出变量。这里有两个细节值得注意一是优先级字段 P0/P1/P2/P3 虽然没在提示词里重新定义但 LLM 通常能按严重程度自己判断如果发现它判断不准可以再加一句“P0 为阻断性问题P1 为重要功能异常P2 为一般问题P3 为轻微问题”二是最后那句“不要添加任何解释性文字”非常关键不然模型会在表格前面写一大段“好的以下是...”之类的废话还得额外清洗。3.5 跑一个真实例子登录需求的用例输出为了让你直观感受流水线的输出我用一段简化版登录需求跑了完整流程。需求文本如下用户输入手机号和密码登录。手机号必须是 11 位有效手机号码密码为 6-20 位字母数字组合。连续登录失败 5 次后账号锁定 30 分钟。锁定期间无法登录30 分钟后自动解锁。流水线跑出来的部分用例截取前几条用例编号所属模块功能点用例标题优先级前置条件测试步骤预期结果用例类型TC001登录用户登录输入有效手机号和正确密码登录成功P0无1. 输入 11 位手机号\n2. 输入正确密码\n3. 点击登录登录成功跳转首页正例TC002登录用户登录手机号为 10 位时登录失败P1无1. 输入 10 位手机号\n2. 输入正确密码\n3. 点击登录提示手机号格式错误不允许提交反例TC003登录用户登录输入 12 位手机号时登录失败P1无1. 输入 12 位手机号\n2. 输入正确密码\n3. 点击登录提示手机号格式错误不允许提交反例TC004登录用户登录密码为 5 位时登录失败P1无1. 输入有效手机号\n2. 输入 5 位密码\n3. 点击登录提示密码长度不足 6 位反例TC005登录用户登录连续 5 次输错密码后账号锁定P0无1. 输入有效手机号\n2. 连续 5 次输入错误密码第 5 次登录失败后提示账号已锁定锁定 30 分钟反例TC006登录用户登录锁定期间尝试登录被拒绝P1账号处于锁定状态1. 输入有效手机号和正确密码\n2. 点击登录提示账号已锁定请 30 分钟后重试反例TC007登录用户登录锁定到期后自动解锁P2账号锁定时间已到 30 分钟1. 输入有效手机号和正确密码\n2. 点击登录登录成功解锁生效正例TC008登录用户登录密码框输入 SQL 注入语句被拒绝P1无1. 输入有效手机号\n2. 密码输入 OR 11 或单引号等特殊字符\n3. 点击登录系统拒绝登录提示账号密码错误无异常报错反例从结果可以看出流水线生成的用例对有明确规则的需求点覆盖得很不错手机号 11 位做了 10/11/12 位边界验证密码 6-20 位做了 5/20/21 位边界验证锁定逻辑也覆盖了锁定触发、锁定期拒绝、到期解锁三个场景。这套用例给任何一名测试人员做二次评审都能省掉大量从零编写的时间。4. 知识库加持让 AI 从“懂测试”变成“懂业务”4.1 知识库里应该沉淀什么历史用例、业务规则、坑如果直接把 1.3 节的提示词拿去生成 ERP 或电商需求用例你会发现效果会打个折扣。原因很简单AI 懂测试但不懂你们公司的业务口径、字段规范和历史包袱。比如一条“销售订单审核通过后扣减库存”的需求AI 默认库存扣减是同步的但你公司的实际逻辑是异步扣减用例自然就错了。知识库就是来解决这个问题的。我建议在知识库里沉淀三类内容第一类是历史用例。上一版本同模块的测试用例直接作为参考LLM 会模仿历史用例的写法和覆盖面输出和团队风格高度一致。第二类是业务规则文档和数据字典。包括字段取值范围、状态流转表、权限模型、会员等级规则等这些是需求文档里不会写但又影响测试设计的关键内容。第三类是历史缺陷记录。把曾经线上出过的 bug 整理成文档放进知识库相当于让 AI 在生成用例时自动“避坑”。举个例子如果你的知识库里有一条“历史问题修改手机号后未重新登录旧设备仍可操作导致账号被盗”那 AI 在生成用户模块用例时就会自动加一条“修改手机号后旧登录态失效”的用例。这是纯模型能力做不到的只有知识库能带来这种业务记忆。4.2 知识库搭建与检索参数调优在 Dify 里创建知识库的路径是“知识库 → 创建知识库”上传文档后选择分段模式。这里有两个参数需要重点关注分段长度和检索模式。分段长度默认是 500 个字符左右。对于业务规则类文档我建议分段控制在 300 到 800 个字符之间。太短了单段信息不完整太长了一次召回的内容太多既浪费上下文窗口也容易让 LLM 抓不住重点。另外如果文档里表格比较多可以打开“自定义分段分隔符”用换行符和表格行分割避免表格被切得七零八落。检索模式建议选择混合检索。向量检索对语义相似内容召回好全文检索对精确关键词召回好混合模式两者兼顾。TopK 我一般设 4 到 6太少了召回不到关键内容太多了模型分不清主次。相关度阈值设置在 0.3 到 0.5 之间比较合适低于这个阈值的结果基本是噪音不如不召回。知识库里的文档不会永远不变。我养成了一个习惯每次版本迭代结束把评审后新增或者修改过的用例回写到知识库。这样流水线会随着团队积累越来越“懂业务”生成质量是持续增长的。这一步刚开始看不出效果跑两三个版本后差距会非常明显。4.3 知识检索失效的排查思路知识检索失效是这种流水线最典型的故障点。症状通常是知识库明明有相关文档LLM 生成时却完全没有用上输出结果和没有知识库时一模一样。我排查这类问题有个固定的思路先看检索结果再看提示词。Dify 的调试面板里可以直接看知识检索节点实际召回了哪些文本。如果召回文本和 query 基本不相关那是检索参数问题如果召回文本相关但生成的用例没体现那是提示词里知识上下文没被放对位置或者被其他文本淹没了。还有一个很隐蔽的原因query 用词和知识库文档里的用词差异太大。比如需求文档里写“手机号变更”知识库里写“修改手机号码”语义一样但字面差异大向量检索可能就召不回。我的解法是在知识库文档入库时用 LLM 生成一段“检索关键词”字段把同义说法都列进去检索时同时匹配标题、内容和关键词。这个办法虽然多花了一点预处理时间但召回的稳定性提升非常明显。5. 踩坑实录与效果评估5.1 高频问题速查表把我在搭建和调优过程中遇到的高频问题整理成一张速查表方便你对照排查问题现象可能原因解决方式文档提取后乱码或内容为空扫描版 PDF、图片型文档在流程前加 OCR或要求提交可复制文本的版本功能点拆解结果不是合法 JSON模型输出不稳定温度调低至 0~0.2提示词里明确 JSON schema必要时用“JSON 修复”后处理节点生成的用例格式不一致提示词约束不够强在提示词里固定表头和字段拒绝“解释性文字”可输出示例长文档跑超时LLM 节点 max_tokens 或模型超时配置不足调大 max_tokens 到 4000模型提供商超时时间调至 120 秒以上或先做文档分段知识库检索结果一直不准TopK 太小、分段不合理、关键词差异大调大 TopK调整分段长度为知识库文档补充检索关键词迭代器跑了很多轮还很慢功能点拆得太碎在功能点拆解提示词中规定“粒度适中”测试时可先用 5-8 个功能点的文档验证本地小模型生成用例质量差模型参数量不够推理能力不足用云 API 模型跑主流程本地模型只用来跑预处理5.2 LLM 模型怎么选质量与成本平衡模型选型直接影响用例质量和成本。我的建议是分两档配置主流程功能点拆解 用例生成用中高能力的商业 API 模型。我试过 DeepSeek-V3、通义千问 Max 和智谱 GLM-4中文需求理解能力和用例结构化输出都做得不错。成本方面一份几千字的需求文档拆解加用例生成消耗的 token 大概在 2 万到 5 万之间折合人民币几毛到几块钱相比人工 2 到 3 小时的用例设计时间这个成本几乎可以忽略。预处理文档清洗、知识库关键词生成可以用便宜的模型甚至用本地 Ollama 跑一个 7B 的小模型就够了。这一步对推理能力要求低对速度和成本敏感。如果你所在团队对数据安全要求高、无法调用外部 API可以考虑用 Ollama 部署 Qwen2.5 14B 或 32B 级别的模型。实测 14B 模型在简单功能需求上能跑出七成左右的效果但涉及复杂业务逻辑时漏用例的概率会明显上升。如果条件允许还是建议至少主力模型用内网部署的中大规模模型而不是本地小模型。5.3 这套流水线到底值不值得搭最后聊一个比较诚实的话题这套流水线到底值不值得花时间搭以我自己这个项目为例我用 5 份历史版本的需求文档做了验证。从时间上看原本一个模块的用例设计大约需要 2 小时左右现在流水线生成初稿只需要 3 分钟加上人工评审和修改整体控制在 15 到 20 分钟。从质量上看需求点覆盖率大约 95%但生成用例的直接可用率在 60% 到 70% 之间剩下的部分需要人工理解业务后补充或修正。这意味着流水线的定位不是“替代测试人员”而是“把用例设计的启动成本降到最低”。它的价值链条是AI 负责把所有常规的思路和边界条件铺出来测试专家负责用业务经验去做筛选和增补。对团队来讲最大的收益是把测试人员从“打字员”角色解放出来把精力放到更值得投入的探索性测试和评审上。从我个人的实际使用体验来说这个项目最有价值的部分反而不是最终生成的用例而是它逼着我把需求文档规范、功能点拆解方法、知识库沉淀机制全部梳理了一遍。流水线就像一面镜子把团队里需求描述不清晰、业务规则文档缺失、历史用例没有沉淀这些老问题全都照了出来。从这个角度看就算你最后不用 Dify这套“需求 → 功能点 → 知识增强 → 用例”的思路本身也值得在团队里沉淀下来。