selenium 4 的新功能，不是非常惊喜，不过确实比较实用了。

在瞬息万变的网络自动化领域,Selenium 一直是主要参与者。随着 Selenium 4 的发布,其功能得到进一步增强,引入了前沿特性,简化了测试流程并提高了效率。Chrome DevTools 和 BiDi API 的集成不仅增强了 selenium 的技术能力,还为管理自动化项目的经理们带来了战略价值。

Chrome DevTools 协议:深入浏览器自动化

Selenium 4 与 Chrome DevTools 协议 (CDP) 的集成为自动化测试人员开启了无限可能。通过直接与浏览器底层协议交互,CDP 实现了全面的网络和性能监控、控制台日志访问以及高级调试能力。

想象一下,你需要测试应用在不同网络条件下的表现。利用 CDP,你可以模拟各种网络速度,分析应用如何处理缓慢或不稳定的连接。这一功能确保你的网络应用具有韧性,能够为各种网络条件下的用户提供最佳性能。

CDP 还支持以下强大功能:

1. 模拟网络条件: 模拟离线模式、慢速网络等情况,测试应用的适应能力
2. 访问控制台日志: 直接捕获和分析控制台日志,便于调试和验证 JavaScript 错误
3. 性能指标: 收集详细的性能指标,识别瓶颈并优化加载时间
4. 安全测试: 监控和操作 cookie,追踪混合内容等安全问题,验证 HTTPS 配置

启用网络拦截的示例代码:

public class ChromeDevToolsExample {
    public static void main(String[] args) {
        System.setProperty("webdriver.chrome.driver", "path/to/chromedriver");
        ChromeOptions options = new ChromeOptions();
        ChromeDriver driver = new ChromeDriver(options);

        DevTools devTools = driver.getDevTools();
        devTools.createSession();

        // 启用网络
        devTools.send(Network.enable(Optional.empty(), Optional.empty(), Optional.empty()));

        // 添加网络请求监听器
        devTools.addListener(Network.requestWillBeSent(), request -> {
            System.out.println("请求 URL: " + request.getRequest().getUrl());
        });

        driver.get("https://www.example.com");

        driver.quit();
    }
}

在这个例子中,我们启用了网络拦截来捕获浏览器发出的所有网络请求。这对于验证是否发出了正确的网络请求以及调试资源加载问题特别有用。

现在很多测试岗位需要测试同学有 CI/CD 流水线的搭建经验，这里给大家推荐一下常用的 7 大 CI/CD 工具，覆盖了代码管理，ci/cd 集成，静态代码扫描，容器安全扫描，测试用例管理，性能测试等方向，值得收藏。

SonarQube: 代码质量的守护者

SonarQube 是一款卓越的代码质量和静态分析工具。

它通过发现 bug、漏洞和代码质量隐患,帮助开发者维护高水平的代码标准。SonarQube 凭借其直观的界面和全面的报告,确保您的代码库保持整洁和易于维护。

我采访过的许多专家都表示,我会喜欢上 SonarQube,因为它能帮助改进代码并推广良好的编码习惯。

SonarQube 的优点:

• 静态代码分析
• 检测 bug 和漏洞
• 追踪代码质量隐患
• 生成全面的质量报告

目前在 GitHub 上拥有 8.8k 星标。

GitLab: 一体化 DevOps 平台

GitLab 不仅仅是版本控制工具。

我交流过的专家认为,它是一个完整的 DevOps 平台,包含 CI/CD 流水线,为众多团队提供一站式解决方案。此外,GitLab 的集成方式简化了工作流程,增强了开发和运维团队之间的协作。

GitLab 的优点:

• 集成版本控制
• 内置 CI/CD 流水线
• 协作开发环境
• 精简的 DevOps 工作流程

目前在 GitHub 上拥有 5.1k 星标。

Gitleaks: 保护密码信息

在 DevOps 中,安全至关重要,Gitleaks 可以扫描和检测代码中的硬编码密码。这个工具有助于防止 API 密钥和密码等敏感信息意外泄露,提高整体安全水平。

之前写过一篇文章讨论如何去做 hello world 的单元测试，当时想到的一个方法是将 hello world 抽象成 1 个函数，这个函数返回 hello world 字符串，然后测试这个函数的返回值就好了，代码大概如下所示。

def hello_world():
    return "hello world"

前几天看到 rust cli 手册里的一个做法，比上面的方案更加的合理，这里忍不住分享一下。

更优雅的解决方案

测试功能有两种互补的方法:测试构建完整应用程序的小单元,这些称为"单元测试"。还有从"外部"测试最终应用程序,称为"黑盒测试"或"集成测试"。让我们从第一种开始。

为了弄清楚我们应该测试什么,让我们看看我们的程序功能是什么。主要来说,grrs 应该打印出与给定模式匹配的行。因此,让我们为此编写单元测试:我们要确保我们最重要的逻辑能正常工作,并且我们要以一种不依赖于周围任何设置代码(例如处理 CLI 参数)的方式来做到这一点。

回到我们对 grrs 的第一个实现,我们在 main 函数中添加了这段代码:

