让自动化测试脚本正常工作只是自动化测试的第一步，由于自动化脚本会经常执行并更新，因此测试脚本需要

• 可以快速执行
• 容易维护
• 容易阅读

本文会提供一些让 selenium 自动化脚本运行的更快的技巧。

在 page_source 中断言 text 比直接使用 text 属性断言要快

我们经常会需要断言页面中的某个部分包含一些具体的文本，下面的语句的输出结果是相同的

driver.page_source
driver.find_element(:tag_name => ‘body') .

不过对于第二条语句来说，selenium 需要去分析页面的结构，最后再找到对应的元素并输入结果，这显然是需要花费时间的。如果页面比较小的化，那么二者的差距可能不大，不过对于大的页面来说，第一条语句速度明显会更快一些。

使用 page text 的情况

expect(driver.find_element(:tag_name => "body").text).to include("platform- and language-neutral wire protocol")

使用 page source 的情况

expect(driver.page_source).to include("platform- and language-neutral wire protocol")

来看一下差距

Method 1: Search whole document text took 0.823076 seconds
Method 2: Search whole document HTML took 0.039573 seconds

当然两者的使用场景是不太相同的，不过我们这里只关注性能，显然 page source 要更快速一些。

元素越具体，获取 text 的速度越快

根据经验，我们可以通过缩小更具体的 Web 控件的范围来节省执行时间。下面的两个断言语句在很大程度上实现了相同的功能，但在执行时间上有很大的不同。

expect(driver.find_element(:tag_name, “body”).text).to include(“language-neutral wire”)

这条语句的执行时间是 0.93s

expect(driver.find_element(:id, “abstract”).text).to include(“language-neutral wire”)

这个断言只执行了 0.02s

很明显，第 2 个断言除了在执行速度上更快之外，断言也更加精确，更容易理解。

使用变量去缓存没有变化的元素

我经常看到有人编写如下测试来检查页面上的多个文本。

driver.navigate.to(site_url + "/WebDriverStandard.html") expect(driver.find_element(:tag_name, "body").text).to include("Firefox")
expect(driver.find_element(:tag_name, "body") ").text).to include("chrome")
expect(driver.find_element(:tag_name, "body").text).to include("W3C")

执行时间 2.35s

上述三个测试语句非常低效，因为每个测试语句都调用driver.find_element(:tag_name, 'body').text，当网页很大时，这可能是费时费力的工作。

看到了一篇不错的关于自动化测试文章，简单翻译了一下。

在我的软件测试生涯中，我听到了许多说法，如 “我们不需要团队中的测试人员！“到 “我们需要用 100%的覆盖率来自动化一切！"。每当我听到这些时，我都会摇头。我打赌你知道为什么。这两个极端都是错误的，因为我认为每个软件开发团队都应该有一个测试人员在其中。当然，100%的测试自动化覆盖率也是不可能的，也是没有效率和要求的。

在这篇文章中，我将分享我在测试自动化方面学到的经验，这些经验是我在软件测试行业工作了 13 年以上的艰苦历程中总结出来的。我将分享我在过去几年中对测试自动化和要避免的陷阱的详细看法。我将分享我在测试自动化方面的注意事项，以帮助你不犯同样的错误。

应该去做的事情

雇用合适的人

雇用具有软件工程技能的人是必须的。没有正确的技能，你的测试自动化会失败。因此，需要在招聘过程中投入大量时间，以确定适合你的需求的人。我建议你写下你想通过新员工实现的目标。一旦目标明确，就从中引申出具体的技能。

现在是时候写一份朗朗上口、不太长的职位描述，并说明所需的核心技能。不要在长长的技能清单中过度使用技术术语和要求。这可能会对潜在的雇员产生负面的影响。

在面试过程中与人交谈时，技术能力是必须的。你可以在编码挑战或临时进行的代码审查中验证它们。然而，不要只看技术能力。检查是否适合团队或公司，以及在与人合作、沟通和解决问题时的正确心态也非常重要。

一旦你雇用了合适的人从事你的自动化工作，相信他们会做正确的事情。给他们尽可能多的上下文，让他们与公司的其他角色一起，如开发人员、设计师和产品人员。在最好的情况下，每个开发团队都有一个测试工程师加入。

在寻找正确的测试自动化工具方面花点时间

在公司拥有正确的测试自动化人员是一个很大的优势。下一个挑战是找到并选择正确的测试自动化工具。而这需要时间。在选择工具之前，与所有参与方坐下来，定义测试自动化的目标。在这个过程中，尽量提出尽可能多的关于工具、自身环境和将要建立的产品的问题。在这些问题的帮助下，你将创建一个长长的选择标准列表，以帮助你找到适合你需要的测试自动化工具。

该列表可以有以下标准。

• 该工具是否支持不同的编程语言？
• 该工具是否能够针对不同的操作系统进行自动化？
• 该工具是否支持 CI/CD？
• 该工具是否提供报告功能？
• 该工具是否有很好的文档，是否提供支持或有一个伟大的社区或干爹？
• 该工具是否满足预算要求？
• 配置该工具的复杂程度如何？
• 该工具是否提供灵活的测试执行能力，例如在不同的操作系统或环境下？

上面的列表只包含了一些可能的问题，以找到合适的工具。因此，需要投入足够的时间来找到适合你需求和环境的工具。也可能是你需要一个以上的自动化工具用于你的技术架构中的不同层，或者是除了测试自动化工具之外，还需要一个测试自动化管理平台。那么你应该分别对每个工具进行选择。

轻装上阵

一旦你确定了适合你的需求的自动化工具，现在是在你的团队或公司内进行配置和实施的时候了。在最初的几天或几周内，试着学习所有关于这个工具和它的功能。一旦你和你的团队熟悉了它，就开始进行第一个自动化方案的工作。但开始时一定要简单! 看看那些容易自动化的产品功能，并帮助团队专注于质量的其他部分。当这个测试是强大的并提供可靠的结果时，就可以进入下一个自动化阶段。开始在更复杂的情况下工作，看看结果。我们也建议在产品的某些部分进行测试，这些部分每天或每周都不会改变。通常一个产品的核心功能是自动化的完美起点。

让开发人员参与到自动化过程中来

编写测试自动化代码并不容易。**它的复杂性与编写生产代码的复杂性相同，这一点永远不应该被低估。**通常一个软件开发团队有 3-5 个软件开发人员和至少 1 个软件测试工程师。这个比例是可以的。然而，测试工程师很难赶上所有对产品进行的代码修改。他/她不仅需要手动测试软件，而且还需要编写复杂的自动化。这一切对团队中的一个人来说是不可能做到的。因此，软件开发人员也必须负责编写测试自动化代码。不仅在单元测试层面，其他层次的自动化测试也可以涉猎。

每个团队都应该坐在一起讨论自动化过程。每个人都必须清楚，产品的质量是每个人的责任。这种心态要求团队中的每个人都支持自动化。如果不是这样，你的自动化过程很可能会失败。

在 ci/cd 上投资时间

与工具选择的时间投资类似。一个软件开发团队必须在 cicd 的配置上投入足够的时间。pipeline 的配置方式必须支持开发团队的需求。例如，在每次提交时运行，在拉代码时运行或在夜间执行整个测试套件。

同样重要的是，定义哪一层的哪些测试应该在什么时候被自动化。在最好的情况下，团队正在制定一个 cicd 策略。一旦 pipeline 策略被实施，重要的是结果对团队中的每个人都是透明的，甚至更好的是对公司中的每个人都是透明的，例如用一个 dashboard。

cicd 工作和投入的时间不应该被低估。根据项目或产品的规模，这可能是一个人甚至整个团队的全职工作。

不应该做的事情

不要因为一个工具被追捧就选择它

我的不做清单的第一点是，当选择一个新的测试自动化工具时，不要因为它在软件开发或测试社区中被炒作而盲目地选择一个工具。如果你真的很幸运，这个工具可能对你有用，但在大多数情况下，你会用它失败。正如我在前面提到的，选择一个工具需要时间。如果没有在选择过程中的这种投资，从长远来看，你可能会损失更多的钱，因为在产品开发过程中的某个时刻，你会发现这个工具不支持某个特殊功能，或者不能按照你需要的方式进行扩展。

在选择工具时，最好检查一下目前什么工具被炒得很热，为什么？也许这种追捧有一个合理的理由，你可能会从中受益。跟上新的工具，并与社区保持联系，获得最新的消息，这总是好的。

不要试图将一切都自动化

我在前面已经提到了这一点。每当你的团队或公司里有人告诉你要把所有事情都自动化的时候，你就装聋作哑好了。这个人很可能是一个从未从事过软件开发的人，或者对测试自动化毫无概念。我见过一些没有经验的人，他们是自动化的新手，试图把所有的东西都自动化，但他们很快就发现，这是不可能的。当你看到有这种观点的人时，和他们谈谈，并解释其消极的一面。

你应该做的是看一下你的产品和代码架构，并确定你的应用程序的关键部分。然后花时间为这些部分创建一个自动化战略。

有了明确的重点和策略，少量的自动化方案可以对产品的整体质量产生更大的影响。

不要太早实现自动化

在产品开发团队中开始使用自动化时，一个典型的错误是开始的太早了。如果团队正在开发一个全新的功能或产品，真的很有可能功能会改变。在这种情况下，开始实施自动化是没有意义的。投入的时间可能会被浪费掉。相反，团队应该从基础开始。例如，建立 CI/CD pipeline，考虑功能所需的数据结构。从中得出一个测试数据策略，也许准备测试数据生成的脚本。

一旦功能越来越成熟，就慢慢开始自动化。我建议与产品所有者保持密切的关系，以了解即将到来的产品功能和变化。使用这些信息来创建你的自动化策略。

永远不要用自动化来取代人工测试

最后但并非最不重要的是，不要用自动化来取代人工测试！人工测试是自动化的重要组成部分。在产品的开发过程中，手工测试是如此强大的一部分，它永远不应该被机器取代。为什么呢？嗯，自动化测试将由机器/计算机执行。机器所做的正是测试自动化代码中的内容，仅此而已。这并不坏，我们都知道这是有用的信息，但软件同学进行手工测试时，会发现更多的问题。首先，测试人员的行为就像一个用户。使用产品的用户会使用它，例如用鼠标、键盘或用手指在使用产品时使用他/她的所有感官。在大多数情况下，手工测试会发现没有人想到会发生的问题。

因此，测试自动化是人工测试的重要补充。

总结

正如你在这篇文章中所看到的，一个人在从事测试自动化时可能会犯很多错误。在雇佣自动化专家、寻找合适的工具和寻找合适的时机开始自动化时，有许多话题需要记住。

之前 ruby on rails 的创始人 dhh 在 twitter 上宣布由于云服务的价格过于昂贵，他们决定自己买服务器自建服务以节约成本。在今年 9 月 15 号的Our cloud exit has already yielded $1m/year in savings这篇博客中,dhh 宣布他们公司37 signals目前云服务的月花费从 18 万美金降到了 8 万美金，也就是 1 年可以节约 100 万美金。10 月 27 号，twitter 也宣布他们的去云化项目为公司降低了 60%的成本。在这之后关于去云化的讨论逐渐热门起来，目前看来一些公司确实在认真思考从云端逃离的可能性。

为什么大家都在逃离云服务

我觉得核心问题还是全球经济衰退，除了裁员节省成本之外，少用或者甚至不用云服务可以带来可观的成本降低。讽刺的是当初云服务的兴起就跟成本节约相关，如今屠龙的少年却成了恶龙，在被人们慢慢抛弃。

在很多年前，互联网应用运维难度大，机器带宽等成本相对较高，资源整合型的云服务可以显著为小型团队节约成本，降低了构建产品的门槛。但这么多年过去了，硬件成本逐步走低，而云服务的定价却变化不大，高溢价就降低了云服务的性价比，从而会影响大家的理性选择。

初创企业往往是云服务利润的贡献者，这几年大量的初创企业倒闭导致云服务商失去了一大块利润来源，这也在一定程度上降低了云服务厂商降价的积极性。

简单来说云服务的存量用户嫌贵，增量用户变少，因此整个市场就显得萧条。

我们是否真的需要云服务

对于大公司来说，云服务确实是必须的，因为规模化带来的巨大成本优势是非常有吸引力的。比如大公司扩张的过程中可以不需要去某些海外市场建机房攒带宽，直接买云服务就可以了，这些服务对于大公司业务来说是一个积极的补充，因此大公司对云的使用其实是混合云为主，自建机房加上云服务辅助，这样就可以尽可能的降低边际成本。

对于初创公司来说，用云服务其实是最快产品化的选择，很多时候如果你拿了投资人的钱的话，你是没得选的，必须上云，然后快速进行产品迭代。如果你产品的最初版本就在云端运行而且运行的很好，那么你是没有动力去买服务器然后托管的。不过随着业务的发展，从成本角度考虑，把服务从纯云端切回混合部署的方式可能会是一个不错的选择，首先可以降低成本，其次可以把核心的数据资产攥在自己手上，从经济上和安全性上考量，混合云的方式都有存在的价值。

所以我认为云服务是必须的，这是一种资源整合带来的规模化优势的体现，很多场景下确实可以降低成本，但完全依赖云服务则不一定可取。

云服务的未来会怎么样

既然大家都在逃离，那么是不是云服务和云计算的前景就变得暗淡了呢？

不一定，我觉得云服务可能跟经济一样有其周期性，如果云服务持续的改进和创新，那么这个周期性可能就会显得很明显。比如经济好的时候，大家都选择创业，大公司选择开拓市场，那么云服务厂商会跟着一同繁荣。但如果经济下行，创业潮过去，大公司选择降本增效，那么云服务自然就会受到冷遇。

云服务的本质决定了这是一种相对来说高效的做法，理论上讲长远看还是有市场的，不过云服务还是需要逐步演进的，比如为解决气候变化问题逐步淘汰低能效的机器，使用清洁能源来替换化石能源等。

逃离可能只是经济发展放缓带来的暂时性问题，一旦云服务迭代跟上了，降低了成本和定价，提升了服务的稳定性，流失的用户是有回归的可能性的。

对很多人来说 2022 年可能是非常糟心的一年，我们有理由去期待 2023 年会触底反弹，经济环境变好，收入提高，内卷的情况得以缓解。不过从目前得到的消息来看，一切可能没有那么乐观。

关于裁员

最近跟字节的朋友聊天，消息可能不是特别准确，不过字节大概已经在开始裁员了，飞书的目标是 10%，其他业务不清楚。根据字节的体量估计的话，有可能会涉及到万人级别。

跟腾讯的朋友聊天，他们表示已经收到消息，明年裁员会继续，不过手段会多样化，基本上会通过不续约和低绩效的方式进行淘汰。

我们公司是二线厂，今年下半年一直在裁员，年底的时候消停了一些，不过估计明年还是会继续的。

国外的话亚马逊开始裁员，估计会回到疫情之前的人员规模。

可以看到 2023 年互联网的企业的主旋律还是裁员，保住饭碗苟下去应该是大多数人的明智之举。

关于换工作

跟猎头聊了一下，字节国内的 hc 应该基本上冻结了，我们公司只裁人不招人，腾讯那边不清楚，少量的 hc 进行血液流通还是会有的。其他厂没有了解过，不过根据之前被裁的同事反馈 2022 下半年还是能找到工作的，机会不多，但不是完全没有。很多人去了字节，算是一个稳定的退路，但 2023 年估计字节也不好进去，除非降低预期往二三线厂看看，不然退路方面的可选择面还是比较少的。

2023 也不是不能换工作，比如换个行业之类的也是比较不错的思路，不过还是不建议裸辞，找到了再换可能更好一点。

另外这几年创业的热潮似乎已经冷却，新的工作机会很难创造出来，去初创企业搏一搏的机会可能都会很少了。

关于年终奖

最近腾讯的朋友们表示已经在吹风了，说今年的年终奖会比之前少很多，其他厂不知道怎么样，不过整个互联网行业的年终收益估计都会有所折扣吧。我们公司也是年终奖大幅减少，并且取消了年度涨薪。

如果是合同规定的年终奖，比如合同规定了 15 薪，那么年底就是 3 薪，这是毋庸置疑的；不过如果合同规定的是浮动年终奖，那么可以讨论的空间可能就不大了。

关于希望

经济滞胀，收入锐减，消费降级，预期降低可能会是 2023 年的主旋律，按道理说在这种大环境下，大家退一步躺平，心平气和，看破红尘反而最有可能海阔天空。但现实的情况是，大家都不想失业，于是越来越卷，越来越焦虑。

希望还是有的，不过是从长期来看。对于 2023，也许不能期待太多，只能把目光放长远，看看 3 年 5 年之后，活在当下但心在远方，坚持下去吧。

很少看到有讨论测试人员薪资的文章，当然了在一些论坛里这个话题似乎是主旋律，经久不衰。但写小作文去讨论这件事的测试人员还是不多的。今天看到一篇名为Want to Increase Your Salary as a Tester? Look for a New Job的文章，说的很实在，国内国外都适用，翻译一下，供大家参考。

我们大多数人都不介意获得加薪,尤其是考虑到通货膨胀如何影响世界大部分地区。一切似乎都在变得越来越贵,我们的购买力似乎每周都在萎缩。大多数公司每年都会进行渐进式的加薪,但这仍无法跟上现实生活中的开支。这些略微的加薪也难以反映出你全年的改进。

你想要的加薪应当与你创造的价值和职业发展成正比。但是你该如何获得与你当前技能水平相称的加薪呢?你可以尝试改进现有技能以获得 QA 经理的晋升,或者从手工测试转向自动化测试。不幸的是,有些工作环境没有职位或能力来晋升任何人。有些公司根本不会从内部晋升任何人。无论你付出多少努力,这些决定都不在你的控制范围内。

无论你是在公司工作了一两年的手工测试人员,还是拥有丰富经验的软件开发测试工程师,获得加薪的最佳方式是找到一份新工作。

作为测试人员跳槽可以获得回报

证据表明,与留在原职位获得的平均加薪相比,跳槽可以带来更高的工资增长。在一份报告中,工资和人力资源巨头 ADP 在 2021 年收集了 1800 万工人的数据,并指出换工作的人工资增长了 5.8%,而保留工作的工人只增长了 3.1%。在日本,人力资源公司 Recruit 今年也得到了同样的结论:换工作的人工资增加了 3%,而留在原地的人只增加了 1.2%。

你或者你认识的人可能都有过有意跳槽获得大幅加薪的经历。我的个人经历也印证了这一点,包括我从一家公司跳槽到另一家公司时,工资增加了 50%(后来由于内部晋升又增加了 33%)。仅仅通过跳槽到一家新公司就将薪水翻倍的故事并不罕见。

基本工资的大幅增加不是跳槽带来的唯一好处。你还应该考虑到与新角色相关的额外福利,比如灵活的工作时间、远程工作的能力和更多的假期时间。根据你所在的国家和组织,这些额外福利可以有很大差异。例如,硅谷的一家创业公司可能会在加薪的基础上提供股权。这许多因素不会直接影响你获得的金钱数额,但从长远来看可以极大地提高职业满意度。

跳槽时金钱并非唯一考量

当然,这不全是关于加薪。我们都需要金钱,但有时仅仅为了短期内的加薪而损害你的长期职业发展是不明智的。你需要看得更长远,确保你正在做出正确的决定来增加你未来多年的挣钱能力。对于职业生涯还在早期的测试人员来说,这一步尤其值得注意。

密切关注你当前角色以及未来职位中的潜在停滞是很重要的。在我职业生涯早期,我离开了一份工作,却进入了另一份工作内容几乎相同的角色。说实话,这导致了停滞和懒惰。我最初跳槽时确实多赚了一点钱,但专业发展的缺乏可能使我失去的要比如果我选择能将我带出舒适区的公司所能获得的要多得多。

当寻找新工作时,你需要探索的主要领域之一是拓展技能的能力。作为一名软件测试人员,你可能已经适应了当前角色中使用的某些工具和遵循的特定流程。找到可以让你接触新方法和新技术的不同职位将大大提高你在 QA 中的价值,并直接影响你未来测试职业生涯的挣钱能力。

在充满不确定性的时期找到测试工作

如今,似乎大多数大型和小型科技公司每周都在裁员。仅 2022 年,像谷歌、Meta 和亚马逊这样的行业巨头就解雇了数万名员工。许多这些公司也暂停了招聘,因此我们现在有更少的选择来寻找新工作。由于市场上涌入大量优秀的被裁员工,任何可用职位的竞争可能也会变得更加激烈。

仅仅发送一个充满时髦词汇的简历并期待接到电话已经不够了。你必须展示你的技能、经验和成为专业 QA 的渴望。在 LinkedIn 或 Ministry of Testing 论坛等地方扩大你的专业网络可以开启新的机会之门。写博客和上传视频是展示你知识并展现你对行业热情的绝佳方式。有许多不同的方式可以使你脱颖而出,许多有价值的公司看重这种主动性。

尽管我们目前似乎处于低迷期,但情况并非大多数主要出版物所描述的那么令人绝望。如果你仔细寻找,你仍会发现许多受人尊敬和有趣的组织在寻找像你这样高技能测试人员加入他们的团队。当然,找到这些职位现在比以前更具挑战性,你可能会收到无数拒绝或“鬼影”。我知道这对心理是一个大负担。但这并非不可能克服。低迷期是暂时的,在跳槽之前,你可以开始为更光明的未来做准备。

总结

在同一家公司工作几十年直到退休的日子早已一去不复返了。大多数现代公司都知道这一点,但暗自希望你尽管缺乏经济和非经济激励但还是继续留下来。作为一名软件测试人员,主导你的职业和财务未来取决于你自己。寻找一份新工作可能是实现这些目标的最佳策略。

离开当前角色去别处找到一份新工作通常伴随着比等待可能永远不会到来的潜在加薪更高的加薪。你还可能获得更灵活的工作环境等额外福利,这可能极大地改善你的工作与生活平衡。除了金钱之外,新角色还带来了新职责,为你未来带来更大的发展机会。

这篇文章并不是说每个读者都需要尽快找到一份新工作。你可能对当前的团队、薪水和职责感到满意。如果是这样,请珍惜你拥有的一切。但是许多人会从一个新环境中受益,无论是为了金钱还是职业发展。目前的求职市场有些紧张,但请开始把自己放在那里——你永远不知道能发现什么。走出舒适区是成为更好测试人员的绝佳方式。

最近 Facebook 的工程师们撰写了一份文档，解释了他们如何编写了一个可以自动修复 bug 的工具。在这篇论文中，他们介绍了 𝗦𝗔𝗣𝗙𝗜𝗫，这是一个自动检测和修复软件 bug 的工具。该工具对 Facebook App Family 中的六个重要安卓应用程序提供了修复建议，这些应用程序包括 Facebook、Messenger、Instagram、FBLite、Workplace 和 Workchat。

工作原理

步骤 1：检测崩溃 - 另一个名为 𝗦𝗮𝗽𝗶𝗲𝗻𝘇 的工具用于查找应用程序崩溃情况。当 Sapienz 识别出崩溃时，它会被记录到数据库中。

步骤 2：确定问题 - SAPFIX 可以准确定位导致问题的代码行。它首先检查崩溃是否可重现。如果不可重现，崩溃将被丢弃。它使用一种称为"基于频谱的错误定位"的技术来确定最可能导致崩溃的代码行。

步骤 3：提供修复建议 - 使用预定义的模板或代码变异，SAPFIX 提出了一个解决方案。在确定故障位置后，SAPFIX 尝试生成一个补丁。它采用了以下两种策略：

• 基于模板的修复 - SAPFIX 使用预定义的模板为常见 bug 提供修复建议。这些模板是根据标准开发者实践设计的。
• 基于变异的修复 - 如果基于模板的方法失败，SAPFIX 将采用基于变异的系统。它会对故障位置应用一系列代码变异，生成潜在的修复方案。

步骤 4：测试修复 - 提议的解决方案会经过测试以确保其有效性。它使用 𝗦𝗮𝗽𝗶𝗲𝗻𝘇 的测试用例来检查补丁的有效性。如果补丁通过所有测试，则被视为有效的修复方案。在补丁验证完成后，SAPFIX 使用 𝗜𝗻𝗳𝗲𝗿（一种静态分析工具）对提议的修复方案进行进一步分析。Infer 会检查补丁是否引入了任何新的潜在问题。

步骤 5：审查 - 开发人员拥有最终决定权，对修复方案进行审查和批准。

论文地址是: https://ieeexplore.ieee.org/document/8804442