我在一所大学工作，我们的一位教员经常对我重复说：“软件需要像石头一样；它需要那么容易使用。” 她是对的。因为如果软件太难使用，就没有人愿意使用它。

我最近在 GNOME 用户和开发者欧洲会议 (GUADEC) 上发表演讲，我在演讲的开头提醒大家，GNOME 正在与 Mac、iPad、Windows 和 Chromebook 等其他对大多数人来说相当容易使用的系统争夺市场份额。因此，为了 GNOME 继续取得成功，它需要对所有人（包括专家和新手）都易于使用。而这就是可用性的用武之地。

那么，什么是可用性？可用性是关于用户的。用户通常是忙碌的人，他们试图完成工作。他们使用程序是为了提高效率，因此用户决定一个程序是否易于使用。一般来说，如果一个程序对于新用户来说易于学习、易于使用，并且在再次使用该程序时易于记住，那么它就具有良好的可用性。

更实际地看，具有典型知识的普通用户应该能够使用该软件来执行实际任务。因此，可用性测试的目的是揭示阻止普通用户成功使用该软件的问题。因此，可用性测试不同于质量保证测试或单元测试，后者的目的是揭示程序中的错误。可用性测试不是对程序功能的评估，而是对程序可操作性的实际判断。

可用性测试不依赖于单一方法。有多种方法可以实施可用性实践，从访谈和焦点小组到正式的可用性测试。无论您使用哪种方法，可用性测试的价值在于在开发期间进行评估，而不是在程序进入功能测试之后，因为那时用户界面更改变得更难实施。在开源软件开发中，开发者社区必须在整个开发过程中迭代地应用可用性测试。开发者不需要广泛的可用性经验即可在开源软件中应用这些可用性实践。

我更喜欢正式的可用性测试，而且这并不难。您只需召集一些测试人员并观察他们使用该软件，就可以获得重要的见解。通过每次迭代，可用性测试都会识别出许多需要解决的问题，并揭示更多的问题，这些问题在解决后将进一步提高程序的易用性。可用性不能仅在软件开发生命周期结束时解决。如果您等到最后，通常为时已晚，无法进行更改。

我最近与 GNOME 设计团队合作，检查了 GNOME 的可用性。这是一个在 GNOME 中进行可用性测试的绝佳时机。该项目正在更新 GNOME 设计模式：齿轮菜单、应用程序菜单、选择模式和搜索，仅举几例。我组织了一次可用性测试，以了解用户对 GNOME 中新设计模式的理解和导航程度。以下是我如何做的。

规划可用性测试的第一步是了解用户。他们是谁，他们通常想要执行哪些任务？对于 GNOME 来说，答案很简单。GNOME 网站解释说：“GNOME 3 是一种简单而优雅的计算机使用方式。它旨在让您掌控一切，并为每个人带来自由。” GNOME 适用于所有人，所有年龄段，适用于休闲用户和软件开发者。

从那里，我与 GNOME 设计团队合作，为这些用户构建了一个可用性测试。该测试还需要练习 GNOME 设计模式。我比较了每个 GNOME 程序使用的设计模式，并确定五个 GNOME 应用程序提供了设计模式的合理表示

1. gedit（文本编辑器）

2. Web（Web 浏览器）

3. Nautilus（文件管理器）

4. 软件（类似于应用商店）

5. Notes（一个简单的笔记程序）

在确定了程序之后，我编织了一组测试场景，这些场景围绕着真实的人们可能做的任务来练习设计模式。设计测试场景是任何可用性测试的重要组成部分。您需要非常小心措辞。仅仅通过使用特定的措辞，就很容易意外地“泄露”如何做某事。例如，我对 Web 的一个场景要求测试人员“请将网站上的文本调大”——而不是“增大字体大小”，后者会暗示他们需要使用菜单操作来完成任务。

因为我在大学校园工作，所以我邀请了学生、教职员工参加可用性研究。志愿者的选择不偏向性别、年龄组或经验水平。这反映了 GNOME 针对广泛用户的偏好。每位测试人员都获得了一张价值 5 美元的校园咖啡店礼品卡，作为对参与可用性测试的“感谢”。

总共有 12 名测试人员参加了可用性测试，代表了不同的性别和 18-74 岁的年龄范围。参与者在 1 到 5 的范围内自我评估了他们的计算机专业知识水平，其中 1 表示“没有知识”，5 表示“计算机专家”。没有测试人员自我评估为 1 或 5。相反，他们填写了“2：我知道一些东西，但不是很多”和“4：我比大多数人强”之间的范围，平均评分为 3.25，众数为“3：我非常普通。”

在每次可用性测试会话之前，每位参与者都收到了可用性研究的简要描述，解释说这是对软件的可用性测试，而不是对他们的测试。此介绍还鼓励测试人员交流他们的思考过程。例如，如果搜索打印操作，参与者应声明“我正在寻找‘打印’按钮。” 测试人员获得了一台运行 GNOME 3.12 “liveUSB” 镜像的笔记本电脑，其中包含一组示例文件，包括 gedit 场景任务中使用的文本文件。然而，USB 镜像被证明对于可用性测试中的大多数程序都不稳定。为了缓解稳定性问题，我将笔记本电脑重启到 Fedora 20 和 GNOME 3.10，以完成 Web、Nautilus、Software 和 Notes 的场景任务。在测试 GNOME 时，每位参与者都使用了单独的访客帐户，该帐户已预加载了相同的示例文件。这些示例文件还包括与可用性测试无关的项目，类似于真实用户如何在计算机上保存各种文档、照片和其他文件，允许参与者导航这些内容以查找场景任务所需的文件和文件夹。

