AI Agent 网页操作测试：四层验证与指标

在演示环境里跑通一次，和这条链路能不能天天用，是两件事。

要做判断，只能把测试拆开：环境那一层归环境验，Agent 那一层归 Agent 验，最后再看两者接起来稳不稳。

单步冒烟：四件事各做一遍

冒烟测试只做四件事，而且一件一件单独做，不要串起来：打开一个指定页面；在页面上定位到某个元素；点下去；把该元素的文本取回来。四件都过，说明连接、会话和元素访问这三件基础设施是通的。

只做四件的好处是失败面很窄。打开页面失败，多半是网络出口或访问权限的问题；能打开但定位不到，通常是页面还没加载完就去抓，或者定位方式过于依赖当前布局；能定位却点不动，看元素是否被遮挡、是否在 iframe 里；取回的文本是空的，先确认取的是渲染后的内容，而不是初始 HTML。

这一段要盯三个数：单步成功率、单步耗时、报错类型分布。它们在冒烟阶段就该稳定，如果单步成功率只在八九成上下浮动，后面的测试没有意义。

多步任务：分支比步骤数更关键

把刚才的四步串成一条真实任务，比如填一份表单、翻几页、按条件筛选、把结果写回本地。步骤变多只是量变，真正的难点是分支：中途弹出提示、目标元素消失、页面主动跳转、撞上需要人工确认的验证环节。

这里看的是任务完成率，不是步骤成功率。失败之后能不能自己调整路径，能不能判断什么时候该停下并明确报出来，比能否跑完全程更重要。

还有一个容易被忽略的数字是人工介入次数。同一个任务跑二十遍，介入过几次、每次卡在哪一步，比总体完成率更能说明这条链路的成熟度。

并发与异常注入

单条链路稳定之后，再叠并发。同时拉起多个环境跑同一类任务，看两件事：环境之间是否互相干扰，以及失败率是否随并发数上升而恶化。这个阶段出现的失败，往往不是 Agent 逻辑写错了，而是资源或会话层面被挤到了。

异常注入是最容易被跳过的一类测试，也是最需要做的一类。超时、元素中途消失、会话过期、验证码出现，这几种情况都要人为造出来，观察链路怎么反应：超时之后是重试成功，还是卡死不动；会话过期之后是明确报错，还是带着失效的凭证继续往下跑。

指标记三个：并发下的失败率曲线、异常发生后的恢复成功率、单次异常带来的额外耗时。恢复成功率低，说明这条链路只能跑顺风局。

环境那一层要单独验

上面的测试都在一个环境里完成，但多个环境放在一起时，还得单独验一层：每个环境要能独立启动，独立持有自己的会话与缓存，独立绑定出口 IP。

多账号运营的团队通常会把环境按账号拆开管理，PurpleMark 这类工具提供的就是环境隔离，给每个账号一份独立的运行空间。测试时的做法是并发启动若干个环境，确认彼此之间的 Cookie、缓存和出口没有串。

对环境这一层，看三个数：环境启动成功率、环境之间的数据串扰（正常情况下应该是零）、环境重建之后会话能否延续。

失败之后怎么归因

链路出问题的时候，最容易犯的错是直接去改 Agent 的脚本。更合理的顺序是先确认环境能不能起来、会话有没有过期，再看网络出口和节点是否正常，最后才怀疑 Agent 的元素定位与任务规划。顺序反了，就会在错误的地方反复改。

单步冒烟那四件事，其实也是归因工具。任何一次失败，都先回到这四件事上单独跑一遍，看是哪一环先断开。多数时候答案在这一步就出来了。