Coze工作流自动生成功能测试用例，并驱动Playwright脚本实践

一直以为测试用例只能靠人肉一条条写，直到我把 Coze 工作流接上需求文档，生成效率和用例覆盖度直接提升了一大截。这篇文章就聊聊我搭的一套“Coze 自动生成测试用例”工作流：它怎么拆解需求、按测试设计方法自动产出功能测试用例，以及怎么把用例进一步变成 Playwright 可直接执行的脚本。

如果你是测试工程师、QA Lead，或者正在搭团队测试基建的开发，这套方案能帮你把“写用例”这个重复劳动大幅压缩。下面直接进入正题，我会把工作流的设计思路、节点配置、提示词模板和踩坑记录都摊开讲。

1. 为什么我会用 Coze 写测试用例

1.1 写用例的痛点：重复、零散、靠经验

做功能测试的人都有这种感觉：新版本来了，需求文档堆成山，用例要一条条写，而且很多模块长得都差不多——登录、列表、筛选、详情、编辑、删除，来回就那几套逻辑。真正费时间的不是设计，是把同样结构的用例反复打字，还要费劲去对齐字段格式、前置条件和预期结果。

更麻烦的是，用例质量完全取决于写的人。资深测试知道要补边界值、异常流、权限校验，新人往往只写了主流程happy path，一上线就漏测。这个痛点靠“加强培训”解决不了，靠“让测试多花时间”更不现实，得把测试设计方法本身固化到工具里，让人人都能按统一标准产出高质量用例。

1.2 为什么选 Coze 而不是直接裸调大模型

直接打开一个聊天窗口让大模型生成用例，我也试过。效果怎么说呢——能出东西，但没法用进工作流：没有固定模板、格式飘忽不定、漏场景、编功能，最要命的是每个人每次问出来的东西都不一样，没有沉淀价值。

Coze 的价值在于它把大模型能力包装成了可编排的工作流：输入可以是文件、文本、URL，中间可以有文档解析、知识库检索、代码执行、条件分支，输出可以固定成 Markdown、JSON、表格甚至转成 Word 文档。也就是说，我可以把“测试工程师写用例的思路”整个复制到工作流里，变成标准流程。同一份需求文档丢进去，无论谁操作、操作多少次，产出的用例结构都一致，质量下限被兜住了。

另外 Coze 是浏览器即开即用的平台，不用自己部署模型服务，团队里任何人打开链接就能用。这点对测试团队特别友好，不需要所有人都会写提示词，只需要一两个人把工作流搭好，其他成员直接上传文档等结果就行。

1.3 这套方案能覆盖哪些测试场景

我实际验证过三类场景：

1. 功能测试用例生成：给 PRD 或需求描述，输出覆盖正常流、异常流、边界值的用例表格，这是最常用的场景，也是本文的主线。
2. 自动化脚本辅助生成：在功能用例基础上，让 LLM 按 Playwright 语法输出可执行脚本。不是全自动生成能直接跑的全部脚本，而是把每个用例对应的操作步骤和断言逻辑先写出来，人工微调后即可执行。
3. 单元测试用例设计：如果给到函数源码或接口定义，Coze 也能按单元测试用例设计方法（分支覆盖、边界覆盖、异常输入组合）生成单测用例框架。这一块我目前只做了轻量验证，效果不如功能测试那么惊艳，但作为补充场景也够用。

下面重点讲功能测试用例生成这条主线，因为它是整个工作流里收益最明显、最值得复制的部分。

2. 核心思路：把测试设计方法固化到工作流里

2.1 工作流节点的角色划分

我搭的工作流和大多数“一条链走到底”的简单流程有个重要区别：它不是让一个大模型节点从需求直接吐一堆用例，而是拆成了三个阶段、三个节点，每个节点承担不同角色。

为什么这样拆？

直接让大模型“读完需求就写用例”，它在超长上下文里很容易顾此失彼：前面提到的字段约束写到后面忘了，主流程用例生成了十几条，异常流一条没有。这是我在实测中最常见的问题，也是最影响可用性的点。

拆成三阶段之后，每个节点输入输出都是结构化的中间产物——先有功能点和规则清单，再基于清单生成用例，最后再让审查节点专门“找茬”补漏。相当于模拟了一个测试组长的干活流程：先理解需求、再设计用例、最后自查一遍。实测这样拆解后，用例覆盖度明显提升，尤其是边界值和异常流。

2.2 提示词里要写清楚的五要素

不管工作流搭得多花哨，核心还是提示词设计。提示词写得好不好，直接决定用例质量。我在反复调优后，把测试用例生成的提示词固定成五个要素：

