brain - use自动化测试怎么做

用 browser-use 系工具做浏览器自动化测试，最先卡住的往往不是「怎么让它点按钮」，而是跑起来不稳：同样的用例今天过明天挂，失败了不知道是模型判断错还是页面没加载完。这篇给一套脚本组织思路——任务怎么切、断言放哪一层、超时和重试怎么配、失败现场怎么留、用例怎么小规模回归，都是能直接抄进自己项目的做法。

用 browser-use 系工具写浏览器自动化测试，卡住人的通常不是「怎么让它点按钮」，而是跑起来不稳：同一个用例今天过明天挂，挂了还不知道是模型判断错了还是页面根本没加载完。这篇只讲脚本怎么组织——任务怎么切、断言放哪层、超时重试怎么配、失败现场怎么留、跑多大范围才合适，都是可以直接搬进自己项目的做法。

核心思路一句话：能用代码判的别交给模型，模型只干模糊环节，其余靠阶段边界和显式等待锁住。下面按拆解、断言、超时、日志、小回归五块展开，每块都给出动作和判断标准。

先把用例拆成「确定性步骤 + 模型判断步骤」

拆解的目标是让模型碰的环节越少越好。页面跳转、填已知表单、点位置固定的按钮，这些优先用选择器或直接调接口完成，不要塞给模型；模型只负责「找元素」「判断当前页面处于什么状态」这类模糊环节。混合编排之后，同一个用例的抖动会明显下降。

1. 划阶段边界每个用例内部分准备数据、操作、断言三段，段与段之间加显式等待条件，比如元素出现、URL 变化、网络空闲，不要写固定 sleep。
2. 写清完成条件目标描述写成一句话指令加几个可检查的完成条件，条件越具体，模型越知道什么时候该停；含糊的指令会让它在页面上反复试。
3. 按业务域分组用例一多就分组，每组共享同一份登录态和初始数据，减少重复准备的开销，也方便单独跑某一组。

断言分两层：机器能判的别让模型判

断言写法直接决定失败时你看不看得懂。原则是硬断言交给代码，软断言才用模型，并且模型的判定结果要能复现。

• 模型判定用的截图或页面快照要存下来，出问题时能回看它当时看到了什么。
• 软断言的输出做成固定结构，字段固定，别让它自由发挥成一段散文，不然没法统计。
• 硬断言失败不要因为模型说「看起来没问题」就放过。
• 不适用的情况：探索性测试里没有明确预期结果，这时只能靠模型判断，但要降低这类用例在回归集里的权重。

超时、重试与「步数上限」怎么设

不稳定多半是超时和重试配得不对。超时分三层设，重试只对可恢复的失败开放，Agent 必须有步数上限和成本上限，否则它会在一个页面上绕圈。

单步动作超时

设短一点，快速失败，别让一个卡住的点击吃掉整批任务时间

单用例整体超时

覆盖准备到断言的全过程，超过就判失败并落现场

整批任务超时

给足总时长，避免前面几个用例卡死把后面全拖没

步数上限

触发即按失败处理，不能当成功放过

成本上限

按模型请求次数估，超了就停，防止无人值守时烧掉额度

重试的边界要写死在配置里：网络抖动、元素没加载完可以重试；模型连续两次判断不一致、硬断言明确失败，重试没有意义，直接记失败。并发跑用例会推高被测站点压力和触发限流的概率，先小并发跑通再逐步加，具体并发档位和退避做法可以去站内的限流与并发相关页面核对当时的口径。

日志要记什么，失败怎么复盘

日志的目的只有一个：让你不重跑就能定位卡在哪。每次运行至少记下用例 ID、开始与结束时间、模型请求次数、最终状态、失败原因分类，这几项凑齐，才分得清是脚本、页面还是模型的问题。

• 失败现场保存最后一张截图、当前 URL、页面关键文本和最后几步的动作序列。
• 失败原因做成有限枚举，比如找不到元素、断言不符、超时、上限触发、接口报错。
• 按枚举统计哪类占多数，才知道先修脚本还是先修提示词。
• 回放验证用同一份数据重跑失败用例，确认是偶发还是必现，别跑一次过了就下结论。

先跑小规模评测，再谈全量回归

改脚本、换模型、调提示词之后，别一上来就跑全量。挑十几到几十条覆盖面广的用例做冒烟集，几分钟内就能知道有没有整体退化，这套集子里要包含正常路径和已知边界情况，不能全是简单用例，否则通过率会骗人。

换模型或换中转渠道后重点看稳定性而不是单次结果，同一个用例连跑多次统计通过次数才有意义。要复盘具体数字，比如各渠道的响应表现和稳定性情况，可以到站内的检测与评测页面核对当时的记录，别拿别人的一次性结论当自己的判断。一次性验证某个页面能不能操作时，跑单条就够了，不必套整套评测流程。