在软件系统领域，熔断器就像守护天使一样，防止级联故障的发生。这篇博客文章深入探讨了这些守护者在各种场景下的细致测试，探索了加强应用程序抵御故障和失败的重要实践。加入我们，一起踏上测试场景、容错性、集成、性能等方面的探索之旅吧！

理解熔断器

本质上，熔断器模式是一种设计策略，用于分布式系统中屏蔽应用程序免受故障的连锁反应。类似于电气熔断器在发生故障时中断电流通路，其软件对应版本通过停止向故障组件或服务发送请求来保护系统。

想象一下，系统中单个组件发生故障，引发多米诺骨牌效应，使整个应用程序崩溃。这就是熔断器发挥作用的地方，它作为哨兵检测异常并隔离故障组件。通过这样做，它防止故障在整个系统中蔓延，允许应用程序的其他部分继续运行。

为了使这个概念更加具体，请考虑您家里的电气系统。当出现电涌或故障时，电气熔断器会中断电流通路，防止损坏您的电器。同样，在软件世界中，熔断器作为保护屏障，隔离故障并确保整个系统的完整性。

QA 自动化工程师的作用

熔断器作为系统弹性的守护者，必须经过严格的测试才能有效地完成其任务。QA 工程师（我们）带着必要的工具和方法进入这个领域，以验证熔断器在各种场景下的功能和响应。我们的角色超越了传统的测试；我们是保证的架构师，为潜在的系统故障构建盾牌。

软件应用程序的可靠性是用户满意度的基石。我们精心设计和执行模拟真实世界的测试场景，将熔断器推到极限。通过这样做，我们确保当系统遇到压力、故障或意外事件时，熔断器能够精确响应，减少对整体用户体验的影响。

一个有弹性的系统必须能够优雅地处理故障并无缝恢复。我们设计和执行测试，仔细检查嵌入在熔断器中的容错机制。我们安排组件故障场景，验证熔断器是否隔离了问题，允许系统优雅地恢复。

测试场景

当我们深入熔断器测试领域时，阐明这些沉默守护者发挥作用的各种场景，加强应用程序抵御潜在中断，是非常重要的。让我们解开常见场景，深入研究我们用来验证熔断器有效性的特定测试用例。

熔断器常见场景：

• 服务中断：
  • 场景：模拟关键服务发生中断的情况。
  • 目标：验证熔断器是否能迅速检测到服务故障并隔离受影响区域，防止级联故障在整个系统中发生。
• 高延迟：
  • 场景：在系统组件之间的通信中引入高延迟。
  • 目标：评估熔断器如何响应增加的响应时间，确保它及时介入以防止整体系统性能下降。
• 资源耗尽：
  • 场景：创建导致资源耗尽（例如，内存、CPU）的条件。
  • 目标：评估熔断器识别资源相关问题和保护系统免于潜在崩溃或性能下降的能力。

熔断器功能特定测试用例：

• 阈值验证：
  • 测试用例：验证当失败数量超过预定义阈值时，熔断器是否激活。
  • 目标：确保熔断器对不断升级的失败数量做出积极响应，防止对整个系统产生广泛影响。
• 平滑降级：
  • 测试用例：有意降低组件的性能，并验证熔断器如何处理这种情况。
  • 目标：确认熔断器是否介入隔离性能下降的组件，允许系统其他部分以最小的中断运行。
• 恢复时间评估：
  • 测试用例：触发故障并测量熔断器允许流量恢复所需的时间。
  • 目标：评估熔断器在故障解决后迅速恢复正常运行的效率。

容错与恢复：熔断器的守护之力

在熔断器测试的复杂世界中，让我们聚焦两个关键方面：容错性和恢复机制。熔断器犹如警惕的守护者，在应用程序面对故障时发挥着不容小觑的作用。

容错性是系统在出现故障或失败时仍能继续运行的能力。熔断器能够检测和隔离故障组件，是增强应用程序抗干扰性的重要手段。通过迅速控制问题，它们可以防止单个故障演变成灾难性的系统崩溃。

当故障发生时，熔断器中嵌入的恢复机制就会启动，负责将系统恢复到正常状态。这些机制可能包括自动重试、回退机制或受控地重新引入之前被隔离的组件。其目标不仅是防止级联故障，而且要促进系统性能无缝恢复到最佳状态。

在细致的测试过程中，我们扮演着验证这些恢复机制有效性的关键角色。通过有针对性的测试场景，我们评估熔断器从故障中恢复的良好程度，确保恢复过程不仅迅速，而且能保持应用程序的整体完整性。

我们关注的关键验证点：

• 恢复时间
  • 测试用例: 验证熔断器在故障解决后能迅速恢复。
  • 目标：评估恢复机制在最小化停机时间和恢复正常运行方面的效率。
• 数据完整性
  • 测试用例: 测试数据完整性在故障和后续恢复过程中可能存在风险的场景。
  • 目标: 确保熔断器的恢复机制保持数据一致性和完整性。
• 回退机制
  • 测试用例: 评估当主组件仍然不稳定时，熔断器如何顺畅切换到回退机制。
  • 目标: 确认回退机制提供可靠的替代方案，防止服务长时间降级。

集成测试

应用程序很少单独存在，它们通常依赖外部服务或 API 来实现特定的功能。集成测试是确保这些互连组件协同工作的关键。对于熔断器而言，测试它们与外部实体的交互对于保证系统整体弹性至关重要。

