2）缺陷出现的区域：分别为表达式级、语句级、声明级、模板缺陷、预处理缺陷、类级缺陷以及性能缺陷。表达式级、语句级、声明级以及预处理的缺陷，主要面向过程程序中的缺陷；模板缺陷、类级缺陷，则是针对面向对象软件的特点提出的；代码冗余等归为性能缺陷；
　　3）缺陷对代码的危害：代码中出现某种缺陷将会造成什么样的影响。
　　例如，检查表中一条缺陷的特征描述如下：
　　问题描述：指针所指内存释放后没有将指针赋为NULL。
　　举例说明：

　　正确形式：在释放内存的同时将指针置空。

　　出现区域：语句级。
　　危害：指针被free释放后其地址并不会自动发生改变（非NULL），p成为了“野”指针，这种情况下再对p进行操作，很容易造成程序崩溃，后果非常严重。
而代码检查清单正是由若干条这样的缺陷特征描述构成的。
　　3、软件问题报告（Software Problem Report）
　　在软件测试过程中，对于发现的每个软件问题（缺陷），都要进行记录该错误的特征和再现步骤等信息，以便相关人员分析和处理软件问题。为了管理测试发现的软件问题，通常要采用软件问题报告数据库，将每一个发现的软件问题输入到软件问题报告数据库中，软件问题报告数据库的每一条记录称为一个软件问题报告。
　　软件问题报告包括头信息、简述、操作步骤和注释。
　　头信息包括：被测试软件名称、版本号、缺陷或错误类型、可重复性、测试平台、平台语言、缺陷或错误范围。并要求填写完整和准确。
　　简述是对缺陷或错误特征的简单描述，可以使用短语或短句，要求简练和准确。
　　操作步骤是描述该缺陷或错误出现的操作顺序，要求完整、简洁和准确。对命令、系统变量、选项要用大写字母，对控件名称等要加双引号。
　　注释一般是对缺陷或错误的附加描述，一般包括缺陷或错误现象的图像，包括其他建议或注释文字。
　　软件问题报告是软件测试过程中最重要的文档之一。它记录了软件问题发生的环境，软件问题的再现步骤以及性质的说明，而且还可以跟踪软件问题的处理过程和状态。软件问题的处理进程从一定角度反映了测试的进程和被测软件的质量状况及改善过程。
　　五、 代码检查规则管理的研究
　　1、潜在的编码规则和缺陷代码模式
　　潜在的编码规则（Implicit Coding Rules）和缺陷代码模式（Bug Code Pattern）是Tomoko MATSUMURA在文献[3,4]中针对代码检查实践，提出的两个相关的概念。
　　潜在的编码规则
　　潜在的编码规则包含以下几个特征：
　　1）不同于在开发启动时明确决定的“编码规范”的规则，这些规则在长期的测试/维护过程中是潜伏的，对这些规则的发现是不可预见的。

　　2）这些规则很少在设计文档或者特定的文档中被清楚的描述。他们通常只存在于开发人员、测试/维护人员的记忆中。换言之，是一种尚未系统化的经验积累和总结的结果。
　　3）不同于使用规范库的公用规则。对于特定的软件有其特定的规则，这也意味着对于不同的软件有不同的潜在的编码规则。
　　4）由于违反潜在的编码规则导致的缺陷通常情况下不是那么容易发现的。其中相当多一部分只在特定的罕见的情况下发生，所以在早期要想发现这些问题是很困难的。
　　5）目前，还不存在好的工具或者检查清单来发现违反潜在的编码规则的代码片段，通常的检查工具（例如PC-Lint、Purify）和通用的检查清单只能发现常见的问题。
　　6）为了减少违反潜在的编码规则的现象的发生，而进行重构通常很困难。要重构一个软件，准确理解代码是非常必要的，然而，老的系统太复杂，并且没有精确的文档和了　　解系统的专业维护人员。总之，重构过期系统的代价很大，需要冒很大的风险。
　　缺陷代码模式：违反潜在的编码规则的编码模式。
　　缺陷代码模式不是肯定会导致缺陷的发生，一段符合缺陷代码模式的代码片段，并不意味着代码片段一定就有缺陷，缺陷代码模式只是疑似存在缺陷。另一方面，因为缺陷代码模式是静态的，没有考虑到代码片段之间的动态关联。需要代码检查人员或者维护人员把符合缺陷代码模式的代码片段提出来，并判断究竟是否存在缺陷。
　　在软件开发过程中发现和建立缺陷代码模式有三条主要途径。其一：在进行代码检查过程中，代码检查人员发现一个软件问题的同时，根据对该问题是否具备代表性和通用性等因素的考虑，确定是否建立一个缺陷代码模式；其二：当软件失效或者发生问题，检查对应的代码部分，发现并确定是否有潜在的编码规范与之相关；其三：分析现存的代码规范和积累的大量问题报告，从中提炼出潜在的编码规则。
　　在文献[3,4]中还给我们介绍了一个代码缺陷检测系统的大致工作流程，如2所示。

　　图2  缺陷检测模型系统的代码检查流程参考图