界面：
　　当前界面有什么？
　　每个东西用户觉得是什么？
　　可以操作吗？
　　用什么手势操作方式？
　　操作之后会怎么样？
　　界面显示的内容足够吗，有没有缺少什么东西？
　　流程：流程的测试是根据任务来进行的。把产品的需求文档罗列出来，然后给每个需求配上一个合适的场景，当然也会出现一个场景覆盖多个需求的情况，这也是允许的。然后让用户在场景下去进行任务，观察用户，然后随时提问用户，随时准备回答用户的问题。
　　以上两点适合所有的可用性测试，但是对于版本更新类的可用性测试，我们还需要了解这个更新对于用户来说的接受度如何，所以需要增加一些对比性的问题：比如说：新旧版的操作流畅度、界面表达对比感受。
　　后需要注意的是，一次可用性测试能涵盖的范围有限，所以要限制脚本问题的数量，以及对脚本的问题进行优先级的排序。
　　举个例子：之前做过一个微信端的众筹平台。我可以设定以下任务：



测试脚本样例

　　3.3制作测试原型
　　可用性测试的原型一般是高保真的Demo，可以用Prott、Flinto、proto、墨刀等来制作，制作力求真实还原应用的终实现效果。制作高保真Demo是一件耗时耗力的工作，所以在制作的时候可以适当忽略一些动效、界面等。不过做出来的Demo终也可以给开发参考，所以辛苦也是值得的。甚至于，可以请求开发人员制作原生的程序Demo（针对安卓平台），程序Demo体验会更加好。
　　当然，纸面模型也是另外一种非常好的工具。纸面模型需要把纸面模型都只做出来，然后把所有的弹出窗口、下拉菜单等控件也制作出来。然后设计师充当wizard of oz来辅助用户完成任务。即用户对着纸面模型来操作，然后设计师实时反馈用户的操作。这样子要求设计师非常熟悉测试的应用，同时，测试的时间也会大大增长。同时，动效作为设计的一环在这里无法表现出来，所以结果可能会不如高保真Demo来的好。总之各有利弊，根据实际情况来考虑。
　　4.设置测试环境
　　测试环境是指测试的时候需要使用的记录设备，通过把测试过程记录下来可以更好地分析用户的行为，特别是用户自己都没有觉察出来的一些东西。
　　首先，重要的一点是录音、录音一方面是在整理访谈记录的时候可以帮助设计师回忆访问的场景，然后填补一些缺失的笔记。另一方面，录音也可以作为一种存档的材料。同时，录音也存在简单、易操作、隐蔽等特点，使用录音笔或者现在随处可见的智能机即可完成录音。所以强烈推荐进行可用性测试的时候一定至少要录音。
　　录音之外是录像、如果有录像的话，录音的步骤可以省略。录像主要是记录用户的表情和动作。有时候，用户的表情和动作可以传达很多东西，通过把这些信息记录下来可以，设计师偶尔可以挖掘到一些闪光的设计点。
　　除此之外，用户的屏幕记录也是一种方式，通过用户的屏幕、加上用户操作的动作，表情，可以真实还原用户的使用场景，方便后期的分析。
　　录像和录屏的操作比较难进行，主要的设备可以参考如下【5】，具体可以查看相关的链接：
　　摄像机：记录动作和部分表情
　　眼动仪：可以追踪眼球的焦点轨迹，不适合移动端
　　鼠标轨迹记录：记录鼠标轨迹，只适用于PC端
　　QuickTime (iOS)：仅记录屏幕
　　Mobizen (Android)：记录屏幕、手势
　　Display Recorder (iOS)：手势、声音
　　SCR (Android)：记录屏幕、手势、表情、声音
　　Magitest (iOS)：记录屏幕、手势、表情、声音
　　Mobizen +AirDroid (Android)：现场观察并记录手势、表情、声音
　　5.预测试
　　预测试是正式实施可用性测试前的一次模拟， 模拟有助于发现问题，这时候邀请同事即可。把正式测试的流程走一遍，包括设配的调试、访谈切入、问题的提问、记录者的记录等，然后把记录的录音、视频等放出来看看效果如何，效果不如意的时候再进行调整。
　　总之，预测试可以帮助发现问题，包括以下几个方面的问题：
　　设备的问题。举个例子，录音设备放置的位置会影响录音的效果。
　　测试脚本的问题。测试问题是否足够清晰。
　　访谈的切入以及问题的提问。
　　记录者的记录。
　　发现问题之后去解决问题，才能使正式测试的时候达到更好的效果。
　　6.正式测试
　　6.1事前接待
　　测试前的接待工作是测试人员对公司的第一印象，给测试人员留下一个好印象、一个好心情有利于可用性测试的进行。所以在这里将一些注意点说一下。
　　首先，可以事先确认一下用户的行程。遇到刮风、下雨、下雪等恶劣天气的时候可以事先送上问候短信。
　　其次，遇上用户迟到的情况下，也要保持克制。在迟到五分钟到十分钟之后再给用户电话询问情况，如果用户因故取消测试，也要保持友好的态度。
　　在接到用户之后，送上一杯温水或者温热的饮料，然后让用户等待一下。后可以有专门的人员先和用户聊聊天，可以打听一些事情。
　　6.2暖场介绍
　　正式开始之前有个暖场介绍。首先主持人做一下自我介绍，然后介绍一下测试的目的和时间，需要向用户强调测试的对象是系统，希望用户可以畅所欲言。如果有录音或者录像，需要向用户告知会有此类行为，但是结果完全保密。后还需要签署保密协议。
　　6.3正式提问
　　正式提问分两个部分：个人信息的小问题和可用性测试任务问题。
　　小问题主要是为了让用户有个适应的过程，可以迅速进入状态。一般可以询问产品使用习惯、产品偏好、上网情况等，之后的测试问题是主要的可用性测试的问题。这里需要把问题放入到场景中，让用户在场景中去完成任务。或者可以询问用户的使用习惯，然后引导到脚本中的问题。需要注意的是，不一定要按照脚本的顺序提问，可以随机应变；所以主持人要非常熟悉脚本的内容。除了询问，聆听之外，主持人还要观察用户的神情以及动作，遇上用户有疑问的表情的时候可以适当穿插新的问题，但是尽量不要提供帮助，也不要指出用户的错误或指责动作太慢，但是可以询问用户“为什么这么操作”，必要的时候可以选择停止任务。
　　测试过程中还需要有一个记录人员，记录人员需要记录：用户做了什么动作和步骤（重点）、用户说了什么、写下自己的疑问（适当时候可以进行提问或者让主持人提问）。
　　6.4结束感谢
　　测试结束之后，主持人可以问一下用户的想法，同时让记录人员补充提问，所有问题结束之后，需要对用户表示感谢。送上礼品并接受用户的一些交通费报销票据等。后要把用户送到公司门口。
　　7.测试结果统计分析
　　测试结束之后，如果有时间可以立马进行整理，因为时间越短，整理出来的内容越丰富。必要的时候，可以用录音或者录像来辅助。在撰写测试脚本的时候还有一份总结大纲，根据大纲来整理内容。大纲要具备灵活性，可以记录一下测试现场发现的新问题。
　　记得只是整理而已，每个测试结束都会有一份整理的资料。后需要汇总多份可用性测试总结，终出具一份可用性测试结果，根据这份结果进行相应的改进工作。
　　我们可以从如下几个维度去分析我们的可用性测试【8】（维度之间可能有交叉）：
　　任务完成度。每个测试任务都对应一个目标，只有当用户达到目标之后，我们才认为他们完成了任务。对于每个任务，用户完成的情况如何？有多少用户终没能完成任务？多少用户需要在主持人提示下完成任务？多少人可以自行完成任务？这些都是很重要的指标
　　致命错误。严重错误指那些阻碍用户完成任务的错误，这些错误非常重要，每一个都要得到足够的重视。
　　非致命错误。非致命错误是指用户能完成任务，但是某些地方会有一些阻滞，会停顿或者思考的错误。这些错误相对来说没那么重要，不过如果发生的次数较多，该类错误也需要得到重视。
　　完成任务的时间。每个任务需要完成多少时间，决定了交互设计流程和界面的设计是否足够友好。
　　主观情绪。用户对于任务的主观感受，比如是否足够简单，是否容易找到信息，可以让用户衡量一下。
　　偏好和建议。可以让用户说出产品中哪些地方很喜欢？哪些地方不喜欢？或者让他们提一下建议。