如何为硒（或类似产品）编写不会因微小或外观变化而失败的测试？

我花了大约一周的时间学习硒，并为即将推出的网站构建了一系列网络测试。非常好学习，我学了一些xpath和CSS定位技术。

不过，对我来说，问题在于，几乎没有什么变化会破坏测试-对div，id或有助于识别小部件的一些autoid数字进行的任何更改都会破坏任何数量的测试-这似乎非常脆弱。

那么您是否编写了硒（或其他类似的）测试，如何处理测试的脆性（或如何阻止它们变脆），以及将硒用于哪种测试？

Selenium的目的是创建UI驱动的集成测试。

集成测试可以验证系统中的所有组件一起部署时都能正常工作。集成测试不是足够的测试策略，并且会补充其他具有不同重点的测试策略，例如单元测试和验收测试。

UI驱动的测试本质上是脆弱的，尽管Selenium和Watir与早期的记录和回放工具相比有所进步。有几种方法可以解决此问题-以下是一些世界级专家的建议汇编：

不要试图从这种类型的测试中获得所有的测试范围。Robert C. Martin 认为集成测试的代码覆盖率应该约为20％。当输入距离多个应用程序层很远时，测试所有执行路径根本是不切实际的。

从单元测试和验收测试中获取大部分测试范围。在FinnNk的答案中查找Gojko Adzic文章的链接。Adzic反复争论要通过验收测试和绕过UI来测试业务逻辑。

但是仍然需要编写一些UI驱动的测试。除了“不要通过UI测试业务逻辑”之外，您还需要一些实用的建议。我会推荐Patrick Wilson-Welsh的博客作为起点。

一旦经过一个微不足道的数字，创建像这样的测试时，最重要的事情就是对称更改的想法-代码中的少量更改会导致测试套件中的更改也很小。

例如，假设您在100个测试中通过两个文本框收集某人的名字。如果您精明地编写这些测试（或者可能正在使用记录回放），那么您将有100个测试需要更改。相反，如果您抽象出一个“输入名称”步骤并在测试中使用它而不是直接使用硒，那么您只有1个位置进行更改。这将取决于您的上下文，您使用多少个抽象层-但是使用抽象将使您的测试可维护很长的路要走。

第二件重要的事情是确保您的选择器基于最重要且变化最小的事物。有时，这可能是id或类，也可能是元素中或元素周围的文本。总是喜欢最简单的选择器（例如id），但有时要实现此目的，您将不得不使用xpath之类的东西。

戈杰科·阿德齐奇有很多在他的博客很好的建议，当谈到这类测试-看看他的死亡的正弦和如何避免它尤其如此。

测试可确保代​​码的行为符合预期。如果您的测试定期中断，则说明该测试不是在测试正确的东西，或者开发人员不会在意这些测试。

我个人认为，如果<div>标签的存在破坏了测试，则该测试不必要地严格依赖于周围的标签，因此应采取更宽松的方法。