这里的一种可能性是在您的测试中建立将失败标记为“已知问题”的能力，然后在每次运行自动化时报告该问题。

我在回答 user246 链接的问题时更详细地介绍了 - 我建议您查看我的评论和那里的其他回复。

您不应该编辑测试以通过。产品中仍然存在缺陷，运行测试并让它们在这些点上失败继续提供问题未修复的数据。

由于开发团队已经接受了这些错误并安排（虽然不是固定地）解决它们，因此修改测试以不再报告缺陷似乎是不好的做法。如果错误被拒绝并决定为“不会修复”，那么您绝对应该编辑您的测试。

不应修改测试以掩盖程序中的错误。它还提供了修复错误时间的另一个数据点，因为您将看到先前失败的测试用例通过。

如果故障点仅与这些低优先级问题隔离，那么您应该将它们留在原处，并处理这些显示为失败的“已知问题”。

确保这些“失败”仍然报告相同的低优先级问题，而不是比最初报告的更大的问题。

并仔细检查它们。由于这类“已知问题”，通常较大的区域无法进行测试。如果他们阻止更深入的测试，那么考虑尝试提高优先级并畅通未测试的部分。

我们正在为 testng 构建一个插件，以将带有 @KnownFailure 注释标记的测试报告为跳过并将它们捆绑到一个单独的存储桶中。@KnownFailure 注释将需要票号，我们将能够通过报告跟踪它们。

我们还在寻找一种方法来检查票证是否已解决，而忽略 @KnownFailure 注释并报告测试的真实结果。