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