集成测试与测试覆盖率答案

【问题标题】：integration tests vs test coverage集成测试与测试覆盖率
【发布时间】：2012-10-31 15:44:28
【问题描述】：

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

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

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

POV 正确吗？在与管理层讨论时，我如何支持它？

【问题讨论】：

如何计算非检测代码的代码覆盖率？
@edutesoy 我不知道：我认为标准 LOC 与测试执行期间触及的代码行进行了比较。但老实说，我对测试覆盖的实际工作原理并不清楚。

标签： testing integration-testing code-coverage

【解决方案1】：

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

您能否在不测试所有可能结果的情况下获得 100% 的覆盖率？你是否可以编写 10,000 个测试，但仍然无法涵盖软件中最重要的类？盲目的指标是不好的，对质量没有真正的影响。

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

【讨论】：

我完全同意：问题是我们没有干净的接口，对“集成点”没有清晰的概念（我最近学到的一个术语，我非常喜欢它，因为它专注于真实的i-tests 的目标。）问题仍然是如何说服管理层（他们发明并促进了当前的设置。
我通常发现管理人员必须了解测试指标。以我的经验，经理们“走得太远了”，无法理解他们真正在问什么。测试数量和测试覆盖率与测试质量无关。这意味着人工代码审查。为此，请与他们坐下来，向他们解释这些概念。更好的是，向他们展示！演示各种测试场景。如果你不在鼓励这种双向对话的地方工作，那就滚出去。

【解决方案2】：

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

【讨论】：