最近发现 github 月热门项目里有个老面孔 selenium base 在短期内获得了比较大的关注。

这个项目存在的时间应该有好多年了，我记得当初似乎也写过文章去介绍。

本以为这就是一个普通的结合 pytest 和 selenium 封装的测试框架，不料几年过去项目的发展似乎渐入佳境。

这次最让我眼前一亮的功能是 selenim base 支持绕过 Cloudflare 的访问校验。

新的爬虫利器？

用 selenium 写过爬虫的同学可能都会对 Cloudflare 的访问校验感到头痛。

简单来说，在你访问目标站点的时候，cloudflare 会自动校验此次访问是不是来自不明的 ip 或者设备，如果是用脚本去访问该站点的话，cloudflare 会直接进行拦截，不展示网页的内容。

不过 selenium base 却用几行代码打破了这一桎梏。

from seleniumbase import SB

with SB(uc=True, test=True, locale_code="en") as sb:
    url = "https://gitlab.com/users/sign_in"
    sb.activate_cdp_mode(url)
    sb.uc_gui_click_captcha()
    sb.sleep(2)

用什么工具写爬虫其实无关紧要，爬虫进入深水区的时候往往需要跟反爬策略做各种对抗。

由于 selenium 本身使用了真实的浏览器进行网页访问，自带光环，可以绕过很多的反爬策略。

但是 cloudflare 的前置拦截却一直没有稳定的解决方案，selenium base 提供了绕过校验的便利，看上去非常利好爬虫的发挥。

其他有意思的特性

支持录制

文档在这里。https://github.com/seleniumbase/SeleniumBase/blob/master/help_docs/recorder_mode.md

因为 selenium base 暴露出来的 api 比较有限，所以录制出的代码可用性相对较高。

可以把用例转换成 markdown 的表格模式

这里的路子跟 robot framework 是反着来的。

把代码转成了更容易阅读的表格，对用例评审来说还是很有用的。

https://github.com/seleniumbase/SeleniumBase/blob/master/help_docs/case_plans.md

智能等待

selenium base 的 api 很多都是操作类型的，比如 click,type 之类，在进行操作时 selenium base 会进行智能等待，从而提升用例的稳定性。

最近看到一款新发布的 AI 自动化测试工具 coTestPilot.ai，项目主页在这里。

这是由 Checkie.AI 的测试专家开发的开源扩展，为自动化测试带来了额外的 AI 功能。该项目旨在通过简单集成现有的 Playwright 和 Selenium 测试，使每个自动化工程师都能享受到 AI 给测试带来的便捷。

什么是 coTestPilot？

coTestPilot 是 checkie.ai 和 testers.ai 上可用的 AI 测试 agent 的轻量级版本。它通过利用 GPT-4 Vision 分析网页，为 Playwright 和 Selenium 扩展了自动化测试和缺陷检测的 AI 能力，以识别潜在问题、不一致和可用性问题。

最棒的是，只需添加一个函数调用，就可以为现有的测试自动化添加 AI 驱动的检查。

主要特点

• 多样化测试角色：内置多个测试 agent 配置文件，包括 UI/UX 专家、无障碍专家、安全测试人员等
• 可定制检查：轻松添加自定义测试规则和专门的提示
• 全面分析：识别视觉错误、内容不一致和功能问题
• 详细报告：生成包含屏幕截图和详细问题描述的 HTML 报告
• 速率限制和重试逻辑：内置 API 速率限制保护

为什么使用 AI 测试 agent？

传统的自动化测试擅长检查特定的预定义场景，但常常会忽略人工测试人员会立即发现的意外问题。coTestPilot 通过为自动化测试套件添加一个 AI 驱动的"额外视角"来解决这个问题。 AI agent 可以识别如下问题：

• 元素错位和视觉缺陷
• 内容不一致和拼写错误
• 无障碍问题
• 基本安全问题
• 性能预警
• 用户体验问题

入门指南

以 selenium 的版本为例。

