当 Mojtaba Hosseini 帮助指导 Zapier 成为一个更加以数据和指标为导向的工程组织时，当团队继续增加和使用指标时，他发现他们有时会遇到这个问题。我还应该注意和使用哪些指标？

让我们加入 Mojtaba 的另一个嘉宾系列，他将探讨 5 类工程指标，这些指标可以帮助团队实现指标的多样化和平衡化

但首先，打个比方…

想想一个汽车的主仪表盘。

有许多指标和表盘，每个都以不同的方式帮助司机。

• 速度和性能：汽车的速度有多快？发动机的工作强度如何？
• 维护：发动机健康状况，机油和电池健康状况，汽油水平，发动机温度。
• 状态：车门、后备箱、引擎盖开/关，灯开/关，指示灯开/关，手刹开/关。

汽车越复杂，这些类别中的表盘和仪表盘就越多。如果司机只能接触到一个类别，他们可能会损坏汽车（或更糟）。

工程测量的 5 个类别

可以说，工程团队可以使用的指标有 5 类。

客户指标

这些指标主要是衡量团队的客户情况。这个类别的指标包括

• 客户净推荐值(NPS，可以理解为口碑)
• 产品 HEART 指标。幸福感、参与度、采用率、留存率、任务完成率
• 关于我们对客户咨询的反应速度的 SLI 指标

这些通常被认为是一个团队最重要的一些指标，因为它们涉及到团队的客户。然而，这些指标可能是滞后指标，可能无法让团队充分了解客户满意（或不满意）的原因。

团队工作量指标

一些团队发现衡量团队的工作量是很有用的，可以深入了解各种类别的工作量。比如说。

• 参与到 feature 开发工作与非 feature 开发工作的百分比
• 团队的支持工作的负荷及其对整体工作量的影响
• 团队的 bug fixing 工作的负荷及其对整体工作量的影响
• 战术性工作与战略性工作的百分比

这些指标可以帮助团队理解和阐述他们的痛点，甚至有时可以与客户指标联系起来。它们有时也能揭示出团队以外的问题和瓶颈，这些问题和瓶颈影响了团队的工作量。

团队效能指标

如果说团队工作量指标衡量的是团队的工作投入，那么团队绩效指标的目的是看团队在处理工作量方面的情况。比如说。

• 周期时间和吞吐量以及在制品（WIP 半成品）的大小：团队如何处理其工作负荷
• 4 个 DORA 指标：一个团队部署到生产的速度和频率以及这些部署的质量，可以参考这篇文章:https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance
• 团队速度：完成需求的平均速度

这些指标通常是最有可能被管理层错误使用的指标–最糟糕的是被武器化。如果使用得当，它们是团队工作量和客户指标的绝佳配套指标。

服务水平度量

软件团队也可以衡量他们维护的服务的健康状况。比如说。

• 资源使用率（CPU/内存）：服务使用资源的程度，通常在一段时间内查看
• (云）成本：资源的成本（通常会进一步细分），通常会随着时间的推移查看
• 服务正常运行时间：服务正常运行的时间百分比
• 服务错误率：一项服务出错或超时的频率

请看这篇来自亚马逊的文章，关于服务指标的各个层次以及为运营可见性创建仪表盘。https://aws.amazon.com/cn/builders-library/building-dashboards-for-operational-visibility/

请注意，对于一些团队，这些服务指标与客户指标有直接或间接的关系–当客户是服务的直接用户时，甚至可能是客户指标。

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

响应式模式

这是我之前在做前端开发时候每天必用的工具，因为那时候响应式前端框架刚刚兴起，我们都希望用一套代码实现 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 代码直接让引导教程没办法弹出来。另一方面，如果出现的弹框是与业务强相关，那么弹与不弹就是两个用例，分别进行测试就好。

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