最近看到一篇文章是关于软件测试与节能减排的讨论的，可持续发展这个观点在西方国家目前经常被拿出来探讨，因为这与气候变化等的人类世问题关系非常密切。把这篇可持续软件测试：为更绿色和更高效的未来制定 5 项策略 简单翻译了一下，里面还是有很多中肯的建议的，一些看法其实与效能提升关系密切，毕竟效率提高了，消耗和浪费可能会有所减少。

背景

在技术进步与进步同义的时代，软件开发的生态足迹往往被忽视。

• ShiftProject 的一项研究估计，2018 年信息和通信技术(ICT)行业的碳足迹约占全球温室气体排放的 2-3%。
• 彭博社预测，到 2030 年，IT 系统将占全球能源需求的惊人 20%。从这个角度来看，交通运输业目前占全球能源消耗的 25%。
• 根据国际能源署(IEA)的数据，2018 年数据中心在全球消耗了约 200 太瓦时(TWh)的电力。

绿色软件开发的出现宛如灯塔，提供了一种转向生态友好实践的范式转变，与全球对可持续发展的迫切呼吁一致。这种方法不仅仅是一个流行语，它呼吁在软件生命周期中致力于资源效率、减少能源消耗和全面考虑环境。

通过优化软件测试流程中的资源利用和能源需求，组织可以降低整体测试成本。对于大型测试项目来说，这可以节省大量的资金。此外，测试过程变得更加高效和流线化，从而实现更快的交付周期和更短的上市时间。

目标很简单：优化测试策略和自动化实践，以节省资源，从而节省能源。

以下是 5 项策略，可立即在您的组织中启动“绿色 QA”。

1. 使所有测试执行“上下文相关”

• 仅执行与代码更改相关的测试。避免盲目执行；不要在每个环境上运行每个测试。避免大批量的测试执行。这将减少资源消耗并最大限度地减少能源使用。
• 避免像晚上、一天多次等计划执行。这些执行会消耗太多资源，如果自上次执行以来部署的代码没有变化，则可能不会提供任何价值。
• 将测试隔离，确保每个测试套件或测试用例在不影响其他测试套件或测试用例的情况下独立运行。这可以防止资源争用并提高并行执行的整体效率。减少测试间依赖，以便更容易地在不等待其他测试完成的情况下并发执行测试。
• 利用云平台进行测试执行，因为它们可以根据需要动态分配资源。这可以为能源效率做出重大贡献。
• 重新设计 CI 和 CD pipeline，以在各种“测试”阶段结合上述原则。

可以通过转向 Trunk-based 开发和使用注释在代码中标记测试并将其作为参数传递给 CI/CD pipeline 来实现。

2. 实施节能的测试自动化 (编码) 实践

测试执行能耗 = 活动代码能耗 + 等待代码能耗 + 空闲代码能耗

• 将测试自动化框架和脚本容器化。容器提供了一个轻量级且孤立的环境，使其易于水平扩展。它们还减少了每次代码下载和构建过程生成的网络流量。
• 最小化文件 I/O 操作，尤其是在循环或频繁文件访问场景中。使用缓冲 I/O 操作来减少磁盘访问次数。例如：从文件中读取测试数据或从文件中读取配置或将结果推送到测试管理工具。
• 学习编写优化的代码，包括死代码消除、循环优化、公共子表达式消除等。此外，分析不同算法的性能特征并为您的特定用例选择最合适的算法。
• 保持测试工具和库是最新的，以受益于任何性能改进。
• 在代码中及时释放资源，尤其是在资源受限的环境中，如移动设备或物联网设备测试。
• 最小化后台进程、任务和线程，这些进程、任务和线程可能会提高 CPU 和内存利用率，从而增加功耗。
• 调整日志记录和报告的详细程度，以避免不必要的资源消耗。

可以通过在自动化指南文档中记录所有上述内容、与质量工程师沟通并在代码审查过程中将它们作为检查领域来实现。

playwright 是微软推出的一款自动化测试工具，据说开发小组的核心人员来自 google 的 puppeteer 团队，真是一出生就有了个好爹而且好爹的亲爹也是爹中的战斗机，这就让人非常期待了。

下载与安装

playwright 应该是使用 JavaScript 进行开发的，不过考虑到大部分的测试同学可能对 python 更为熟悉，这里的安装就以 python 版本为例。

