《妙手回春:网站可用性测试及优化指南(修订版)》一第1章 您看到周围有大象吗?

简介:

本节书摘来自异步社区《妙手回春:网站可用性测试及优化指南(修订版)》一书中的第1章,第1.1节,作者 【美】Steve Krug,更多章节内容可以访问云栖社区“异步社区”公众号查看

第1章 您看到周围有大象吗?

妙手回春:网站可用性测试及优化指南(修订版)
DIY可用性测试是什么,为何它很有效?为何很少人这样做?

您为什么拿着一只鸡在头上挥来挥去? 1

为了赶走大象。

这管用吗?

您看到周围有大象吗?

—一个非常古老的笑话

介绍DIY可用性测试之前,先让我来说一下什么是可用性测试。

很简单!

观看其他人试着使用您正在(或已经)创建/设计/建造的产品,目的是(1)让它使用起来更容易;(2)证明它容易使用。

可用性测试的种类有很多,但它们有一个共同点,那就是都需要观察用户实际使用产品。

实际使用使得可用性测试与调查、访谈和焦点小组等方法截然不同。在调查、访谈和焦点小组中,您将询问用户对产品的看法或过去的使用体验。

为了将各种可用性测试进行分类,一种有用的方法是,看它是定性的还是定量的。

在定量测试中,您的目的是要证明某个结论,例如“最新的版本是不是比以前的版本好?”或者“我们的网站与竞争对手的网站使用起来一样容易吗?”;这是通过测量诸如成功率(多少人完成了您指派给他们的任务?)和完成任务花了多少时间等指标来实现的。

由于目标要进行证明,因此定量测试有点像科学试验:它们必须严密,否则结果将不可信。这意味着您必须制订测试方案,并严格按方案测试所有参与者2。您必须仔细地收集数据。您必须有足够大的参与者样本,以确保结论具有统计意义。而这些参与者必须能够代表实际用户,这样才能将结果外推到更大的人群。所有这一切都意味着您必须对测试有深入的了解,并在测试中小心行事。

在定量测试中,为了避免测试结果受到影响,您通常要尽最大的努力减少与参与者的交互。在极端情况下,参与者独自坐在房间里,主持人通过对讲机发出指令,而观察者通过单向玻璃进行观察并记录数据。

那么,什么是DIY可用性测试呢?
现在您可能猜到了,我向您推荐的测试位于定性—定量谱系的另一端。

DIY可用性测试绝对是定性的,它不是要证明什么,而是要让您获得用来改善产品的观点。

因此,DIY测试不用那么正式,也不用那么科学。这意味着您可以测试更少的用户(只要能获得所需的观点就可以),甚至可以在测试中途改变规则。例如,如果第一位参与者不能完成某个特定任务而且其中的原因显而易见,您可以修改这个任务,甚至让其他参与者跳过这个任务。而在定量测试中不能这样做,因为这将导致结果无效。

基本上,只需要主持人和参与者坐在一起,将要执行的任务交给他,并让他在执行任务期间进行发声思维就可以了。

不需要收集数据,相反,开发小组成员、客户和其他利益相关方将在另一个房间通过屏幕共享软件观察测试过程。测试完毕后,观察者们将进行总结(debriefing),他们核对所做的记录,并确定要修复的问题以及如何修复它们。

仅此而已。

有趣的是,这确实管用
在做可用性测试讲座时,我总是首先进行一次现场演示——完全临场发挥。我做的唯一准备工作是,选择一位出席者的网站并使用它,找出访客在该网站可能想完成的一个任务。例如,如果是卫生保健网站,我可能选择一个有关预约挂号的任务。


49101002771e7d31a7037d6955567e092a372e67

接下来,我让一位志愿者充当测试参与者,并花15分钟进行简化的测试(真正的测试通常需要一小时,但也可能短到只有5分钟或长达一整天)。

结果几乎总是相同。

  • 参与者度过了一段美好的时光,并且因为勇敢地充当志愿者而获得热烈的掌声。
  • 网站“所有者”在整个15分钟内都忙于记录要修复的问题,并询问能否将录像播放给同事和老板看3。
  • 每个人最后都想:“这么简单?我也能做”。
  • 测试结束后,我问,“这15分钟花得值吗”?所有人都点头表示同意。

现场演示是为了表明(1)这很容易;(2)总是管用。有些人认为我之所以能够让测试看起来很容易是因为我做过很多次,但等到讲座结束以后,尝试过测试的每个人都认为这没有什么神奇之处,它确实像看起来的那样简单。

