首先应该明确的是，测试人员的职责是“软件质量”。基本的工作是，根据一定的方法和逻辑，寻找或者发现软件中的缺陷，通过这个过程来证明软件的质量是优秀的，还是低劣的。所以，往往发现缺陷，成为很多测试人员关注的焦点。但是，事实上，我们还应该对缺陷进行分类统计，从综合的角度考虑软件的质量问题。
现在和大家分享一下如下的规则给我们测试工作带来的指导意义。
规则 1：发现的缺陷的数量说明不了软件的质量。
软件中不可能没有缺陷，发现很多的缺陷对于测试工作来说，是件很正常的事。缺陷的数量大，只能说明测试的方法很好，思路很全面，测试工作有成效。但是，以此来否认软件的质量，还比较的武断。
如果，测试中发现的这些缺陷，绝大多数都是属于提示性错误、文字错误等，错误的等级很低，而且这些缺陷的修改几乎不会影响到执行指令的部分，而软件的基本功能或者是性能，发现很少的缺陷，很多时候，这样的测试证明的是“软件的质量是稳定的”，因而它属于优秀的软件的范畴。这样的软件，只要处理好发现的缺陷，进行一下返测，基本就可以发行使用了；进行完整的回归，就是增加软件的成本，浪费商机和时间。
反过来，如果在测试中发现的缺陷比较少，但是这些缺陷都集中在功能没有实现，性能没有达标，动不动就引起死机、系统崩溃等现象，而且，在大多数的用户在使用的过程中都会发现这样的问题，这样的软件不会有人轻言“发布”的，因为他承担的风险太大了。
虽然，这两个例子都比较的极端，在实际的测试中，几乎不会发生，但是，提出来，是希望从事测试工作的同行们，不要把自己的工作集中在发现缺陷的问题上。
规则 2：缺陷要分类统计
看一下，笔者在实际的测试过程中得到的一组缺陷的统计的柱状图：（见第一幅图）
它说明的是，在某些模块，执行的测试用例多，但是没有成比例的发现很多缺陷，所以这些模块是比较成熟的，因为在这些模块几乎不怎么修改，再测试的话，也不会发现什么问题的；但是某些模块执行的测试少，却发现了更多的缺陷，这些模块修复的地方，或者发生功能变更的可能性大，所以将成为质量不稳定的关键点。
如果，你是一个软件质量管理人员，你就应该明白的是，在以后的回归测试中，应该在质量不稳定的模块中投入更多的人手和时间，进行更全面的测试，其它模块就相应减少测试工作的投入。这样，测试工作的压力就不是那么大了，而且效率也相对提高了。
规则 3：不要指望找出软件中所有的缺陷
很多人都知道这个道理，但是却不明白这个规则给软件测试工作的意义。它其实是在指导我们，该在什么时候停止软件测试，发布软件。
我们再来看一组数据：（见第二幅图）
这个缺陷趋势分析图，说明了，软件在测试版本的 Ver 1.4的时候，软件的质量已经得到了很好的控制了，在 Ver 1.8的时候，基本上就已经可以发布软件了，后面的测试几乎是没有什么意义的。原因很简单，软件中的缺陷既然是不可能全部发现的，就不要指望找出软件中全部的缺陷，当它足够少（各公司的定义是不同的）的时候，就应该停止测试了。
规则 4：只依赖缺陷的趋势也可能有问题
缺陷固然是在减少，但是是不是所有模块的缺陷都在减少呢？是不是所有级别的缺陷都在减少呢？而且它们也符合你的期望呢？
同样是上面一组数据，我们换个角度统计，看看又会怎么样？（见第三幅）
可能眼睛看得很花，没有关系，我想你至少能够看到的是，各模块之间，不同的阶段都会发现缺陷突然变多，这就是统计各模块的时候，发现的各模块的缺陷趋势。它给我们的信息是，软件不同阶段，各模块的质量和软件整体的质量是不对称的。虽然缺陷在不断的减少，但是一些关键的模块，尤其是风险分析中风险值比较大的模块，仍然是质量不稳定的，这样的软件可能可以算优秀的软件，因为缺陷的绝对值可能真的很小了，但是，也同时是风险大的软件。
这个缺陷趋势分析图，说明了，软件在测试版本的 Ver 1.4的时候，软件的质量已经得到了很好的控制了，在 Ver 1.8的时候，基本上就已经可以发布软件了，后面的测试几乎是没有什么意义的。原因很简单，软件中的缺陷既然是不可能全部发现的，就不要指望找出软件中全部的缺陷，当它足够少（各公司的定义是不同的）的时候，就应该停止测试了。
规则 4：只依赖缺陷的趋势也可能有问题
缺陷固然是在减少，但是是不是所有模块的缺陷都在减少呢？是不是所有级别的缺陷都在减少呢？而且它们也符合你的期望呢？
同样是上面一组数据，我们换个角度统计，看看又会怎么样？（见第三幅）
可能眼睛看得很花，没有关系，我想你至少能够看到的是，各模块之间，不同的阶段都会发现缺陷突然变多，这就是统计各模块的时候，发现的各模块的缺陷趋势。它给我们的信息是，软件不同阶段，各模块的质量和软件整体的质量是不对称的。虽然缺陷在不断的减少，但是一些关键的模块，尤其是风险分析中风险值比较大的模块，仍然是质量不稳定的，这样的软件可能可以算优秀的软件，因为缺陷的绝对值可能真的很小了，但是，也同时是风险大的软件。
诸如此类的规则，其实还有很多的，例如：修改一个缺陷，可能引入了更多更深的缺陷；软件测试中的“二八定律”等等。
很多公司都有严格的缺陷分类和管理制度，并在此基础上对软件产品的发布标准，都有具体的要求。例如：产品在发布的时候，一般都会要求，各模块致命的缺陷不得有 2个，严重的缺陷不得超过 5个，轻微的缺陷不能多于 5个，残留的缺陷总数不得多于 10个等。
这些看似简单的规定，其实是经历了很多人长期的努力才总结出来的经验，他们大多来源于一些事故，但是现在，却直接指导着我们的测试工作，无疑对减少软件测试工作的压力和工作量都提供了足够充分的理论依据。
综合的讲，笔者在这里的建议仅仅只是希望，即将进入或者已经进入软件测试行业的兄弟姐妹们，不要只关心如何发现软件中的缺陷，还应当对这些缺陷进行分类的跟踪、管理和分析，并从这些已经存在的数据中，找到一些对我们的软件测试工作有意义的指导，这才是缺陷跟踪分类、统计、跟踪管理的意义。
文章来源于领测软件测试网 https://www.ltesting.net/
