第四章 缺陷管理
u 什么是缺陷
u 缺陷查找技术
u 代码复查
u 缺陷预测
4.1什么是缺陷
缺陷是指程序中存在的错误,例如语法错误、标点符号错误或者是一个不正确的程序语句,是任何影响程序完整而有效的满足用户要求的东西,是可以表示、描述和统计的客观事物。
有人把缺陷称为Bug,这是不正确的。当成为Bug时,令人想到的是那些令人讨厌的小虫子,应该把它们拍死或者不予理睬。这会使一些重要的问题被视为琐碎小事,会养成一种错误的态度。缺陷并不像无足轻重的Bug,更像是定时炸弹。大家可能会觉得有些夸大其词,绝大部分细小的缺陷没有引起严重后果。然而不幸的是,很小一部分看起来无关紧要的缺陷却能引起严重问题。虽然现在缺陷对你来说还不是一个严重问题,但很快就会成为一个重要的问题。
设计错误的复杂性和所导致的缺陷的影响没有之间关系,一些微小的编码错误却可能引起严重的系统问题。事实上,绝大多数软件缺陷都源于程序员的疏忽大意。
为了减小缺陷,就必须进行缺陷管理,研究已经引入的缺陷,确定引起这些缺陷的原因,并学会在将来如何避免重复同样的错误。
缺陷分类。在分析缺陷时,将缺陷进行分类是有帮助的。通过缺陷分类,可以迅速找出哪一类缺陷的问题最大,然后集中精力预防和排除这一类缺陷,这就是缺陷管理的关键。把精力集中到最容易引起问题的几类缺陷上,一旦这几类缺陷得到控制,在进一步找到新的容易引起问题的几类缺陷上。表4.1是Chillarege和他的IBM研究院的工作成果。
不要急于把10种类型的每一类细分出若干子类,直到你已经搜集到大量程序的缺陷数据。那时,才能够看出哪里需要更详细以及补充什么样的信息才是最有用的。
表4.1 缺陷分类
类型编号 | 类型名称 | 描述 |
10 | 文档 | 注释,信息 |
20 | 语法 | 拼写,标点符号,打字,指令格式 |
30 | 联编打包 | 变更管理,库,版本控制 |
40 | 赋值 | 说明,重名,作用域,限制 |
50 | 接口 | 过程调用和引用,输入输出,用户格式 |
60 | 检查 | 出错信息,不合适的检查 |
70 | 数据 | 结构,内容 |
80 | 函数 | 逻辑,指针,循环,递归,计算,函数缺陷 |
90 | 系统 | 配置,记时,内存 |
100 | 环境 | 设计,编译,测试,其他支持系统问题 |
备注:
|
统计缺陷个数。采用缺陷记录日志,记录那些当你完成初始设计或编码后仍然留在产品中的缺陷。人们很容易对缺陷辩解,但是要管理好缺陷,就必须收集有关缺陷的准确数据。如果原谅缺陷,那只会自欺欺人。如果你这样做的话,就别指望有所提高。
表4.2 缺陷记录日志
日期 | 编号 | 类型 | 引入阶段 | 排除阶段 | 更改时间 | 修复缺陷 |
|
|
|
|
|
|
|
描述: | ||||||
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
| ||||||
|
|
|
|
|
|
|
|
4.2缺陷查找技术
为什么要尽早发现缺陷。不要期望一个简单拼凑出来的满是缺陷的程序,经过修改可以成为一个合格的产品。一旦生产出一个有缺陷的程序,它将永远是有缺陷的。虽然你可以修复所有已知的问题,并且让它通过所有的测试,但它还是一个有许多不定的有缺陷的程序。如果工程师能宽容有缺陷的工作,他将生产出低质量的产品。“我们忙,以后在修补吧”,这样的态度不可能出产出优质产品。
发现和修复缺陷的费用。在典型项目中,产品被分成很多小的模块,由不通的工程师负责开发。在模块设计、实现、编译后,工程师作初始的单元测试;单元测试后,多个模块组成一些大组件进行集成测试;经过各种级别的组件测试后,这些组件集成为产品进行产品设计;最后,将产品集成到系统中进行系统测试。随着系统的规模和复杂程度不同,单元测试、集成测试、组件测试、产品测试、系统测试的类型、持续时间、复杂程度有所不同,但几乎所有规模的软件产品,都需要这个过程。
研究证明,开发过程每前进一步,发现和修复缺陷的平均代价要增长10倍。尽管缺陷的修复时间变化很大,但平均时间总是遵循这样的规律,而与缺陷的类型无关。
发现和修复缺陷的方法。尽管没有办法不引入缺陷,但是在开发过程中尽早发现和修复缺陷还是可能的。有多种发现程序中的缺陷的方法,基本上都包括以下步骤:表示缺陷征兆;从征兆中推断出缺陷的位置;确定程序中的错误;决定如何修复缺陷;修复缺陷;验证这个修复是否已经解决了这个问题。
有多种工具和辅助手段来帮助完成这些步骤,工程师最常用的工具是编译器,它能够表示出大部分语法缺陷。但是编译器最基本的任务是生成目标代码,并且可能会在源程序有缺陷的情况下生成代码。因此,不能检查出所有的拼写、标点符号或其他不符合语法的缺陷。一般编译器仅提供了缺陷的征兆,你必须自己对问题定位,并确定是什么问题,通常很快能够做到这一点,但偶尔也需要较长的时间
另外一种常用方法就是上面讲述的测试。测试的质量是由测试用例覆盖所有程序功能的程度决定的。测试可以用来验证程序几乎所有的功能,但有自己的缺点:同编译器一样只能满足缺陷派出的第一个步骤,你仍必须从缺陷征兆找出问题的根源,然后才能修复;随着项目规模的扩大,全面的测试会花费大量的时间,要进行完全测试几乎不可能的。
最有效的发现和修复缺陷的方法是个人复查源程序清单。这种方法是负很难彻底清除程序中的缺陷,但事实证明,这是最快而且最有效的方法。