测量代码覆盖率的典型工作流程

Question

我在工作中出现了一种情况，这让我质疑了我在测试跨多个测试驱动程序应用程序的代码覆盖率时执行的工作流程。

这是工作流程准确...

1. 编译能够测量代码覆盖率的应用程序的特殊版本。
2. 运行应用程序以生成代码覆盖结果文件。
3. 合并代码覆盖率结果文件以测量代码库（单元，集成，回归等）测试套件的代码覆盖范围。
4. 报告合并文件的总体结果。

似乎人们正在为每个测试应用程序生成单独的报告，这给出了覆盖范围的分散数字，本子报告中的一些，另一子报告中的一些，其中的重叠部分是不明确的。

所以我的主要困惑是围绕第3点，以及它如何与多个测试应用程序以及代码覆盖率工具的设计有关如何汇集/合并来自各种测试的贡献。

仅仅从某些角度来看，我关注的是一种语言，一种代码库的修订版本以及多种测试应用程序，它们正在运行该代码库。关于“代码覆盖工具的设计”，我正在寻找生成报告的开发人员的观点，而不是关于结果文件格式的内部细节以及关于如何实现合并而是更概念化的细节可以说，开发人员通过工具的UX设计开展一系列的动作。我想更好地理解代码覆盖工具产生的工件，以及它们是如何产生并最终融合在一起的。

Answer 1

如果工具不同意如何以集体合并信息的方式表示信息，则无法合并范围信息。

这意味着您几乎无法将多种语言工具的覆盖率信息结合起来，因为大多数测试覆盖率工具供应商仅为一种语言制作工具。

将单个工具产生的信息合并为一个语言，并且更容易将来自一个工具的信息与针对特定程序实例的多个测试运行相结合，显然更容易。

如果应用程序在测试过程中发生更改，您也有问题。您可能拥有昨日的应用程序的覆盖范围信息，以及今天的新信息。你能安全地合并这些数据吗？大多数情况下不会，因为代码更改可能会对程序功能产生任意的影响。真正复杂的程序分析可以合并这些覆盖数据;我还没有看到任何可以做到这一点的生产测试覆盖工具。

（我的公司使测试覆盖工具可以处理上述所有情况，除了跨应用程序更改...因为这真的很难:)。