[摘要]
那么是不是说找缺陷就不重要了呢？当然不是。软件测试的另一个经济目标是尽早发现缺陷，降低修复及售后服务成本。显然，每一个已发布产品中的缺陷除了会影响产品及企业的声誉外，还会直接增加产品的售后服务成本。无论是派人到现场调试，或研发、发布补丁程序都要远比在发布前的修复成本昂贵数十倍，甚至数百倍。

　 事实上，许多统计资料表明，开发过程每前进一步，发现和修复一个缺陷的平均成本要提高 10...

那么是不是说找缺陷就不重要了呢？当然不是。软件测试的另一个经济目标是尽早发现缺陷，降低修复及售后服务成本。显然，每一个已发布产品中的缺陷除了会影响产品及企业的声誉外，还会直接增加产品的售后服务成本。无论是派人到现场调试，或研发、发布补丁程序都要远比在发布前的修复成本昂贵数十倍，甚至数百倍。

　 事实上，许多统计资料表明，开发过程每前进一步，发现和修复一个缺陷的平均成本要提高 10 倍。在代码复查阶段，平均 1-2 分种能发现和修复一个缺陷，在初始测试阶段要 10-20 分钟。在集成测试时要花费 1 个小时或更多，在系统测试时要花 10-40 个小时。所以软件测试除了可以揭示和评估软件产品的可靠性之外的首要任务，就是要在开发过程中尽可能早地找到可能存在的各种缺陷，并找出最佳的解决方案。一旦在某一 “ 变换 ” 过程的工作产品成了次品，那末后继的所有 “ 变换 ” 过程的工作产品也永远是一个次品。

　 现在再来分析上节所导出的成本公式 (3)

　 C n = (k 1 k 2 …k n N 0 +k 2 k 3 …k n NS 1 +k 2 k 3 …k n NR 1 +…+NS n +NR n )×(CT n +CR n )

　 再设定不再是把软件测试和修复都留到最后，而是前移到每个 “ 变换 ” 过程 Pi 后，且设定对每个中间工作产品的缺陷捕获率和缺陷修复率分别为 RTi 和 RRi ，那末整个软件产品的测试和缺陷修复总成本为：

　 CT = CT 1 +CT 2 +CT 3 +…+CT n

　 = N 0 ×RT 1 (CT 1 + RR 1 ×CR 1 )

　 + (N 0 (1-RT 1 ×RR 1 )+NS 1 +NR 1 ))×RT 2 (CT 2 + RR 2 ×CR 2 )

　 + (N 0 (1-RT 1 ×RR 1 )+NS 1 +NR 1 ))×((1-RT 2 ×RR 2 )+NS 3 +NR 3 ))RT 3 (CT 3 + RR 3 ×CR 3 )

　 +……

　 + (N 0 (1-RT 1 ×RR 1 )+NS 1 +NR 1 ))×((1-RT 2 RR 2 )+NS 3 +NR 3 ))×…

　 ×( (1-RT n-1 ×RR n-1 )+NS n +NR n )…))×RT n (CT n + RR n ×CR n ) …… (4)

　 由 (4) 可知，当

　 N 0 =NS 1 =NR 1 = NS 2 =NR 2 =…=NS n =NR n =0时，有

CT=0

　 显见，这就是人们期望的在每个 “ 变换 ” 过程 P i 中均实现最理想的 “ 零 ” 缺陷目标的结果。但是，这是不可能的，因为至今软件项目涉及的诸多的 “ 变换 ” 过程 P i 还是人工介入的，尤其是由多人或众多团队介入后，引入缺陷是难免的，所以，控制成本的中心任务之一就是如何预防和减少对每一 “ 变换 ” 过程 P i 所引入的缺陷数。现在再回到上节中的 “ 变换 ” 过程 P i 模型 -- 图－ 2 ，即：



