好的，这正是我们在旧演出中遇到的情况。请允许我提供一些建议...

• 首先，在您致力于维护与多个开发分支的测试兼容性之前，请仔细考虑。这样想：假设您有一个由 5 名手动测试人员组成的团队，以及一个要测试的主要开发分支。然后，SW 团队宣布他们有 3 个新的子分支，并希望您测试所有 4 个分支。你会说：“嗯……我仍然只有 5 名手动测试员，所以我需要 15 名更多的测试员来处理负载。” 自动化测试也是同样的情况：要测试更多的分支，就需要更多的人。

• 如果您商店的 SW 团队没有有效地传达合并状态，您将不断追赶他们的工作。这会让你发疯。听起来这已经是贵公司的问题了。

• 考虑到这一点，我建议您缩小承诺范围。承诺只为主开发分支开发自动化测试。提供在其他分支上运行这些测试，但不保证兼容性。

你说过，Selenium 测试，所以我假设所有的自动化代码都是 Selenium 代码。在这种情况下，以与处理应用程序代码相同的方式处理自动化代码是错误的。因为如果测试用例流程（步骤）或定位器没有变化，则无需每次都更改代码。

例如，代码库或数据库更改而不是 UI。另一个例子是重新设计了 UI，但所有这些定位器都保持不变。在这些情况下，即使背景发生了很多变化，自动化也能正常工作。这就引出了另一个问题，如果两个或三个团队并肩工作并且定位器/UI 发生变化，这些分支会怎样？如何维护代码？使用标签。如果自动化代码由模块分隔并且定位器位于代码之外，这很容易做到。您可以标记几个文件并完成工作。

即使在所有这些事情之后，自动化新事物也会存在一些问题。这是因为，正如有人之前所说，两个团队之间的沟通问题。

我们保留一个与当前开发分支匹配的 Selenium 分支，并在开发分支进入 prod 时合并 selenium 分支。对我来说，这听起来像你现在正在做的事情。我们有单独的分支有两个原因。将测试保持在源代码之外，并且测试代码的合并不太重要。我们首先完成所有其他合并，然后最后进行测试合并。

我们通常只处理一个主要的 sprint 分支，并且实际上并没有您目前遇到的多个分支问题。我认为只要您不需要针对主干代码运行主干测试，您的方法就可以工作。我确实发现我们测试的 prod 分支并不是那么重要，因为它不代表生产中的任何真实内容。

我唯一担心的是，当您遇到严重的生产缺陷并从主干切下一个新分支来处理它时。当您尝试削减一个新的自动化分支时，您最终可能会遇到一个混合包，而不是针对您的新分支的可靠的即时可运行套件。

我认为你在正确的轨道上。对于每个项目的自动化，我们都有自己的源代码控制。虽然这主要是一种让我们无法对应用程序源代码进行写访问的简单方法（合规性要求），但它允许我们以任何我们认为合适的方式设置自动化策略。当我们尝试学习不同的东西时，为实验代码设置另一个分支设置实际上并不少见。不过老实说，最近，自从我们切换到 SpecFlow 以及使用步骤范围处理步骤定义的方式以来，并没有太多需要创建单独的分支。我敢肯定，如果我们有更大的高影响更改，我们可能会考虑削减一个新分支，但现在，即使是一个非常大的、6 个月以上的改进，我也没有