易用性测试的目标是确定产品被用户理解、学习、使用以及吸引用户的能力，但是理解、学习、吸引这些要求，并不像功能、性能、可靠性等有明确的测试标准，而是有很强的主观性，很难被量化，所以易用性测试也成了所有测试中最具争议的。如何从主观评价中提炼客观标准，是易用性测试的难点。
易用性测试要求表
易用性测试要求表：1）可以自动辨别当前环境是否符合基本要求（系统资源的要求）；2）能方便知道产品/系统的功能列表；3）引导用户进行正常操作以避免出错；4）页面交互能力；5）考虑使用者的障碍；6）兼顾习惯和约定俗称的隐喻。
从易用性测试要求表，讨论两个易用性测试方法：一致性测试法和可用性测试法。
一致性测试法
很多公司都会建立易用性设计机制或一些易用性设计基线，以此引导和保证产品的易用性设计，这些机制一般都会包含易用性测试要求表中的测试要求。一致性测试法，是确认产品在风格、布局、元素、操作上是否统一、合理，是否遵循了公司的要求。
不同的行业、产品和系统对易用性的要求会有差异。下面给出一个较为通用的一致性测试方法步骤，供大家参考。
1）确认页面和产品整体的风格是否相符，包括页面的色彩、文字大小、字体等。
2）确认页面的“图标”是否来自产品的图标库，风格是否统一。
3）确认页面的“元素”是否符合产品的UI设计规范。例如，规范中要求多选输入使用“□”，单选输入使用“〇”。如果在多选中使用了“〇”，就属于不符合产品UI设计规范的情况。
4）确认“页面布局”是否符合设计规范。例如，规范中要求分级不能超过3级，如果测试时发现页面在分级时超过了3级，就属于不符合页面布局设计规范的情况。
5）确认页面在“操作合理性”上是否符合设计规范。例如，规范中要求查询时，如果结果多于20条，则应提供分页显示功能，所以需要测试产品在查询结果超过20条时，是否分页显示了。
6）确认页面的各种“提示”是否符合设计规范，如确认、错误提示等在大小、格式、图标上是否符合规范。例如，规范要求确认类的提示框要新建一个窗口，窗口大小为30像素×90像素，内容以一个“感叹号”图标开头，然后紧跟文字，测试时就需要确认提示框是否符合这项规范要求。
7）重复上述步骤，遍历所有的页面。
可用性测试法
可用性测试从用户的使用场景出发，从用户角度去判断产品是否符合用户的使用习惯和关注点。
最适合进行可用性测试的人当然是用户本身，但现实中用户会充分参与的项目往往少之又少，此时深谙用户需求但对产品实现没有那么熟悉的人就成了最佳的测试人选，如产品经理、交付经理、需求工程师等。这是因为他们不会陷入产品实现的思维模式中，他们更能从用户视角去发现问题。测试人员交叉测试，也是个不错的主意，但是注意，新员工或者有意找的“小白人员”不适合作为此项目的测试人员，因为他们根本不了解用户，给出的测试结论容易因为过于主观而失去效用。
接下来讨论可用性测试的一般方法。
1）梳理用户典型场景，确定本次测试的范围。
2）讨论确定测试关注点和测试标准。原则上希望测试关注点和测试标准都包含在需求规格表中，但是实际项目中我们会发现，在进行这一步的时候大量需求规格并没有明确指出，这就需要需求人员、开发人员和测试人员再进行沟通，对测试标准达成一致。
可用性测试的关注点和标准
3）执行测试，并按照上表4的内容来记录测试情况。需要特别说明的是，执行测试时，“步骤”“求助”等应包含测试者操作错误的情况和正确的情况。例如测试者在配置场景时，前面执行了5个步骤都是错误和无效的步骤，后面6个步骤才是正确有效的步骤，那完成这个场景配置的步骤就是11个，而不是正确的那6个步骤。除此之外，测试中断和求助等情况也需要记录。
4）分析测试结果，确定可用性方面的问题。虽然我们在可用性测试中尽量使用可衡量的标准，但是难免还是有很多主观的成分，这就会导致在和开发人员确认问题的时候容易出现分歧。避免这类问题的一个方法是对比友商产品，特别是那些在易用性方面做得好的友商，从而让我们提出的易用性方面的改进建议更有说服力。例如，可以参考××（友商）的设计，通过××的组织方式，减少××功能的配置步骤。
摘取自刘琛梅老师的《测试架构师修炼之道：从测试工程师到测试架构师 第2版》
网友评论