提升系统测试覆盖率的新方法

在去年的系统测试阶段，测试覆盖工具的试运行曾在几个项目中进行，取得了一般效果。然而，目前事业部的项目主要以维护为主，每次测试都是增量加核心业务测试（用例很少），因此经常会出现很多覆盖率为0或者很低的情况。这导致分析测试覆盖率需要耗费大量时间，而投入产出比并不合适。对于新项目来说，由于版本变更频繁，现有的覆盖率统计工具也并不适用于项目的开始阶段。为解决上述问题，我们可以通过对现有的覆盖率统计工具进行二次开发，实现生成增量代码的覆盖率信息，包括增量行覆盖率、增量分支覆盖率以及增量函数覆盖率。目前，我们已经成功实现了基于Linux C程序和gcov的增量覆盖率统计方法，该方法能够快速、准确地统计出模块的增量覆盖率信息，并将结果以报表形式展示。未来，根据实际效果，我们也将考虑是否引入JAVA基于emma的增量代码覆盖率统计工具。

适用人群和具体实现方法

本方法适用于测试设计师、测试经理、质量保证主管以及项目经理。具体实现包括以下几个方面：

函数覆盖实现

1. 增量函数列表（FN）：根据执行结果中的所有函数名和开始位置，进行增量遍历代码修改记录。若代码行数在两个函数的起始行之间，则说明该函数本次被修改。

2. 增量函数执行次数（FNDA）：根据增量函数结果，在所有函数的执行次数中进行过滤，剔除在增量函数中不存在的函数执行次数。

3. 增量函数总数（FN）：即增量函数列表（FN）的个数。

4. 增量函数执行总数（FNH）：指增量函数执行次数（FNDA）中执行次数大于0的个数。

代码行覆盖实现

1. 增量代码行（DA）：根据代码修改记录结果，在所有代码行中进行过滤，排除在代码修改记录中不存在的代码行。若某行在DA中不存在但在修改记录中存在，说明该行为无效代码，应删除。

2. 增量代码有效行总数（LF）：即上一步骤中DA的个数。

3. 被执行到的增量代码有效行总数（LH）：指在DA记录中，执行次数非0的行数。

分支覆盖实现

1. 增量分支总数（BRDA）：根据代码修改记录结果，在所有分支行中进行过滤，剔除在代码修改记录中不存在的分支行。

2. 增量分支总数（BRF）：指增量分支总数的个数。

3. 增量分支执行个数（BRH）：表示增量分支总数（BRDA）中执行次数大于0的个数。

通过以上实现方法，我们可以更全面地统计系统的覆盖率信息，从而提升测试质量和效率。

版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。