【IT168 技术文章】

    许多刚刚接触软件测试的专业人员一样，对软件缺陷的分类和跟踪管理不是很感兴趣，极端的还有一种抵触的情绪，“搞那么多名堂干嘛”？这里，笔者就想说一下，在实际的工作中缺陷分类和跟踪管理的意义。

    首先应该明确的是，测试人员的职责是“软件质量”。基本的工作是，根据一定的方法和逻辑，寻找或者发现软件中的缺陷，通过这个过程来证明软件的质量是优秀的，还是低劣的。所以，往往发现缺陷，成为很多测试人员关注的焦点。但是，事实上，我们还应该对缺陷进行分类统计，从综合的角度考虑软件的质量问题。

    现在和大家分享一下如下的规则给我们测试工作带来的指导意义。

    规则 1：发现的缺陷的数量说明不了软件的质量。

    软件中不可能没有缺陷，发现很多的缺陷对于测试工作来说，是件很正常的事。缺陷的数量大，只能说明测试的方法很好，思路很全面，测试工作有成效。但是，以此来否认软件的质量，还比较的武断。

    如果，测试中发现的这些缺陷，绝大多数都是属于提示性错误、文字错误等，错误的等级很低，而且这些缺陷的修改几乎不会影响到执行指令的部分，而软件的基本功能或者是性能，发现很少的缺陷，很多时候，这样的测试证明的是“软件的质量是稳定的”，因而它属于优秀的软件的范畴。这样的软件，只要处理好发现的缺陷，进行一下返测，基本就可以发行使用了；进行完整的回归，就是增加软件的成本，浪费商机和时间。

    反过来，如果在测试中发现的缺陷比较少，但是这些缺陷都集中在功能没有实现，性能没有达标，动不动就引起死机、系统崩溃等现象，而且，在大多数的用户在使用的过程中都会发现这样的问题，这样的软件不会有人轻言“发布”的，因为他承担的风险太大了。

    虽然，这两个例子都比较的极端，在实际的测试中，几乎不会发生，但是，提出来，是希望从事测试工作的同行们，不要把自己的工作集中在发现缺陷的问题上。
 
    规则 2：缺陷要分类统计

    看一下，笔者在实际的测试过程中得到的一组缺陷的统计的柱状图：

    它说明的是，在某些模块，执行的测试用例多，但是没有成比例的发现很多缺陷，所以这些模块是比较成熟的，因为在这些模块几乎不怎么修改，再测试的话，也不会发现什么问题的；但是某些模块执行的测试少，却发现了更多的缺陷，这些模块修复的地方，或者发生功能变更的可能性大，所以将成为质量不稳定的关键点。

    如果，你是一个软件质量管理人员，你就应该明白的是，在以后的回归测试中，应该在质量不稳定的模块中投入更多的人手和时间，进行更全面的测试，其它模块就相应减少测试工作的投入。这样，测试工作的压力就不是那么大了，而且效率也相对提高了。

    规则 3：不要指望找出软件中所有的缺陷

    很多人都知道这个道理，但是却不明白这个规则给软件测试工作的意义。它其实是在指导我们，该在什么时候停止软件测试，发布软件。

    我们再来看一组数据：

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