今天我将谈论浏览器技巧——你甚至可能没有意识到这些小功能的存在，主要是在浏览器的“开发者工具”部分。 这些不是关于代码，而是使测试更容易一些的方法。

响应式模式

这是我之前在做前端开发时候每天必用的工具，因为那时候响应式前端框架刚刚兴起，我们都希望用一套代码实现 pc 端和移动端的统一体验。这个工具是 chrome 和 firefox 上的轻量手机模拟器，可以模拟网页在不同设备上的显示情况。在 Firefox 中，它是 Tools->Web Developer->Responsive Design Mode，而在 Chrome 中是 View->Developer tools，然后单击设备工具栏 - 看起来像全尺寸屏幕旁边的移动设备图片 . 单击后，您将看到 chrome 认为该网站将如何显示在设备上。

自己编辑网页

如果您发现前端错误，你可以直接编辑页面上的 html 代码，并查看是否修复了错误。 以 chrome 为例，就是这样：

打开开发者工具，选择第一个 tab 页也就是 Elements，选择你想要编辑的 html 代码， 在左侧会有三个点，单击它们会出现一个包含“Edit as HTML”的菜单； 然后您可以编辑元素本身。 当您按 ENTER 或 RETURN 时，网页就会发生变化了。

这意味着你可以做的不仅仅是查找错误，而是实际提出修复方案。 这样依赖测试是开发团队的一个完全参与的部分了，从辅助变成了输出。

离线模式

有时候我们会希望测试一下网页在弱网甚至是断网时候的表现，直接关 wifi 或者拔网线的话其实挺麻烦的，这时候离线模式就派上用场了。

以 chrome 为例，打开开发者工具，选择 Network 标签，紧挨着的下面一行有个默认是"No throtting"并且旁边带个小三角箭头的东西，这其实就是个下拉列表了，点开可以选择"Offline"，如果你想模拟弱网的话，还可以选择"Slow 3G" 等选项。

javascript 控制台

这个控制台里可以执行任意的 js 代码，最有利的一点是我们可以在控制台里直接写代码去调用后端接口进行调试，之前阿里内部员工抢月饼的脚本应该就是在控制台里运行代码去实现的。当我们学会操作 dom 之后，我们还可以直接用控制台写代码去实现一些页面上的简单自动化，提高我们的测试效率。

修改文件的保存路径

在 Firefox 中，在首选项下，你可以看到下载的位置选项。 如果您像我一样，每天可能会保存数十个文件，那么将它们直接放在桌面上将为您节省两次点击。 这样一天就是五十次点击，也许一周会节约一两分钟。 这样你在花时间阅读我这篇文章时候就不会感到内疚了。

原文地址：https://medium.com/geekculture/five-cs-of-a-test-engineer-59f0f74049d8

简单来说，优秀的测试工程师应该具备下面的 5 种特质，因为对应的英文单词都是 c 开头，所以可以简称为 5c 特质。

Critical Thinking

批判性思维。

这是经常被人忽视的点，测试同学经常需要收集信息，对多个渠道的获取的信息进行整合和判断，具有批判性思维可以让我们理性清晰的思考，了解信息之间的逻辑性以及对业务和用户的造成的影响。

Communication

沟通。

这点是毋庸置疑的了，如果无法进行高效的沟通和表达，那么发现再多的缺陷和问题都没什么大用处了，测试工程师往往是杰出的沟通者。

Collaboration

协作。

测试同学一般不会孤立的工作，或者这样说，不应该孤立的工作。我们是团队的一员，大部分时间都在与开发人员和产品人员通力合作，同时收集有关业务规则和上下文的知识。因此，协作便成为了测试工程师为团队带来贡献的日常基本技能。

Creativity

创造力。

创造性和跳出条条框框进行思考是一种技能，它经常让我们找出那些可能会对整个产品产生巨大影响的不受欢迎的边缘情况，从而提升我们的自身的影响力，而影响力则在高级测试工程师所具有的独门技能中排名第一。创造力可以理解为不走寻常路，独辟蹊径的能力，在探索性测试的时候非常关键。