1. 角色定义：让模型明确自己是资深测试工程师，熟悉等价类划分、边界值分析、场景法、错误推测法。
2. 输入来源：说明用例要基于上一节点提取的功能点和业务规则，不要自己编造不存在的功能。
3. 输出结构：规定每条用例必须包含用例编号、所属模块、用例标题、前置条件、测试步骤、预期结果、优先级七个字段，且步骤用编号列表。
4. 覆盖要求：明确要求覆盖正常流、异常流、边界值、权限校验，每条需求必须至少有正常流和异常流各一条。
5. 格式约束：最终输出为 Markdown 表格，方便后续转 Word 或导入测试管理平台。

提示词模板我放在第 3 部分的配置里，你可以直接抄。

2.3 从需求描述到用例字段的映射

这里再往深挖一层：为什么说“先把需求转成功能清单”就能提升用例质量？

关键在于业务规则和字段约束是测试用例的原材料。举个例子，需求文档里写“用户名支持 6-20 位字母或数字”，这句话在原始文档里可能埋在好几段文字中间，让模型直接生成用例，它很容易只写一条“输入正确的用户名密码，登录成功”就完事了。

但如果先有一个节点专门做信息抽取，把这句话抽成结构化规则：username: 6-20位，字母数字，必填，那生成节点就拿到了非常明确的边界值测试输入：5位、6位、20位、21位、含特殊字符、为空、纯数字、纯字母……用例自然就详细了。

所以在设计时，我特意把“输入格式、长度、是否必填、业务状态流转、不同角色权限”这些内容单独抽出来，放进一个功能清单里。这一步是整个工作流比裸聊大模型强的最关键原因。

3. 实操搭建：从上传需求文档到输出表格

3.1 准备工作：账号与材料

用 Coze 工作流需要先有个账号，浏览器打开平台注册即可。我建议直接在工作流编辑页面操作，不用先建 Bot，因为测试用例生成的核心逻辑都在工作流里，Bot 只是外层封装。

需要准备的材料很简单：

1. 一份真实的需求文档，格式可以是 txt、pdf、docx 或 markdown。强烈建议用 markdown 格式，解析效果最稳定。
2. 明确的输出要求，先想清楚你要的是 Markdown 表格还是 Word 文档。
3. 被测系统的基本信息，比如用户角色、模块划分、常见权限规则，这些可以作为固定配置写进系统提示词里。

3.2 输入节点与文档解析配置

工作流第一件事是接收用户的输入。我配置了两种输入方式：

• 直接粘贴需求文本（适合小文档，省去解析环节）
• 上传文件（适合 PRD、需求说明书，走文件解析节点提取文本）

文件解析节点配置时要注意一个细节：大文档一定要做截断或分段处理。Coze 的文件解析节点会对内容长度有限制，我之前传过一个 50 多页的 PRD，解析出来后被截掉了后半段，功能点直接少了一大半。后来我把文档按照章节拆成多个文件，每个文件单独走一轮生成流程，再汇总结果，彻底解决了这个问题。

如果你不想手动拆文档，也可以在工作流里加一个文本处理节点，按标题关键字（如“第X章”“功能需求”）自动切分文本，再循环处理。这个方案更优雅，但配置复杂度高一些，新手可以先手动拆。

3.3 LLM 节点参数与提示词模板

工作流里需要三个 LLM 节点，参数基本一致，重点在提示词不同。我用的核心参数如下：

• 模型：选择效果较好的版本，具体按平台当前可用模型选，效果优先
• 温度：0.2 左右。生成测试用例不是创意写作，要求稳定、可控、可复现。温度过高会让每次输出的用例结构漂移，同一份需求两次生成结果完全不同，非常难受
• 最大 token：建议 4000 以上，否则用例一多就会输出截断
• 输出格式：如果平台支持 JSON 模式，建议开启，方便后续节点处理

第一个节点（需求理解）的提示词我写得很简洁：

你是一名资深业务分析师。请提取用户提供需求文档中的功能点和业务规则。 要求： 1. 按模块归类列出所有功能点 2. 对每个功能点，标注涉及的字段、输入约束（长度/格式/必填性）、业务状态、角色权限 3. 不要遗漏异常场景相关的规则（如密码错误次数限制、超时、并发等） 4. 输出格式：Markdown 列表，按【模块名】分组

第二个节点（用例生成）的提示词是核心，我也直接贴出来：

