你很敏锐地认识到改变是自动化 UI 测试的致命弱点。这与开发/维护需要与应用程序的多个版本一起工作的共享库没有什么不同。

您可以遵循一些做法来减少（但不能消除）疼痛。在产品方面：

• 在你的 UI 中使用可预测的元素 ID，这样测试对 DOM 布局的依赖性就会降低。
• 使用可复用的组件来设计你的页面，使页面设计更加一致；这减少了测试需要理解的模式数量。
• 让您的 UI 开发人员参与测试设计，以便每个人都了解更改的影响。

在测试方面：

• 在元素 ID 可用时利用它们（并且当它们一致时；动态元素 ID 对测试人员不是特别有用）。
• 构建您的测试以利用页面设计模式。
• 让您的测试了解他们正在运行的产品版本，并使用版本信息标记您的测试。
• 考虑协商您打算支持的生产版本的数量。也许在只兼容最新代码和兼容任意版本之间存在一些中间立场。
• 考虑多少测试套件需要保持兼容。有些测试可能比其他测试更重要；只承诺完整测试套件的一部分的兼容性可能就足够了。

我假设你有充分的理由，无论是商业还是其他，这样做。从源存储库中提取适当版本的测试代码对我来说似乎更简单（您确实在源存储库中有测试代码并标记版本，对吗？），但无论如何......

我在这里看到两个主要选项。一种是包括版本检测和每个构建的内部功能列表。这里的好处包括使测试更简单，因为如果版本列表显示功能 X 不是其中的一部分，则脚本永远不会检查功能 X，以及“功能预言机”的存在。缺点是实现和维护更复杂，因为特性/版本矩阵必须是正确的并且是最新的，否则您可能有未测试的特性（如果 oracle 说该特性来自更高版本或缺少该特性完全）或测试失败（如果预言机说该功能来自太早的版本）。

另一种是在您的脚本中构建特征检测：检查特征 X 的链接是否存在，并仅在它存在时对其进行操作。优点包括 - 如果该功能存在，它将被测试，测试将永远不会在尝试使用不存在的功能时失败。缺点包括 - 这会更慢，因为总是有必要的检查时间来确定该功能是否存在，您将不知道版本中是否缺少某个功能（除非您同时使用这两种方法，这当然会让您两者的优点和缺点）。

无论如何，对应用程序对象的更改会给你一些非常丑陋的代码：而不是拉取引用特定对象的版本化代码，你的脚本代码最终会得到一个基于版本的决策树，或者该对象是否可以在它的任何一个下找到已知的名字。

老实说，我不确定拥有脚本代码库的单个分支和版本的优点是否超过了这种方法的缺点，但如果必须，我会使用如上所述的混合方法来处理它。

祝你好运。