自动化测试解决方案

真正的全流程自动化测试

从开发提测到结果验收,让 Agent 分工完成代码检查、用例设计和实际操作。需求、代码与测试证据围绕同一张任务流转,测试人员专注异常判断与质量把关。

了解测试流程
原始实践截图:客户端测试 Agent 在任务中回传测试结果与证据清单

来自团队的真实实践 · 测试结果与执行证据,回到原任务

从开发提测,到人工验收

白盒预检与测试版本核验,在用例设计环节汇合。

左右滑动,查看完整流程

从开发提测,到人工验收白盒预检与测试版本核验,在用例设计环节汇合。 虚线表示开发根据白盒预检修复问题;黑盒测试由测试人员安排执行,验收通过后再进入待发布。开发依照白盒预检修改 Bug开发提交与提测任务进入待测试白盒测试 Agent代码归属与白盒预检测试包打包成功版本核验 Agent核验落地 Commit被 Tag 包含任务转为测试中用例设计 Agent生成数据准备与测试用例Web/客户端测试 Agent执行黑盒测试人工验收必要时建 Bug与复测任务标记待发布报告 · 截图 · 录屏待确认项

从提测到验收

每一次交接,都有依据

以「会话中切换 Runtime」为例:让用户为当前会话切换 AI 工具或执行电脑,同时保留 Agent 默认设置。

01白盒测试 Agent / 白盒检查

代码先过检,风险先明确

任务状态 → 待测试

开发将 PR 关联到需求,任务进入待测试后自动触发白盒检查。核对代码与合并结果,执行相关测试,再把需要实际操作验证的风险交给后续环节。

  • 交付给下一环节 · 测试结果、提测预检,以及工作目录、弹层位置、失败重试等黑盒检查重点。
白盒测试 Agent 在需求任务中输出测试结论和风险提示
02版本核验 Agent / 版本核验

确认测到的,就是这次改动

测试包打包成功 → 飞书通知

版本打包完成后,通过飞书通知触发核验。版本核验 Agent 确认落地提交包含在测试版本中,将满足条件的任务流转为测试中。

  • 交付给下一环节 · 版本核验结果、测试批次与更新后的任务字段。
飞书群中的版本打包通知与版本核验过程
03用例设计 Agent / 用例设计

把需求和风险,写成可执行用例

任务状态 → 测试中

根据需求描述、任务评论与白盒风险准备数据和用例,覆盖所有需求点和边缘场景。

  • 交付给下一环节 · 测试范围、前置条件、操作步骤与预期结果,直接回传原任务。
用例设计 Agent 生成的会话 Runtime 切换测试用例
04Web 测试 Agent · 客户端测试 Agent

实际操作,把验证过程留下来

测试人员安排并发起执行

按照测试用例执行测试,逐条执行后给出测试结果。输出 HTML 测试报告,保留截图和录屏证据。

  • 交付给下一环节 · 逐条用例结果、HTML 报告、截图、录屏与环境证据,供人工复核。
测试人员从任务中发起客户端测试 Agent 执行黑盒测试

Agent 分工

五位测试队友,各有所长

白盒发现风险,用例承接风险,执行留下证据。按需求选择 Web 或客户端测试路径。

白盒测试 Agent

阅读需求和代码,检查提交归属与提测条件,执行相关测试并标出风险。

版本核验 Agent

核对落地 Commit 是否被测试 Tag 包含,维护测试批次和任务状态。

用例设计 Agent

将需求与白盒风险转成测试范围、数据准备和可执行的用例表。

Web 测试 Agent

操作浏览器执行黑盒用例,交付测试报告、截图和录屏。

客户端测试 Agent

验证桌面客户端及安装、升级场景,同时保留客户端与环境证据。

配置方式

把分工,接到日常任务流转中

用 Agent 指令定义职责,用 Skills 提供操作方法,再用自动化连接触发条件和执行动作。

配置 Agent 与 Runtime

为各角色设置指令,绑定共享电脑上的 Claude Code、Codex 等 Runtime。准备仓库权限、测试工具和所需 Skills,让每个 Agent 按自己的职责执行。

Agent 配置页面:设置测试角色的指令、运行方式与工具

任务状态变化时触发 Agent 执行

待测试 → 白盒测试 Agent 执行预检;测试中 → 用例设计 Agent 生成用例。配置触发条件、执行 Agent 与指令,在自动化详情中查看提示词和运行记录。

自动化详情:任务进入测试中时,由用例设计 Agent 生成测试用例,并保留运行记录

连接 Git,关联任务与代码

通过 GitHub/GitLab 集成,将 PR 与需求任务关联。白盒 Agent 据此追踪改动,版本核验 Agent 确认落地 Commit 是否包含在测试 Tag 中。

Git 集成实践:需求任务关联的 PR 与代码记录

连接飞书,接收通知与结果

将版本打包通知接入飞书群,触发版本核验 Agent 检查测试版本。团队也可以从飞书创建和指派任务,并在群中接收 Agent 的运行结果。

飞书集成实践:群中的测试版本通知和 Agent 运行结果

落地准备

让每次开测,都有可靠的起点

可追踪的完整实现

本实践将前后端放在同一仓库,便于沿用户路径检查实现。每个 Feature 有人负责完整交付,对齐代码、部署条件和验收规则。

持续在线的共享测试机

准备浏览器、测试客户端、Runtime 和可操作的桌面环境,避免个人电脑休眠或日常使用打断测试。

脚本化的环境准备

统一依赖安装、数据库初始化、服务启动和测试命令;开测前检查服务、迁移、测试机和 Runtime 是否就绪。

专用账号与测试数据

准备管理员、普通成员、只读成员等角色,明确空间权限,并让测试数据支持自动创建与清理。

明确的验收标准

写清主流程、权限限制、异常行为和保存后的预期,让 Agent 依据需求判断对错。

持久化的执行证据

及时上传报告、截图和录屏,关联任务、运行编号与用例编号,避免临时目录回收后丢失产物。

从一条自动化开始

先跑通一个真实需求

先让白盒检查接住提测,再逐步加入用例设计、实际执行和人工验收。

01

准备一个测试 Agent

连接仓库与 Runtime,写清白盒检查职责,并确认测试机和依赖可用。

02

配置提测自动化

当任务进入待测试,自动交给 Agent 检查,将测试结论回传原任务。

03

逐步补齐测试链路

加入版本核验、用例设计和 Web/客户端执行,由测试人员复核证据并验收。

常见问题

开始之前,你可能想了解

全流程自动化,是否意味着不需要测试人员?

+

仍然需要。Agent 承担代码检查、用例生成和实际操作;测试人员定义验收标准、安排黑盒执行、判断疑点并最终验收。本实践中的客户端测试由测试人员手动发起。

每个需求都要同时跑 Web 和客户端测试吗?

+

按影响范围选择。普通 Web 功能可交给 Web 测试 Agent;涉及客户端安装、升级或本地环境时,再安排客户端测试 Agent。跨端需求应分别验证受影响的路径。

必须一次配置好五个 Agent 吗?

+

可以先从一条自动化开始:任务进入待测试时,让 Agent 做白盒检查。跑通后再加入版本核验、用例设计、黑盒执行与人工验收。

运行前需要准备什么环境?

+

本实践使用绑定共享电脑的本地 Runtime。白盒测试需要仓库和测试依赖,Web 测试需要浏览器和专用账号,客户端测试还需要测试客户端和可操作的桌面环境。建议用脚本完成环境准备和开测检查。