个体软件过程之缺陷管理

（本文基于网络资料，由“赵亮-碧海情天”重新进行组织和个别修正，使之更符合逻辑理解的顺序和更加严谨。）

缺陷的概念与影响

缺陷是指程序中存在的错误或不理想的设计。

即使有经验的程序员，一般开发10行左右源程序就会引入一个缺陷。通常在编译和测试阶段能发现和纠正大部分缺陷，但仍有许多缺陷留在最终产品中。

为防止缺陷的引入，需要精通所用的程序设计语言，深入理解开发支持环境，掌握要开发的应用系统的类型，并具有丰富的设计经验等。

一般的软件组织要用一半以上的时间和精力来查找和修复缺陷。由于测试时间难以预计，产品缺陷常常是产生超支和延期的主要原因。

当软件工程师对你说程序中仅剩几个BUG时，你可能感到一阵轻松。但若告诉你，程序经过全部测试，仅留几个定时炸弹时，你的感觉又会如何？

缺陷管理

编写程序的软件工程师本人最适合查找和修复程序中的缺陷，因此软件工程师应该承担所生产的软件的质量责任。

若你不朝着设计无缺陷程序的方向努力，你永远也不可能做到这一点。

把缺陷进行分类，把精力集中到最容易引起问题的几类缺陷上，这是缺陷管理的关键。

逃过你所有的缺陷预防和检测手段的漏网者，对于了解你自己的个体软件过程的弱点是非常重要的，对它们的了解将成为你个体过程改善的主要数据来源。

目前，我们可以把精力集中在编译或测试阶段来发现缺陷。随着收集缺陷的增多和习惯，逐渐关注和寻找在设计和编码阶段出现的错误，因为大多数的缺陷还是在设计和编码阶段引入的。

收集缺陷数据的理由

• （1）提高程序设计水平：缺陷数据可以帮助你改进编写程序的方法。不要轻易对缺陷辩解，不要轻易原谅缺陷。

• （2）减少程序中缺陷个数：通过收集缺陷数据，改进编程方法，可以减少引入的缺陷。

• （3）节省时间：错误能引起更多的错误，查找和修复缺陷应越早越好，越能节约项目时间。

• （4）节约开支：缺陷带来的费用是昂贵的——单元测试后，在以后的各个测试和维护阶段，其查找和修复的费用平均以十倍的速度增长。

• （5）负责任地完成工作：缺陷是工程师引入的，他们有责任查找和修复这些缺陷。

发现缺陷的方法

使用编译器发现缺陷

编译器是现有速度最快的缺陷检测工具，但它只能查出大约90%的语法错误和很少的逻辑错误。它并不能真正辨认你整体的意图.

编译器检查不出来的大部分是设计错误，也有一些是语法错误。C++的缺陷数据表明，大约有9.4%的语法错误会通过编译。

通过测试找出缺陷

通过用户发现和反馈找出缺陷

这是一种常见的方法，事实证明，这也是花费最大的策略，如IBM每年花费大约2.5亿美元用于修复1.3万个客户反馈的缺陷和重新安装修复后的版本，每个缺陷花费约2000美元。

单元测试是最有效的测试阶段，但它只能发现大约50%的缺陷。

系统测试一般仅能找到进入系统测试时产品中缺陷的大约30~40%

测试可以验证程序几乎所有的功能，但它只能给出缺陷的征兆，需要你去找出问题的根源，然后开始修复。

通过代码复查技术找出缺陷

代码复查就是个人复查源程序清单。这是最快和最有效的发现和修复缺陷的方法。

代码复查有效率的原因是：在代码复查时看到的是缺陷本身而不是征兆。

同行检查，或叫同行评审，是让几个工程师彼此复查程序。同行检查组织得好，一般会发现程序中50~70%的缺陷。

代码复查也有缺点：一是非常耗时，二是很难恰当地进行。

在PSP（个体软件过程）中主要的缺陷排除方法就是个人代码复查：先打印程序清单，然后逐行进行复查。

最有效的方法是找出以前的程序中，在编译和测试阶段引起最大问题的那些缺陷类型。

在第一次编译前仔细地复查代码，能减少大约10%的编译时间，并且可节省更多的测试时间。

（赵亮注：看上去这不一定合算，但不要忘了，BUG总是会有的，代码迟早要检查的，既然早晚要走这么一趟，何不先行一步呢？况且，保持在测试人员与上司心目中的光辉形象也是很重要的哦，倒不只是虚荣心，将来升职加薪也都是要参考你的工作表现的。）