（写于2010年左右，那时候一直在做可用性测试，在我离职的时候算了一下，大概有25个报告，在福富三年四个月，我就是一直做测试，电信的产品真让人恶心，我一直写报告，但是最终看不到产品）
可用性标准包括：
容易学习－为了完成基本的任务，用户能够多快的学会使用一个他以前从未使用的系统？使用的效率－一旦用户对系统有些了解，他需要多少时间来完成关键的任务？
可记忆性－当用户再次使用系统时，为了有效的使用它，他/她将记得充分吗？
错误频率和严重程度－系统中出现错误的频率如何？他们的严重程度如何？用户如何从错误中恢复？
主观满意度－用户怎样对系统作出反应？他/她感觉使用的如何？
●用户招募
1、执行人：用户研究员、公司里人际圈较广的人、外包公司
2、招募人数：一个典型的可性测试需要招募8到12个人进行测试（为了防止意外情况，招募用户需要比实际测试用户多1到2个人。）
3、招募方式：
◎公司内部的人 （不要请产品的开发或者测试人员，可以邀请请如行政部门的MM、其他部门的同事，邀请同事快捷简单，还可以省去保密和费用的问题，千万要记得要和同事的上司沟通好哦）
◎网络上发布招募信息（我们可以选择人气比较旺的论坛。如小鱼网，需要详细的说明招募的条件、测试的时间、回馈的礼品或礼金等）
◎依靠同事或者朋友推荐（发动同事和朋友，把符合标准的亲朋好友推荐给你）
◎街头拦截等方式（到目标场所拦截用户）
◎用户资料库（依靠平时积累受测的用户资料，建立用户信息库）
最佳的情况上是我们的手上有许多用户资料，可以随时的时候根不同项目的需要来寻找不同的用户。当然建立丰富的用户信息库，需要平时的不断积累。（备注：客户信息样本库，我们正在建立中）
4、用户沟通：当寻找到符合标准的用户的时候，需要进一步进行沟通，沟通要点如下：
◎简单的介绍项目情况
◎再一次确认用户的相关情况，进一步的筛选用户
◎与用户确定测试时间
◎告之详细地址、联系方式，
5、确认沟通：
◎到了受邀用户出发前，务必再次与用户确认。
●用户文档准备
1、执行人：用户研究员
2、准备文档类型：
◎ 用户信息表（参考客户信息模版，但是因为产品的不一样，关注的点会不一样，收集的选项也会不同。一般情况下要关注人口统计学特征有：教育水平、使用经验水平、工作类型、年龄、性别、种族、身体条件等。）
◎保密协议（参考用户保密协议，主要涉及用户的权利和义务）
◎ 可用性测试脚本
要保证测试结果的公正客观和可比较性，以同样的方式问候用户，以同样的方式解释测试，以同样的方式回答问题，以同样的方式进行提示等等。为了做到这点，需要制定执行的脚本
可用性测试脚本主要包括以下内容：
1)用户的姓名、性别、编号、开始时间、结束时间、测试序号。
2）欢迎致词、简单介绍、测试的目的、签署保密协议等
3）测试前的一些问题
4）测试任务描述及记录
5）测试后的问题
更多具体参考标准文档可用性测试脚本，总之，测试脚本主要是给主持人使用的，所以主持人一定要熟悉脚本，尽可能的参与脚本的编写，只有熟读脚本才可能运筹帷幄，才可以在现场上应付自如。
在脚本的设计上必须是考虑详细周到的，不能想当然，由于现场环境的难控制，可能一些问题会被忽略，所以有备无患。并且在测试前，需要进行预演，及时调整脚本中的问题和不足。
◎ 用户任务卡片
根据可用性测试的目标制定测试任务，在设计任务中我们以发现问题，同时保证用户能够顺利完成任务为出发点，在任务的顺序和制定上需要多方考量，并且进行预演。如
1）任务应该是有意义的，以一定的逻辑顺序展现给用户。
2）把难点的任务后置，不能让用户一开始就陷入焦虑状态，会影响整个测试过程。
3）控制好测试时间，这里要记住无论你自己重复多少次测试过程，你都不会对一个测试需要多长时间有准确的估计，只有用一个新手用户进行预测试，你才能知道一些小的细节，才能大约推算出时间。这个人不需要与测试用户具备相同的特征，但他/她应该是产品的新手用户
◎ 测试前问卷（根据产品情况制定相关问题，并且根据项目情况取舍，有些项目不需要）
◎ 测试后问卷（根据产品情况制定相关问题，并且根据项目情况取舍，有些项目不需要）
●环境准备
录音录像设备
录屏幕软件
●用户招待
1、执行人：用户研究员/公司文职
2、接待事项：
◎到公司门口接用户，向保安索取入门卡，安排用户在休息期等候。
◎为用户准备好茶水、杂志、报纸等。
◎简单的介绍产品、沟通测试注意事项、测试任务等。
◎任务完成后，送用户离开公司。
3、注意点
◎注意要约用户时间上的安排，让用户久等会造成一些负面影响。如影响情绪、用户放弃等。
◎有时候一些用户是结伴而来的，需提醒用户不能相互交流沟通。
◎注意礼仪，时刻秉承用户至上的心怀。
总之，多从用户角度考虑，给用户良好的测试体验感受，我们才能得到用户的积极配合。
●现场主持
1、执行人：主持人（即用户研究员）
2、执行事项：
◎再请用户进入可用性测试室前，首先检查，确保所有的材料、物品准备完好，因为现场的任何一个准备不足都可能会影响测试过程。
◎当用户在执行任务的时候，让用户大声的说出自己的想法。
◎在测试过程，正常情况下，不要随意干扰用户操作。当用户在操作中，陷入困境的时候，应该给予一定的提示，
◎在脚本上即使记录用户使用时的表情和用户的回答。
◎客观的观察与记录，可以询问被测试者做某项操作的原因，但不能向被测试者做演示说明、不能指点被测试者如何“正确”操作。
◎营造轻松自在的氛围，尽量鼓励用户说出产品的使用真实感受和真实想法
●测试总结
1、整体测评：对个题目的失败率、平均耗费的时间、以及难易评价数据进行简单的归纳。
2、问题的归纳：将测试中发现的问题，用图标的方法分析和表现出来，并且提供改进建议，找到问题就是要改进，一般来说这样简单的测试会暴露许多设计问题出来。具体要归纳的有下面几个部分：
◎问题描述：简要客观地描述问题的状态。
◎问题类别：判断问题的归纳。
◎问题分析：从用户角度，要有数据支撑，分析问题产生的原因。
◎问题出现的频率：有多少人在此发生问题。相似的设计出现的频率如何。
◎失败率：有多少人因此操作失败。他在整个测试环节中的重要性如何。
◎问题严重性：根据该项任务的重要性、失败率、误点击率的评价，综合评定。
◎修改意见：根据所观察的测试，要提出一套解决问题的修改意见。这个也就是测试的目的所在.
●测试报告
将测试总结、UED成员建议以及这次测试的的项目背景、测试的执行过程、用户信息表、测试人员、测试环境说明等相关内容，整理成报告提交。
陈淑玲于2010年