在命令行中输入pip install pytest-playwright，等 playwright 安装成功之后再输入命令playwright install，这条命令的作用是安装测试所需要的各种浏览器支持，相比较 selenium 需要先安装浏览器再安装相应版本的 driver，playwright 的初始化工作就显得轻松了很多。

第一个用例

接下来按照官方文档里的例子我们来跑第一个 playwright 用例。

新建一个名为 test_my_app.py 的文件，然后把文档中的例子一字不差的进行拷贝粘贴。

import re
from playwright.sync_api import Page, expect

def test_homepage_has_Playwright_in_title_and_get_started_link_linking_to_the_intro_page(page: Page):
    page.goto("https://playwright.dev/")

    # Expect a title "to contain" a substring.
    expect(page).to_have_title(re.compile("Playwright"))

    # create a locator
    get_started = page.locator("text=Get Started")

    # Expect an attribute "to be strictly equal" to the value.
    expect(get_started).to_have_attribute("href", "/docs/intro")

    # Click the get started link.
    get_started.click()

    # Expects the URL to contain intro.
    expect(page).to_have_url(re.compile(".*intro"))

然后在命令行里输入 pytest，视网速而定，等待个 10 秒钟左右，就可以看运行结果了。

一般情况下我是不喜欢追热点蹭热度的，不过这两天公安机关警情通报之后，吴亦凡事件发生了各种逆转，这起全员恶人事件非常凑巧的契合了安全测试中的一个概念：也就是中间人攻击。我们在吃瓜之余可以简单了解一下中间人攻击的一些原理，通过例子去学习，印象自然会深刻一些。

什么是中间人攻击？

下面的定义来自维基百科。

中间人攻击（英语：Man-in-the-middle attack，缩写：MITM）在密码学和计算机安全领域中是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。在许多情况下这是很简单的（例如，在一个未加密的Wi-Fi 无线接入点的接受范围内的中间人攻击者，可以将自己作为一个中间人插入这个网络）。

一个中间人攻击能成功的前提条件是攻击者能将自己伪装成每一个参与会话的终端，并且不被其他终端识破。中间人攻击是一个（缺乏）相互认证的攻击。大多数的加密协议都专门加入了一些特殊的认证方法以阻止中间人攻击。例如，SSL协议可以验证参与通讯的一方或双方使用的证书是否是由权威的受信任的数字证书认证机构颁发，并且能执行双向身份认证。

举个例子

下面的内容依然来自维基百科。

假设爱丽丝（Alice）希望与鲍伯（Bob）通信。同时，马洛里（Mallory）希望拦截窃会话以进行窃听并可能在某些时候传送给鲍伯一个虚假的消息。

首先，爱丽丝会向鲍伯索取他的公钥。如果 Bob 将他的公钥发送给 Alice，并且此时马洛里能够拦截到这个公钥，就可以实施中间人攻击。马洛里发送给爱丽丝一个伪造的消息，声称自己是鲍伯，并且附上了马洛里自己的公钥（而不是鲍伯的）。

爱丽丝收到公钥后相信这个公钥是鲍伯的，于是爱丽丝将她的消息用马洛里的公钥（爱丽丝以为是鲍伯的）加密，并将加密后的消息回给鲍伯。马洛里再次截获爱丽丝回给鲍伯的消息，并使用马洛里自己的私钥对消息进行解密，如果马洛里愿意，她也可以对消息进行修改，然后马洛里使用鲍伯原先发给爱丽丝的公钥对消息再次加密。当鲍伯收到新加密后的消息时，他会相信这是从爱丽丝那里发来的消息。

具体展开如下：

1.爱丽丝发送给鲍伯一条消息，却被马洛里截获：

爱丽丝“嗨，鲍伯，我是爱丽丝。给我你的公钥” –>  马洛里   鲍伯

2.马洛里将这条截获的消息转送给鲍伯；此时鲍伯并无法分辨这条消息是否从真的爱丽丝那里发来的：

爱丽丝   马洛里“嗨，鲍伯，我是爱丽丝。给我你的公钥” –>  鲍伯

3.鲍伯回应爱丽丝的消息，并附上了他的公钥：

爱丽丝   马洛里<– [鲍伯的公钥]–  鲍伯

Selenium 4.11.0 正式发布了，先来看一下主要特性。

