CN105224460A - 一种基于插装技术统计测试覆盖率的方法 - Google Patents

Abstract

本发明公开了一种基于插装技术统计测试覆盖率的方法，所述方法在保证被测程序原有逻辑完整性的基础上在程序中***一些探针，通过探针的执行并抛出程序运行的特征数据，通过对这些数据的分析，获得程序的控制流和数据流信息，进而得到动态信息测试覆盖率，从而实现测试目的；所述测试覆盖率采用层次覆盖率，按照程序粒度划分为三个层次：api覆盖率、函数覆盖率、代码条件分支覆盖率，三个层次的覆盖率由粗到细，相互关联。本发明通过计算三个层次的测试覆盖率，三种覆盖率相结合，一定程度减少过度集中调用对数据的影响；根据项目测试阶段和覆盖率数据，有理有据的、灵活的判断测试的有效性，防止互相推诿、无视事实，提高项目管理的科学性。

Description

一种基于插装技术统计测试覆盖率的方法

技术领域

本发明涉及软件测试和项目管理技术领域，具体涉及一种基于插装技术统计测试覆盖率的方法,主要针对软件开发过程中质量反复，可控性差，问责困难等问题，通过在程序代码中***测试桩，监测该代码在某次测试中是否被执行，统计测试覆盖率，减少测试的随机性、随意性，提高项目管理的科学性，从而缩短项目测试时间，降低测试成本。

背景技术

从事软件项目管理及测试管理时，我们会发现在项目面对结项时间压力，此时软件质量反复、bug收敛度不如预期等问题，往往是项目结项面临的最大问题。项目经理通常采取的做法第一是bug分类追踪问责：将本次bug分类，新发现、修改导致、未修改等，以追究测试人员及开发人员的责任，期待开发人员修改bug质量及测试人员测试全面性的提高，第二是加班赶工。测试经理为了减少新发现bug的数量，往往采用固定模块测试人员的做法。

不可否认，这些做法会取得一定的效果。但是bug分类的统计过程，缺乏科学的、***的标准，依据开发及测试对于往期的测试印象而进行分类，这往往造成开发与测试互相推诿的现象。

总结这些矛盾的根本在于测试覆盖率的问题，如何保证在测试初期就进行全面的覆盖？作为管理人员如何在测试之后统计本次测试对于程序测试的全面性？

目前在项目工期紧、软件质量反复、bug收敛度不如预期的情况下，项目经理归结原因时往往缺乏科学性和可靠性，对项目其他人员来说此结论缺乏数据依据和说服力。

发明内容

本发明要解决的技术问题是：基于上述技术，本发明提供一种基于插装技术统计测试覆盖率的方法。

本发明所采用的技术方案为：

一种基于插装技术统计测试覆盖率的方法，所述方法在保证被测程序原有逻辑完整性的基础上在程序中***一些探针（又称为“探测仪”），通过探针的执行并抛出程序运行的特征数据，通过对这些数据的分析，获得程序的控制流和数据流信息，进而得到动态信息测试覆盖率，从而实现测试目的；所述测试覆盖率采用层次覆盖率，按照程序粒度划分为三个层次：api覆盖率、函数覆盖率、代码条件分支覆盖率，三个层次的覆盖率由粗到细，相互关联。

基于插装技术的统计测试覆盖率的方法即在被测程序中***装探针，当程序被执行（被测试）时，探针执行并输入指定信息，反之，探针的指定信息未输出则证明该段程序在本轮测试中未被测试到，从而可以科学的、有说服力的计算测试的覆盖率。

所述api覆盖率，以程序接口为单位，在每一个接口执行前***探针，探针信息包括接口编号、执行次数变量X（i）（接口每被执行一次该变量加1，初始值为0），在程序详细设计时，记录编号为i的接口被调用的次数，计为总数A(i)，api（i）=X（i）/A(i),当api（i）>1时，视该接口被完全覆盖（本方法基于测试的随机性排除该接口被少数情况下集中调用的情况）剔除i接口在总api覆盖率中的计算，

总api覆盖率=[X（1）+X（2）+…+X(n-1)+X(n)]/[A(1)+A(2)+…+A(n-1)+A(n)]（其中1到n中剔除api（i）>1的i接口）。当api覆盖率偏低时，可以通过计算api（i）=X（i）/A(i)来具体到是某个具体的api。

所述函数覆盖率，以函数为单位，在每一个函数开始执行之前***探针，探针信息包含函数编号、执行次数X（i）（函数每被调用一次该变量加1，初始值为0），在程序详细设计时，记录编号为i的函数被调用的次数，计为总数A(i)，函数覆盖率=X（i）/A(i)。

所述代码条件分支覆盖率，以函数内分支为单位，在每个分支执行时***探针，探针信息包括分支编号，在编码阶段，记录分支数量，分支覆盖率=执行的编号总数/总的分支数量。

