automated-tests - 您如何处理在开发过程中预计会失败的单元/回归测试？

Question

在软件开发过程中，代码库中可能存在已知问题的错误。如果测试编写得很好，这些错误将导致回归/单元测试失败。

我们的团队一直在争论如何管理失败的测试:

使用 REVISIT 或 TODO 注释注释掉失败的测试用例。

优势 :我们将始终知道何时引入了新缺陷，而不是我们已经知道的缺陷。

缺点 :可能忘记重新访问注释掉的测试用例，这意味着缺陷可能会从裂缝中溜走。

让测试用例失败。

优势 :不会忘记修复缺陷，因为脚本失败会不断提醒您存在缺陷。

缺点 :由于故障噪声，当引入新缺陷时难以检测。

我想探讨一下这方面的最佳实践是什么。就个人而言，我认为三态解决方案是确定脚本是否通过的最佳方式。例如，当您运行脚本时，您可以看到以下内容:

通过百分比:75%

失败百分比(预期):20%

百分比失败(意外):5%

您基本上可以使用一些元数据标记您预计会失败(由于某些缺陷)的任何测试用例。这可确保您在测试结束时仍能看到失败结果，但立即知道是否出现了您未预料到的新失败。这似乎是上述 2 个提案中最好的部分。

有没有人有任何管理这个的最佳实践？

Answer 1

我会把你的测试用例留在里面。根据我的经验，用类似的东西注释掉代码

// TODO:  fix test case

类似于做:

// HAHA: you'll never revisit me

严肃地说，随着您越来越接近交付，在代码中重新访问 TODO 的愿望往往会消退，尤其是在单元测试之类的事情中，因为您正专注于修复代码的其他部分。

将测试留在您的“三态”解决方案中。然而，我强烈鼓励尽快修复这些案例。我不断提醒的问题是，在人们看到它们之后，他们往往会掩饰它们并说“哦，是的，我们一直都会遇到这些错误......”

举个例子——在我们的一些代码中，我们引入了“可跳过断言”的概念——断言是为了让你知道存在问题，但允许我们的测试人员跳过它们进入其余的代码。我们发现 QA 开始说诸如“哦，是的，我们一直得到断言，但我们被告知它是可跳过的”，并且没有报告错误。

我想我的建议是还有另一种选择，即修复您的测试用例立即发现的错误。不这样做可能有实际的原因，但从长远来看，现在养成这种习惯可能更有益。