获取用户反馈一直是我们创建引人入胜的应用程序的核心，这些应用程序可以为客户带来业务价值并传达出色的用户体验。 我们通常通过测试应用程序用户来做到这一点。 电子书“测试应用程序用户的实用指南”为设计人员和开发人员提供了分步指南，介绍了如何在审核和非审核（在线）测试中进行用户测试。 在本文中，我们将研究关键组件之一：如何编写有效的可用性测试脚本。
出色的可用性测试方案既简单又具有启发性
为什么主持人拥有一个在用户测试中必须遵循的脚本很重要？ 首先，您希望测试尽可能地标准。 这样可以确保您不会偏向单个参与者的响应。 并且确保每个用户都能回答相同的问题，从而确保您可以看到用户回答中的异同，这将帮助您从研究中得出更具说服力的结论。
最终，脚本应该很简单，但应包含足够的说明，以帮助主持人在主持会议期间指导参与者–或提供参与者在非主持（在线）会议中需要了解的所有信息。 以下是脚本文档应包括的部分，并针对每个部分提供了建议：
提示：为使脚本在主持人的测试中更易于阅读，请使用其他文本样式或颜色将说明与将要读取给参与者的实际脚本分开。
1.背景资料
本部分适用于主持人和阅读可用性测试脚本但不与测试参与者共享的人员。 通常，我们会提供有关测试日期，客户端，参与者人数和类型，版本历史记录和测试方法的参考信息。 我们还将描述您正在测试的内容，测试的目标以及每个参与者需要多长时间。 包含有关会员奖励和补偿的信息也很有用。
2.简介
可用性测试脚本中介绍性部分的示例。
本节为主持人提供了一个脚本，主持人欢迎参与者，并为他们提供关于测试的期望的总体思路。 如果对测试进行审核，我们还将代表协调员和所有参与公司。
在这一点上，告知参与者没有正确或错误的答案是有帮助的。 这将帮助他们感到更舒适。 此外，鼓励用户在完成作业时大声说出来。 您将需要了解他们的思维过程，他们的行为和感觉。
请求同意记录会话也很重要。 确保获得明确的口头同意。
提示。 在个人主持的测试过程中，您应该让参与者有机会在开始之前提出任何问题。
3.初步检查问卷
在用户测试的此部分中，您的主要目标是使您的参与者感到自在。
在可用性测试方案中，您将包括有关基本信息的问题，例如姓名，年龄，职业以及与测试有关的任何其他人口统计信息。 在审核过的测试中，只需请求确认即可（例如，“请确认您的名字是[NAME]。”）。
然后询问与您的项目有关的任何常规问题。 例如，如果您正在测试旅行应用程序，则可能会询问参与者飞行的频率以及他们是否使用任何应用程序来预订和计划行程。
4.任务和方案
任务是您要求参与者在设备或其他测试界面上执行的操作。 每个任务必须有一个目标。
脚本可以帮助参与者与界面进行交互，并想象他们将如何在现实生活中使用该应用程序。 用户的目标和任务可能如下所示：
- 测试目标： 查看酒店房间并预订一间 。
- 一个不好的任务的例子： 预订旅馆房间 。
- 一个更好的工作（有一个场景）的例子： 您计划从9月3日至14日去曼谷度假。 您需要预订住宿。 转到应用程序，查看信息并预订您认为最好的房间 。
提示：始终让用户回来并根据需要多次阅读作业。
最佳写作技巧
尝试不扭曲用户行为是一项艰巨的任务，但是如果您想获得有用的结果，则非常重要。 以下是编写更有效的中性任务的五个技巧：
- 使任务切合实际，以帮助参与者与界面进行交互。 创建可以最大程度模拟现实世界的场景。 不要强迫他们做通常不做的事情。 例如：
- 测试的目的： 查看site.com上出售的产品 。
- 一个艰巨任务的例子： 买一条出售李维斯（Levi's）的白色高腰牛仔裤 。
- 一个更好的任务的例子： 以不到20美元的价格买一条Levi's牛仔裤 。
- 在现实生活中，用户可能会在选择要购买的商品之前先进行浏览。 在第一个示例中，我们没有为用户提供选择他通常选择的功能的能力。 相反，我们告诉他们该怎么做。 他们将专注于寻找我们告诉他们要寻找的牛仔裤，并且可能不会像往常一样与界面交互。
- 不要强迫参与者与特定功能进行交互。 而是尝试弄清楚他们是如何决定使用该界面的。 这样，您将发现他们是否可以找到功能并按预期使用它们。
- 测试的目的： 找到一个食谱 。
- 一项艰巨任务的示例： 使用搜索栏查找印度食谱 。
- 最好的任务示例： 您现在想煮印度菜。 使用该应用查找食谱。
- 避免添加提示或步骤说明。 为场景提供背景比提供明确的步骤来实现目标要好。 这个想法是允许参与者自己导航界面。
- 测试的目的： 监视书中的进度 。
- 一个糟糕的任务的例子： 您想更新正在阅读的书中的进度。 转到应用程序，找到书，将其添加到列表中并更新进度 。
- 最好的任务示例： 您开始读一本新书，不想失去上一次完成的学习。 使用该应用程序更新进度 。
- 对于使用在测试界面中可以轻松找到的相同语言的参与者，不要让他们更轻松地完成任务。 例如，如果界面显示“免费使用月份”的按钮，则您不应在任务中使用相同的措词：
- 测试目的： 免费试用该服务 。
- 一个不好的工作的例子： 去这个网站免费使用一个月 。
- 任务的最佳示例： 您想首次尝试此服务。 转到该站点并注册 。
- 尽可能直接地制定任务。 看一下以下两个示例任务：
- 测试目的： 预约 。
- 一项艰巨任务的例子： 现在，看看是否可以尝试找到与营养师约会的方法 。
- 更好的工作的一个例子： 现在，约一个营养师 。
- 其中第一个带有附加短语“查看是否可以找到方法”给人的印象是该任务将难以完成，甚至提示可能等待确定的答案，因为界面的经验或设计不佳。
提示：如有必要，您可以在任务之间提问。 最好等到参与者完成任务，以免分散他们的注意力。
5.测试后问卷
完成主要测试后，部分可用性测试脚本问卷将指导主持人提出其他问题。 在本节中，主持人将希望探索答案不清楚或模棱两可的领域。
您可以向参与者询问有关产品或特定功能的高级问题，或者他们是否希望有所不同。 您还可以询问有关他们要使用的新功能的开放式问题。
6.总结
在可用性测试脚本的这一部分，您将感谢与会人员的宝贵时间。 您可以询问用户是否有任何问题。 最后，您应该与您的用户讨论他们的补偿细节。