当测试工程遇到 AI Agent：测试智能体落地实践

从需求资料、接口文档、后台页面，到自动执行、截图取证、Excel 明细和飞书交付，我们尝试把测试工作中最重复、最容易漏、最难标准化的部分，交给一个可执行、可追溯、可迭代的测试工程智能体。

写在前面

过去一段时间，我们围绕 KAZ 资讯系统、消息系统迁移 newMSG、接口文档分析、后台 UI 自动化和飞书交付，逐步搭建了一套测试工程智能体工作流。

它不是一个“问答机器人”，也不是一句 Prompt 生成几条用例的演示工具。它更像一个能跟测试人员协作的执行型助手：能读资料、能跑脚本、能打开浏览器、能调接口、能生成报告、能把结果同步到协作平台。

这篇文章想分享的不是“AI 很厉害”，而是一个更实际的问题：

测试团队怎样把 AI 从“偶尔帮忙写点东西”，推进到“参与真实项目交付”？

一、背景：测试交付里真正耗人的地方

测试工作中最耗人的，经常不是某一个接口、某一个页面、某一条用例，而是这些细碎动作叠在一起：

这些工作有一个共同特点：它们并不都需要很强的创造力，但需要耐心、规范和持续性。恰好这是 Agent 工作流可以发挥价值的地方。

二、目标：不是替代测试人员，而是重构测试工作方式

测试工程智能体的定位很明确：

人负责目标、判断和业务取舍；智能体负责拆解、执行、记录和交付。

测试人员仍然是负责人：

• 判断需求是否合理。

• 判断用例是否充分。

• 判断失败是真缺陷、环境问题还是脚本问题。

• 判断风险是否可以接受。

智能体承担的是工程动作：

• 从资料中提取测试范围和不明确点。

• 根据接口文档和页面结构设计测试执行路径。

• 运行接口测试和 UI 测试。

• 保存截图、请求响应、失败原因。

• 输出统一格式的 Markdown 报告和 Excel 明细。

• 支持发布到飞书在线文档和飞书电子表格。

三、整体架构

flowchart LR A[需求/接口/页面资料] --> B[资料解析与问题识别] B --> C[测试策略与执行顺序] C --> D1[接口测试执行] C --> D2[UI 自动化执行] D1 --> E[执行结果归档] D2 --> E E --> F[测试报告总结.md] E --> G[测试执行明细.xlsx] G --> H[飞书电子表格] F --> I[飞书在线文档]

从文件结构上看，它把测试资产分成三类：

MyAI/ ├─ input/ # 原始输入：需求、接口文档、飞书拉取内容、备注 ├─ test_assets/ # 测试资产：用例、探索结果、自动化脚本 ├─ output/ # 执行产物：报告、Excel、截图、飞书同步结果 └─ docs/ # 规范、分享、架构和沉淀文档

这个结构解决了一个很现实的问题：测试过程不再散落在聊天记录、临时 Excel、截图文件夹和脚本目录里，而是可以按项目复盘、迁移和复用。

四、核心能力拆解

1. 资料读取与需求分析

智能体可以读取本地需求文档、接口文档、飞书文档、历史报告和人为备注，做几类事情：

• 提取功能点。

• 找出接口字段不明确点。

• 识别缺失的长度、格式、唯一性、枚举、必填规则。

• 分析页面菜单范围。

• 发现模块之间的数据依赖。

以 KAZ 资讯系统为例，接口文档存在不少字段说明不足的问题，比如字段含义、格式限制、唯一性规则、异常兜底逻辑没有写清楚。智能体会先把这些不确定点整理出来，而不是直接假设字段规则。

这一步的价值是把“测试人员脑子里的疑问”结构化，便于评审和补充。

2. 接口测试执行

接口测试不只是“把 OpenAPI 里的接口都调一遍”。我们在规范里明确了几个原则：

• 正常场景必须先准备合法依赖数据。

• 异常场景才故意传非法 ID、缺失参数、重复唯一字段。

• 编辑接口应先查详情，再基于完整对象修改指定字段。

• 查询接口不能只测分页参数，也要覆盖业务筛选字段。

• 报告中必须能看到请求、响应、判定和备注。

当前接口测试统一输出两份正本：

这让接口测试结果不再是一堆日志，而是可以直接进入评审和飞书协作的交付物。

3. UI 自动化测试

UI 自动化是最容易“看起来跑了，实际没覆盖全”的地方。我们在 KAZ 和 newMSG 上踩过这个坑。

早期 newMSG 脚本已经覆盖了配置管理、租户配置部分页面、消息通道和消息日志，但对照后台左侧菜单后发现还漏了：

• 应用列表

• 创建应用

• 租户配置

• 模板列表

• 创建模板

后来我们补了一层“菜单级 smoke 覆盖”：

菜单页面加载 列表页查询/重置 表单页控件加载 截图留证 写入执行明细

