在UI自动化脚本中使用硬等待有什么问题？

Question

• 我总是在人们抱怨的地方继续提问 或流利的等待不是一直在工作所以寻找其他一些 解。在大多数情况下，在等待2或之后的硬等待 3秒问题得到解决。

• 但仍然决定使脚本更快更快 如果使用硬等待几秒钟后你的脚本不太可靠 他们真正需要的是我的想法。

  我知道我的答案的解决方案不是任何代码，但是要真正理解他们在自动化脚本中使用硬等待是否有任何严重危险？ 对我来说，他们对明确和流利的等待同样重要。

Answer 1

硬或隐式等待是不可取的，因为它们会给自动化套件增加不必要的执行时间。如果您的测试套件很小，不能定期运行或者您没有任何时间限制，那么可能会接受隐式等待。

在大多数现实场景中，非常需要快速测试执行周期，如果您在每次提交分支或执行大型测试套件时执行测试，则添加几个2/3秒等待会相当快。

我认为如果明确的等待不能正常工作，那么它们要么是：

1. 写得不好
2. 没有给予足够的时间

前者更有可能。

Answer 2

使用＆＃34;等待的危险＆＃34;或Thread.Sleep()更确切地说，您不确定您的病情是否得到满足。在UI测试中，您通常会添加睡眠，因此UI将满足某些条件，例如要加载的页面，要显示/启用的元素等等。

当您使用Thread.Sleep()时，您需要将其设置为最长时间，这样您才能确保满足您的条件（即使您无法确定＆＃39;压力＆ ＃39;情况 - 网络负载等）。所以你浪费了你的时间和资源，使你的自动化可扩展性降低，灵活性降低（对某些人来说是另一种危险......）

所以我会说，如果你不能为你的等待添加一个条件Thread.Sleep()很好（虽然不太可读），否则它只是一个不好的做法。