我应该继续注册失败吗？

Question

我正在为我维护的应用程序开发自动化回归测试套件。在开发自动化回归测试时，我遇到了一些几乎肯定是bug的行为。所以，现在，我已经修改了自动化回归测试，以避免注册失败 - 我故意故意允许这种不良行为通过。

所以，我对这个网站上其他人的意见感兴趣。显然，我会在缺陷跟踪中添加一个错误，以确保错误行为得到解决。但是，是否有任何令人信服的理由（无论哪种方式）改变回归测试以不断表明失败或者让回归测试中断，并且在我们能够修复缺陷行为之前不会失败？我认为这是另一类问题中的6个问题，但我在这里问，因为我认为其他问题可能会有所不同。

---

@保罗汤布林，

只要是明确的 - 我从来没有考虑删除的考验;我只是在考虑修改合格/不合格的条件，以便在我每次运行测试时都不会在我的面前抛出失败。

我有点担心从已知的原因反复失败，最终得到像C++警告一样的待遇。我认识那些在C++代码中看到警告的开发人员，他们会忽略它们，因为他们认为它们只是无用的噪音。我担心在回归套件中留下已知的失败可能会导致人们开始忽视其他可能更重要的失败。为了避免误解，我认为C++中的警告是构建强代码的重要帮助，但从我遇到的其他C++开发人员判断，我认为我是少数。

Answer 1

我会说“地狱呀！”。简单的事实是，它失败了吗？是!然后它应该被记录。通过允许失败的测试通过，你几乎可以妥协你的测试。

我个人关心的一件事是，如果我这样做，并且乘坐公共汽车，那么“修补程序”可能不会被删除，这意味着即使在“错误修复”后，该错误仍可能保留。

留在，更新项目的笔记，甚至移动的严重程度下降（如果可能），但肯定不打破正在检查破事的事;）

Answer 2

如果您停止测试它，您将如何知道它何时被修复，更重要的是，您将如何知道它是否会再次被破坏？我反对进行测试，因为您可能会忘记将其重新添加回来。

Answer 3

应该仍然是一个失败，如果它不做预期的事情。

否则，这太容易忽视了。保持简单 - 它可以工作，或者不需要。失败或成功:)

- Kevin Fairchild

Answer 4

失败的测试是一种光栅。破碎的代码和未完成的代码之间有区别，测试是否应立即解决取决于这种失败测试揭露的情况。

如果它坏了，你应该尽快修复它，而不是晚些时候。如果未完成，请在有空时处理。

在这两种情况下，显然你可以忍受它表现不好（现在），所以只要问题被记录下来，你可能不会对它感到厌烦，直到你有时间修复它。

Answer 5

虽然我同意保罗所说的大部分内容，但论证的另一方面是，严格来说，回归测试应该测试程序行为的变化，而不是任何旧的错误。他们专门告诉你什么时候你破坏了曾经工作过的东西。

我认为这可以归结为在这个应用程序上运行其他类型的测试。如果你有某种单元测试系统，那么对于这个测试来说，这可能是一个比较合适的地方，而不是回归测试（至少在bug修复之前）。但是，如果回归测试是您唯一的测试，那么我可能会离开测试。

Answer 6

我们在单元测试中添加了“打盹”功能。这使得测试可以用基本上说'忽略从这个日期起的X周失败'的属性来注释。开发人员可以注释一个他们知道一段时间内不会修复的测试，但是在将来不需要任何干预来手动重新启用它，测试会在指定时间回弹到测试套件中。

Answer 7

尽管最好在有错误时测试失败，但这通常是不切实际的选择。当首次将测试添加到某个区域时，特别容易陷入发现的错误，因此不能完成主要目标。而且，长时间失败的测试变得非常噪音，更容易忽略。

编写失败的测试是修复错误的一部分，并且在修复这些错误时非常重要。这应该由您当前的产品和质量优先事项决定。如果您碰巧将测试作为其他努力的副作用，那很好，但不应该被允许将您从实际的优先级中分散开来。

我会建议在发现任何bug的同时将测试改进为警告并向他们提交错误。这是一种广度优先的方法，可以帮助您完成当前的任务，同时还可以实际使用您学习的内容。当错误被安排修复时，测试可以很容易地变成真正的失败。

与其他受访者不同，我认为失败与警告一样容易被忽视，而培训团队忽略失败的成本太高而无法实现。如果您在此项工作中产生失败的测试，那么当任务正在改进时，您将摧毁回归测试套件的实用程序。