Web UI自动化不可靠。我认为可以提高Web UI测试的可靠性。这样的建议之一是在您的测试之上放置一个抽象层，以执行实际的DOM操作代码。但是页面的HTML经常会更改，并且测试仍然失败。由于您对抽象层进行了一次更改，因此无需花费太多精力来更新测试，但是您仍然需要进行此更改。

针对HTML更改采用的哪些实践会破坏您的自动化？

#1 楼

您提到了从框架中抽象测试代码。页面对象模式是可以完成此操作的一种方式，并且相当普遍。它在Selenium中很流行，但是可以应用于任何UI自动化：http：//code.google.com/p/selenium/wiki/PageObjects。

您可以避免使用包含整个路径的xpath （甚至是路径的一部分）到UI元素，以便如果父元素或祖先元素发生更改或移动，则您的测试仍然可以进行。您可以通过ID标识元素，从而即使元素类型或类或其他属性发生更改，您的自动化也不会中断。

您还可以教育开发人员有关其更改如何影响自动化的知识。我注意到的一件事是，初级开发人员（或不习惯大量QA或流程的开发人员）将对UI进行比通常所需更多不必要的更改。他们应该知道要给所有重要的元素ID，不要更改ID，也不要更改这些元素的基本行为，除非对于新功能而言是绝对必要的。教育开发人员的一种好方法是在签入新代码之前让他们运行自动化。我保证如果他们是在更改UI时必须更新自动化的人，他们会很聪明地避免不太多更改UI。

我看到的另一件事使UI自动化不可靠是计时问题。许多人使用显式等待元素，或者只是假设元素已加载并且可以正常工作。我喜欢隐式地等待任何元素出现在页面上，这意味着如果我尝试单击该元素，我将首先轮询该元素以确保它存在，然后一旦知道它存在就尝试单击它。我已经在Selenium顶部的抽象层中自动完成了此操作，因此它将始终等到元素首先存在。

#2 楼

Web UI自动化测试模仿手动操作。 UI自动化应该使用“ 2/8”规则作为参考。

我们应该在UI自动化的好处和成本保持之间取得平衡。