什么是可用性测试
可用性测试是指，让一群有代表性的用户尝试对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。该产品可能是一个网站，软件，或者其他任何产品，它可能尚未成型。测试可以是早期的纸上原型测试，也可以是后期成品的测试。
你能从可用性测试获得什么？
在每一轮的可用性测试中，你都应该先明确具体的测试问题和目标，针对这些目标进行测试。举例来说，项目刚刚起步，你可以对定量的指标（如时间，错误率和满意度）进行测试，为日后修改网站提供参照。再例如，如果你已经设定了可测量的可用性目标，你可以看看你的产品是否切合这些目标。
对于一个典型的可用性测试，你可以：
找出该产品的任何的可用性问题
从测试参与者的表现收集定量数据
确定该产品的用户满意度
可用性测试是以用户为中心的设计的一个重要组成部分。用户为本的设计过程本身就应该包括对性能和偏好进行评价的一系列测试。
什么时候该做可用性测试？
尽早做，经常做。可用性测试可以让设计师和开发团队在产品成形之前尽早发现问题。 问题越早发现和弥补，所造成的损失就越低。这些问题是找到并固定好，越昂贵的补丁程序。随着项目的进展，对设计主体进行改动会变得越来越困难和昂贵。你测试的越多，并就相应测试进行改进，你就可以更加确信你的网站没有偏轨，确信它是符合您的目标和用户的需要的。
迭代开发过程——开发原型，测试用户，分析结果，随之修改原型，然后再重复测试、分析、修改周期——是开发一个成功的网站或软件的最好方式。
通过可用性测试你能学到什么？
通过一个典型的可用性测试，你可能找到这些问题的答案：
测试参与者能成功完成任务吗？
在成功完成的任务中，每项任务能做的多快？
在成功完成的任务中，每项任务要多少页（或者点击多少次）才能完成？
测试参与者的表现是否满足可用性目标？
测试参与者对网站的满意度如何？
做出什么改变才能确保更多用户能够完成地更顺利？
可能还有更具体的问题。举例来说，如果这一轮测试主要关注的是搜索功能，你可能会关注这些问题：
测试参与者会在页面上浏览还是直接使用搜索？
他们搜索时最常用的关键字是什么？
搜索框是否足够大，能呈现大部分的搜索关键字？它的位置是否合理？
搜索结果是否能引导用户的快速找到答案？
如果搜索结果恰好包含用户想要的答案，这些答案是否经常显示在第一页？
搜索是否能检测到拼写错误并帮助纠正？
可用性测试中你该注意什么？
必须牢记以下四点：
1. 你测试的是产品，而不是使用者。
2. 更多地依靠用户的表现，而不是他们的偏好。
3. 把你掌握的测试结果应用起来。
4. 基于真实的用户体验，找出问题的最佳解决方法。
1. 你测试的是产品，而不是使用者。
对一些用户而言， “测试”有负面的涵义。我们要努力确保他们不认为测试是针对他们。我们要让他们明白，他们正在帮助我们测试原型或网站。事实上，我们可以不使用“测试”这个术语。相反，我们是邀请参加者为我们提供帮助， “勇于尝试原型” 。
当用户难以完成任务时，我们应该改变网站，而不是改变用户。同时我们还应该思考该网站能在多大程度上符合那些典型用户的的目标，而不是关注用户在这个任务做的多好。
2. 更多地依靠用户的表现，而不是他们的偏好。
通过测试我们可以测量到用户的表现，以及他们的偏好。用户的表现包括是否成功完成，所用时间，产生的错误等等。偏好包括用户自我报告的满意度和舒适度 。
一些设计人员认为，如果他们的设计能迎合用户的喜好，用户在该网站上就会有良好的表现。但证据并不支持这一点。事实上，用户的表现以及他们对产品的偏好并非一一对应。一项研究发现，约有百分之七十的用户同意表现和喜好有联系。也就是说，他们在喜爱的网站上表现良好，在不喜欢的网站上表现欠佳。
然而，还有相对比较大比例的人（ 30 ％ ）认为 ，用户的表现以及他们对产品的偏好并非一一对应。他们在不喜爱的网站上可能表现良好，在喜欢的网站上也可能表现不佳。
关于人们为什么会对自己表现欠佳的网站给出较高的评价有多种解释。他们可能会把表现不佳归结到自己，而不是网站。或者说，他们可能担心给一个较低的评价会伤害网站设计者，也就是我们的感情。或者说，他们可能并没有完成任务，却自认为成功完成了，他们并没有意识到问题所在。基于所有这些理由，我们建议你：更多地依靠用户的表现，而不是他们的偏好。
3. 把你掌握的测试结果应用起来。
可用性测试不仅仅是用于核对项目进度的一个里程碑，你要知道，当最后一个参与者完成任务的时候，可用性测试还没有结束。整个团队必须仔细研究结果，设定优先次序，基于结果对或者网站原型进行修改。
4. 基于真实的用户体验，找出问题的最佳解决方法。
制造任何产品，包括大部分网站和软件，需要考虑许多不同的用户的工作方式、体验、问题以及需要。大多数项目，包括设计或修改网站，都要处理时间、预算和资源等方面的限制。平衡各个方面对大部分项目来说都是一个重大的挑战。
在你权衡利弊时，最好优先开发那些能使最多用户完成任务的网站或软件。有研究表明，产品推出后，用于支持失败客户的花费远远高于开发时对产品修正所付出的花费。
你需要认真考虑假定用户、使用场景以及可用性测试的结果，试图找出针对不同客户需求的理想解决方法。找不到最好的解决方法，用户就不能够顺畅地完成任务。有证据表明，即使用户延长使用时间在一个不太完美的产品界面完成任务，也远不及在一个更好的产品界面带来的成功感。
你是否需要一个实验室做可用性测试？
用不着，无论使用正式的或非正式的设备你都可以做可用性测试。使用任何类型的设备，你都可以采用各种正式或非正式的方法。
使用下述任何一种设置，你都可以进行有效的可用性测试：
两室或三室的固定实验室，配备视听设备
会议室，用户的家或工作室，配备便携式录音设备
会议室，用户的家或工作室，没有录音设备也可以用人眼观察和笔记来代替
当用户在不同地点可以远程控制
因此，即使你没有或没法找到一个固定的实验室，你也应该进行可用性测试。不要说，“因为我们没有一个可用性实验室，所以我们没法做可用性测试。“ 只要去做！在任何空间你都可以完成。
可用性测试需要多少人参与？
看情况。一个典型的测试需要8至16个人（每用户组）。如果每个用户将花费一小时，就意味着每个用户组的测试需要一到两个工作日。
当你的项目处在：
纸上原型或早期开发阶段
计划通过几轮测试整个开发
有相当一致的用户群
如果只要人帮忙找出严重问题，你可能只需要4到6人。
如果您有不同的潜在用户群组（例如医生、病人、研究人员），你需要所有这些群体的用户代表。如果你对用户的电脑操作或网络经验有要求，还需要包括经验较少的和经验较多的用户。
如果你要对你的产品或系统进行正式的定量测试，你将需要更多的人以获得统计上有意义的结果。对于诊断型的可用性测试，6至8个用户通常是不足以揭露产品的大部分问题的。
如果在网站开发过程中你一直在做迭代（重复）的可用性测试，就会有许多用户参加其中一个或另一个版本的网站测试。因此，尽管每个可用性测试只有少于10名的测试参予者，但在网站推出前你可能需要15到30人参加测试。
做可用性测试需要多少费用？
成本要看网站的大小，你的测试量，预期的用户类型数目，以及你期望这个测试正规到什么程度。
如果你已经有一个标准的测试程序和可用的材料设备，可用性测试将进行地很快很便宜。如果你或你的用户招聘公司拥有一个用户数据库，用于招募的时间就可以大量节约，因此，花费会更少。
在对可用性测试进行预算时应该考虑这些因素：
计划所用的时间：确定测试的主要问题，需要测试的用户类型，招聘的用户的筛选问卷以及测试场景。
招聘的花费：公司人员的时间，给招聘公司（通常是一个很好的选择）的花费，可用性专家需要花时间熟悉网站及其制作团队，设计相应的测试场景，如果你需要录制测试过程，还需要花费实验室或便携式摄录设备的租金。
团队观察用户（进行测试）花费的时间
付给测试参与者的报酬或礼物
分析视听资料，查找存在的问题以及推荐解决办法所用的时间
和开发人员讨论变动和修改方案，撰写调查结果和建议报告所用的时间。
记住，预算分析要包含多个可用性测试。打造一个网站（或产品）的可用性是一个反复迭代的过程。你会发现，用在在开发过程中几个小测试的预算比起在项目末期只做一个大型测试要有价值的多。
现在，你知道可用性测试是怎么一回事了吧？
作者：小胖
相关阅读
ab是一种用于测试Apache超文本传输协议（HTTP）服务器的工具。apache自带ab工具，可以测试apache、IIs、tomcat、nginx等服务器但是ab没
我曾经和来自不同开发机构的人探讨过关于他们如何管理软件开发，如何组织，他们遵循什么样的开发实践，以及什么样的开发实践真正有效。
设计是感性和理性的混合体。但在UX设计领域，我们更多依靠的还是理性。本文从产品的完整用户流：注册产品 — 首次使用 — 持续使用，分
siege是一款开源的压力测试工具，可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量
本篇文章作者分享了对有关内容及视觉可用性测试的几个问题的思考。前言最近项目中经常接触内容及视觉可用性测试，一开始有些懵圈，因