所述方法在计算程序测试覆盖率时，综合这三种层次的覆盖率，判断该轮测试是否为有效的测试，对于覆盖率与有效测试的关系，根据测试的不同阶段来具体定义，在测试后期，程序功能趋于完善时，三种覆盖率基本上要达到90%以上，测试才算有效。

所述方法操作步骤如下：

1）项目详细设计阶段，根据详细设计图，给api编号，并记录api将被调用情况的数量；给函数编号，并记录函数被调用的情况数量；

2）在编码阶段，给函数的分支编号；

3）在编码阶段，在api接口开始、函数开始及函数的分支开始，***探针：System.out.println语句，输入信息到指定的文件，包括但不限于编号及执行次数;

4）在测试结束后，分别计算api覆盖率、函数覆盖率及分支覆盖率（综合三种覆盖率的情况，可以一定程度上避免少数情况下集中调用的情况），综合考量目前项目功能的完成情况及三种覆盖率，对测试是否有效做出判断。

在测试初期，项目的功能只完成了50%，根据二八原则，三种测试覆盖率若均低于48%，则考虑测试覆盖率低的情况，再根据单个的接口覆盖率、单个的函数覆盖率及单个函数的分支覆盖率，去排查确认是哪些代码未覆盖到；到了项目后期，程序功能基本完成，则三种测试覆盖率基本上要达到80%以上甚至更高，才能判断此次测试有效。

所述***测试需要持续5轮甚至更高，比较轮次之间的测试覆盖率，当测试覆盖率逐渐升高的情况下，判断项目在朝好的方向发展；当测试覆盖率下降，在排除测试原因时，判断程序质量出现后退，需要引起项目经理的重视。

本发明的有益效果为：

本发明通过在代码中插装的技术，记录测试轨迹；通过一轮测试之后的探针输出，计算三个层次的测试覆盖率，三种覆盖率相结合，一定程度减少过度集中调用对数据的影响；根据项目测试阶段和覆盖率数据，有理有据的、灵活的判断测试的有效性，防止互相推诿、无视事实，提高项目管理的科学性。

附图说明

图1为本发明基于插装技术计算测试覆盖率方法图。

具体实施方式

下面根据说明书附图，结合具体实施方式对本发明进一步说明：

实施例1：

一种基于插装技术统计测试覆盖率的方法，所述方法在保证被测程序原有逻辑完整性的基础上在程序中***一些探针（又称为“探测仪”），通过探针的执行并抛出程序运行的特征数据，通过对这些数据的分析，获得程序的控制流和数据流信息，进而得到动态信息测试覆盖率，从而实现测试目的；所述测试覆盖率采用层次覆盖率，按照程序粒度划分为三个层次：api覆盖率、函数覆盖率、代码条件分支覆盖率，三个层次的覆盖率由粗到细，相互关联。

基于插装技术的统计测试覆盖率的方法即在被测程序中***装探针，当程序被执行（被测试）时，探针执行并输入指定信息，反之，探针的指定信息未输出则证明该段程序在本轮测试中未被测试到，从而可以科学的、有说服力的计算测试的覆盖率。

实施例2：

在实施例1的基础上，本实施例所述api覆盖率，以程序接口为单位，在每一个接口执行前***探针，探针信息包括接口编号、执行次数变量X（i）（接口每被执行一次该变量加1，初始值为0），在程序详细设计时，记录编号为i的接口被调用的次数，计为总数A(i)，api（i）=X（i）/A(i),当api（i）>1时，视该接口被完全覆盖（本方法基于测试的随机性排除该接口被少数情况下集中调用的情况）剔除i接口在总api覆盖率中的计算，

总api覆盖率=[X（1）+X（2）+…+X(n-1)+X(n)]/[A(1)+A(2)+…+A(n-1)+A(n)]（其中1到n中剔除api（i）>1的i接口）。当api覆盖率偏低时，可以通过计算api（i）=X（i）/A(i)来具体到是某个具体的api。

实施例3：

在实施例1的基础上，本实施例所述函数覆盖率，以函数为单位，在每一个函数开始执行之前***探针，探针信息包含函数编号、执行次数X（i）（函数每被调用一次该变量加1，初始值为0），在程序详细设计时，记录编号为i的函数被调用的次数，计为总数A(i)，函数覆盖率=X（i）/A(i)。

实施例4：

在实施例1的基础上，本实施例所述代码条件分支覆盖率，以函数内分支为单位，在每个分支执行时***探针，探针信息包括分支编号，在编码阶段，记录分支数量，分支覆盖率=执行的编号总数/总的分支数量。

实施例5：

在实施例1-4的基础上，本实施例所述方法在计算程序测试覆盖率时，综合这三种层次的覆盖率，判断该轮测试是否为有效的测试，对于覆盖率与有效测试的关系，根据测试的不同阶段来具体定义，在测试后期，程序功能趋于完善时，三种覆盖率基本上要达到90%以上，测试才算有效。

实施例6：

如图1所示，在实施例5的基础上，本实施例所述方法操作步骤如下：

