3.询问开放式问题
根据开放式问题的结果发现新的问题以及玩家认为游戏存在的不足，将其统计进单个用户的观察记录表（表中黄色部分）：
4.优化测试任务列表
基于上一次的测试，确定新发现问题的严重性并将其添加至测试任务列表（表中绿色部分）：
四、形成测试结果
1.汇总观测数据
汇总所有受试者的观测结果：
表格标题行大写字母表示较高梯度段的受试者名字，小写字母表示较低梯度段的受试者名字。
2.数据处理
利用用户符合程度的评分对结果进行加权求和，算出每个问题的评分，评分越高证明对目标用户影响越大。
算出所有问题的评分后，可以与研发或运营部门确定问题的修改范围和修改方法，然后开始制作输出性文档。
五、输出与对接
1.工作范围表
研发项目内部进行的测试结果可以直接生成工作范围表，用于生成进度计划：
2.测试报告
帮助运营部门测试的项目或者代理项目可以生成测试报告，测试报告的重点在于用户问题的反馈以及问题描述及优化建议。优化建议的格式如下：
结语
以上就是我介绍的一种简单的可用性测试方法，这种方法虽然不像传统的互联网产品那样对各个系统的操作进行了操作时间测量、眼动仪测试等更为精确的测试，但是基本可以发现玩家在体验上的大部分问题。
因为作为手游玩家，相对于网页来说这些用户拥有更强的留存意愿，并且他们的核心关注点是在非界面的内容上，因此手游的可用性测试在降低界面学习成本，提高易用性的基础上更应挖掘玩家对游戏核心诉求方面的内容。
由于这些内容的共性较低，因此没能够在文章中很好的介绍出来，但是对于界面降低学习成本和易用性方面的优化以上方法应该基本可以满足手游需求了，最后祝各位的游戏大卖（笑）。
