我可以想到两种选择：
将测试留在测试集中。但是现在，每次运行测试集时，整个测试集都会失败，这可能会掩盖其他新引入的错误。
删除测试/将测试标记为预期的失败。然后，该错误的凭单将引用该测试，以便在修复该错误后也将启用该测试。这种方法的问题在于可能永远忽略该错误，并且质量检查不会推动开发。
#1 楼
在我工作的地方使用的方法使用的是三态结果：通过，警告或失败。我们通常会配置低优先级的bug会影响要警告的测试的情况，以便在纠正bug（可能已发布多个版本）之前，这组测试将报告警告，但不会影响其余的运行（因此其他更改）。要做到这一点需要花费一些工作和高度模块化的数据驱动框架，但是以我的经验，这是值得的。现在，大约有五十种这样的不同测试集运行，其中一些报告已知错误的警告，而另一些则运行干净。他们中的每个人都会在引入后的24小时内发现新的错误，除非某个错误将某个错误破坏到某种程度，使得自动化无法继续进行并且无法在一段时间内修复（由于明显的原因，任何完全破坏自动化的事情都是紧急情况） 。
具有足够模块化的测试，可以配置案例以报告警告并继续进行而不会导致下游影响，这是我选择完全避免这种二分法的方式。
#2 楼
我们使用一个系统来标记数据库中的已知故障，并带有指向我们的错误跟踪系统的链接。在错误跟踪系统中将错误标记为已完成后，将自动重新打开测试。我们甚至将其用于高优先级故障，从而使报告对于以后无关的提交来说是干净的。评论
出色的方法-我喜欢当错误被标记为已修复时重新打开测试的自动化。忘记它的机会越少越好。
– Mal Ross
2012年4月24日上午11:34
#3 楼
“最佳实践”的问题在于您的工作总是一个例外。其他答案也建议在代码固定后自动打开测试的方法。这比希望在代码修复后有人打开它要好得多，但是
在这种情况下，您如何报告未运行的测试？
测试/错误最终出现在发行说明中吗？
我们在测试脚本中添加了借口。
测试仍然失败并且在统计中
借口在最高层给出
分析（验证失败是否与借口相符）很简单
/>
失效的测试（不会长期修复）保持运行
当然可以借口
如果有多个测试同样失败的情况下，我们倾向于减少样本量，或将其余部分推至广告系列末尾，以免被跳过。自动。
我们开展了许多不同的测试活动。健全性和回归活动只能获得被证明是可靠的测试。那应该意味着像这里描述的那样的失败永远不会进入那些战役...
...所以我们仍然可以运行全自动测试来证明构建没有被破坏。
#4 楼
低优先级的修复程序将意味着该漏洞不是关键性漏洞，也不会在很大程度上影响系统。在这种情况下，在您提到的2个选项中，第2个选项看起来更好。如果您没有其他任何问题，选项1将是一种“错误警报”。错误跟踪系统应确保错误不会落入裂缝，并且在将来的发行版中始终可见。#5 楼
我们同时使用这两种方式。1将使更多的人关注该bug，因为报告中将包含FAIL，这也是一个缺点，因为高层管理人员可能希望获得干净的报告（我知道，我知道。 ..诚信，道德...）
2甚至有更大的机会让其他错误进入
那么该怎么办？我认为最好的折衷办法是从＃1开始，当您确定无法解决该错误时，请立即移至＃2并为此添加一个发行/测试说明。
评论
“但是现在每次运行测试集时，整个测试集都会失败，这可能掩盖了其他新引入的错误。”为什么会掩盖其他错误？@JoeStrazzere，因为人们会习惯测试套件的失败，因此可能不会费心去检查结果，而会错过套件中的另一项失败。
攻击问题的“可能不会打扰”的部分，而不是人为地消除真正的故障，可能更有意义。
@JoeStrazzere我和danio在一起。您只是通过尝试改变人们的行为来应对潮流。最好只是接受它并更改系统以进行补偿。