我同意您的测试需要持续维护（大多数测试自动化也是如此）。有一些策略可以组织您的 Selenium 测试，以便更容易维护，但它们取决于用户界面的编写方式、开发人员是否帮助维护测试以及用户界面更改的方式。事实上，用户界面变化越快，编写自动化测试的意义就越小。

对于任何类型的测试自动化，一个好的经验法则是慢慢开始，事先选择一些成功标准，然后尽可能诚实地评估这些标准。例如，当我第一次听说 Selenium 时，我担心维护成本和测试对时间问题的敏感性。我选择了我们应用程序的一小部分，它相当容易自动化，过去有很多错误，而且手动测试既费时又容易出错。编写测试后，我将它用于多个版本，并记录我花了多少时间更新测试以跟上应用程序的变化。我还多次调整测试以解决时间问题。经历了那段经历后，我喜欢 Selenium 用于选定的任务，但我永远不会用它来测试我们的整个应用程序；

最后，到目前为止，如果您在 SQA 中搜索“Selenium”这个词，您将找到 174 个问题。您可能值得花时间阅读其中的一些内容。

写得很好的答案的另一个想法：在问题中，作者提到了开发人员的反对意见：

采用 Selenium 测试进行更改（例如更改 button_id 或其他内容）将花费太长时间。

由于 UI 测试相对于 UI 的底层结构是脆弱的，因此 UI 自动化的成功取决于 UI 测试团队和开发人员之间的成功协作。假设您通过以下方式回应此反对意见：

适应按钮 id 不会有问题，因为 SW 团队需要为所有小部件建立标准命名约定，然后遵守该约定。

好吧，听起来是个合理的想法，不是吗？我遇到了对这个想法的 2 个回应：

（响应 #1）：哦，是的，这是个好主意。这将使每个人的生活更轻松。

（回应#2）：你是什么，疯了！？我有足够的事情要做。你只需要赶上我的发展。

如果您的商店中有很多响应#2 的人，那么 UI 自动化将非常困难。如果您的商店有很多响应#1 的人，那么您就有了战斗的机会。

因此，在决定 UI 自动化的合理目标时，请务必考虑到 devops 文化。

我完全同意 Phil 的说法，他说这听起来不像您在项目中使用 BDD/TDD。这通常包括开发人员在编写代码之前或之后编写的测试。

我也可以理解开发人员的部分不确定性。过去，我与许多开发人员就我使用代码来测试代码发生过争论。然而，对此的论点是，我不是用它来测试代码，而是检查那些正在工作且未更改的东西是否仍在工作。

你的硒测试应该首先用于测试/检查那些极其单调且需要经常做的事情。除此之外，请尝试将花费最多时间的检查自动化。

我可以完全理解标识符已更改的元素的挫败感。我的建议是，为其中的每一个创建一个库类（即：btnFriendlyName）并选择你要分配给它的值。使用页面对象模式，如果 ID 或 Name 确实发生了变化，那么更正您的自动化套件变得更加简单。

我也同意您将自动化与主代码分开。我听说很多其他人都在谈论将他们的测试与应用程序代码捆绑在一起，但是，根据我的经验，在它自己的版本控制系统中分离测试效果要好得多。

听起来你的开端很好！

让我暂时将 BDD 排除在外，并回答您关于 Selenium 自动化推荐场景的问题。我发现 UI 自动化应该关注两个主要领域以获得最佳投资回报率：

第一个是特定于 UI 的功能，例如由页面上的 javascript 驱动的任何内容（包括 ajax/xhtml 请求）或由 html 指示的任何内容：例如，texbox 上的 maxlength。这里有很多非常基础的测试，还有一些非常复杂的测试，比如你正在测试拖放功能等。

第二个是场景测试，涵盖用户通常会经历的端到端场景。这些较长的场景通常更难以在较低级别实现自动化 - 无论是单元测试还是针对 API 或 WebService 本身的测试。但是，这些测试有时可能很困难，具体取决于您正在测试的站点，它们可能需要额外的设置或配置，然后您还需要自动化这些过程。

一些确实不利于 UI 自动化的场景（但经常尝试）是深度现场验证（它太慢了）、安全测试（同样，太慢了，并且没有给你直接访问服务的灵活性） , 性能测试, 布局测试（尝试在不同的浏览器上验证布局，这更容易手动完成），本地化测试（您可以做一些事情，但总的来说这不是一个好主意 - 请参阅这篇文章：做你在你的自动化测试中验证文本的存在吗？）。

大多数其他测试可以在 UI 以外的级别上实现自动化。用于与其他 Web 服务、api、公共库等集成的集成测试可以在 API 级别自动化，有时甚至可以作为集成单元测试。可以直接使用 httpwebrequests 或使用将为您执行这些请求的现有工具来完成大部分安全测试。压力测试绝对不应该通过 UI 自动化来完成，尽管您可以将测量性能添加为 UI 测试的一部分。

如果您将 BDD 重新添加到等式中，那么在该过程中反对 UI 自动化的论点都只是语义。将自动化 UI 测试作为 BDD 或 TDD 流程的一部分是完全可以接受且相当普遍的。最大的区别在于，它们需要在运行测试之前编译代码和部署组件，但取决于您进行集成测试的程度，无论如何，情况可能已经如此。

其他反对 UI 自动化的论点，比如可维护性，都与你如何实现自动化有关。如果您想保护自己免受页面或行为或元素等的更改，请确保您使用适当的抽象层编写自动化测试。在 selenium 中，“页面对象模式”用于克服或减少您可能遇到的许多可维护性问题。