news 2026/9/1 18:46:46

【获取WebSocket】使用 Playwright 监听 Selenium 自动化测试中的 WebSocket 消息（二）

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
【获取WebSocket】使用 Playwright 监听 Selenium 自动化测试中的 WebSocket 消息（二）

使用 Playwright 监听 Selenium 自动化测试中的 WebSocket 消息（二）

文章目录

  • 使用 Playwright 监听 Selenium 自动化测试中的 WebSocket 消息（二）
    • 六、Selenium 与 Playwright 的生命周期协同设计
      • 6.1 一个常见但不明显的问题
      • 6.2 一个相对稳妥的调用顺序
    • 七、为何需要“按操作切片”的 WebSocket 捕获机制
      • 7.1 问题本质
      • 7.2 基于序号的切片思路
    • 八、WebSocket 消息方向与 Action 字段的处理策略
      • 8.1 抽象消息方向
      • 8.2 关于“空消息”的处理
    • 九、从 WebSocket 消息中提取并统计 Action
      • 9.1 Action 提取与计数
      • 9.2 在测试中的使用方式
    • 十、实现过程中遇到的典型问题与取舍
      • 10.1 CDP 连接失败（ECONNREFUSED）
      • 10.2 关于方案边界的说明

六、Selenium 与 Playwright 的生命周期协同设计

在将 Playwright 引入到现有 Selenium 框架时，真正需要谨慎处理的并不是 API 使用本身，而是两个工具在生命周期上的协同关系。

Playwright 的ConnectOverCDPAsync本质上是一个主动连接行为：
它假设目标浏览器已经启动，并且在指定端口上暴露了 Chrome DevTools Protocol 服务。

如果在浏览器尚未完成启动、或者启动时未正确携带--remote-debugging-port参数的情况下尝试连接，连接失败是一个合理且可预期的结果。

6.1 一个常见但不明显的问题

在测试框架中，以下两段逻辑往往分散在不同层级：

  • Selenium WebDriver 的创建（通常发生在TestInitialize或更底层）
  • Playwright 的 CDP 连接（通常写在测试辅助类或工具类中）

如果不对调用顺序加以控制，很容易出现如下问题：

  • Playwright 连接逻辑执行得过早
  • 浏览器进程尚未监听调试端口
  • 最终表现为ECONNREFUSED

6.2 一个相对稳妥的调用顺序

在本文的实现中，采用了如下顺序：

  1. 类级别初始化（ClassInitialize）

    • 仅生成调试端口
    • 创建 WebSocket 监听器对象（不做连接）

  2. 用例初始化（TestInitialize）

    • 调用base.TestInitialize()，由 Selenium 启动浏览器
    • 浏览器携带--remote-debugging-port
    • 再显式调用 Playwright 的EnsureConnected()

我们必须选择在浏览器已经处于稳定运行状态后再附加监听。

七、为何需要“按操作切片”的 WebSocket 捕获机制

在真实的前端系统中，WebSocket 消息往往是持续产生的，并不严格对应某一个 UI 操作。

例如：

  • 页面加载完成后的初始化消息
  • 心跳包
  • 其他用户触发的协同事件

如果在测试中直接对“当前页面收到的所有 WS 消息”做断言，很容易引入噪音，难以判断精确地对指定的操作进行验证。

7.1 问题本质

测试关注的并不是“页面是否收到过某类消息”，而是：

“某一个明确的用户操作，是否触发了预期数量和类型的 WebSocket 消息”

因此，测试需要一种方式，将消息流按时间切割。

7.2 基于序号的切片思路

在实现中，并未引入复杂的时间戳或异步同步机制，而是采用了一个简单但可控的方式：

  • 为每一条捕获到的 WebSocket 消息分配递增序号
  • 在执行 UI 操作前记录当前序号
  • 操作完成后，仅保留序号大于该值的消息

示例代码如下：

privateList<WsMessage>CaptureCore(ActionuiAction,intwaitMs){varstartSeq=Interlocked.Read(ref_seq);uiAction();Thread.Sleep(waitMs);return_messages.Where(m=>m.Seq>startSeq).OrderBy(m=>m.Seq).ToList();}

这种方式并不能保证“绝对只包含该操作的消息”，
但在大多数前端交互场景下，可以显著降低噪音并提高断言稳定性。

八、WebSocket 消息方向与 Action 字段的处理策略

在 Chrome DevTools 中，WebSocket 消息通常以“方向”区分：

  • 客户端 → 服务端
  • 服务端 → 客户端

在 Playwright 中，这一差异体现在两个事件上：

  • FrameSent
  • FrameReceived

8.1 抽象消息方向

在监听器内部，将方向抽象为字符串标识：

