从Neilsen提出简单的可用性测试只需要5名用户后，这个原则就一直在流传，同时伴随这个结论流传的有一张图（图1）：

图1. 测试用户数目与发现可用性问题的概率（Nielson）

虽然没有进行过实际的可用性测试，但是我很好奇这个结论是怎么来的，尤其是当它还有个这么定量的图存在时。在我的观念里，产品测试中发现问题的概率跟产品有关，怎么就能够有这么确定的关系呢。

结论的前提

Google到Neilsen的原文后才发现，果然这个图做出来是有前提的

前提1：每次测试发现问题的概率独立于之前的测试结果

前提2：测试一个用户时发现问题的概率设定为0.31

有了这个假设，问题就容易多了。因为这让我想到中学就开始接触到的独立事件的概率问题。

情境迁移-射击问题

当时的经典例子：假设一个枪手打中目标的概率为p，那至少要打几次才能保证95%的可能能够打到目标。这个问题很简单，但是这里还是要一步步来记录思维过程：

假设打了n次还打不中目标的概率为小于5%，n的最小值就是问题要求的值。从反面思考问题更简单了：

一次打中目标的概率为p，则一次打不中目标的概率为1-p

因此n次都打不中目标的概率为(1-p)^n<5%

现在把情境迁移过来，假设一次可用性测试能够发现问题的概率为0.31，则需要测试多少个用户才能保证发现85%的问题？

很显然只要保证(1-0.31)^ n<15%

结论的抽象化

把这个问题及解决方案抽象化：对于一次测试能够发现问题的概率为p的测试，需要多少个用户才能保证发现x的问题？

（1-p)^n<1-x;或者如果希望作类似于图1的图，则可以得到x=1-（1-p)^ n

好了，推导结束后我们就可以回头思考是否真的像很多人传播的那样我们只要测试5个用户就够了。

很显然这个问题跟之前提到的基本前提假设有关。因此这里想说明两点：

1.对于迭代性的测试，在做第二轮测试的时候第一轮测试中已经发现的问题很可能已经修正了，因此二者是不独立的

2.虽然平均问题发现率是0.31，每一次的实际测试并不一定是这个值（随着p的变化，需要测试的人数也在变化，见图2）。

图2.三种不同独立问题发现率下测试人数和总问题发现率关系

实际问题中问题发现率p跟以下因素有关：

• 产品本身的问题量。早期的测试可能问题非常多，因此或许只测试一个用户就能发现50%的问题，而到产品开发的后期，这个概率会非常低。

• 测试者的发现力N，即射击案例中击中目标的能力

• 另外，可用性测试针对特定的任务集合进行测试，因此发现问题的概率还和任务的设定有关

Nielsen关于测试人数和发现问题概率的讨论当然比这个走得更远，他还衡量了测试不同人数的成本和收益，并与启发式评估做了对比，详情见他的paper。本文只是试图追根溯源，力求不仅知道what，还要知道why~