人们如何维护他们的测试套件？

我尤其对以下方面感到好奇：

1. 您怎么知道您的测试用例是错误的（或已过期）并且需要修复（或丢弃）？我的意思是，即使一个测试用例变得无效，它仍然可以通过并保持沉默，这可能使您错误地认为您的软件可以正常工作。那么，您如何认识到测试套件中的此类问题呢？

2. 您怎么知道您的测试套件已不再足够，应该添加新的测试用例？我想这与需求更改有关，但是是否有任何系统的方法来检查测试套件的适当性？

简短的答案：使用有助于维护测试用例质量的已知工具，例如以下代码覆盖率和代码质量工具：Cobertura，PMD，Sonar等，它们将帮助您注意到程序的关键组件未经过足够的测试。另外，编写集成测试，该测试最有可能在出现问题时首先中断。

长答案：

您怎么知道您的测试用例是错误的（或已过期）并且需要修复（或丢弃）？我的意思是，即使一个测试用例变得无效，它仍然可以通过并保持沉默，这可能使您错误地认为您的软件可以正常工作。那么，您如何认识到测试套件中的此类问题呢？

• 使用Cobertura这样的代码覆盖工具，您可以检测到给定类或复杂方法的测试用例不再足够。您无需在任何地方都达到100％的代码覆盖率，在大多数情况下，这将很难实现且不一定有用；但是应该对程序的最关键方面进行测试，并至少保持80％的代码覆盖率。
• 通过使用连续构建和集成工具（例如我非常喜欢的Jenkins），结合Sonar插件，您可以设置触发器，以将电子邮件和其他类型的警报发送给负责最新更改的人员。各种图形和统计信息（Sonar还使用Cobertura等许多其他工具）帮助代码审阅者和测试用例开发人员专注于关键问题。

您怎么知道您的测试套件已不再足够，应该添加新的测试用例？我想这与需求更改有关，但是是否有任何系统的方法来检查测试套件的适当性？

我为第一个问题写的内容是第二个问题的答案的一部分。我还将在此处添加以下几点：

• 除了测试用例之外，还要编写集成测试用例（如果需要，也可以编写“业务”用例）。这些最有可能首先更改/破坏，因为它们通常取决于多个类/方法。而且由于它们经常断裂，因此被遗忘的可能性较小。根据我的个人经验，唯一有助于编写好的测试的方法/方法是“ 测试驱动开发”。特别是如果编写测试用例的人与编写测试用例的人不是同一个人。使用TDD编写好的测试用例也需要时间，但是结果，至少对我来说，是非常令人满意的。
• 每当出现错误时，请编写修复程序及其附带的测试用例。测试用例应仅涵盖此特定的错误。由于您已经完全覆盖了负责该错误的代码，因此不应再次出现。

确实没有任何方法可以确保您的测试用例正确，除了在创建它们时要非常集中精力-了解需求，理解代码并确保它们同意。有一个测试套件的一点是，你只需要做这一次，从此你可以重新执行的测试和检查，他们通过，而没有一个测试套件，你将不得不集中真的很难所有的时间，即每当对代码库执行任何操作时。但是必须首先确保做正确的事情的根本问题仍然存在-计算机根本不够智能，无法减轻我们的任务。

因此，（1）如果您的测试套件不完整，则没有简单的方法可以看到它。代码覆盖率分析可以证明某些代码行从未执行过，即，该套件在某种程度上存在缺陷，但不足之处并不严重，也无法证明其足够。即使100％的代码覆盖率，您也不能保证所有相关状态该系统的状态被执行，并且由于可能存在的状态的组合数量，因此对于任何现实的系统而言，都无法实现完整的状态覆盖。确保您的测试用例至少对检查您要检查的事物正确的一种好技术是编写测试，验证它确实确实失败，编写/更改代码，然后验证它现在可以通过。因此，人们对测试驱动的开发充满热情：它使您可以完全确定单个测试可以做正确的事情，如果以这种方式创建整个代码库，即使在大型系统中，也可以获得类似的置信度。

（2）每当需求发生变化时，测试套件通常就会变得不够用-您不必猜测。如果客户希望某些特定的行为发生变化，并且您的测试在更改前后都可以成功，那么显然他们没有在使用这种特定的输入/输出关系。

至于没有测试覆盖率或您不知道覆盖范围的遗留系统，则没有正式的证据，但是（根据父母的意见：遵循个人意见！）从经验上讲，测试很有可能是不足够的。当测试被认为是事后，可选的，质量提高但并非真正必要的活动时，它往往是不完整和不系统的，因为确保测试与代码库保持一致的动机是不在那里。