关于测试：如何测试用户界面的可用性

您如何测试应用程序用户界面的可用性-是Web还是桌面？ 您是否将所有内容放在一起，然后在应用程序上线后根据用户体验对其进行调整？ 还是在发布之前将其传递给特定的可用性团队进行测试？

我们是一家小型软件公司，但是我对如何衡量可用性的最佳实践感兴趣。

任何帮助表示赞赏。

---

我喜欢Paul Buchheit在创业学校提供的答案。他说的简短内容听您的用户。聆听并不意味着服从您的用户。接受数据过滤掉所有不良建议，并反复清理站点。泡沫，冲洗，重复。

如果您是一家小商店，则可能没有QA小组或可用性小组或任何需要通过网站的人员。您的用户将成为实际使用该网站的用户。他们的反馈是无价的。

如果某些东西太难使您的一个用户无法使用，或者太复杂以至于无法理解为什么要使用它，那么对于其他1000个用户而言，可能是相同的方式。寻找完成同一件事的简单方法。

收集所有这些反馈并列出要执行的操作后，请首先执行最简单的操作。这样，您就可以在可用性方面取得进步。

---

我想做的就是给某人一个安装包，请他们执行一些与应用程序的工作方式有关的任务，然后进行监视。

最难的部分是保持嘴巴闭合。

---

Jakob Nielsen的网站http://www.useit.com上提供了一些有关可用性测试的最佳建议。他主张Will将要提到的内容-要求用户在您的网站或Web应用程序上执行各种任务，然后坐下来看看他们在做什么。

请勿通过提问或指导来打扰用户。只需观察它们并记录其流程即可。您还可以获取硬件和软件来进行眼动追踪，并了解吸引用户注意的内容。

但是，可用性不应从测试阶段开始。您必须对开发时用户通常喜欢什么和不喜欢什么有一些一般的了解。有许多网站和书籍概述了普遍接受的可用性标准和原则。

---

我同意亚当。使用非常计算机不识字的人非常有帮助。但是，我之前遇到的问题是我希望他们尝试的程序并没有像他们想做的那样"弄糟他们"。

一个好的开始方法是使用纸质原型。拥有您希望您的"用户"执行并执行的特定任务。有关纸张原型的更多信息，请从这里开始。

---

通常，我们通过要求一小部分用户试用Beta版本来测试新界面的可用性。

我们会为您提供一些有关新功能/屏幕应该做什么的说明，并让他们直接进行学习。看到他们正在寻找并单击的位置非常有趣。我们从不演示新功能-我们只谈论它的功能。

如果用户界面的更改很小，那么它们就会生效，我们会收集真实用户的反馈。只有在进行重大更改时，我们才能通过Beta版的可用性测试。

在开发新屏幕时，通常会让很多人陷入困境，让同事坐在UI前面并问他们做什么。他们点击哪些区域？他们首先在哪里看？哪些部分吸引了他们的注意力？等等

---

有许多方法可以测试或评估应用程序的可用性。分解为定性和定量方法，并基于计划进行测试的时间。

进一步根据是否涉及用户或专家进行测试将其分类。

列举一些方法，

专家评论-用户界面或可用性专家根据确定的启发式方法和原则对界面的可用性进行评估

形成性可用性测试-采取任务流程，并向用户提供要完成的任务。根据用户在测试过程中感到的痛点，收集定性反馈。这种测试形式是在设计期间完成的，以提供对应用程序设计的反馈。

汇总可用性测试-采取任务流程，并向用户提供要完成的任务。应用程序在效率，有效性和满意度上的性能是根据用户的任务完成情况来衡量的。

重要性差异是您是让用户还是专家来告诉您可用性上的差异。进一步进行评估的时间-在项目结束时或在设计阶段。

---

随着可用性检查的进行，有几种可行的方法。他们在人员，分析和装备方面需要不同数量的资源。

最常见，最容易执行的称为

启发式评估

您基本上会遍历每个屏幕以检查其是否符合您或您的客户设置的试探法。

查看尼尔森的这篇文章

认知演练

此方法要求您要求用户完成应用程序中的步骤。您为用户准备要完成的步骤。完成应用程序时，将考虑此演练过程中出现的问题。

有关详细信息，请查阅本文。

大声思考

我主要在原型设计的早期阶段就使用过这种方法。我在使用过程中让用户自由谈论系统。询问有关使用，设计等方面的问题。您可以很好地了解系统的总体感觉，以及缺少哪些功能。

有关详细信息，请查阅本文。

互动分析
这是一个比较棘手的问题。我只使用了此人提出的数据收集技巧。该技术考虑了上下文，活动，肢体语言等。交互分析通常集中在研究上，而不是商业评估中。

此链接将您带到该文章。

请记住，这些方法需要实践来完善。我将从HE入手，继续到CW和THA。如果您有很多资源和时间，请仅使用"交互分析"。

---

自从这个问题上一次活跃以来，Z'been已经有一段时间了，但是无论如何这里都是这样。

根据经验：

• 始终使用客观可衡量的方法来确定可用性是否更好(完成精心选择的任务的时间，不活动的时间，KLM类型指标)，这里的鼠标记录器可能是宝贵的盟友
• 在与您的客户再次协商和评估之前，切勿过分前进(不要迷恋纸质原型并随成品出现……这永远都行不通)
• 阅读，阅读，阅读，尝试，发展
• 保持简单，并始终记住完成任务(为什么用户需要界面)
• 再测试再测试...
• 始终转到用户请求的底部。尽管用户在此特定位置请求的复选框可能是最好的选择，但它几乎总是隐藏了更基本的缺陷
• 系统用户(使用它的用户...而不是为此付费的用户)是您最好的盟友，请让他/她站在您的身边

永远不要害怕重构设计并开发系统。同时也要发展指标和度量，但是要小心，以免破坏度量的连续性，因为这是在非常主观的世界中客观进步的最好标志。

推荐读物(以前建议的除外)：

• 可用性测试手册Jeff Rubin。有点极端，但是我们玩弄了他的方法的一个敏捷版本，发现如果我们每周与用户一起花费30分钟，我们将获得很多有用的反馈，而不会被太多的信息所淹没。

• 密切关注这个世界以及其他可能崛起的Sneiderman和Nielsen

---

有很多方法可以测试系统的可用性。请检查任何可用的文献资料。我只想坚持认为，可用性测试并不像您或任何人所想的那样难。 J. Nielsen和T. K. Landauer在INTERACT'93和CHI'93中的著名论文"发现可用性问题的数学模型"中指出，只有5个用户就可以在一个小型系统中找到大多数问题。

如果您无法阅读本文，请在作者的网站上尝试以下文章：
http://www.useit.com/alertbox/20000319.html

---

我经常将自己正在使用的任何新界面带给我们的技术支持人员之一。他们听到了关于您所能想象到的接口的所有抱怨，因此，如果有人要想出潜在的问题，他们会的。

另外，我并不是在开玩笑，我经常选我认识的计算机知识最少的人(您妈妈通常是个不错的选择……但他们必须先使用计算机，否则毫无意义。 )，并在没有说明的情况下让它们在界面上松动。如果他们无法直观地判断出什么地方，那么您的GUI可能需要工作。记住，不要让他们思考！ (是的，我知道这是针对网页设计的，但它适用)

---

我坚信所谓的3-martini可用性测试。设计系统时，请想象将要使用它的人只有3个马提尼酒。

在将系统移交给同事(其他程序员，质量保证，技术支持)或可用性测试人员之前，与几个朋友和一瓶伏特加酒(当然是在工作之外)进行的非正式测试通常可以起到指导作用。

---