11/11 全绿的那次执行，登录按钮其实没被点到这不是假设，是我们平台自己踩过的坑。一条 11 步的登录用例跑出 11/11 passed，截图也在，但最后一步的截图里账号、验证码、条款、登录按钮全都还在——页面根本没变。日志写着「点击 登录按钮 sel=text:登录 270ms pass」。
这段时间，做 GUI Agent 和移动端 Agent 的团队陆续在说同一件事：评测跑完只敢报一个「成功率」，真要定位问题，又得从头翻录屏和日志。共同点是：成功率这个数字，掩盖了失败发生在哪一层。
一、成功率藏了四件不同的事
一个「失败」背后，至少可能是：
- 2. 定位到了，但点错了元素（命中了正文标题而不是按钮）；
- 3. 点对了，但业务没发生（请求没发出去、状态没变）；
- 4. 业务发生了，但没人验证（用例里根本没有断言）。
这四件事的修法完全不同。把它们压成一个成功率，等于把「该改定位器」「该加等待」「该加断言」「产品真有 bug」四种结论混成一个数字。
这也是为什么「成功率」这个数字在评测里特别危险：它把四种修法不同的结论，压缩成了一个百分比。百分比涨了，你不知道是断言补上了，还是把难的用例删掉了；百分比跌了，你也不知道该改元素库还是改产品。评测报告一旦只剩这一个数，它就从诊断工具退化成了排行榜。
二、三层归因：定位、动作、断言
图 1：三层里只有第三层在回答「业务对不对」，前两层通过只说明动作没报错
第一层：定位层。 看候选链走到了第几个、每个候选命中几个。平台现在的规则很硬：命中 0 个就落到下一个候选；命中多个绝不点击，直接报「定位不唯一」，并提示补锚点。因为点错行比失败更难发现——失败至少还会红。
第二层：动作层。 动作返回 success，只代表事件已经派发出去，不代表页面已经变了。这是最容易被误读的一层。
第三层：断言层。 这一步到底验了什么。11/11 全绿的那次执行，每一步都「成功」，但整条用例没有一条「登录成功」的断言——所以登录失败也会全绿。
三、动作层的那个时间差
图 2：click() 返回只用了 26ms，页面真正变化在 461ms——在 26ms 截图，拍到的一定是旧页面
我们实测过一次登录点击的时序：
原来的实现是「动作一 resolve 就截图」，于是截到的是登录页。更隐蔽的是最后一步：中间步骤的跳转间隙会被后续步骤的等待和截图自然覆盖，最后一步后面没有步骤了，页面永远没有机会稳定下来再被拍。
后来改了两件事：每一步成功之后做一次有界的稳定等待（预热 → 等网络空闲 → 静默），循环结束后再补拍一张 result.png 终态截图。失败步骤不等待，保留即时态——错误 toast 比稳定后的页面信息更多。
四、评测报告怎么改
把「成功率」拆成三个可以分别看的数：
特别要盯住一个数：有断言的用例占比。如果 100 条用例里只有 20 条带断言，那 80% 的「通过」只是在说「脚本没崩」。
还有一个容易被忽略的口径问题：分母。算成功率时，失败后被跳过的用例、执行超时的用例、以及根本没有断言的用例，到底算不算进分母？三种算法能得出三个完全不同的百分比。对外报数之前先把分母写清楚，否则同一个版本能报出三个成功率。
五、可照做清单
- 1. 评测报告里把「通过」拆成定位 / 动作 / 断言三层，分别给数。
- 2. 定位命中多个时不要点第一个，直接失败并提示补锚点。
- 3. 动作后先等页面稳定再截图；流程最后补一张结果截图。
- 4. 统计「有断言的用例占比」，低于 50% 就先补断言，别急着扩用例。
- 5. 失败时保存候选链日志：试了哪几个候选、每个命中几个。
- 6. 对「动作应导致状态变化」的步骤，至少加一条能验证变化的断言。
关于怎么把 AI 用进测试流程，我们一直在做这件事，也踩过不少坑。如果这篇对你有用，欢迎转给正在看评测报告的朋友；也欢迎来信聊聊你们的 Agent 评测口径，邮箱 clzc_ai2026@qq.com。
（文中截图为平台演示环境数据）