• Chrome DevTools 支持的版本现在是：v113、v114 和 v115（Firefox 仍然对所有版本使用 v85）
• 通过 Selenium Manager 支持 Chrome For Testing（CfT）
• Selenium Manager 现在可以在 PATH 或配置的路径上定位 driver 的二进制文件，检查潜在的不兼容性，并提供更好的警告和错误信息。
• 每晚都会推送 Ruby 和 Java 的构建版本。对其他语言的支持即将推出。
• 在查找窗口句柄时忽略进程 ID 匹配 - Edge 上的 IE 模式。

这里最重要的更新是支持了 Chrome For Testing.

Chrome For Testing

这是 chrome 推出的专门针对测试场景使用的浏览器，为了解决下面一些痛点

• chrome 的自动化更新。自动更新：对用户来说很方便，对开发者来说很痛苦，特别是测试同学，应为我们希望(a)在重复的测试运行中获得一致且可重复的结果，但如果浏览器可执行文件或二进制文件在两次运行之间决定自行更新，这会毁了一切。(b)我们想要固定一个特定的浏览器版本，并将该版本号添加到你的源代码仓库中，这样你就可以检出旧的提交和分支，并重新运行测试，以便使用那个时间点的浏览器二进制文件进行测试。基于上面两个原因，自动更新让人欲除之而后快。

• 下载不到特定版本的 chrome 浏览器。除了自动更新之外，你可能也发现很难找到特定版本的 Chrome 二进制文件。谷歌故意不提供带有版本号的 Chrome 下载，因为用户不应该关心版本号，他们应该尽快更新到最新版本。这对用户来说很好，但对于需要在旧版本的 Chrome 中重现错误报告的开发人员来说很痛苦。这个问题的一个更具体的例子是当你想要使用 ChromeDriver 进行浏览器自动化时。你不仅需要以某种方式下载 Chrome 二进制文件，还需要一个相应版本的 ChromeDriver 二进制文件，以确保这两个二进制文件是兼容的。

在这样的背景下，chrome for testing 应运而生。官方的说法是

为了解决这些问题，Chrome for Testing 是 Chrome 的一个专用版本，针对测试用例进行了优化，不会自动更新，与 Chrome 发布流程集成，每个 Chrome 版本都可用。这个版本的二进制文件尽可能接近常规的 Chrome，同时不会对测试用例产生负面影响。

国外有机构展望了 2022 年值得测试和开发同学关注的技术趋势，我在这里简单的给大家介绍一下，路漫漫其修远兮，大家一起求索吧。

混合组织成为常态

2022 年很明显，有些人不会返回办公室，至少不会一直返回办公室。病毒大流行开始时最大的挑战之一就是远程工作的弱点和新机遇。 人们远程工作面临的最大困难是深陷工作无法自拔。另一方面，人们承认他们在在线交流和协作方面遇到的困难较少。全球 CIO 调查显示，截至 2021 年 3 月，31% 的受访者预计将继续永久远程工作。据另一项调查显示，73％的雇员要求更灵活的工作选择。

对测试人员意味着什么

由于远程管理的困难降低使得原本对外包保持警惕的公司放弃了一些担忧。外包 QA 团队是内部团队的延伸。如果正确的设置流程，管理外包并不具有挑战性。更多的公司可能会开始使用外包的 QA 资源。

对通讯工具的需求不断增长

2020 年 3 月，在线会议软件的使用量猛增。Zoom 打破下载记录，股价上涨超过 100%，Google Hangouts 提供半年免费使用高级计划，Microsoft Teams 一个月赢得了 1200 万用户。这样的故事在 2021 年听起来并不令人震惊。我们已经加入了用户行列，成为统计数据的一部分。 组织仍在不断寻找可靠的通信和合作软件工具。远程办公不应限制工作活动。

反过来，科技公司的目标是增强他们的通信工具，加入更多功能，以提供更大的灵活性。 例如，Slack 推出了 Huddles——一种轻量级的音频优先通信功能，允许用户在不安排面对面或视频会议的情况下接听电话。此外，现在用户可以发送音频和视频消息，这对许多人来说也是一个很大的好处。

对测试人员意味着什么

各种规模和各行各业的公司都在使用通信工具，市场广阔，现有工具还有改进空间。随着新功能的添加，QA 部门将忙于进行功能、集成和回归测试。 喜欢使用定制解决方案的公司可能会决定升级其内部平台。例如，添加与 Zoom、Skype、Meet 或其他一些工具的集成将能够更快地访问视频通话功能。这些改进总是伴随着 API 和回归测试。

