我平时写测试用例最烦的就是那些“测试点谁都会列但每次都列不全、列不深”的活。一个登录框翻来覆去就是必填校验、格式校验、密码错误、账号锁定那几板斧真要覆盖到SQL注入、越权、并发、弱口令这些场景全靠个人经验和临场状态。所以当Dify和Ollama这两个词频繁出现在我信息流里的时候我第一反应是这玩意儿能不能帮我把“懂业务、懂接口、懂异常场景”这件事固化下来答案是可以而且跑通之后效果比我预期的好不少。这套系统说白了就是用Ollama在本地跑一个大模型用Dify把“需求文档检索、测试点拆解、用例格式规整”串成一条流水线最后你只需要把一段需求描述或者一个接口文档丢进去几分钟就能拿到一份带优先级、带前置条件、带预期结果的完整用例表。这篇文章我就把整个搭建过程、踩过的坑、调优的心得全部摊开讲适合那些手头有测试项目、想用AI提效但又不想把数据传到云端团队的测试工程师或测试开发。1. 为什么我要自建一套测试用例生成系统而不是直接用在线大模型先聊动机。市面上能写测试用例的AI工具不少ChatGPT、Kimi、通义千问都能干这活我一开始也是直接打开网页把PRD粘贴进去让它生成。但用了两周就发现三个绕不开的问题。第一是数据隐私。公司内部的接口文档、数据库表结构、未上线的业务逻辑这些信息往公网大模型里一贴法务和安全那边第一个不答应。尤其我们做的是金融类项目别说贴文档了连“这个需求涉及批量代付接口”这种描述我都不敢写得太具体。第二是上下文割裂。网页版聊天工具每次都要重新粘贴需求、重新强调格式要求生成出来的用例风格飘忽不定这次给表格下次给列表字段名还经常变。第三是没法沉淀。同一个项目的接口文档、历史缺陷记录、规范模板这些知识散落在各个位置普通聊天工具根本没有办法把它们变成持续起作用的“背景知识”。所以我的思路很明确要有一套自己能完全掌控的系统数据不出内网知识可积累生成格式可定制。Dify加Ollama这个组合恰好能满足这些要求。Dify负责把知识库、模型调用、流程编排串起来Ollama负责在本地跑模型推理两者一结合就相当于你在自己电脑上部署了一个私有的、懂你业务规矩的AI测试助手。这里多说一句有朋友问为什么不用云厂商的API毕竟用Qwen-Max之类的在线模型效果确实比本地7B模型好不少。这个我承认但要分场景。如果你们公司对数据外发没有限制那直接用在线API接入Dify也完全可行整个架构不需要变只需要把模型供应商从Ollama换成兼容OpenAI接口的云服务就行。我之所以坚持用Ollama主要是为了“数据不出内网”这条红线另外一套本地模型跑起来之后做接口测试、造数据这些场景也能复用边际成本几乎为零。2. 环境准备Ollama模型部署和Dify社区版安装哪些细节会卡住人这一节不讲太多废话直接说我在部署过程中真正花时间解决的几个问题。Ollama的安装本身不复杂去官网下一个对应系统的安装包就行但有两个细节容易坑人。第一个是模型下载速度问题。Ollama默认从官方仓库拉模型国内网络环境下经常几KB每秒一个7B的模型少说4GB多下到天荒地老。解决办法是配置镜像源我用的是设置环境变量OLLAMA_HOST和OLLAMA_MODELS的方式镜像仓库地址可以换成国内能访问的地址具体地址因网络环境而异建议直接搜一下当前可用的镜像源另外也有人在用代理工具这个看个人网络条件我这里只讨论最稳妥的镜像方案。下载完成后可以通过ollama list命令确认模型是否就位。第二个是Dify的部署方式。官方文档推荐用Docker Compose部署我一开始没当回事直接clone代码库然后docker compose up结果发现版本之间兼容性问题不少。建议直接照着官方文档的步骤走clone指定版本的release分支不要用master最新代码然后按文档里的.env.example配置好环境变量。我部署的是社区版1.10之后的版本这个版本开始支持多租户对团队内部共享使用来说方便了很多。部署完成后验证方式很简单浏览器打开Dify的登录页能正常注册管理员账号就说明Web服务起来了。但此刻先别急着建应用还要检查Dify能不能连通Ollama。这里有一个非常容易踩的坑如果你的Dify也是跑在Docker容器里它访问宿主机上的Ollama服务时不能写localhost要写host.docker.internal或者你宿主机的局域网IP。我第一次配置的时候没注意这点在Dify后台把Ollama API地址填成了localhost:11434结果测试连接一直超时查了半天才发现是容器网络模式的问题。顺便把Ollama侧需要确认的事情也说一下。Ollama服务装好后默认监听在11434端口你要确保这个端口能被Dify容器访问到。如果开启了防火墙记得放行。我是在macOS上跑的没有这个烦恼但如果是Linux服务器部署这一步很容易漏。验证方法很简单在Dify容器里执行curl http://host.docker.internal:11434 能返回Ollama is running就说明网络通了。模型选择上我首推qwen2.5:7b中文理解能力在7B这个级别里数一数二生成测试用例的格式稳定性也不错。如果机器配置更高比如有24G以上显存可以上qwen2.5:14b效果会明显好一截。Llama3.1 8B我也试过英文场景更好但中文输出偶尔会夹英文处理中文测试用例反而不如qwen舒服。3. 知识库是第一生产力只有把PRD、接口文档、历史缺陷喂进去AI生成才有依据很多人搭完Dify加Ollama随便输入一个需求描述让AI生成测试用例结果发现生成的东西泛泛而谈毫无项目针对性于是得出“AI生成测试用例就是个玩具”的结论。说实话这不能怪模型是因为你没给它足够的项目上下文。这就好比你让一个新来的实习生写用例但什么都不告诉他只丢一句“测一下登录功能”他当然只能写出网上都能搜到的那堆通用用例。要让AI生成真正有价值的测试用例必须把项目的“行业知识”通过知识库喂进去。我实践下来至少需要准备三类资料。第一类是全项目的通用规范包括公司或团队的测试用例编写规范、通用测试数据要求、常见Web安全测试检查点清单。这些资料的目的是让AI知道“你们团队的用例格式是什么样”“你们要求覆盖哪些安全测试项”。第二类是当前被测系统的业务文档包括PRD、接口文档、数据库表结构说明、系统架构图。这些资料决定了AI对业务逻辑的理解深度比如一个转账功能它需要知道金额上限、手续费规则、资金来源限制这些具体业务规则。第三类是历史缺陷记录和线上故障复盘这部分最有价值因为AI能从过去的错误中学到容易被遗漏的测试点。比如过去发生过“并发提现导致余额超扣”的线上故障那么AI在生成提现功能用例时就会主动加上并发场景。资料准备好后在Dify中创建一个知识库把文档传进去即可。有几个细节要注意。文档格式尽量用Markdown、TXT或者PDFDify对文件的解析能力有限如果你的PRD是复杂的Word表格建议先转成Markdown再上传。分段设置选择“自动分段”就行但检索策略建议选“向量检索”召回效果比全文检索好不少。我试过混用向量检索对语义相近的内容召回更准比如你问“用户余额不足时系统怎么处理”它能召回文档里写“当账户余额小于扣款金额时提示余额不足”的那段内容。知识库建好后在Dify应用里添加“知识检索”节点关联这个知识库再设置一个合理的检索数量。太小了上下文信息不够太大了容易把无关内容混进来干扰生成。以我的经验10到20这个区间比较合适具体要看你的文档被分段之后的粒度。如果一段文档内容本身就很长检索数量取小一点如果分得很碎就取大一点。知识库跑起来之后我明显感觉到生成质量从“网络小说水平”变成了“实习生长进三个月后的水平”。比如同样是测登录功能没接知识库之前AI只会生成账号密码框的常规校验用例接了知识库之后它知道我们系统有“连续输错5次锁定30分钟”的规则知道验证码有有效期还知道登录接口要做SQL注入过滤和暴力破解防护的检查这些细节全部来自我喂进去的PRD和安全检查清单。4. 工作流编排把“需求描述”变成“结构化测试用例”的完整链路知识库解决的是“AI懂不懂业务”的问题接下来要解决的是“AI怎么组织输出”的问题。Dify的工作流编排功能是这套系统的核心我在这个环节花了不少心思。先说整体流程设计。我的工作流分成四个节点开始节点、知识检索节点、LLM节点、结束节点。开始节点接收用户输入的需求描述和需要生成的用例条数知识检索节点用这段描述去知识库里召回相关文档片段LLM节点把“用户输入检索到的文档片段系统提示词”合成一段完整的请求发给Ollama模型最后结束节点把模型生成的用例按Markdown表格格式返回给用户。听起来逻辑很简单但这里有个关键设计LLM节点里的提示词不是简单的“请生成测试用例”而是一套严格的结构化指令。我在系统提示词里明确规定了输出的格式包括用例编号、所属模块、测试标题、前置条件、测试步骤、测试数据、预期结果、优先级这几个字段。同时定义了生成用例时要遵循的规则比如必须覆盖正常流程、异常输入、边界值、接口安全、数据一致性这五类场景每条用例的步骤不能超过6步预期结果必须可验证等。这么做的好处是输出很规整可以直接复制到Excel或者禅道、Jira里。为了达到更好的效果我在提示词里还加了少量示例专业说法叫Few-shot。比如输入“用户登录”期望输出里包含一条“SQL注入防护在用户名输入框输入 or 11验证系统是否返回登录失败且无SQL报错信息”的用例。有了这几个例子Ollama这种7B小模型也能快速明白“你要的到底是什么样的用例”输出格式的稳定性提升很明显。这条经验非常实用如果你用的模型规模不大Few-shot是性价比最高的调优手段。再聊一个容易被忽略的细节LLM节点的温度参数。Ollama接入Dify后这个参数是可以调的。默认值通常是0.7但我强烈建议把它调到0.2以下。原因很简单生成测试用例是“确定性优先”的任务不是创意写作我们希望AI每一次输出都能保持稳定和严格而不是每次生成出不同的风格和侧重点。温度调低后虽然看起来“变笨”了一些但输出质量和一致性反而更好。跑通整个工作流后我实际使用下来的体感是输入“用户登录功能要求覆盖正常登录、密码错误、账号锁定、SQL注入、验证码失效、多次登录失败、并发登录”这段描述点击运行十几秒后就能拿到一份十几条的用例表格字段完整格式统一基本不需要大改就能直接评审。这比从零手写快了不止一个量级。5. 提示词设计与模型调优同样一个请求为什么输出质量差这么多Dify加Ollama这套系统里提示词设计决定了上限模型调优决定了能否逼近上限。我先后调过好几版提示词也对比过不同模型的表现这节把经验集中说一下。先说提示词的结构设计。一套好的测试用例生成提示词至少包含四个部分。第一是角色设定告诉模型“你是一名资深的测试工程师擅长Web应用功能测试和安全测试”。第二是任务描述明确“根据用户提供的需求描述和知识库检索结果生成覆盖正常流程、异常输入、边界值、接口安全、数据一致性的测试用例列表”。第三是输出格式约束用示例说明每一条用例的字段和格式。第四是质量要求比如“每条用例的测试步骤必须具体到可在十分钟内执行完成”“预期结果必须用明确的断言来描述”。我在实际调试中发现一个很微妙的事情模型对“必须”“禁止”这类强约束词的理解能力其实有限但对示例的模仿能力很强。所以与其反复强调“不要生成无效用例”“不要遗漏异常场景”不如直接在示例里放一条“无效用例”的反面例子告诉模型这种格式不完整、没有具体步骤的用例是不合格的。模型看到对比之后输出质量会明显提高。这一点对大模型尤其适用小模型对抽象规则的理解能力更弱但模仿能力依然存在所以示例驱动的方式效果更稳定。另外一个重要的调试维度是知识库检索内容的组织方式。默认情况下知识检索节点会把所有检索结果按顺序拼接在一起传给LLM但这会导致一个问题当检索结果很多、超过模型上下文窗口时LLM可能会被中间某段不相关的内容带偏。我的解决方法是把系统提示词放在最前面然后用占位符引用知识库检索结果最后再强调一遍“请严格按照以上信息生成用例不要编造系统中不存在的功能”。这样模型在生成时始终带着“以检索内容为准”的约束。模型选择方面我做了几组对比实验。qwen2.5:7b在格式遵循能力上表现最稳生成的用例结构基本不会乱Llama3.1 8B的英文内容处理能力更强但对中文需求的理解弱一些偶尔会把业务规则理解偏DeepSeek-R1-Distill-Qwen-7B在逻辑推理上表现不错但生成速度略慢。如果机器配置允许我建议直接上14B级别的模型推理深度和上下文理解能力都会有肉眼可见的提升。如果只能在7B范围内选那qwen2.5:7b是目前综合体验最好的选择。最后说一个很多人没注意到的问题生成速度。本地模型在CPU上跑7B模型生成一条完整用例大约需要30到60秒体验相当着急。建议有条件的一定要用GPU哪怕是苹果的M系列芯片用Metal加速后速度也能快三四倍。如果公司有闲置的带GPU的Linux服务器那最好直接把Dify和Ollama都部署在服务器上团队成员都能访问效率会高很多。6. 实测效果、典型翻车案例与后续扩展方向系统跑通之后我拿真实项目做了几轮测试有惊喜也有翻车。先说效果好的场景。拿一个“批量代付接口”的需求做实验输入描述加上知识库里的接口文档AI生成的用例覆盖了正常批量导入、部分卡号无效、余额不足、代付接口超时、重复提交幂等性、并发批量请求、敏感信息加密传输等十几个关键场景其中幂等性和并发这两个点说实话我手工写的时候经常漏掉AI反而记住了。这个效果让我觉得整套系统的核心价值已经达到了它不是替代你写用例而是帮你把遗漏的场景补上。另一个效果不错的场景是回归测试用例生成。我把上几个版本的缺陷记录导入知识库然后输入“生成订单退款功能的回归测试用例”AI会调取历史缺陷中退款超时、退款金额算错、退款状态回写失败这些曾经出过问题的点生成针对性很强的回归用例。这比人工翻历史缺陷再整理要高效太多。但翻车案例也值得讲一下。最典型的问题是当输入的需求描述过于模糊时AI会基于知识库里通用安全测试清单的内容去生成一堆“看起来正确但和你项目毫无关系”的用例。比如我输入“测一下用户中心”AI生成了一堆关于头像上传格式、昵称敏感词过滤的用例但用户中心实际核心功能是账户信息修改、实名认证、解绑手机号它一个都没提。原因很简单模糊输入匹配到的知识库内容也是模糊的。解决方法是让知识库按功能模块拆分同时输入时尽量带上“登录”“注册”“用户资料修改”这类具体功能名。如果输入质量不够AI输出质量永远上不来。另一个常见问题是对数据库相关的测试点覆盖不足。可能是模板里没有强调AI生成的用例大部分集中在界面和接口层面对数据库层面的校验偏少。我的解决办法是在知识库里放了一份“数据库常见测试检查点”包括数据一致性、并发控制、脏数据插入、事务回滚、数据字典约束、索引效率等内容AI在生成时就会自动把这些检查点融入到用例里。加了这个之后用例深度直接提升了一个档次。如果你所在团队有“根据编码批量自动生成不同二维码”这类复杂数据需求的测试场景也可以把对应的编码规则说明放进知识库让AI生成编码规则校验相关的测试用例。后续我计划在三个方向继续扩展这套系统。第一是接入自动执行链路把生成的用例直接通过接口调用去验证部分可自动化的测试点比如用Python脚本跑一遍生成的接口用例把结果回写到Dify里标注通过或失败。第二是多轮对话式完善用例在Dify的对话流里加一个“继续补充场景”的交互节点让测试人员可以在AI生成的初版用例基础上继续追问“再加几条并发场景的用例”“把金额边界值补全”这样生成结果会更贴合手工思维。第三是把知识库做得更厚实把线上监控告警规则、竞品分析文档也喂进去让AI的“行业视野”更广。另外Dify社区版持续在更新我部署的1.10版本已经支持多租户了如果你们团队人比较多升级到新版本在多账号管理上会省心很多。最后分享一个个人体会这套系统真正提升效率的不是“一键生成完整用例”而是“把初级工作压缩到分钟级”。以前分配一个新模块给新人写用例至少得半天现在AI生成一版老工程师在上面做增删改两个小时就能出去一份质量不错、覆盖面完整的用例集。这就是AI辅助测试的正确打开方式它不给最终答案但给了你一个远超平均水平的初稿。如果你也在做测试用例自动生成相关的探索建议先从知识库积累开始那个环节做得越厚后面的效果越超预期。