// ...
for line in content.lines() {
    if line.contains(&args.pattern) {
        println!("{}", line);
    }
}

遗憾的是,这不太容易测试。首先,它在 main 函数中,所以我们不能轻易调用它。这可以通过将这段代码移到一个函数中来轻松解决:

fn find_matches(content: &str, pattern: &str) {
    for line in content.lines() {
        if line.contains(pattern) {
            println!("{}", line);
        }
    }
}

现在我们可以在测试中调用这个函数,看看它的输出是什么:

之前翻译了一版我认为是史上最全的测试 wiki，并把内容作为测试知识库放到了 itest.info，也就是重定向学院的网站上面。

一段时间过去了，前几天我偶然看了一下百度统计里的结果，发现这些 wiki 内容竟然已经有自然流量了，尽管翻译的效果不是很好，但有访问就是好事，可以重点去优先那些大家都在搜索的页面了。

热门内容

我稍微统计了一下，热门的测试知识点有下面几个。

测试规范(测试规格说明书)

可能是这个条目的英文把大家给迷惑了，英文叫做 test specification，直接翻译过来就是测试规范。

大家在工作中遇到一些质量管理的问题时总会想着去学一下别人是怎么做的，有没有好的管理流程和质量规范。

但这个条目的测试规范不是我们所理解的在测试里的准入和准出标准，或者跟流程相关的内容，这里的测试规范实际上是测试规格说明书。它包含下面这些内容。

• 测试范围：明确定义需要测试和不需要测试的内容，确保测试的重点和效率。
• 测试目标：概述测试的目标和目的，提供方向和成功标准。
• 测试标准：指定通过/不通过的标准，包括进入和退出条件。
• 测试环境：描述进行测试时的硬件、软件、网络配置和其他条件。
• 测试用例：详细描述每个测试，包括步骤、预期结果和测试数据。
• 可追溯矩阵：将测试用例与需求关联，确保覆盖和责任。
• 测试交付物：列出测试过程的输出，如报告、日志和缺陷摘要。
• 资源规划：识别测试所需的人员、工具和其他资源。
• 进度和估算：提供测试准备、执行和评估的时间表。
• 风险分析：评估测试过程中潜在的风险，并制定缓解策略。
• 假设和依赖：记录进行测试所需的前提条件或假设。

这更像是描述测试管理理念的终极文档。包含了测试范围，测试规划，测试环境和测试产出等，是个纲领性质的东西。

如果大家有搭建测试团队或者团队管理的需求，可以参考这个条目的内容，我已经重新翻译过了，尽量做到英文内容的忠实还原。

地址: https://www.itest.info/wiki/test-specification

故障注入测试

故障注入测试(FIT)是一种测试人员故意向系统引入错误,以评估其健壮性和错误处理能力的方法。这种技术通过模拟故障来观察系统在意外情况下的表现,确保它能够优雅地处理和恢复故障。

这个条目也是大家热搜的内容，这是因为近年来故障注入的好处越来越被更多人知晓。

故障注入测试的主要好处包括:

• 增强系统稳定性:通过故意引入故障,可以在不利条件下测试系统,确保它能优雅地处理意外情况。

• 提高容错能力:它验证了故障处理机制的有效性,从而打造出更具弹性的软件。

• 系统加固:让系统暴露于故障中有助于识别并加强薄弱环节,降低生产环境中出现故障的可能性。

• 提升可靠性:通过确认系统在故障条件下的正确行为,整体可靠性得到提高。

• 改善风险管理:有助于识别潜在风险及其影响,从而制定更好的缓解策略。

• 主动发现问题:故障注入测试能发现常规测试可能无法发现的隐藏 bug。

• 验证监控和告警:确保监控系统能按预期检测并提醒故障。

• 符合行业标准:某些行业要求验证容错能力,这可以通过故障注入来实现。

• 节省成本:早期发现故障可以节省软件开发生命周期中与停机时间和后期修复 bug 相关的成本。

• 洞察系统行为:它提供了对系统在压力下行为的深入理解,可以指导未来的开发和测试工作。

该条目除了解释了故障注入的原理和概念，还推荐了一些常用工具。

地址: https://www.itest.info/wiki/fault-injection-testing

基准测试

这是在性能测试中经常引入的概念。

我们可以在某个时间点以当时系统的性能作为基准，然后每次发布之前都去做一次性能测试，从而对比系统的性能有没有劣化，如果有的话则要进行修改和优化。

地址: https://www.itest.info/wiki/baseline-testing

背靠背测试

这个我确实不知道，之前也没听说过。

背靠背测试（Back-to-back testing）是一种软件测试方法，它涉及到比较两个不同版本（通常是现有系统）的输出，以验证它们在一系列测试用例下的行为是否相同。这种测试方法在将遗留系统迁移到新平台或重构代码时特别有用，以确保新系统的行为与旧系统一致，同时避免引入回归错误。

经过两个星期的努力，我终于肝完了 playwright 中文站的主要内容。

站点地址 playwright.itest.info

