首先，在上游工作产品 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 应遵循的规范、标准，在选择合适的开发团队、操作人员和其它资源后，还要进行上岗培训，它包括对上游工作产品进行 “ 变换 ” 应遵循的规范、标准及所选择的工具、构件等。随后再启动后继的变换过程及质量监测和控制点，以保证每一个变换过程都能产生更好的、完整的文档。以防止由于不清楚或不完整引入的缺陷。这些都是软件质量保证和测试策划过程必须与以关注的。

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

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

    •  何时应当停止测试 

    软件测试还有一个很重要的问题 – 何时应当停止测试？对于许多企业来说，终止测试的时间往往是随产品的预定发布时间或交付时间来定的。甚至有的地方产品发布或交付前一周还在写新功能。每一个测试人员都在叫测试时间不够，但又没有谁能说出到底多少时间才算够。

    其实问题也很简单，一个合理的测试终止条件只能来源于一个清晰的测试目标。如果测试的目标是找到所有的缺陷，那么无论多少时间都是不够的。而要从测试的两个经济目标来看，合理的终止条件应当是由以下两点组成：

    测试是为了保证软件的质量，而软件的质量标准是由用户来决定的。这个标准应当在软件开发初期由用户需求调查所得，如果每一需求项都列出了可测试的、被共同利益者认可的标准和写入测试计划之中的测试用例，这样软件测试结束的第一个必要条件就是所有在测试计划中所列出的测试项和标准（常见的有：必要及重要的功能通过测试，某种公认的认证测试用例包测试通过，连续无故障运行超过一定时间等）都被通过。

    通常来说，早期找到并排除的缺陷越多，总的售后服务的成本就越少，但密集的测试就会导致测试成本的增高。而对测试来说，随着旧的缺陷不断地被找到并修复，软件的质量也就越来越好，后继的服务成本就越来越低，相应地，新缺陷也就越来越难找，即测试成本越来越难高。所以售后服务的成本和测试的成本大致可以用下图来表示：

    由图－ 4 可知，当找到并解决的缺陷占总缺陷的比例达到 T E 时，可终止测试。因为再要通过测试去发现一个缺陷成本比发布后再去维护的成本要高了。其实从企业利润的角度来看，就要使这两部分的成本之和最小。当然在实际情况下，这两条曲线是无法准确估计的。人们往往按拇指规则，即假设残留的缺陷数与最后一阶段排除的缺陷数相等，启用这样一个较为合理的中止条件 ： 当一段时间内（通常是一个星期）测试不出的新缺陷时，就可中止寻找缺陷了；或按本文提出的测试效益规则，即当找到的新缺陷的实际价值低于相同时间的测试运行费用、或测试成本与维护成本之和达最小值时、或经 3 至 5 倍企业同类软件开发项目的平均单位缺陷测试时间内测试不出的新缺陷时就可中止找缺陷了。

    结尾

    随着软件行业的进一步发展，对软件测试及软件测试管理的要求也越来越高，尤其是在当前发达国家渐渐兴起软件外包浪潮的关键时刻，谁能提供低价可靠的软件开发服务，谁就能抢先占领市场，而高效经济的软件测试则必然会成为软件企业竞争力的最大助益。