最近在招聘，3 个测试岗位，1 个 sre 岗位，进展不是十分顺利。

3 个测试岗位里 2 个是正式编制，1 个是外包岗位，sre 岗位是正编。

招不到人的原因其实并不是因为简历不够，相反简历数据还是很可观的。

核心原因还是因为现在招聘的要求比之前行业红火的时候高了很多。

现在就职的公司大概属于三四流公司的水平，比上不足比下有余的类型，反正跟大厂比差距还是很大的。

但哪怕是这种非头部公司，对新晋人员的要求还是有一定门槛的。

对于正式编制来说，需要满足

• 40 岁以下
• 一本学历以上

外包编制相对没有那么严格，只要是正规的全职日本科就好。

对年龄和学历的硬性要求就导致了尽管收到的简历很多，但真正可以通过筛选并进入面试流程的候选人寥寥无几。

相反的，静下心来想一想，从另一方面推测，今年测试人员找工作其实应该非常困难。

原因大概以下几点。

市场不景气

各种公司裁员倒闭的消息层出不穷，市场上真正的需求其实非常疲软，真正放出来的岗位其实非常有限。

企业要求水涨船高

三四流公司都要求一本学历了，这其实是行业从业人员渐进式换血的体现。

之前行业欣欣向荣，英雄不问出处，旺盛的市场需求就造成了很多学历一般专业不对口的候选人可以进入软件测试行业。

但现在市场相对饱和，大浪淘沙加上挤出效应，原先条件一般的从业人员慢慢被市场淘汰，客观上完成了一轮又一轮的洗牌。

测试行业停滞不前

测试行业这么多年来的变化其实相对有限，无论是云计算时期，音视频时期还是 ai 阶段，测试人员的工作性质和范围基本变化不大。

整个行业停滞不前已经很多年了，缺少颠覆性的变化造成了行业本身新需求不足。

另外行业十分稳定也造成了测试人员同质化相对严重，好的背景自然而然就成为了求职的关键。

近期建议

既然寒冬已至，那么还是要有应对的套路的。

• 有工作的同学相对要保持稳健一些，毕竟跳槽之后新东家忽然一夕之间倒闭关门也是有可能的
• 没有工作的同学心态平和一些，多锻炼身体，减少不必要的开销，先苟住，静待春暖花开

最后

顺便发个招聘信息。

• 正编测试，base 重庆/深圳，功能测试为主，希望有一定的工程化能力，20k 左右，oa 或 hr 项目，统招本科，一本，2 人
• 外包测试，base 深圳，功能测试为主，oa 项目，1 人
• SRE 工程师，base 深圳，1 人，统招本科，一本

感兴趣的同学麻烦加下面的群哈。

最近发现 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 万和一年的时间（我也经历过）。我已经不太记得那时用的货币是芬兰马克还是欧元了，只记得那种对项目的巨大责任感，因为我需要确保这个耗资百万的项目能够顺利进行。那段经历让我从此更加重视测试环境，不仅对工作站、服务器和版本有了更清晰的分类，处理这些事情也变成了日常工作的一部分。