我读过很多地方,即使我偶尔使用露骨的睡眠陈述,它们在自动化测试中都是不好的做法。它们可能很烦人(在测试中创建不必要的等待),但我想不出任何示例说明它们实际上有害的原因。


睡眠陈述在自动化测试中造成伤害的一些例子是什么?


#1 楼

硬编码的睡眠语句通常应该表示测试期间应用程序中不存在的某种模拟延迟。嘲讽中实际存在的复杂性。

以网络延迟为例。您的生产系统通常需要4秒钟才能通过网络出去,获取一些数据,然后通过网络返回结果。因此,您只需对数据进行模拟,在4秒钟的延迟后将其扔回去。听起来很简单。

因为它很简单-几乎太简单了。如果您网络上的某些内容发生变化,则您的测试现在不准确。您看不到例程在异常沉重或异常轻的网络负载下如何反应。换句话说,您正在尝试测试无法控制的内容。您正在做一些可重复的操作(经过4秒钟的睡眠),但实际上是不可重复的(通过网络运行不会两次相同)。一个无效且可能经常变化的假设,那么该测试的可靠性又如何呢?

评论


+1这是我正在寻找的答案。我只测试了桌面应用程序,而对网络方面没有太多的关注,因此这可以帮助我了解可能出了什么问题。

– joshin4colours
2012年9月7日在1:03

极好的答案。但是,人们能做什么呢?如果带有常量的显式睡眠是不明智的,那么哪种测试方法会更好?它确实需要测试并通过,但是如果不通过常量“睡眠”怎么办呢?

–米奇
2012年9月7日15:27

我还要补充说,长时间睡眠同样有害。您可能不会因为没有等待而失败,但是您将使每个测试花费更长的时间,这可能会很快加起来,并且在运行持续集成时会适得其反。

–山姆·伍兹(Sam Woods)
2012年9月7日18:52

@Mitch您应该轮询某些状态。如果您的UI自动化在加载新页面并且显示并启用“继续”按钮之前无法继续进行,则应轮询按钮是否存在,然后轮询按钮的状态直至可见并启用。轮询只是在间隔很短(大约100毫秒)内重试。您仍将最终也要超时,因为在某个时候,如果页面加载时间太长会失败,并且您不想在按钮永不出现的情况下陷入无限循环。在Selenium中,这是“显式等待”。

–山姆·伍兹(Sam Woods)
2012年9月7日在18:58



@corsiKa我见过很多网站,其中隐式等待不起作用或对加载页面或元素没有任何影响。那么在这种情况下,您的建议是什么?我们可以不自动化该测试用例吗?或其他方式?

–Sagar007
16-3-13在7:35

#2 楼

当您在Sleep语句中使用的时间值不适用于当前测试实例时,会产生主要危害。

您的脚本可能会休眠4秒钟,因为那是花了一些时间创建脚本时显示的重要对象。然后,脚本会使用该新对象继续执行操作。

但是,当您重新运行脚本时,不能保证该对象会在4秒钟内出现。您的脚本(取决于4秒钟后出现的对象)可能会失败,运行amok或报告错误-所有这些都必须稍后进行分析。

您打算编写的脚本是“休眠直到所需对象出现”。有时,“睡眠4秒”不能很好地表示该意图。

硬编码的睡眠使您的脚本不能忍受变化的时间,更易碎,并且不太可能执行您想要的动作。

评论


您打算编写的脚本的+1是“休眠直到出现所需的对象”

–艾莉森
2012-09-10 13:34

#3 楼

在软件中,有两种方法可以等待事件发生。一种方法是使事件通知您。有时这是可能的,有时则不可能。另一种方法是轮询:请稍等片刻,检查事件是否已发生,如果尚未发生,请再次执行。事件已发生。当然,如果这样做,则最好等待足够长的时间。有时,明确的睡眠表示在等待时间的猜测。这种猜测在某种情况下可能很好,但在另一种情况下是错误的。当您移动到速度较慢的计算机,网络连接速度较慢或服务器因必须努力工作而速度下降时,您的猜测可能是错误的。

#4 楼

我进行了一系列约50次Selenium测试,耗时不到10分钟。通过编写测试,我能够将执行时间减少几分钟,从而无需sleep()即可知道何时到达输出。当我没有一个很好的方法来真正监视我正在测试的事物的状态,何时真正完成其工作时,就测试它是否正确。使用sleep()等于“您准备好了吗?您准备好了吗?” @Dmitry Zhariy指出,在测试中增加睡眠会导致延迟。这不好。您的测试应始终尽可能快地运行。如果项目的运行不可避免地会出现延迟,请照做(但请尝试看看是否可以找到使它们运行得更快的方法。)

#5 楼

好吧,当测试浪费您的时间时,我认为那是有害的。但是,这取决于。
示例:您有多个测试环境。 MachineA是高性能的真实计算机。 MachineB –是位于南极洲中部的远程服务器上的慢速虚拟机。

在MachineA上,您需要1秒钟。睡觉。在MachineB上,您需要10秒。因此,您在代码中使Sleep(10s)浪费了MachineA性能。

因此,现在您的测试时间取决于实验室中最慢的计算机。
假设您有100项测试,并且延迟了10秒。在高性能工作站上,每次运行100 * 10 = 1000秒= 17
分钟的浪费时间。

在我以前的项目中,我们不得不与Sleeps进行很多斗争,并将1200个测试的测试执行时间从12小时减少到9小时。我曾经使用过的同事提早来到工作场所,并没有等待2-3小时才能完成测试套件。

但是无论如何,我们留下了一些无法快速修复的睡眠。