Playwright v1.50.0 引入了多项值得关注的功能和改进，旨在提升测试体验。以下是这些新增功能的详细概述，并附有示例以说明其使用方法。

Runner 增强

1. 步骤超时配置

现在可以通过 timeout 选项为单个测试步骤指定最大运行时间。如果某个步骤的运行时间超过此限制，测试将失败。

示例：

test("example test", async ({ page }) => {
  await test.step(
    "step with timeout",
    async () => {
      // 此步骤必须在 1000 毫秒内完成
      await page.click("#some-button");
    },
    { timeout: 1000 }
  );
});

2. 跳过测试步骤

新增的test.step.skip()方法允许跳过特定的测试步骤，这在某些条件未满足或功能尚未实现的情况下非常有用。

示例：

test("some test", async ({ page }) => {
  await test.step("before running step", async () => {
    // 正常步骤
  });

  await test.step.skip("not yet ready", async () => {
    // 此步骤将被跳过
  });

  await test.step("after running step", async () => {
    // 即使上一步被跳过，此步骤仍会运行
  });
});

3. ARIA 快照存储于单独文件

expect(locator).toMatchAriaSnapshot()方法已扩展，允许将 ARIA 快照存储在单独的 YAML 文件中，便于更好地组织和版本控制。

示例：

test("ARIA snapshot test", async ({ page }) => {
  await page.goto("https://example.com");
  await expect(page.locator("body")).toMatchAriaSnapshot();
});

在此示例中，ARIA 快照将存储在对应的 YAML 文件中。

又又又看到有人发帖抱怨说 postman 太慢了，想找一款可以替代 postman 的工具。这个需求基本上每隔几个月都会被提出来一次。

这里顺手总结一下原帖中提到的解决方案，再加上自己的亲身体验，给大家推荐一些 postman 的替代工具。

反正我坚持认为，postman 只要不登录，速度快点，那么它还是用起来最顺手的 http 请求工具了。

RapidAPI

mac 用户强推了，当年的版本叫 paw，我是花了不少钱买的。现在完全免费了，妥妥的背刺。

https://paw.cloud/

Bruno

开源的轻量 API 测试工具，类似 Postman。

下载地址: https://www.usebruno.com/。

主打一个开源以及个人用户不要钱。

Thunder Client

这个是 vscode 的扩展，很轻量，而且免费，用起来不如 postman 顺手。

Rest Client

同样也是 vscode 的扩展，用着还行。

Hoppscotch

今天才之前 Hoppscotch 的前身是之前我们关注过的 postwoman。

工具地址：https://hoppscotch.io/

建议直接用 chrome 的扩展，跟当年的 postman 一样。

Insomnia

另一个类似 Postman 的 API 工具。

我记得当年是完全开源免费的，现在要收钱了，不过免费的版本完全够用了。

https://insomnia.rest/

Yaak

这个似乎就是 Insomnia 的原作者新写的工具，目前免费。

https://yaak.app/

Jmeter

属于啥都能干，但是体验没有 postman 好了，完全免费，怎么都香。

这确实是个非常值得讨论的话题。

测试人员究竟是不是需要成为 devops 工程师，我的答案是不需要，但又需要。

测试有时候在开发团队会不被开发同事所重视，甚至有时候会背上效率低下的骂名，我认为其中一个很重要的原因是：测试的工程化程度不高。

想想开发的一些核心行为

• 写设计文档和方案：这个工程化程度不算太高，但是如果是写接口文档，那么很多工具都支持从代码生成文档，这个是可以工程化的；
• 搭建本地开发环境和测试环境：可以工程化。
• 写代码：本身代码就是工程化的一环。
• 构建发布产物：可以工程化。
• 发布：可以工程化。
• 监控和告警：可以工程化。

再看测试的核心行为

• 用例编写：很难工程化；
• 用例执行：手工执行用例很难工程化；
• 测试数据准备和清理：可以工程化；
• 提出 bug 并进行跟踪：很难工程化；

我们再看看 devops 的概念，DevOps 将软件开发（Dev）和 IT 运维（Ops）的工作进行整合和自动化，旨在提升并缩短系统开发生命周期。

