CN101286132B

CN101286132B - 一种基于软件缺陷模式的测试方法及系统

Info

Publication number: CN101286132B
Application number: CN2008101142610A
Authority: CN
Inventors: 宫云战; 陈俊亮; 杨朝红; 肖庆; 王雅文
Original assignee: Beijing University of Posts and Telecommunications
Current assignee: Beijing University of Posts and Telecommunications
Priority date: 2008-06-02
Filing date: 2008-06-02
Publication date: 2010-09-08
Anticipated expiration: 2028-06-02
Also published as: CN101286132A

Abstract

本发明公开了一种基于软件缺陷模式的测试方法，包括：读取被测程序源代码文件及缺陷状态机SDSM描述文件，对被测程序进行预处理，解析SDSM描述文件；对被测程序进行词法分析和语法分析，构造出抽象语法树；根据抽象语法树，生成控制流图和符号表，并根据控制流图和符号表，进行变量取值区间集的计算与更新；对被测程序进行函数调用关系分析，生成函数调用关系图；根据函数调用关系图以函数为单位对控制流图进行遍历，并计算控制流图上每个节点缺陷状态机的状态变迁，缺陷状态机进入缺陷状态时报告对应的检查点。本发明还公开了一种基于软件缺陷模式的测试系统，包括：输入模块，缺陷模式统一测试框架，和用户界面模块，完成对被测程序的统一测试。

Description

一种基于软件缺陷模式的测试方法及系统

技术领域

本发明涉及软件测试技术，尤其涉及一种基于软件缺陷模式的测试方法及系统。

背景技术

程序静态分析是当前软件工程的一个研究热点，该类方法的一个主要优势就是在软件测试中，可以快速对大量程序源码进行自动扫描并找到潜在的故障。静态分析方法有很多，如：符号执行、定理证明、抽象解释、类型推导、模型检查、基于程序风格和注释的检测等。但是，这些方法在实现上有的过于复杂使得难以对大型程序进行测试，有的方法虽然相对简单但会造成过多的误报，很难实用。基于模式的软件测试技术也是一种静态分析方法。与形式验证如定理证明试图证明整个软件没有故障不同，基于模式的软件测试技术首先提出软件模式，然后通过检测算法进行检测，如果检测算法是完全的，则能够从待测软件中找出该类模式对应的的程序代码进行后续处理。

近年来，基于模式的软件测试技术得到快速的发展，大量的软件测试工具被研制出来从而可以自动地检测软件中的故障，并且在对一些大型商业软件和开源软件的测试中发现了大量以前测试没有发现的软件故障和安全隐患。例如，SDV在对Windows操作系统126个使用多年的驱动程序测试中发现了多个故障；ExPLODE在一些常用的文件存储系统中发现了大量的严重故障；MC在Linux、OpenBSD和Xok exokernel软件中发现了近500个故障以及100多个安全漏洞；FindBugs在Eclipse、J2SE和JBoss等开源软件中发现上百的故障。在NASA以及神舟软件的测试中，基于模式的软件测试技术都得到较好的应用。

与其他测试技术相比，基于模式的软件测试技术具有如下特点：

(1)工具自动化程度高、测试效率高。在内存为1G、CPU主频为1.8G的PC机上，FindBugs对Eclipse、J2SE和JBoss等开源软件进行分析，所耗时间不超过65分钟。举例来说，对J2SE中的rt.jar分析，该程序包有13083个类，约40M大小，所耗时间只需45分钟。

(2)基于模式的软件测试技术往往能发现其他测试技术难以发现的故障。如上面举例说明的对经过测试且长期投入运行的程序进行检测时，仍检测到存在的大量软件故障、安全漏洞、安全隐患。

虽然基于模式的测试方法相比其他测试技术有很多优越之处，但现有一些基于模式的测试方法还是存在误报、漏报、测试精度不够高的问题。

发明内容

有鉴于此，本发明的主要目的在于提供一种基于软件缺陷模式的测试方法及系统，以提高软件测试精度。

为达到上述目的，本发明的技术方案是这样实现的：

