莫
莫知
Unregistered / Unconfirmed
GUEST, unregistred user!
可用性测试为您带来的好处
简言之，如果将可用性测试从产品开发周期的一开始一直贯彻到项目的每一阶段中，将使您
在最后的处理过程中省去重新开发这一环节。
本文首先讨论重复、周期性的设计过程。第一部分阐述了以用户为中心进行设计时的四个原
则，这是由 Gould、Boies 和 Lewis 提出的。接下来介绍了两种类型的产品设计过程：
“瀑布式”方法和“螺旋式”方法。本文的其余部分将简要介绍产品开发的各个阶段，并讨
论可用性活动是如何渗透各个阶段并带来益处的。此处所述的开发阶段包括：构思、规划、
开发、稳定化以及为下一版本做准备。
在您阅读各小节时，请注意用户将频繁地参与到各个过程中。用户对每个阶段的介入将会在
项目的收尾阶段为您省去成本高昂的返工工作，而且这样开发出来的产品将使用户乐于使用
、易于学习，并会长期使用。
使用反复、周期性的设计过程
反复、周期性的设计过程为以用户为中心进行的设计带来了极大的便利。以用户为中心的设
计有四个重要原则，这些原则是由 Gould、Boies 和 Lewis 于 1991 年提出的：
及早以用户为中心：设计人员应当在设计过程的早期就致力于了解用户的需要。
综合设计：设计的所有方面应当齐头并进发展，而不是顺次发展。使产品的内部设计与用户
界面的需要始终保持一致。
及早并持续性地进行测试：当前对软件测试的唯一可行的方法是根据经验总结出的方法，即
若实际用户认为设计是可行的，它就是可行的。通过在开发的全过程引入可用性测试，可以
使用户有机会在产品推出之前就设计提供反馈意见。
反复式设计：大问题往往会掩盖小问题的存在。设计人员和开发人员应当在整个测试过程中
反复对设计进行修改。
多年来，“瀑布式”的产品设计过程是软件设计的标准。在这一方法中，项目开发通过分阶
段发展的、按顺序的各个阶段进行。这种方法使用重大事件作为转变点和评估点，并认为在
下一阶段开始前，前面的每一阶段均已结束。“瀑布式”的方法对于复杂的项目很有效。在
复杂的项目中，多个供应商负责项目的各个方面（例如，一个供应商负责需求分析，另一个
负责规范，等等）。但是，使用这种方法可能导致随着项目的进展，对项目进行更改越来越
难。
相形之下，“螺旋式”的产品设计过程却是反复、周期性的 (Software Engineering
Economics, Barry W. Boehm, 1981)。这一过程允许更大地发挥创造性，并且更易于随着项
目的进展而对项目进行修改。在进行螺旋式的设计过程时，您会发现可在各个阶段对产品各
方面的功能进行设计。这种方法可为以用户为中心的产品开发过程带来便利。
螺旋式的产品设计过程有六个阶段：构思、规划、建模、开发、稳定化以及为下一版本做准备。
构思阶段
产品开发的构思阶段是确定项目的目标和范围的阶段。此阶段要确立构思陈述、设计目标、
风险评估以及项目构架。
在构思阶段，通常进行下列可用性活动：
环境研究
基于 Beyer 和 Hotzblatt 于 1997 年出版的 Contextual Design 一书中所述的方法，此
类型的研究包括观察用户的所做所为，使您更为直观地了解用户行为。如果您尚未决定究竟
要开发何种软件，但认为存在市场机会，就可使用环境研究来对活动进行研究。您可了解可
为用户做些什么以及实现的难易程度。不是寻求具体的功能，而是寻求设计机会。
环境研究为项目提供工作的重心。如果项目是全新的项目，或是较全面的升级，这种方法最
为适用。在进行较全面的升级或开展全新项目时，您无法全面了解用户在做什么、如何做、
以及他们所面临的问题或困扰。而进行较小的升级时，您有可能从产品支持部门、先前的研
究等处获得这些信息。在这种情况下，您基本上是对现有的设计加以完善，所以环境研究并
不是不可或缺的。
环境研究在以下情况最为适合：项目组进行跨学科的环境研究，小组由可用性工程师带领。
竞争性测试
通过竞争性可用性测试，您可以为产品设置量化的可用性目标 — 任务完成的速度、每项任
务出错的数目，等等。这种方法可对项目的成功与否进行量化的度量，即使所进行的竞争只
是人工过程，而您将对此过程进行自动化。竞争性测试经常用于市场开发。当市场开发代表
对竞争对手进行评估时，他们只比较产品的功能。可用性测试则更侧重于使用这些功能完成
任务时的性能。
竞争性测试对仅用于公司内部的产品来说，似乎不大适用。但是，如果仔细考虑，从理论上
而言，您也是在与产品的先前版本或前一个流程竞争。内部产品可能与人工过程进行竞争
— 产品必须比现有的进程更有效、更好。
进行竞争性测试的方法之一是开展研究，比较与其相竞争的产品的性能。例如，对其他人员
的产品进行性能研究。在选择要测试的竞争产品时，要考虑到计算机之外的产品：如果产品
涉及在线交易，则竞争性产品就可以是电子货币。从研究结果中您可以确定使用最频繁的、
最重要的功能。
用户/受众分析
了解您的用户！尽可能采取各种方法来了解您的用户的特点。考虑一下如果您基于产品最终
用户的特点来开发软件，可减少多少技术支持电话的数量。设想一下用户是否认为产品易于
使用并且包含了他们所需的功能。问自己“对于我要创建的产品，哪些用户特点是与之相关
的？”，例如：
计算机使用经验
年龄
接受培训的程度
用户群之间的社会关系
特殊要求（可访问性）
您可以通过环境研究来获得一些此类信息。例如，您可对一些用户进行观察以得出一些假设
，然后通过调研或取样来验证这些假设。您的人力资源部门或培训部门可能会具有一些相关
的信息；例如每个新雇员要接受多少培训。市场研究人员也可能有此类信息。对于公司内部
使用的应用程序而言，收集这些信息有时会比对外出售的应用程序简便，因为您的用户是具
体的群体而不是普通大众。
规划阶段
规划阶段是进行首次实际设计的阶段。在此阶段中，有关用户界面的早期设想将初步成形，
并着重于先前阶段未涉及的知识。原始模型可以是任何形式，如描述概念或功能的卡片、
屏幕的简单描绘图纸、打印在纸上的屏幕位图图形，用 Macromedia Director 之类的程序
创建的带有有限交互功能（也称为“点阅”）的联机版本，或是用 HTML 或 Microsoft
Visual Basic? 创建的带有大量交互功能的联机版本。在大多数情况下，您会发现原型具有
的仿真度越高，用户建议进行重大修改的可能性就越低。所以，用写在纸上的原型来开始着
手测试是非常值得采取的做法。
根据您所设计的产品种类，您可能需要进行下述的一些或所有活动。如果您在规划阶段花时
间来完成这些任务并使用原型，则在开发阶段碰到的可用性问题将会大为减少。
用户情况
创建您自己的用户情况概要，列出产品的典型用户能做什么，不能做什么。通过早期的环境
研究和用户/受众分析，您做出一些较高级别的决策，基于这些决策进行软件设计。使用用户
情节，您可创建一个有关用户使用您所设计的软件的“故事”。这些情况可以是情节串联图
板、联机 Macromedia Director 电影、简单的流程图、或简单的叙述性文本。一种比较精致
的用户情节模式是“日常生活”录像。这种录像把演员作为“用户”显示，这些用户在日常
活动中与模拟的系统进行交互。通过用户情节可得出您在任务分析时要寻找的具体细节。
任务分析
任务分析决定了在新产品中执行任务的方式。在撰写规范之前，必须首先进行任务分析。用
任务分析来确定您所规划的支持的任务是否确实能够反映现实，这一点是很重要的。对任务
的逼真度进行分析。就产品的特性而言，任务的完整性如何？分析逼真度意味着观察用户完
成一项任务所必须执行的所有操作；或进行表象的观察，了解用户完成所有任务或功能所需
执行的所有操作。无需担心过于详尽 — 把重点放在实质内容上。
一些要考虑的问题和活动：
此环境中的任务是什么？环境研究应能帮助您找出并描述用户所执行的任务。
创建顺序图，描述用户执行的任务之间、用户和产品之间的相互作用。
在构思阶段确定功能的作用领域。提出问题：“我们要支持的具体任务是什么？”
与产品设计者一起创建情节串联图板或顺序简图。
启发式评估
启发式评估涉及评估人员小组，这些评估人员查看界面并基于基本可用性原则来对其做出判
断。启发式评估允许您在整个反复式设计过程中查找并更正可用性问题。如果您在工作进展
的同时纠正问题，您将在收尾阶段节省大量工作。因为在收尾阶段，更改真实代码将更加困
难而且成本更高。
如 Jakob Nielse
n 在 Usability Engineering (1994) 中所述，启发式评估包括以下步骤：
每个评估人员都浏览数遍界面，检查各种对话框元素，然后将其与一些已知的可用性原则相比
较。
评估人员相互合作，将结果合并到列表中，列出用户界面中的可用性问题，并注明设计方案
中违反的相关可用性原则。
一旦每个评估人员都分别执行了启发式评估后，他们就集中起来将其评估结果合并在一起。
在开发的早期阶段，启发式评估可能是发现可用性问题的非常有效的方法。
认知性遍历
认知性遍历的意思是，仔细检查界面要求用户执行多少步骤以及何种步骤后，才能完成某项
任务，其中包含用户必须经过思考才能完成的那些步骤。您需要关注的是用户必须调用什么
或用户必须进行的计算 — 认知性任务决定学习和使用您的产品的难易程度。认知性遍历可
帮助您找出潜在的可用性问题，以及找出您制订的规范中的破绽！
根据 Gregory Abowd 的 Performing a Cognitive Walkthrough，要进行认知性遍历活动，
需要以下四个条件：
对系统原型的详尽描述，例如初级规范可提供什么样的系统。这种描述不一定是完整的，但
要相当详尽。诸如菜单的位置或措辞这样的细节也可能导致相当大的差异。
对用户在系统中要完成的任务的描述。该任务应当是大多数用户将要执行的有代表性的任务。
一个完整的、书面的操作清单，列出使用给定原型完成任务所需执行的操作。
指出用户的身份，以及评估人员能够假定这些用户已具有哪一类别的知识和经验。
有了这些信息，评估人员可执行一遍上文第三项所列的操作，从而确定用户是否能够按预期
要求合理执行这些步骤。
GOMS
GOMS 是描述任务和用户执行该任务所需知识的方法，它是通过目标 (Goal)、操作符
(Operator)、方法 (Method) 以及选择规则 (Selection rule) 四个方面进行描述的。
Card、Moran 和 Newell 提出了原始的 GOMS 模式。他们还创建了一个简化的版本，即击键
级别模型 (KLM)。Bonnie E. John 开发了并行活动版本 CPM-GOMS，而 David Kieras 则开
发出定义更为严谨的版本：自然 GOMS 语言 (NGOMSL)。所有这些技术都基于同一 GOMS 概念。
不言自明，目标就是指用户的目标。用户使用软件要达到什么目的？在下一天、下几分钟、
下几秒钟？
操作符是指软件允许用户采取的操作。
方法是子目标和操作符经仔细设计后得出的序列，可用来实现诸如剪切和粘贴等目标。
选择规则是用户要遵守的判定规则，以确定在特定环境下要使用的方法。
GOMS 模型由对方法的描述组成，这些方法是达到目标所必需的。方法是一些步骤，这些步
骤包括用户为达到目标所需执行的操作符。如果有一种以上的方法可以达到目标，则需使用
选择规则来确定在此情况下哪种方法更为适用。
卡片排序
卡片排序是一种可用性技术，用于此阶段的早期，以了解用户关于信息的总体模型。卡片排
序的基本任务是要让参与者按卡片上的说明对卡片进行组织，将属于同一类的项目堆放在一
起。在创建好堆后，参与者还可为所创建的堆建立名称、标签或说明。
卡片排序用于：
展示用户对于任务范围的总体模型。
展示用户如何对项目进行分组或分类的。
展示用户对项目之间的关系和相似性的看法。
将用户的概念模型转换为设计。
反复可用性测试
对原型设计的反复可用性测试是另一种很有价值的方法，用于在产品周期的早期阶段确定界
面是否易于用户使用。在此阶段进行更改比等到开发阶段开始后再进行更改要更容易些，并
且成本更低。
您从可用性实验室可以收集的数据量取决于原型的强健性。对于纸上原型测试，可用性工程
师就是计算机，并且在测试的过程中与用户在一起。
在许多种情况下，严谨的可用性测试是过犹不及的。在建模阶段，您仍可使用简化的方法进
行有效的可用性测试，这些方法通常称为“打折扣的”可用性测试。
如 Jakob Nielse
n 所述，反复的可用性测试包括：
用户和任务观察 — 观察用户，保持安静，让用户做一切通常情况下会做的操作。
情况 — 使用一种可以减少功能数量、降低功能级别的建模方法。
简化的对谈式测试 — 一次安排一个用户完成一组任务，并要求用户“发现问题就直接告知
测试人员”。
启发式评估 — 基于基本可用性原则来评价界面。
开发阶段
开发阶段是将产品用实际的代码来实现的阶段。在此阶段中，您可以对实际产品的早期版次
进行可用性测试。您仍有可能不时要用到原型，但随着时间的推移产品将逐渐完善。不是所
有的功能都将在开发阶段同时完成，所以您有可能在原型和实际代码之间往复转换。
在理想条件下，您将可以把大部分时间用来进行推敲，在建模阶段就能够找出主要问题。
真实代码测试
让用户测试真实代码版本可能会有助于针对在计算机上使用产品发现问题。这些问题更有可
能是设计问题而非概念问题。它们通常涉及相当低级的交互作用问题，如在屏幕上选择项目
、拖放，以及仅在实际产品中才有的动态图形。对于产品的大多方面，真实代码不一定比设
计上的原型或其它模型的真实度更高，所以不要拖延到有真实代码后再进行可用性测试。
可用性实验室测试
在开发阶段，您可进行可用性实验室测试，该测试类似于规划阶段的反复可用性测试。但是
，由于产品的更多部分已趋于完善，您可测试更多任务。您仍可在 Director 中使用模型，
或将稍做修改的版次用在可用性测试中。随着时间的推移，产品会越来越完善，原型就越来
越不象一个模型了。但是，用“已完成”产品进行测试的问题在于，由于已进行了如此之多
的工作，剩下的时间如此之少，您就不能指望对发现的问题做太多的修改了。
注意： 作为此任务的一部分，您还可能进行焦点组分析或群集分析，以对产品进行可用
性测试。
稳定化阶段
当开发结束、错误已修正后，就进入了稳定化阶段。在此阶段中，要创建一个可发售的稳定
的产品。在此阶段对可用性进行测试的重点是进行微调。新的功能以及代价高昂的可用性增
强功能应被记录下来，以备下一版本使用。
基准测试
对可用性进行基准测试类似于“质量保证”中的综合测试。基准测试的目的是通过测试用户
想要完成的所有顶级任务，就产品的可用性提供可靠的量化数据。这些测试的目标与其说是
要找出问题（虽然找出问题是大多数可用性测试的目的），不如说是要评估产品可用性的状
态。
要进行基准测试，请首先观察产品的功能，然后将这些功能按任务细分。在稳定化阶段，特
别是对于复杂的产品，您将不能对用户界面进行可提高每个任务性能的修改。理想情况下，
您可以确定哪些是顶级任务，并且确保大多数顶级任务都是可用的。低优先级的任务的可用
性可以较低，可记录下来在将来的版本中再作改进。
为下一版本做准备
将此阶段视为开始对过程进行回顾的阶段。您将全面考虑在构思阶段和规划阶段所进行的许
多相同任务。例如，您将进行：
竞争性测试 — 在稳定化阶段，这种测试是对自己的产品进行测试，以将其与先前收集的有
关竞争产品的数据作比较。
现场研究 — 类似于环境研究（该研究是要了解“我们要做什么软件？”），使用您已构建
的软件来找出存在哪些问题，可在下一版本加以解决。
关于事件的工具化版本研究 — 软件的工具化版本基本上用来观测软件自身并在发生事件时
记录数据。您在大量会话和用户的基础上对产品进行测量以找到使用趋势。
简言之，如果将可用性测试从产品开发周期的一开始一直贯彻到项目的每一阶段中，将使您
在最后的处理过程中省去重新开发这一环节。
本文首先讨论重复、周期性的设计过程。第一部分阐述了以用户为中心进行设计时的四个原
则，这是由 Gould、Boies 和 Lewis 提出的。接下来介绍了两种类型的产品设计过程：
“瀑布式”方法和“螺旋式”方法。本文的其余部分将简要介绍产品开发的各个阶段，并讨
论可用性活动是如何渗透各个阶段并带来益处的。此处所述的开发阶段包括：构思、规划、
开发、稳定化以及为下一版本做准备。
在您阅读各小节时，请注意用户将频繁地参与到各个过程中。用户对每个阶段的介入将会在
项目的收尾阶段为您省去成本高昂的返工工作，而且这样开发出来的产品将使用户乐于使用
、易于学习，并会长期使用。
使用反复、周期性的设计过程
反复、周期性的设计过程为以用户为中心进行的设计带来了极大的便利。以用户为中心的设
计有四个重要原则，这些原则是由 Gould、Boies 和 Lewis 于 1991 年提出的：
及早以用户为中心：设计人员应当在设计过程的早期就致力于了解用户的需要。
综合设计：设计的所有方面应当齐头并进发展，而不是顺次发展。使产品的内部设计与用户
界面的需要始终保持一致。
及早并持续性地进行测试：当前对软件测试的唯一可行的方法是根据经验总结出的方法，即
若实际用户认为设计是可行的，它就是可行的。通过在开发的全过程引入可用性测试，可以
使用户有机会在产品推出之前就设计提供反馈意见。
反复式设计：大问题往往会掩盖小问题的存在。设计人员和开发人员应当在整个测试过程中
反复对设计进行修改。
多年来，“瀑布式”的产品设计过程是软件设计的标准。在这一方法中，项目开发通过分阶
段发展的、按顺序的各个阶段进行。这种方法使用重大事件作为转变点和评估点，并认为在
下一阶段开始前，前面的每一阶段均已结束。“瀑布式”的方法对于复杂的项目很有效。在
复杂的项目中，多个供应商负责项目的各个方面（例如，一个供应商负责需求分析，另一个
负责规范，等等）。但是，使用这种方法可能导致随着项目的进展，对项目进行更改越来越
难。
相形之下，“螺旋式”的产品设计过程却是反复、周期性的 (Software Engineering
Economics, Barry W. Boehm, 1981)。这一过程允许更大地发挥创造性，并且更易于随着项
目的进展而对项目进行修改。在进行螺旋式的设计过程时，您会发现可在各个阶段对产品各
方面的功能进行设计。这种方法可为以用户为中心的产品开发过程带来便利。
螺旋式的产品设计过程有六个阶段：构思、规划、建模、开发、稳定化以及为下一版本做准备。
构思阶段
产品开发的构思阶段是确定项目的目标和范围的阶段。此阶段要确立构思陈述、设计目标、
风险评估以及项目构架。
在构思阶段，通常进行下列可用性活动：
环境研究
基于 Beyer 和 Hotzblatt 于 1997 年出版的 Contextual Design 一书中所述的方法，此
类型的研究包括观察用户的所做所为，使您更为直观地了解用户行为。如果您尚未决定究竟
要开发何种软件，但认为存在市场机会，就可使用环境研究来对活动进行研究。您可了解可
为用户做些什么以及实现的难易程度。不是寻求具体的功能，而是寻求设计机会。
环境研究为项目提供工作的重心。如果项目是全新的项目，或是较全面的升级，这种方法最
为适用。在进行较全面的升级或开展全新项目时，您无法全面了解用户在做什么、如何做、
以及他们所面临的问题或困扰。而进行较小的升级时，您有可能从产品支持部门、先前的研
究等处获得这些信息。在这种情况下，您基本上是对现有的设计加以完善，所以环境研究并
不是不可或缺的。
环境研究在以下情况最为适合：项目组进行跨学科的环境研究，小组由可用性工程师带领。
竞争性测试
通过竞争性可用性测试，您可以为产品设置量化的可用性目标 — 任务完成的速度、每项任
务出错的数目，等等。这种方法可对项目的成功与否进行量化的度量，即使所进行的竞争只
是人工过程，而您将对此过程进行自动化。竞争性测试经常用于市场开发。当市场开发代表
对竞争对手进行评估时，他们只比较产品的功能。可用性测试则更侧重于使用这些功能完成
任务时的性能。
竞争性测试对仅用于公司内部的产品来说，似乎不大适用。但是，如果仔细考虑，从理论上
而言，您也是在与产品的先前版本或前一个流程竞争。内部产品可能与人工过程进行竞争
— 产品必须比现有的进程更有效、更好。
进行竞争性测试的方法之一是开展研究，比较与其相竞争的产品的性能。例如，对其他人员
的产品进行性能研究。在选择要测试的竞争产品时，要考虑到计算机之外的产品：如果产品
涉及在线交易，则竞争性产品就可以是电子货币。从研究结果中您可以确定使用最频繁的、
最重要的功能。
用户/受众分析
了解您的用户！尽可能采取各种方法来了解您的用户的特点。考虑一下如果您基于产品最终
用户的特点来开发软件，可减少多少技术支持电话的数量。设想一下用户是否认为产品易于
使用并且包含了他们所需的功能。问自己“对于我要创建的产品，哪些用户特点是与之相关
的？”，例如：
计算机使用经验
年龄
接受培训的程度
用户群之间的社会关系
特殊要求（可访问性）
您可以通过环境研究来获得一些此类信息。例如，您可对一些用户进行观察以得出一些假设
，然后通过调研或取样来验证这些假设。您的人力资源部门或培训部门可能会具有一些相关
的信息；例如每个新雇员要接受多少培训。市场研究人员也可能有此类信息。对于公司内部
使用的应用程序而言，收集这些信息有时会比对外出售的应用程序简便，因为您的用户是具
体的群体而不是普通大众。
规划阶段
规划阶段是进行首次实际设计的阶段。在此阶段中，有关用户界面的早期设想将初步成形，
并着重于先前阶段未涉及的知识。原始模型可以是任何形式，如描述概念或功能的卡片、
屏幕的简单描绘图纸、打印在纸上的屏幕位图图形，用 Macromedia Director 之类的程序
创建的带有有限交互功能（也称为“点阅”）的联机版本，或是用 HTML 或 Microsoft
Visual Basic? 创建的带有大量交互功能的联机版本。在大多数情况下，您会发现原型具有
的仿真度越高，用户建议进行重大修改的可能性就越低。所以，用写在纸上的原型来开始着
手测试是非常值得采取的做法。
根据您所设计的产品种类，您可能需要进行下述的一些或所有活动。如果您在规划阶段花时
间来完成这些任务并使用原型，则在开发阶段碰到的可用性问题将会大为减少。
用户情况
创建您自己的用户情况概要，列出产品的典型用户能做什么，不能做什么。通过早期的环境
研究和用户/受众分析，您做出一些较高级别的决策，基于这些决策进行软件设计。使用用户
情节，您可创建一个有关用户使用您所设计的软件的“故事”。这些情况可以是情节串联图
板、联机 Macromedia Director 电影、简单的流程图、或简单的叙述性文本。一种比较精致
的用户情节模式是“日常生活”录像。这种录像把演员作为“用户”显示，这些用户在日常
活动中与模拟的系统进行交互。通过用户情节可得出您在任务分析时要寻找的具体细节。
任务分析
任务分析决定了在新产品中执行任务的方式。在撰写规范之前，必须首先进行任务分析。用
任务分析来确定您所规划的支持的任务是否确实能够反映现实，这一点是很重要的。对任务
的逼真度进行分析。就产品的特性而言，任务的完整性如何？分析逼真度意味着观察用户完
成一项任务所必须执行的所有操作；或进行表象的观察，了解用户完成所有任务或功能所需
执行的所有操作。无需担心过于详尽 — 把重点放在实质内容上。
一些要考虑的问题和活动：
此环境中的任务是什么？环境研究应能帮助您找出并描述用户所执行的任务。
创建顺序图，描述用户执行的任务之间、用户和产品之间的相互作用。
在构思阶段确定功能的作用领域。提出问题：“我们要支持的具体任务是什么？”
与产品设计者一起创建情节串联图板或顺序简图。
启发式评估
启发式评估涉及评估人员小组，这些评估人员查看界面并基于基本可用性原则来对其做出判
断。启发式评估允许您在整个反复式设计过程中查找并更正可用性问题。如果您在工作进展
的同时纠正问题，您将在收尾阶段节省大量工作。因为在收尾阶段，更改真实代码将更加困
难而且成本更高。
如 Jakob Nielse
n 在 Usability Engineering (1994) 中所述，启发式评估包括以下步骤：
每个评估人员都浏览数遍界面，检查各种对话框元素，然后将其与一些已知的可用性原则相比
较。
评估人员相互合作，将结果合并到列表中，列出用户界面中的可用性问题，并注明设计方案
中违反的相关可用性原则。
一旦每个评估人员都分别执行了启发式评估后，他们就集中起来将其评估结果合并在一起。
在开发的早期阶段，启发式评估可能是发现可用性问题的非常有效的方法。
认知性遍历
认知性遍历的意思是，仔细检查界面要求用户执行多少步骤以及何种步骤后，才能完成某项
任务，其中包含用户必须经过思考才能完成的那些步骤。您需要关注的是用户必须调用什么
或用户必须进行的计算 — 认知性任务决定学习和使用您的产品的难易程度。认知性遍历可
帮助您找出潜在的可用性问题，以及找出您制订的规范中的破绽！
根据 Gregory Abowd 的 Performing a Cognitive Walkthrough，要进行认知性遍历活动，
需要以下四个条件：
对系统原型的详尽描述，例如初级规范可提供什么样的系统。这种描述不一定是完整的，但
要相当详尽。诸如菜单的位置或措辞这样的细节也可能导致相当大的差异。
对用户在系统中要完成的任务的描述。该任务应当是大多数用户将要执行的有代表性的任务。
一个完整的、书面的操作清单，列出使用给定原型完成任务所需执行的操作。
指出用户的身份，以及评估人员能够假定这些用户已具有哪一类别的知识和经验。
有了这些信息，评估人员可执行一遍上文第三项所列的操作，从而确定用户是否能够按预期
要求合理执行这些步骤。
GOMS
GOMS 是描述任务和用户执行该任务所需知识的方法，它是通过目标 (Goal)、操作符
(Operator)、方法 (Method) 以及选择规则 (Selection rule) 四个方面进行描述的。
Card、Moran 和 Newell 提出了原始的 GOMS 模式。他们还创建了一个简化的版本，即击键
级别模型 (KLM)。Bonnie E. John 开发了并行活动版本 CPM-GOMS，而 David Kieras 则开
发出定义更为严谨的版本：自然 GOMS 语言 (NGOMSL)。所有这些技术都基于同一 GOMS 概念。
不言自明，目标就是指用户的目标。用户使用软件要达到什么目的？在下一天、下几分钟、
下几秒钟？
操作符是指软件允许用户采取的操作。
方法是子目标和操作符经仔细设计后得出的序列，可用来实现诸如剪切和粘贴等目标。
选择规则是用户要遵守的判定规则，以确定在特定环境下要使用的方法。
GOMS 模型由对方法的描述组成，这些方法是达到目标所必需的。方法是一些步骤，这些步
骤包括用户为达到目标所需执行的操作符。如果有一种以上的方法可以达到目标，则需使用
选择规则来确定在此情况下哪种方法更为适用。
卡片排序
卡片排序是一种可用性技术，用于此阶段的早期，以了解用户关于信息的总体模型。卡片排
序的基本任务是要让参与者按卡片上的说明对卡片进行组织，将属于同一类的项目堆放在一
起。在创建好堆后，参与者还可为所创建的堆建立名称、标签或说明。
卡片排序用于：
展示用户对于任务范围的总体模型。
展示用户如何对项目进行分组或分类的。
展示用户对项目之间的关系和相似性的看法。
将用户的概念模型转换为设计。
反复可用性测试
对原型设计的反复可用性测试是另一种很有价值的方法，用于在产品周期的早期阶段确定界
面是否易于用户使用。在此阶段进行更改比等到开发阶段开始后再进行更改要更容易些，并
且成本更低。
您从可用性实验室可以收集的数据量取决于原型的强健性。对于纸上原型测试，可用性工程
师就是计算机，并且在测试的过程中与用户在一起。
在许多种情况下，严谨的可用性测试是过犹不及的。在建模阶段，您仍可使用简化的方法进
行有效的可用性测试，这些方法通常称为“打折扣的”可用性测试。
如 Jakob Nielse
n 所述，反复的可用性测试包括：
用户和任务观察 — 观察用户，保持安静，让用户做一切通常情况下会做的操作。
情况 — 使用一种可以减少功能数量、降低功能级别的建模方法。
简化的对谈式测试 — 一次安排一个用户完成一组任务，并要求用户“发现问题就直接告知
测试人员”。
启发式评估 — 基于基本可用性原则来评价界面。
开发阶段
开发阶段是将产品用实际的代码来实现的阶段。在此阶段中，您可以对实际产品的早期版次
进行可用性测试。您仍有可能不时要用到原型，但随着时间的推移产品将逐渐完善。不是所
有的功能都将在开发阶段同时完成，所以您有可能在原型和实际代码之间往复转换。
在理想条件下，您将可以把大部分时间用来进行推敲，在建模阶段就能够找出主要问题。
真实代码测试
让用户测试真实代码版本可能会有助于针对在计算机上使用产品发现问题。这些问题更有可
能是设计问题而非概念问题。它们通常涉及相当低级的交互作用问题，如在屏幕上选择项目
、拖放，以及仅在实际产品中才有的动态图形。对于产品的大多方面，真实代码不一定比设
计上的原型或其它模型的真实度更高，所以不要拖延到有真实代码后再进行可用性测试。
可用性实验室测试
在开发阶段，您可进行可用性实验室测试，该测试类似于规划阶段的反复可用性测试。但是
，由于产品的更多部分已趋于完善，您可测试更多任务。您仍可在 Director 中使用模型，
或将稍做修改的版次用在可用性测试中。随着时间的推移，产品会越来越完善，原型就越来
越不象一个模型了。但是，用“已完成”产品进行测试的问题在于，由于已进行了如此之多
的工作，剩下的时间如此之少，您就不能指望对发现的问题做太多的修改了。
注意： 作为此任务的一部分，您还可能进行焦点组分析或群集分析，以对产品进行可用
性测试。
稳定化阶段
当开发结束、错误已修正后，就进入了稳定化阶段。在此阶段中，要创建一个可发售的稳定
的产品。在此阶段对可用性进行测试的重点是进行微调。新的功能以及代价高昂的可用性增
强功能应被记录下来，以备下一版本使用。
基准测试
对可用性进行基准测试类似于“质量保证”中的综合测试。基准测试的目的是通过测试用户
想要完成的所有顶级任务，就产品的可用性提供可靠的量化数据。这些测试的目标与其说是
要找出问题（虽然找出问题是大多数可用性测试的目的），不如说是要评估产品可用性的状
态。
要进行基准测试，请首先观察产品的功能，然后将这些功能按任务细分。在稳定化阶段，特
别是对于复杂的产品，您将不能对用户界面进行可提高每个任务性能的修改。理想情况下，
您可以确定哪些是顶级任务，并且确保大多数顶级任务都是可用的。低优先级的任务的可用
性可以较低，可记录下来在将来的版本中再作改进。
为下一版本做准备
将此阶段视为开始对过程进行回顾的阶段。您将全面考虑在构思阶段和规划阶段所进行的许
多相同任务。例如，您将进行：
竞争性测试 — 在稳定化阶段，这种测试是对自己的产品进行测试，以将其与先前收集的有
关竞争产品的数据作比较。
现场研究 — 类似于环境研究（该研究是要了解“我们要做什么软件？”），使用您已构建
的软件来找出存在哪些问题，可在下一版本加以解决。
关于事件的工具化版本研究 — 软件的工具化版本基本上用来观测软件自身并在发生事件时
记录数据。您在大量会话和用户的基础上对产品进行测量以找到使用趋势。