自动化是 DevOps 中的重要部分。软件程序员和架构师应使用“适应性函数”（fitness functions）来确保他们的软件保持在预期状态。

简单来说 devops 就是运维工程化，而工程化最好的体现就是运维的自动化。

测试需要工程化

测试同学其实可以不用成为专职的 devops 工程师，毕竟这是另一个研发角色，负责的内容和范围也不太一样。

但是测试同学确实是可以借鉴 devops 文化中的工程化思想，让测试变得更具工程化一些。

然而我们看到，核心的一些测试行为确实很难进行工程化，这样一来，我们就需要扩大我们的工作半径，将一切可以提升质量的行为都纳入到我们的工作职责中来，而这一系列的行为里，有一部分是可以进行工程化的。

最典型的可以进行工程化质量实践就是构建 ci/cd 流水线。

测试同学可以通过构建 ci/cd 流水线进行自动化的准出测试，如果对代码库的 precommit hook 进行工程化定制的话，还可以对准入进行控制。

流水线的输入是代码，输出也是代码，其中执行的各种任务也都是代码实现的，所以如果测试同学想要构建一条对质量有所裨益的流水线，那么下面的一些技能还是需要具备的。

• 一定的代码能力
• 一定的工具整合能力，ci/cd 的工具很多，有时候我们不需要开发，只需要接入和定制就好
• 一定的质量规划能力，加什么准入和准出？如何保证各种检查不会拖慢流水线的执行？

小结

简单来说，会代码，有工程化思想，有构建高质量产出物的工具和思路，这类的测试同学应该还是会受欢迎的。

但不要忘了，测试同学的核心任务还是质量保障，ci/cd 只是质量保障的一种实践，而不是质量管理的全部。

其他人的观点

最近看到了一篇文章对测试人员要不要成为 devops 人员进行了讨论，这里顺便放上来，供大家参考。

原文地址: https://visible-quality.blogspot.com/2024/09/do-testers-need-to-be-devops-engineers.html

在我职业生涯的某个阶段，我逐渐专注于理解测试环境。这一切始于观察子系统之间的关联，以及识别哪些数据可以兼容。在保险行业，进行有效测试没有其他选择，尤其是当时一个新的 IBM 大型机测试环境的搭建就耗费了 100 万和一年的时间（我也经历过）。我已经不太记得那时用的货币是芬兰马克还是欧元了，只记得那种对项目的巨大责任感，因为我需要确保这个耗资百万的项目能够顺利进行。那段经历让我从此更加重视测试环境，不仅对工作站、服务器和版本有了更清晰的分类，处理这些事情也变成了日常工作的一部分。

看到了一篇讨论测试和 AI 的文章，有些观点确实是非常正确的，顺手翻译了一下，供大家参考。

我自己读了两遍，发现翻译的版本措辞不够通顺，还是直接给个省流版本好了。

省流

• AI 生成的代码开发可能不理解其中的原理，这就为代码变更埋下了隐患，毕竟代码等于是抄的，改抄过来的东西往往不容易
• AI 每次生成的代码可能风格都不一样，这样用的越多，代码风格百花齐放的可能性就越大，这样在团队协同的时候会带来麻烦
• AI 生成的代码不好维护，集成进现有代码的难度其实很大
• AI 写用例很菜，一些异常情况可能考虑不到
• AI 生成的测试用例是没有测试模型指导的，所以随机性很大，这就导致了用例对功能的覆盖率可能不会很高
• AI 生成的代码可能引入过时的依赖库和解决方案，从而让团队背上了技术债
• 泛化型的 AI 在代码和测试用例生成时可能不会给出最正确的决策，这很好理解，毕竟有些训练数据本身可能质量不高，这就造成了生成的内容质量低下
• 招聘问题。是招会写代码的人还是招会用 ai 的人？

