规则 4：只依赖缺陷的趋势也可能有问题

    缺陷固然是在减少，但是是不是所有模块的缺陷都在减少呢？是不是所有级别的缺陷都在减少呢？而且它们也符合你的期望呢？

    同样是上面一组数据，我们换个角度统计，看看又会怎么样？

    可能眼睛看得很花，没有关系，我想你至少能够看到的是，各模块之间，不同的阶段都会发现缺陷突然变多，这就是统计各模块的时候，发现的各模块的缺陷趋势。它给我们的信息是，软件不同阶段，各模块的质量和软件整体的质量是不对称的。虽然缺陷在不断的减少，但是一些关键的模块，尤其是风险分析中风险值比较大的模块，仍然是质量不稳定的，这样的软件可能可以算优秀的软件，因为缺陷的绝对值可能真的很小了，但是，也同时是风险大的软件。

    这个缺陷趋势分析图，说明了，软件在测试版本的 Ver 1.4的时候，软件的质量已经得到了很好的控制了，在 Ver 1.8的时候，基本上就已经可以发布软件了，后面的测试几乎是没有什么意义的。原因很简单，软件中的缺陷既然是不可能全部发现的，就不要指望找出软件中全部的缺陷，当它足够少（各公司的定义是不同的）的时候，就应该停止测试了。

    诸如此类的规则，其实还有很多的，例如：修改一个缺陷，可能引入了更多更深的缺陷；软件测试中的“二八定律”等等。 

    很多公司都有严格的缺陷分类和管理制度，并在此基础上对软件产品的发布标准，都有具体的要求。例如：产品在发布的时候，一般都会要求，各模块致命的缺陷不得有 2个，严重的缺陷不得超过 5个，轻微的缺陷不能多于 5个，残留的缺陷总数不得多于 10个等。

    这些看似简单的规定，其实是经历了很多人长期的努力才总结出来的经验，他们大多来源于一些事故，但是现在，却直接指导着我们的测试工作，无疑对减少软件测试工作的压力和工作量都提供了足够充分的理论依据。 

    综合的讲，笔者在这里的建议仅仅只是希望，即将进入或者已经进入软件测试行业的兄弟姐妹们，不要只关心如何发现软件中的缺陷，还应当对这些缺陷进行分类的跟踪、管理和分析，并从这些已经存在的数据中，找到一些对我们的软件测试工作有意义的指导，这才是缺陷跟踪分类、统计、跟踪管理的意义。