自动化代码库（Selenium测试）已成为应用程序代码库的一部分。因此，随着每个具有专门项目需求的应用程序分支的开发，它也运行由我们为该特定分支开发的相应自动化测试。由于我们的质量检查数量有限，因此最终有时会在多个分支机构工作。并且在某个时间点（再次没有特定时间），构建工程师将应用程序代码库的一个分支推送到主干）。 br />考虑到我们在一个分支中开发测试（这意味着应用程序定位器，一些通用实用程序，一些测试），而该分支尚未进入主干，现在我们开始在新的应用程序分支上工作，我们需要部分代码，在其他分支开发。我们现在处于修复状态。
由于合并不是那么频繁，所以一旦将分支合并到主干中，最终会导致自动化代码发生更多冲突，如果合并频率更高，则可以减少冲突。而且，由于自动化代码库的缘故，我们不能要求合并到主干。在分支中应该有足够好的应用程序源代码，然后才能转移到主干。
所以我建议从应用程序目录中删除自动化代码。
并跟踪应用程序分支我们可以在质量检查自动化项目中有相应的分支机构。即应用程序分支Feature1，Feature2等在自动化项目中将具有对应的分支Feature1，Feature2等。
这样做将允许QA（这意味着我们）在需要时合并到我们自己的主干中，并消除了自动化代码何时进入应用程序主干的当前依赖性。
此时，我看到的唯一障碍是使QA自动化主干代码与应用程序主干保持同步，以便可以将其用于测试项目代码主干。但是，当我们更频繁地合并到QA时，自动化主干将对某些功能进行测试，而这些功能可能在应用程序主干中尚不可用。因此，那么-
我们应该在自动化代码库中维护一个与应用程序源代码主干相对应的不同分支。这样一来，我们仍然可以在需要时继续合并到自动化主干中，或者
我完全弄错了，有更好的解决方案吗？
#1 楼
好的，这正是我们以前的演出中遇到的情况。请允许我提供一些建议...首先，在致力于维护与多个开发分支的测试兼容性之前，请非常仔细地考虑。这样考虑：假设您有一个由5个手动测试人员组成的团队，以及一个要测试的主要dev分支。然后，SW团队宣布将拥有3个新的子分支，并希望您测试所有4个分支。您会说：“嗯……我仍然只有5个手动测试器，所以我希望再有15个测试器来处理负载。”自动化测试也是如此：要测试更多分支机构，您需要更多人。这会让你发疯。听起来这已经成为您公司的问题。
考虑到这一点，我建议您缩小承诺范围。致力于仅针对主要dev分支开发自动化测试。可以在其他分支上运行这些测试，但不能保证兼容性。
评论
肯定是我们过度承诺的情况。您的指针很好地描述了它。
–塔伦
2011年11月23日下午5:20
我要补充一点，在合并发生之前，您仍然需要就合并进行沟通。这样，您可以在其他分支上运行测试，以查看代码更新在合并之前在哪里破坏了您的测试，从而使合并后由于功能更改而导致测试维护的时间（理想情况下）为零（理想情况下）（因为您将拥有已经进行了更改）。
– Ethel Evans
11年11月29日在1:07
#2 楼
您已经说过，Selenium Tests，所以我假设所有自动化代码都是Selenium代码。在这种情况下，以与处理应用程序代码相同的方式处理自动化代码是错误的。因为如果测试用例流程（步骤）或定位器没有变化，则无需每次都更改代码。例如，代码库或数据库被更改，而不是UI。另一个示例是重新设计了UI，但所有这些定位器均保持不变。在这些情况下，即使背景发生了很多变化，自动化也可以正常工作。这引出了另一个问题，如果两个或三个团队并排工作并且定位器/ UI发生变化，那是那些分支怎么办？如何维护该代码？使用标签。如果自动化代码由模块分隔，并且定位器位于代码外部，则这很容易做到。您可能只标记了几个文件即可完成工作。
即使完成了所有这些事情，自动化新事物也会遇到一些问题。这是因为，正如某些人之前所说，两个团队之间的沟通问题。
#3 楼
我们保留与当前开发分支匹配的Selenium分支，并在开发分支进入生产时合并Selenium分支。在我看来，这听起来像您现在正在做什么。我们有单独的分支机构有两个原因。将测试放在源代码之外，合并测试代码不太重要。我们首先完成所有其他合并，然后再进行测试合并。我们通常只在一个主sprint分支上工作，实际上并没有您当前遇到的多个分支问题。我认为只要您不需要针对中继代码运行Trunk测试，您的方法便会奏效。我确实发现我们的测试中的prod分支并不是那么重要，因为它并不代表生产中的任何真实内容。
我唯一担心的是遇到一个严重的生产缺陷，并从树干上切下了一个新的分支来处理。当您尝试剪切一个新的自动化分支机构时，您可能会得到一个混乱的结果，而不是在您的新分支机构中使用一个可立即运行的可靠套件。
#4 楼
我认为您的方向正确。对于每个项目的自动化，我们都有自己的源代码控制。尽管这主要是使我们无法访问应用程序源代码（合规性要求）的简便方法，但它使我们能够以我们认为合适的任何方式来设置自动化策略。当我们尝试学习不同的东西时，为实验代码设置另一个分支实际上并不少见。不过，老实说，最近，自从我们切换到SpecFlow以及使用步骤范围处理步骤定义的方式以来，就没有太多需要创建单独的分支了。我敢肯定，如果我们要进行更大的高影响变更，我们可能会考虑削减新的分支机构，但是现在，即使是6个月以上的非常大的改进，我也没有必要这样做。评论
我正在考虑建议我们的测试在任何时候都应与主干代码兼容。必须维护多个自动化分支使我们发疯
–塔伦
2011年11月23日下午5:22
评论
您能否更具体地介绍您的分支策略？您在主干中的代码是Prod分支的一种吗？您是否从主干进行部署？是的，目前已设置好，它是生产分支，并已部署到主干。