本发明公开了一种基于软件缺陷模式的测试方法，该方法包括：

a.读取被测程序源代码文件及缺陷状态机SDSM描述文件，对被测程序进行预处理，解析缺陷状态机SDSM描述文件；所述缺陷状态机SDSM具体为对应于缺陷模式的状态机，每种缺陷模式对应一类缺陷状态机，而状态机是指一个行为，用于指定一个对象在其整个生命周期中对事件作出响应而先后经历的各种状态，同时表明响应和动作；

b.对被测程序进行词法分析和语法分析，构造出被测程序的抽象语法树；

c.根据抽象语法树，生成控制流图和符号表，并根据控制流图和符号表，进行变量取值区间集的计算与更新；

d.根据符号表，对被测程序进行函数调用关系分析，生成函数调用关系图；

e.根据函数调用关系图以函数为单位对控制流图进行遍历，并计算控制流图上每个节点缺陷状态机的状态变迁，缺陷状态机进入缺陷状态时报告对应的检查点。

该方法进一步包括：

f.对于每个检查点，确认是否为真的缺陷。

该方法还包括：设置基于软件缺陷模式测试方法的技术指标，包括：漏报率ER，准确率CR，误报率DR，缺陷检测率DDR，自动缺陷检测率ADR。

进一步的，上述方法中：

步骤b所述抽象语法树的所有节点支持访问者模式接口；

步骤c所述控制流图及符号表的生成分别通过采用访问者模式遍历抽象语法树生成；所述进行变量取值区间集的计算与更新为：沿着被测程序控制流正向遍历控制流图、采用递归调用的方法进行；

步骤e所述对控制流图进行遍历由缺陷模式分析引擎进行，缺陷模式分析引擎根据步骤c所述变量取值区间集的计算，识别不可达路径上的缺陷，且不会将其报为缺陷。

本发明还公开了一种基于软件缺陷模式的测试系统，该系统包括：包括输入模块和缺陷模式统一测试框架；其中，

输入模块，用于提供被测程序源代码文件、软件缺陷模式对应的缺陷状态机SDSM描述文件和系统配置文件；所述缺陷状态机SDSM，是指对应于缺陷模式的状态机，每种缺陷模式对应一类缺陷状态机，而状态机是指一个行为，用于指定一个对象在其整个生命周期中对事件作出响应而先后经历的各种状态，同时表明响应和动作；

缺陷模式统一测试框架，用于读入所述输入模块提供的文件，对被测程序进行基于缺陷模式的测试并生成分析缺陷分布情况的缺陷报表；所述缺陷模式统一测试框架进一步包括：

被测程序预处理模块，读入被测程序源代码文件进行预处理；

缺陷状态机SDSM解析器，读入软件缺陷模式对应的缺陷状态机SDSM描述文件，并解析缺陷状态机SDSM描述文件；

词法分析及语法分析模块，对被测程序进行词法分析、语法分析；

抽象语法树生成模块，生成被测程序的抽象语法树；

控制流图生成模块，采用访问者模式、遍历抽象语法树，生成被测程序的控制流图；

符号表生成模块，采用访问者模式、遍历抽象语法树，生成被测程序的符号表；同时对被测程序进行语义分析；

区间运算模块，通过区间运算计算变量在程序中的取值区间集；

函数调用关系图生成模块，根据所述符号表，对被测程序进行函数调用关系分析，生成函数调用关系图；

缺陷模式分析引擎，根据函数调用关系图以函数为单位对控制流图进行遍历，根据缺陷状态机的变迁，对被测程序进行测试，缺陷状态机进入缺陷状态时报告对应的检查点，并生成缺陷报表。

该系统还包括：

用户界面模块，用于提供用户使用的界面，显示缺陷报表。

进一步的，上述输入模块中，所述软件缺陷模式包括故障模式、安全漏洞模式、低性能模式、坏习惯模式、疑问代码模式、死锁模式。

本发明所提供的基于软件缺陷模式的测试方法及系统，由于采用了区间运算，用于对被测程序进行基于缺陷模式的测试和帮助识别不可达路径；采用基于缺陷模式的分析引擎，能对被测程序的控制流图进行遍历，检出缺陷代码，并且不会报告不可达路径上的缺陷，减少了误报。因此，应用本发明的方法和系统具有测试精度高、测试时间短、自动化程度高的优点。