后面我会把精力放到 playwright 的原创教程上去，预计也会在这两周发布吧。

这次技术选型的时候遇到了一些问题，肝到快结束才发现 zola 并不支持中文索引的能力，也就是说搜索功能就没办法实现了。

所以我搞了个全部教程的 archive 页面，大家需要搜索的话可以可以在全部教程页面进行搜索。

目前全站应该更新了 90 篇左右的资料，涉及到 playwright 的基础，框架设计，api 测试以及各种最佳实践，技术含量还是不错的。

在整理和翻译教程的过程中，我自己对 playwright 也有了比较深入的了解，对目前正在写的 playwright 教程的帮助很大，一些实现和配置目前基本上手到擒来，所以建站的过程也是一个非常好的学习的过程，付出和收获是对等的。

另外一些文章翻译的质量不是很高，比如有一篇关于 playwright 视觉测试的教程，英文内容本来是很好的，不过翻译过来之后就显得牛头不对马嘴，我自己理解起来都觉得费劲，所以下周我决定抽时间把这篇教程本地化一下，做一个高质量的视频教程。

因为写了很多爬虫的关系，站点的内容应该会持续更新下去的，后面有机会的话看能不能把之前 selenium 的内容也整理出来，做一个 selenium 的中文教程站，毕竟现在对静态网站的制作也是非常得心应手了。

推荐内容

我精选了一些我认为比较好的内容，我把教程的名字放在这里，感兴趣的内容大家自行去所有教程的存档页面搜索就可以了。

• 如何让 playwright 运行的更快: 非常实用，特别是你的自动化代码足够多的话
• 如何使用 Playwright 监控 JavaScript 控制台日志和异常: 监听页面的pageerror事件，对实时前端页面监控很有意义
• 挖掘 playwright 的隐藏宝藏: 各种最佳实践，量大管饱
• 全面的基于 Playwright 的 ui 自动化测试，使用页面对象模型的模块化框架: 用 playwright+po 实现测试框架
• Playwright: 如何正确使用 fixture 构建页面对象: 使用 fixture 来组织 po，这个实践的工程化水平很高，推荐
• 使用 playwrigth api 测试: 用 playwright 做 api 测试，这一系列教程确实写的很好
• 如何使用组件来重构 playwright 的代码: 在元素之上，page 之下还可以抽象 1 个组件层，代码思想很好

最后

创作内容和维护内容不易，希望这个站点对大家会有所帮助。

我花了一周的时间肝了个 playwright 的教程站，域名是 playwright.itest.info，事情的起因还要从 1 个油管视频说起。

我从那个视频上了解到，1 个做 AI 硬件的公司把 playwright 的自动化操作功能跟 AI 硬件结合了起来，融了 2000 万美金。

这让我大受震撼。

首先我没想到这么高大上的产品竟然用的是如此朴实无华的技术，更让我感到惊讶的是这家公司选择的工具是 playwright，而不是自动化届的老大哥 selenium。毕竟如果从纯技术的角度上考虑，selenium 是在原生浏览器上跑的，它的兼容性其实更好。

看来 playwright 确实是有它独到之处的。

这也让我陷入了思考，可能大部分人学习 ui 自动化工具的初衷不是测试，而是赚钱。

毫无疑问，在 2024 年的今天，playwright 是最有钱景的自动化测试工具，当然了，是金钱的钱。

不过我发现 playwright 的中文资料非常有限，所以我和虫师创建了这个站点，希望可以一直维护下去吧。

关于目前的进度

目前上线的版本有大概 24 篇左右的原创加翻译的资料。

我写了个爬虫去关注 playwright 的最新进展，也爬了 120 多篇非常优秀的英文教程。后面我会持续更新，这样一来资料会更加丰富一些。

除了翻译，我目前主要的精力是放在了原创教程上。在 playwright 可以找到的资料里，大部分的内容都是和自动化测试相关的，这些内容很好，不过我想如果我的教程把关注的重点放在爬虫和自动操作上，那么是不是受众会更广泛一些。

爬虫可以获取数据，在 AI 大行其道的今天，数据是各种大语言模型的基础。

自动化操作可以提升工作效率，在提效这个赛道上，永远是有商机可以挖掘的。

所以我开始肝一套 playwright 的中文教程，可以写的素材相当的丰富，既然要写很多，那么不如就写一本书吧。

目前书籍的进度大概是这样的，typescript 版本应该完成了有 50%了，等肝完 ts 的版本，再花点时间把 python 版本结束掉。

关于网站内容的质量，翻译的文章，我尽量翻译的通俗易通，然而水平毕竟有限，一些翻译的资料中会出现比较神奇的表达，希望大家可以多多指正。

原创的文章我会尽量做到深入浅出，让大家容易理解。

另外 playwright 的 api 变化很快，之前已经过期的内容我这边会人肉过滤掉，尽量保证呈现出的内容是最新的，一些翻译文章里我会加入自己的看法，明目张胆的夹带私货了。

结束掉文本资料的部分后，我会根据教程的内容录制一套 playwright 的视频教程，也会把重点放在爬虫和自动化操作上。