143

我们的开发团队一直在使用GitFlow分支策略，效果非常好！

最近我们招募了几个测试人员来提高我们的软件质量。这个想法是每个功能都应该由测试人员进行测试/QA。

过去，开发人员在单独的功能分支上处理功能，并develop在完成后将它们合并回分支。feature开发人员将自己在该分支上测试他的工作。现在有了测试人员，我们开始问这个问题

测试人员应该在哪个分支上测试新功能？

显然，有两种选择：

  • 在单个功能分支上
  • 在develop树枝上

在开发分支上测试

最初，我们认为这是必经之路，因为：

  • develop自开发开始以来，该功能已与合并到分支的所有其他功能一起进行测试。
  • 任何冲突都可以更早地被检测到
  • 它使测试人员的工作变得轻松，他始终只处理一个分支 ( develop)。他不需要向开发者询问哪个分支是针对哪个特性的（特性分支是由相关开发者独家自由管理的个人分支）

这样做最大的问题是：

  • 分支被develop错误污染。

    当测试人员发现错误或冲突时，他会将它们报告给开发人员，开发人员在开发分支上修复问题（功能分支在合并后被放弃），之后可能需要更多修复。如果可能的话，多个子序列提交或合并（如果再次从develop分支重新创建分支以修复错误）使得从分支回滚功能develop非常困难。有多个功能develop在不同时间合并到分支并固定在分支上。当我们想要创建仅包含develop分支中的一些功能的版本时，这会产生一个大问题

在功能分支上测试

所以我们再次考虑并决定我们应该在特性分支上测试特性。在我们测试之前，我们将develop分支的变化合并到特性分支（赶上develop分支）。这很好：

  • 您仍然使用主流中的其他功能测试该功能
  • 进一步的开发（例如错误修复、解决冲突）不会污染develop分支；
  • 在完全测试和批准之前，您可以轻松决定不发布该功能；

但是，也有一些缺点

  • 测试人员必须合并代码，如果有任何冲突（很可能），他必须向开发人员寻求帮助。我们的测试人员专门从事测试，不会编码。
  • 可以在不存在另一个新功能的情况下测试一个功能。例如，功能 A 和 B 同时都在测试中，这两个功能彼此不知道，因为它们都没有被合并到develop分支中。这意味着当两个功能都合并到开发分支时，您将不得不develop再次针对该分支进行测试。而且您必须记住在将来对此进行测试。
  • 如果功能 A 和 B 都经过测试和批准，但在合并时发现冲突，则这两个功能的开发人员都认为这不是他自己的错误/工作，因为他的功能分支通过了测试。沟通中有额外的开销，有时解决冲突的人都会感到沮丧。

以上是我们的故事。由于资源有限，我想避免到处测试一切。我们仍在寻找更好的方法来解决这个问题。我很想听听其他团队如何处理这种情况。

4

6 回答 6

110

我们这样做的方式如下：

在合并最新的开发分支代码后，我们在功能分支上进行测试。主要原因是我们不想在一个特性被接受之前“污染”开发分支代码。如果一个特性在测试后不被接受，但我们想发布已经在开发中合并的其他特性，那将是地狱。开发是发布版本的分支，因此最好处于可发布状态。长版本是我们在多个阶段进行测试。更分析：

  1. 开发人员为每个新功能创建一个功能分支。
  2. 功能分支（自动）部署在我们的 TEST 环境中，每次提交都供开发人员测试。
  3. 当开发人员完成部署并准备好测试功能时，他将开发分支合并到功能分支上，并部署包含 TEST 上所有最新开发更改的功能分支。
  4. 测试人员在 TEST 上进行测试。完成后，他“接受”故事并在开发时合并功能分支。由于开发人员之前已经在功能上合并了开发分支，我们通常不会期望有太多的冲突。但是，如果是这种情况，开发人员可以提供帮助。这是一个棘手的步骤，我认为避免它的最佳方法是保持功能尽可能小/具体。最终必须以一种或另一种方式合并不同的功能。当然，团队的规模对这一步的复杂性也有影响。
  5. 开发分支也（自动）部署在 TEST 上。我们有一个政策，即使功能分支构建可能失败，开发分支也不应该失败。
  6. 一旦我们达到功能冻结，我们就会从开发中创建一个版本。这会自动部署在 STAGING 上。在生产部署之前，在那里进行了广泛的端到端测试。（好吧，也许我夸大了一点，它们不是很广泛，但我认为它们应该是）。理想情况下，beta 测试人员/同事，即真正的用户应该在那里进行测试。

您如何看待这种方法？

于 2013-09-19T16:14:43.513 回答
43

在测试之前，我们将develop分支的改动合并到feature分支

不，不要，特别是如果“我们”是 QA 测试员。合并将涉及解决潜在的冲突，这最好由开发人员（他们知道自己的代码）完成，而不是由 QA 测试人员（他们应该尽快进行测试）完成。

让开发人员在 之上对他/她的分支进行变基featuredevel，然后推送该feature分支（开发人员已将其验证为在最近的devel分支状态之上编译和工作）。
这允许：