附图说明

图1为本发明基于软件缺陷模式的测试方法的流程图；

图2为本发明基于软件缺陷模式的测试系统组成结构框图；

图3为本发明系统的DTS界面示意图；

图4为本发明方法抽象语法树的生成在DTS系统中的实现过程示意图；

图5为本发明系统对一段被测程序利用控制流图遍历时部分节点的缺陷状态机状态信息流动示意图。

具体实施方式

下面结合附图及具体实施例对本发明再作进一步详细的说明。

本发明的基本思想是：首先读取被测程序源代码文件进行预处理，解析软件缺陷模式对应的缺陷状态机(SDSM)描述文件；再对被测程序进行词法分析和语法分析，构造出被测程序的抽象语法树；根据抽象语法树，构造控制流图，生成符号表；然后进行变量取值区间集的计算与更新，并根据符号表、对被测程序进行函数调用关系分析，生成函数调用关系图；最后缺陷模式分析引擎对控制流图进行遍历，并计算控制流图上每个节点缺陷状态机的状态变迁，如果缺陷状态机进入缺陷状态，则报告对应的检查点(IP，Inspective Point)。

图1为本发明基于软件缺陷模式的测试方法的流程图，如图1所示，该方法包括以下步骤：

步骤11，读取被测程序源代码文件及软件缺陷模式对应的缺陷状态机SDSM描述文件，对被测程序进行预处理，解析SDSM描述文件。

这里，所谓状态机是指一个行为，用于指定一个对象在其整个生命周期中对事件作出响应而先后经历的各种状态，同时表明响应和动作，本发明中将对应于缺陷模式的状态机称为缺陷状态机，每种缺陷模式对应一类缺陷状态机。对被测程序进行的预处理是指对被测程序进行测试之前要进行宏替换、文件包含和条件编译。

对SDSM描述文件的解析是利用一段解析程序，将SDSM描述文件解析成后续处理中缺陷模式分析引擎能够识别的内存数据结构。

步骤12，对被测程序进行词法分析和语法分析，构造出被测程序的抽象语法树。

这里，词法分析(Lexical analysis)将被测程序转换为可以进行语法分析的记号流。

抽象语法树(Abstract Syntax Tree)是一种编译技术中的用语，指的是编译器将源程序代码解析，转换为方便计算机处理的数据结构，这种数据结构通常为树状结构，因此称为抽象语法树。本发明方法中所述的抽象语法树由不同类型的节点组成，所有的节点都支持一个统一的访问者模式接口，这样就能很方便地对抽象语法树通过访问者模式进行进一步的不同形式的加工、遍历访问和输出。

步骤13，根据所构造的抽象语法树，生成反映被测程序控制结构的控制流图。

控制流图采用访问者模式遍历抽象语法树得到，其方法是：在遍历抽象语法树的基础上，由一个控制流图生成访问者实现。所述访问者采用递归下降的办法生成控制流图，即在每个抽象语法树中代表语句节点的访问者函数中加入相应产生控制流图的代码。每一个控制语句对应抽象语法树节点的访问者函数负责生成该控制语句的部分控制流图，在遍历的过程中将这些部分控制流图一一连接组织起来就构成了被测程序的控制流图。

被测程序的控制流图与抽象语法树是相对应的，控制流图的每一个节点对应抽象语法树的语句节点，从控制流图可以访问抽象语法树，同样的，从抽象语法树的语句节点也可以很方便的访问到控制流图的相应节点。另外，控制流图的每个节点对应被测程序中的一条语句。

步骤14，根据所构造的抽象语法树，生成被测程序的符号表，用来记录被测程序标识符的类型、作用域以及绑定信息，并对被测程序进行语义分析。

符号表的生成与控制流图的生成类似，也是采用访问者模式遍历抽象语法树得到，只是在每个抽象语法树中代表语句节点的访问者函数中加入的是相应产生符号表的代码。

