可用性测试（二战时期源于人因工程的测试）

起源

可用性最早来源于人因工程（human factors）。人因工程又称工效学（ergonomics），起源于二战时期，设计人员研发新式武器时研究如何使用机器、人的能力限度和特性，从而诞生了工效学，这是一门涉及多个领域的学科，包括心理学、人体测量学、环境医学、工程学、统计学、工业设计、计算机等。

历史发展

第一次有记录的可用性测试出现在1981年。当时施乐公司下属的帕罗奥多研究中心的一个员工记录了该公司在Xerox Star工作站（Xerox 8010 Information System）的开发过程中引入了可用性测试的经过。不过由于一共只有大约25,000套左右的销售成绩，Xerox Star系统被认为是一个典型的商业失败案例。

1984年，美国财务软件公司Intuit Inc.在其个人财务管理软件Quicken的开发过程中引入了可用性测试的环节。Suzanne E. Taylor在其2003年的业界畅销书《Inside Intuit》中提到“在第一次可用性测试实例中，该做法后来已成为行业惯例，LeFevre从街上召集了一些人来同时试用Quicken进行测试，每次测试之后程序设计师都能够对软件加以改进。”Intuit Inc.公司的创立者之一的Scott Cook也曾经表示“我们在1984年做了可用性测试，比其他的人早了5年的时间。进行可用性测试和在已售人群中进行可用性测试是不大一样的，而且例行公事的去进行和把它作为核心设计流程中的一环也是很不一样的”。

经过二十多年的发展和应用，可用性测试已经成为产品（服务）设计开发和改进维护各个阶段必不可少的重要环节。它的价值在于初期及早的发现产品（服务）中可能会存在的问题，在开发或投产之前提供改进方案，从而节约设计开发成本。而在产品（服务）的销售疲软或是使用过程中出现问题却无法及时精确的找到问题关键时，可用性测试可以在很大程度上的提高解决问题的效率。通过可用性测试不但可以获知用户对产品（服务）的认可程度，还可以获知一些隐含的用户行为规律。

国际标准

ISO/IEC 9126-1将可用性定义为“在特定使用情景下，软件产品能够被用户理解、学习、使用、能够吸引用户的能力” 【ISO/IEC 9126-1. Software engineering – Product quality – Part 1: Quality model[S]. International Standards Organization,2001.】。 ISO/IEC 9126-1阐述了在产品开发过程中软件质量的六个方面（见下图），依次为功能性（functionality）、可靠性（reliability）、可用性（usability）、有效性（efficiency）、维护性（maintainability）、移植性（portability）。ISO/IEC 9126-1将“使用质量（Quality in use）”作为广义的目标：满足目标用户和支持用户的使用质量，功能性、可靠性、有效性和可用性决定着目标用户在特定情景中的使用质量，支持用户则关心维护性和移植性方面的质量。目前ISO/IEC 9126-1有两个作用，首先是作为具体软件设计活动的一部分（可用性定义），其次是提供软件满足用户需求的最终目标。

