昨天一个测试工程师发邮件给我，询问软件评测师考试的一个题目的答案。题目是关于估算系统中存在缺陷数量的，原题如下：
两个小组独立地测试同一个程序，第一组发现25个错误，第二组发现30个错误，在两个小组发现的错误中有15个是共同的，那么可以估计程序中的错误总数是 ___个。
A．25 B．30 C．50 D．60
当然，任何一个了解估算方法的朋友都可以根据公式计算出最终的结果是50个，这没有什么问题。——但是，我在这里引用这个题目，是希望我们可以把学习这件事情通过类比变得更加有趣一点。
其实，如何估算一个系统中存在的缺陷数，我们的老祖宗早就有现成的方法了。不信，请看我在我们老祖宗的数学专著中找到的一个实践问题：“有一口鱼塘，不知道其中有多少条鱼，如何才能估算出池塘中鱼的数量？”（当然，原文不是这样，请原谅我一下子找不到出处，只好凭记忆用我的语言描述一下了）。我们老祖宗给出的答案是这样的：
首先，从鱼塘中打捞出一些鱼（假设数量为m）；
将这些鱼做上记号，然后将其放回鱼塘；
等待一段时间，等到鱼均匀分布在鱼塘中了之后，再次打捞上来一些鱼（假设数量为n）；
统计第二次打捞上来的鱼中的带记号者（假设数量为p）；
计算得出鱼塘中鱼的数量为 S = m / (p/n)
对这个答案最简单的理解是：假设第一次做了记号的鱼在鱼塘中是均匀分布的，第二次打捞上来的n条鱼中有p条是有记号的，则说明有记号的鱼的分布密度是p/n，鱼塘中一共有m条有记号的鱼，当然总的鱼数量就是 S = m / (p/n)了。
再回到我们的原始问题，很容易做一个类比，第一个小组发现了25个缺陷（相当于第一次打捞的鱼m），第二个小组发现了30个缺陷（相当于第二次打捞上来的鱼n），两者相同的是15个（相当于是p），所以答案是 50。
所以，从现在开始，不要再认为这个方法是什么深奥的方法——看看，我们的老祖宗都能熟练运用呢
本来，到这里就可以告一段落了，可是我们能不能再深入点思考这个问题呢？
这种方法显然是可以得到一个估算结果，但这种方法在哪些情况下不合适，使用时有什么注意事项没有呢？
还是回过头看我们养鱼的例子，很显然，我们讨论的前提是“做记号的鱼在池塘中分布均匀”，如果这个条件不满足，我们的估算结果显然是有很大的偏差的。就鱼塘来说，不同类型的鱼由于喜欢的食物种类不同，喜欢分布在不同的层次，这样一来的话，在打捞的时候就要注意，如果只侧重在某一个水层，显然结果是有很大的偏差的，另外，由于鱼塘边上的温度相对较低，夏天鱼更加喜欢在鱼塘边休息……，可见，要达到“平均”这样的条件还是有难度的…… —— 等等，我们讨论了这么久的鱼，和我们的缺陷有什么关系呢？
别忘了，缺陷在系统中的分布和鱼在鱼塘中的分布可是有异曲同工之妙的哦
。缺陷有不同的类型（功能缺陷，性能缺陷，安全性缺陷……），分布在不同的模块，由于模块设计和实现人员的水平的差异，模块自身复杂度的差异等，不同模块中的缺陷分布显然是不同的，一个系统中，由于测试的测试不同，不同类型缺陷的发现效率也是不同的……——再看看，这和我们的鱼塘是不是一回事？
关于鱼塘和缺陷的故事，如果我们要深究下去，还会发现他们的很多共同点，当然，你也可以提出各种方法来修正我们这个简单的模型——但这不是我们的重点。我要说的重点是：无论如何，在这条路上的思考是不是会比简单的背公式更有趣一些呢？
经常有测试工程师问到，应该怎样才有最高的学习效率呢？
我的回答是：学习、思考是乐趣，不是负担。我们学习是为了追求它自身的乐趣——获得知识的乐趣，在自己头脑中天马行空的乐趣，发现的乐趣，以及分享的乐趣——至于“书中自有黄金屋，书中自有颜如玉”，对不起，一般来说，这样的学习者和我不是一类人。
