我的 Selenium 不稳定

乔梁 | 2022-04-09

我听过太多次无法忽视的抱怨,类似于:

我的 Selenium 测试不稳定!

自动化测试很不稳定。

它们有时成功,有时失败。

多么深刻的领悟,多么令人沮丧!

当这种状态持续一段时间后,大家就开始忽略自动化测试的结果了。

而这意味着,在发现 bug 和找到回归问题上,它们能为团队所提供的价值都将失去。

这是一种可耻的浪费,但并非必须如此。

首先,让我们明确澄清一下:

不是 Selenium 不稳定,是你的 Selenium 测试用例不稳定

同样的说法,也适用于你用 WebDriver 写的测试用例。

当然,这提出了一个很明显的问题。

为什么 Selenium 测试有用,但却未能达到你的预期?

根据我的观察,导致不稳定测试用例的常见原因有很多,在这里与大家分享一下。

问题 1: 测试用例的隔离性差

场景

很多测试用例以相同的用户身份登录,而且还使用相同的固定数据集。

症状

单独运行某个测试用例时,它可以正常工作,

但在持续构建执行批量任务时,会「随机」失败。

解决方案

  • 每个用例都尽可能使用隔离资源。在每个测试用例内组装数据,以避免依赖于构建中的「设置数据存储」步骤。 例如,使用Builder 模式

  • 为每个开发人员建立可独自使用的一个数据库。例如使用 HypersonicSQLite 之类的东西,作为私有的轻量级内存数据库。

  • 创建隔离数据。如果你的应用程序需要用户登录,那么,就创建几个仅为你自己的测试用例保留的用户帐号,并提供锁定机制,以确保一次只有一个测试用例使用该特定的用户帐号。

问题 2:依赖不稳定的外部服务。

场景

使用生产环境的后端服务,或依赖团队自身无法控制的基础设施。

症状

由于相同的依赖原因(如后台的某个服务),可能导致所有测试用例都失败。

解决方案

  • 不要依赖团队无法控制的外部服务

这说起来容易做起来难,因为存在构建时间过长的风险,并且很难建立一个足够紧密地模拟服务且使测试有价值的环境。

有时在进程中启动服务也是可行的,例如使用 Java 世界中的 Jetty 或在 Ruby世界中使用 webrick

通过观察测试用例的执行是发现这些外部服务依赖的好方法。

在我们的一个项目中,尽管后端内容会发送回浏览器,但测试用例仍会时不时地超时。

通过观察发现了潜在的问题:我们提供的是「 fluff(来自 iframe 中外部服务的额外内容)」,而它有时无法及时加载。即使我们的测试用例不需要它,如果它尚未完成加载,我们的测试用例也会失败。

我们的解决方案是通过修改持续集成机器上的防火墙规则,来简单地阻止不必要的 fluff。

突然之间,一切都变得顺畅了一点!
  • 在运行测试用例之前执行“健康检查”。即:对测试用例所依赖的所有服务「是否正常运行」进行事先检查。

鉴于端到端测试往往会运行很长时间,并且可能会给系统带来出乎意料的负载。

所以,这个方法不是万无一失的方法。但是,因检测出异常而跳过测试用例的执行,总比给团队一个「假失败」的结果要好。

问题 3:超时的设定时间不够长

场景

对于一个需要 15 秒才能完成的 AJAX 请求,你只等待了 10 秒。

症状

大多数情况下,测试运行良好,但在负载或特殊情况下它们就会失败。

解决方案

这里的困难点在于:由于异步性,我们无法提前就知道某个操作需要多长时间才能真正完成。

最明智的做法是:去检测(而不是等待)

去检测所要的操作是否已完成,以便测试用例可以尽快地继续执行下去。 而不仅仅是设置一个等待时长,然后一直等着这个时间点到期而 Time Out。

例如,当 XmlHttpRequest 返回时,更改生产代码以在 Javascript 的`Window` 对象上的全局设置标志并不难,这就构成了简单闩锁的基础。

你可以设置一个等待标志,而不是轮询 UI。 或者,如果你的 UI 给出明确的「操作忆完成」的信号,就请使用轮询。

Selenium RC 和 WebDriver 等框架提供了帮助类,使这变得更加容易。

问题 4:超时的设定时间太长

场景

通过轮询一段文本来等待页面加载完成,只是让服务器抛出异常并给出 500 或 404 错误,而文本永远不会出现。

症状

你的测试不断超时,可能让你的构建任务也持续超时。

解决方案

不要只轮询你想要的结束条件,还要考虑轮询众所周知的错误条件。

当你看到错误条件时,让测试失败并显示信息性错误消息。

由于这个原因,WebDriver 的 SlowLoadableComponent 有一个“isError”方法。你可以为 Selenium RC 将附加检查放在一个正常的 Wait里。

组织一个特攻队

当你的测试用例不稳定时,请进行一些根本原因分析,以了解它们为何不稳定。

为了有效地完成此类分析和测试稳定性改进工作,你可能需要其它团队的支持和帮助。 假如你是自己工作,或者在一个小团队中工作,这可能不会太难。但在在大型项目中,这可能会比较难。

所以,让一两个人不去开发功能,而是让测试运行更稳定,会让你的项目取得成功

你可能会想,这么做会导致编写生产代码的人力减少,团队会有生产力损失。

但从长期看,还是值得的。

因为这能让端到端的测试套件更稳定且有效,即:一旦「测试用例失败」,就是真正的「失败」。


原文作者: Simon Stewart
原文链接:My Selenium Tests Aren’t Stable!
发表时间:June 02, 2009