在每次可用性测试结束时，我简短地采访了测试人员，以探究他们对任务和程序的反应，以便更好地了解他们在某些看起来特别容易或困难的任务期间的想法。总的来说，可用性测试包括 23 个场景任务，大多数测试人员在 50-55 分钟内完成。

可用性测试的价值在于找到程序难以使用的领域，以便开发者可以在下一个版本中改进界面。为此，您需要确定大多数用户难以执行的任务。

您可以通过使用热图轻松查看可用性测试结果。这种可视化方式简洁地总结了可用性测试的结果。在热图中，每个场景任务都用单独的一行表示，行中的每个方块代表测试人员对该任务的体验（图 1）。绿色方块表示测试人员几乎没有或没有困难完成的任务，黄色方块表示任务存在中等难度。红色方块表示测试人员遇到极大困难或测试人员错误完成任务的任务。黑色方块表示测试人员无法完成的任务，而白色方块表示测试中省略的任务，通常是由于时间不足。

图 1. 可用性热图

热图中的“热点”显示了测试人员难以完成的任务。

1) 有趣的是，所有参与者在更改 gedit（GNOME 3.12）中的默认字体时都遇到了重大问题。相当多的测试人员无法在 Notes 中完成类似的任务。在观察测试时，测试人员通常在齿轮菜单下寻找“字体”或“文本”操作。许多参与者将齿轮菜单称为“选项”或“设置”菜单，因为之前与齿轮图标以及 Mac OS X 和 Windows 应用程序中的“设置”相关联（图 2）。

图 2. gedit 的标题栏，显示齿轮菜单

这些参与者期望更改字体是程序中的一个选项，因此在齿轮或“选项”菜单下搜索“字体”操作。这种困惑部分源于将文本编辑器视为文字处理器，例如 Microsoft Word，它使用菜单或工具栏中的项目来设置文档字体。这种行为通常表现为在搜索“字体”操作之前首先突出显示文档中的所有文本。

2) 在 Nautilus 文件管理器中，测试人员在创建文件夹书签时也遇到了严重困难。在 GNOME 中，此任务通常通过单击进入目标文件夹，然后从齿轮菜单中选择“Bookmark this Location”（将此位置添加为书签），或通过单击并将目标文件夹拖到左侧窗格中的“书签”上来实现（图 3）。

图 3. 在 Nautilus 中拖动文件夹以创建书签

然而，测试人员最初通过尝试将文件夹拖到 GNOME 桌面来解决此任务。当被问及此反应时，几乎所有参与者都表示，他们更喜欢将经常访问的文件夹保存在桌面上以便于访问。大多数测试人员最终将目标文件夹移动到其主目录中的“桌面”文件夹中，并认为他们已成功完成任务，即使目标文件夹未出现在桌面上。

3) 测试人员在尝试在 gedit 中“查找和替换文本”时也遇到了困难。在此任务中，测试人员使用 gedit 中的“查找”功能来搜索文档中的文本。在试验“查找”时，测试人员表示他们希望在搜索文本的同时进行替换。在几次失败的尝试之后，测试人员通常能够成功地在齿轮菜单下调用“查找和替换”操作。

尽管整体 GNOME 桌面不属于可用性测试的一部分，但许多测试人员在使用 GNOME “活动”热角时遇到了困难。在 GNOME 桌面环境中，“活动”菜单显示当前正在运行的程序以及可用程序的选择。用户可以通过单击屏幕左上角的“活动”文字按钮或将鼠标移动到该角（“热角”）来触发“活动”菜单。尽管测试人员通常很快从意外的“热角”操作中恢复过来，但此功能在可用性测试期间引起了重大问题。

开源软件可用性挑战是文化性的。迄今为止，可用性一直与开源软件理念背道而驰，大多数项目都是从解决开发者感兴趣的问题开始的，并且新功能的加入是基于需求。创建新功能优先，而开源开发者很少考虑最终用户将如何访问这些功能。

然而，开源软件开发的一个关键优势是开发者与用户的关系。在开源软件项目中，用户社区在新版本的测试中发挥着重要作用。不幸的是，测试人员不能依赖典型的用户测试周期来提供足够的用户界面反馈。开发者只需观察一些用户与程序的交互，并记下测试人员遇到问题的地方，就可以学到很多东西。这就是可用性测试的本质。

可用性测试不需要在正式的实验室环境中进行，开发者也不需要成为专家才能将可用性测试方法应用于他们的项目。开发者只需要观察用户与程序的交互，可用性问题就会变得清晰。少量针对原型进行操作的可用性测试人员提供了足够的反馈，可以进行明智的可用性改进。有了良好的可用性，每个人都是赢家。