我正在尝试找到一种可以解决以下问题的工具：
我们的整个测试套件需要花费数小时来运行，这通常会使查找哪个提交破坏特定测试变得困难或至少非常耗时，因为在测试运行之间可能会有50到200次提交。在任何给定时间，只有非常少的破坏测试，因此与运行整个测试套件相比，仅重新运行损坏的测试非常快。
是否有工具，例如一个持续集成服务器，可以在测试正常的最后一个版本和测试不正确的第一个版本之间进行几次修订，从而重新运行失败的测试，从而自动找出测试从成功切换到哪个特定提交破碎。
例如：
测试A和B在修订版100中没有问题。测试A和B在修订版200中被破坏。
该工具现在应该使用修订版150运行两个测试。 然后如果是测试A被破坏，测试B在修订版150中是正常的，它可以继续检查测试A的修订版125和测试B修订版175，依此类推，直到每个破坏的测试可以通过某些特定的提交来解释。
对于单个测试，我可能会与git bisect一起破解某些东西。但是对于多次失败的测试，这可能是不够的，因为我们需要在两个方向上搜索许多修订。
答案 0 :(得分：4)
您使用的是git还是mercurial（请参阅：What is Mercurial bisect good for?）？
假设您的项目版本2.6.18有效，但“master”版本崩溃了。有时，查找此类回归原因的最佳方法是在项目历史记录中执行暴力搜索，以查找导致问题的特定提交。 git bisect命令可以帮助您执行此操作：[...]
来自：Finding Issues - Git Bisect。
基本上，您将两个修订标记为开始和结束，然后点击：
$ git bisect
然后运行测试，并根据是通过还是失败调用
$ git bisect good
或
$ git bisect bad
分别git将进行二分查找，总是将剩余的修订减半。我猜你可以轻松编写脚本。如果您使用svn，git可以轻松导入整个存储库。
这不是答案，而是建议 - 只测试每一次提交！今天，您可以轻松地对持续集成服务器进行集群，通过一组服务器来测试所有提交并不困难。