可维护测试自动化的 Git 分支策略

Git 在开发中的应用

首先，让我们考虑正在开发的产品的典型 git 策略。通常，开发管道被分解为几个工件。在最原始的层面上，有一个交付给最终用户的生产版本、一个我们进行最终回归测试的候选版本，以及一个包含开发中最新功能的开发版本。针对不同的环境，这可以分为更多类别，例如支持金丝雀发布、集成等等。这种分类是大规模软件开发的标准。

对于每个类别，我们在 git 存储库内构建分支。分支是我们在隔离的代码库中分支并独立推进开发的一种方式。当我们准备好时，我们可以向后和向前合并来自同一主线实例的其他分支。在开发过程中，每个环境都使用一个单独的分支。

Curiosity 在我们的开发环境中自己的 Git 分支策略遵循这个模型。首先，当开发人员开始开发新功能时，他们会从核心（主）开发分支分支出来。为此，开发人员可以并行工作，使用与其用户故事和任务相关的独立代码。一旦某个功能达到完成的定义，就会发出拉取请求，可以批准合并，以将其代码与自初始分支创建以来也已提交工作的任何其他开发人员的工作集成在一起。一旦构建了版本或冲刺的所有功能，就可以创建候选版本，在测试金字塔（单元、功能、性能、API 和安全性）中执行用户验收测试和回归。

随着持续集成的引入，通过启动沙箱环境并对代码执行测试自动化来持续测试每个代码签入也很常见。如果每次合并测试都通过，那么它就会集成到要发布的分支中。最后阶段是将发布候选分支移至生产分支。由此发布候选版本，通常带有与发布版本号相对应的适当标签。

几乎每个使用 Git 作为源代码控制的开发团队都应用了这种方法的一些变体。特定的策略将取决于环境的数量及其应用程序通过的测试层。合并是一个至关重要的概念，因为它通常是通过拉取请求来促进的，拉取请求使其他开发人员能够执行代码审查。开发人员可以检查即将合并的工作，批准或拒绝合并请求。这是创建高质量且可维护的代码库领域的强大助手。

测试自动化框架的 Git 策略

在理想的情况下，我们的自动化框架将驻留在同一个存储库中，因此将与生成的产品工件保持同步。然而，这很少可行，因为通常是一个单独的团队创建自动化，因此它驻留在单独的源代码存储库中。这意味着测试库必须与产品交付同步。

存储在 Git 中的测试自动化框架的初始策略通常围绕使用一条主线。当一名 SDET（测试中的软件开发工程师）在项目中工作时，这很好；然而，有效地扩展框架需要更简洁的分支策略。因此，我们将分支分解为开发中使用的类别：生产、候选版本和开发。每个功能都有分支，这次是针对我们的测试资产，创建功能分支，但生成每个自动化测试。

在此背景下，我们对自动化框架和 Git 开发环境使用类似的分支策略。首先，当 SDET 开始为新功能创建自动化（页面对象和测试）时，它们会从核心（主）分支分支出来。在这一点上，为开发功能分支创建标签也很有用。

一旦创建了具有足够测试覆盖率的自动化资产，就会发出拉取请求，可以批准合并，以将其代码与在其间提交工作的任何其他自动化工程师的工作集成在一起。在这种情况下使用分支意味着我们不会将非生产就绪自动化与持续集成管道中使用的核心自动化混合在一起。一旦为发布创建了自动化，就可以将其与自动化发布分支合并。

分支的使用允许我们执行代码审查以达到相同的效果，但对我们生成的自动化代码进行审查。这确保了新代码符合高标准，具有可维护的对象标识符和良好的架构。这是创建随时间扩展的有效自动化框架的核心方面。它还使我们能够区分生产就绪的自动化和进行中的自动化。此外，我们可以在每个分支中嵌入链接，以实现产品源代码和测试自动化代码之间的完全可追溯性。更好的是，如果测试分支遵循相同的约定，这意味着我们可以在源代码和自动化测试之间进行跟踪。

这使我们能够创建一个自动化框架，有效地将分支应用于测试自动化资产。请注意，这实际上与开发中使用的方法相同，但应用于我们的测试自动化框架。

在整个企业范围内扩展自动化

到目前为止，我们已经讨论了单个自动化框架的实用性。虽然测试自动化可以在整个企业的孤岛中成功实现，但最成功的自动化是自上而下领导的，并得到整个组织的支持。在这种情况下，每个团队创建自己的框架和相关实用程序是没有意义的；需要有一个清晰、连贯的战略，使采用无缝，并最大限度地提高战略投资回报。为什么要重新发明轮子？

对于大多数组织来说，敏锐的开发人员可能已经存在大量框架，他们已经构建了自己的框架和工具。在这种情况下，应该进行审查过程来确定框架的质量，以及它是否适合在整个组织中使用。通常情况下，非官方的公司框​​架已经获得了一些关注，成为事实上的方法。

自动化框架本身在很大程度上应被视为一个单独的产品线，包含与现有产品工具的集成、用于调用后端系统或协议的实用程序以及特定于组织内自动化的其他有用工件。然后，团队在自己的产品线上使用这样的框架，并嵌入相关的测试资产（页面对象和测试场景，以及产品的一些其他自定义实用程序）。即使在单个团队中应用自动化，这也是一个值得遵循的良好实践，因为它使框架与实际的测试逻辑代码分离和分解。

如果在整个企业范围内扩展自动化时存在卓越中心 (CoE)，则原始自动化框架应由该部门内的职能团队拥有。该团队负责提供框架中的必要实用程序、报告功能、集成和其他非功能组件。每个在项目中采用测试自动化的团队都可以利用这个框架。使用 Git 可以克隆中央存储库，并从中分支以采用该框架。每个团队都为他们正在测试的产品线嵌入自己的页面对象和测试场景。这为整个组织使用自动化提供了一种连贯的方式。