　 首先，在上游工作产品 D i-1 流入 “ 变换 ” 过程 P i 前，由该过程的操作者共同参与对 D i-1 评估或测试，尽量避免或减少经输入端导入和引发的缺陷数，其中导入的缺陷数是指上游工作产品 D i-1 自身中所含的缺陷数，而引发的缺陷数是指由于上游工作产品 D i-1 中所含的缺陷或因为该过程的操作者对上游工作产品 D i-1 理解上的差异而引发的。

　 其次，由于 S ：规范、标准、 … 的缺陷，如无完整、清晰的、可操作的文档化的东西，有些团队甚至只有非文挡化的约定，以至造成该 “ 变换 ” 是一种非稳定的过程，是因人而异的，这就使这种 “ 变换 ” 过程 Pi 所流向下游的工作产品 Di 必定是极不稳定的。

　 最后，来分析 R ：资源对过程质量的影响，其中虽然涉及到该过程所用的外部构件、工具、工作平台等，但这里重点要分析的是该过程的操作者 - 人。根据 [ 美 ]Watts S.Humphrey 在他的《 Introduction to the Personal Softwere Process 》，即 PSP 一书中指出：学生和工程师一般在设计阶段每小时引入 1~3 个缺陷，在编码阶段每小时引入 5~8 个缺陷。在代码复查阶段一般每小时发现 6~12 个缺陷，在测试阶段每小时排除 2~4 个缺陷。而经过 PSP 培训后，所引入的缺陷可减少 50% ，缺陷排除效率提高近 4 倍。又指出 Motorila 的工程师在学习了 PSP 后，第一次在测试时只发现 1 个缺陷。

　 实际上，排除一个缺陷的时间要比测试一个缺陷多 5 到 6 倍。当然，系统越复杂，排除缺陷的费用越高。以 Micrisoft NT 系统为例，共修复了 30000 个缺陷，测试一共花费了 250 个人 - 年，平均 16 个小时修复 1 个缺陷。

　 显然测试和排除缺陷不仅要耗费人工、花钱，而且还要拖延时间，所以对缺陷的测试和排除要综合考虑质量（ Q ）、时间进度（ T ）与成本（ C ）。保证工作质量的原则之一是每一次要开发出合格的产品。切忌一开始就匆忙进行设计、编码，首先要有一个好的、合格的需求，然后按需求特性确定一个适用的软件需求开发过程及每个 “ 变换 ” 过程 Pi 应遵循的规范、标准，在选择合适的开发团队、操作人员和其它资源后，还要进行上岗培训，它包括对上游工作产品进行 “ 变换 ” 应遵循的规范、标准及所选择的工具、构件等。随后再启动后继的变换过程及质量监测和控制点，以保证每一个变换过程都能产生更好的、完整的文档。以防止由于不清楚或不完整引入的缺陷。这些都是软件质量保证和测试策划过程必须与以关注的。

　 例如，以设计过程为例。一个有经验的工程师在进行设计时，经常在各个设计层次之间动态地进行切换： ① 首先要理解一定抽象层次上是如何工作的，然后才能在高层设计中放心用。 ② 如一个功能过去用过就可不考虑它的细节，否则要进行详细设计，甚至做一个原型加以验证后，才可放心地回到高层设计。 ③ 由于难以把设计阶段和实现阶段严格区分开来，所以要关注的是设计活动，即过程，而且除了要按照支持该过程的规范、标准，把该过程的最终结果完整地、正确地在设计文档中给予详细地表述，即评估、测试及后继的下游过程是可视化的，还要在给出最终设计文档前的活动中适当引入同行评审来过滤掉不良设计思路或碰撞出好的思路，这也是十分有效的。

　 现在我们再来考虑评估、测试活动的实际效益问题。事实上，软件工作产品中越复杂或所含的缺陷愈少，测试发现缺陷的效率越低，因此测试、修复缺陷的花费越大。加上软件产品中确切的缺陷数是无法知道的，无休止的测试也是不可取的。这就涉及到两个方面的问题 – ：第一是这些缺陷可能带来的损失到底有多大； 第二是这种缺陷被激发的可能性有多大。如果两个问题的答案都是 “ 极小 ” ，那么就根本不应当列入考虑之中。