企业可能对更复杂的产品感兴趣，例如具有多客户端功能的内网视频平台、媒体资产管理等。在这种情况下，提供商应该准备好提供具有高级定制功能的产品。从头开始创建这样的平台需要仔细的市场分析，然后进行广泛而细致的测试。

吸引眼球，拉拢更多的用户

人们越来越意识到社交网络和品牌可以如何操控他们的思想。此外，2021 年的数据表明，用户对新奇产品保持兴奋的程度是有限的，比如 clubhouse。新媒体专家用多篇文章总结了这些事件，一些人在新社交网络的早期就预测到了 clubhouse 这样的结果，以及总结了该产品的失败原因。

• 显然，创作者没有看到长期的潜力，逐渐停止为平台增值。
• 实时性的功能（例如只能进行直播而无法进行广播录制）营造了一种怀旧/复古的氛围，然而大房间的访问受限和人数限制导致了激怒和两极分化。
• 算法和用户体验都远非完美。Clubhouse 围绕最初的炒作发展，而不是专注于平台改进 。

令人惊讶的是，TikTok 仍然是派对之王，逐渐吸引了更多不同的受众。当然，Instagram 也不容忽视，其通过推出 Reels 做出了回应。无论是良好的实现还是熟悉的平台，用户似乎都对它感到满意。

对测试人员意味着什么

把用户牢牢的绑在平台上，对用户忠诚度甚至注意力的竞争变得更加激烈。 这意味着软件开发团队现在应该更加关注最终用户体验。当然，很大程度上决定开发新应用或功能的人并非技术专家。然而，软件开发人员是实现这些想法的人，而软件测试人员是接触结果的人。功能、UI 和兼容性测试将非常重要。 最后，在流程中涉及业务分析师的团队将更好地了解市场契合度、商业机会和规模。仔细的分析和精心编写的文档有助于避免逻辑空白和不适合市场/需求。

当前市场上各种端到端的测试工具层出不穷，工具市场很繁荣，但真正成功的项目实践却很少见。今天看到了一篇很有意思的文章，我愿称作者为典型的 selenium 原教旨主义者， 他的一些观点尽管看上去非常的 old school，不过总的来说是很有道理的，这里简单的分享一下他的观点。

他的这篇文章叫做 Correct two Common Misconceptions: End-to-End Test Automation is “Simple and Easy” or “Complex and Impossible”，翻译过来就是纠正两个常见的错误观念。端到端测试自动化是 “简单而容易 “还是 “复杂而不可能”, 原文的地址是https://zhiminzhan.medium.com/correct-two-common-misconceptions-end-to-end-test-automation-is-simple-and-easy-or-complex-and-ad559ade982a。

一切都开始于这样的一个观点:

事实：大多数测试自动化的尝试都失败了

“根据我在这个领域 17 年的经验，我同意图片中描述的主要概念，即大多数测试自动化的努力往往是失败的。” - 作者

端到端测试自动化是简单还是复杂？

答案取决于你问谁。在过去的 30 年里，测试自动化供应商，如惠普，一直在推销 “记录/回放 “和 “对象识别工具 “的概念。尽管这些方法已经被证明是无效的，但一些供应商仍然坚持使用这些方法。

在一个典型的软件团队中，众多的软件工程师和经理可能认为 “测试自动化 “是一个简单的任务，尽管没有人见过测试自动化的成功实施（也就是说，团队完全依靠手工测试）。作为证据，许多招聘广告要求申请人有 “创建测试自动化框架 “的经验，这似乎很荒谬。

所以，端到端的测试自动化可能并不像许多人想象的那样简单和容易。

“根据我的经验，优秀的开发人员不一定能成为优秀的测试人员，但优秀的测试人员（同时具有很强的设计能力）可以成为优秀的开发人员。这是一种心态和一种激情。…他们是黄金”。

• 谷歌副总裁帕特里克-科普兰，在一次采访中（2010 年）

“95%的时间，95%的测试工程师会写出糟糕的 GUI 自动化，只是因为它是一件非常难做的事情。

• 这篇来自微软测试大师 Alan Page 的采访（2015 年）

“测试比开发更难。如果你想有好的测试，你需要把你最好的人放在测试中”。

• Gerald Weinberg，在一个播客中（2018 年）。

考虑到事实和上述知名专家的引言，似乎完成端到端的测试自动化是一个无法克服的挑战。

我的答案是 “它可以很简单，但往往是人为的错误使它变得不必要的困难。”

许多人做出了明显的错误的决定

我见过错误的决定，往往不止一个，在失败的测试自动化尝试中。