这里，符号表将标识符与其类型和在程序中所处的位置进行映射，在处理类型、变量和函数的声明时，这些标识符可以在符号表中得到解释。当发现有标识符被使用时，这些标识符都可以在符号表中找到。

在实际应用中，步骤13和步骤14是并列的，前后顺序不限。

步骤15，根据所生成的控制流图和符号表，沿着被测程序控制流正向遍历控制流图；采用递归调用的方法，进行变量取值区间集的计算与更新。

本发明方法所采用的区间运算对基本的区间运算进行了扩展，支持区间集运算和实数、布尔变量、句柄变量和数组变量多种数据类型的区间运算，可以对声明语句、赋值语句和条件语句进行区间计算，在对控制流图遍历时，通过区间运算可以大概计算被测程序变量的取值范围，该信息用于后续基于缺陷模式的测试和帮助识别不可达路径。

步骤16，根据生成的符号表，对被测程序进行函数调用关系分析，生成函数调用关系图。

其中，所述对被测程序进行函数调用关系分析包括：分析函数在源代码中的位置、函数之间的调用关系以及函数调用的先后顺序和次数等。

步骤17，对被测程序进行测试，以函数为单位，根据函数调用关系图对控制流图进行遍历，并根据SDSM描述文件中关于缺陷状态、状态变迁以及引起状态变迁的动作的描述，计算控制流图上每个节点缺陷状态机的状态变迁，如果缺陷状态机进入缺陷状态，则报告对应的检查点。

这里，利用预先定义的缺陷模式分析引擎对控制流图进行遍历，实现对缺陷状态机状态变迁的计算，报告检查点IP。检查点IP定义了和缺陷相关联的变量的定义代码行、缺陷的发生代码行和缺陷的类型。

对于控制流图上的每个节点，其相应动作改变缺陷状态机的状态，如果有缺陷状态机进入出错状态(Error)，则报告一个缺陷。

具体的，对控制流图的遍历以函数为单位进行，根据函数调用关系图，按照函数调用关系的拓扑逆序进行；在函数控制流入口处开始遍历，如果符合缺陷状态机创建条件，则建立相应的缺陷状态机实例，如：对函数中每个会被引用的句柄变量建立一个空指针引用缺陷状态机实例。对于控制流图的每个节点，计算每个缺陷状态机的状态变迁，缺陷状态机的状态信息流动可以用如下方程表示：

in [n] = \underset{p &Element; pred [n]}{\cup} out [p],

out[n]＝gen[n]∪(in[n]-kill[n])

其中，in[n]指到达节点n之前的所有可能状态集合；out[n]指到达节点n之后所有可能状态集合；gen[n]为节点n中新产生或改变得到的新状态集合；kill[n]为节点n中“注销”或“被改变”的状态集合；pred[n]为节点n的所有前驱节点集合。

利用步骤15的区间运算，缺陷模式分析引擎在对控制流图进行遍历的过程中，将识别出不可达路径上的缺陷，并且不会报告不可达路径上的缺陷，减少了误报。

在分析过程中，如果在节点n上的状态集合出现Error状态，则报告一个缺陷，也就是报告对应的检查点IP。

步骤18，对于每个检查点，进一步确认是否为真的缺陷。

考虑到程序的逻辑复杂性以及测试代价等因素，IP经确认后分为三种情况：确认为缺陷、确认为非缺陷、以及不能确定是否缺陷。对于基于缺陷模式的测试，根据经验估计，对IP判断其是否为真的缺陷的工作从经济上来说占测试总代价的80％以上，通常由有经验的测试小组进行确认，每个成员平均每天能确认100个IP。

进一步的，在本发明的方法中，还定义了基于软件缺陷模式测试方法的几个主要技术指标：包括漏报率(ER)、准确率(CR)、误报率(DR)、缺陷检测率(DDR)、自动缺陷检测率(ADR)。这些参数可通过以下方式具体计算得出：