随着生成式 AI 及其对各行各业的影响成为热门话题,我想探讨一下它将如何影响软件测试,主要基于使用这类 AI 可能带来的风险。了解这些新工具的潜在风险,有助于我们获得相关信息,并思考将其融入团队时需要采取的测试策略。

代码质量不如亲自编写

生成式 AI 通过分析互联网上的内容来根据提示创建代码,这意味着你会继承其他开发者的编码风格和特点。这可能导致我们难以理解为我们生成的代码,从而增加维护和继承的难度。另一个风险是我们可能会想当然地认为 AI 按照我们的要求执行,而不去验证(因为代码难以理解)。

这不仅影响产品代码,也会影响测试代码的生成。为应对这个问题,我们可以对代码进行全面的静态分析和重构,以提高其可读性。

编码习惯和风格不一致

与上述情况类似,AI 会采用各种程序员的风格和习惯。这意味着每次要求生成代码时,可能会得到不同的实现方式或编码风格。这同样会影响代码的可维护性和可继承性,缺乏一致性也使问题更难被发现。代码所有权也可能成为问题,因为难以确定是团队中谁的代码。在代码集成方面,不同的编码风格可能难以协调,函数行为可能相互矛盾。

解决方案仍然是进行更多的静态分析和代码重构,以及对函数行为进行基于代码的测试,以确保代码的可理解性和正确性。

更高的维护成本

生成的代码可能难以与现有代码很好地融合,因此我们可能不得不替换而非添加代码。这可能导致现有的代码测试失效,增加代码行为偏离预期的风险。替换现有代码还意味着必须重新测试现有功能,特别是如果我们失去了贴近代码的测试,这将增加测试所需的时间。

对代码(或生成的测试)缺乏理解意味着每次修改代码库时都需要花更多时间进行静态分析。一种应对方法是为测试建立独立的代码库,这样对代码的修改就不会影响测试。测试人员还必须人工审查生成的测试,确保它们与当前的代码库相符。

生成的代码质量如同实习生水平

生成式 AI 创建的软件代码或自动化测试可能只达到实习生的水平。它会完成你明确要求的内容,但可能忽视细节或异常情况。这存在测试覆盖不全的风险,也可能无法发现更深层次的问题。任何不确定性都可能导致 AI 做出与你意图不符的假设,从而影响功能表现。

应对这种情况的方法是确保继续进行探索性测试和人工测试。测试人员不仅要审查生成的测试,还要继续测试 AI 已涉及功能的准确性。我们还必须善于减少不确定性,并以不留任何假设空间的方式记录所有要求,以便输入到 AI 中(不要认为它会有常识并知道失败应该导致错误)。

缺乏测试模型

由于你可能使用简短的提示而非详细的测试用例,你可能对测试覆盖率缺乏心理预期。如果过度依赖低代码或无代码测试工具,我们可能对代码/软件的行为缺乏深入理解。这可能影响软件的可维护性,并可能导致遗漏或错误测试边缘情况和功能。

为应对这些风险,我们需要制定计划来探索代码和功能,以了解其工作原理。这种理解可以用于改进生成的自动化测试,并指导我们知道应该测试什么以及如何测试。

引入不良依赖项导致技术债务

生成式 AI 可能会引入过时的库,这可能导致代码不受支持或无法正常工作。尝试更新生成的代码可能会失败,或者如果 AI 引入了我们不知道会发生变化的库,就存在代码突然停止工作而我们不知原因的风险。AI 使用的库可能存在安全漏洞,如后门或恶意代码,我们必须诊断和修复这些问题。

我们必须确保团队分析所使用的库,并在生成的代码中记录这些库,以便检查其有效性。还需要对所有生成的代码进行静态分析,以测试是否存在漏洞和安全缺陷(包括对 AI 创建的功能进行渗透测试)。

AI 可能做出不直观的决策

所使用的 AI 可能会在创建代码、测试内容或测试方法上做出糟糕的决定。如果代码不直观,我们可能无法从代码中推断 AI 所做的假设。这带来了无法理解或维护代码和测试的风险,以及得到无用的测试或遗漏关键内容的风险。