干测试这些年我一直觉得最费时间的事情就是写测试用例。需求一变几十条用例就要陪着改线上环境不一样边界条件也得跟着调手工维护一条条用例本质上是在打地鼠。直到我试了用Coze搭建自动生成测试用例的工作流把一段需求描述丢进去几分钟就能拿到一版结构完整、覆盖不错的测试用例实测下来这个方案是真的稳。先说我眼中的Coze是什么。它就是一个可视化的AI应用搭建平台国内用起来很方便你可以在里面组装一个工作流把大模型节点、代码节点、条件判断、知识库、文档插件像拼积木一样串起来。也就是说你不光能让AI帮你写用例还能让AI帮你把用例整理成固定格式、按字段校验完整性甚至转成Word文档或者生成自动化脚本。这套组合拳打下来写用例这件事的自动化程度比我预想的高很多。这篇文章就把我的搭建思路、核心细节、实操过程和踩坑记录都摊开讲适合所有被重复性用例编写折磨的测试工程师也适合想用Coze做文本生成类工作流、但不知道怎么设计流程的人参考。1. 为什么建议用Coze搭测试用例生成工作流1.1 手动写用例的同款痛点先啰嗦几句痛点。很多人会说写用例难道不是测试的基本功吗是基本功没错但基本功做久了重复劳动的部分会让人非常疲惫。一个功能模块正常流程、异常流程、边界条件、权限场景、数据关联场景这些都是必写的少说二三十条多的上百条。我以前写过一次活动页面的用例需求文档只有两页A4纸最后用例写了两百多条写了整整一个下午第二天产品经理改了需求其中有三分之一直接作废。这种重复劳动有几个典型问题。第一是容易漏人不是机器写到最后几条时注意力已经下降了最容易漏掉的是那些看起来不常发生、但一发生就是事故的异常分支。第二是不稳定不同测试人员写出来的用例风格差异很大有人喜欢把前置条件和操作步骤写在一起有人喜欢分得很细评审的时候经常因为格式吵起来。第三是维护成本高需求一旦变更你得手动逐条去过判断哪些用例受影响了这个动作非常消耗精力。我尝试过用通用的大模型聊天窗口写用例效果是有的但体验很割裂。你得把提示词复制来复制去生成的格式经常变今天用表格明天用列表而且当需求比较复杂的时候大模型容易写着写着就跑偏。后来我开始研究Coze工作流因为它能把让AI干活这件事拆成可复用的流程至少解决了流程化的核心问题。1.2 Coze解决了我最头疼的三个问题用Coze搭完之后我复盘了一下它实际上解决了三个具体问题。第一个是流程固定。工作流不是一锤子买卖的聊天它是把写用例这件事拆成一段可以反复执行的pipeline。我只要把需求文本丢进去后面的解析、生成、校验、格式化都是固定流程不会像聊天一样每次输出都不一样。你甚至可以设置不同的入口处理功能测试用例和接口测试用例走不同的分支流程。第二个是格式可控。Coze里可以在工作流中加入代码节点我能对LLM的输出做二次处理比如强制转成JSON、过滤掉多余的空格、按字段校验完整性再把结果拼成统一的Markdown模板。这个能力是最关键的因为AI生成内容最大的毛病不是写不好而是格式不稳定格式一稳定后续交给其他系统处理就很方便。第三个是生态衔接好。Coze有插件系统、知识库、文件上传这些能力。我可以把历史用例文档传到知识库让AI参考过往的项目风格生成用例也可以通过工作流的文件上传能力直接读取PRD文档内容省去手动整理需求的时间。再加上文档处理插件生成完的用例还能直接转成Word交付整个链路都不用离开平台。1.3 工作流的输入与输出到底该怎么设计搭工作流之前第一件事不是急着去拖节点而是想清楚输入和输出。我见过很多人搭Coze工作流失败就是因为一开始没定义清楚搭到一半发现缺这少那。我的输入设计分两种场景。场景A是功能测试用例输入是需求描述文本或者一个功能点列表。场景B是接口测试用例输入是接口文档的关键信息包括请求方法、URL、请求参数、必填校验、返回码等等。这两种场景对LLM的要求不一样功能测试用例需要理解业务流程接口测试用例需要更结构化的字段化推理所以我在工作流里做了两个分支分别用不同的Prompt处理。输出设计上我强制要求输出JSON结构再通过代码节点转成Markdown表格。字段我固定成以下几列用例编号、所属模块、用例标题、前置条件、测试步骤、预期结果、优先级、设计方法。为什么用这八列因为这是我们在实际评审中最常用的维度优先级方便排版本设计方法方便做覆盖率审计前置条件和预期结果则是用例是否可执行的关键。这里我做一个输入到输出的对应关系表看起来更直观一些输入类型处理方式输出结果需求描述文本LLM节点解析业务规则功能测试用例JSON数组功能点列表LLM节点逐项拆解每个功能点的多条用例接口文档字段LLM节点字段级推理接口测试用例JSON数组历史用例/规范文档知识库检索辅助风格统一的用例文案我在这个设计上最大的体会是,先把输出结构定下来再去搭节点成功率会高很多。因为后面的代码校验、模板拼装、插件导出全都是围绕这个输出结构来设计的。2. 让Coze写出高质量测试用例的核心细节节点、Prompt与参数2.1 节点选型与编排逻辑为什么这样设计Coze工作流的节点看着很丰富但真正核心的就那几个大模型节点、代码节点、条件判断节点、知识库节点和插件节点。我在用例生成这个场景里用得最多的是前三个。大模型节点是主角。它的作用是完成需求理解、用例生成这些智力工作。这里要注意一个节点干一件事就够了不要想着一个节点把所有活都干了。我早期的失败经验就是一个LLM节点既做需求解析又做用例生成还做格式整理结果输出经常出现你让我总结需求又让我出用例我该以哪个为主这种混乱。现在我的流程是第一个LLM节点只负责把用户输入的需求文本拆成功能点列表第二个LLM节点才负责根据功能点列表生成用例职责干脆效果也稳定。代码节点是配角但不可缺。它主要负责三件事校验大模型节点的输出、处理字符串格式、组装最终的Markdown。有人会问校验格式为什么要用代码节点因为LLM的输出不是百分百可靠偶尔会多出注释文字、缺少字段、甚至直接输出一段无关内容代码节点可以用程序逻辑兜底而不是靠提示词求着它别出错。条件判断节点用来做分支路由。比如判断输入里有没有接口文档字段如果有就走接口用例生成分支如果没有就走功能用例分支。这个在复杂一点的工作流里很有用。节点编排的通用逻辑我觉得可以这样理解开头节点收集输入解析节点理解需求生成节点产出内容校验节点确保质量导出节点做结果落地。清晰的流水线比堆节点更重要。2.2 测试用例Prompt模板直接能抄的那种Prompt设计是整个工作流里核心中的核心。我调试了很多版最后沉淀下来两个最稳定的模板这里直接分享出来。第一个是功能测试用例生成模板我通常放在主LLM节点里你是一位资深测试工程师擅长功能测试用例设计。请根据以下功能点列表为该功能生成完整的测试用例。要求覆盖正常流程、异常流程、边界值、权限场景、数据关联场景。每个用例必须包含用例编号、所属模块、用例标题、前置条件、测试步骤、预期结果、优先级、设计方法。设计方法必须标注采用的是等价类划分、边界值分析、场景法中的哪一种。请严格按照JSON数组格式输出不要输出任何解释性文字和Markdown代码块标记。配合的输入格式是{module: 登录模块, feature_list: [用户名密码登录, 验证码登录, 记住密码]}第二个是接口测试用例生成模板我会用在工作流的接口分支你是一位接口测试专家。请根据以下接口定义设计接口测试用例。重点关注参数必填、参数类型、参数边界、业务约束、异常返回码。输出字段要求用例编号、接口名称、请求方法、请求URL、请求参数、预期状态码、预期响应内容、设计方法。请严格按JSON数组输出。接口定义的输入我一般这样组织{api_name: 创建订单, method: POST, url: /api/order/create, params: {goods_id: string,必填, num: int,1~99, coupon_id: string,选填}}我为什么会反复强调严格按JSON数组输出不要输出解释性文字因为大模型天生有输出的惯性它总想跟你解释一句好的下面是生成的用例这多出来的话会让代码节点直接解析失败。我甚至会在Prompt最后加一句如果你理解了我的要求直接开始输出不要做任何额外说明。2.3 让输出稳定可控的三个小技巧除了Prompt本身还有三个参数和设置层面的小技巧对稳定输出帮助很大。第一个是模型选择。不要无脑选最强最大的模型要看任务类型。用例生成这种任务逻辑推理占比高对发散创作要求低我实测下来选豆包或者通义千问这类在国内环境稳定的模型配合适合文本生成的版本效果就很好。模型太大会导致输出速度慢而且容易自由发挥过度生成一些根本不成立的用例步骤。模型太小又会出现字段遗漏、逻辑跳脱的问题。我建议在多模型里各跑一遍同一条用例选那个在格式和内容上最稳定的。第二个是温度参数。Coze的大模型节点里模型参数通常可以配置。温度我一般设置在0.3左右。测试用例需要的是确定性输出不是创意写作温度太高会导致每次生成的用例内容飘忽不定A/B版本完全对不上温度太低又会显得死板边界条件的思考容易被压掉。0.3是我试下来覆盖率和稳定性比较平衡的点。如果某个模型默认不支持配置温度那就依赖强约束的Prompt来兜底。第三个是二次校验。我在主LLM节点后面一定会挂一个校验LLM节点或者代码节点专门检查输出是不是合法的JSON、字段有没有少项。代码节点做JSON解析解析失败就把原始文本丢给一个专门的修复节点处理解析成功就继续走。这套机制加上去之后流程成功率从大概80%提到了95%以上体验提升非常明显。3. 从零到一搭建Coze测试用例工作流一步一步实操记录3.1 前置准备账号、模板和一份真实需求开始动手之前需要的准备工作并不多但每一样都别省。首先是Coze账号。国内环境直接用扣子平台就行注册登录后打开工作台可以看到项目列表。我个人习惯是先在个人空间里建一个项目把所有测试用例相关的资源放在一起。国际版的界面和信息架构略有不同但国内版对中文需求的解析更友好推荐先用国内版。其次是准备一份测试用例模板。这份模板不是给AI看的是给你自己定义输出标准用的。我的办法是把公司之前的优秀用例脱敏后整理成几份代表不同风格的文档后续上传到知识库让AI在生成时参考句式和颗粒度。没有历史模板也没关系可以先用我上节给的Prompt字数生成一版再反向调整格式要求。最后是准备一份真实的需求文本作为测试输入。第一次搭工作流时我强烈建议不要直接拿一个大而全的PRD去测而是选一个功能点比较清晰的小模块比如用户注册分享海报生成这类。目标越小调试越容易定位问题。我自己的第一份测试输入选的是验证码登录功能一开始就控制了变量。3.2 搭主流程需求解析节点到用例生成节点现在进入实操。打开Coze工作台新建一个工作流命名可以叫测试用例自动生成助手。第一步拖入开始节点。这个节点负责接收用户输入。我设置了两个输入字段一个是requirement_text用来接收需求描述文本另一个是input_type用来标记输入类型是功能用例还是接口用例。input_type这个字段非常重要它是后面条件判断节点做分支路由的依据。第二步拖入第一个大模型节点命名为需求解析器。在这个节点里我要做的是把用户输入的需求文本转成结构化的功能点列表。模型选我刚才说过的通用文本模型温度设0.3Prompt用这样一段你是一个需求分析助手。请从用户输入的需求描述中提取功能点并以JSON数组输出。每个功能点包含function_name功能名称、description功能描述、rules业务规则列表。如果输入内容不完整请输出空数组不要自行编造功能点。这个节点就干这么一件事不做别的。很多人会在这个节点忍不住让AI顺便把用例也写了真的是一个大坑一旦出问题你根本分不清是解析问题还是生成问题排查起来非常痛苦。第三步拖入条件判断节点判断input_type。这一步的意义在于区分功能测试用例和接口测试用例两条生成链路。功能链路走我上面给的功能用例Prompt接口链路走接口用例Prompt。两个分支各自挂一个大模型节点我这里会分别命名为功能用例生成器和接口用例生成器。3.3 让代码节点做格式校验一次彻底的兜底主流程串起来之后下一步就是在每个用例生成节点后面挂代码节点这个环节绝对不能漏。代码节点的作用我前面提过主要是校验和规整。我实际使用的JavaScript逻辑大致如下// 输入previous_output 是LLM输出内容 async function main({ previous_output }) { let raw previous_output.trim(); // 去掉可能出现的Markdown代码块标记 raw raw.replace(/json/g, ).replace(//g, ); let arr; try { arr JSON.parse(raw); } catch (e) { return { is_valid: false, error: e.message, raw: previous_output }; } // 校验必备字段 const required [case_id, module, title, precondition, steps, expected, priority, method]; for (let item of arr) { for (let key of required) { if (!(key in item)) { return { is_valid: false, error: missing field: key, raw: previous_output }; } } } return { is_valid: true, cases: arr, count: arr.length }; }这段代码解决了我三个实际问题一是去掉LLM画蛇添足加的代码块标记二是把非法JSON拦截在流程中间而不是带病往下走三是在字段缺失时报出具体字段名方便我回查Prompt哪里约束不到位。如果代码节点返回的是is_valid: false工作流会进入异常分支。我在异常分支里放了一个修复节点也是一个LLM节点它的Prompt是请修复以下JSON数据使其合法并补全缺失字段只输出修复后的JSON然后修复节点的输出再送回同一个代码节点做二次校验。这个暴力重试修复的机制虽然看起来不够优雅但在实际运行中非常管用流程稳定率就是这样一点点拉上来的。3.4 让用例更贴合项目风格知识库和文件上传的两种玩法Coze里对测试用例生成最有帮助的两个能力我认为是知识库和文件上传。它们的场景完全不同但都能减少人工干预。知识库的玩法是这样的。我把历史项目的用例文档脱敏后做成一个知识库文档格式用Markdown或者Word都行Coze会自动做索引。在工作流里加一个知识库节点让它检索并返回与当前功能点相关的历史用例文本片段然后把这个片段作为上下文拼进用例生成器的Prompt里。这样生成的用例在语言风格、颗粒度、步骤描述习惯上会和团队的历史风格高度一致。我甚至试过把团队内部的用例评审规范也传进去Prompt里可以引用规范来判断优先级如何设置效果很不错。文件上传的玩法更多用在入口优化上。Coze工作流支持文件上传节点用户可以直接上传需求文档比如Word版本的产品需求文档。节点会解析出文本内容再交给需求解析器处理。这样测试人员就不需要手动从PRD里复制需求描述了。这个能力在对付大文档时很省力尤其当一个需求的描述分散在文档多个章节的时候直接让AI读取全文比人眼去找要快得多。不过要注意文件上传对超大文档仍有长度限制我一般建议超过一万字的文档先做章节拆分或者只上传核心需求描述章节。3.5 从Markdown到Word测试用例文档的导出链路测试用例写出来不是终点交付才是。我们团队测试用例的呈现载体是Word文档所以工作流的最后一步我做了从Markdown到Word的转换。实现方式有两种第一种是直接用Coze的文档处理插件在插件市场搜文档转换或者Word生成相关的插件把前面代码节点组装好的Markdown内容作为输入插件输出Word文件这个做法最简单但不同的插件对表格样式的支持度不太一样用之前要测一下生成的Word表格是否完整。第二种是自己在代码节点里做。简单一点可以生成一个.doc兼容的HTML文件内容是标准的HTML表格把文件后缀改成Word可识别的格式WorkOS上大部分流程都能接受这种方式。Coze代码节点里可以用JavaScript拼字符串把用例数组遍历成HTML表格行最后组装成一个带table结构的HTML文本。我在这个环节的踩坑经验是不要过度依赖模板文件生成docx。docx本质是一个压缩包里面是多段XML要在代码节点里手工生成docx实在是太复杂了而且稍有不慎文件就会损坏。用插件或者用HTML转Word的方式稳定性都要高得多。如果项目对格式要求极高还可以让工作流输出Markdown源码再自己用本地工具批量转换成Word虽然多了一步但可控性最强。3.6 往自动化方向延伸与Playwright测试脚本的衔接测试用例生成之后还有一个让人很兴奋的方向就是把用例直接转成自动化测试脚本。这里我重点说下Playwright。Playwright是微软开源的一套自动化测试框架支持Chromium、Firefox、WebKit写脚本用的是JavaScript或Python。它是完全合规合法的开源技术也是目前业界做端到端测试的主流选择之一。Coze生成测试用例之后怎么和Playwright衔接呢我的思路不是在Coze里直接跑Playwright而是让Coze生成可转化成脚本的用例结构。具体做法是在用例生成的Prompt里增加一项要求为每个用例提供playwright_code字段字段里是这条用例的可操作步骤描述比如点击登录按钮、输入用户名、断言元素可见。这些描述不是直接能运行的代码但它的操作序列已经足够明确。然后我再写一段转换逻辑把用例的步骤描述映射成Playwright的API调用模板比如page.click(选择器)、page.fill(选择器, 值)、expect(page.locator(选择器)).toBeVisible()。这里我不会让AI直接生成完整可跑的脚本因为不同前端项目的元素定位方式千差万别AI不了解你的页面结构生成的代码大概率不能直接跑。更合理的做法是让AI产出可理解的步骤和定位建议再由测试开发人员或代码生成工具去做最终映射。这个思路可以避免大量无效调试工作。我自己试过一次让AI直接生成Playwright代码结果因为元素定位全部失效脚本基本没法用后来改成先生成步骤描述再人工映射效率反而高了很多。4. 实测中踩过的坑Coze生成测试用例常见问题与排查4.1 输出格式飘忽不定最让人头疼如果你只用Coze做过简单对话可能体会不到格式问题有多恶心。当工作流里的下游节点依赖上游输出的时候格式飘忽不定就是最大的流程杀手。我最早跑通流程的时候第一次生成出来的是JSON第二次竟然在JSON外面套了json代码块标记第三次直接输出了Markdown表格代码节点解析直接崩掉。针对这个问题的排查方法我的经验有几条。第一条是在Prompt里把输出格式写成负面清单加正面示例的方式正面示例就是完整的一个JSON数组样例负面清单就写不要输出代码块标记、不要输出解释文字、不要输出Markdown标题。负面约束对LLM的规范效果非常好。第二条是代码节点做兼容处理就是我前面那段代码先用正则把代码块标记剥掉再解析。第三条是异常分支做修复重试让修复节点把非JSON内容改造成JSON再回来过一遍校验。4.2 用例覆盖不足漏掉关键分支怎么办AI写用例的另一个常见问题是漏。它的漏和人一样容易漏掉异常条件、权限场景、数据之间的相互影响这些冷门分支。针对覆盖率问题我的方法论是分层设防。第一层防在Prompt里面我要求用例设计必须显式标注设计方法比如等价类划分、边界值分析、场景法并且要求每个功能点至少覆盖一条正常流、一条异常流、一条边界值。这个要求看起来简单但对大模型有很明显的强制定心丸作用它为了不丢面子会刻意补齐这几类用例。第二层防在代码节点里统计每一组用例中设计方法字段里是否包含边界值和异常这两个关键词如果没有就返回警告提醒我人工复核这个模块。第三层靠人工评审兜底AI生成用例我从来不会直接提交一定会安排至少一轮快速评审重点就是看有没有明显漏掉的业务规则。4.3 长文本截断和字段丢失这个坑最隐蔽Coze大模型节点都有最大输出token限制模型越便宜限制越严格。我遇到过最尴尬的情况是上下文很长的时候输出到一半戛然而止用例数组的最后几条被切断整个JSON变成非法格式。不仔细看根本看不出是截断了因为JSON没闭合报错也报得很隐晦。这个问题的根治思路是分片。与其让AI一次生成很多用例不如把功能点列表拆开一个功能点或者两个功能点一组分多次生成最后再把用例数组合并起来。合并这个工作也在代码节点里做把多次生成的JSON数组合并成一个大的数组。分片虽然会增加调用次数但稳定性提升立竿见影。另外一个问题是上下文过长导致模型遗忘某些字段这时需要精简Prompt。我把Prompt里的解释性文字全部删掉只留精确要求和示例实测字段丢失率下降很多。4.4 其他高频问题和处理办法速查再列一个速查表把我在使用中遇到过的问题、现象和解决办法都整理在一起方便你对照排查问题现象可能原因我的解决办法输出不是JSONPrompt约束不足增加正面示例和负面清单加修复节点JSON解析通过但字段少LLM遗漏字段代码节点做字段校验缺字段走重新生成分支用例内容雷同温度参数太高或Prompt缺乏约束温度降到0.3要求按设计方法分类生成用例步骤不够具体功能点拆解太粗先解析生成更细的功能点列表再生成用例生成的用例脱离需求上下文被其他内容干扰精简Prompt只保留必要的示例和输入长文档上传后处理失败超出模型上下文限制上传前做章节拆分或只上传核心章节Word转换后表格错乱插件对Markdown表格支持不完整改用HTML模板生成或用本地脚本批量转换这个速查表基本覆盖了我三个月中遇到的高频问题如果你后面踩到新坑大概率也能在里面找到类似的处理思路。5. 跑了三个月我用真实数据算了一笔账5.1 时间成本对比从人工半天到工作流十分钟先算最实在的时间账。以一个中等复杂度的功能模块为例包含十个功能点每个功能点平均需要十二条用例。在没有使用Coze之前我手动编写这大约一百二十条用例快的下午也要三四个小时而且中间要不停翻需求文档、对照边界值、思考命名规范。如果需求描述再模糊一点一整天耗在上面也不意外。用了Coze工作流之后我的操作流程变成把需求描述复制进工作流设定模块名和功能点点击运行整个流程大概需要两到五分钟。跑完之后我花十五到二十分钟做一件事——人工评审。重点看漏掉的业务规则、异常的优先级是否合理、步骤描述是否够清晰。总体时间从三个小时缩短到了半小时以内而且消耗的主要是评审时间不是编写时间。我自己的直观感受是工作流替代的是机械书写的部分保留的是测试设计判断的部分。5.2 覆盖率和可维护性评估时间是看得见的收益另一个维度是质量。我对照了同样一个功能模块的人工用例和Coze用例人工用例是两百二十条Coze生成的是两百四十六条。我第一反应是AI比我还能写但仔细评审后发现AI多的那些用例里有一部分是穷举参数组合产生的伪增量可用性不强。不过它在边界值和异常场景上的覆盖率确实比我习惯的那个版本要高尤其是权限场景、空值场景、超长值场景几乎都没漏。所以我的结论是Coze不是用来替代测试人员思考的它是用来补齐人工盲区的。它最大的价值在于当你已经想清楚了这个功能应该覆盖哪些类型之后它可以快速帮你把每个类型下的具体用例铺满而铺满这个动作在人工执行时最容易偷懒或遗漏。可维护性方面因为工作流输出的是结构化的JSON后续如果用例格式需要调整我只需要改Prompt和代码节点的模板重新跑一遍工作流几秒钟就能全量更新。这比我以前手动改几十条用例要舒服太多了。5.3 最后再分享几点我的实际体会这几个月用下来我对Coze自动生成测试用例这件事的认知也在变化。最初我以为它是一个偷懒工具后来发现它更像一个提效底座。它不是让你变成一个不写用例的人而是让你把写用例的时间挪去做更值得做的事比如测试策略设计、自动化脚本维护、现场问题复盘。如果让我给准备入手的同学提三条建议这可能是最核心的实践沉淀第一不要追求一个工作流解决所有用例类型。功能用例、接口用例、性能用例的逻辑差异很大各自独立的工作流或者分支会更容易维护。第二把格式校验做扎实比把Prompt写漂亮更重要。稳定的结构是工作流能被信任的基础。第三留一条人工评审的底线。AI生成用例之后责任还在测试工程师身上评审不过关的用例坚决不能直接进项目文档。我在实际项目里已经把这套工作流用到了三个模块上稳定运行的体验给了我一个明确的方向以后新功能进来先跑一版AI用例再人工评审打磨测试设计的效率确实可以再上一个台阶。这就是我最真实的感受希望这篇记录能让你少走一些弯路。
