点击蓝字
关注我们
一个测试工程师的24小时
● 09:00 收到30页PRD，下午要出用例
● 15:00 写了60条用例，发现登录规则改了，重来
● 22:00 回归测试挂了一个老功能，没用例，手工跑
● 00:30 还在写测试报告
痛点本质：需求理解靠人、用例设计靠手、缺陷分析靠猜。在传统的测试流程中，测试工程师需要反复阅读冗长的产品需求文档，逐字逐句理解后凭个人经验手动编写用例。这个过程不仅耗时，还容易遗漏边界情况或异常场景，尤其是当需求变更时，测试用例的同步更新又是一轮繁重的手工劳动。
Coze（扣子）不是又一个Chatbot，而是一个可编排、懂业务、能执行的AI智能体平台。工作流本质上是一个有向无环图（DAG），由多个节点按照特定逻辑连接而成，支持条件分支、并行处理和错误恢复，更贴合真实业务场景。
本文不讲概念，直接上硬货——四阶AI测试工作流，附代码和配置。
一、Coze凭什么能干活？
Coze集成了GPT-4、DeepSeek等多种大模型能力，其核心优势在于通过可视化拖拽节点的方式编排逻辑，无需编码即可构建复杂流程。
同时，知识库集成功能允许上传项目文档、接口规范、测试标准等，让AI真正具备“领域知识”。
二、实战案例：一个完整的工作流设计
为了让你更直观地理解工作流的设计过程，这里以“用户登录功能”为实战案例，完整拆解从零搭建到上线运行的全流程。
第一步：明确输入与输出
假设我们收到这样一份需求文档：
登录功能需求：
1、用户可通过手机号和密码登录
2、手机号为11位数字，以1开头
3、密码长度为8-16位，需包含大写字母、小写字母和数字
4、登录成功：跳转至首页，显示“欢迎，[用户名]”
5、登录失败（手机号或密码错误）：提示“手机号或密码错误”
6、登录失败（手机号或密码为空）：提示“请输入手机号和密码”
7、连续失败5次后，账号锁定30分钟
期望输出：一份标准的测试用例列表，包含用例ID、测试模块、用例标题、前置条件、操作步骤、预期结果、优先级等字段。
第二步：设计工作流框架
根据上述需求，设计如下工作流：
整个工作流框架由四个核心节点构成：
1.开始节点：定义输入参数，如用户上传的PRD文档或需求文本
2.文档解析节点：读取并解析上传的文档内容，将其转化为纯文本
3.LLM处理节点：这是工作流的“大脑”，根据解析出的需求文本生成结构化测试用例
4.结束节点：将生成的测试用例以指定格式输出
第三步：创建工作流
实际操作步骤如下：
1、登录Coze平台（https://www.coze.cn），在个人空间中选择“工作流” → “创建工作流”
2、填写工作流名称和描述，点击“确认”进入编辑画布
3、插入开始节点，定义输入变量（如将变量名命名为 requirement_text，类型设置为文本或Word文档）
4、添加插件节点 → 选择“文件读取”插件，将开始节点与读取节点连接
5、添加大模型节点，选择合适的模型（如DeepSeek-R1），配置提示词
6、将各节点首尾相连，形成完整的数据流向
7、点击“试运行”验证工作流，测试成功后发布
下图为工作流的详细结构示意图：
工作流的最大优势在于支持条件分支、并行处理和错误恢复。例如，在“登录功能”案例中，可以在LLM节点后添加一个“判断节点”，当需求中涉及“记住密码”“多因素认证”等扩展功能时，自动分支到对应的用例生成逻辑，实现更精准的覆盖。
三、四阶AI测试工作流
第一阶段:需求解析→自动输出风险点和验收标准
工作流节点：知识库检索 → LLM分析 → 结构化输出
在开始需求解析之前，需要先创建知识库。知识库是让AI“学会”业务的核心。
知识库创建步骤：
1、点击“个人空间” → “知识库” → “创建知识库”
2、填写知识库名称（如“XX项目需求库”）和描述
3、点击“新增单元”，上传以下文档：
● 产品需求文档（PRD）——PDF或Word格式
● 接口文档（Swagger JSON）
● 测试标准文档（优先级定义、通过准则等）
● 历史用例库（Excel/CSV，作为AI的范例）
4、选择“自动采集”或“手动上传”，等待系统完成文档切片
5、Coze会自动将文档分割成内容片段进行存储，并通过向量搜索检索最相关的内容
知识库结构说明：
● 知识库：一整套领域知识，是Bot加载的最小单位
● 单元：知识库的一部分，可上传的最小内容单位（一个PDF文件或一个网页）
● 分段：一个单元切分成多个分段，是模型查询的最小单位。分段内容的完整度和准确性直接影响AI回答的质量
工作流Prompt模板（可直接复制） ：
你是测试架构师。分析以下需求，输出:# 一、核心测试要点(3-5个)# 二、模糊点与风险点(表格:模糊描述|潜在风险|澄清问题)# 三、验收标准(Given/When/Then格式)# 四、建议测试数据不确定的信息不要编造，放入“模糊点”。
输入:PRD片段或文档链接
输出:一份可直接评审的结构化报告，需求理解时间从2小时压缩到10分钟。
下图展示了第一阶段工作流的节点构成和数据流向：
实战输出示例（登录需求）：
1. 核心测试要点
● 正常登录流程
● 密码错误锁定机制
● 输入校验（手机号格式、密码复杂度）
● 连续失败计数与锁定恢复
2. 模糊点与风险点
3. 验收标准
● 场景1：正确手机号+正确密码 → 跳转首页
● 场景2：连续5次错误密码 → 账号锁定30分钟
4. 建议测试数据
● 正确手机号：13812345678
● 正确密码：Abc12345
● 错误密码：Abc1234（7位）、abc12345（全小写）等
第二阶段：用例生成 → 20+条用例/30秒
工作流连接：将第一阶段的输出作为本工作流的输入。
Prompt模板：
基于以下需求分析，生成测试用例。要求:- 覆盖:正常、异常、边界、安全- 技术:等价类、边界值、判定表- 格式:Markdown表格(编号|标题|前置条件|步骤|预期结果|优先级)编号规则:TC-模块-类型-序号(FUNC/BOUND/EXCP/SEC)优先级:P0阻塞/P1高/P2中/P3低
工作流图示：
实战效果（登录功能为例）：
产出：20+条用例，耗时30秒，人工审核5分钟。效率提升8倍。
第三阶段：执行辅助 → 数据生成 + 环境巡检
测试数据自动生成（独立工作流）：
工作流设计:- 开始节点: 输入数据规格描述- LLM节点: 生成测试数据- 代码节点: 格式校验（正则表达式）- 结束节点: 输出JSON数组输入示例: "10个合法手机号 + 5个非法手机号"LLM生成后校验: 正则 ^1[3-9]\d{9}$输出: ["13812345678", "13987654321", ...]
环境巡检Bot（定时触发）：
工作流设计:- 触发器: 定时触发（每小时）- HTTP节点: 调用服务健康检查接口 /health- 代码节点: 解析响应码- 条件节点: 非200则触发告警- 通知节点: 企业微信发送告警告警示例: "【告警】订单服务 /health 返回503，请及时处理"
工作流图示：
效果：7×24小时无人值守，MTTR从2小时降到5分钟。
第四阶段：缺陷分析 → 自动提单 + 根因推断
自动提单工作流（输入失败日志 → 输出Jira工单）：
工作流设计：
1、触发节点：手动触发（粘贴失败日志）或Webhook触发（自动化测试失败时自动调用）
2、知识库检索节点：从历史缺陷库中检索类似问题
3、LLM节点：分析失败信息，生成结构化缺陷报告
4、HTTP请求节点：调用Jira/TAPD的API自动创建缺陷单
5、通知节点：发送企业微信消息
LLM Prompt：
根据以下失败信息，输出JSON格式缺陷报告:{"title": "[模块]简述","severity": "致命/严重/一般","steps": "1. ... 2. ...","actual": "","expected": "","root_cause_guess": "基于日志的初步分析"}失败场景: {{scenario}}日志: {{logs}}
根因分析增强（结合知识库）：
● 输入：NullPointerException at OrderService.calculatePrice:127
● 知识库检索：第127行调用了 couponService.getUserCoupons()
● 历史故障匹配：2025-01-15类似问题，缓存返回null
● 输出：“根因假设：getUserCoupons返回null而非空列表；修复建议：返回Collections.emptyList()”
开发拿到的不是一句“报错了”，而是带排查路径和修复建议的报告。
工作流图示：
完整四阶工作流总览
四、落地配置（可直接抄）
4.1 自愈定位配置（coze-config.yaml）
element_strategy:primary: "data-test-id"fallback: ["id", "text", "xpath"]self_healing:enabled: truemax_attempts: 3healing_strategies: ["re_locate_by_text", "scroll_and_retry"]
效果: 按钮ID从 login-btn改成 submit-login，脚本不报错——自动通过文字“登录”重新定位。
4.2 Docker私有化部署
字节跳动于2025年7月26日正式开源Coze，包含Coze Studio可视化开发工具和Coze Loop运维管理系统两大核心组件，仅需2核CPU+4GB内存即可本地运行。
# 1. 克隆代码git clone https://github.com/coze-dev/coze-studio.gitcd coze-studio/docker# 2. 配置环境变量cp .env.example .env# 3. 配置模型（以DeepSeek为例）# 编辑 backend/conf/model/deepseek-r1.yaml，填写base_url和api_key# 4. 一键启动docker compose --profile '*' up -d# 5. 访问控制台# 浏览器打开 http://localhost:8888
避坑指南：
● 端口冲突：若提示端口被占用，使用 netstat -ano | findstr :3306 查找占用进程后结束，或修改 docker-compose.yml 中的端口号
● MySQL启动失败：报错 MYSQL_USER cannot be "root" 时，删除系统环境变量中的 MYSQL_USER 和 MYSQL_PASSWORD
● Elasticsearch启动失败：报错 exit 127 时，用VSCode打开 docker/volumes/elasticsearch/setup_es.sh，将右下角CRLF切换为LF后保存
4.3 CI/CD集成（GitLab CI）
coze_test:image: coze/runner:latestscript:- coze run --project web-e2e --env stagingartifacts:paths:- reports/
每次代码提交自动触发测试套件，报告自动归档。
......
本文节选自第九十期《51测试天地》
原创文章
《用Coze做测试:从点工到AI训练师的实战之路》
文章后续为大家详细讲解了:
模型选型、避坑指南与核心转变等
想继续阅读全文
或查看更多《51测试天地》的原创文章
请点击下方 阅读原文或扫描二维码 查看
声明：本文为51Testing软件测试网 半夏 用户投稿内容，该用户投稿时已经承诺独立承担涉及知识产权的相关法律责任，并且已经向51Testing承诺此文并无抄袭内容。发布本文的用途仅仅为学习交流，不做任何商用，未经授权请勿转载，否则作者和51Testing有权追究责任。如果您发现本公众号中有涉嫌抄袭的内容，欢迎发送邮件至：editor@51testing.com 进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。