你是资深测试工程师，请基于下面的功能点和业务规则，设计功能测试用例。 功能点和规则： {{function_list}} 要求： 1. 使用等价类划分、边界值分析、场景法、错误推测法设计用例 2. 每个功能点至少覆盖：正常流、异常流、边界值 3. 涉及权限的功能，需包含无权限/低权限访问用例 4. 每条用例格式如下： | 用例编号 | 所属模块 | 用例标题 | 前置条件 | 测试步骤 | 预期结果 | 优先级 | 5. 测试步骤内部用 1. 2. 3. 编号，预期结果必须可验证 6. 不要生成与输入规则无关的用例

第三个节点（质量审查）的提示词核心是“找茬”：

你是一位严格的测试组长，审查下面的测试用例清单。 审查重点： 1. 是否有遗漏的边界值（如列表为空、单条数据、最大数量、超过最大数量） 2. 是否有缺失的异常流（如接口超时、服务端报错、非法输入） 3. 是否有重复用例或相似用例需要合并 4. 用例标题是否清晰，预期结果是否具体可验证 5. 补充你发现的所有遗漏用例，直接输出完整的用例清单，不要只输出修改意见

3.4 输出节点：Markdown 表格与 Word 导出

第三个节点输出的 Markdown 表格，已经可以直接复制使用。但我在实际使用时发现，测试团队更习惯把用例导出成 Word 或 Excel 文档去评审，所以我在工作流最后加了一个输出环节，把 Markdown 转成 Word。

Coze 平台里文件处理能力升级后，文档生成这块体验好了不少。我走的方案是：用代码节点运行 Python 脚本，把 LLM 输出的 Markdown 表格解析成 docx 文件，关键处理包括中文字体设置为宋体、表格自动加边框、用例标题行加粗。

核心代码逻辑大概是：

from docx import Document from docx.shared import Pt from docx.oxml.ns import qn doc = Document() doc.styles['Normal'].font.name = 'Times New Roman' doc.styles['Normal']._element.rPr.rFonts.set(qn('w:eastAsia'), '宋体') doc.add_heading('功能测试用例', level=0) table = doc.add_table(rows=1, cols=7) table.style = 'Table Grid' # 表头写入 headers = ['用例编号', '所属模块', '用例标题', '前置条件', '测试步骤', '预期结果', '优先级'] for i, h in enumerate(headers): table.rows[0].cells[i].text = h # 按行解析markdown表格并写入

不过说实话，这步配置对不熟 Python 的朋友有一定门槛。如果你不想折腾代码，也可以让 LLM 输出一个标准 CSV 格式的用例清单，然后用 Excel 打开另存为即可，不用额外写代码。两条路都可行，优先级看你自己习惯。

4. 进阶玩法：让 Coze 输出的用例直接驱动 Playwright

4.1 为什么功能用例和自动化脚本可以一起生成

这是我从“生成给人看的用例”跨到“生成给机器跑的用例”的关键一步。

功能测试用例和 Playwright 自动化脚本之间，本质上共享同一个信息源：操作步骤和预期结果。人工写自动化脚本时，也是先把测试步骤翻译成 page 操作，再把预期结果翻译成断言。那这个过程同样可以交给 LLM。

区别在于，自动化脚本对格式要求极其严格——选择器写错一个字符就定位不到元素，断言方法用错就直接报错。所以这个节点不能像生成功能用例那样自由发挥，必须在提示词里给出非常严格的约束。

4.2 让 LLM 输出稳定可执行的 Playwright 代码

我在工作流里的“脚本生成”节点是这样配置的：

1. 输入上一步生成的用例清单
2. 提示词中明确指定使用 Playwright 的sync_playwrightAPI
3. 要求只使用page.goto / page.fill / page.click / page.wait_for_selector / page.inner_text这些基础稳定方法，不要用复杂的 xpath，优先使用id、placeholder、>from playwright.sync_api import sync_playwright def test_login_positive(): with sync_playwright() as p: browser = p.chromium.launch(headless=False) page = browser.new_page() page.goto("http://your-app/login") page.fill("#username", "valid_user") page.fill("#password", "valid_pass") page.click("#login-btn") page.wait_for_selector(".dashboard") assert page.inner_text(".user-info") == "valid_user" browser.close()

   这一步生成的脚本，说实话直接运行的概率不是 100%，但已经能替代 70% 的机械编码工作。剩下的 30% 主要是元素定位修正和特殊业务逻辑处理，这部分工作量和纯手写相比已经非常划算了。

   4.3 关于选择器稳定性的一个经验

   这里有个我踩过几次的坑：AI 很喜欢自己去"猜"定位器，比如page.click("text=登录")、page.locator("div.login-form > button")，这类选择器在页面小改版后就会挂。所以我在提示词里专门加了一句：

   所有元素必须使用配置的元素映射表中提供的 id 或>