开发团队承诺在“未来几个月”内修复这些问题，这是几个月前的事。
我应该编辑测试以通过（例如，注释验证）吗？
还是应该继续抨击开发团队，直到他们修复这些未成年人显示问题？在这种情况下，“最佳做法”是什么？
#1 楼
这里的一种可能性是在您的测试中内置将故障标记为“已知问题”的功能，然后在每次自动化运行时报告该故障。我在对user246链接的问题的回答中做了更详细的介绍-建议您在此处查看我的评论和其他回复。
#2 楼
您不应编辑要通过的测试。产品中仍然存在缺陷，因此运行测试并在这些点上使测试失败会继续提供未解决问题的数据。由于开发团队已经接受了错误并安排了计划（尽管（不是很牢固）要解决的问题，修改测试以不再报告缺陷似乎是不好的做法。如果错误被拒绝并确定为“无法修复”，那么您绝对应该编辑测试。
不应修改测试以掩盖程序中的错误。它还提供了错误修复时间的另一个数据点，因为您将看到先前失败的测试用例通过。
#3 楼
如果故障点仅与这些低优先级问题无关，那么您应该将它们留在原处，并处理显示为故障的这些“已知问题”。确保这些“故障”是仍然报告相同的低优先级问题，并且没有比最初报告的问题大。
并仔细检查它们。由于这些“已知问题”，通常较大的区域无法进行测试。如果他们阻止更深层次的测试，请考虑尝试提高优先级，并取消阻止未测试的部分。
#4 楼
我们正在为testng构建附加组件，以将带有@KnownFailure批注标记的测试作为跳过报告，并将其捆绑到单独的存储桶中。 @KnownFailure批注将需要一个票证＃，我们将能够通过报告对其进行跟踪。我们还在寻找一种检查票证是否已解决的方法，忽略@KnownFailure批注。并报告测试的真实结果。
#5 楼
编辑要通过的测试是不合适的；如果测试很早就失败了，并且意味着其他测试用例受到污染，则可能有增加重试或其他机制的余地，以便测试可以继续进行，并且增加更多价值-但请注意，这是在解决失败的问题。仍应报告。
您还可以执行其他操作，取决于结果的分析方式。我当前使用的测试系统将信息输入数据库，并且需要针对每个故障的跟踪标识符-一个脚本可以报告多个故障。
遇到已知故障时，我们有以下选择
什么也不做。有人需要每次查看故障并分配一个标识符。
在测试中添加一个临时的Bug标识符。有人需要确认故障机制是否匹配。
在测试中添加错误标识符。全自动。
全自动错误标识符很有用，但是您对脚本可以确定确切的故障模式有多自信？过去，由于错误地识别问题的方法，我们错过了新问题。
此外，将测试分组在一起的技术很有用。这样，您就可以将结果分为
回归：或应该起作用
破碎：完全不可靠
不可靠：失败率超过10％的测试。
通过这种方式分离测试，您可以看到新的失败（回归活动），意外的修复（破坏的活动），并且仍然可以在不可靠的脚本中发现主要的回归（不可靠的活动突然导致超过25％的失败）时间）
这些技术确实需要某种形式的简化分析前端（数据库可以完成-但是这个词会吓到人们）
评论
这可能对您有用：sqa.stackexchange.com/questions/2998/…为什么这么多低优先级验证点已被包含为硬断言？将它们覆盖为软断言，以使它们不会通过测试。