Coding

每个测试工程师都需要具备表达和阐明业务规则并轻松为其进行领域建模的技能。他们是将实际用例和业务逻辑转换为代码的专家。

综上，不过这几个技能套在开发同学身上也能行得通，可以这么认为在软件相关的行业，优秀的人才往往具备一些共性的特质，而这些特质是可以通过工作和学习进行培养和训练的。

之前看到一篇文章比较系统的比较了 playwright 和 cypress，这里简单翻译了一下，希望可以给大家在技术选型时提供一些参考。原文地址在这里：https://applitools.com/blog/cypress-vs-playwright/。文本中的演示代码可以在 github 仓库找到：https://github.com/applitools/webinar-cypress-vs-playwright

第一轮：元素操作

首先从最常见的场景进行比较，看看最简单的流程。

这是一个简单的登录场景，初相见感觉是差别不大，不过 cypress 显得更加简洁一些。在用户投票中，cypress 以 61%的得票胜出。

第二轮：如何对 iframe 进行测试

尽管 iframe 的测试在日常的工作中并不是特别常见，不过 iframe 的处理对 qa 来说确实是一件非常有挑战的事情。实际上 cypress 需要引入插件才能进行处理，所以可能在这一轮 playwright 会稍微占据一些优势。playwright 原生支持对 iframe 进行操作，省去了额外安装插件的工序。

第三轮：等待与重试

因为现代 web 页面的特性，等待与重试成为了自动化测试工具非常重要的一种能力。参赛双方都有自动等待和重试的机制，直接看代码吧，在用户投票中这一轮 cypress 以 53%的选票获胜。

第四轮：处理浏览器的原生 alert

鉴于每个工具的不同设计，看看它们各自如何处理本地浏览器事件是很有趣的事情。Playwright 使用 websocket 服务器与浏览器进行通信，而 Cypress 则被注入到浏览器中，并从那里实现应用程序的自动化。处理本地浏览器的事件可能会更复杂，在这一轮比赛中也证明了这一点。虽然 Playwright 对警报和提示显示了一致的解决方案，不过 Cypress 对所有三种情况都有自己的解决方案，最后 Playwright 在本轮比赛中取得了 91%的横扫胜利。

翻译了一篇Limitations of API-only testing: Why it shouldn’t be your sole testing strategy，这篇文章的核心观点是讨论为什么不能只做 api 级的测试，挺有道理的，适合泛读以及扩充观点库。

前几天我收到了一篇独特的文章，它提出了一个大胆的观点：“API 测试比 UI 测试更好”。在软件世界中，像“A 比 B 更好”这样的绝对陈述很少成立。“这取决于”才是大多数技术问题的答案，因为有原因。

让我们比较 API 和 UI 测试，并讨论为什么一个不如另一个。这两个方法是“敌人还是朋友”，但永远是不同的。这很好。

API 测试和 UI 测试——两种截然不同的挑战

当你比较 API 和 UI 测试并说一个更好时，这句话背后是什么？人们经常比较这两种测试方法的可扩展性、稳定性或可维护性。然而，这些比较都没有价值，因为 API 和 UI 测试非常不同。

根据我的经验，这些比较的基础总是相同的：API 测试比 UI 测试更容易维护。让我们深入研究一下，看看为什么这并不重要！

API 测试易于实现

API 测试比 UI 测试更容易维护的说法是成立的。在最简单的形式中，你甚至可以用你喜欢的编程语言编写一个 50 行的脚本，对本地或暂存环境进行 HTTP 调用，并解析 JSON 来评估响应是否正确。使用 HTTP 并不难。你甚至可以使用一些 shell 魔法来连接请求并将脚本并行化，以单个命令覆盖整个 API 表面。

很快，你会意识到你需要测试报告、合适的测试运行器和高级测试断言。此外，没有人知道如何处理你自制的测试脚本。因此，你将转向 Postman 或类似的工具。恭喜你！现在，你可以创建 HTTP 请求并测试整个 API 表面。而且可以扩展！这很棒！