1）项目详细设计阶段，根据详细设计图，给api编号，并记录api将被调用情况的数量；给函数编号，并记录函数被调用的情况数量；

2）在编码阶段，给函数的分支编号；

3）在编码阶段，在api接口开始、函数开始及函数的分支开始，***探针：System.out.println语句，输入信息到指定的文件，包括但不限于编号及执行次数;

4）在测试结束后，分别计算api覆盖率、函数覆盖率及分支覆盖率（综合三种覆盖率的情况，可以一定程度上避免少数情况下集中调用的情况），综合考量目前项目功能的完成情况及三种覆盖率，对测试是否有效做出判断。

在测试初期，项目的功能只完成了50%，根据二八原则，三种测试覆盖率若均低于48%，则考虑测试覆盖率低的情况，再根据单个的接口覆盖率、单个的函数覆盖率及单个函数的分支覆盖率，去排查确认是哪些代码未覆盖到；到了项目后期，程序功能基本完成，则三种测试覆盖率基本上要达到80%以上甚至更高，才能判断此次测试有效。

实施例7：

在实施例6的基础上，本实施例所述***测试需要持续5轮甚至更高，比较轮次之间的测试覆盖率，当测试覆盖率逐渐升高的情况下，判断项目在朝好的方向发展；当测试覆盖率下降，在排除测试原因时，判断程序质量出现后退，需要引起项目经理的重视。

以上实施方式仅用于说明本发明，而并非对本发明的限制，有关技术领域的普通技术人员，在不脱离本发明的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本发明的范畴，本发明的专利保护范围应由权利要求限定。

Claims (7)

1.一种基于插装技术统计测试覆盖率的方法，其特征在于：所述方法在保证被测程序原有逻辑完整性的基础上在程序中***一些探针，通过探针的执行并抛出程序运行的特征数据，通过对这些数据的分析，获得程序的控制流和数据流信息，进而得到动态信息测试覆盖率，从而实现测试目的；所述测试覆盖率采用层次覆盖率，按照程序粒度划分为三个层次：api覆盖率、函数覆盖率、代码条件分支覆盖率，三个层次的覆盖率由粗到细，相互关联。

2.根据权利要求1所述的一种基于插装技术统计测试覆盖率的方法，其特征在于：所述api覆盖率，以程序接口为单位，在每一个接口执行前***探针，探针信息包括接口编号、执行次数变量X（i），在程序详细设计时，记录编号为i的接口被调用的次数，计为总数A(i)，api（i）=X（i）/A(i),当api（i）>1时，视该接口被完全覆盖剔除i接口在总api覆盖率中的计算，

总api覆盖率=[X（1）+X（2）+…+X(n-1)+X(n)]/[A(1)+A(2)+…+A(n-1)+A(n)]。

3.根据权利要求1所述的一种基于插装技术统计测试覆盖率的方法，其特征在于：所述函数覆盖率，以函数为单位，在每一个函数开始执行之前***探针，探针信息包含函数编号、执行次数X（i）（函数每被调用一次该变量加1，初始值为0），在程序详细设计时，记录编号为i的函数被调用的次数，计为总数A(i)，函数覆盖率=X（i）/A(i)。

4.根据权利要求1所述的一种基于插装技术统计测试覆盖率的方法，其特征在于：所述代码条件分支覆盖率，以函数内分支为单位，在每个分支执行时***探针，探针信息包括分支编号，在编码阶段，记录分支数量，分支覆盖率=执行的编号总数/总的分支数量。

5.根据权利要求1-4任一所述的一种基于插装技术统计测试覆盖率的方法，其特征在于：所述方法在计算程序测试覆盖率时，综合这三种层次的覆盖率，判断该轮测试是否为有效的测试，对于覆盖率与有效测试的关系，根据测试的不同阶段来具体定义，在测试后期，程序功能趋于完善时，三种覆盖率基本上要达到90%以上，测试才算有效。

6.根据权利要求5所述的一种基于插装技术统计测试覆盖率的方法，其特征在于，所述方法操作步骤如下：

1）项目详细设计阶段，根据详细设计图，给api编号，并记录api将被调用情况的数量；给函数编号，并记录函数被调用的情况数量；

2）在编码阶段，给函数的分支编号；

3）在编码阶段，在api接口开始、函数开始及函数的分支开始，***探针：System.out.println语句，输入信息到指定的文件，包括但不限于编号及执行次数;

4）在测试结束后，分别计算api覆盖率、函数覆盖率及分支覆盖率，综合考量目前项目功能的完成情况及三种覆盖率，对测试是否有效做出判断。

7.根据权利要求6所述的一种基于插装技术统计测试覆盖率的方法，其特征在于：所述***测试持续5轮以上，比较轮次之间的测试覆盖率，当测试覆盖率逐渐升高的情况下，判断项目在朝好的方向发展；当测试覆盖率下降，在排除测试原因时，判断程序质量出现后退，需要引起项目经理的重视。