对于可用性测试，业内人士存在一些普遍认可的原则。它们神圣地如同自然科学里的理论，似乎我们只能对其言听计从、俯首称臣才能践行出“好的可用性测试”。其实，即便是科学，它的一个特征也是“可证伪性”――理论的正确性总是存在前提条件的。真理再向前一步就成为谬误！

     可用性测试中的原则同样如此，需要根据目的、资源、环境的不同，灵活把握、权衡取舍，而非一味恪守某一个或某几个原则，也许这才是可用性从业人员经验重要性的体现。

    一．任务设置：精细 VS 宽泛

    制定的任务过于精细，一般原则上是反对的。理由很清楚，如果你的任务精细到一步一步“引导”用户进行操作，那太不符合用户现实中的使用情境，平时没有人在旁边“引导”用户的每一步操作；而且过于控制用户的操作步骤，用户缺乏真实使用时的灵活性。

    是不是我们设置的任务只能是宽泛的，不能细化呢？这就必须根据研究的目的来做抉择。如果产品处在设计的初期，我们需要关注一些宏大的问题(如：网站的整体架构、导航和分类的合理性、页面的逻辑关系)，此时就需要通过宽泛而有弹性的任务，来查找宏观层面的问题。如果产品的设计已经非常完善，开始进行细节的修改迭代，此时就需要通过设置相对具体的任务来查找特定的细节问题(如：对某个命名的理解、按钮的使用、链接的点击、表单的填写)。按照《Don’t make me think》一书的观点：一般用户使用互联网产品时满足于能用就行，不会寻求最好的使用方法；只扫描网页，不会仔细阅读。所以，如果完全宽泛有弹性地设置任务，虽然更吻合实际使用情况，但是很可能用户直接跳过你想考察的细节。

    实际工作中，由于时间和资源的限制，无法做到每个产品从设计初期到上线前后进行多次可用性测试。可能在一次的可用性测试中即需要同时关注宏观方面和细节上的问题。此时，还是需要和产品经理、交互设计师反复沟通，确认测试的主要目的，同时通过对任务设置精细程度的权衡把握，使次要目的也尽量得以满足。

    不过，即便是想考察细节的任务，也要尽量避免“直接指导操作”式的语言描述方式，这样能让任务与真实使用情境不会相距太远。例如：想考察豆瓣读书页面【想要】按钮是否能被看到、是否具备可点击感。下面列出两种表述方式，以作对比：

    A.请找到您喜欢的那本书，并在该页面点击【想要】。(×)

    B.请找到您喜欢的那本书，并在该页面对其作个标记。(√)

    二．任务数量：多VS少

    任务数量的多少与可用性测试考察范围有关，与任务的精细程度也有关。如果对网站全站进行考察和只对其中某个页面、某个操作流程进行考察，所需的任务数量自然不一样。在同样的考察范围下，如果任务设置得越精细，所需任务数量也就越多。

    Lindgaard和Chattratichart(2007)的研究发现任务数量与发现可用性问题比例存在显著的相关关系(r=0.82，p<0.01)。为了尽可能多地发现可用性问题，我们就尽量多地设置任务给用户吗？

    此时要考虑任务数量过多可能带来的弊端：学习效应和疲劳效应，尤其是靠后的任务更可能会受影响。心理学实验中处理此问题的方法是顺序平衡，抵消影响。但是可用性测试中设置的场景和任务存在特定的先后次序，不适合采用顺序平衡的方法。基于我们的经验，还是通过对测试的任务数量进行控制，确保正式测试环节最多不超过1小时，加上前后的欢迎语、访谈、问答等，整个过程不超过1.5小时。

    此外，任务数量的多少还会间接影响到测试所需参与者数量的多少。

    三．用户人数：5个足够VS 5个不够

    Nielsen的研究发现，5个用户可以发现80%以上的可用性问题。这个结论得到许多人的推崇，因此称之为“魔法数字5”。这个结论的来源依据是每个用户平均可以发现30%的可用性问题，且假设所有问题都有同等被发现的概率。不过，当设置的任务数量过多，且任务的精细程度和难度多种多样时，这个前提有可能不成立。

    Lindgaard和Chattratichart(2007)的研究发现测试用户数量与发现的可用性问题比例并不存在显著的相关关系。这个结论似乎又支持我们选择少量用户进行测试即可。

    其实，在用户招募阶段，比用户数量更需要重视是用户的代表性的问题。能否招募到有代表性的用户将直接影响可用性测试的成败。如测试一个医疗软件产品，招募到医护人员和患者作为测试用户，那5个用户可能就足够了；但如果只招募到医学实习生来测试，就必须超过5个以上的用户(即便这样，也未必能推论到整个产品的用户群)。

    由此看来，招募用户的人数和任务的数量、精细程度、用户的代表性也是息息相关的。参考Tom Tullis(2009)和本人经验：当可用性测试范围限定在一定的范围(20个任务内、或30个网页之内)，且招募到很强代表性的用户，那么5个足够了。如果存在着差别较大的亚群体，争取做到每个亚群组有5个左右的代表性的用户(当然，目标用户的特征及分类应该是在可用性测试之前的用户调研阶段就解决的问题)；一次测试最多不会超过12个用户。

    四．用户表现：行为VS言语

    在可用性测试中强调对用户操作行为的关注，是毋庸置疑的。因为：

    1.用户的行为指标更明确、具体、客观，易观察和记录。

    2.如果完全把关注点放在用户的操作行为上，那么就无需跟用户进行多余的(指导语之外的)语言交流。类似于心理学研究规范，对实验或测试中的指导语进行统一，对一切无关变量(包括主试的语言、体态表情)进行控制，以减少对研究过程的干扰。

    3.即便你直接询问用户某些问题，也极可能得到错误的答案。30年前Richard Nisbett和Timothy Wilson的实验、2年前Peter Johansson在《science》的文章，都证实了某些情况下人们无法解释清楚自己行为的真正原因。另外，用户还可能揣摩主试的喜好，回答他们认为主试期望的答案。

    因此，有必要强调在可用性测试过程中关注的重点永远应该是用户的操作行为，而且尽量减少任何无关变量的干扰。但这个原则被有些人引申到极端，认为只有观察用户的操作行为才有意义，其他信息都是无需关注的，甚至轻率地怀疑用户的话都是不可信的。

    可用性测试的主要目的虽然是发现问题，但也需要了解问题背后的原因，而仅仅依靠观察用户的操作行为是无法获悉所有问题背后的原因的，此时，我们就希望用户能采用“出声思维法”，出声思维就是集中于如何与产品进行交互的意识流。如果测试中的氛围比较平等、自然、融洽，用户又特别愿意表达，那么用户就会在进行任务操作同时，表达他们想做什么、打算如何做、背后的原因是什么。此时，不仅是操作行为、用户表达出来的想法和原因、以及语言中透露出的疑惑、失望、不满、惊讶、犹豫等情绪同样是需要我们加以关注的。但是，有些用户比较内向，不善于主动表达自己的想法，此时就需要主试跟他进行简单的交流，以引导用户说出背后的原因(注：不是引导用户说出你期望得到答案)。

    所以，在实际的可用性测试，基本应该以关注用户的行为为主，少量、适时地进行询问交流也是需要的。但这个度如何把握呢？

    1.当用户出现犹豫、惊讶、任务失败(过程节点上出现自然而然地稍微中断/暂停)的时候才进行简单的询问。

    2.询问采用一般疑问句的句式，重复用户刚才的行为表现(要具体客观)：“你刚才没有……，是吗？”――虽然没有直接问“为什么”，但暗示了希望听到他进一步的解释。

    3.如果用户没有自己主动说出原因，可以“顺便”问一下“为什么？”或通过身体前倾、目光注视等非语言方式来暗示用户你希望能听到更多内容。若用户很快、坚定地说出原因，则该理由的可信度较高；如果用户犹豫、或难以说出原因，就不要继续追问。

    除了上述的语言、情绪、行为都需要得到关注，还有一种特殊情况是需要听懂用户“没有说的”语言。例如，我们预计网站的某二级导航标签和一级导航标签存在分类逻辑上的不合理；但用户在测试中，导航相关的操作步骤进行得很流畅，用户也什么都没说。这通常表明用户认为这些是理所当然的、不影响操作的――此时你需要听懂用户“没有说的”语言。如果你简单粗暴地打断用户并询问：“你觉得这两个导航标签如何？”，则变成了一种诱导性地提问。

    总结一下关于此部分内容的实践应用：

    1.用户的操作行为永远是可用性测试的重点。

    2.鼓励用户采用“出声思维法”。

    3.适时、少量地向用户提问，禁止对同一个问题反复追问“为什么”。

    4.采用真正地“倾听”技术保持和用户的交流状态，而非通过过多的话语。

    5.开放、不预设立场地观察、倾听用户“没有说的”语言。

建议继续学习：

1. Xvfb+YSlow+ShowSlow搭建前端性能测试框架    (阅读：54214)
2. 安全测试与渗透测试区别    (阅读：23699)
3. 使用Fiddler对手机应用进行抓包测试    (阅读：6929)
4. 服务器性能测试工具推荐    (阅读：6477)
5. 给Apache做压力测试时遇到的问题    (阅读：5920)
6. WEB性能测试工具推荐    (阅读：5650)
7. 可用性测试好助手——Morae软件的应用    (阅读：5500)
8. 12款很棒的浏览器兼容性测试工具推荐    (阅读：4864)
9. 可用性测试的权衡之道（二）    (阅读：4804)
10. 在线测试不同操作系统不同浏览器网页的显示效果    (阅读：4692)