这样报告里就能明确看到每个菜单是否进入过、页面是否加载、是否有表格或表单控件，而不是只依赖脚本作者记忆。

4. 执行顺序和数据依赖

KAZ 资讯系统是一个典型例子。它的页面之间不是平铺关系，而是有明显的数据依赖：

所以 KAZ UI 的执行顺序没有简单按左侧菜单顺序走，而是写在run_all.py的MODULE_SCRIPTS里，并在探索总览文档中说明原因。

这件事的经验是：

全量 UI 测试不是“菜单从上到下点一遍”，而是要按数据生产和消费关系组织。

五、一次真实执行长什么样

以 newMSG 全量 UI 测试为例，一次完整执行大致分成 6 步：

这轮执行不是只看控制台日志，而是把过程证据一起沉淀下来。报告中可以看到执行概览，截图目录中可以看到每个关键页面的留证图片，Excel 中可以筛选失败项并继续跟踪。

示例产物路径：

output/vbkr_message_center_migration/ui_results/ ├─ 测试报告总结_20260617101258.md ├─ 测试执行明细_20260617101258.xlsx └─ full_test_20260617101258/ ├─ 应用列表_00_页面加载.png ├─ 创建应用_00_页面加载.png ├─ 模板列表_00_页面加载.png └─ ...

补齐菜单覆盖后的执行结果是：

新增的菜单覆盖项全部通过：

• 租户配置 > 应用列表

• 租户配置 > 创建应用

• 租户配置 > 租户配置

• 模板管理 > 模板列表

• 模板管理 > 创建模板

同时，失败项仍然保留在失败清单中，例如：

• 短信签名配置新增后容器未关闭。

• 接入系统新增保存超时。

• APP 菜单配置新增后搜索不到目标数据。

• 消息通道列表新增后搜索不到目标数据。

这些失败不会被简单吞掉，也不会被一句“执行失败”概括，而是进入 Excel 的失败清单，附带模块、页面、用例、实际结果、耗时和截图路径。

六、报告交付标准化

我们后来做了一个重要收口：每轮测试只交付两份正式产物。

测试报告总结.md 测试执行明细.xlsx

UI 测试的 Excel 固定三张表：

这个约束看起来很小，但对团队协作非常重要。因为测试报告最终要进入飞书，字段和 sheet 名稳定之后，后续查找、筛选、评审和复盘都会更顺。

七、为什么是 Agent，不是 Prompt

一句 Prompt 可以让模型生成一份用例，但无法完成真实测试交付。

真实流程里需要：

• 读文件。

• 读在线文档。

• 运行脚本。

• 打开浏览器。

• 处理 cookie、验证码和登录态。

• 截图。

• 生成 Excel。

• 判断失败原因。

• 修改脚本。

• 再跑一轮。

这不是一次问答，而是一个多步骤工程流程。

sequenceDiagram participant T as 测试人员 participant A as MyAI Agent participant B as 浏览器/接口 participant F as 文件系统 participant R as 报告/飞书 T->>A: 给出目标、cookie、资料或备注 A->>F: 读取需求、用例、历史报告 A->>B: 执行接口或 UI 自动化 B-->>A: 返回响应、页面状态、截图 A->>F: 写入 Markdown 和 Excel A->>R: 同步为在线文档/电子表格 A-->>T: 汇总结果、失败清单、下一步建议

Agent 的价值就在于它可以在这个流程中持续使用工具，而不是只生成一段文本。

八、落地过程中踩过的坑

坑 1：报告说“全量”，但菜单没有全覆盖

newMSG 早期脚本只覆盖了MODULES和READONLY_MODULES，看上去已经跑了很多模块，但对照真实菜单后发现遗漏了应用和模板相关页面。

后来补了MENU_SMOKE_MODULES，让菜单级覆盖进入全量报告。

经验：

全量测试必须同时对照“脚本清单”和“实际菜单清单”。

坑 2：复杂表单不能靠顺序填表硬跑

创建应用、创建模板这类页面字段多、依赖多、下拉多。通用填表逻辑如果只是按控件顺序填，很容易误填字段。

当前策略是分层：

坑 3：验证码识别不稳定

后台登录有验证码，验证码输入错误后会刷新。自动化脚本要处理：

• 多次识别重试。

• 验证码刷新。

• 登录失败后的状态恢复。

• Cookie 直接注入和自动登录两种模式。

这类问题不是一次就能完美解决，需要随着项目环境慢慢沉淀。

坑 4：Excel 结构不统一会影响协作

一开始有的报告叫测试明细，有的叫执行明细，有的还有 JSON 中间文件。后来统一成：

• 执行概览

• 执行明细

• 失败清单

并且要求正式交付不再依赖 JSON。

坑 5：内部文档访问不能只靠“能打开链接”

