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

从需求资料、接口文档、后台页面到自动执行、截图取证、Excel 明细和飞书交付我们尝试把测试工作中最重复、最容易漏、最难标准化的部分交给一个可执行、可追溯、可迭代的测试工程智能体。写在前面过去一段时间我们围绕 KAZ 资讯系统、消息系统迁移 newMSG、接口文档分析、后台 UI 自动化和飞书交付逐步搭建了一套测试工程智能体工作流。它不是一个“问答机器人”也不是一句 Prompt 生成几条用例的演示工具。它更像一个能跟测试人员协作的执行型助手能读资料、能跑脚本、能打开浏览器、能调接口、能生成报告、能把结果同步到协作平台。这篇文章想分享的不是“AI 很厉害”而是一个更实际的问题测试团队怎样把 AI 从“偶尔帮忙写点东西”推进到“参与真实项目交付”一、背景测试交付里真正耗人的地方测试工作中最耗人的经常不是某一个接口、某一个页面、某一条用例而是这些细碎动作叠在一起场景传统做法问题需求质量一般人工读文档、整理问题、找产品确认容易漏字段、漏边界、漏异常规则接口文档不完整手工补参数、试接口、猜字段限制自动化容易因为依赖数据不对产生假失败后台菜单很多人工逐页点、截图、记录页面行为覆盖范围不透明报告说“全量”但可能漏菜单UI 有数据依赖靠经验决定先测哪个模块换人后顺序丢失回归不稳定报告交付手工写 Markdown、整理 Excel、上传飞书格式不统一证据链断裂这些工作有一个共同特点它们并不都需要很强的创造力但需要耐心、规范和持续性。恰好这是 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、缺失参数、重复唯一字段。编辑接口应先查详情再基于完整对象修改指定字段。查询接口不能只测分页参数也要覆盖业务筛选字段。报告中必须能看到请求、响应、判定和备注。当前接口测试统一输出两份正本产物用途测试报告总结.md给人看的结论、范围、问题、风险测试执行明细.xlsx给协作和追溯用的逐条执行明细这让接口测试结果不再是一堆日志而是可以直接进入评审和飞书协作的交付物。3. UI 自动化测试UI 自动化是最容易“看起来跑了实际没覆盖全”的地方。我们在 KAZ 和 newMSG 上踩过这个坑。早期 newMSG 脚本已经覆盖了配置管理、租户配置部分页面、消息通道和消息日志但对照后台左侧菜单后发现还漏了应用列表创建应用租户配置模板列表创建模板后来我们补了一层“菜单级 smoke 覆盖”菜单页面加载 列表页查询/重置 表单页控件加载 截图留证 写入执行明细这样报告里就能明确看到每个菜单是否进入过、页面是否加载、是否有表格或表单控件而不是只依赖脚本作者记忆。4. 执行顺序和数据依赖KAZ 资讯系统是一个典型例子。它的页面之间不是平铺关系而是有明显的数据依赖顺序模块依赖/产出1栏目管理产出栏目/信源配置2频道管理产出有效频道3股票管理提供有效股票代码4视频管理提供可关联视频5内容管理产出内容最好是可发布/已发布状态6频道资讯管理依赖内容 频道7个股资讯管理依赖内容 股票所以 KAZ UI 的执行顺序没有简单按左侧菜单顺序走而是写在run_all.py的MODULE_SCRIPTS里并在探索总览文档中说明原因。这件事的经验是全量 UI 测试不是“菜单从上到下点一遍”而是要按数据生产和消费关系组织。五、一次真实执行长什么样以 newMSG 全量 UI 测试为例一次完整执行大致分成 6 步步骤动作产物1明确测试目标技术迁移场景重点验证后台菜单可达、CRUD 主链路和只读日志查询测试范围说明2准备登录态和测试环境配置.env、cookie 或测试账号3对照后台左侧菜单补齐 smoke 覆盖项菜单覆盖清单4执行 UI 自动化脚本逐页进入菜单、填写表单、查询结果并截图full_test_时间戳/截图目录5汇总执行结果按通过、失败、跳过分类测试报告总结.md6生成 Excel 明细保留每条用例的模块、页面、动作、实际结果、耗时和证据路径测试执行明细.xlsx这轮执行不是只看控制台日志而是把过程证据一起沉淀下来。报告中可以看到执行概览截图目录中可以看到每个关键页面的留证图片Excel 中可以筛选失败项并继续跟踪。示例产物路径output/vbkr_message_center_migration/ui_results/ ├─ 测试报告总结_20260617101258.md ├─ 测试执行明细_20260617101258.xlsx └─ full_test_20260617101258/ ├─ 应用列表_00_页面加载.png ├─ 创建应用_00_页面加载.png ├─ 模板列表_00_页面加载.png └─ ...补齐菜单覆盖后的执行结果是指标数量总用例65通过50失败11跳过4菜单补充覆盖5Excel 工作表执行概览、执行明细、失败清单新增的菜单覆盖项全部通过租户配置 应用列表租户配置 创建应用租户配置 租户配置模板管理 模板列表模板管理 创建模板同时失败项仍然保留在失败清单中例如短信签名配置新增后容器未关闭。接入系统新增保存超时。APP 菜单配置新增后搜索不到目标数据。消息通道列表新增后搜索不到目标数据。这些失败不会被简单吞掉也不会被一句“执行失败”概括而是进入 Excel 的失败清单附带模块、页面、用例、实际结果、耗时和截图路径。六、报告交付标准化我们后来做了一个重要收口每轮测试只交付两份正式产物。测试报告总结.md 测试执行明细.xlsxUI 测试的 Excel 固定三张表Sheet内容执行概览项目、时间、总数、通过数、失败数、截图目录执行明细每条用例的模块、页面、动作、预期、实际、判定、证据失败清单只保留失败项方便快速评审和提 Bug这个约束看起来很小但对团队协作非常重要。因为测试报告最终要进入飞书字段和 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复杂表单不能靠顺序填表硬跑创建应用、创建模板这类页面字段多、依赖多、下拉多。通用填表逻辑如果只是按控件顺序填很容易误填字段。当前策略是分层层级目标菜单 smoke确认页面可达、表单加载、控件存在CRUD 深测单独写字段语义明确的脚本依赖链路用上游创建数据驱动下游操作坑 3验证码识别不稳定后台登录有验证码验证码输入错误后会刷新。自动化脚本要处理多次识别重试。验证码刷新。登录失败后的状态恢复。Cookie 直接注入和自动登录两种模式。这类问题不是一次就能完美解决需要随着项目环境慢慢沉淀。坑 4Excel 结构不统一会影响协作一开始有的报告叫测试明细有的叫执行明细有的还有 JSON 中间文件。后来统一成执行概览执行明细失败清单并且要求正式交付不再依赖 JSON。坑 5内部文档访问不能只靠“能打开链接”飞书文档、内部博客、项目平台都有访问控制。浏览器能打开不代表 Agent 能读到。需要明确URLcookietoken是否需要客户端证书是否需要特定命令输出格式内部博客这次就是典型例子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 在测试领域最现实的价值不是替代测试人员而是让测试人员从重复的工程动作里抽身出来。它帮我们做这些事把资料读完。把脚本跑完。把截图留好。把失败列清楚。把报告生成好。把资产沉淀下来。而测试人员要做的是继续把控方向、业务判断和质量结论。如果说过去测试自动化解决的是“让机器点页面、调接口”那么测试工程智能体想解决的是更上游的问题让测试活动从分析、执行、证据、报告到沉淀都形成一个可持续演进的工程闭环。