测试工程师会不会被 AI Agent 取代，先别急着看演示里生成了多少用例。公开案例给出的答案更朴素：Agent 已经能接手起草、补全和重复操作，到了动态 UI、跨页面状态和关键业务断言，QA 仍要做最终判断。
2025 年 7 月 29 日，CCF TF 第 168 期活动邀请张刚、傅景良和程天阳，围绕 AI Agent 与研发效能展开分享。腾讯广告投放系统的 Web UI 自动化公开实践，还把 AIGC 和流量录制放进同一套方案，用来处理传统脚本编写和维护中的难题。
这些材料没有给出“无人测试”的依据。现阶段更稳妥的做法，是先让模型减少机械工作，再由工程师守住断言和风险边界。
单测更容易提速，因为边界清楚
单元测试通常有相对明确的输入、输出和依赖关系。Agent 可以根据代码与需求描述生成候选用例，补充常见边界值和异常分支，工程师再检查断言是否符合业务语义。
腾讯云开发者社区的一篇实测文章提到，作者连续两个月上手多款主流 AI Agent 测试工具，并把“从需求文档直接生成测试用例”列为一个明确场景。这项能力最实用的地方，是省掉从空白开始写第一版的时间。
生成出来只是第一步。需求里的隐含条件、历史兼容逻辑和异常处理，未必会完整出现在文档中。用例可以由 Agent 起草，关键断言仍需人工校验，尤其不能仅凭用例数量判断质量。
Mock 数据和日志整理也适合采用类似分工。Agent 可以按接口约束生成候选数据，或先对 stack trace 进行归类和摘要。工程师负责确认数据是否合理、异常原因是否判断正确。接入 PR 和 CI 后，这些工作能减少等待，但不应直接替代审核。
UI脚本好写了，验收仍然很难
腾讯广告投放系统选择“大模型加流量录制”，说明 UI 自动化不能只依赖模型理解页面。流量轨迹可以提供已有操作路径，大模型则负责生成和调整脚本，两者配合更接近真实工程环境。
UI 的麻烦在于变化太多。元素位置会调整，页面可能异步加载，弹窗会遮挡按钮，A/B 实验和跨端样式也会改变视觉结果。Agent 即使顺利找到按钮并完成点击，也未必能判断业务结果是否正确。
美团技术沙龙的公开议程列出了“Multi Agent 驱动的 UI 自动化测试新范式”和“UI 缺陷检测—多模态微调实践”。这些议题能说明团队正在尝试多智能体和多模态方案，但仅凭议程还无法判断工具已经成熟，更不能据此省掉人工验收。
像素比对同样会受到页面压缩、机型差异和样式调整影响。正常变化可能触发误报，细小缺陷也可能被忽略。QA 需要决定哪些差异可以接受，哪些变化会影响交易或操作结果。
页面之外，还有一整套状态
资金流、订单链路和库存回滚比单页面测试更难。用户看到的界面只是当前状态，真正需要检查的还包括前置条件、状态转换和失败后的补偿逻辑。
“执行 A 后进入 B”容易写成测试步骤；“B 失败后必须补偿回 A”则依赖完整的业务规则和历史状态。Agent 可以协助跑流程、整理结果，却很难独立决定补偿是否正确、风险是否可接受。
这也是核心断言需要 QA 掌握的原因。脚本跑通只代表操作完成，不能直接证明资金、库存或订单状态符合预期。
放权先看出错代价
风险分层不必做成复杂模型，先判断一次误判会造成什么后果。
- 可以先让 Agent 起草：单元测试草稿、接口用例补全、Mock 数据准备和日志摘要。重点是减少重复劳动，关键断言由人复核。
- 适合人机协作：UI 脚本生成与修复、跨端兼容性测试、稳定性回归。Agent 负责执行、重试和整理结果，QA 设置检查点并处理异常。
- 最终判断留给 QA：资金链路、合规断言、隐私边界和灰度发布。Agent 可以跑数据、对比历史差异、生成报告，验收和发布责任仍由工程师承担。
同一项任务在不同系统里的风险也不一样。结构稳定的配置后台，与频繁改版的活动页，不能采用同一套放权标准。
生成量之外，还要算维护账
评估 AI 测试 Agent 时，不必预设统一的漂亮数字。更值得持续记录的是：
- 一个 PR 从触发测试到得到可判断结果，需要等待多久；
- Agent 生成的用例有多少需要改写、删除或补充断言；
- 页面改版后，脚本失败和误报是否明显增加；
- Token、算力和人工复核成本是否抵消了节省的时间；
- 覆盖率增加后，真正有效的业务断言是否同步增加。
如果生成范围不受控制，用例数量很容易先涨，维护负担也会跟着上涨。刚接入 CI 时，可以先把 Agent 产物设为建议项或非阻断检查，运行稳定后再决定是否进入质量门禁。资金、隐私和合规链路则应保留人工复核。
现阶段，Agent 在测试流程里更适合充当加速层。单测草稿、脚本骨架、Mock 数据和日志整理可以做得更快；动态 UI、复杂状态和发布判断继续由 QA 把关。工具会改变测试工程师的时间分配，线上责任不会随模型调用一起转移。
