也说软件测试中的80-20定律

   写这篇文章的想法来源于John Lee写的一篇“Tricks of Software testing”中提到的：

   (1)群集现象：发现问题越多的地方，隐含的缺陷也越多，需要重点处理。 
    佩瑞多定理：（80-20定律）许多软件现象都遵循佩瑞多分布规律：80%的贡献来自于20%的贡献者。例如20%的模块含有80%的错误。

   这里提到集群现象也就是我们一般所说的bug的群居现象（我们为什么把在软件中发现的问题叫bug呢？除了众所周知的美国海军计算机继电器的故事，再就是软件中的问题也像bug一样具有群居性和抗药性）。

    如果简单归纳一下软件测试中的80-20定律，大致有这些：
    1、80%的bug隐藏在20%的代码中；
    2、80%的bug是由20%的测试人员发现的；
    3、80%的bug属于20%的错误类型；
    4、80%的时间用在测试计划、测试设计、测试实现上，20%的时间用于测试执行上；
    5、80%的bug通过静态测试发现，20%的bug通过动态测试发现；
    6、80%的bug通过人工测试发现，20%的bug通过自动化测试发现；
    7、对于一个测试人员而言，20%的时间发现80%的bug，而剩余的80%的时间只能发现20%的bug。
    。。。。。。
    （一下子也想不到太多了，想到了再更新，也欢迎大家补充）

    这里不想对这些所谓的定律做更多的说明，主要是想关注一下80-20中的20这个小部分（比如80%的代码中包含的20%的错误），80这个大的部分大家已经重视的很多了（比如进行缺陷分析时针对的是属于20%错误类型的80%的bug）。

    提到80-20定律，就不得不提下长尾定律（没见过的去google一下：））：简单一点说就是看似不起眼的20%的部分，有可能产生的影响要等于甚至大于80%的部分。这个听起来比较绕口，还是针对上面提到的80-20定律好了：
    1、20%的bug隐藏在80%的代码中。那说明这些bug其实是很难去查找的，也就是说我们前面发现的80%的错误更多的是比较明显的错误，那下面就有这样一个问题了，怎样去尽量快的把这20%的bug找出来呢？
    2、80%的测试人员只发现了20%的bug。这说明从整个团队而言，能力上存在比较明显的等级分化，真正的高级测试工程师很少，更多的是茫然的、无助的、民工似的普通测试工程师，而这些普通测试工程师又是公司测试的主力军，怎样去提高这80%的测试人员的水平呢？
    3、一个测试人员80%的时间只能发现20%的bug。因此不少测试人员会感觉自己很多时间都在做无用功、没有什么收获，那么应该怎样去充分利用这80%的时间呢？

    这里只是胡乱抛出了几个问题，希望能和大家交流。

PS：接下来准备针对
    (2)用例： 一般考虑3个方面的，合理的，不合理的和边界的。
    再写一篇“合理不合理还是正向逆向”。