自动化用例的尺度到底怎么拿捏，每个测试团队或者每个人都有自己的想法和方法论，今天看到一篇文章以处理弹框为例比较详细的讨论了这个问题，觉得跟我的思路很接近，这里拿出来分享一下。原文地址：https://responsibleautomation.wordpress.com/2023/01/31/should-test-automation-just-handle-it/

在文章里作者列举了几个场景

• 有时我们收到这个弹出窗口，所以我们检查一下它是否在那里。如果有，我们就点击 “取消”，然后继续。
• 有时我们得到一个网页，上面写着 “系统不可用”，所以我们就点击 F5，然后继续，因为这只发生在 QA 环境中。
• 有时，应用程序让我们在支付过程中二次登录。

碰到这些情况，自动化脚本应该如何处理？

从技术上讲我们始终是可以用代码处理这些情况的，不过核心的问题是，遇到这些突发情况，我们是要断言用例成功与否，还是写代码去 pass 这些细枝末节？有时候这类问题确实很困扰。

作者把这些问题分为两类

• 对业务没影响的，可以容忍的问题
• 不可容忍的问题

可容忍的问题

作者举了个例子，他们的 ios app 在进入的时候会弹框，要求用户授权定位和通知权限。遇到这种情况，脚本是直接点掉还是返回错误呢？作者表示他们也不能做决定，最后通过跟客户讨论，客户认为这种问题可以忽略，所以他们最终的策略是点掉，继续后面的流程，这就是可容忍问题的例子。

不可容忍的问题

还是上面那个 app，一些情况下用户没有配置签名会弹出提示框，要求提供签名后继续，这种问题直接影响到了业务流程，就是不可容忍的问题，在这种情况下进行断言会比较好，因为没有签名后面的业务流程都走不通了，应该当做一个异常用例来进行专门的测试。

总结

作者给的例子都是弹框的，确实很少见到有人专门写东西来讨论弹窗的处理，简而言之一些弹框跟业务无关，那么就直接点掉或者不让它弹。比如之前我在写 wordpress 用例的时候，打开编辑器后总会出现全屏的用户引导教程，页面上所有文本框都没办法进行输入，我这时候认为新手教程不影响业务的核心流程，所以用了一些 js 代码直接让引导教程没办法弹出来。另一方面，如果出现的弹框是与业务强相关，那么弹与不弹就是两个用例，分别进行测试就好。

另外除了弹框，还有一些处理也可以分类来探讨。比如测试环境下超时时间调长一点，加载不出来就刷新一下，这种问题再测试环境是可以容忍的，不影响主业务和流程。

之前介绍过一个使用 chatgpt4 分析 dom，然后生成 puppeteer 代码进行自动化的测试工具 Taxy AI。今天发现有人推荐了一个使用 chatgpt4 生成 playwright 代码的测试工具BrowserGPT，稍微看了一下，原理比较简单，比较适合我们去研究一下，顺便打开思路。

演示动画

具体使用

因为我没有 chatgpt4 的 key，所以没办法直接上手使用，只能通过文档去猜测一下具体用法。

BrowserGPT 设置了 openai 的 key 以及 start url 之后就可以在命令行里运行了，大致的使用方式是输入一些自然语言，然后 BrowserGPT 执行 AI 生成的 playwright 代码，实现自然语言自动化的功能。

go to hn
click on the abc article

比如上面的一些描述就实现了去 hacknews 网站点击 abc 这篇文章的功能。

原理分析

大致看了一下，执行的流程是这样的，代码在这里

• 获取初始化的 url，打开 chrome 浏览器，跳转到这个 url
• 在命令行里启动 prompt，也就是给用户一个输入的 ui
• 初始化 openai 的 api
• 写个死循环，每次用户输入之后调用doAction函数
• 在doAction函数里简化当前页面的 dom 元素
• 将简化过的 dom 元素传给 chatgpt，让 gpt 根据 playwright 的示例生成代码
• 执行 chatgpt 生成的代码

这里最有意思的部分是doAction函数