我正在阅读隐式和显式等待,发现以下两个语句:


隐式等待不被认为是一种好习惯,因为不同的浏览器具有不同的加载时间,隐式等待会导致
在不同的浏览器中获得不同的结果。


我试图找到我读过此文章的博客,但找不到。但是,本文表达了类似的观点。

下一条引文来自:

与显式等待相比,隐式等待是透明且
/>不复杂。语法和方法比显式等待更简单。
隐式等待易于应用,但也带来了一些缺点。这会增加测试脚本的执行时间,因为
在恢复执行之前,每个命令都将停止等待规定的时间



问题:
使用隐式等待是否不好?一个人应该只使用显式等待吗?

注意:从Selenium文档中,很明显,一个人不应同时使用两个等待。我只问隐式等待。

#1 楼

简短的答案:是的,这是一种不好的做法,除非您有非常非常好的理由,否则请不要使用隐式等待。 (读这篇文章!)

我曾经在团队中有人认为这是个好主意,直​​到我开始研究为什么我们所有测试的起始时间都这么长。在我们的设置中的某个地方,隐式等待时间增加到了几秒钟,从而导致每次测试开始的时间变慢了几秒钟,甚至运行了更长的时间。我们检查了加载指示符是否不存在,导致使用了完整的隐式等待时间。


如果要检查是否缺少元素必须始终等到超时。


在某些情况下,如果您想查找相似的元素并且知道必须等待X个周期,可能会很方便地为每次搜索添加几毫秒的时间。增加隐式等待的步骤,然后将其设置回0,从不增加整个运行的时间。

FluentWait

如果您认为显式等待的语法详细说明一下,看看这个FluentWait示例。将此函数放在某个地方,并用它来查找需要等待的元素。

评论


只是一个愚蠢的问题。如果不鼓励使用findElement,则必须始终使用wait.Until(ExpectedCondition ...)的变体?

– FDM
2015年4月9日在9:52

@FDM哪里不鼓励findElement?如果您知道其中存在该元素,为什么还要等待?

– Niels van Reijmersdal
2015年4月9日在9:55

您发布的第一个链接:它说隐式等待仅发生在findElement方法中。由于您不确定页面的加载速度,因此您总是在隐式等待。

– FDM
2015年4月9日在10:07

我将等待页面上第一个使用的元素,或者等待该页面已准备好加载/绘图的另一个指示器,我们在JS框架中添加了isReady()函数,以检查在某些情况下页面是否已完全加载。从那一刻起,您应该能够知道哪些元素存在或不存在。

– Niels van Reijmersdal
2015年4月9日10:50在

如果页面上有更改,该怎么办?

– fijiaaron
17年2月10日在22:27

#2 楼

应该根据场景和要自动化的应用程序明智地选择硒中的等待使用方式。整个脚本。因此它并不总是明智的。

但是,只要知道特定元素的加载需要一些时间或希望页面加载(如果希望使用类似于此显式等待的情况),就可以使用显式等待。

#3 楼

在隐式等待的情况下,驱动程序将花费定义的时间移至下一步,而与找到或未找到元素无关,但在显式等待的情况下,驱动程序将在元素找到/满足条件时移至下一步,驱动程序将不等待定义的等待时间。因此我们可以说,在显式等待的情况下,等待时间为给定的0倍,但在隐式等待的情况下为常数。
答案是-显式等待时间可以节省时间。

评论


如何改善接受的答案?

–凯特·保罗(Kate Paulk)
18 Mar 16 '18在15:59