彩票走势图

在软件开发人员抱怨单元测试的众多原因中，处理嘈杂的测试套件是最大的原因之一。而且，某个软件存在的时间越长，它的噪音就越大。

为了明确起见，“噪音”是指不断失败的测试，但是无论如何您都知道（认为）还可以，所以就顺其自然。或有时会失败且有时会起作用的测试，但没有人曾费心找出或修复它们。然后，由于代码已更改并且需要更新测试，因此某些测试确实失败了。所有这些噪音只是为了引起我们的注意而尖叫，但要注意的是，噪音越大，我们对它所做的任何有意义的事情就越不可能。

但猜猜怎么了？那些“失败但可以通过”的测试中的某个地方是您希望知道的一些实际问题。认为它就像尝试使用拼写检查器一样。如果您不坚持下去，将会得到您不关心的所有东西，例如特殊的行业用语，名称等，这些都不是真正的拼写问题。但是，隐藏在混乱中的某个地方却是您实际上犯下的令人尴尬的错误-您想要从那里出来的愚蠢的拼写错误的单词。当然，全球存在大量错误的拼写错误-但是与您的软件不同，那里并没有很多内在的风险，只是有些尴尬。

但是，单元测试套件通常处于相同状态。我们习惯于看到和忽略很多嘈杂的结果，不幸的是隐藏了我们需要知道和理解的真实结果。在许多组织中，要解决此问题，有人会不时安排一次冲刺以清理测试套件，时间间隔从几个月到几年。花费大量时间使套件尽可能人性化，但不可避免地问题很快就会回来，而且比您预期的要快。这会形成一个负面的反馈循环——没有人希望清理测试，因为他们认为下次会再次变得嘈杂。

答案是采用一种更实用的方法-从一开始就消除乏味，无用的清理冲刺，并避免使用嘈杂的测试套件。

尽量减少嘈杂的测试套件

为此，重要的是要了解单元测试失败时的含义。它归结为三个原因，并提供了简单的修复程序：

1. 代码已损坏。因此，请修复代码。（理想情况下，这是干净的测试套件告诉您的内容。） 

2. 代码已正确更改，现在测试已中断。因此，请修复测试以匹配新代码。（如果您的代码正在更改，则可以预期会发生这种情况。在处理代码时，有充分的理由进行测试。）

3. 测试是错误的，代码很好。因此，请修复测试。（或者删除它。但是关键是–不要忽略测试。）

现在。您可能在想–如果我的大量测试用例适合该第三类呢？这有什么帮助？因此，让我们分解一下。

产生噪声的原因通常归结为一些基本问题：不良测试，脆弱测试或不良主张。不良测试是指无法正常工作的测试。他们正在进行比他们应有的测试更多的东西，或者他们悬挂的数据不一致或可能因外部条件而发生变化。

为了将噪音降到最低，请确保对于每一个给您带来问题的测试（或者更好的是所有测试），您都能很好地回答以下两个简单问题：

1. 测试通过意味着什么？

2. 测试失败意味着什么？

如果对于任何测试，您对这两个问题都没有合理的答案，则需要改进。

改善脆弱性测试

易碎测试是那些容易打破的测试。同样，这通常是懒惰断言的征兆-仅检查事物（因为可以对其进行检查）并不意味着应该对其进行检查。每个断言应具有与要测试的代码满足的要求有关的真实含义。常见的罪魁祸首包括对日期/时间敏感的断言，操作系统依赖性，文件名/路径依赖性，第三方软件安装，合作伙伴API等。请确保您仅断言为进行良好测试所需的最低要求，并确保测试所需的一切都是源代码控制和构建系统的一部分。

其他错误的断言要么是持续处于故障状态，要么您不介意放开（“噢，别无所求，不要担心”），或者处于不断变化的状态（“以前很好，昨天失败了，但是今天很好！”）如果代码不断变化，可以在短时间内获得不断变化的结果，但是从长远来看，这是不可接受的。您需要了解为什么测试结果一直在变化，或者肯定为什么您认为可以失败并仍然可以发布。对单元测试（包括断言）进行同行评审将大大有助于永久解决此问题。（同行评审的另一个好处是？如果您处于合规环境中，测试是强制性监督的一部分，那么生存起来就容易得多。） 

评估损坏的测试确实是进行大多数清理工作的好地方。我想请您认真检查失败了几个月甚至几年的测试。问问自己，他们是否真的在增值。记住，您还是会忽略结果，所以说实话它们有什么用？删除您忽略的测试将使您可以将精力集中在重要的测试上，并实际上提高了总体质量。

因此，它变得相当简单（尽管可能需要花费最初的时间）。要进行清理，只需遵循以下最佳实践：

• 定期运行测试，以确保它们不会过时——使用代码进行测试。

• 删除始终失败的测试，或对其进行修复。

• 删除不断翻转状态（通过/失败）或拧紧测试的测试。

• 同行评审单元测试。

当然，不要忘记使用自动化来完成繁琐的工作，从而使您花在编写测试上的时间更有效率，从而使您可以创建噪音较小的测试。

使用测试自动化

利用自动化软件测试的优势，可以减少单元测试的工作量。如果您可以让自动化完成简单繁琐的部分（计算机擅长的部分），那么您就可以腾出时间来做需要实际的人类智慧（您擅长的事情）的事情。例如，让自动化创建您的xUnit测试用例的第一个工作通过（做起来非常繁琐的简单代码）。如果让工具自动生成吸气剂/装甲剂测试方法，则可以节省大量时间，可用于其他更有趣的事情。 

当我们对测试自动化变得更加复杂时，工具可以提供更多的帮助，进行单元测试中一些棘手的部分，例如创建和配置存根和模拟。您利用自动化的机会越多，单元测试所花费的时间就越少，也将减少很多乏味。如果您使用的是Java，请查看集成在Parasoft Jtest中的新的单元测试助手。它可以做所有这些事情，甚至更多，这使得单元测试不仅更加容易，而且更加令人愉悦。