必须承认,我在最初几次现场测试演示中有些担心。但到目前为止,我做了大约50次这样的测试,每次都管用,无论测试的是哪个网站,也不管参与者是谁。

事实上这确实管用。只要问一问做过可用性测试的人,他都会告诉您这几乎总是管用。只要让人们——任何人坐下来使用您正在开发的产品,他都不可避免地会遇到一些问题,而这些问题是大部分用户都会遇到的。

但它为何管用呢?
只需要做这么简单的工作(让人执行任务并观察)就总能发现严重的可用性问题,这看起来有些不可思议。但只要考虑一段时间(而我考虑了多年),就能明白其中的原因。

  • 它之所以管用是因为每个网站都有问题。每个人都可以根据自己的经验了解到这一点。在使用网站的过程中,您经常会遇到可用性问题,而这些问题通常很严重,让您极度沮丧甚至无法完成原本要做的工作。
  • 有些成熟的网站可能没有那么多严重的问题,尤其是经过多轮可用性测试以后,但不要自欺欺人:您的网站肯定存在可用性问题。我的网站也存在可用性问题,您可以想见这有多让人难为情。甚至Amazon网站也存在可用性问题,而我对该网站的评价很高4。
  • 它之所以有效是因为严重的问题通常容易发现。同样,想想您在其他人的网站中遇到的可用性问题吧。您是否经常这样想:他们怎么可能不知道这种问题呢?很多最严重的问题一眼就能发现,几乎所有人都会遇到。


c45b4fb4c863025a936a52542b40fa948ecb3031
  • 但是对于我们自己的网站,我们却总是认为这样的问题难以发现。
  • 对您来说,您自己网站的可用性问题可能不明显,因为您知道该网站的工作方式——至少是您认为的工作方式;而用户并不知道,这就是区别所在。
  • 当然,也有一些严重的可用性问题隐藏得更深,这种问题不会有那么多的访客遇到。但是除非有大量资源用于可用性测试(例如,这是您的全职工作),否则强烈建议您重点排除那些显而易见的问题,而大多数网站连这一点都没有做到。

最后:

  • 它之所以管用是因为观看用户使用产品能让您成为更优秀的设计师。虽然大多数网站开发人员都知道诸如“以用户为中心的设计”和“用户体验”等术语,但设计师、开发人员、客户、经理和支票签字者——所有参与设计过程的人都很少花时间观看用户如何使用网站。因此,最终用户变成了抽象的概念,而设计是根据我们自己的想象完成的。
  • 通过观看测试过程可以让您更深入地了解用户如何使用产品以及如何为使用而设计产品。它赋予您设计的智慧,就像旅行可以开阔视野一样。

为什么很少有人进行测试
既然它这么容易而且这么有价值,为什么可用性测试没有成为每个Web项目的标准组成部分呢?即使在当前,进行可用性测试的公司也很少,即使做,他们也通常只做一次,那就是在项目即将完成的时候。

在我看来,这在很大程度上是因为大多数人都没有任何可用性测试方面的直接经验,他们还没有认识到测试的价值所在。但是即使他们有这样的经验,也还是有很多似是而非的理由不这么做。

例如,没有时间。测试看起来需要做大量的工作,而大部分人手头的工作还来不及完成呢!大多数网站开发的日程安排都非常紧张,因此一种普遍的态度是“先发布,以后再调整”。

另外,人们普遍不愿意展示未完成的产品。既然我们都知道产品有问题,为什么还要向别人展示并让他们告诉我们已经知道的问题?这不是在浪费彼此的时间吗?谁喜欢向公众展示产品的缺陷呢?

这些说法好像都很有道理,但正如您将看到的,它们并不一定正确。

FAQ
您讨论的是小样本测试。通过网站分析从大量用户那里收集数据不是能获得更可靠的信息吗?

是的,网站分析让您能够非常精确地了解用户在您的网站中做了什么(72%的访客在5秒钟内离开了主页)。它的样本非常大(实际上是所有用户),数据是根据实际使用情况收集的,而分析工具让您能够提出任何统计性问题并立即得到答案。

但问题是,正如任何可用性专业人员都乐意向您指出的,虽然通过分析工具可以非常详细地了解用户在您的网站中都做了些什么,但它们并不能告诉您用户这样做的原因。例如,如果访客在某个特定网页上花费了大量时间,统计数据并不能告诉您这是因为他们发现这个网页的内容很有用并忙于阅读,还是因为这些内容不知所云,他们正忙着猜测呢。

