我的工作情况刚刚出现让我质疑我对测量跨多个测试驱动程序应用程序的代码覆盖率所执行的工作流程的理解。
此工作流程是否准确......
似乎人们正在为每个测试应用程序生成单独的报告，这些报告给出了覆盖范围的分散数据，一些在此子报告中，一些在另一个子报告中，其重叠是模糊的。
所以我的主要困惑在于第3点，以及它与多个测试应用程序的关系以及代码覆盖工具的设计，以及各种测试的贡献是如何汇集/合并的。
仅仅从某种角度来看，我专注于一种语言，一种代码库的修订版，以及运行该代码库的多个测试应用程序。并且关于代码覆盖工具的设计＆＃34;我正在寻找生成报告的开发人员的视角，而不是结果文件格式的内部细节和有关如何实现合并的详细信息，而是更为概念性的逐步操作集开发商凭借工具进行工作。 UX设计可以这么说。我想更好地理解代码覆盖工具产生的工件以及它们如何起源并最终融合在一起。
答案 0 :(得分：0)
如果工具未就如何以信息可以集体合并的方式表示信息达成一致，则无法合并覆盖范围信息。
这意味着您几乎无法将多种语言的工具的覆盖率信息结合起来，因为大多数测试覆盖率工具供应商只为一种语言制作工具。
将一个工具生成的信息组合成一个语言显然更容易，甚至更容易将来自一个工具的信息与特定程序实例的多个测试运行相结合。
如果应用程序在测试过程中发生更改，您也会遇到问题。您可能拥有昨天应用程序的覆盖率信息，以及今天的新信息。你能安全地合并这些数据吗？通常不是，因为代码更改会对程序功能产生任意影响。真正复杂的计划分析可以合并这些覆盖数据;我没有看到任何可以执行此操作的生产测试覆盖工具。
（我的公司制作的测试覆盖工具可以处理上述所有情况，除了应用程序更改之外......因为这很难：）。