飞书文档、内部博客、项目平台都有访问控制。浏览器能打开，不代表 Agent 能读到。需要明确：

• URL

• cookie

• token

• 是否需要客户端证书

• 是否需要特定命令

• 输出格式

内部博客这次就是典型例子：PowerShell/curl 读不到，但 Python 标准库带 cookie 可以读取。

九、收益和变化

1. 从“靠人记”变成“有文档和脚本”

以前执行顺序、字段规则、页面依赖，经常停留在测试人员经验里。现在可以沉淀到：

• 探索总览。

• 测试用例。

• 执行脚本。

• 报告明细。

• 失败清单。

2. 从“跑完就算”变成“可追溯”

每条执行结果都有模块、页面、动作、实际结果和证据路径。后续复盘时不用再翻聊天记录找截图。

3. 从“单次交付”变成“可复用资产”

KAZ 的 UI 脚本、新 MSG 的菜单覆盖、接口测试报告格式、飞书同步能力，都可以被下一个项目复用。

4. 从“人工整理报告”变成“执行即交付”

脚本跑完后，报告和 Excel 同步生成。测试人员主要做 review 和结论确认，而不是手工搬运数据。

十、当前边界

这个智能体不是万能的。

它目前仍然需要测试人员参与这些判断：

• 需求是否完整。

• 文档未说明的字段规则如何处理。

• 后端兜底逻辑是否符合预期。

• UI 失败是脚本定位问题还是产品缺陷。

• 哪些失败需要提 Bug，哪些只是环境阻塞。

• 复杂业务链路的数据是否允许自动创建和清理。

所以我们对它的定位更接近：

一个永远在线、能执行、能留证据的测试工程助理。

不是最终裁判，也不是业务负责人。

十一、下一步计划

短期重点：

• 补齐 newMSG 创建应用、创建模板的 CRUD 深测。

• 将菜单清单自动提取，减少手工维护。

• 把接口测试中的人为备注复测流程标准化。

• 优化验证码、cookie、登录态管理。

• 把执行顺序从脚本列表逐步抽象为项目级配置。

• 尝试拉取被测项目代码，把需求、接口路径、页面路由和源码模块关联起来。

中期规划：

• 引入项目知识库，关联接口、表字段、历史缺陷、页面模块。

• 基于项目代码和执行证据做失败根因分析，区分真实缺陷、脚本问题、环境阻塞和测试数据问题。

• 打通飞书闭环：自动读取需求文档，自动发布测试报告和执行明细，并回填在线文档、在线表格链接。

• 从失败清单中生成 Bug 草稿，包括标题、复现步骤、实际结果、期望结果、请求响应、截图和影响范围。

• 对 AI 生成的测试用例引入质量评分。

• 对大模型输出类需求引入 LLM-as-Judge。

• 支持按风险自动推荐回归范围。

• 建立跨项目的测试资产索引。

自动提交 Bug 这一步需要渐进推进。建议先生成“待确认 Bug 草稿”，由测试人员确认后再提交，避免把脚本定位问题、环境问题或测试数据问题误报成真实缺陷。

长期希望达到的状态：

flowchart TD A[新需求进入] --> B[自动读取需求/接口/历史资产] B --> C[拉取并分析被测项目代码] C --> D[识别影响范围和依赖关系] D --> E[生成测试策略与用例草案] E --> F[自动执行接口/UI 测试] F --> G[失败根因分析] G --> H{疑似真实缺陷?} H -->|是| I[生成 Bug 草稿] H -->|否| J[标记脚本/环境/数据问题] I --> K[测试人员确认后提交 Bug] J --> L[回写测试报告] K --> L L --> M[同步飞书并沉淀知识资产]

十二、给测试人员的协作建议

和 Agent 协作时，最有效的不是“帮我测一下”，而是给它明确上下文。

更好的表达方式：

• “这是接口文档，先分析 admin 部分字段不明确点。”

• “这个页面是技术迁移，只需要保证增删改查正常。”

• “page_size 和 page_no，查询内容详情内容ID不存在 的异常场景忽略，后端有兜底。”

• “截图每次执行用独立文件夹，不要和旧截图混在一起。”

• “Excel 明细要和接口测试保持一致，分执行概览、执行明细、失败清单。”

这些信息越明确，Agent 越能稳定地执行。

结语

AI Agent 在测试领域最现实的价值，不是替代测试人员，而是让测试人员从重复的工程动作里抽身出来。

它帮我们做这些事：

• 把资料读完。

• 把脚本跑完。

• 把截图留好。

• 把失败列清楚。

• 把报告生成好。

• 把资产沉淀下来。

而测试人员要做的，是继续把控方向、业务判断和质量结论。

如果说过去测试自动化解决的是“让机器点页面、调接口”，那么测试工程智能体想解决的是更上游的问题：

让测试活动从分析、执行、证据、报告到沉淀，都形成一个可持续演进的工程闭环。