可用性测试是指，让一群有代表性的用户尝试对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。该产品可能是一个网站，软件，或者其他任何产品，它可能尚未成型。测试可以是早期的纸上原型测试，也可以是后期成品的测试。
你能从可用性测试获得什么？在每一轮的可用性测试中，你都应该先明确具体的测试问题和目标，针对这些目标进行测试。举例来说，项目刚刚起步，你可以对定量的指标（如时间，错误率和满意度）进行测试，为日后修改网站提供参照。再例如，如果你已经设定了可测量的可用性目标，你可以看看你的产品是否切合这些目标。对于一个典型的可用性测试，你可以：找出该产品的任何的可用性问题从测试参与者的表现收集定量数据确定该产品的用户满意度
可用性测试和以用户为中心的设计的关系？可用性测试是以用户为中心的设计的一个重要组成部分。用户为本的设计过程本身就应该包括对性能和偏好进行评价的一系列测试。
什么时候该做可用性测试？尽早做，经常做。可用性测试可以让设计师和开发团队在产品成形之前尽早发现问题。 问题越早发现和弥补，所造成的损失就越低。这些问题是找到并固定好，越昂贵的补丁程序。随着项目的进展，对设计主体进行改动会变得越来越困难和昂贵。你测试的越多，并就相应测试进行改进，你就可以更加确信你的网站没有偏轨，确信它是符合您的目标和用户的需要的。迭代开发过程——开发原型，测试用户，分析结果，随之修改原型，然后再重复测试、分析、修改周期——是开发一个成功的网站或软件的最好方式。
通过可用性测试你能学到什么？通过一个典型的可用性测试，你可能找到这些问题的答案：测试参与者能成功完成任务吗？在成功完成的任务中，每项任务能做的多快？在成功完成的任务中，每项任务要多少页（或者点击多少次）才能完成？测试参与者的表现是否满足可用性目标？测试参与者对网站的满意度如何？做出什么改变才能确保更多用户能够完成地更顺利？可能还有更具体的问题。举例来说，如果这一轮测试主要关注的是搜索功能，你可能会关注这些问题：测试参与者会在页面上浏览还是直接使用搜索？他们搜索时最常用的关键字是什么？搜索框是否足够大，能呈现大部分的搜索关键字？它的位置是否合理？搜索结果是否能引导用户的快速找到答案？如果搜索结果恰好包含用户想要的答案，这些答案是否经常显示在第一页？搜索是否能检测到拼写错误并帮助纠正？
可用性测试中你该注意什么？必须牢记以下四点：1. 你测试的是产品，而不是使用者。2. 更多地依靠用户的表现，而不是他们的偏好。3. 把你掌握的测试结果应用起来。4. 基于真实的用户体验，找出问题的最佳解决方法。1. 你测试的是产品，而不是使用者。对一些用户而言， "测试"有负面的涵义。我们要努力确保他们不认为测试是针对他们。我们要让他们明白，他们正在帮助我们测试原型或网站。事实上，我们可以不使用“测试”这个术语。相反，我们是邀请参加者为我们提供帮助，"勇于尝试原型" 。当用户难以完成任务时，我们应该改变网站，而不是改变用户。同时我们还应该思考该网站能在多大程度上符合那些典型用户的的目标，而不是关注用户在这个任务做的多好。2. 更多地依靠用户的表现，而不是他们的偏好。通过测试我们可以测量到用户的表现，以及他们的偏好。用户的表现包括是否成功完成，所用时间，产生的错误等等。偏好包括用户自我报告的满意度和舒适度 。一些设计人员认为，如果他们的设计能迎合用户的喜好，用户在该网站上就会有良好的表现。但证据并不支持这一点。事实上，用户的表现以及他们对产品的偏好并非一一对应。一项研究发现，约有百分之七十的用户同意表现和喜好有联系。也就是说，他们在喜爱的网站上表现良好，在不喜欢的网站上表现欠佳。然而，还有相对比较大比例的人（ 30 ％ ）认为 ，用户的表现以及他们对产品的偏好并非一一对应。他们在不喜爱的网站上可能表现良好，在喜欢的网站上也可能表现不佳。关于人们为什么会对自己表现欠佳的网站给出较高的评价有多种解释。他们可能会把表现不佳归结到自己，而不是网站。或者说，他们可能担心给一个较低的评价会伤害网站设计者，也就是我们的感情。或者说，他们可能并没有完成任务，却自认为成功完成了，他们并没有意识到问题所在。基于所有这些理由，我们建议你：更多地依靠用户的表现，而不是他们的偏好。3. 把你掌握的测试结果应用起来。可用性测试不仅仅是用于核对项目进度的一个里程碑，你要知道，当最后一个参与者完成任务的时候，可用性测试还没有结束。整个团队必须仔细研究结果，设定优先次序，基于结果对或者网站原型进行修改。4. 基于真实的用户体验，找出问题的最佳解决方法。制造任何产品，包括大部分网站和软件，需要考虑许多不同的用户的工作方式、体验、问题以及需要。大多数项目，包括设计或修改网站，都要处理时间、预算和资源等方面的限制。平衡各个方面对大部分项目来说都是一个重大的挑战。在你权衡利弊时，最好优先开发那些能使最多用户完成任务的网站或软件。有研究表明，产品推出后，用于支持失败客户的花费远远高于开发时对产品修正所付出的花费。你需要认真考虑假定用户、使用场景以及可用性测试的结果，试图找出针对不同客户需求的理想解决方法。找不到最好的解决方法，用户就不能够顺畅地完成任务。有证据表明，即使用户延长使用时间在一个不太完美的产品界面完成任务，也远不及在一个更好的产品界面带来的成功感。
文章来源于领测软件测试网 https://www.ltesting.net/
