本文摘自《Handbook of Usability Testing》，作者：Jeffrey Rubin和Dana Chisnell，由天翼阅读用户研究员张晓雯翻译。
列出任务清单
任务清单包含被试在测试中要完成的所有任务。清单包括在使用产品、文档等过程中进行的常规任务。
任务设计经历两个阶段。早期阶段，任务清单是为项目团队成员，而不是真实用户设计的。你只需要提供尽可能详实的细节，以便测试计划的审阅者可以评估是否任务是正确且可执行的。
然后，才是将任务扩展为丰富的任务场景脚本，供被试使用。场景脚本应该有现实细节和情境，帮助被试无需主持人的介入就能进行。
测试计划的任务组成部分
测试计划中的任务包括以下四个组成部分：
任务的简短介绍
此时不需要提供太多细节，用一行文字叙述，将任务与项目团队沟通清楚就好。
任务执行中需要的材料和设备
可用性测试中场景至关重要。如果产品处于早期设计阶段，你作为测试主持人，需要提供这些场景材料或是模拟器的当前状态。例如，你想测试一个还没有编码或制作高保真原型的网站，那你至少需要提供页面的线框图。又或者，电脑中的网页可单独操作，只是还没有被组合为完整的工作原型，你（或者是被试）需要按照恰当的时间顺序打开并浏览页面文件。
设定任务成功完成的标准
如何测量任务成功呢？令人惊讶的是，对于这个问题的答案存在诸多分歧，甚至是开发者们对于如何界定任务成功也存有异议。一旦任务描述中确定了任务成功完成标准（SCC），也就意味着你已经精确地说明测试的内容和任务了。SCC定义了任务的范围并且阐明了测试计分规则。如果你很难确定SCC，也正说明了开发团队关于产品设计的疑惑。即便是为了证实这个判断，尝试建立和说明SCC也非常有必要。
成功完成的标准包含：任务或流程到达某个具体步骤或页面；（信息搜索任务中）允许犯错或错误路径的最大次数；确认如果被试到达最终节点但过程中错误不断是否属于“完成”任务。
时间或其他标准
你可能想用时间作为衡量任务成功的标准或是基准。如果你基于时间设置某些基准，那我建议你务必考虑周全，且将此限定在合适的情况下。限定时间的任务在验证/总结性测试中的确是很好的测量方式，但在早期的探索性测试中通常不适用。另外，如果你在测试中要求被试出声思考，那我也不建议你限定时间标准，显然出声会影响任务时间。除了时间外，你还可以用错误率作为基准：例如，无错误一次完成的任务的频率。
任务清单的窍门
尽管标题看起来直接明了，但其实任务设计绝对是非常精妙的过程：请被试通过使用产品执行任务，从而间接地发现可用性问题。实质上，被测试的是产品和终端用户间的关系。从在用户立场、产品以及与之相关的配套资料等方面来看，这种关系说到底就是用来解决问题的某种方法或是提供某种服务。
因此你测试的任务要尽可能地反应这种关系，以便很好地发现痛点：在完成任务时，产品变成了障碍而不是帮手。让我们先来看一个简单的满足测试目的的任务例子，同时总结缺点。
任务案例：网站中的导航Tab
假设你的目标之一：是测试某个供业余和专业摄影师使用的图片分享网站中的Tab标签是否易于理解。将这个测试目标书面化：“了解用户是否可以理解XYZ标签的含义”。在网站上有6个文本Tabs。其中，XYZ标签是有问题的，其标签文本为“Organize（组织）”。
网站现有版本中，用户认为该标签是用来改变浏览的页面中自己图片展示的位置顺序。但事实上，该标签是指将图片分类。
如果仅仅看到了测试目标的表面：用户是否可以理解XYZ标签的含义。那你可能会设计任务来要求主持人：
被试展现标签XYZ并要求他们解释其含义。
主持人会获得关于标签文本的反馈。这样看起来简单直接，毕竟文本是产品的痛点。但是，我们的确将事情过于简单化了。简单地分析下，正确使用这个标签的过程中，至少存在3个独立的过程。
1. 注意到标签
2. 阅读标签
3. 信息加工过程及正确的反应
这三个过程是发生在使用该网站发布照片的具体场景中的。
■ 如果你只是简单地向被试展示标签，那仅仅进行第二和第三个过程就可以了。你不会知道这些行为的前提条件：被试是否注意到了标签。同时，你也将整个场景过分简单化了。事实是，被试是在使用网站执行某个或某些任务的过程中，阅读标签；而不是某人指出标签并询问他们如何理解。不难看出，“场景”是非常重要的，它会极大地影响信息的加工效果。
■ 另外，你也需要辨别标签所处页面位置的影响。如果想要将测试的标签和其他五个行为标签并排放置，那你需要了解被试在有这些潜在干扰标签时是如何反应的。
现在再回到上述的标签案例中。我们分析了标签用途、场景和位置，显然你已经知道，仅仅询问被试标签的含义是绝对不够的。你需要提供恰当的任务，在任务中让被试自然地使用标签。并且，确定是否被试注意到、正确理解并使用了标签（任务可参照图5-5）。事实上，对于将图片归类分组这一任务来说，标签是次要的，辅助的。
图5-5 某个探索性可用性测试的总体任务描述
而测试标签可用性的真正任务是：
将图片分组
请注意，任务甚至都没有提到标签。
在任务执行中，测试主持人需要间接地测试标签的可用性。主持人必须注意观察被试的视线焦点和操作，并在事后访谈部分询问被试对标签的理解等。
现在我们已经设计了满足测试目标的正确任务，下一步根据我们前面描述的任务四部分，细化补充任务。下表描述了测试任务中的四部分。
任务选择方式
已经看过了设计某个任务的案例，下一步是确定测试需要包含哪些任务。受限于时间，你肯定不能对界面、功能甚至是两者都进行完整的任务测试。通常情况是，只测试有代表性的那部分产品功能。
选择任务前，尽可能多地熟悉产品的主要部分以及阐明测试目标是非常重要的。将你的任务清单筛选或缩减到可完成的长度，同时保证任务涵盖了尽可能多的可用性缺陷。下面总结了如何挑选或缩减任务清单的常用方法以供参考。
■ 根据频率选择。选择终端用户群体中最频繁执行的那些任务。最常用的那些任务是终端用户每天都进行的常规操作，可能会占到使用产品总时间的75%-80%。例如，你打算测试一款文字处理包。在考虑设定像“隐藏不想打印出来的批注”这样的诡异任务前，先要确保终端用户可以容易地完成下列任务：
1. 打开某个文档
2. 保存某个文档
3. 编辑某个文档
4. 打印某个文档
通常，测试中会有几个不常见的任务：终端用户中低于5%的群体曾经发现并使用。为什么任务里有它们呢？我们的理论是，开发团队会认为这些个别的“5%用户”会用到这些最有趣且最有挑战性的任务。不幸的是，大部分典型终端用户可不会管那些奇怪任务背后开发者的热情。
如果在践行“75%用户使用的引导线”原则后，仍有时间测试更多任务的话，此时可以测试下至少有25%的终端用户经常进行的任务。只有当你确信常用任务已经全部纳入到清单后，可以适当增加使用频率不高的任务。
■ 根据重要性选择。重要任务是指那些如果错误操作或漏掉操作，将会对终端用户或产品、公司声誉造成严重后果的任务。这些后果可能是：寻求热线电话帮助、数据丢失、产品本身受损，甚至是对用户造成身体上的伤害。总而言之，确保任务清单中已经穷尽了可能导致巨大伤害和恶劣影响的重要任务。
■ 根据弱点选择。弱点在此是指测试前你就已经有所怀疑的，非常难完成或是设计有缺陷的那些任务。通常，开发团队会有较好的把控。当被问到哪些任务可能会较困难时，他们肯定会流露出对新特性、流程、界面风格等的担忧。
有时，开发者会撒谎说“都一样”：所有功能都同样流畅（或糟糕），没有突出的问题部分。不管是出于何种正当或不正当的原因，开发者总是不希望在测试中暴露已知的问题。但是，为了避免后续没有时间修复，用自己的判断力预估哪些任务/功能是不流畅的，哪些部分是新增的，哪些部分是从未被测试过的，以及哪些任务对内部人员来说是较难完成。如果你不确定，那就邀请一位人因学专家来评估决定产品的哪些部分是有缺陷的。（专家评估也可以帮你从整体上细化你的测试目标。）
■ 根据完成情况选择。如果你的测试不得不在开发阶段的后期进行，你可能只能测试已经开发完成的那部分，甚至是完全放弃测试了。尽管这种情况很糟糕，但有时你不得不那么做。你几乎没有时间去等用户手册部分的完成。切记，测试点什么比什么都不测试总是要好点。
描述测试环境、设备和后勤辅助
测试计划的这部分会阐明：你试图在测试中营造的环境和被试需要使用的设备。例如，你想模拟某个保险员的产品销售办事处环境。或者你的产品被化学家用于环境实验室中。又或者你想在嘈杂、拥挤、电话时常响起的环境中测试你的产品。测试场景尽可能地向真实场景靠近。这会帮助被试感觉自己是个真实的终端使用者，而不是被测试者。而且，得到的结果更贴近真实场景下产品使用的情况。
设备描述只要说清楚被试使用的设备：如手机、电脑、打印机等等。其他的数据收集设备，或是用来监控测试的摄像机等设备不一定要写明。图5-6给出了一个例子。
图5-6 测试环境描述：地点和设置
解释主持人作用
这章节解释你作为测试主持人要做什么。如果测试中充当观察者的同事对测试过程不熟悉时，写明主持人作用尤为重要（示例见图5-7）。你要明确主持人什么时候会有些不寻常的举动，以免引起困惑：譬如，主持人在什么情况下会发问或介入测试，以及介入的原因。尤其是在面对过分沉默的被试时，主持人可能会假定自己是某些角色或是魔鬼代言人，鼓励被试发言。
图5-7 测试主持人作用描述
列出要收集的数据
测试计划的这部分会说明测试中收集的数据类型：包括行为和偏好数据。行为数据是指测量被试行为的这部分结果，包括错误率、任务中寻求帮助的次数、执行任务花费时间等。偏好数据是指收集到的被试看法、思考过程的数据，包括被试排序结果、问题的回答等。收集哪些数据是由研究问题决定的。有时，测试计划中的其他部分，如测试方法中已经列出了一些数据指标。不管是定性还是定量地测量行为或是偏好数据，这一切都取决于测试目标。图5-8是在线酒店预订网站进行测试的数据示例。
图5-8 在线酒店预订的测量指标示例
详尽地列出你要测量的指标，可以帮助需求方或相关人士在浏览测试计划后更好地确认结果是否包含了他们希望的数据类型。
下面就是某个典型测试中你可能收集到的数据类型指标。
行为指标清单
■ 帮助下和无帮助下正确完成任务的数量和百分比
■ 获得的提示类型和数量
■ 未正确完成任务的数量和百分比
■ 错误选择的次数
■ 遗漏错误次数
■ 错选菜单次数
■ 错选图标次数
■ 请求帮助次数
■ 使用个人手册次数
■ 访问目录次数
■ “负性评价或是奇怪行为”次数
■ 找到手册中的信息花费时间
■ 找到在线帮助中的信息花费时间
■ 从错误中恢复需要的时间
■ 阅读手册中XX版块花费的时间
■ 询问帮助桌面花费的时间
■ 完成每项任务的时间
定性数据
■ 出声思维的口头报告
■ 亮点语句：（举例）
■ “我爱死它了——什么时候我能有一个呢？”
■ “你们这些人又这么做了——你们怎么依旧不听顾客的意见呢”
■ “哇，太令我印象深刻”
■ “请问我现在能走吗——带着我的钱和产品”
偏好指标清单
评分排序：
■ 产品的有用性
■ 产品与期望的匹配程度
■ 用户任务中产品功能的符合程度
■ 产品使用的容易程度
■ 产品整体的易学习程度
■ 安装的容易程度
■ 索引、目录、帮助、图像等的有用性
■ 阅读屏幕文字的容易程度
■ 帮助桌面对咨询的响应度
偏好排序：
■ 原型1 vs.原型2
■ 本品 vs. 竞品
■ 本品的新概念模型 vs. 原来的模型
描述如果报告结果
本章节将会总结你的测试报告主体，以及如何与开发团队沟通测试结果。图5-9列出了测试报告中需要包含的内容。
图5-9 测试报告包含的内容
你在报告撰写前以及完成后都要与开发团队进行结果沟通。在测试执行完毕后数据分析前，你可能会就项目的重要部分出具一份信息汇总报告。而在分析完毕以及输出正式测试报告后，组织一场正式的演示，邀请整个项目团队、其他感兴趣的人、管理者等参加。
测试计划案例
如果我们把上述提到的部分汇总起来，将会得到一份10页左右的测试计划。你可以访问本书的网页地址(www.wiley.com/go/usabilitytesting)参看完整计划案例。案例中我们测试了某个在线酒店预订系统，你可以下载相关的测试计划和其他文档。