Testing 集成测试与测试覆盖率

我的公司有一个规则，即通过单元测试或集成测试达到75%的测试覆盖率。由于整个系统的复杂性，开发人员倾向于编写集成测试（例如，对正在运行的应用程序使用selenium webdriver），而不是承担模拟依赖服务/类的负担

我不是这方面的朋友，我想知道I-tests的测试覆盖率数据实际上意味着什么：

在我看来，测试应该定义预期的行为并测试它。如果一个i-test深入到应用程序中，通过许多服务，可能下到DB层，然后再返回，它将覆盖很多行，但是绝对不清楚这样一个覆盖行的预期行为是什么。因此，覆盖率数据的质量值得怀疑，更糟糕的是，它增加了维护工作

---

这个POV正确吗？当涉及到与管理层的讨论时，我如何支持它？

关于测试覆盖率的盲目百分比规则并不理想。集成测试就是一个很好的例子。如果有东西坏了，你能准确地说出是什么东西坏了吗？如果您有多个集成点（例如，单个请求访问数据库、web服务并发送电子邮件），该怎么办？有太多的事情要做，所以测试没有真正的意义

你能在不测试所有可能结果的情况下获得100%的覆盖率吗？你能写10000个测试，但仍然不能覆盖一个软件中最重要的类吗？盲目的度量是不好的，在质量上没有真正的结果

---

通常，更小、更离散的测试更有价值。我们通过剔除集成点并在测试中模拟它们来实现这一点。然后您可以设置场景，“如果数据库执行此操作，那么我的代码执行此操作。”这种类型的问题在内存中解决起来要比在可重复的基础上设置数据库执行此操作容易得多。如何在服务器断开连接时自动执行集成测试？那很难。剔除数据库处理特定的SQL异常更容易且可重复。

如果在截止日期前无法达到75%的测试覆盖率，或者即使达到了，剩下的25%又会怎么样，因此，您的公司不是专注于获得一个缺陷不太明显的产品，而是专注于测试覆盖率的百分比。尽管您使用selenium或任何所谓的方法，但请以可信的方式解释您的方法。

如何计算非插入指令代码的代码覆盖率？@edutesoy我不知道：我认为标准代码覆盖率与测试执行期间接触的代码行进行比较。但老实说，我不清楚测试覆盖率实际上是如何工作的。我完全同意：问题是我们没有干净的接口，对“集成点”（我最近学到的一个术语，我非常喜欢，因为它专注于I-tests的真正目标）没有清晰的概念。问题仍然是如何说服管理层（它发明并推广了当前的设置。我通常发现，必须向管理层传授测试指标。根据我的经验，管理层“走得太远了”了解他们真正的要求。测试的数量和%的测试覆盖率对测试的质量没有任何影响。这意味着人工代码审查。要做到这一点，请与他们坐下来，向他们解释这些概念。更好的是，向他们展示！演示各种测试场景。如果你不在鼓励这种双向对话的地方工作，那么我们出去了。