而可用性测试非常适用于帮助您了解访客的所做所为背后的原因。

在需要找出并修复可用性问题时,可以使用精确的数据分析,它们将告诉您用户都做了些什么,但您无法知道用户是怎么想的。也可以和用户坐在一起一个小时,这能够让您倾听用户的想法并提出探究性的问题。如果必须在这两者之间做出选择,我每次都会选择后者。

1 译者注:当前,编程领域有一个谚语叫wave a dead chicken,指的是自己知道无效但还要做给别人看的工作。
2 在可用性测试中,将我们观察的人称为“测试参与者”而不是“测试对象”,这旨在强调我们测试的不是人,而是他们使用的产品。
3 有一位所有者在几个月后写信告诉我,看过针对其网站的演示测试后,开发小组马上做了一个简单的修改。他们根据前几个月的数据进行了计算,这种修改将每年为公司节省100000美元。
4 经常有人给我发电子邮件指出他们在Amazon.com中发现的问题,好像我能针对这些问题做点什么似的。我确实是Amazon的金牌会员(每年的费用是79美元,换来的是能够在第二天“免费”发货),但我的影响力也仅此而已。Amazon做了大量的可用性测试,如果您遇到问题,我敢肯定不是他们没有意识到,很可能只是还没有决定怎么处理而已。

相关文章
|
17天前
|
测试技术 C语言
网站压力测试工具Siege图文详解
网站压力测试工具Siege图文详解
26 0
|
25天前
|
安全 Linux 测试技术
提升龙蜥内核测试能力!探究持续性模糊测试优化实践
清华大学软件学院对Anolis OS使用靶向模糊测试方法将测试工作引向修改的代码,进而提高对业务代码的测试能力。
|
1月前
|
敏捷开发 运维 安全
链家网站系统测试设计与实现_kaic
链家网站系统测试设计与实现_kaic
|
1月前
|
敏捷开发 分布式计算 测试技术
深入理解软件测试中的自动化框架选择与优化策略
【2月更文挑战第29天】 在软件开发的生命周期中,测试环节扮演着至关重要的角色。随着敏捷开发和持续集成的普及,自动化测试成为确保软件质量和加快产品上市速度的关键手段。本文将探讨在构建自动化测试框架时面临的挑战,分析不同类型自动化框架的特点及其适用场景,并提出一系列优化策略,旨在帮助测试工程师提高测试效率,确保测试结果的准确性。
23 0
|
1天前
|
测试技术 API Python
Appium控件交互策略:优化自动化测试效率的关键方法
该文介绍了如何使用Selenium与APP进行交互,包括点击、输入和状态判断等操作。例如,通过element.click()点击控件,element.send_keys()输入文本,以及element.is_displayed()检查元素是否可见。还展示了如何获取元素属性,如resource-id、text和class,并提供了Python代码示例来定位并操作APP元素,如滑动条的显示、可点击性检测及点击滑动条中心位置。在编写测试脚本时,应注意元素定位和状态验证以确保测试稳定性。
8 1
|
17天前
|
测试技术 Linux Apache
网站压力测试工具webbench图文详解
网站压力测试工具webbench图文详解
12 0
|
19天前
|
Web App开发 搜索推荐 测试技术
网站速度测试
【4月更文挑战第8天】网站速度测试
12 2
|
1月前
|
SQL Apache 流计算
Apache Flink官方网站提供了关于如何使用Docker进行Flink CDC测试的文档
【2月更文挑战第25天】Apache Flink官方网站提供了关于如何使用Docker进行Flink CDC测试的文档
143 3
|
1月前
|
敏捷开发 分布式计算 数据管理
探索自动化测试在持续集成环境中的优化策略
【2月更文挑战第18天】 在高速迭代的软件开发过程中,自动化测试已成为确保产品质量和加快交付速度的关键。本文深入探讨了自动化测试在持续集成(CI)环境中面临的挑战,并提出了一系列优化策略。通过对测试流程、工具选择和测试数据管理等方面的细致分析,旨在为软件测试人员提供实用的改进方法,以提高自动化测试的效率和准确性。
|
2月前
|
前端开发 测试技术 Android开发
自动化测试学习网站
自动化测试学习网站

热门文章

最新文章