假设P是被测程序，M是缺陷模式，A是算法，IP是检查点。将M分成n类：M＝{M₁，M₂，…，M_n}，每类分成种：M_i＝{M_i1，M_i2，…，M_iL}，从P中计算出与M相匹配的检查点的集合IP＝{IP₁，IP₂，…，IP_k}。IP(M，A，P)是在算法为A时IP总的数目，IP(M，P)是在M和P给定之后，IP总的数目。

理论上，在M和P给定之后，IP(M，P)是确定的，但是在实践中很难得到IP(M，P)；实际中，用

表示IP(M，P)，其中A₁，A₂，…，A_n为不同测试工具所对应的算法。

所述技术指标ER、CR、DR、DDR、ADR可分别表示为：

ER(ErrorRatio)：

ErrorRatio = \frac{| IP (M, A, P) - IP (M, P) |}{| IP (M, P) |};

CR(CorrectRatio)：

CorrectRatio = \frac{{IP}_{Y} (M, A, P) + {IP}_{U} (M, A, P)}{IP (M, A, P)};

其中，IP_Y(M，A，P)表示IP确认为缺陷的数目，IP_U(M，A，P)表示不能确定是否为缺陷的数目；

DR(DistortRatio)：

DistortRatio = \frac{{IP}_{N} (M, A, P)}{IP (M, A, P)};

其中，IP_N(M，A，P)表示确认为非缺陷的数目；

DDR(DefectDetectingRatio)：

DefectDetectingRatio = \frac{{IP}_{Y} (M, A, P)}{IP (M, A, P)};

ADR(AutoDefectRatio)：

AutoDefectRatio = \frac{{IP}_{AY} (M, A, P)}{IP (M, A, P)};

其中，IP_AY(M，A，P)表示不需人工确认，工具可以自动确认为缺陷的检查点个数。

为实现上述方法，本发明还提供了一种基于软件缺陷模式的测试系统(DTS，Defect Testing System)，该系统能够实现对C/C++/Java语言编写的源程序的缺陷测试和规则测试。

图2是本发明基于软件缺陷模式的测试系统组成结构框图，该系统由输入模块21、缺陷模式统一测试框架22、及用户界面模块23组成。

其中，输入模块21提供被测程序源代码文件、软件缺陷模式对应的缺陷状态机SDSM描述文件和系统配置文件。

缺陷模式统一测试框架22读入输入模块21提供的文件，对被测程序进行基于缺陷模式的测试，并生成分析缺陷分布情况的缺陷报表24。该缺陷模式统一测试框架22能够对多类软件缺陷模式同时测试，多类软件缺陷模式的测试能共享很多信息，如变量取值等，可以缩短测试时间。

缺陷模式统一测试框架22进一步包括：被测程序预处理模块、SDSM解析器、词法分析及语法分析模块、抽象语法树生成模块、控制流图生成模块、符号表生成模块、区间运算模块、函数调用关系图生成模块和缺陷模式分析引擎。

具体的：

被测程序预处理模块，用于读入被测程序源代码文件进行预处理；

SDSM解析器，用于读入软件缺陷模式对应的缺陷状态机SDSM描述文件，并解析SDSM描述文件，将SDSM描述文件解析成后续处理中缺陷模式分析引擎能够识别的内存数据结构；

词法分析及语法分析模块，负责对被测程序进行词法分析、语法分析；

抽象语法树生成模块，用于生成被测程序的抽象语法树；

控制流图生成模块，采用访问者模式遍历抽象语法树，生成被测程序的控制流图；

符号表生成模块，采用访问者模式遍历抽象语法树，生成被测程序的符号表；同时对被测程序进行语义分析；

函数调用关系图生成模块，根据符号表，对被测程序进行函数调用关系分析，生成函数调用关系图；

缺陷模式分析引擎，对被测程序进行测试，以函数为单位，根据函数调用关系图对控制流图进行遍历，根据缺陷状态机的变迁，对被测程序进行测试，如果缺陷状态机进入缺陷状态则报告对应的检查点，并生成缺陷报表24。

用户界面模块23包括文件视图、代码视图、描述视图以及检查点列表，用于提供用户使用的界面，显示缺陷报表24，图3是本发明系统的DTS界面示意图。

