如上图所示，所有的测试用例都会有一个函数调用的路径。我们把这些调用路径一一记下来。对于新版本所作的改动，所有与之相关的上层调用的测试用例都能够准确地选出来，这样我们就能用这些准确的测试用例来覆盖这次改动所产生的影响。毫不相关的测试用例则不会被选出来。从而用较小的成本完成这次改动所需要的回归测试，既省时省力又保证较高的测试质量。
图 4. 覆盖率分析举例
图片4
如上图所示，在版本更新过程中受到影响的测试用例为 Test Case1， Test Case2， Test Case3 覆盖了 12 个 Node，在版本更新过程中的更新点是 4，其中被覆盖到的为 3，还有 1 个更新点没有被覆盖到，现有测试用例集合的更新覆盖能力为 75% 。这样，我们知道上一个版本的测试用例设计不够充分尚有程序模块没有被任何已有的测试用例所覆盖。由于代码的更新最有可能引起程序的缺陷甚至系统崩溃，所以需要添加新的测试用例以保证对更新的覆盖，以降低程序运行的风险。
对于软件的节点覆盖率，我们细化到函数粒度。我们是通过软件部署的 Binary 代码分析得知的函数情况。不需要借助源代码，因此对于软件进行测试覆盖率分析来说要求低，用较小的成本完成此次的测试用例覆盖反馈与分析。既省时省力又保证较高的测试质量。
图片2
图片1
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