每次测试人员检测到错误，他/她都会向开发人员报告并删除当前的功能分支。
开发人员可以：

  • 修复错误
  • rebase 在最近获取的开发分支之上（再次确保他/她的代码与其他经过验证的功能集成在一起）
  • 推动feature分支。

总体思路：确保合并/集成部分由开发人员完成，将测试留给 QA。

于 2013-09-18T09:45:07.843 回答
14

最好的方法是持续集成，一般的想法是尽可能频繁地将功能分支合并到开发者分支中。这减少了合并痛苦的开销。

尽可能依赖自动化测试，并通过 Jenkins 的单元测试自动启动构建。让开发人员完成所有工作，将他们的更改合并到主分支中，并为他们的所有代码提供单元测试。

测试人员/QA 可以参与代码审查、检查单元测试并编写自动化集成测试以在功能完成时添加到回归套件中。

有关更多信息，请查看此链接。

于 2013-09-18T13:38:29.103 回答
9

我们使用我们所说的“金”、“银”和“铜”。这可以称为 prod、staging 和 qa。

我开始称其为大熔炉模型。它对我们很有效，因为我们在业务方面对 QA 有巨大的需求，因为与技术相比，需求可能难以理解。

当一个错误或功能准备好进行测试时，它会进入“青铜”阶段。这会触发将代码推送到预构建环境的 jenkins 构建。我们的测试人员（顺便说一下，不是超级技术人员）只是点击一个链接，而不关心源代码控制。此构建还运行测试等。如果测试（单元、集成、硒）失败，我们在此构建实际上将代码推送到 testing\qa 环境。如果您在一个单独的系统上进行测试（我们称之为铅），您可以防止将更改推送到您的 QA 环境。

最初的担心是我们在这些功能之间会有很多冲突。它确实发生了，功能 X 看起来好像功能 Y 正在破坏，但它并不常见并且实际上有帮助。它有助于在看似变化的背景之外进行广泛的测试。很多时候，您会很幸运地发现您的更改如何影响并行开发。

一旦一个特性通过了 QA，我们就将它移到“银”或 staging 中。运行构建并再次运行测试。每周我们将这些更改推送到我们的“黄金”或产品树，然后将它们部署到我们的生产系统。

开发人员从金树开始他们的更改。从技术上讲，您可以从分期开始，因为这些很快就会上升。

紧急修复直接放入金树中。如果更改简单且难以进行 QA，则可以直接进入白银状态，白银会找到通往测试树的途径。

在我们发布后，我们将黄金（产品）的更改推送到青铜（测试），以保持一切同步。

在推入暂存文件夹之前，您可能需要重新设置基准。我们发现不时清除测试树可以保持其清洁。有时功能会在测试树中被放弃，尤其是在开发人员离开的情况下。

对于大型多开发人员功能，我们创建一个单独的共享存储库，但在我们准备好后将其合并到相同的测试树中。事情确实倾向于从 QA 中反弹，因此保持您的变更集隔离非常重要，这样您就可以添加然后合并/压缩到您的暂存树中。

“烘焙”也是一个很好的副作用。如果你有一些根本性的变化，你想让它坐一会儿，这里有一个不错的地方。

另请记住，我们不保留过去的版本。当前版本始终是唯一的版本。即使这样，您也可能拥有一个主烘焙树，您的测试人员或社区可以在其中查看各种贡献者的交互方式。

于 2014-07-30T22:50:31.977 回答
3

在我们公司，我们不能使用敏捷开发，并且需要对业务的每一个变更进行审批，这会导致很多问题。

我们使用 GIT 的方法是这样的；

我们已经在我们公司实施了“Git Flow”。我们使用 JIRA，只有获得批准的 JIRA 票证才能投入生产。对于测试批准，我们通过创建一个单独的测试分支来扩展它。

处理 JIRA 票证的步骤如下：

  1. 从 Develop-Branch 创建一个新的分支
  2. 在功能分支上进行代码更改
  3. 从功能中提取更改到测试/QA 分支
  4. 业务批准后，我们​​将更改从功能分支拉到开发
  5. 开发经常在一个版本中进行，然后最后是 master 分支

将每个请求拆分为自己的功能可确保只有经过批准的更改才能投入生产。

完整的过程如下所示： 在此处输入图像描述

于 2020-07-01T09:08:41.267 回答
1

我不会仅仅依靠手动测试。我将使用 Jenkins 自动测试每个功能分支。我设置了一个 VMWare 实验室，在 Linux 和 Windows 上为所有浏览器运行 Jenkins 测试。它确实是一个很棒的跨浏览器、跨平台测试解决方案。我使用 Selenium Webdriver 测试功能/集成。我的硒测试在 Rspec 下运行。我专门编写了它们以供 Windows 上的 jRuby 加载。我在 Rspec 下运行传统单元测试，在 Jasmine 下运行 Javascript 测试。我使用 Phantom JS 设置无头测试。

于 2013-09-08T04:16:13.103 回答