进一步的，在输入模块21中，所述软件缺陷模式对应的缺陷状态机SDSM描述文件，采用xml技术实现，描述了要检测的缺陷模式、或者系统中自定义规则的状态机。系统中自定义规则是指软件开发所要遵循的一些规则或模式，比如命名规则、代码规则等，违反这些规则也是不允许的。

本系统所述的缺陷模式包括故障模式、安全漏洞模式、低性能模式、坏习惯模式、疑问代码模式、死锁模式六个大类，30个子类，150种；所述规则的模式有200种。

进一步的，在缺陷模式统一测试框架22中，抽象语法树生成模块生成抽象语法树的实现过程如图4所示，包括以下步骤：

步骤1，编写语法规则及抽象语法树的生成动作描述文件；

本发明实施例中，可编写DTS系统中的Java.jjt文件，.jjt文件是语法规则及其抽象语法树生成动作描述文件。

步骤2，生成抽象语法树数据结构定义文件和解析器最终能识别的语法规则文件；

这里，利用JavaCC的伙伴工具JJTree来处理.jjt文件，自动生成抽象语法树数据结构定义Java文件和.jj文件，.jj文件为JavaCC最终能识别的语法规则文件。其中，所述JavaCC为现有的解析器生成器工具软件。

步骤3，构造出在内存中的抽象语法树结构；

JavaCC根据.jj文件创建抽象语法树的Java分析器，在分析被测源程序的基础上生成抽象语法树分析代码，执行该代码将在内存中生成抽象语法树结构。

控制流图的生成在遍历抽象语法树的基础上，由一个控制流图生成访问者ControlFlowVisitor实现。ControlFlowVisitor访问者采用递归下降的办法生成控制流图，即在每个抽象语法树中代表语句节点的访问者函数中加入相应产生控制流图的代码。每一个控制语句对应抽象语法树节点的访问者(visit)函数负责生成本语句的部分控制流图，在遍历的过程中将这些部分控制流图一一连接组织起来就构成了被测程序的控制流图。

符号表生成模块用来构造符号表，同样采用遍历抽象语法树的访问者模式。以一个在DTS系统中对一段被测程序的分析为例：

Java中支持向前引用，例如：

class Test{

……

TestCase a；

}

class TestCase{

……

}

在Test类中使用了TestCase类，但是TestCase类的声明此时还未出现，为了支持向前引用，需要采用两遍访问。第一遍仅仅处理所有的声明(declarations)和能产生作用域的节点，在每个声明的节点对符号表进行符号记录的添加；第二遍处理所有标记符出现的地方，对符号记录进行查询，将每一个标记符的出现和相应的正确声明进行联系，如此构造出DTS系统中被测程序的符号表的一部分或全部。

区间运算模块计算程序中每个语句中变量的当前可能取值范围。区间分析主要由四个访问者完成：

ExpressionDomainVisitor完成对抽象语法树上的各种表达式的遍历，计算表达式的取值区间，包括赋值表达式；

ConditionDomainVisitor对抽象语法树上的条件判断表达式进行处理，计算条件判断中各变量在条件判断被限定取真或假值后的取值区间；

ControlFlowDomainVisitor主要处理构造方法和普通方法语法树节点，启动控制流图遍历；

DomainVexVisitor是遍历控制流图的访问者，将区间分析应用到整个程序并处理控制流图对变量区间的影响，经过DomainVexVisitor访问者的处理后，控制流图上的每个节点都记录了当前节点的相关变量取值区间。

下面是几个比较典型的Java被测程序的例子，用来比较基于软件缺陷模式的DTS和常见静态分析工具之间的差异。

例1：在控制流图遍历过程中，对缺陷状态机实例的每一个状态都关联一个前提条件，该前提条件由一系列变量及其取值区间组成。如果某个状态的前提条件中存在一个变量的取值区间为空，则说明该状态是不可能状态，也即发现了不可达路径，以往的一些测试工具对于不可达路径上的缺陷可能会报告为故障，而利用本发明的DTS系统则能识别不可达路径上的缺陷，不会将其报为缺陷，减少了误报。如本例所示，参照图5，一段被测程序代码及相应的控制流图节点缺陷状态机的状态变化如下，其中，n1～n8为八个节点：

