自动化测试脚本越来越容易写，测试失败后的定位工作却没有因此消失。
在 Selenium 自动化测试项目中，一个登录用例昨天还运行正常，今天突然失败了。页面停在登录按钮上，脚本抛出 TimeoutException。重新执行几次，有时能通过，有时又失败。
测试人员通常会先检查元素定位、等待时间和页面加载状态。但如果问题出在后端接口返回了 500、JavaScript 执行异常、接口响应被拦截，或者前端拿到数据后没有正确更新页面，反复修改定位器就很难解决问题。
自动化测试失败，只能说明预期没有达成，并不能直接说明故障发生在哪里。
传统 Selenium 自动化测试擅长操作浏览器、验证页面结果。要进一步分析失败原因，还需要采集浏览器运行时的证据，包括网络请求与响应、JavaScript 异常、控制台日志，以及测试执行过程中的关键时间点。
Selenium WebDriver BiDi 为这类浏览器事件采集提供了新的技术路径。结合 AI 对多类日志进行关联分析，测试系统就有机会从“报告哪个步骤失败”，进一步走向“解释为什么失败，以及有哪些证据支持这个判断”。
这对正在从功能自动化转向测试开发、智能化测试的工程师来说，是一个值得落地研究的方向。
一、Selenium WebDriver BiDi 到底能做什么？
传统 WebDriver 采用命令与响应的交互方式：测试脚本发送点击、输入、跳转等指令，浏览器执行后返回结果。
WebDriver BiDi（双向通信协议）在此基础上增加了 WebSocket 通信能力，让自动化程序能够订阅并接收浏览器实时产生的事件，例如控制台消息、未处理的 JavaScript 异常和网络相关事件。它是 W3C 推进的浏览器自动化标准。
两者的区别可以这样理解：
对比维度
传统 WebDriver
WebDriver BiDi
主要用途
操作浏览器、验证页面
在操作之外采集浏览器事件
元素交互
点击、输入、查找元素
继续使用原有交互能力
JavaScript 错误
需要额外的采集方案
可以通过日志事件处理器采集
网络分析
通常需要额外工具或机制
可利用相应的 BiDi 网络能力
AI 故障归因
需要整理外部证据
可以为分析提供更丰富的浏览器证据
需要明确：BiDi 负责提供事件与证据，AI 负责分析证据。 它本身不会自动判断业务故障的根因，也不意味着所有浏览器、所有 Selenium 版本都具备完全一致的网络监听能力。
二、一次登录失败，AI 如何判断问题出在哪里？
假设测试脚本执行登录流程，最后等待首页元素出现，却在 10 秒后抛出超时异常。
如果只看 Selenium 的异常信息，我们只能确定首页元素没有按预期出现。加入 BiDi 事件采集后，可以进一步收集以下信息：
采集内容
关键证据
可以排查的方向
网络请求
请求地址、方法、状态码、耗时
接口异常、请求失败、响应缓慢
JavaScript 异常
错误信息、来源位置、调用堆栈（可用时）
前端脚本执行失败
控制台日志
错误级别、消息内容、时间戳
资源加载、前端运行异常
测试执行记录
当前步骤、操作时间、断言结果
定位异常发生在哪个操作之后
例如，采集到以下记录：
步骤：点击登录按钮
网络请求：
POST /api/login
HTTP 500
耗时：128ms
JavaScript 异常：
Cannot read properties of undefined
最终断言：
首页元素未出现
这时，AI 可以提出一个有证据支持的分析方向：登录接口返回了服务器错误，随后前端代码又因读取未定义的数据发生异常，最终导致首页没有正常展示。
但这还不能证明 JavaScript 异常一定由该接口引起。要确认因果关系，还需要核对请求与异常的时间顺序、业务代码及服务端日志。
如果接口返回的是 401，分析方向就可能转向登录凭证或认证状态；如果接口正常返回 200，但前端仍然抛出异常，则需要继续检查响应数据结构和页面渲染逻辑。
故障归因的关键，是把失败步骤与同一时间窗口内的浏览器事件关联起来，而不是让 AI 单独阅读一条异常信息。
三、从 Selenium 到 AI 故障分析，架构应该怎么设计？
建议将系统拆成五个部分：
图片
第一步：启用 BiDi，采集浏览器运行时日志
以 Java 版 Selenium 为例，官方文档提供了控制台消息和 JavaScript 异常的处理接口。下面的代码演示了基本接入方式。
ChromeOptions options = new ChromeOptions();
options.setCapability("webSocketUrl", true);
RemoteWebDriver driver = new ChromeDriver(options);
// 注册控制台日志处理器
driver.script().addConsoleMessageHandler(log ->
System.out.println("[CONSOLE] " + log.getText())
);
// 注册 JavaScript 异常处理器
driver.script().addJavaScriptErrorHandler(error ->
System.out.println("[JS ERROR] " + error.getText())
);
driver.get("https://test.example.com/login");
这段代码展示的是日志采集的基本入口，并非完整的故障分析框架。实际项目还需要处理事件持久化、监听器生命周期、并发执行隔离和异常捕获。
网络请求采集则需要结合所使用的 Selenium 版本、浏览器及对应的 BiDi 网络接口实现。Selenium 官方文档仍在持续完善相关网络能力，因此上线前应针对目标环境验证支持情况。
第二步：把事件与测试步骤关联
单纯收集日志还不够。
如果一个页面同时发出 20 个请求，其中有 3 个失败，AI 必须知道哪些请求与当前失败的测试步骤有关。
建议每个测试步骤至少记录：
用例 ID、步骤 ID 和浏览器会话 ID。
操作开始时间、结束时间及断言结果。
相关网络事件、JavaScript 异常和控制台错误。
当前页面地址、截图及 Selenium 原始异常。
这些信息统一整理成结构化记录，再交给后续分析模块。
四、AI 如何生成可信的故障归因报告？
当证据准备好后，可以让大模型按照固定结构分析，而不是直接问一句“为什么测试失败”。
建议要求模型输出四项内容：
失败现象： 哪个步骤失败，实际结果与预期有什么差异。
候选原因： 根据现有证据，最可能的故障方向是什么。
证据链： 引用具体的请求状态、异常信息和发生时间。
下一步排查： 建议检查哪个接口、前端模块或服务端日志。
例如，报告可以这样写：
失败类型： 登录流程异常。
候选原因： 登录接口返回 HTTP 500，可能导致前端登录流程中断。
支持证据： 登录请求返回 500；同一测试步骤附近出现 JavaScript 异常；首页断言最终超时。
待确认事项： 检查服务端异常日志，并核对前端异常堆栈，确认两类异常是否存在直接因果关系。
工程实现中，还可以建立规则优先的归因机制：明确的网络错误先分类，明显的 JavaScript 异常再关联，证据不足的情况交由 AI 提出候选原因。这样比完全依赖大模型自由判断更容易控制误报。
五、落地时，测试团队需要注意什么？
第一，不要把所有控制台错误都当成用例失败。 第三方脚本、浏览器扩展或页面已有的告警，都可能产生噪声。需要结合错误级别、来源、测试步骤和业务影响进行过滤。
第二，不要只用 HTTP 状态码判断接口是否正常。 HTTP 200 可能包含业务失败结果，HTTP 500 也需要结合请求上下文和服务端日志进一步确认。
第三，保护测试数据。 请求头、Cookie、令牌、个人信息以及响应正文可能包含敏感内容。交给 AI 分析之前，应进行脱敏、字段筛选和访问权限控制。
第四，AI 结论必须保留证据。 不应让模型直接修改测试脚本、忽略失败断言或自动关闭缺陷。对于低置信度结论，应明确标记为待人工确认。
六、Selenium 自动化测试的下一步
过去，自动化测试报告通常告诉我们哪个用例失败、哪一步超时。加入 WebDriver BiDi 后，测试系统可以进一步获取浏览器运行时的网络、日志与脚本异常信息，再结合 AI 进行跨事件关联分析。
对测试开发工程师来说，这项实践的价值不在于增加一个 AI 接口，而在于建立一套可采集、可关联、可追溯、可验证的浏览器故障诊断机制。
当失败证据足够完整，AI 才有条件帮助测试人员缩小排查范围；当证据不足时，系统也应该明确告诉工程师还缺什么，而不是给出一个听起来合理却无法验证的答案。
这才是 Selenium 自动化测试从“执行与报错”走向“辅助诊断”的工程基础。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
