5.缺陷检查表
在进行人工代码检查时,代码缺陷检查表是我们用到的测试用例。
代码缺陷检查表中一般包括容易出错的地方和在以往的工作中遇到的典型错误,如下所示。
l
①嵌套的IF正确地缩进了吗?
②注释准确并有意义吗?
③使用有意义的标号了吗?
④代码基本上与开始时的模块模式一致吗?
⑤遵循全套的编程标准吗?
l
①初始入口和最终出口正确吗?
②当对另一个模块的每一次调用时,全部所需的参数传送给每一个被调用的模块吗?
③被传送的参数值正确地设置了吗?
④对关键的被调用模块的意外情况(如丢失、混乱)有处理吗?
l
①使用一个或一组晟佳的动词了吗?
②模块中使用完整定义的语言的有限子集了吗?
③使用了适当的跳转语句吗?
l
①每一个域在第一次使用前正确地初始化了吗?
②规定的域正确吗?
③每个域有正确的变量类型声明吗?
l
①判断正确的条件了吗?
②用于判断的是正确的变量吗?
③每个转移目标正确并至少执行一次了吗?
l
①逻辑被最佳地编码了吗?
②提供正式的错误,例外子程序了吗?
l
①清单格式适于提高可读性吗?
②标号和子程序符合代码的逻辑意义吗?
l
①全部设计已实现了吗?
②代码做的是设计规定的内容吗?
③每一个循环执行正确的次数了吗?
l
①对从外部接口采集的数据有确认吗?
②遵循可靠性编程要求了吗?
对应于不同的编程语言,代码缺陷检查表的具体内容将会不同。例如,针对广泛使用的C/C++语言,可以参照表2-3所示的代码缺陷检查表。
|
重要性 |
审查项 |
结论 |
文 件 结 构 |
|
头文件和定义文件的名称是否合理 |
|
|
头文件和定义文件的目录结构是否合理 |
| |
|
版权和版本声明是否完整 |
| |
重要 |
头文件是否使用了ifndef/define/endif预处理块 |
| |
|
头文件中是否只存放“声明”而不存放“定义” |
| |
|
…… |
| |
程 序 的 版 式 |
|
空行是否得体 |
|
|
代码行内的空格是否得体 |
| |
|
长行拆分是否得体 |
| |
|
“{”和“}”是否各占一行并且对齐于同一列 |
| |
重要 |
一行代码是否只做一件事?如只定义一个变量,只写一条语句 |
| |
重要 |
if、for、while、do等语句自占一行,不论执行语句多少都要加“{}” |
| |
重要 |
在定义变量(或参数)时,是否将修饰符*和&紧靠变量名 |
| |
|
注释是否有错误或者可能导致误解 |
| |
重要 |
注释是否有错误或者可能导致误解 |
| |
重要 |
类结构的public,protected,private |
| |
|
…… |
| |
命 名 规 则 |
重要 |
命名规则是否与所采用的操作系统或开发工具的风格保持一致 |
|
|
标识符是否直观且可以拼读 |
| |
|
标识符的长度应当符合“min-length && max-information”原则 |
| |
重要 |
程序中是否出现相同的局部变量和全局变量 |
| |
|
类名、函数名、变量和参数、常量的书写格式是否遵照一定的规则 |
| |
|
静态变量、全局变量、类的成员变量是否加前缀 |
| |
|
…… |
| |
表达式与基本语句 |
重要 |
如果代码行中的运算符比较多,是否已经用括号清楚地确定表达式的操作顺序 |
|
|
是否编写太复杂或者多用途的复合表达式 |
| |
重要 |
是否将复合表达式与“真正的数学表达式”混淆 |
| |
重要 |
是否用隐含错误的方式写if语句?例如 (1)将布尔变量直接与TRUE、FALSE或者1、0进行比较 (2)将浮点变量用“==”或“!=”与任何数字比较 (3)将指针变量用“==”或“!=”与NULL比较 |
| |
|
如果循环体内存在逻辑判断,并且循环次数很大,是否已经将逻辑判断移到循环体的外面 |
| |
重要 |
Case语句的结尾是否忘了加break |
| |
重要 |
是否忘记写switch的default分支 |
| |
重要 |
使用goto语句时是否留下隐患?例如跳过了某些对象的构造、变量的初始化、重要的计算等 |
| |
|
…… |
| |
常 量 |
|
是否使用含义直观的常量来表示那些将在程序中多次出现的数字或字符串 |
|
|
在C++程序中,是否用const常量取代宏常量 |
| |
重要 |
如果某一常量与其他常量密切相关,是否在定义中包含了这种关系 |
| |
|
是否误解了类中的const数据成员?因为const数据成员只在某个对象生存期内是常量,而对于整个类而言却是可变的 |
| |
|
…… |
| |
函数设计 |
|
参数的书写是否完整?不要贪图省事只写参数的类型而省略参数名字 |
|
|
参数命名、顺序是否合理 |
| |
|
参数的个数是否太多 |
| |
|
是否使用类型和数目不确定的参数 |
| |
|
是否省略了函数返回值的类型 |
| |
|
函数名字与返回值类型在语义上是否冲突 |
| |
重要 |
是否将正常值和错误标志混在一起返回?正常值应当用输出参数获得,而错误标志用return语句返回 |
| |
重要 |
在函数体的“入口处”,是否用assert对参数的有效性进行检查 |
| |
重要 |
是否滥用了assert?例如混淆非法情况与错误情况,后者是必然存在的并且是一定要作出处理的 |
| |
重要 |
return语句是否返回指向“栈内存”的“指针”或者“引用” |
| |
|
是否使用const提高函数的健壮性?const可以强制保护函数的参数、返回值,甚至函数的定义体。“Use const whenever you need” |
| |
|
…… |
| |
内存管理 |
重要 |
用malloc或new申请内存之后,是否立即检查指针值是否为NULL(防止使用指针值为NULL的内存) |
|
重要 |
是否忘记了为数组和动态内存赋初值(防止将未被初始化的内存作为右值使用) |
| |
重要 |
数组或指针的下标是否越界 |
| |
重要 |
动态内存的申请与释放是否配对(防止内存泄露) |
| |
重要 |
是否有效地处理了“内存耗尽”问题 |
| |
重要 |
是否修改“指向常量的指针”的内容 |
| |
重要 |
是否出现野指针,例如
(1)
(2) |
| |
重要 |
是否将malloc/free和new/delete混淆使用 |
| |
重要 |
malloc语句是否正确无误?例如字节数是否正确?类型转换是否正确 |
| |
重要 |
在创建与释放动态对象数组时,new/delete的语句是否正确无误 |
| |
|
…… |
| |
C++函数的高级特性 |
|
重载函数是否有二义性 |
|
重要 |
是否混淆了成员函数的重载、覆盖与隐藏 |
| |
|
运算符的重载是否符合制定的编程规范 |
| |
|
是否滥用了内联函数?例如函数体内的代码比较长,函数体内出现循环 |
| |
重要 |
是否用内联函数取代了宏代码 |
| |
|
…… |
| |
类的构造函数、析构函数和赋值函数 |
重要 |
是否违背编程规范而让C++编译器自动为类产生四个缺省的函数:
(1)
(2)
(3)
(4) |
|
重要 |
构造函数中是否遗漏了某些初始化工作 |
| |
重要 |
是否正确地使用了构造函数的初始化表 |
| |
重要 |
析构函数中是否遗漏了某些清除工作 |
| |
重要 |
是否错写、错用了拷贝构造函数和赋值函数 |
| |
重要 |
赋值函数一般分为四个步骤:
(1)
(2)
(3)
(4) |
| |
重要 |
是否正确地编写了派生类的构造函数、析构函数、赋值函数?注意事项:
(1)
(2)
(3)
(4) |
| |
|
…… |
| |
类的高级特性 |
重要 |
是否违背了继承和组合的规则
(1)
(2) |
|
|
…… |
| |
其他常见问题 |
重要 |
数据类型问题:
(1)
(2)
(3) |
|
重要 |
变量值问题:
(1)
(2)
(3) |
| |
重要 |
逻辑判断问题:
(1)
(2)
(3) |
| |
重要 |
循环问题:
(1)
(2)
(3)
(4) |
| |
重要 |
错误处理问题:
(1)
(2)
(3)
(4) |
| |
重要 |
文件I/O问题:
(1)
(2)
(3)
(4) |
|