int logLevel；

……

PrintWriter log＝null；

if(logLevel＞0)log＝new PrintWriter(...)；

if(logLevel＞3)log.println(″Log started″)；

在n1节点：in：{Start(logLevel：[MinInt，MaxInt])}，out：{MayNull(logLevel：[MinInt，MaxInt])}；

在n2节点：in：{MayNull(logLevel：[MinInt，MaxInt])}，out：{MayNull(logLevel：[MinInt，MaxInt])}；

在n3节点：in：{MayNull(logLevel：[1，MaxInt])}，out：{NonNull(logLevel：[1，MaxInt]))；

在n4节点：in：{MayNull(logLevel：[MinInt，0])NonNull(logLevel：[1，MaxInt])}，out：{MayNull(logLevel：[MinInt，0])NonNull(logLevel：[1，MaxInt]))；

在n5节点：in：{MayNull(logLevel：[MinInt，0])NonNull(logLevel：[1，MaxInt])}，out：{MayNull(logLevel：[MinInt，0])NonNull(logLevel：[1，MaxInt])}；

在n6节点：in：{MayNull(logLevel：：

)NonNull(logLevel：[4，MaxInt])}，out：{NonNull(logLevel：[4，MaxInt])}；

在n7节点：in：{MayNull(logLevel：[MinInt，0])NonNull(logLevel：[1，MaxInt])}，out：{MayNull(logLevel：[MinInt，0])NonNull(logLevel：[1，MaxInt]))；

在n8节点：in：{MayNull(logLevel：[MinInt，0])NonNull(logLevel：[1，MaxInt])}，out：{END}；

其中，in：{Start(logLevel：[MinInt，MaxInt])}表示进入节点n1缺陷状态机的状态为Start状态，其前提条件是：整型变量logLevel的取值范围为[MinInt，MaxInt]，MinInt，MaxInt代表整型变量的默认的最小和最大取值。执行完节点n1后，该状态机的状态为MayNull。执行完节点n3后，由于对log进行了内存分配，故缺陷状态机的状态为NotNull，其前提条件是：整型变量logLevel的取值范围为[1，MaxInt]；进入节点n4的缺陷状态机有关联不同前提条件的两个状态：MayNull(logLevel：[MinInt，0])和NonNull(logLevel：[1，MaxInt])。进入节点n6的缺陷状态机有两个状态：MayNull(logLevel：：

)和NonNull(logLevel：[4，MaxInt])，由于此时和MayNull状态关联的前提条件是：logLevel取值范围为，故该状态为一个不可能状态，该不可能状态实际反映了n1-＞n2-＞n4-＞n5-＞n6为不可达路径，所以节点n6对句柄变量log的引用不会报告空指针引用故障。

例2：如本例所示，每个用例都会产生一个空指针引用故障，如果用注释代码替换源代码相应部分，则空指针故障不会产生。表项中v代表x为局部变量的情况，f代表将x改为成员变量后的情况。一个v代表正确地报告出了故障，两个v代表代码替换前后都报告故障，其中一个是误报；f情况类似，一个f代表正确地报告出了故障，两个f代表代码替换前后都报告故障，其中一个是误报；空白表示没有报告故障。用例如下：

int intra1(int level){ int intra4(boolean b){ int inter 1(boolean b){

Object x＝null； Object x＝null； Object x＝null；

if(level＞0) Object y＝null； if(b /*！b*/)

x＝new Object()； if(b) x＝new Object()；

if(level＜/*＞*/4) x＝″x″； return helper1(x，b)；

return x.hashCode()； if(x！＝null) }

return 0； y＝″y″；

} if(y！＝null) int inter2(){

return x.hashCode()+ return helper2(null)；/*0*/

int intra2(boolean b){ y.hashCode()； }

Objectx＝null； else

if(b) return x.hashCode()/*0*/； int inter3(boolean b){

x＝new Object()； } Objectx＝null；

if(！b/* b */) if(b)x＝″x″；

return x.hashCode()； int intra5(Object x){ return helper2(x)；/*0*/

return 0； if(x＝＝null){ }

} return x.hashCode()；/*0*/

} //Bug when x is null

int intra3(Object x){ return 0； //and b is false

Object y＝null； } private int helper1(

if(x！＝null) Object x，boolean b){

y＝new Object()； int intra6(Object x){ if(b)return 0；

if(y！＝null) if(x＝＝null){ return x.hashCode()；

return x.hashCode()+ Object y＝x；/*0*/ }

y.hashCode()； return y.hashCode()；

else } private int helper2(Object x){

return x.hashCode()/*0*/； return0； return x.hashCode()；

} } }

