单元测试和集成测试的代码覆盖率报告是分开的，还是两者都有一个报告？

应该为单元测试和集成测试提供单独的代码覆盖率报告，还是为两者提供一个代码覆盖率报告？

其背后的想法是，代码覆盖率使我们能够确保我们的代码已被尽可能多的测试所覆盖（无论如何，现在无论如何机器）。

拥有单独的报告更方便我们了解单元测试未涵盖的内容以及集成测试未涵盖的内容。但是这样一来，我们看不到总覆盖率。

最重要的是，您需要拥有并分析合并的（总）覆盖率。如果考虑到这一点，这是正确确定风险优先级并集中精力进行测试开发工作的最自然的方法。

综合覆盖率为您显示的代码没有覆盖测试的所有，即是最危险的，需要先进行调查。单独的覆盖率报告在这里无济于事，因为它们无法让您确定代码是否经过某种方式测试或根本没有测试。

单独的覆盖率分析也可能很有用，但最好在完成组合分析后再进行，并且最好也包含分析组合覆盖率的结果。

单独的覆盖率分析的目的与组合的目的不同。单独的覆盖率分析有助于改善测试套件的设计，与之相反，组合覆盖率分析则旨在决定无论如何都要开发的测试。

“哦，这个差距并不能弥补，因为我们忘记将简单的单元（集成）测试添加到我们的单元（集成）套件中，让我们添加它” –在这里，单独的覆盖和分析是最有用的，因为结合起来可以掩盖差距您想要涵盖的特定套件。

从上面的角度来看，尽管也希望获得组合覆盖率分析的结果，以便分析棘手的案例，但这仍然是理想的。考虑一下，有了这些结果，由于有了有关“合作伙伴”测试套件的信息，您的测试开发决策可能会更有效。

“这里有一个差距，但是开发一个覆盖它的单元（集成）测试确实很麻烦，我们有什么选择？让我们检查合并的覆盖范围……哦，它已经在其他地方覆盖了，也就是说，在我们的套件中覆盖它是”至关重要。”

您没有提到您的测试工具。许多工具具有“合并”功能，可让您汇总多个运行或套件的结果。如果要使用汇总覆盖率指标，请探索覆盖率工具中的合并功能。

现在，我们可以谈谈房间里的大象吗？

没有勺子。而且没有“总覆盖率”。至少，没有简单的一个。

覆盖率是一个易于理解的指标，旨在帮助您了解测试套件的范围，深度和范围。但是，就像任何简单的基准测试一样，很容易将目标固定在此值上，作为“完全测试”的某种神奇护身符。

假设您已经实现了“ 100％测试覆盖率”的荣耀。好极了！但是，这是什么意思？100％的代码行都经过测试，对吗？那这条线呢？

launch_missile = launch_authorized and launch_cmd_given else previous_launch_status

“覆盖”该行很重要-但不是很多，因为存在多种条件True或False具有某种可能性，但是您不太可能已经测试了这些条件的所有组合。即使该行被覆盖了十几次，如果其中一种情况相对不常见，您也无法接近测试实践中可能发生的所有实际结果。为了使这一点更清楚，一个更综合的示例：

engage_laser = (laser_armed and safety_disengaged) or random.random() < 0.0000003

要真正详尽地测试它，您必须覆盖几次？您需要覆盖几次以结合程序中的所有其他变量（具有它们自己的，可能同样很少见）的概率对其进行测试？

我并不是说覆盖率指标没有用。他们实际上很棒。他们关注以下关键问题之一：我的软件系统受到了多大的测试？他们帮助从“我们进行了一些测试”过渡到“我们进行了彻底的测试”。

但是，当您使用“综合评分”时，现实情况是您的评分通常是针对“语句覆盖率”而不是“条件”，“谓词”或“路径”覆盖率。因此，无论您的总得分为您提供了多少数字，它都不太可能真正为您测试正在测试的程序潜在状态和状态组合的数量。在努力提高覆盖率时，请考虑同时测量谓词覆盖率。这将使您对测试范围更加真实（几乎总是无比清醒）。