我们设计测试场景，在其中与外部服务或 API 等集成组件遇到故障。模拟这些故障是一门细致的艺术，涉及注入故障或操控响应以模拟真实世界的情况。这种方法使我们能够观察到当外部依赖项出现故障时，熔断器如何响应。

集成测试场景示例

• 服务不可用：
  • 测试用例: 暂时使外部服务不可用。
  • 目标： 验证熔断器是否识别到不可用性，并激活以防止故障在系统中传播。
• 延迟峰值：
  • 测试用例: 引入集成 API 的响应时间突然峰值。
  • 目标： 评估熔断器处理增加延迟的良好程度，确保其介入以保持应用程序的整体响应性。
• 间歇性错误：
  • 测试用例： 在外部服务的响应中引入间歇性错误。
  • 目标： 验证熔断器是否能有效识别和隔离间歇性错误，防止对系统产生连锁反应。

作为集成架构师，我们精心设计和执行这些测试，细致地检查熔断器在各种集成场景下的行为。通过这样做，我们可以确保熔断器成为弹性的守门员，保护应用程序免受外部依赖项不可预测的影响。

最近看到一篇关于 mock 的文章，觉得挺有道理的，，简单总结分享一下，原文在这里：https://levelup.gitconnected.com/why-mocks-are-considered-harmful-b4e8fe60478d。 文章的观点很简单，就是 mock 其实是弊大于利的。

自动化测试涉及到很多技术，其中 mock 技术我们应该尽量避免使用。mock 用的好其实也只是锦上添花，用的不好的话则会给你带来一些过度的自信。

首先看下什么是 mock。mock 其实就是模拟代码中的一些外部访问行为，比如访问第三方的付款 api 或者是对数据库进行访问，这会给单元测试带来一些好处

• 运行加速，因为你不需要访问额外的服务；
• 提升稳定性，第三方服务提供商的一些不稳定因素被规避掉了

不过 mock 是为一些具有副作用的代码服务的，也就是说这些代码其实是依赖于外部服务，并不是依赖于各种参数的输入。我们可以把函数分成两类

• 纯粹的函数：没有外部依赖的函数
• 不纯粹的函数：有外部依赖的函数

mock 带来的问题

mock 不等同于其替换掉的服务。

比如你把代码中数据库访问的部分给 mock 掉了，这意味着你的代码可能会在有 mock 的时候工作良好，然而你还是需要进行集成测试以确保在没有 mock 的时候也可以正常工作。

不可能进行特性平替

如果你使用的是简单的 mock 方式，那么 mock 可能不会返回一些有用的数据，你花在 mock 上的时间越多，mock 返回的 data 可能会约实用。然而 mock 不能平替被 mock 系统的方方面面。

开发了 mock 但不使用其实就是浪费时间

如果你开发了数据库的 mock 但从不使用的话，这就是浪费时间了。在现实世界中这是很有可能发生的，因为代码可能需要获取一些真实配置去做初始化，而 mock 的时候却很难满足这一条件。

如何去找到 mock 的替代方案

很简单，就是重构代码，把代码重构成纯粹的函数和不纯粹的函数两种，纯粹的函数是不需要 mock 就可以测试的，，不纯粹的函数则可以通过集成测试来进行验证。

举个例子

def logic():
    x = addition(1, 3)
    y = multiplication(2, 4)
		z = x + y
		database_write(z)
    return

上面的函数就是不纯粹的函数，因为其访问了 db，然而我们还是可以把这个函数重构成 1 个纯粹函数和另一个不纯粹的函数

一句话解释 xss 就是通过提供恶意的用户输入让浏览器执行恶意的 JavaScript 代码。

最简单的例子

<div>
    <h1> Welcome {your input} </h1>
</div>

这里页面希望你通过文本框输入自己名字，然后把你输入的名字展示出来。假如你输入的名字是:<script>alert('XSS')</script>

这时候浏览器将解析下面的 html 代码

<div>
  <h1>
    {" "}
    Welcome <script>alert('XSS')</script>
  </h1>
</div>

script 标签里的 js 代码就被执行了，这就是一个最简单的 xss。

复杂一点点的例子

<div>
    <h1> Welcome <input value="{your input}"</h1>
</div>

这时候如果你输入<script>alert('XSS')</script> 那么将得到类似下面的结果

<div>
    <h1> Welcome <input "<script>alert('XSS')</script>"</h1>
</div>

因为 script 标签被包含在双引号里，浏览器会认为这是一个普通的字符串，所以不会执行 js 代码。不过如果你输入“"><script>alert('XSS');</script>” 那么你将会打开一个新的局面

<div>
    <h1> Welcome <input ""><script>alert('XSS')</script></h1>
</div>

input 标签被强行闭合，script 标签成功上位。这时候 js 代码又可以执行了。

再来个例子

<script>document.getElementsByClassName('name')[0].innerHTML='{input}';</script>

这个例子里我们要想办法在现有的代码中插入恶意的 js 代码，这里需要用到 2 点小知识

• js 代码中;号可以结束一行语句
• js 代码中//表示后面的所有内容都是注释，可以被忽略掉

因此如果我们输入的是';alert('XSS');// 那么中间的 alert 语句是可以执行的

<script>
  document.getElementsByClassName('name')[0].innerHTML='';alert('XSS');//'
</script>

前面的单引号被第 1 个单引号匹配并终结，后面的分号直接结束了这一句，而后面的那个单引号则被// 注释掉了，所以中间的 alert 代码是可以顺利执行的。

当 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

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

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