原文来自《The Wiley Handbook of Human Computer Interaction》一书中的“Usability Testing ”章节
作者：Sirpa Riihiaho
导论
可用性是一个多方面的术语。在以用户为中心的产品开发中，它通常意味着在特定环境下的使用质量，或ISO 9241‐11标准(1998)对其的定义“特定用户在特定使用环境下有效、高效和满意地使用产品以实现特定目标的程度”。在以用户为中心的设计中，重要的是在整个开发过程中评估可用性，而不是只在最后进行大量测试。根据可用性评估的目标，可用性评估可以分为形成性评估和总结性评估。形成性评估用于收集用户反馈以供进一步开发，而总结性评估用于评估是否满足设置的可用性需求(Hewett, 1986)。由于可用性应该在开发过程中进行多次评估，大多数评估本质上是形成性的，允许在方法和测试设置中有更多的修改空间。可用性评估方法也可以根据用户的参与程度分为用户测试方法和可用性检查方法。可用性测试这个术语有时被用作用户测试或可用性评估的同义词。为了区分一种方法和一组方法，本章使用了以下术语:
•用户测试涵盖了一组涉及用户参与的可用性评估方法
•可用性测试是一种用户测试方法，由一个或多个具有代表性的用户在观察下依次执行任务或描述他们的意图。
可用性测试的可用性评估过程分为四个阶段：
1设计和准备测试。
2进行测试。
3分析结果。
4传达结果。
虽然可用性测试有多种变体，但在受控测试环境中使用预定义测试任务的测试仍然是一种普遍的做法。然而，现场、移动中的测试变得越来越普遍。本章概述了可用性测试的基本过程，然后介绍了传统可用性测试的一些修改。
规划可用性测试
测试计划用于获得管理层和其他相关人员的批准，并阐明测试的目标。在谈论可用性评估的目标时，有两个不同的目标层次：评估过程的总体目标和动机，以及所选择的可用性属性的更具体的目标。可用性评估的动机包括确保产品达到最低可用性水平;获得有关目标达成情况的反馈;并确定产品中潜在的可用性缺陷。与用户一起测试还有机会收集有关用户需求的新信息，将设计与竞争产品进行比较，并找到培训问题。
在这些总体目标和动机中，通常有一些更具体的评估目标。这些目标应该是特定的，以确保评估真正感兴趣的属性，并选择一组合适的评估方法，测试参与者和测试任务。例如，在一个商业现货（COTS）软件系统采购中，我们大学正在购买一个新的当前研究信息系统（CRIS），的我们的总体目标是从两种备选方案中找出最好的系统，强调其成本，实用性和可用性（Riihiaho，Nieminen，Westman，Addams-Moring，＆Katainen，2015）。几所大学参与了我们大学组织的采购流程，因此对于竞争公司来说这是一个非常有吸引力的交易。获奖系统将由几家芬兰大学购买，因此这是一项重大投资，可能会导致与之相比表现不佳的公司提起诉讼。我们认为定量结果在法庭上比定性结果更容易证明，因此我们强调统计结果和比较。这个需求影响了我们在测试过程中做出的许多决策。现在，我们将考虑设计测试时提出的问题。
我们必须要测试一些功能吗?
如果测试用户可以尝试的话，那么他们就更容易对系统进行评论。这在总结性测试中尤其重要，因此如果需要进行统计分析，最好使用功能原型或工作系统。然而，在形成性评估中，测试用户和测试主持人之间更加对话式的交互是合适的，因为主持人可以帮助测试用户使用简单的草图原型或网站线框。
当使用纸质原型时，建议使用多个版本，因为Tohidi、Buxton、Baecker和Sellen (2006a)的研究表明，与评估三种备选方案相比，用户在评估一种设计时给出的评分要高得多。然而，在这两种情况下，重新设计方案的数量仍然很低。为了获得更多的想法，Tohidi, Buxton, Baecker和Sellen (2006b)在之前的研究中测试了原型之后，要求测试参与者在一张纸上勾画出他们理想的产品设计。如果测试用户看到了系统的多个版本，他们自己的草图就会更加通用。
如果将纸上原型和正在运行的系统进行比较，例如，在将新思想与旧系统进行比较时，必须记住，主观评价是不太具有可比性的。Sauer和Sonderegger(2009)操纵了原型的美学和逼真度。有点令人惊讶的是，与所有其他版本(包括类似的纸上原型)相比，美学水平较低的全功能系统的吸引力评分要低得多。研究人员认为，纸上的原型给用户留下了空间来确定系统的最终外观，因此测试用户可能是基于这些含义而不是手头的原型来进行评估的。(Sauer & Sonderegger, 2009)。
我们应该使用哪些指标？
我们应该从一开始就明确测试的目标，以便能够集中测试并将范围限制到特定的用户组、属性和任务。对于感兴趣的每个属性，应该设置能够评估可用性级别的度量。例如，Hornb_k(2006)对不同指标的有效性、效率和满意度进行了出色的总结，如二进制任务完成、准确性、错误率、完整性、和结果质量。
这些可用性指标很重要，尤其是在总结性评估中，但也可用于形成性可性评估，以给出与以前的测试和竞争产品进行比较的定量结果。然而，如果在测试中使用了“出思考”方法，那么测量应该强调性能时间以外的其他指标，因为出声思考可能会降低性能。
在我们的CRIS案例中，我们从ISO 9241‐11标准(1998)中选择有效性、效率和满意度作为我们的可测量属性。有效性是通过在15分钟内成功完成多少任务来衡量的。如果任务没有及时完成，或者被用户放弃，或者被用户或评估人员判定为不成功，则不计算在内。效率是指用户完成任务的平均时间，不成功的任务最长使用15分钟。由于测试的是性能时间，所以在这些测试中我们没有使用大声思考。最后，使用正面版本的系统可用性量表(SUS)来衡量满意度(在本章后面讨论)，并要求用户在测试这两个系统之后选择他们最喜欢的系统(Riihiaho等，2015)。
无论这些度量标准是什么，它们都应该包括客观和主观的度量，但仍然要明确分开。例如，完成任务的时间通常在测试用户之间差异不大，但用户对需时间的感知方式可能会有很大差异，并且可能会显示系统使用中的挫折（Hornbæk，2006）。
我们应该拥有什么样的测试用户，以及多少测试用户?
可用性测试的参与者应该尽可能地代表真实用户。朋友，家人或同事不是首选，因为参与者和主持人之间的密切关系很容易使结果产生偏差。 Schrier（1992）也指出，如果观察者不熟悉，测试用户通常更容易与主持人和观察者互动，并评价产品。但是，在东亚文化中，建议测试用户熟悉主持人，并且他们的地位高于主持人，以便对评估系统给予的负面评价感到满意（Yeo，2000）。
在选择一组合适的测试参与者时，应考虑许多因素，例如不同的用户群，年龄，性别和专业水平。用户的专业知识受到他们对评估系统或其先前版本的体验的影响，同时也受到他们在计算机、信息技术和其他技术设备方面的经验以及他们在任务领域的经验（Nielsen，1993，p.43）的影响。用户的组织知识，培训，输入设备技能，资格和语言技能也会影响他们以前的经验（Maguire，2001）。
特别是在评价职业系统时，测试用户应是任务领域的专家，但应根据测试的目标考虑使用类似系统的经验水平适当的专家。新手用户善于发现具有可学习性和可承受性的问题，而专家用户善于发现与同类产品不一致的地方，发现不符合逻辑的特征。在我们的CRIS案例中，我们决定同时使用来自管理的专家用户和来自研究人员和研究生的新手用户(Riihiaho等，2015)。
如果要评估的系统是针对儿童的，那么最好分两个阶段进行测试：在第一阶段，测试团队向孩子们介绍自己，并且只在第二阶段，要求孩子们进行测试观察中的一些任务。对于儿童，必须考虑测试参与者的语言表达能力和倾向，集中精力，动机，适应陌生环境的能力，自我报告的可信度，以及他们的知识和技能（Markopoulos＆Bekker，2003）。在学校环境中，教师是选择合适的测试参与者的宝贵助手。
所需的测试用户数量一直是一个热门话题，尽管有一些研究显示测试用户数量和检测到的可用性问题数量之间没有关系，例如Molich，Ede，Kaasgaard和Karyukin的研究（2004） 。此外，Lindgaard和Chattratichart（2007）的分析表明，测试任务的数量与检测到的问题的数量相比，优于测试用户的数量。
即便如此，评估的期望覆盖范围，系统的复杂性，计划的迭代次数，可用的测试资源以及统计分析的需要都会影响所需的测试用户数量。在形成性测试中，经常使用五个用户，因为Lewis（1994），Nielsen（1994a）和Virzi（1992）的早期研究表明，大约80％的可用性问题可以在五个用户中找到——可能是由于评估相当简单的系统。在总结性测试和统计结果中，经常需要更多用户。为了估计所需的用户数量，Lewis（2001）给出了估算发现问题比例的基本公式：1−(1−p)n，其中p是问题发现率，n是测试用户数。在Hwang和Salvendy（2010）最近的一项荟萃分析中，发现通常需要9名用户才能解决80％的问题。
在我们的CRIS案例中，我们对发现的问题的比例不感兴趣，但希望测试结果中存在一些统计差异。 因此，我们在比较中使用了六位专家和六位新手用户的结果。 为了获得这12个可比较的结果，我们需要三个额外的用户，因为我们在这三个测试中遇到了一些技术问题，这些问题会影响他们的结果。此外，我们在两组中都有一个试验测试用户在实际测试之前检查我们的测试设置。
我们应该选择哪些测试任务和方案？
在设计可用性测试时，建议进行一到两次可用性检查，以获得关于可用性问题的一些早期概念。如果检查发现了一些相当大的问题，那么可以在用户参与之前修复它们，或者用一些测试任务对测试用户进行验证。
在规划可用性测试时，在实际使用环境中采访一些用户是一种有益的方法。首先，它提供了适合的场景和测试任务的想法。其次，它可以更深入地了解用户的目标，从而有助于找到测试的重点。最后，有关用户目标和优先级的信息有助于产生有效的重新设计方案，以解决测试中发现的问题。
测试任务应该是现实的，并代表实际使用的领域。 任务应涵盖产品的最重要部分，并反映所选的属性作为测试的重点。任务不应超过一个小时，以保持测试用户的注意力。但是，任务的覆盖范围应该足够广泛，并且各种任务的大小足以让用户有机会尝试系统。此外，Lindgaard和Chattratichart（2007）的分析表明，检测到的问题数量与测试任务的数量相关，因此建议每个用户执行多项任务，因为获得测试用户的工作量通常很大。
测试任务的质量和相关性会影响发现的问题数量（Skov＆Stage，2012）。因此，测试任务应该是有意义的，具有明确的目标，但没有关于如何完成它们的说明。即使测试任务的措辞也不应给出所需操作的明确提示。
在测试开始时有一个简单的任务可以让测试用户有机会熟悉测试设置并稍微放松一下。任务应该彼此独立，并且一次呈现一个，以便在时间不多的情况下可以忽略某些任务。场景可用于在任务之间建立联系，并为参与者提供任务的社会和组织背景，例如，护士工作的特定转变。如果没有合理的背景情景，那么来自中国文化的人可能会发现孤立的任务是人为的，难以理解（Clemmensen等，2009）。
在我们的CRIS案例中，我们为两个用户组都设置了5个测试任务。研究人员和研究生的任务如下(Riihiaho等，2015):
•在系统中手动输入文章详细信息;
•创建对另一所大学的研究访问的描述;
•修改您的研究概况;
•根据个人资料撰写一份包含出版物和活动的简历;
•从BibTeX文件中将以前的出版物导入系统。
每个任务的最大长度为15分钟，然后要求用户继续下一个任务。测试用户可以在任务中使用他们自己的研究信息，因为我们在测试之前已经将他们的数据输入到比较系统中。有了这些现实的数据，用户就有机会评估系统的实用性，正如Bdker和Madsen(1998)所建议的那样。
在问卷调查和访谈中我们应该问什么？
在用户执行测试任务之前和之后经常使用调查表。通常，预测试问卷侧重于用户的背景信息以及他们对系统的期望和态度。然后，测试后问卷收集有关用户使用评估系统的体验的信息。结构化和半结构化访谈也可用于补充或替换这些后测问卷。
建议使用标准化问卷而不是设计自己的问卷，因为它们具有更好的可靠性（Hornbæk＆Law，2007），特别是在总结性评估中。例如，系统可用性量表（SUS，https：// www.usability.gov/how-to-and-tools/methods/system-usability-scale.html）于1986年免费提供，随后成为几乎是可用性评估的事实标准（Brooke，2013）。 SUS调查问卷包含十个评级为五点李克特式评级的陈述（强烈不同意与强烈同意）。综合结果以单个数字表示“代表所研究系统整体可用性的综合指标”（Brooke，1996）。该评分范围为0到100，理论平均得分为50分，但实际实现的平均得分接近70（Bangor，Kortum＆Miller，2008）。
SUS问卷包括五个正面陈述和五个否定陈述（Brooke，1996）。正面和负面陈述的混合用于平衡各种偏见，并使受访者在回答之前考虑每个陈述。然而，负面陈述更有可能在回答问题和解释结果时出错，因此Sauro和Lewis（2011）开发了SUS问卷的全面正面版本。由于他们的结果几乎与原始调查问卷相同，因此建议使用此正面版本，特别是如果评估人员无法与用户核对答案。为了避免误解，我们还在CRIS案例中使用了所有正面版本并进行了一些小修改：Sauro和Lewis（2011）在其版本中使用了术语网站，因此我们在我们的版本中返回了术语系统。SUS语句的原始版本和修改版本如表14.1所示。
另一种常用的标准化和免费提供的问卷是NASA任务负荷指数（NASA-TLX，http：//humansystems.arc.nasa.gov/groups/tlx/）。它旨在使用六个分量表评估人机交互中的主观工作量：心理，物理和时间要求，以及自己的表现，努力和挫折。商业问卷包括软件可用性测量库存（SUMI，sumi.uxp.ie），以及网站分析和测量库存（WAMMI，http：//www.wammi.com/index.html）。
在使用问卷时，应该记住人们在调查和访谈中都渴望取悦。因此，应该通过计算机而不是亲自询问潜在敏感问题以最小化偏差，并且当使用1到5的等级时，应使用3.6作为中性均值的估计值，而不是数学3.0（尼尔森， 1993年，第37,213-214页）。
此外，测试用户在测试后问卷中的主观质量判断不一定反映整个测试，而只反映其最近的事件（Hassenzahl＆Sandweg，2004）。因此，如果需要任务相关信息，建议使用特定的任务后问卷（Sauro＆Lewis，2009）。
儿童在访谈和问卷的调查结果中显得尤其具有挑战性（不确定性），因为他们的语言和运动技能、阅读年龄、自信以及取悦他人的欲望都会影响他们的答案。（Read& MacFarlane, 2006）当我们评估一个儿童教育系统时，我们使用的一种方法是让五个孩子在教室里和他们自己的老师一起测试的功能原型。在这个测试之后，我们在我们开发的反馈游戏的帮助下，对孩子们进行了访谈。
反馈游戏使用的是一种物理游戏，包括八排面试问题和五列脸谱，孩子们可以在每个问题之后设置身体（脸谱）。例如，我们问孩子们是否觉得使用这个系统很有趣。所有的孩子都在同一时间设置了一个他们认为更合适的栏目，然后他们开始了讨论，提出了更详细的问题来说明作出答案的原因。例如，关于乐趣的问题，再加上一个关于系统中最有趣或最无趣部分的问题。对于物理对象和规则来说，每个人都有自己的时间来解释答案，这使得这种互动对孩子们来说很容易，也很自然。(Kantosalo &Riihiaho, 2014)
我们应该在哪里测试呢？
可用性测试几乎适用于所有地方。网站对参与者来说更熟悉，使他们更容易放松，但对客户来说更具有挑战性，因为很难控制，而且设备必须随身携带。因此，特定的实验室能够更好地控制感兴趣的变量，测量结果也更加精确，但人工环境可能会产生不切实际的结果。例如， McDonald, Monahan, 和Cockton在与他们的访谈中发现的问题里，多达三分之二与使用环境有关。
尽管测试的物理位置，测试内容应该包括实际使用其中最关键的组件。需要考虑的问题包括：实际的测试数据；可用的日常材料和工具；需要模拟的压力和时间压力；用户之间需要的合作；系统和其他有关材料的放置；以及组织情况和用户的作用。对于我们的案例，我们的可用性实验室提供了一个控制良好的环境，接近用户，并且使用了特定于用户的实际研究数据来为每个测试用户提供更多的使用环境。
虽然在几个细节上使用上下文具有许多属性，但最常见的上下文很容易涵盖一半以上的使用情况。例如，Kim，Lee，and Choi(2002)研究了移动互联网的使用背景。他们将使用情境分为八个参数：使用系统的原因；情绪状态；使用的一只或两只手；移动或静止；视觉；听觉；周围的人数；以及与他人的互动程度。他们的结果显示，在256种理论可能性中，只有两种类型的使用上下文涵盖了20%以上的报告使用会话。此外，手的可用性、腿部的移动以及用户周围的人数对移动互联网中检测到的可用性问题的影响最大。(Kim等人，2002年)。
我们是否应该有一位主持人在场？
在实验室进行测试有好处也存在问题：如果测试数据不存在，测试数据的完整性就不那么偏倚，但是用户在测试室中可能会感到不舒服，而这反过来又可能使测试结果产生偏差。与测试用户的交互指南强调了通过语音和肢体语言的语态来评估用户行为的风险，但是对于这种存在的实际影响的研究却很少，而且结果也不尽相同。
负面影响是相当罕见的，因为HART和(1992)的研究表明，如果存在某一种评估，专家用户对系统的负面评价很高，但即使在这些研究中，用户也给出了稍微正面的评分。因此，其他研究显示出了更积极的效果，例如鼓励参与者寻找比自己已知更多的信息，以及更肯定地完成测试。2009年的研究还表明，在测试用户和测试用户之间进行良好的再加工可以提高用户的性能。最后，作者自己的实验(2015年)表明，当用户在问卷中评估系统的过程中愉快程度高，测试的存在会产生更积极的结果。
由于主持人的存在可能会影响用户的性能和主观评级，因此建议用户仅在汇总测试中留下，或至少最小化与用户的交互。例如，在我们的CRIS比较中，我们有一个主持人参加了测试，以帮助解决技术问题，但主持人大多是沉默的，并且在需要时只给出了预定的答复。在形成性测试中，强烈建议在用户旁边设一个主持人，因为这给用户提供了一个宝贵的机会来密切观察用户的“第一印象”，并探讨他们的期望和体验。
我们是否应该出声思考？
在可用性测试中，测试用户通常被要求在执行测试任务时出声思考。出声思考作为一种研究认知过程的方法，长期以来一直被应用于心理学研究中，也成为可用性测试的核心方法之一。（出声思考—thinking aloud，即"出声思维"。是指凭借出声的口头言语而进行的思维。如幼儿早期的思维。他们用大声的言语组织自己的思维过程和表达自己思维的结果，离开了出声的言语就没有思维活动。儿童7岁以后，出声思维就逐步变为无声思维。在心理学实验中，用作口语报告分析的研究方法，研究人的思维活动。即实验者要求被试进行大声思维，并将被试的口语报告记录下来，以便对人在思维活动中的行为进行客观的分析。1945年格式塔心理学家邓克尔首先使用。20世纪5O年代认知心理学兴起后，常用于问题解决研究。）
参与者在完成任务时，可以同时记录自己的想法，也可以在完成测试任务后回顾性地描述他们的想法。回顾性报告被认为不如同期报告那么有用和可靠，因为它们依赖于参与者对他们一段时间前的想法的记忆。回顾性报告也需要测试用户更多的时间，因此在可用性测试中，同时出声思考已成为最普遍的口头报告形式。
口头报告有三个层次：在第1级，信息是以工作记忆中处理的同样方式告知的；在第2级，原始信息不是口头形式的，如图像，因此必须翻译；在第3级，被试被要求做的不仅仅是大声表达他们的想法，比如根据给定的指示选择信息。如果被试被要求描述他们的运动活动或日常行动，否则他们不会注意，则属于第3级。在第1级和第2级，认知过程保持不变，就好像参与者在默默地行动一样，但第2级可能仍会减慢表现。然而，在第3级，受试者可能会改变他们的正常行为，更多地关注信息，从而使他们在当前或接下来的任务中更有效率。
在评估中，经常使用响应时间来衡量可用性的水平。因此，在评估中不应使用出声思考，也不应将其保持在第1或2级。然而，在评估中，从用户那里获取尽可能多的信息是很重要的，所以通常要求用户给出他们只是陈述自己的理由。用户还可以探测任务之间的进一步信息，甚至在任务期间，如果发生了令人惊讶的事情，或者用户在执行任务时被卡住了。这种轻松的思维方式为讨论提供了空间，也有助于在测试过程中创造一个良好的结果。在我们的例子中，我们没有使用出声思维，因为我们使用响应时间作为我们的中心可用性度量标准。
引导测试
一个非常实用的清单列出了进行测试的十个步骤，包括：
1 自我介绍
2 概括地描述测试的目的。
3 告诉参与者，他们可以随时辞职，但他们仍然可以得到费用。
4 解释房间里设备的用途。
5 解释怎样能大胆设想，并给出例子。
6 说明测试中不会提供帮助。
7 描述任务并且介绍产品。
8 询问用户是否有任何问题，然后开始观察。
9 总结观察结果。
10 处理运用结论。
在任何实际测试之前，至少需要一个先导测试来检查测试任务、指令、设备和位置。试验应及早进行，以便在必要时仍有足够的时间进行更改。预测用户不必来自目标组，而是来自测试团队之外的人，以便能够发现模糊的、重复的任务序列。由于在我们的案例中有两个具有不同测试任务的用户组，所以在实际测试前几天，我们对这两个组进行了一个试点测试。
可用性测试通常是为了减少产品的使用压力，但是测试过程本身对测试参与者来说压力很大。测试前的主要道德考虑因素包括：确保参与者到达前一切就绪；告知参与者系统的状态和结果的机密性；确保参与者知道测试的产品，而不是用户。
为了证明用户的技能和知识的一致性，硕士和高级教师的角色对测试用户和测试者都是合适的，这类似于AXECT(1995)在查询中所起的作用。在任何情况下，都不能表示参与者犯了错误或进展得太慢。相反，无论发生什么，都应该“在整个测试过程中保持积极的态度”(1992年)。测试结束后，测试人员应该感谢参与者的帮助，并确保他们在测试结果中保持匿名。这些录音只有在参与者的许可下才能在测试小组外展示。
分析讨论结果
测试分析解释了在测试过程中发生了什么，以及出现了哪些问题和获得了哪些成功。这些问题应按其重要性-范围和严重性-加以组织。问题的范围是指问题的地方，即问题有多广泛。因此，可用性问题的严重程度是指问题发生的频率、问题发生时的影响以及问题的持久性。有几种量表可以对这些问题进行评分。例如，给出了一个四级等级，并明确地参考了这一标准：
·等级一：问题妨碍用户完成任务；
·等级二：问题显着地降低了用户的性能，降低了用户的性能；
·等级三：问题对可用性影响不大；
·等级四：问题指向了未来潜在的升级可能。
分析和评分可以在观察会议和做笔记时进行，或随后由多个视频数据分析完成。例如，现在的数据分析，可以用来分析测试日期间的测试。在这种方法中，一个特定的促进者帮助总结每个测试日结束时的注释和发现，并在每个测试日结束时给出相应的注释。在他们的学习中，等等。(2004)仅在相应的视频数据分析所需时间的10%内就能够检测到系统中85%的关键可用性问题。
如果需要改进，交流结果是评价过程中的一个关键阶段。结果不应该使开发人员感到失望，而应该给出使系统更好的想法。因此，这些积极的发现也应该被报告，可用性问题的总数应该保持在一个可管理的范围内，比如15-60个问题，只关注最重要的问题。
分析结果应在一份报告中连同重新设计建议一并提出。如果可能的话，测试团队应该与少数用户一起测试这些建议，以验证这些想法。记住业务目标，并反映对这些目标的建议更改，这也提高了测试报告对开发人员的效用。总之，结果应该以多种方式传达给开发团队和管理人员：书面报告、会议或研讨会中的结果，以及测试过程中的视频片段。
国际标准13407(1999年)提供了侧重于评估的可用性评估报告内容的一个例子，而ISO/IEC 25062(2006年)定义了专用于评估的通用行业格式。这些报表格式的主要结构如表14.2所示。
可用性测试的改进
出声思维的方法被广泛使用，但它并不适用于所有的情况，例如在关键条件下使用的测试系统，或者用于幼儿的测试。一些测试用户也发现了这种方法和方法。此外，作者和Simon(1980)的研究表明，出声思维可能会降低用户的性能，因此测试用户可能会更多地关注他们在正常使用中会忽略的细节。因此，为了满足用户使用评估系统时的各种需要和经验，开发了几种替代方法。这介绍了一些可用性测试方法，这些方法是为了克服传统实验室测试中存在的各种问题而开发出来的。
配对用户测试是一种让思维更自然的方法。它涉及两个用户一起试图解决一个问题或探索一个系统。它已经使用了很长时间，所以它有几个名称，如建设性的交互，学习，团队可用性测试，配对用户测试和交流沟通。
在配对用户测试中，参与者被鼓励对所研究的系统进行实验，只有在讨论结束时，他们才会受到干扰或中断。参与者向他们的伴侣解释他们的想法和理由，因此他们需要事先认识对方，并拥有可比的专业知识，才能使对方变得平等和放松。当用户参与系统的分析和探索时，用户可以在配对用户测试中与测试用户保持更远的距离。例如，我们在评估游戏老虎机、办公系统和电话时都采用了这种方法。
朋辈导修是利用两个用户之间的自然交互的另一种方式。例如，Hpp、Hmll和(2003)使用朋辈导修对儿童互动电脑游戏进行评估。同样，我们在对9-10岁儿童的新教育体系进行评估时，也使用了朋辈导修。我们一次只有一个孩子，先学会使用这个系统，然后教他/她的朋友。这样，孩子们就可以使用他们自己的语言，把注意力集中在他们最感兴趣的事情上。
我们对成年人也使用了朋辈导修，例如在考试期间让第三方进入考场。在研究与工作相关的系统时，这个第三方扮演了一个新的角色，在一个娱乐系统中，角色是亲戚或朋友在使用评估系统时征求意见。这种设置有助于揭示用户在控制系统时的疑虑和不确定性。
多元可用性演练是一种将具有代表性的用户、系统设计者和可用性专家聚集在一起，对新的设计思想进行评估和讨论的可用性评估方法（Bias，1994）。讨论是基于参与者在纸张原型的帮助下尝试执行的任务，例如（参与评估）系统的一组用户界面草图。参与者将得到他们所执行的给定任务需要的对话副本，以及根据他们的行为进行对话的指示。
此时很少提供文档或帮助功能，因此系统设计人员通常作为“活文档”，回答用户需要在系统文档的帮助下才能解决的问题。通过这种方式，用户可以继续完成任务，设计人员可以获得有价值的文档提示和进一步开发的提示。
在最初的偏倚方法中，多元可用性演练结合了进行可用性检查的专家和参与用户对系统的评论。但是，我们将这些分开，这样参与用户就可以成为演练期间的焦点。出于同样的原因，我们让用户开始讨论，只有当所有的用户都对任务发表了评论之后，系统设计者才允许说出系统支持哪些解决方案。设计人员通常会根据用户的意见为系统提出一些新的想法，欢迎所有的参与者对这些想法进行评论并生成新的想法。（Riihiaho，2002年、2015年）
此外，回溯分析（Akers、Jeffries、Simpson和Winograd，2012）同时收集了多个用户在同一位置执行预定义的任务。在任务执行期间，当用户启动撤消或擦除功能时，将触发日志记录。在参与者完成任务后，他们将配对对这些记录事件进行回顾性讨论。首先其中一个参与者询问分析工具提示的问题，另一个参与者同时对记录的事件进行评论。答案是音频记录的，并集成到记录的数据中进行进一步分析。在第一个参与者处理完所有事件后，（与其配对的）参与者切换角色。这样，与传统的可用性测试相比，用于进一步分析的材料数量要少得多，因为只记录和解释了关键事件（Akers等人，2012年）。
可视演练是我们研究小组开发的一种用户测试方法，用于获取有关用户对被评估用户界面及其组件感知到的信息和解释（Niemenn&Koivune，1995）。该方法可用于补充可用性测试或作为单独的方法。在可视演练期间，不允许用户浏览用户界面，而是一次只关注一个视图。首先要求用户描述他们在屏幕上看到了什么和注意到什么。在此概述之后，要求用户描述他们注意到的元素、组和细节。下一步是要求用户解释他们认为（视图中出现的）术语和符号意味着什么，以及他们认为元素分别提供了什么样的功能。之后，可能还有一个任务，要求用户陈述自己的意图而不实际执行这些操作（Niemenn和Koivunen，1995年）。
我们在修改后的版本中也使用了可视演练方法，该方法除了评估系统的可用性外，还评估了系统的实用性。在修改后的版本中，我们要求测试用户在硬拷贝中用不同的颜色标记他们需要和使用最多的部件、相当重要的部件以及他们从不使用或发现无用的部件（Juurmaa、Pitk_nen、Riihiaho、Kantola和M_kel_，2013）。这种方法的参与者必须是（系统所涉及的）领域的专家，以便他们能够评估哪些信息是相关的。
为了呈现着色任务的结果，我们将一些用户界面元素组合成块，并用一种颜色（如果用户的颜色是趋同的）或条纹（如果颜色变化很大）来着色这些块。这些聚集的块图显示出最相关的部分为绿色，而红色则表示参与者从未使用过或很少使用过的块。这种着色方法简单，成本低廉，甚至适用于纸和笔的着色。我们还发现彩色方块图是向客户传达令人信服且易于理解的结果的宝贵工具（Juurmaa等人，2013年；Riihiaho，2015年）。
非正式演练是可用性测试、观察和访谈的混合体。它侧重于评估系统的直观性，因此不使用预先定义的或特定的测试任务。相反，测试主持人有一个功能列表，需要进一步开发反馈的功能被包含在列表中，用户则按照自己的节奏和顺序浏览这些功能。当用户浏览系统时，如果用户自己找到了访问的功能，主持人会将其标记为“X”；如果意外发现了该功能，则标记为“A”；如果用户不尝试该功能，则标记为“–”。在用户浏览系统之后，主持人会检查是否仍然没有访问某些需要反馈的功能。在这些情况下，可以使用场景、任务或问题来指导用户使用这些功能（Riihiaho，2009年、2015年）。
非正式演练既可用于单用户测试，也可用于多用户测试，可用于实验室和现场。它已经成为一种很好的方法，例如，评估游戏机和数字服务，其概念已经为测试用户所熟悉。
上下文演练是一种评估系统在实际使用上下文中的使用情况的方法。它包含 传统可用性测试和上下文查询的元素。上下文查询的四个主要原则（Beyer&Holtzblatt，1998，第37-38页），即语境、伙伴关系、解释和焦点，也同样适用于上下文演练。上下文必须是真实的；测试用户和评估者应该扮演主人和学徒的角色；评估者应该解释他看到的内容，并与测试用户一起验证这些解释；评估中应该有一个预先确定的重点。
上下文演练是评估专业系统（如呼叫中心服务）的一种便捷方法，它不能与使用上下文分离。此外，具有实际任务的实际使用环境为评估系统的可用性和实用性提供了极好的机会。
使用上下文演练评估的系统必须是测试用户已经在使用的系统，或者即将投入使用的系统。用户需要用自己的材料进行试验，因此系统必须处于功能原型或运行系统的级别。用户还需要有足够的经验来扮演主人的角色，展示如何完成工作（Riihiaho，2009年、2015年）。
经验片段（isomursu，Kuutti，与väinämö，2004），也利用了实际使用环境。它可以评估真实用户在现实生活中使用移动应用程序和设备，而无需评估人员随时观察测试用户。在这种方法中，路人被成对地邀请作为用户进入研究。一个参与者获得具有评估的应用程序的手机，另一个参与者获得具有视频拍摄能力的手机。后者在第一个参与者使用该应用程序时拍摄视频剪辑。返还设备时，参与者选择需要呈现的可用的拍摄片段，并简要描述他们对应用程序所做的工作以及应用程序的工作方式（Isomursu等，2004）。
这些可用性测试方法的实例表明，根据评估的目标，可以根据评估的目标以多种方式修改特定可用性实验中的传统测试设置。在不以统计显著性为目标，而是以用户的丰富反馈为目标的形成性测试中，可以在测试之间甚至在测试会话期间修改方法、设置和原型，以最大化用户对新想法和重新设计提案的评论。
每种方法都有其优点和要求，因此建议在每个评估过程中结合一组方法。表14.3简要总结了本章介绍的方法，介绍了该方法允许用户评估系统的级别（操作，效用或值）、所研究的时间间隔、拟使用该方法的环境、测试任务的来源、一次测试中预期测试用户的数量。以及所需原型的级别（纸张原型，功能原型或工作系统）。
总结表明，所有的方法只关注一个简短的测试会话或一个简短的探索。因此，如果需要进行纵向研究，必须重复评估，或者在测试之前必须给用户一个试用系统的机会。
大多数方法还需要一些用户可以实际尝试的东西，例如，功能原型，甚至是工作系统。只有多元化可用性演练和视觉演练是专为纸张原型设计的。多元化可用性演练为小组讨论提供了空间，因此在系统开发的早期阶段评估新想法是一种很好的方法。
此外，总结表明，除了系统的可用性之外，很少有方法支持对其他问题的评估。然而，在实践中，大多数方法都可以修改以支持评估其他属性。如果允许测试用户自己探索系统，可以选择自己的任务，或者可以使用现实的和个人的数据，那么他们将更有能力评估系统的有用性，甚至可以评估系统在用户日常生活和社会环境中的价值。
