国外有机构展望了 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 年）。

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

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

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

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

2021 年其实立过 flag，但最终事情太多，没有完成既定的目标。2022 年初的时候，想到很久都没有做过教程和视频了，于是兴冲冲的录了一些 selenium 的全套教程，目录如下：

• 环境搭建
• 跑个脚本先
• 第 1 个自动化用例
• 前进和后退
• 搞定被测项目
• 使用 id 定位
• 使用 name 定位
• 使用 xpath 定位：定位王者 xpath
• 使用 tag name 定位
• 使用 class name 定位
• 使用 css 选择器定位
• 往文本框里输入内容
• 执行 js 脚本
• 滑动到页面的最底部
• 各种表单元素的操作
• 显示等待
• page object
• 常见问题答疑

做的不足的地方

因为录制的时间比较短，所以影片的编辑和准备其实是不够充分的，教程应该能看，不过节奏感不好，毕竟年纪大了，有时候会显得啰嗦了一些。

另外 selenium 的一些新特性其实并没有涉及，后面有时间可以重点补充一节。

亮点

当然，教程也是有一些亮点的。

• 脉络基于官方文档，整体的思路还是清楚的；
• 修正了一些官方文档的不足；
• 使用本地文件进行演示，不依赖网络，脚本的稳定性还是比较高的

发布节奏

目前 b 站和微信公众号都在同步更新，每周更新 4-5 集，目前录了 18 集，应该 1 个月就能更新完吧。

后续计划

准备专门弄一个软件测试视频教程分享站点，代码还没写，不过大致的思路有了，啥时候不忙了就可以开工了。

众所周知，java 语言版本的 selenium 一般被认为是最正宗的 selenium 版本，今天我们以 java 语言为例，来看看 selenium 4.0 的各种新特性以及新旧 api 的对比。

Capabilities

如果你需要对浏览器进行一些全局设置，那么使用 Capabilities 是唯一的选择。说实话，旧的 Capabilities 有点不太符合直觉，具体用法如下。

DesiredCapabilities capabilities = DesiredCapabilities.chrome();
capabilities.setCapability("platform", "Mac OS X");
capabilities.setCapability("version", "94");
driver = new RemoteWebDriver(capabilities);

在新版本中，我们直接设置 options 就可以了，语义上显得更为自然。

ChromeOptions options = new ChromeOptions();
options.setBrowserVersion("94");
options.setPlatformName("Mac OS X");
driver = new ChromeDriver(options);

Waits

在之前的版本里，我们实例化各种 wait 对象时候需要传入 2 个参数：time 以及 type of time，在新版本里我们只需要使用 Duration 类就可以了。

这是之前的做法

driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
driver.manage().timeouts().pageLoadTimeout(10, TimeUnit.SECONDS);
driver.manage().timeouts().setScriptTimeout(10, TimeUnit.SECONDS);

新的方式

driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));
driver.manage().timeouts().pageLoadTimeout(Duration.ofMinutes(3));
driver.manage().timeouts().setScriptTimeout(Duration.ofHours(1));

当然，现在支持各式各样的 Duration 了，需要注意的是这里接受的是 long 型的参数。

Duration.ofNanos(long nanos);
Duration.ofMillis(long millis);
Duration.ofSeconds(long seconds);
Duration.ofMinutes(long minutes);
Duration.ofHours(long hours);
Duration.ofDays(long days);

当然，我们还可以直接设置浏览器的各种全局等待时间，代码上看观感好了不少。

ChromeOptions options = new ChromeOptions();
options.setImplicitWaitTimeout(Duration.ofSeconds(10));
options.setScriptTimeout(Duration.ofSeconds(10));
options.setPageLoadTimeout(Duration.ofSeconds(10));

相对定位器

一些哲学流派告诉我们，世界是变化的，相对的，没有绝对的静，也没有绝对的动，物体总是相对着其他物体进行着运动。

之前发过一篇公众号文章，大意是字节某些部门在推进去测试化，当时就有同学留言表示，在字节的某些部门测试同学其实很多，果不其然，昨天跟一位字节的候选人聊天，候选人就表示在他所在的部门，测试同学确实不少。

他表示他们部门的测试主要有两种编制的同学构成，分别是正式和外包，正式员工跟外包的比例是 1：2，整个部门有几百人的测试规模。

由于时间关系，我也没仔细了解这几百人全部是正式员工还是外包员工，也没弄清楚他们部门一共有多少人，不过从一个单体产品的角度上看，这几百人的规模还是比较大的。

