我们使用大量分支（相当传统的主线模型）进行开发，事实证明，它作为一种组织事物和保持开发人员在大型团队中高效的方式非常有效。在将它们推回主线之前，我们有 QA 测试开发分支，这确保了主线始终稳定。
现在有一些与测试相关的有趣问题。最常见的情况是：假设测试人员在测试过程中遇到错误，该错误已被标记为已修复。那是因为修复失败（在这种情况下他们应该重新打开错误），还是因为修复尚未到达正在测试的分支？
作为 perforce 用户，我们正在考虑通过 perforce 作业解决这些问题。虽然它是一个相当“原始”的工具——它或多或少地为此提供了底层功能，但不是一个简单的界面，尤其是供测试人员使用。所以我想知道是否有更多用户友好的方法，或者完全不同的方法（我不认为在这种情况下“避免分支”对我们来说是一个实际的答案！）
在多个分支机构执行有效 QA 的最佳实践是什么？有没有什么好的工具可以为这些问题提供自动化和支持？
有时在开发分支上进行一次测试，并在合并到发布分支后再次进行。但这是一个过程选择，而不是要求。
如果您只从“主线”分支发布，您可能会考虑更改您的 QA 流程，以便仅在将更改合并到发布分支后进行测试。并依靠开发人员在合并前后测试他们的更改。这个比较典型。
就你现在所拥有的而言，听起来可能每个开发人员都有一个分支（只是猜测）。并且您针对每个开发分支提交错误。我会认真考虑改变这个过程。它是不可维护的，并且在合并后将是非常具有挑战性的跟踪错误。
正如 TrueWill 所建议的那样，建立一个持续集成将是一个好主意。通过频繁（每日）构建来补充它。然后让 QA 测试构建。
如果 qa 在主分支中发现错误，并且在 dev 分支中已修复，则：
至于其他情况，请尝试像这样锻炼场景（这里有一段错误生命周期）。为何时测试和测试什么准备场景，通信 qa-dev 应该是什么样子。把一切都写下来。这将是你的测试过程。让 QA 遵循它（并在适当的情况下进行开发）。可能你不会马上涵盖所有情况，所以随着时间的推移改进你的过程。
至于大型多分支项目。也许考虑雇用测试经理/测试负责人/或任何你想称呼这个角色的人。负责管理 QA 工作的人。准备测试策略。准备测试计划。与开发团队协调 QA 工作。确保适当的沟通。此外，此人可以管理不同分支机构之间的 QA 工作。在具有并行分支的大型复杂项目中，QA 需要良好的管理（与其他人一样）。
至于工具可能很少，但我只使用 HP Quality Center 和 HP Quick Test Pro。QTP 是测试自动化软件（记录和回放、数据驱动、脚本化 - VB）。QC 是测试（手动和自动）、缺陷的存储库，也可以保存需求、测试结果。它可以跟踪需求测试覆盖率和测试缺陷链接（实际上是测试运行缺陷，但您可以从测试运行跳转到测试）。
此外，您可以在其中定义周期和发布，例如，它可以是每个分支的周期和每个代码发布的发布（每个发布都与给定的周期相关，因此很清楚发布了哪个分支代码）。或者你可以用不同的方式映射它。
问题是，软件要花钱。我的意思是真的钱。这是一个承诺。