1、测试的过程

在我看来,测试主要有四个步骤 : 1.测试前思考2.从首页开始一个一个页面测试,分别从样式(样式与设计稿进行比对)、功能、效果来测试3.撰写测试文档4.测试结果统计分析,这四个步骤有些事可以并行的，有些是需要严格按照前后顺序执行的。下面我就针对这四个步骤，谈谈具体要怎么做。

2、测试前思考

不论是做哪个平台的可用性测试，比如PC端、移动端的测试，最最重要的就是要先理清楚一些基本问题。

1.为什么要进行这个测试（why）？测试可以验证一些设计中的疑惑，或者找出现有的界面、流程设计上的问题，具体问题要具体分析。

2.什么时候在哪里做测试（when？where？）时间一般是需要和测试者协调的；地点一般选择在安静的会议室即可。

3.谁要作为测试者（who）？测试者一般是跟我们的角色接近的人，或者换个说法，测试者一般是我们的目标用户。所以我们要站在目标用户的角度来进行测试。

4.我们要测试什么（what）？测试一些功能点，测试界面设计，测试流程设计，测试设计中有争议、有疑问的地方。

当然这些问题其实都不太难，但是这些都是至关重要的问题。如果没有经过这个步骤的思考，整个可用性测试做下来就会像无头苍蝇，没有一个总的指导。

3、 撰写测试文档

测试文档的好坏直接关系到结果的好坏。在撰写测试文档之前，我们需要先确定一些结果分析的维度。一般的维度有：a)任务完成度b)致命错误c)非致命错误d)完成任务的时间e)主观情绪f)偏好和建议。

由于分析的维度会关系到文档的问题，所以在确定分析维度之后，我们可以对功能点进行任务分析。把所有需要测试的功能点列出来，对每个功能点进行任务设计。对于任务而言，用户最主观的感受就是两个：界面和流程。所以测试文档又可以从这两个维度去细分。

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

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

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

界面：

a）当前界面有什么？

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

c）可以操作吗？

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

e）操作之后会怎么样？

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

流程：

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

4. 测试结果统计分析

测试结束之后，如果有时间可以立马进行整理，因为时间越短，整理出来的内容就越丰富。必要的时候，可以用录音或者录像来辅助。在撰写测试文档的时候可以一份总结大纲，根据大纲来整理内容。大纲要具备灵活性，可以记录一下测试现场发现的新问题。

记得只是整理而已，每个测试结束都会有一份整理的资料。最后需要汇总多份可用性测试总结，最终出具一份可用性测试结果，根据这份结果进行相应的改进工作。

我们可以从如下几个维度去分析我们的测试【8】（维度之间可能有交叉）：

a)任务完成度。每个测试任务都对应一个目标，只有当用户达到目标之后，我们才认为他们完成了任务。对于每个任务，用户完成的情况如何？有多少用户最终没能完成任务？

b）致命错误。严重错误指那些阻碍用户完成任务的错误，这些错误非常重要，每一个都要得到足够的重视。

c）非致命错误。非致命错误是指用户能完成任务，但是某些地方会有一些阻滞，会停顿或者思考的错误。这些错误相对来说没那么重要，不过如果发生的次数较多，该类错误也需要得到重视。

d）完成任务的时间。每个任务需要完成多少时间，决定了交互设计流程和界面的设计是否足够友好。

e）主观情绪。用户对于任务的主观感受，比如是否足够简单，是否容易找到信息，可以让用户衡量一下。

f）偏好和建议。可以让用户说出产品中哪些地方很喜欢？哪些地方不喜欢？或者让他们提一下建议。