这些信息拼凑起来，我们可以知道大公司的去测试化进度并不是整个公司统一的，可能有些部门比较激进，有些部门就保守一些，测试同学的数量很多，但可能是外包为主。比如很多年前手 Q 团队的测试人数特别多，但是正式员工其实数量有限，大部分的功能测试都是外包同学，华为也类似。

那么字节这个部门的测试同学在做些什么呢？

候选人表示在 4 个方面进行探索。

• 质量维度。负责产品的质量保障工作，这点大家其实很熟悉了；
• 安全维度。负责产品的安全测试和安全方面的各种建设，其实候选人也表示这里的安全可能不够准确，其实应该是各种专项维度，比如性能稳定性之类的，不会只局限于安全；
• 体验维度。这里是最有意思的，我们可以想一想，影响用户体验的是哪些因素？是不是应用的打开速度，给你推送内容的精准度之类？这里的体验就是量化可以影响用户体验的指标，然后持续监控指标，保障指标的值持续达标；比如持续监控 app crash 率，一旦大于某个阈值就告警，然后紧急进行定位和修复；
• 效率维度。通过工具或其他活动提升测试效率。这里可以理解为偏测试开发的部分，比如开发测试工具提高自动化回归的效率等；

所以总结起来，测试同学在字节该部门的关键字其实是：质量+专项+体验+效率，质量这边其实有大量的活动是外包同学可以去承担的，其他的部分专业性比较强，自行做团队建设可能会更好一点。

总之在同一个公司的不同部门里，对于测试的态度可能是不尽相同的，之前讨论的腾讯去测试化也是腾讯的某一个 bg，可能不一定是整个公司的行为。

另外去测试化不是说完全不要测试，而是之前的一些必要的测试工作用一些成本更低的方式去做，比如外包。另外提高测试效率从另一方面说也就是降低测试的成本，是不是感觉有点卷起来了？想反内卷？字节的测试同学其实给我们提供了一个很好的思路，那就是换赛道。目前字节的测试有了 4 个赛道，而且除了质量赛道之外其他的赛道其实专业性还是很强的，所以也许在未来测试这边会分的越来越细，专业化越来越强，赛道越来越多。在某个赛道做专才或者在大部分赛道做通才都是不错的反内卷的方式吧。

前言

我个人认为，AI 一定会对软件测试甚至整个行业内的质量保障工作带来天翻地覆的影响。

但是现在，AI 对测试人员来说可能更接近工具一些。

正好看到一篇讨论类似内容的文章，随手用 AI 翻译了一下，供大家参考。

两种极端观点的碰撞

直到最近，关于 AI 在软件测试中的讨论仍存在两种极端观点。一方面，狂热者坚信 AI 将在一夜之间彻底改变质量保障(QA)，实现所有测试自动化、预测所有缺陷并使人工测试彻底消失。另一方面，怀疑论者则认为 AI 不过是又一个被过度炒作的趋势，是对真正测试专业性的干扰。

现实中的平衡点

事实往往介于两者之间。AI 既不是质量保障的银弹，也不是华而不实的噱头。它本质上是一种工具，其价值完全取决于使用方式。

AI 应该增强而非取代 QA

关于 AI 在 QA 中的最大误解，莫过于认为它将取代人类测试人员。这种观点根本站不住脚。AI 可以自动化繁琐任务、分析海量数据，甚至发现传统方法可能遗漏的模式。但优秀的质量保障工作远不止自动化这么简单，它需要批判性思维、问题解决能力和对业务场景的深刻理解。

试想：AI 可以生成测试用例，但它能质疑"这个功能对我们的用户真的有意义吗？"

AI 可以分析日志，但它能挑战产品经理的风险假设吗？

显然不能。这正是人类测试人员不可替代的价值所在。

当前 AI 在 QA 中的有效应用

如果我们不再将 AI 视为测试人员的未来替代品，而是作为增强工具，就会发现其真正的应用价值：

1. ​测试自动化辅助

   • 自动生成脚本
   • 优化测试覆盖率
   • 自我修复不稳定的测试用例

2. ​缺陷预测

   • 通过 AI 驱动的分析识别代码高风险区域

3. ​智能测试数据管理

   • 生成真实测试数据
   • 敏感信息脱敏处理

4. ​视觉与 UI 测试

   • 检测传统自动化测试可能遗漏的界面问题

QA 中 AI 的错误使用方式

尽管优势明显，但 AI 在 QA 中常被误用。最常见的错误包括盲目信任未经人工验证的 AI 生成测试用例（AI 缺乏领域专业知识），以及没有明确战略地追逐各种 AI 工具。优秀团队会针对具体问题使用 AI，而不是将其作为时髦的装饰品。