可用性测试的属性 ——
可用性测试是要发现问题
可用性测试，故名思议是评估（测试）设计方案或者产品的可用性水平。目前最常用的评估可用性水平的指标有：用户在没有帮助的情况下完成任务的比例，完成任务所用的时间，用户寻求帮助的次数等等。这些指标对于描述可用性水平有益处，但却不是重点。可用性测试的更重要的成果是从可用性工程学的角度来支持这些数据，也就是发现并指出产品或者设计方案中存在的可用性问题――当然也包含优点。可以说在大多的项目中，特别是在迭代反复的产品开发流程中，可用性测试的根本目的是发现问题并解决它，从而提高产品的可用性水平。从Nielson的这张“经典”的用户与发现可用性问题数量关系的图表中，你可以得到这样的体会：“5名用户的测试可以发现85%的可用性问题”――请暂时忽略这里的具体数据，而关注并且记住这句话的主干：“测试发现问题”。
可用性测试是定性研究
绝大多数的可用性测试都是定性研究而不是定量研究。熟悉统计学的人都清楚，定量研究需要相当大的样本量才能达到一定的信度和效度。根据Nielson最近的一篇文章，要做定量的可用性测试研究，每个用户类型至少需要有20名用户 。这对于一般的测试项目来说成本太大以致无法承受。虽然有部分定量的可用性研究，但就我们目前所从事的大多可用性测试来说都是定性研究。也就是说绝大多数情况下，我们得到的只是描述性的结论，而那些尝试将测试结果推论到整个用户群体的想法都是不切实际的，徒劳的， 错误的。
可用性测试不是万能的
可用性测试是找可用性问题的方法，所以可用性测试非常适合于发现设计方案、产品中存在哪些可用性问题，并帮助解决它。这个优点，特别对于迭代式的产品开发流程来说，非常有效，经过测试－改进－再测试的几个周期，可以显著地提高产品的可用性水平。
但是，如果你的项目经理希望通过这个测试来了解这个产品有多好，上市后有多少人会喜欢或者喜欢那个特殊设计点，或者有将来有多少比例的用户能顺利完成某个操作？不，请明确告诉他，这不是可用性测试能做的。记住，可用性测试是定性研究，定性研究的样本量得出来的结论不具备推论的效度。可用性测试中确实会有一些比例数据，但这个比例只能作为参考。
究竟几个人合适？ ——
我的时间少，资源有限，三个人可以吗？
面临时间短，资源有限，用户难找等问题，是可用性从业者普遍面临的问题。手头的资源仅够测试三个人，还值得去做吗？遇到这样问题的时候，我们往往会迟疑。回想前面提到的，可用性测试是要发现问题，解决问题。测试三个人能实现这个目的吗？当然可以！问题已经有答案了。是的，由于可用性测试是定性研究，而且就发现问题这个角度来说，三个人的测试和六个、八个的测试仅仅是发现问题数量上的差异。我们不仅赞成，而且非常鼓励这样规模小，周期短的测试。
客户要求做十五个测试，有必要吗？
国内外诸多经验，包括笔者两年多的工作经验中也体会到，在测试完5个用户之后，发现重要的可用性问题的几率，也就说测试的效率已经比较低。继续做更多的测试，最多情况是看更多的用户在同样的位置出现同样的错误。由于继续做测试的产出与投入的比例比较低，我们并不推荐这样做。
有的人希望多测试几个人，希望了解有多少比例的用户会遇到特定的情况。对于这种需求，我们只能不胜其烦地解释：可用性测试作为定性研究，不能得出这样的推论。另外还有个很重要的问题需要考虑：发现四个人出现同样的问题后，真的有必要知道多少比例的人会出现这个问题？问题已经在那，你需要做的是想办法解决这个问题，而不是统计有多少人犯了这个错！
另外可能有人说，我们希望找到尽可能多的，甚至所有的可用性问题。首先，从投入和产出的比例来说，这是非常昂贵而不聪明的做法；另外很遗憾的说，你不可能在一轮的测试中发现所有的问题。问题存在一定的情境当中，而不是孤立、凭空地存在，有的问题会“埋藏”在另一些问题的下面。例如说，任务3必须要在用户完成任务1之后才能做，但用户未能顺利完成任务1，此时要么在主持人指导下完成任务1而进入任务3，或者直接跳过任务3。而这两种方式都会影响任务3的真实情况，而错过它存在的问题。所以，要发现任务3存在的问题，就必须先解决任务1中存在的问题。
推荐的做法 ——
尽早开展测试，不要担心测试的人数太少而放弃宝贵的机会。记住，你要做的是发现最重要的可用性问题并且解决它，测试三个人可以发现可用性问题吗？可以，那就去做吧，你会有意想不到的收获。
客户／领导要求做大数量的测试？如果明确测试的目的是要发现产品中存在的问题，而不是要进行定量分析，那么你应该说服他们采取少人多轮的方式来进行，这样的做法最经济而且效果最好。
参考书目：
１《When to test and when to hold off》 by Ellen Tauber, Julie Stanford and Laura Klein
974
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
