SUT（被测软件）包含一个已知的错误。说，我们希望网页包含“成功保存更改”字符串，但是由于该错误，此字符串丢失。因此，在Fitnesse中，此测试用例标记为红色。
假设，在另一个测试案例中，我们希望网页包含“用户创建成功”字符串。在最后一次测试执行之前，它工作得很好。因此，现在这个测试用例也被标记为红色。
因此，现在我们为两个测试用例开了红灯：一个众所周知的bug和一个新发现的bug。问题是它们都标记为红色。因此，当我查看测试结果时，我无法区分其中哪些是已知的和最新的。
当然，我可以比较测试历史记录，并查看两次运行之间的差异（有无新创建的错误）。
或者我可能不会执行带有已知错误的测试用例。
或者我可以对其进行调整，以使该测试用例始终为绿色，并在修复错误后进行更改。
但是这一切非常不便。我想要的是区分两种错误（一个众所周知的错误和一个新错误），以便：
通过查看测试结果，我可以轻松地说：这是一个新错误而且那些很旧。例如：无错误-绿色，已知的错误-黄色，新错误-红色。
修复错误后，很容易更改测试用例。验收测试，尤其是Fitnesse？
#1 楼
当前，您的自动化测试已设置为回答“什么没有按预期方式工作？”现在您希望他们回答“我不知道什么在起作用”这一问题关于？”
您的解决方案是更改自动测试，以便它们通过以下两种方式之一解决“已知”错误：
您可以发表评论找出所有已知错误的测试，以使它们不执行
您可以更改找到已知错误的测试以临时查找失败条件，而不是预期条件
请谨慎使用这些解决方案！它们要求您每次编写错误报告时都要不断更新测试。而且，您必须记住，每当您要再次问“什么不能按预期工作？”问题时，都要重新设置测试。
还有另一个技巧（我过去使用过）保留测试不变，但保存自动化测试中的输出日志，并将其与之前的运行进行比较。该差异会告诉您“今天的跑步与昨天的跑步相比有什么不同？”如果日志的构造正确（例如，仅记录故障，而从不记录当前日期/时间或其他动态数据），则可以为您提供所需的答案。
昨天的日志和今天的日志将指示今天运行中发现的所有新错误，以及今天运行中已修复的所有旧错误。
评论
乔，谢谢您的想法。在Fitnesse中自动比较两个输出的最佳方法是什么？我知道如何在Fitnesse UI中进行比较，但结果不是用户友好的...
–乔什
2012年1月26日15:03
抱歉，乔什，我还没使用过Fitnesse。我的回应是基于我多年来使用的许多其他测试工具和框架。希望具有更多Fitnesse知识的人可以提供具体帮助。
–乔·斯特拉泽（Joe Strazzere）
2012年1月26日16:02
我们的测试框架专门允许三种测试执行状态：PASSED，FAILED和KNOWN_ISSUE。 KNOWN_ISSUE表示测试未按预期进行。为此，我们将已知问题与测试执行步骤联系在一起。 （由于全部在C＃中，因此我们可以动态查找已知问题以查询其状态）。
–斯蒂芬·格罗斯（Stephen Gross）
2012年1月26日22:23
斯蒂芬，谢谢您的反馈。是否有可能在Fitnesse中具有三种状态？
–乔什
2012年1月27日上午8:55
#2 楼
我没有使用Fitnessfite，但是已经解决了同样的问题。我认为有两个相关但截然不同的问题：处理长期错误和识别新故障。处理长期错误
如果测试由于已知原因而失败错误（预期的失败），并且您知道该错误将很快被修复，您在解释测试结果时可能需要考虑到这一点。您可以选择以下选项：
直到您期望修复此错误后，才运行测试。如果测试需要很长时间才能运行，这可能会很有吸引力。您可以通过注释掉测试来完成此操作。甚至更好的是，您的测试框架可能允许您指定排除（“不运行”）列表。
运行测试但注释预期的故障，以便您可以将它们与其他故障区分开。
运行测试，但从结果中排除预期的失败。上一次运行。詹金斯提供了一种方法。管理大量测试套件的任何人都想这样做。
评论
user246，是的，您的所有建议都有意义，但是我想清楚地表明发生了什么事情。没有错误-绿色。已经已知的错误-黄色，新的错误-红色。
–乔什
2012年1月26日15:38
#3 楼
我正在使用错误解决方法来处理测试自动化中的“长期”错误。我的工作流程如下：
在错误跟踪器中创建错误。例如，其ID为
BUG10666 创建一个名称为bug id的布尔常量：
const bool is_
BUG10666_fixed = false;用于bug的所有常量都应放在单独的文件中。 使用替代方法使测试变为绿色
例如：
测试为：
字符串实际= “ DZis是一个测试”；
期望的字符串=“这是一个测试”；
Assert.Equals（实际，实际）；
解决方法之后：
实际字符串=“ DZis是一个测试”；
预期字符串=“这是一个测试”;
If（is_ BUG10666_fixed == false）// #Put bug说明的解决方法在此处＃
{
=“ DZis是一个测试”； < brass
}
断言等于（实际，实际）；
，测试用例将变为绿色。
开发人员修复问题后，请更改常量值：
is_ BUG10666_fixed = true 禁用解决方法。
之后，您可以重构代码以删除解决方案的if语句： ，那么您始终可以知道启用了哪些解决方法以及禁用了哪些解决方法。
如果套件中有30多个失败的测试，那么您肯定会错过一些新问题，因为测试被已知问题所阻止。
您总是可以增强此变通方法，例如，具有一系列变通方法，以便可以在测试报告中自动打印所有使用的变通方法。
我报告了99％通过的自动化运行以及已使用的解决方法列表。
如果发生了一种解决方法–那么我套件中的最后一个测试用例将变为红色，并打印所有已使用的解决方法列表。
#4 楼
如果您使用的是自定义框架和自定义报告/日志记录机制，则有可能围绕“失败但已知的测试”开发一些其他逻辑。一旦您的自动化脚本发现“失败的测试”，自定义报告算法应从“已知问题”列表中进行查找。如果该故障出现在您的已知问题列表中，则您的报告算法可以在日志/报告中将该问题标记为“已知问题”。
这种机制的优点是您不必更改自动化代码即可解决。但是，我不确定健身是否提供了将故障标记为“已知问题”的机制
#5 楼
解决难题的一种方法是在运行后将结果导出到电子表格中，并使用宏/公式比较输出。在测试历史记录页面上，选择文件>另存为浏览器，然后选择单页（不是整个网站）
在excel中打开该文件
我通常使用文本到使用点作为定界符的列中
然后您可以使用结果列来查看结果
复制并粘贴到主列表中进行比较进一步提高水平，然后在另一张纸上使用数据透视表进行比较。一旦设置了数据透视表，就可以轻松更改其使用的数据。
数据透视表的第二个用途是将所有方便的数据集添加到报表中！
评论
天真的问题：这有关系吗？您不希望所有测试都是绿色的吗？这将使它变成浅红色而变成深红色有什么区别-它们都表示故障？根据上述问题，捕获到的更改似乎是由于自动化故障（包括错误警报）引起的。如果您不知道更改，并且自动化套件检测到故障，则需要手动验证这些错误的故障。当开发人员不传达代码中更改的ID时，我也遇到过类似的UI问题。
菲尔，我们有数百个测试用例。自动化套件每天晚上运行。因此，早上我们想看看情况是否有所变化。说，我们看到了75个红色测试用例，我们不能轻易地说出它们是已知的bug（我们不必对其进行任何处理）还是新的bug（应将其写入bug跟踪器）。