我的公司有一个规则是通过单元测试或集成测试达到 75% 的测试覆盖率。由于整个系统的复杂性，开发人员倾向于编写集成测试（例如，针对正在运行的应用程序使用 selenium webdriver），而不是承担模拟依赖服务/类的负担。
我不是那个朋友，我想知道 i-tests 的测试覆盖数据实际上意味着什么：
在我看来，测试应该定义预期的行为并对其进行测试。如果 i-test 深入到应用程序中，通过许多服务，可能到 DB 层并再次返回，它将覆盖很多行，但绝对不清楚这种覆盖行的预期行为是什么. 因此，覆盖数据的质量是有问题的恕我直言，而且——更糟糕的是——增加了维护工作。
那个POV正确吗？在与管理层讨论时，我如何支持它？
关于测试覆盖率的盲目百分比规则并不理想。集成测试就是一个很好的例子。如果有东西坏了，你能准确地说出是什么坏了吗？如果您有多个集成点（例如，单个请求访问数据库、Web 服务并发送电子邮件）怎么办？那里发生了太多事情，以至于测试没有真正的意义。
您能否在不测试所有可能结果的情况下获得 100% 的覆盖率？你是否可以编写 10,000 个测试，但仍然无法涵盖软件中最重要的类？盲目的指标是不好的，对质量没有真正的结果。
通常，进行更小、更离散的测试更有价值。我们通过存根集成点并在测试中模拟它们来做到这一点。然后您可以设置场景“如果数据库执行此操作，那么我的代码执行此操作”。这种类型的问题在内存中解决比在可重复的基础上建立一个数据库来做那个确切的事情要容易得多。您将如何自动化集成测试服务器断开连接？这很难。存根处理特定 SQL 异常的数据库更容易且可重复。
如果你无法在截止日期之前达到 75% 的测试覆盖率，或者即使你达到了，那剩下的 25% 会怎样，所以你的公司没有专注于获得具有不太明显缺陷的产品，而是专注于测试覆盖率的百分比。尽管您使用硒或任何所谓的东西，但仍以可信的方式解释您的方法。