不知身为软件工程师的你，在写代码时是不是有过这样的经历：一方面对自己写的代码信心满满，一方面又非常希望知道自己开发的代码的质量到底多高。如果代码真的没被测出bug来或者测出的bug较少时，反而有点担心??会不会还有隐藏的更深的bug没被发现？或者身为测试工程师的你，可能比开发人员担心的会更多：这些代码该不该再继续测试了？怎么能断定当前的版本算是通过验收标准了，继而可以被客户和用户认可？是不是可以把这个版本交付使用了呢？

　　--------------------------------------------------------------------------------

　　相信这是很多开发和测试人员都曾经经历过的。无论是开发人员、测试人员，还是项目经理、高层管理人员，都已经为版本的交付日以继夜的加班工作，可不能在交付的时刻功亏一篑。打击心情不说，加班加点不说，而且，谁该来为可能的返工和无休无止的变更买单呢。

　　所以，软件版本在发布时需要有一个判定的标准??没有预先定义的判定标准，无法去判断版本是否已经达到了客户的要求。不进行判断，或者是错误的判断，都很有可能会造成该项目资源安排的不合理，甚至造成资源的浪费，那么不管是精神上还是体力上，甚至进度上、成本上，都会给项目团队带来不小的打击。

　　CMMI四级的一个要求是量化的管理项目（详见量化项目管理QPM中文版）。映射到缺陷预测活动中，也是量化的管理缺陷。量化的退出标准是将类似“这个版本是否能够通过”这样的问题，形象地转变为“已经测出的bug数是否已经足够多，遗留的bug是否已经少到不会影响软件的交付”等等这样的表述。这样，无论是理解上还是判断上都更加容易，版本发布标准也变得不难理解了。

　　在决定发布版本之前，需要去统计这样几件事：我们已经发现了多少个bug；用量化的方法进行管理时，我们还有多少个bug没有发现；我们统计到的未发现的bug数是否能达到客户的要求；如果无法满足客户的要求，那我们至少还需要发现多少个bug。当这一系列问题都解决了以后，开发、测试人员是终于可以“收”工拿项目奖，还是需要返工加班、继续努力，也一目了然了。

　　知道了要做什么，接下来要考虑的是“怎么做”。出于这样的原因，方正国际软件有限公司（以下简称方正国际）几年来一直都在内部实施着利用统计学的原理对软件缺陷进行管理和监控。用统计学的方法监控和预测缺陷的发展情况，从而对发现的缺陷进行管理，确定还未发现的缺陷情况、为了按时交付每一个阶段应当发现的缺陷情况，以此相应调整测试工作的时间和进度。

　　这是方正国际近两年来一直在内部实施的基于Gompertz模型的缺陷预测与管理，以及在此基础上开发的缺陷预测与管理的工具。在已经采集到的多个项目数据的基础上，现在该工具已经在公司内部使用。应用这个工具，让测试人员在测试初期对自己大致的工作量有了比较准确的估计，并对测试的每个阶段发现的bug实施分析和监控；根据预实对照的目标达成情况来调整开发、测试的进度；而且在终交付时，给客户一个高质量的、可靠的工作产品。简单用个例子来说明吧。在项目A还未进入但即将进入测试阶段时，测试经理会根据历史的情况、经验等方法，估计出进入测试阶段后的第一周，大概可以发现多少件缺陷；同样，再估计出版本交付时可能出现的缺陷数目，以及版本交付后会出现的缺陷的数目。利用这三个数据的信息，大致可以得到：要达到预定的目标，在进入测试阶段后，每周、甚至每天大概需要发现多少缺陷。以此为依据，测试经理可以对团队中的测试人员的任务进行分配、对工作进行评价。当然，这仅仅是Gompertz模型使用的场景之一。

　　统计学是很强大的，统计学知识的应用也是很广泛的。那么，在缺陷预测中的统计学原理，或者说是理论依据是什么呢？基于Gompertz模型的缺陷预测工具到底是怎样对测试活动和质量进行监控的呢？接下来，我们会逐步与大家分享。