一篇文章向你介绍可用性测试方法(2)

需要注意的是，可用性测试中，问只是其中的一部分，观察是另外一个重要的内容，所以测试脚本不仅仅要有问的问题，还有需要撰写工作人员观察的注意点。同时可以在撰写完测试脚本的同时，把总结大纲也写出来，方便后期总结的时候统一结果展示。

特别的，在设计的时候有疑惑的点，或者有争议的点，在可用性测试也可以得到较好的验证。

写完测试脚本之后，可以和利益相关者（项目经理、产品经理、开发等）讨论一下，请他们校验一下测试脚本。

界面：

a)当前界面有什么？

b)每个东西用户觉得是什么？

c)可以操作吗？

d)用什么手势操作方式？

e)操作之后会怎么样？

f)界面显示的内容足够吗，有没有缺少什么东西？

流程：流程的测试就是根据任务来进行的。把产品的需求文档罗列出来，然后给每个需求配上一个合适的场景，当然也会出现一个场景覆盖多个需求的情况，这也是允许的。然后让用户在场景下去进行任务，观察用户，然后随时提问用户，随时准备回答用户的问题。

以上两点适合所有的可用性测试，但是对于版本更新类的可用性测试，我们还需要了解这个更新对于用户来说的接受度如何，所以需要增加一些对比性的问题：比如说：新旧版的操作流畅度、界面表达对比感受。

最后需要注意的是，一次可用性测试能涵盖的范围有限，所以要限制脚本问题的数量，以及对脚本的问题进行优先级的排序。

举个例子，之前做过一个微信端的众筹平台。我就可以设定以下任务：

测试脚本样例

3.3制作测试原型

可用性测试的原型一般是高保真的Demo，可以用Prott，Flinto，proto，墨刀等来制作，制作力求真实还原应用的最终实现效果。制作高保真Demo是一件耗时耗力的工作，所以在制作的时候可以适当忽略一些动效、界面等。不过做出来的Demo最终也可以给开发参考，所以辛苦也是值得的。甚至于，可以请求开发人员制作原生的程序Demo（针对安卓平台），程序Demo体验会更加好。

当然，纸面模型也是另外一种非常好的工具。纸面模型需要把纸面模型都只做出来，然后把所有的弹出窗口、下拉菜单等控件也制作出来。然后设计师充当wizard of oz来辅助用户完成任务。即用户对着纸面模型来操作，然后设计师实时反馈用户的操作。这样子要求设计师非常熟悉测试的应用，同时，测试的时间也会大大增长。同时，动效作为设计的一环在这里无法表现出来，所以结果可能会不如高保真Demo来的好。总之各有利弊，根据实际情况来考虑。

4.设置测试环境

测试环境是指测试的时候需要使用的记录设备，通过把测试过程记录下来可以更好地分析用户的行为，特别是用户自己都没有觉察出来的一些东西。

首先，最最重要的一点是录音，录音一方面是在整理访谈记录的时候可以帮助设计师回忆访问的场景，然后填补一些缺失的笔记。另一方面，录音也可以作为一种存档的材料。同时，录音也存在简单、易操作、隐蔽等特点，使用录音笔或者现在随处可见的智能机即可完成录音。所以强烈推荐进行可用性测试的时候一定至少要录音。

录音之外就是录像，如果有录像的话，录音的步骤就可以省略。录像主要是记录用户的表情和动作。有时候，用户的表情和动作可以传达很多东西，通过把这些信息记录下来可以，设计师偶尔可以挖掘到一些闪光的设计点。

除此之外，用户的屏幕记录也是一种方式，通过用户的屏幕、加上用户操作的动作，表情，可以真实还原用户的使用场景，方便后期的分析。

录像和录屏的操作比较难进行，主要的设备可以参考如下【5】，具体可以查看相关的链接：

·摄像机：记录动作和部分表情

·眼动仪：可以追踪眼球的焦点轨迹，不适合移动端

·鼠标轨迹记录：记录鼠标轨迹，只适用于PC端

·QuickTime (iOS)：仅记录屏幕

·Mobizen (Android)：记录屏幕、手势

原文转自：http://www.jianshu.com/p/7dc60d80a928