HOW TO—撰写可用性测试报告
数据分析
根据测试计划中所确定的观测指标，你会得到各种类型的数据。在分析观测得到的数据时，可结合测试过程中记录的笔记，看看不同测试任务、不同用户之间是否存在一定的规律。值得注意的是，对于被测试者在操作中遇到的问题，需要详细说明该问题产生的背景（前提条件）、该问题的出现次数，遇到该问题的人数。看看能否从数据中发现一些共同的趋势。
[br]
[br]
当发现某个可用性问题时，需要考虑这个问题是局部的还是全局的，其他模块是否也会出现同样的问题。如果是全局的，那么你的结论很可能也会适用于其他模块。例如，由于系统某个界面的文案描述不清晰，用户无法顺利找到想要的功能，那么，是否其他界面也存在类似问题呢？确定问题严重等级
并不是所有问题的重要程度都一样，有些问题出现的频率更高（即被测试者中较多人遇到了这个问题），有些问题出现频率较低。为方便后期对系统的改进，我们建议将问题分为三到四个严重等级：
- 关键问题: 若该问题未得到解决，用户将无法顺利完成操作任务
- 重要问题: 若该问题未得到解决，将影响许多用户的操作，例如操作时感到迷惑、多次尝试不成功，甚至导致用户放弃操作。
- 次要问题：用户在操作时可能感到麻烦，但是仍然会继续完成操作。这类问题可以稍后再修改。
撰写可用性测试报告
总体来说，可用性测试报告应当包括以下内容：背景介绍，测试方法，可用性测试的结果、发现以及建议。这里有一些英文的报告模板可以借鉴，或许对你写报告有帮助。
背景介绍
简要介绍你的测试目标（网站or手机应用），此次测试的时间、地点，使用的设备，测试的关键执行步骤（例如测试中所用的素材等，放在报告的附录中），测试团队，测试过程中遇到的重要问题以及合适的解决方案。
测试方法
为方便其他人根据报告复现此次测试，借鉴此次测试中好的方法实践，因此需要将测试方法陈述在报告中。具体包括的内容有：测试任务，被测系统或界面的类型，所采集记录的数据指标，任务场景描述。另外，简要描述被试者的整体情况、用表格展示其人口统计学信息（例如年龄，职业，网络使用情况等），但是注意，不要记录被试者的全名。
测试结果
分析录像设备、录音设备、速记员等所记录的信息、日志。包括完成率最高和最低的测试任务，统计单个被测试者、单个任务的成功率，以及所有任务的平均成功率，（可用表格展示）。
- 每个测试任务完成的人数以及百分比（可使用条形图展示）
- （针对完成了测试任务的人）每个测试任务所使用的平均时间
- 满意度调查结果
- 被测试者的一些重要评论
结论和建议
列出数据分析（定性数据、定量数据、测试过程中的记录等）所得出的结论和建议。每个结论都应当有数据支撑——即在测试中实际观测到的用户行为，用户评论或者实际统计到的数据。在展示结论时，可以使用一个表格来汇总所有的结论与建议，也可以按照不同场景对应的结论逐一说明。需要注意的是：
- 虽然测试报告的主要目的在于发现问题，但也要指出现有系统中一些好的设计（例如：用户普遍反应较好，使用较为顺手，没有遇到操作问题的设计）以便告诉开发与设计团队，在后续版本中继续保持这些优秀的实践。
- 客观呈现报告的结果，哪怕测试结果是负面的。
- 在展示测试结果或者结论时，描述清楚、具体。
- 尽量针对每一项测试发现给出相应的改进建议。
重要观点结合图例、视频来说明
多使用图例、视频等可视化的方式展示报告，让报告更加直观、有趣，例如：
- 用屏幕截图形象化地展示测试界面：尤其是出现问题的页面以及好的页面。
- 用短片（秒拍）的形式描述具体问题。视频记录能够更清晰的呈现问题并且说服读者。
落地执行与检验测试
可用性测试的价值在于，能够将测试中的发现运用到实际迭代开发中，不断改进现有的系统。当然，不是所有的问题都能及时得到解决，不是所有建议都能及时执行，任何产品的开发都必然是多方面权衡日程、预算、人力和用户需求变更等各项因素的结果。这时，你需要根据问题的范围、严重程度来确定优先级，确保用户最亟待解决的问题能够得到及时处理。
最后，请记住，支撑一个设计拙劣的网站/系统所需要的成本永远要比在开发过程中改进这个网站所需要的成本大得多。
参考资料：usability.gov
http://www.usability.gov/how-to-and-tools/methods/reporting-usability-test-results.html
作者简介：Eva（新浪博客：Eva_UR的博客）,互联网用户研究从业者
关键字：用户体验, 测试, 可用性, 问题
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
