您的自动化测试目前已设置为回答“什么没有按预期工作？ ”这个问题。

现在，您希望他们回答“我还不知道什么不起作用？ ”

您的解决方案是更改自动化测试，以便它们以两种方式之一解决“已知”错误：

• 您可以注释掉找到每个已知错误的测试，这样它们就不会执行
• 您可以更改发现已知错误的测试以临时查找故障条件，而不是预期条件

小心使用这些解决方案中的任何一个！它们要求您在每次编写错误报告时不断更新您的测试。并且您必须记住，每当您想再次提出“什么没有按预期工作？”这个问题时，都要重新设置您的测试。

另一个技巧（我过去使用过）是让测试保持原样，但保存自动化测试的输出日志，并将其与之前的运行进行比较。该差异会告诉您“今天的运行与昨天的运行相比有什么不同？ ”如果日志构造正确（例如，仅记录失败，并且从不记录当前日期/时间或其他动态数据），这可能会有所帮助给你你需要的答案。

昨天的日志和今天的日志之间的差异将指示在今天的运行中发现的任何新错误，以及在今天的运行中修复的任何旧错误。

我没有使用 Fitnesse，但我处理过同样的问题。我认为有两个相关但不同的问题：处理长期错误和识别新故障。

处理长期错误

如果测试由于已知错误（预期失败）而失败，并且您知道该错误不会很快得到修复，您可能希望在解释测试结果时考虑到这一点。您的选择包括以下内容：

• 在您期望修复错误之前不要运行测试。如果测试需要很长时间才能运行，这可能很有吸引力。您可以通过注释掉测试来完成此操作。更好的是，您的测试框架可能允许您指定排除（“不运行”）列表。
• 运行测试但注释预期的失败，以便您可以将它们与其他失败区分开来。
• 运行测试但从结果中排除预期的失败。

识别新的故障

有时您想要识别上次运行中未发生的故障。 Jenkins提供了一种方法来做到这一点。任何管理大型测试套件的人都希望这样做。

我正在使用错误解决方法来处理测试自动化中的那些“长期”错误。我的工作流程如下：

1. 在错误跟踪器中创建错误。例如它的 id 是BUG10666

2. 创建一个名称中带有 bug id 的布尔常量：const bool is_ BUG10666_fixed = false;所有 bug 的常量都应该放在一个单独的文件中。

3. 使用解决方法使测试变为绿色

例如：

测试是：

String actual = "DZis is a Test";

字符串预期 = “这是一个测试”；

断言.Equals（实际，实际）；

解决方法后：

String actual = "DZis is a Test";

字符串预期 = “这是一个测试”；

if (is_BUG10666_fixed == false) // #Put bug description here的解决方法#

{

预期 = “DZis 是一个测试”；

} Assert.Equals（实际，实际）；

并且测试用例将是绿色的。开发人员解决问题后，更改常量值： is_ BUG10666_fixed = true 以禁用解决方法。

之后，您可以重构代码以删除 if 语句以获得解决方法： // If (is_ BUG10666_fixed == false)

并且由于您已将所有解决方法切换到单独的文件，因此您始终可以知道哪些解决方法已启用，哪些已禁用。

如果您的套件中有超过 30 个失败的测试，那么您肯定错过了一些新问题，因为您的测试被已知问题阻止了。

而且您总是可以增强这种变通方法，例如，拥有一系列变通方法，以便您可以在测试报告中自动打印所有使用的变通方法。

我报告了 99% 通过的自动化运行和使用的解决方法列表。如果其中一种变通方法发生了——那么我套件中的最后一个测试用例会变成红色并打印出所有使用过的变通方法列表。

如果您正在使用自定义框架和自定义报告/日志记录机制，则可以围绕“失败但已知的测试”开发一些额外的逻辑。一旦您的自动化脚本找到“失败的测试”，自定义报告算法应该从“已知问题”列表中进行查找。如果故障出现在您的已知问题列表中，那么您的报告算法可以在您的日志/报告中将此问题标记为“已知问题”。这种机制的优点是您不必更改您的自动化代码作为解决方法。但是，我不确定 Fitness 是否提供将故障标记为“已知问题”的机制