classWsMessage{publiclongSeq{get;set;}publicstringMessageType{get;set;}// Sent / ReceivedpublicstringText{get;set;}}

这种抽象并不依赖具体协议细节，仅用于后续过滤与分析。

8.2 关于“空消息”的处理

在实际观察中，一部分 WebSocket 帧内容可能为：

  • {}
  • 空字符串
  • 不包含业务字段的控制帧

这些消息在多数业务断言中并不具备价值，因此在工具方法中提供了可选的过滤能力：

publicIEnumerable<string>OnlyReceived(IEnumerable<WsMessage>list,boolcontainEmpty=false){returnlist.Where(m=>m.MessageType=="Received").Where(m=>containEmpty||(!string.IsNullOrWhiteSpace(m.Text)&&m.Text!="{}")).Select(m=>m.Text);}

这种设计允许测试在“完整保留原始数据”和“聚焦业务字段”之间进行选择。

九、从 WebSocket 消息中提取并统计 Action

在许多实时系统中，WebSocket 消息的核心语义体现在某个字段上，例如：

{"Action":"EditRecord","Data":{...}}

测试关注的往往不是消息的完整结构，而是：

  • 是否出现了某种 Action
  • 出现了几次
  • 是否符合预期行为模型

9.1 Action 提取与计数

实现上，采用了较为保守的 JSON 解析方式：

  • 非 JSON 或结构异常的消息直接忽略
  • 只在存在Action字段时才参与统计
privateDictionary<string,int>CountActions(IEnumerable<string>messages){varresult=newDictionary<string,int>();foreach(vartextinmessages){if(string.IsNullOrWhiteSpace(text)||text=="{}")continue;try{varj=JObject.Parse(text);varaction=(string)j["Action"];if(string.IsNullOrEmpty(action))continue;result[action]=result.GetValueOrDefault(action)+1;}catch{// 非预期结构，忽略}}returnresult;}

9.2 在测试中的使用方式

vartexts=_wsCollector.CaptureTexts(()=>{UIAction();});varactionCount=CountActions(texts);Assert.AreEqual(1,actionCount.GetValueOrDefault("SelectionChange"));Assert.AreEqual(1,actionCount.GetValueOrDefault("EditRecord"));

这种断言方式的优势在于：

  • 明确表达“期望行为的次数”
  • 对多余或缺失消息都具备可观测性

十、实现过程中遇到的典型问题与取舍

10.1 CDP 连接失败（ECONNREFUSED）

通常由以下原因引起：

  • Playwright 连接过早
  • 调试端口未正确注入
  • 使用localhost导致 IPv6 解析问题

在实现中，采用了以下应对方式：

  • 延迟连接到TestInitialize之后
  • 使用127.0.0.1显式指定 IPv4

10.2 关于方案边界的说明

该方案的目标并非替代 Selenium，也不是尝试“全面接管浏览器调试能力”，而是在既有框架和版本约束下，提供一种可控、可维护的 WebSocket 可观测手段。

在以下情况下，可能需要重新评估方案：

  • 对性能指标有强需求
  • 需要跨浏览器（非 Chromium）
  • 希望统一迁移到 Playwright
版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/8/31 19:05:23

【AI落地应用实战】基于 Amazon Redshift + dbt + MWAA 搭建现代数据栈

一、引言 在当今瞬息万变的商业环境中&#xff0c;数据已成为企业不可或缺的核心资产。面对海量数据&#xff0c;如何高效提取有价值的信息、支撑敏捷决策&#xff0c;成为企业必须应对的关键课题。 传统数据处理方式&#xff0c;如ETL&#xff08;提取、转换、加载&#xff…

作者头像 李华
网站建设 2026/8/31 16:07:23

【量子机器学习实战指南】：VSCode结果评估的5大核心技巧揭秘

第一章&#xff1a;量子机器学习的 VSCode 结果评估在开发量子机器学习模型时&#xff0c;VSCode 作为主流集成开发环境&#xff0c;提供了强大的调试与结果可视化支持。通过插件如 Python、Quantum Development Kit&#xff08;QDK&#xff09;以及 Jupyter 支持&#xff0c;开…

作者头像 李华
网站建设 2026/9/1 18:29:59

如何高效突破408冲刺阶段刷题瓶颈：个性化提分策略

计算机考研408冲刺阶段&#xff0c;你是否面临着"刷题无数&#xff0c;分数不涨"的困境&#xff1f;本文为你提供一套精准诊断、科学配题、高效执行的个性化刷题方案&#xff0c;助你在最后阶段实现分数突破&#xff01;&#x1f4c8; 【免费下载链接】cs-408 计算机…

作者头像 李华
网站建设 2026/9/1 4:53:50

如何快速掌握多模态AI：视频内容理解的技术突破与实践指南

如何快速掌握多模态AI&#xff1a;视频内容理解的技术突破与实践指南 【免费下载链接】awesome-multimodal-ml Reading list for research topics in multimodal machine learning 项目地址: https://gitcode.com/gh_mirrors/aw/awesome-multimodal-ml 还在为海量视频内…

作者头像 李华
网站建设 2026/9/1 18:47:46

【专家亲授】量子计算镜像兼容性测试的8大陷阱与规避策略

第一章&#xff1a;量子计算镜像兼容性测试概述在量子计算系统开发与部署过程中&#xff0c;镜像兼容性测试是确保量子算法、控制软件与硬件平台协同工作的关键环节。该测试主要验证量子计算环境的虚拟化镜像在不同架构、操作系统及量子处理器&#xff08;QPU&#xff09;接口下…

作者头像 李华