专注测试技术的课程订阅站点

selenium 4 0新特性及新旧api对比

众所周知,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 在软件测试中的讨论仍存在两种极端观点。一方面,狂热者坚信 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,而不是将其作为时髦的装饰品。