失败的自动化测试：如何区分已知和新引入的错误？

Posted 2023-02-23

【中文标题】失败的自动化测试：如何区分已知和新引入的错误？

【英文标题】：Failed automated tests: how to distinguish known and newly introduced bugs?

【发布时间】：2012-01-26 14:51:19

【问题描述】：

用例：Fitnesse 用于网站的自动化测试。

SUT（被测软件）包含一个已知错误。说，我们希望网页包含“更改已成功保存”字符串，但由于错误，该字符串丢失。所以在 Fitnesse 中，这个测试用例被标记为红色。

假设，在另一个测试用例中，我们期望网页包含“A user created successfully”字符串。它工作得很好，直到最后一次测试执行。所以，现在这个测试用例也被标记为红色。

所以，现在我们有两个测试用例的红灯：一个众所周知的错误和一个新发现的错误。问题是它们都被标记为红色。因此，当我查看测试结果时，我无法区分其中哪些是已知的和新的。

当然，我可以比较测试历史并查看两次运行之间的差异（有和没有新创建的错误）。

否则我可能无法执行具有已知错误的测试用例。

或者我可以调整它，使这个测试用例一直是绿色的，并在错误修复时更改它。

但这一切都很不方便。我想要区分两种错误（众所周知的错误和新错误），以便：

通过查看测试结果，我可以轻松地说：这是一个新错误，而且那些都是旧错误。例如：没有错误 - 绿色、已知错误 - 黄色、新错误 - 红色。

bug 修复后可以很容易地更改测试用例。

一般来说，验收测试（尤其是 Fitnesse）的最佳策略是什么？

【参考方案1】：

这里有一个微妙的区别：您谈论的是跟踪测试状态，而不仅仅是它是否是一个已知的错误。好的 CI 系统可以帮助您通过历史记录跟踪测试的状态，并让您知道它何时更改状态。 （昨天通过，今天失败。）好的 CI 系统也可以解决错误的失败，这样它们就不会混淆你的历史。 （我特别想的是我在其中做过的 Team City。）

对失败的测试有错误是另一个问题。正如 Barry 所提到的，命名约定会有所帮助。我还使用测试框架元数据通过在测试属性或属性中标记描述来帮助识别现有错误。

【参考方案2】：

据我所知，没有简单的方法可以区分“新”错误和预期错误，除非手边有一个已知问题列表。如果您使用命名约定，您可以快速列出已知会失败的测试，然后您可以快速扫描哪些错误不在该列表中 - I.E.它们是需要研究的新错误。

【参考方案3】：

这实际上是多个问题。我将重点介绍我认为运行 FitNesse 测试的良好做法。

我建议您在像 Hudson 这样的 CI 系统中运行测试。 CI 系统擅长跟踪每次运行所发生的情况。

为此，您需要采用 Hudson 可以跟踪的格式的结果。您可以使用 XSL 将 FitNesse Suite 运行的结果转换为 Junit 样式报告，然后利用 Hudson 跟踪 Junit 结果的能力。这为您提供趋势和图表。它还可以让您看到任何失败的年龄。这是我的做法：http://whotestedthis.squarespace.com/journal/2012/1/26/transforming-fitnesse-results-to-junit.html

【参考方案4】：

当我们记录一个确认的错误时，我们会在测试源代码的失败语句中添加一个#warning，以指示错误编号和对失败行为的（非常）简短的描述。如果我们不希望很快修复错误（例如，在几天内），我们会将测试隔离到一组预计会失败的测试中。我们会定期查看这些测试的历史记录，以确保它们没有开发出新的故障模式，并在错误修复后将它们移出隔离区。

正如 Jim Holmes 所说，一个好的 CI 系统（我们也使用 JetBrains 的 TeamCity）将以一种使这种事后分析变得容易的方式维护历史。