测试时间长时如何保持行李箱稳定？

我们提供三套测试套件：

• 一个“小型”套件，只需几个小时即可运行
• 耗时数小时的“中型”套件，通常每晚（每晚）
• 一个“大型”套件需要一周以上的时间才能运行

我们也有很多较短的测试套件，但在这里我不关注它们。

当前的方法是在每次提交到干线之前运行小型套件。然后，中型套件每天晚上运行，如果早晨发现它失败了，我们将尝试找出应归咎于昨天提交中的哪个，回滚该提交，然后重试测试。对于大型套房，只执行每周一次而不是每晚一次的类似过程。

不幸的是，中型套件确实经常失败。这意味着后备箱通常是不稳定的，当您要进行修改和测试时，这非常烦人。这很烦人，因为当我从后备箱中退房时，我无法确定它是否稳定，并且如果测试失败，我也无法确定它是否是我的错。

我的问题是，是否存在一些已知的方法来处理此类情况，以使行李箱始终处于最佳状态？例如：“提交到一个特殊的预提交分支，该分支将在每夜经过时定期更新中继”。

它是像SVN这样的集中式源代码控制系统还是像git这样的分布式源代码控制系统有关系吗？

顺便说一下，我是一名初级开发人员，但更改功能的能力有限，我只是想了解是否有办法解决我遇到的这种痛苦。

解决不稳定性的根本原因的唯一方法是将代码解耦，以使更改更加隔离，如其他答案所建议的那样。

但是，作为一个单独的开发人员，如果您想要一个更稳定的构建供您自己使用，则相对来说很容易解决。您无需花费任何技巧，而只需将通过通宵测试套件的最后一个构建拉入工作树即可。如果您可以为每个更改创建功能分支，则从最后的稳定版本中分支出来。

是的，您的树会落后几天，但是大多数时候都没有关系。对稳定的版本进行工作，以使您知道所做的更改破坏了所有测试，然后在签入之前更新到最新版本并进行常规集成。然后，在签入之后，再次备份到上一个稳定的版本。

您仍然必须进行混乱的集成工作，但是我喜欢这种方法的地方是它将集成工作隔离到更方便的时间，并在不方便的时候为我提供了稳定的代码库。与其他人相比，当我的更改可能使构建中断时，我有一个更好的主意。

我知道您正在尝试避免这种情况，但是真正的见解是要意识到您的代码库存在严重问题：您需要运行整套测试，而这需要一周的时间才能确保您的代码稳定！

解决此问题的最有利方法是开始将代码库和测试分离为（独立的）子单元。
这有很多优点：

• 这些单元中每个单元的测试都将运行得更快（根本就是更少），并且如果独立单元或下游单元之一出现问题，它们也不会中断。
• 测试失败将被定位到特定的单元，这将使查找问题根源变得容易得多。
• 您可以分离不同单元的VCS位置，以便您的“稳定”分支可以是每个单元的最新经过成功测试的构建的“挑剔”组合，从而使一两个损坏的单元不会破坏您的“稳定”版本的稳定性。

在另一方面，您的VCS结构的管理将变得更加复杂，但是在整个星期的测试过程中，我认为您可以承受痛苦！

我仍然建议以某种形式使用“稳定”和“开发”分支策略，但是有很多方法可以解决，您可以选择最适合您组织的方法（具有固定修订版的元存储库指向每个单元都有单独的存储库，一个稳定分支和一个dev分支，一个功能分支....）

对于SVN，我不了解“预提交”之类的东西。我认为测试失败时可能会产生提交和回滚。正如doc-brown所说，唯一的方法是在一个临时分支上提交，然后再将其与trunk合并。

我认为使用git或mercurial之类的分布式工具是可行的。使用“测试”存储库和“稳定”存储库。您推动测试代表，每晚进行测试，如果一切正常，则从测试推动到稳定。否则，您将回滚测试代表。当您从测试版本推向稳定版本时，我有点不确定版本历史记录的样子，但是我认为这样做可以排除损坏的回滚内容。首先进行一点试验是最安全的。

另一种选择是每晚测试每个人的本地后备箱。然后，允许通过测试的人员在早上将其推送到中央服务器。

恕我直言，这与您使用的VCS没有关系。使用“被测”分支可能是解决方案，也可以使用集中式或分布式VCS来实现。但说实话，我认为您所处的状况中最好的是尝试优化中级测试套件（似乎它包含最重要的测试），以便其运行速度更快，因此您可以将其用于预提交到主干测试，就像您现在使用“小型套件”进行测试一样。

失败的中级测试：在大多数情况下，相同的测试会失败吗？

如果出现故障，是否总是有相同的相关测试失败？

如果为true，则可以选择一些经常失败的中等测试（针对每种错误类别进行一次测试），然后在较小的范围内执行它们。

大多数测试集成测试都使用真实的数据库吗？如果是这样，是否可以将其替换为具有模拟数据库的单元测试？

您需要使测试运行更快，没有其他方法可以使该圆圈平方。

考虑一下问题：您要确保在签出时拥有有效的代码。当然，您可以推迟提交并进行分支直到发布之前，但这只会将问题的出现推迟到集成为止。在这种情况下，每次合并后都需要运行为期一周的套件吗？方法学不是解决方案，解决方案纯粹是技术性的。

这是我的建议：

1）尽可能使测试处于大气状态，并最大程度地重用环境。

2）获得一个测试套件场来运行它们。如果最终只有8个大模块而不是50个，则可以启动一堆Amazon EC2竞价型实例并并行运行整个套件。我敢肯定这会花费一些钱，但是会节省大量的开发人员时间。

在您的问题中，理所当然的关键是所有提交都必须通过测试。尽管这是一个很好的遵循规则，而且似乎有些道理，但有时却不切实际。您的案例就是一个例子（尽管MadKeithV确实有道理），而且我可以想象保留一个VCS分支，这样如果开发者之间没有足够的合作，那么可能很难做到原始。

实际上，您想要以某种方式知道哪些提交通过或失败。您建议的“预提交分支”将起作用，但是开发人员在进行提交时可能需要开发人员付出额外的努力，这可能很难销售。

一种可能更容易的类似方法是，让人们随心所欲地断开主干，并为未中断的提交创建分支。自动脚本可以在对主干进行提交时进行提交，对它们运行测试，如果通过则将其添加到分支中。

或者，您可能太荒谬了，并拥有一个脚本，该脚本在文本文件中列出了传递的提交（它本身可能受版本控制）。

或者有一个批处理系统，它接受对分支/修订的请求（从树中的任何地方进行测试），并对其进行测试，如果它们通过，则将其提交到主干（或另一个分支）。