Dify+AI:从需求文档到Excel用例,全自动生成,我的测试用例以后全交给AI写了【附完整配置流程】

产品扔过来一份需求文档，你从头看到尾，然后在 Excel 里一条一条敲测试用例。功能一多，写到大半天，脑子糊了，漏测是常有的事。

咱们天天说 AI 赋能测试，AI 到底怎么赋能？

今天带你实操一遍，用 Dify 搭一个工作流。以后你只要上传需求文档，AI 自动帮你分析测试点、生成结构化用例，最后直接导出 Excel。

整个流程就四步，跟你平时做事的逻辑一模一样：拿到需求文档，分析需求挖掘测试点，根据测试点写详细用例，导出成文档。区别在于，以前这四步全是你在干，以后你让 AI 来干。

一、为什么不是直接问 AI，而是搭工作流

很多人试过直接把需求文档丢给 ChatGPT，让它生成用例。确实能生成，但问题马上来了。

第一次，它给你 Markdown 表格，表头是“用例编号-输入-预期”。第二次，它给你自然语言描述，开头是“针对以下接口，建议覆盖如下场景”。第三次，它把异常和正常混在一起，你得重新分类整理。

每次格式都不一样，每次都要手动调整。更烦的是，每次都得重新写一遍 Prompt：“你是资深测试工程师，请覆盖正常、异常、边界、鉴权四类场景……” 同样的话，说了不下五十遍。

这时候你才意识到：你缺的不是 AI 能力，是让 AI 稳定输出的“容器”。

Dify 工作流的价值就在这。它把测试流程固化成标准化节点，每个节点干每个节点的事。你不再需要每次重新写 Prompt，不再需要每次手动整理格式。AI 按你设计好的流程走，输出稳定、可复用、可迭代。

二、整体思路：四步流程，跟平时做事一样

整个工作流拆开来看，就是四步：

第一步，拿到需求文档。第二步，分析需求，挖掘测试点。第三步，根据测试点写出详细用例。第四步，导出成文档。

在 Dify 里，这四步对应五个节点：开始节点接收文件，文档提取器读取内容，第一个 LLM 节点生成测试点，第二个 LLM 节点生成详细用例，Markdown 转换器把结果导出成 Excel。

下面一步步拆解怎么搭。

三、实操拆解：从创建应用到跑通工作流

3.1 创建应用

在 Dify 里选择创建空白应用，类型选 Chatflow。应用名就叫“根据需求生成测试用例”。应用描述可以写：可以针对需求文档，分析挖掘需求，提炼为测试点，并生成 Excel 测试用例。

创建完成后，进入功能管理，把“文件上传”打开。这一步很重要，不开的话后面上传不了需求文档。

3.2 节点一：开始

这个节点不用动啥，直接用默认的就行。它的作用是接收用户上传的文件和输入的查询内容。

3.3 节点二：获取需求文档——文档提取器

这个节点选“文档提取器”。你只需要做一件事：输入变量那里，选开始节点里的 sys.files。说白了，就是告诉 AI，你上传的那个文件要从哪儿拿。

文档提取器支持 txt、markdown、mdx、pdf、html、docx、csv、xlsx 等格式，常见的需求文档格式基本都覆盖了。

3.4 节点三：生成测试点——LLM 节点

这是整个工作流最关键的一步。

模型选择 deepseek-chat，或者你习惯用的大模型。上下文选择上一个节点“文档提取器”的 text。

系统提示词可以这样写：

# 角色你是一位经验丰富、专业的软件测试工程师，擅长从复杂的原始需求中提炼核心测试点。# 任务以下是完成任务的详细步骤：1. 需求深度挖掘：   - 仔细阅读原始需求文档，识别所有显性和隐性需求。   - 标记需求中的模糊点或矛盾点，提出澄清问题。   - 分析需求的业务背景和技术约束，确保测试覆盖全面。2. 测试点提炼：   - 熟练使用常见用例设计方法，如等价类、边界值分析、错误推测法、场景法、流程分析法等。   - 依据不同类型的需求，精准匹配最合适的用例设计方法。3. 异常情况考虑：   - 设计非法值、空值、越界值等异常输入测试用例。   - 验证系统对违反业务约束情况的处理能力。   - 确保所有错误提示信息清晰且符合用户预期。4. 用户视角验证：   - 始终站在用户的角度思考问题，逼真模拟用户在实际使用软件过程中的各种场景。   - 从用户操作习惯、期望结果等方面出发，完善测试点的设计。# 输出- 仅设计测试点，无需设计详细的测试用例。- 输出格式严格以 markdown 形式，不要包含 ```markdown``` 等语言标签，只输出标准的 markdown。# 示例输入：用户登录功能，要求用户名6-20位字母数字组合，密码8-16位且必须包含大小写和特殊字符。输出：- 用户名6位，密码8位，是否正常登录- 用户名0位，密码16位，是否正常登录- 异常输入：用户名5位- 异常输入：用户名21位- 异常输入：密码7位- 异常输入：密码17位- 异常输入：密码输入纯数字/纯字母/纯字符- 用户名为空- 密码为空- 连续5次错误密码后锁定账户

