我的公司有一个规则，通过单元或集成测试达到75％的测试覆盖率。由于整个系统的复杂性，开发人员倾向于编写集成测试（例如，使用针对正在运行的应用程序的selenium webdriver），而不是承担嘲笑依赖服务/类的负担。集成测试vs测试覆盖
我不是一个朋友，不知道对我的测试中的测试覆盖数据实际上意味着：
在我看来，测试应明确预期的行为和测试。如果一个i-测试深入到应用程序中，通过许多服务，可能直到数据库层再返回，它将覆盖很多行，但是绝对不清楚这种覆盖行的预期行为是什么。因此，覆盖率数据的质量是可疑的恕我直言，甚至更糟 - 增加维护工作量。
POV是否正确？谈到与管理层的讨论时，我该如何备份它？
关于测试覆盖率的盲目百分比规则并不十分理想。集成测试就是一个很好的例子。如果有什么事情发生，你能准确地说出什么事了吗如果您有多个集成点（例如，单个请求遇到数据库，Web服务并发送电子邮件）会怎么样？那里有太多的测试真的有意义。
如果不测试所有可能的结果，您是否可以拥有100％的覆盖率？你能写10,000个测试，但仍然无法覆盖一个软件中最重要的类？盲目的指标很糟糕，并没有真正的质量结果。
通常，进行更小，更离散的测试更有价值。我们通过剔除集成点并在测试中嘲笑它们来做到这一点。然后你可以设置场景，“如果数据库这样做，那么我的代码就是这样做的。”这种类型的问题在内存中解决起来要比设置数据库在可重复的基础上执行确切的事情容易得多。你将如何自动化一个服务器断开连接的集成测试？这非常困难。删除处理该特定SQL异常的数据库非常容易且可重复。
我完全同意：问题在于我们没有清晰的界面，对“集成点”没有清晰的概念（我最近学到了一个术语，我非常喜欢它，因为它专注于i测试的真正目标。）问题仍然是如何说服管理层（它发明并推广了当前的设置） – Bastl
我通常会发现管理层必须教授测试指标。根据我的经验，管理者“已经远离了旧的方式”去了解他们的目标真的在问，测试数量和测试覆盖率对测试质量没有任何影响，这意味着人类代码评估，为此，请坐下来，向他们解释这些概念，甚至更好地展示他们！如果你不在鼓励这种双向对话的地方工作，那么就出去吧。 –
如果您在截止日期之前达不到测试覆盖率的75％，或者即使达到了测试覆盖率，如果其他测试覆盖率达到25％，那么您的公司将不会专注于获得缺陷不太明显的产品而是专注于测试覆盖率的百分比。尽管您使用硒或任何所谓的方法，但可靠地解释了您的方法。
如何计算非检测代码的代码覆盖率？ – edutesoy
@edutesoy我不知道：我认为标准LOC与在测试执行过程中被触及的代码行进行比较。但说实话，我并不清楚测试覆盖的实际工作原理。 – Bastl