表1为空指针引用故障的测试结果：

表1

表1中，DTS对于函数内部用例中的第1和第2个测试用例只报告了x为局部变量的情况，在x为成员变量时DTS没有报告错误。这是因为对于成员变量，只选择报告那些在函数中存在类似x＝＝null或x！＝null的检查情况，以避免大量的误报。另外，在处理第1个函数间用例时测试结果是vv，也就是说产生了一个误报，这是因为DTS还只能处理比较简单的函数间情况。

由例2可以看出使用本发明DTS工具的测试误报要少很多，测试的准确率较高。

例3：本例是使用不同的测试工具对Tomcat4.1.24进行缺陷测试的结果如表2所示：

表2

从表2可以看出，很明显的，使用DTS系统测试时，相对于别的现有测试工具，使用了本发明方法的DTS系统，具有很高的准确率和缺陷检测率，较低的误报率。

使用了本发明方法的DTS系统，其优点还在于：

测试时间短。对同样的被测程序而言，由于程序静态分析的方式本身的测试速度要比程序动态分析的快，也就是测试时间相对要短，同时，本发明中采用缺陷模式统一测试框架，使得一次测试能对多类软件缺陷模式同时测试，多类软件缺陷模式的测试能共享很多信息，如变量取值等，缩短了测试时间；本发明所述的DTS系统对数十万行的程序，可以在1～2个小时内测试完毕。

自动化程度高。应用DTS，可直接对C/C++/Java的源代码进行扫描测试，并自动产生故障点IP。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims

1.一种基于软件缺陷模式的测试方法，其特征在于，该方法包括：

2.根据权利要求1所述的基于软件缺陷模式的测试方法，其特征在于，该方法进一步包括：

f.对于每个检查点，确认是否为真的缺陷。

3.根据权利要求1所述的基于软件缺陷模式的测试方法，其特征在于，该方法还包括：设置基于软件缺陷模式测试方法的技术指标，包括：漏报率ER，准确率CR，误报率DR，缺陷检测率DDR，自动缺陷检测率ADR。

4.根据权利要求1所述的基于软件缺陷模式的测试方法，其特征在于，步骤b所述抽象语法树的所有节点支持访问者模式接口。

5.根据权利要求1所述的基于软件缺陷模式的测试方法，其特征在于，步骤c所述控制流图及符号表的生成分别通过采用访问者模式遍历抽象语法树生成；所述进行变量取值区间集的计算与更新为：沿着被测程序控制流正向遍历控制流图、采用递归调用的方法进行。

6.根据权利要求1所述的基于软件缺陷模式的测试方法，其特征在于，步骤e所述对控制流图进行遍历由缺陷模式分析引擎进行，缺陷模式分析引擎根据步骤c所述变量取值区间集的计算，识别不可达路径上的缺陷，且不会将其报为缺陷。

7.一种基于软件缺陷模式的测试系统，其特征在于，该系统包括：包括输入模块和缺陷模式统一测试框架；其中，

抽象语法树生成模块，生成被测程序的抽象语法树；

8.根据权利要求7所述的基于软件缺陷模式的测试系统，其特征在于，该系统还包括：

用户界面模块，用于提供用户使用的界面，显示缺陷报表。

9.根据权利要求7所述的基于软件缺陷模式的测试系统，其特征在于，所述软件缺陷模式包括故障模式、安全漏洞模式、低性能模式、坏习惯模式、疑问代码模式、死锁模式。