国际标准ISO 9241-11将可用性定义为“特定的用户在特定的使用情景下，有效、有效率、满意的使用产品达到特定的目标”【ISO9241-11. Ergonomic requirements for office work with visual display terminals (VDT's) – Part 11: Guidance on usability[S]. International Standards Organization,1998.】。ISO 9241-11将可用性概括为三方面：有效性（effectiveness），用户使用系统完成各种任务所达到的精度（accuracy）和完整性（completeness）；效率（efficiency），用户按照精度和完整度完成任务所耗费的资源，资源包括智力、体力、时间、材料或经济资源；满意度（satisfaction），用户使用该系统的主观反应，描述了使用产品的舒适度和认可程度。

Nielsen（1994）认为实用性（utility）和可用性（usability）构成了系统能否用来达到特定目标的因素，称为有用性（usefulness）【Nielsen J．可用性工程[M]．刘正捷等译．北京：机械工业出版社，2004：16-24．】。可用性定义为“用户能否很好地使用系统的功能”，分为五个因素：可学习性（learnability），用户可以在短时间内使用系统完成相关任务；效率（efficiency），用户学会使用系统后，能够高效率地使用系统；可记忆性（memorability），用户在一段时间没有使用系统后，仍然能够使用系统；出错（errors），用户使用系统时能够少出错，系统必须防止灾难性错误发生；满意度（satisfaction），用户使用系统主观上感到满意。

Shackel（1991）将可用性定义为“按照人的功能特性，系统很容易、有效地被特定用户群使用，经过特定培训和用户支持，在特定的环境情景中，完成特定范围的任务”，并将可用性分为四个因素：有效性（effectiveness）、可学性（learnability）、灵活性（flexibility）、态度（attitude）。

测试的方法

所谓可用性评估，即是对软件“可用性”进行评估，检验其是否达到可用性标准。目前的可用性评估方法超过20种，按照参与可用性评估的人员划分，可以分为专家评估和用户评估；按照评估所处于的软件开发阶段，可以将可用性评估划分为形成性评估和总结性评估。形成性评估是指在软件开发或改进过程中，请用户对产品或原型进行测试，通过测试后收集的数据来改进产品或设计直至达到所要求的可用性目标。形成性评估的目标是发现尽可能多的可用性问题，通过修复可用性问题实现软件可用性的提高，总结性评估的目的是横向评估多个版本或者多个产品，输出评估数据进行对比。网站可用性测试包含的步骤有：定义明确的目标和目的，安装测试环境，选择合适的受众，进行测试和报告结果。

评估方法

（Cognitive Walkthroughs）是由Wharton等（1990）提出的，该方法首先要定义目标用户、代表性的测试任务、每个任务正确的行动顺序、用户界面，然后进行行动预演并不断地提出问题，包括用户能否建立达到任务目的，用户能否获得有效的行动计划，用户能否采用适当的操作步骤，用户能否根据系统的反馈信息评价是否完成任务，最后进行评论，诸如要达到什么效果，某个行动是否有效，某个行动是否恰当，某个状况是否良好。该方法优点在于能够使用任何低保真原型，包括纸原型。该方法缺点在于：评价人不是真实的用户，不能很好地代表用户。

（Heuristic Evaluation）由Nielsen和Molich（1990）提出，由多位评价人（通常4至6人）根据可用性原则反复浏览系统各个界面，独立评估系统，允许各位评价人在独立完成评估之后讨论各自的发现，共同找出可用性问题。该方法的优点在于专家决断比较快、使用资源少，能够提供综合评价，评价机动性好，但是也存在不足之处：一是会受到专家的主观影响，二是没有规定任务，会造成专家评估的不一致，三是评价后期阶段由于评价人的原因造成信度降低，四是专家评估与用户的期待存在差距，所发现的问题仅能代表专家的意思。

（User Test）就是让用户真正地使用软件系统，由实验人员对实验过程进行观察、记录和测量。这种方法可以准确地反馈用户的使用表现、反映用户的需求，是一种非常有效的方法。用户测试可分为实验室测试和现场测试。实验室测试是在可用性测试实验室里进行的，而现场测试是由可用性测试人员到用户的实际使用现场进行观察和测试。

用户测试之后评估人员需要汇编和总结测试中获得的数据，例如完成时间的平均值、中间值、范围和标准偏差，用户成功完成任务的百分比，对于单个交互，用户做出各种不同倾向性悬着的直方图表示等。然后对数据进行分析，并根据问题的严重程度和紧急程度排序撰写最终测试报告。

注意事项

你测试的是产品，而不是使用者

对一些用户而言， "测试"有负面的涵义。我们要努力确保他们不认为测试是针对他们。我们要让他们明白，他们正在帮助我们测试原型或网站。事实上，我们可以不使用“测试”这个术语。相反，我们是邀请参加者为我们提供帮助， "勇于尝试原型"。当用户难以完成任务时，我们应该改变网站，而不是改变用户。同时我们还应该思考该网站能在多大程度上符合那些典型用户的的目标，而不是关注用户在这个任务做的多好。

更多地依靠用户的表现，而不是他们的偏好

通过测试我们可以测量到用户的表现，以及他们的偏好。用户的表现包括是否成功完成，所用时间，产生的错误等等。偏好包括用户自我报告的满意度和舒适度。一些设计人员认为，如果他们的设计能迎合用户的喜好，用户在该网站上就会有良好的表现。但证据并不支持这一点。事实上，用户的表现以及他们对产品的偏好并非一一对应。一项研究发现，约有百分之七十的用户同意表现和喜好有联系。也就是说，他们在喜爱的网站上表现良好，在不喜欢的网站上表现欠佳。然而，还有相对比较大比例的人（ 30 % ）认为，用户的表现以及他们对产品的偏好并非一一对应。他们在不喜爱的网站上可能表现良好，在喜欢的网站上也可能表现不佳。关于人们为什么会对自己表现欠佳的网站给出较高的评价有多种解释。他们可能会把表现不佳归结到自己，而不是网站。或者说，他们可能担心给一个较低的评价会伤害网站设计者，也就是我们的感情。或者说，他们可能并没有完成任务，却自认为成功完成了，他们并没有意识到问题所在。基于所有这些理由，我们建议你：更多地依靠用户的表现，而不是他们的偏好。

把你掌握的测试结果应用起来

可用性测试不仅仅是用于核对项目进度的一个里程碑，你要知道，当最后一个参与者完成任务的时候，可用性测试还没有结束。整个团队必须仔细研究结果，设定优先次序，基于结果对或者网站原型进行修改。

基于用户体验，找出问题的最佳解决方法

制造任何产品，包括大部分网站和软件，需要考虑许多不同的用户的工作方式、体验、问题以及需要。大多数项目，包括设计或修改网站，都要处理时间、预算和资源等方面的限制。平衡各个方面对大部分项目来说都是一个重大的挑战。在你权衡利弊时，最好优先开发那些能使最多用户完成任务的网站或软件。有研究表明，产品推出后，用于支持失败客户的花费远远高于开发时对产品修正所付出的花费。你需要认真考虑假定用户、使用场景以及可用性测试的结果，试图找出针对不同客户需求的理想解决方法。找不到最好的解决方法，用户就不能够顺畅地完成任务。有证据表明，即使用户延长使用时间在一个不太完美的产品界面完成任务，也远不及在一个更好的产品界面带来的成功感。

实用性

无论使用正式的或非正式的设备你都可以做可用性测试。使用任何类型的设备，你都可以采用各种正式或非正式的方法。

可用性测试的地点

使用下述任何一种设置，你都可以进行有效的可用性测试：

* 两室或三室的固定实验室，配备视听设备

* 会议室，用户的家或工作室，配备便携式录音设备

* 会议室，用户的家或工作室，没有录音设备也可以用人眼观察和笔记来代替

* 当用户在不同地点可以远程控制

因此，即使你没有或没法找到一个固定的实验室，你也应该进行可用性测试。不要说，“因为我们没有一个可用性实验室，所以我们没法做可用性测试。" 只要去做！在任何空间你都可以完成。

可用性测试需要多少人参与

看情况。一个典型的测试需要8至16个人（每用户组）。如果每个用户将花费一小时，就意味着每个用户组的测试需要一到两个工作日。当你的项目处在： * 纸上原型或早期开发阶段 * 计划通过几轮测试整个开发 * 有相当一致的用户群 如果只要人帮忙找出严重问题，你可能只需要4到6人。 * 如果您有不同的潜在用户群组（例如医生、病人、研究人员），你需要所有这些群体的用户代表。如果你对用户的电脑操作或网络经验有要求，还需要包括经验较少的和经验较多的用户。 * 如果你要对你的产品或系统进行正式的定量测试，你将需要更多的人以获得统计上有意义的结果。对于诊断型的可用性测试，6至8个用户通常是不足以揭露产品的大部分问题的。 * 如果在网站开发过程中你一直在做迭代（重复）的可用性测试，就会有许多用户参加其中一个或另一个版本的网站测试。因此，尽管每个可用性测试只有少于10名的测试参予者，但在网站推出前你可能需要15到30人参加测试。

做可用性测试需要多少费用？成本要看网站的大小，你的测试量，预期的用户类型数目，以及你期望这个测试正规到什么程度。如果你已经有一个标准的测试程序和可用的材料设备，可用性测试将进行地很快很便宜。如果你或你的用户招聘公司拥有一个用户数据库，用于招募的时间就可以大量节约，因此，花费会更少。

可用性测试的预算

应该考虑这些因素：

* 计划所用的时间：确定测试的主要问题，需要测试的用户类型，招聘的用户的筛选问卷以及测试场景。

* 招聘的花费：公司人员的时间，给招聘公司（通常是一个很好的选择）的花费，可用性专家需要花时间熟悉网站及其制作团队，设计相应的测试场景，如果你需要录制测试过程，还需要花费实验室或便携式摄录设备的租金。

* 团队观察用户（进行测试）花费的时间

* 付给测试参与者的报酬或礼物

* 分析视听资料，查找存在的问题以及推荐解决办法所用的时间

* 和开发人员讨论变动和修改方案，撰写调查结果和建议报告所用的时间。

记住，预算分析要包含多个可用性测试。打造一个网站（或产品）的可用性是一个反复迭代的过程。你会发现，用在在开发过程中几个小测试的预算比起在项目末期只做一个大型测试要有价值的多。网站可用性测试是为了实现跨形式的视觉一致性，包括测试屏幕分辨率改变时的显示，边距和列布局，表单的颜色和大小，标签使用的字体，按钮的大小，所使用的热踺或快捷键，使用的动画/图形，按钮等控件的标签，同一字段的文本框的长度，日期和时间字段的格式。