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

Question

使用案例：Fitnesse用于自动测试网站。

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

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

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

当然，我可以比较测试历史记录，看看两次运行之间的区别（有没有新创建的bug）。

或者我可能不会执行已知错误的测试用例。

或者我可以对其进行调整，以便此测试用例始终为绿色并在修复错误时进行更改。

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

1. 通过查看测试结果，我可以很容易地说：这是一个新的bug，而且它们已经过时了。例如：没有错误 - 绿色，已知的错误 - 黄色，新错误 - 红色。

2. 修复错误后，很容易更改测试用例。

一般来说，验收测试的最佳策略是什么，特别是Fitnesse？

Answer 1

这里有一个微妙的区别：你在谈论跟踪测试状态，而不仅仅是它是否是一个已知的错误。良好的CI系统可以帮助您通过历史记录跟踪测试状态，并在状态发生变化时通知您。 （昨天通过，今天失败。）良好的CI系统也可以解决错误的失败，因此他们不会弄乱你的历史。 （我正在考虑Team City，我已经完成了这项工作。）

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

Answer 2

据我所知，没有简单的方法来区分“新”错误和预期的错误，除了方便地列出已知问题。如果您使用命名约定，您可以快速列出已知它们将要失败的测试，那么您可以快速扫描列表中没有的错误--I.E。它们是需要关注的新bug。

Answer 3

这实际上是多个问题。我将重点关注我认为运行FitNesse测试的良好实践。

我建议您在像Hudson这样的CI系统中运行测试。 CI Systems擅长跟踪从运行到运行的情况。

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

Answer 4

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

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