USER 变量选择开始节点的 sys.query。

这一步输出的是一份测试点清单，不包含详细步骤，只列测试场景。为什么先出测试点再出用例？因为测试点是“测什么”，用例是“怎么测”。分开两步走，AI 的思考更有层次，输出质量也更稳定。

3.5 节点四：生成测试用例——LLM 节点

模型同样选 deepseek-chat。上下文选择上一个节点“生成测试点”的 text。

系统提示词这样写：

# 任务针对【上一个节点】输出的测试点，输出表格类型的测试用例。表头为：用例编号、用例模块、用例标题、前置条件、测试步骤、预期结果。其中，测试点作为用例标题；测试步骤从【文档提取器】的 text 中梳理，每个步骤之间换行输出。# 输出将表格类型的测试用例，转化为表格类型的 markdown，不要包含 ```markdown``` 等语言标签，只输出标准的 markdown 表格。

USER 变量可以留空，也可以按需填写。

这一步输出的就是结构化的测试用例表格了。表头固定，字段清晰，每条用例包含编号、模块、标题、前置条件、步骤和预期结果。

3.6 节点五：将生成的测试用例输出为 Excel

这里需要用到工具：Markdown 转换器。

先切换到工具视图，搜索“Markdown 转换器”，找到后安装到插件，下载完成后才能在编排页面选择。

然后添加“markdown 转 xlsx 文件”这个工具。设置输入变量时，选择上一个节点“生成测试用例”的输出。

这样，AI 生成的 Markdown 表格就会自动转换成 Excel 文件，你可以直接下载。

3.7 节点六：直接回复

把最终结果返回给用户。整个工作流就跑通了。

四、调试与避坑

搭完之后，别急着上复杂需求，先用一份简单的需求文档跑通，再换复杂的。

常见问题一：AI 输出带了 markdown 标签，导致后面转换失败。 解决办法是在提示词里明确写“不要包含 markdown 等语言标签，只输出标准的 markdown”。

常见问题二：测试步骤没有换行，挤在一行。 解决办法是在提示词里写“每个步骤之间换行输出”。

常见问题三：生成的用例表头不对。 解决办法是在提示词里把表头字段写死，不要让 AI 自己发挥。

常见问题四：上传文件后没有反应。 检查功能管理里的“文件上传”是否开启，检查文档提取器的输入变量是否选了 sys.files。

调试的时候，可以逐个节点查看输出。先看文档提取器有没有正确读出内容，再看生成测试点的输出是否符合预期，最后看生成用例和 Excel 转换是否正常。

五、从执行者到流程设计者

这个工作流最大的价值，不是省了几小时，而是把你的测试经验固化下来。

以前你写用例，靠的是脑子记、手速快。写得多了会累，累了会漏。AI 有一个人类比不了的优势：它不会累，不会漏。你手动写可能写着写着忘了某个边界条件，但 AI 会基于需求文档逐条分析，覆盖率比你凭感觉写要高得多。

更重要的是，你的角色变了。

以前你是一个手动执行者，拿到需求，打开 Excel，一条条敲。现在你是一个流程设计者，你设计分析路径，AI 执行并填充细节。你不再拼手速，你拼的是定义标准的能力。

测试工程师的核心价值，从来不是敲用例，而是设计覆盖策略和判断质量风险。用例可以 AI 生成，执行可以自动化，报告可以模板化。唯独“哪些场景必须覆盖”“哪些风险可以接受”“能不能上线”，这些判断只能人来做。

这个工作流的作用，就是把“敲用例”的时间省下来，让你有时间去做真正需要人脑的事。

六、最后

这套工作流的核心就是四步流程、五个节点、四个避坑点。你照着搭一遍，也就十来分钟的事。

搭好之后怎么用？你只需要做一件事：上传需求文档。AI 自动帮你分析出测试点，自动生成结构化的测试用例，最后直接导出 Excel。原来半天的工作，现在几分钟搞定。

拿到文档后，一定要去 Dify 里亲手搭一遍，别放收藏夹吃灰。搭好了，你每天至少省出两个小时。

我把完整实操文档整理好了，里面包含工作流配置截图、完整提示词、模块映射表，以及端到端案例源码和目录结构。

有需要的朋友，评论区扣“666”，我直接发你。