可用性测试的测试的方法

1. 可用性测试的测试的方法

所谓可用性评估，即是对软件“可用性”进行评估，检验其是否达到可用性标准。目前的可用性评估方法超过20种，按照参与可用性评估的人员划分，可以分为专家评估和用户评估；按照评估所处于的软件开发阶段，可以将可用性评估划分为形成性评估和总结性评估。形成性评估是指在软件开发或改进过程中，请用户对产品或原型进行测试，通过测试后收集的数据来改进产品或设计直至达到所要求的可用性目标。形成性评估的目标是发现尽可能多的可用性问题，通过修复可用性问题实现软件可用性的提高，总结性评估的目的是横向评估多个版本或者多个产品，输出评估数据进行对比。网站可用性测试包含的步骤有：定义明确的目标和目的,安装测试环境，选择合适的受众，进行测试和报告结果。

2. 可用性测试的实用性

无论使用正式的或非正式的设备你都可以做可用性测试。使用任何类型的设备，你都可以采用各种正式或非正式的方法。 使用下述任何一种设置，你都可以进行有效的可用性测试：* 两室或三室的固定实验室，配备视听设备* 会议室，用户的家或工作室，配备便携式录音设备* 会议室，用户的家或工作室，没有录音设备也可以用人眼观察和笔记来代替* 当用户在不同地点可以远程控制因此，即使你没有或没法找到一个固定的实验室，你也应该进行可用性测试。不要说，“因为我们没有一个可用性实验室，所以我们没法做可用性测试。 只要去做！在任何空间你都可以完成。 看情况。一个典型的测试需要8至16个人（每用户组）。如果每个用户将花费一小时，就意味着每个用户组的测试需要一到两个工作日。 当你的项目处在： * 纸上原型或早期开发阶段 * 计划通过几轮测试整个开发 * 有相当一致的用户群 如果只要人帮忙找出严重问题，你可能只需要4到6人。 * 如果您有不同的潜在用户群组（例如医生、病人、研究人员），你需要所有这些群体的用户代表。如果你对用户的电脑操作或网络经验有要求，还需要包括经验较少的和经验较多的用户。 * 如果你要对你的产品或系统进行正式的定量测试，你将需要更多的人以获得统计上有意义的结果。对于诊断型的可用性测试，6至8个用户通常是不足以揭露产品的大部分问题的。 * 如果在网站开发过程中你一直在做迭代（重复）的可用性测试，就会有许多用户参加其中一个或另一个版本的网站测试。因此，尽管每个可用性测试只有少于10名的测试参予者，但在网站推出前你可能需要15到30人参加测试。做可用性测试需要多少费用？ 成本要看网站的大小，你的测试量，预期的用户类型数目，以及你期望这个测试正规到什么程度。 如果你已经有一个标准的测试程序和可用的材料设备，可用性测试将进行地很快很便宜。如果你或你的用户招聘公司拥有一个用户数据库，用于招募的时间就可以大量节约，因此，花费会更少。 应该考虑这些因素：* 计划所用的时间：确定测试的主要问题，需要测试的用户类型，招聘的用户的筛选问卷以及测试场景。* 招聘的花费：公司人员的时间，给招聘公司（通常是一个很好的选择）的花费，可用性专家需要花时间熟悉网站及其制作团队，设计相应的测试场景，如果你需要录制测试过程，还需要花费实验室或便携式摄录设备的租金。* 团队观察用户（进行测试）花费的时间* 付给测试参与者的报酬或礼物* 分析视听资料，查找存在的问题以及推荐解决办法所用的时间* 和开发人员讨论变动和修改方案，撰写调查结果和建议报告所用的时间。记住，预算分析要包含多个可用性测试。打造一个网站（或产品）的可用性是一个反复迭代的过程。你会发现，用在在开发过程中几个小测试的预算比起在项目末期只做一个大型测试要有价值的多。网站可用性测试是为了实现跨形式的视觉一致性，包括测试屏幕分辨率改变时的显示，边距和列布局，表单的颜色和大小，标签使用的字体，按钮的大小，所使用的热踺或快捷键，使用的动画/图形，按钮等控件的标签，同一字段的文本框的长度，日期和时间字段的格式。

3. 可用性测试篇

刚好最近公司的产品要上线了，上线车间工头指定了测试的任务要我来负责，这下硬着头皮整理一下最近可能后面一段时间长期要进行的这一项任务——可用性测试。
  
 结合之前刘津老师《破茧成蝶》里面对可用性测试的说明解释一下可用性测试，作为上线前的测试工作，一般有 可用性测试和结合灰度上线的A/B测试 ，但我们公司的产品属于B端产品，所以选取了可用性测试为主要的测试方法。
  
 
  
                                          
 其中的“ 用户 ”即为请来的测试人员，这一类人往往是这一产品的代表使用者，是极具价值的目标人群，从他们操作过程中发现的问题往往更具代表和真实性，能获得更准确的结果。对于这类用户的要求是：
  
 其中的“ 使用产品 ”则是通过我们对产品业务逻辑的理解，把具体的业务目标转述成使用目标，使用目标不能提出具体操作，给出工作目标即可，以我们车间生产的产品为例，如“客户来电欲预订下周二中午的酒席，请操作”，不需要具体的操作方法和功能，完整表达产品的逻辑即可。对使用目标的标准是：
  
 “ 发现并处理问题 ”在用户使用过程中，观察用户的操作行为，在进行具体操作时，用户停顿了，有疑虑了，出现了操作的中断、失误，都有可能是产品的易用性缺失导致的，需要对当时的页面进行完整思考，之后再做出可行性的优化，同时，可能统计出来的问题比较复杂和混乱，就需要对出现的问题进行归纳和整理，做出设计和开发上面优先级的排序，以方便后续的优化，归纳依据如下：
                                          
 开发次序
  
 以上是我们现在操作可行性测试的大概方法，结合实践了很多前辈的经验，由于车间资源不是很充足，所以都是请其他部门的开发同志操作，因为B端产品的特殊性（针对特定群体，需要一定学习成本，产品具有差异化）最终测试也还是取得了一定的成效，结合PDCA式的优化方案，继续进行测试并改进产品，希望大家都能好好打磨自己的产品，完。

4. 可用性测试

可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题，通常只能做少数几个用户的测试，看他们怎么做，属于典型的定性研究。
  
  
 它是UGC理念的一种很漂亮的实践，在目的明确的前提下，简单介绍一下主要过程。
  
 首先要招募测试用户。招募测试用户的主要原则是，这些用户要能尽可能地代表将来真实的用户，比如说，如果产品的主要用户是新手，那么就应当选择一些对产品不熟悉的用户。
  
 然后是准备测试任务，测试的组织者在测试前需要准备好一系列要求用户完成的任务，这些任务应当是一些实际使用中的典型任务。
  
 接下来的重头戏是测试过程。可用性测试的基本过程就是用户通过使用产品来完成所要求的任务，同时组织者在一旁观察用户操作的全过程，并把发现的问题记录下来。
  
 测试结束后：组织者可以询问用户对于产品整体的主观看法或感觉。另外，如果用户在测试的过程中没有完全把思考的过程说出来，此时也可以询问他们当时的想法，询问他们为什么做出那些操作。
  
 最后是研究和分析：在可用性测试结束之后，组织者分析记录并产出一份产品的可用性问题列表，并对问题的严重程度进行分级，使得我们可以根据项目进度来选择哪些优先处理。
  
 可用性测试的常见问题与对策
  
 和用户访谈、调查问卷一样，可用性测试也有其特别需要注意的问题。
  
 第一，如果可用性测试做得太晚（往往在产品将要上线的时候），这时发现问题也于事无补了。
  
 其实，可用性测试在产品的各个阶段都可以做。在尚无任何成型的产品时，可以拿竞争对手的产品给用户做；在产品只有纸面原型的时候，可以拿着手绘的产品，加上纸笔给用户做；在产品只有页面Demo的时候，可以拿Demo给用户做；更多的时候，在产品已经可以运行以后，可以拿真实的产品给用户做。不同阶段不同做法，从中都能发现相应的问题。
  
 第二，总觉得可用性测试很专业，所以干脆不做。
  
 可用性测试，听着很专业，但收益又无法量化，所以对很多老板来说，不太愿意在这个上面投入资源，经常因为项目时间过紧被略过。我们知道，可用性测试通常来说做5 个左右的用户才可以发现大部分的共性问题，前前后后的准备也耗时不少，但只做一个用户，并且简化步骤，也比不做要好。
  
 对一个内部使用的用户管理平台，我自己尝试过一次最轻量级的可用性测试，表现为：一个同事，半个小时，在我的座位上，简单的几个任务，比如“将XXX用户的有效期增加一年”，“将YYY公司的状态设置为冻结”，“查询ZZZ公司的员工数”等。结果发现了十几个问题，效率很高。
  
 第三，明确是测试产品，而不是测试用户。
  
 可用性测试要邀请用户来做测试人员，我们在开始之前，应当明确地告诉用户，这个测试的目的是发现软件产品中的问题，而不是要测试用户是否有能力来很好地使用软件。所以，不要让用户听到“可用性测试”的术语，而是说“来试用一下我们的新产品，提点意见”。清楚地说明这一点将有助于减轻用户的压力，使得他们能像在真实环境一样来使用软件。
  
 第四，测试过程中，组织者该做的和不该做的。
  
 刚开始的时候，可以告知用户大概持续的时间，要做哪些事情，让用户心中有数，轻松愉快地完成任务。
  
 可用性测试中，我们可以要求用户在使用产品的过程中采用一种名为“发声思维”的方法，即在使用产品的同时说出自己的思考过程，比如为了完成某个任务，用户想先做什么，后做什么，为什么要做某个动作，等等。
  
 做测试的过程中千万不要有任何的引导与暗示，而只是观察和记录，因为任何引导都可能使得原本可以发现的问题无法暴露。用户行为和预想的不一样时，可以提问，实在进行不下去的时候，给予提示。记住，一切的错都是产品和我们的错，用户绝对没有错。如果真觉得用户错了，那也是你找错人了，不是这个人错了。
  
 结束之后，如有可能应该送个小礼品，当然在邀请的时候就要告诉用户会有一些对他付出时间的补偿。尽快总结，并且发给用户，一方面让用户感到他做了一件有意义的事，另一方面也是表示感谢，建立长期和谐的“用户参与产品设计”的氛围。最重要的，这份总结要用于指导产品改进，这才是可用性测试的根本目的。

5. 可用性测试的介绍

可用性测试的概念是：让一群具有代表性的用户对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。该产品可能是一个网站，软件，或者其他任何产品，它可能尚未成型。测试可以是早期的纸上原型测试，也可以是后期成品的测试。在IS0-9241-11中对于可用性做出了明确的解释：Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

6. 可用性测试的起源

可用性最早来源于人因工程（human factors）。人因工程又称工效学（ergonomics），起源于二战时期，设计人员研发新式武器时研究如何使用机器、人的能力限度和特性，从而诞生了工效学，这是一门涉及多个领域的学科，包括心理学、人体测量学、环境医学、工程学、统计学、工业设计、计算机等。

7. 【超详细】可用性测试方法总结

之前总结过一版 交互设计流程图 ，主要是想给自己以后做设计梳理一下过程，但是那份流程里面只有枝干，并没有枝叶，所以针对每个方法我都会撰写一份方法总结，或者说指导，目的就是为以后实践做准备。我期望的效果是，假如一个没有接触过该方法的人看到这份总结，可以按照这个总结一步步完成实验。这就是我最大的目的。下面就是第一份总结《可用性测试方法总结》。
  
 （预警：长文慎入！不过耐心看完肯定会有所收获）
  
 ============分割线==================
  
 可用性测试的过程主要有七个步骤：测试前思考、制作测试原型、撰写测试脚本、招募测试者、设置测试环境、预测师、正式测试以及测试结果统计分析。这七个步骤有些事可以并行的，有些是需要严格按照前后顺序执行的。七个步骤组成的流程图如下：
                                          
 下面我就针对这七个步骤，谈谈具体要怎么做。
  
 不论是做哪个平台的可用性测试，比如PC端、移动端或者是WEB端的可用性测试，最最重要的就是要先理清楚一些基本问题。基本问题就是最经典的5W问题：
  
  
 ·为什么要进行这个测试（why）？测试可以验证一些设计中的疑惑，或者找出现有的界面、流程设计上的问题，具体问题要具体分析。
  
 ·什么时候在哪里做测试（when？where？）？时间一般是需要和测试者协调的；地点一般选择在安静的会议室即可，如果公司有专门的实验室那就最好不过了。
  
 ·谁要作为测试者（who）？这里可以在招募测试者会详细讨论，不过测试者一般是跟我们的persona接近的人，或者换个说法，测试者一般是我们的目标用户。
  
 ·我们要测试什么（what）？测试一些功能点，测试界面设计，测试流程设计，测试设计中有争议、有疑问的地方。
  
 当然这些问题其实都不太难，但是这些都是至关重要的问题。如果没有经过这个步骤的思考，整个可用性测试做下来就会像无头苍蝇，没有一个总的指导。
  
 在想清楚以上的问题之后，需要为可用性测试做一些准备工作。主要工作有：①招募测试者；  ②撰写测试脚本；  ③制作测试原型。
  
 这三个过程不分先后，条件允许的情况下（人力物力充足时）也可以同时进行。
  
 招募测试者算是可用性测试最重要的一个环节之一的，测试者是否合适直接关系到测试结果的好坏，测试结果直接关系到能否发现产品现有的问题。所以招募测试者是重中之重。理想的测试者是我们的目标用户，所以可用性测试要努力寻找到目标用户作为测试人员。寻找的途径如下：
  
  
 a)最简便的，假如同事（非同部门）或者好友也是目标用户，可以选用同事或者好友作为测试人员。
  
 b)其次，大型公司都会有自己的用户资料库，可以从这个库里面寻找到测试人员。
  
 c)又或者说，委托第三方机构帮忙寻找测试人员也是允许的，不过效果可能不如自己寻找的。
  
 d)当然，现在的应用一般都会有自己的微博、微信、官网或者论坛，这些是非常好的寻找测试者的渠道。我们可以推送招募测试者的公告，让用户填写一份调查之后，我们再筛选得到我们想要的测死者。公告中要注明奖励，一般为小礼品的奖励，保证对测试者有一定的吸引力，同时又不至于让他们会为了这个礼物对个人信息造假。其次，对于测试者，我们需要进行一个筛选【3】。首先需要用户填写必要的个人信息：比如姓名、电话（邮箱）、空闲时间；然后根据调查选择其他一些个人信息：性别、年龄、职业之后，最后留几道问卷题目进行筛选。
  
 筛选的维度主要有：
  
 ·平台。如果测试的产品与平台有关，比如是Android或者iOS，需要在这里进行一个筛选。
  
 ·对产品的熟悉程度。比如我们想找一些初级用户和一些高级用户，可以选用“使用时间”这一项来衡量用户对产品的熟悉程度。
  
 测试脚本的好坏直接关系到结果的好坏。在撰写测试脚本之前，我们需要先确定一些结果分析的维度。一般的维度有：a)任务完成度b)致命错误c)非致命错误d)完成任务的时间e)主观情绪f)偏好和建议。对于这些维度的解释具看第文章的最后一部分“测试结果统计分析”。
  
  
 由于分析的维度会关系到脚本的问题，所以在确定分析维度之后，我们可以对功能点进行任务分析。把所有需要测试的功能点列出来，对每个功能点进行任务设计。对于任务而言，用户最主观的感受就是两个：界面和流程。所以测试脚本又可以从这两个维度去细分。
  
 需要注意的是，可用性测试中，问只是其中的一部分，观察是另外一个重要的内容，所以测试脚本不仅仅要有问的问题，还有需要撰写工作人员观察的注意点。同时可以在撰写完测试脚本的同时，把总结大纲也写出来，方便后期总结的时候统一结果展示。
  
 特别的，在设计的时候有疑惑的点，或者有争议的点，在可用性测试也可以得到较好的验证。
  
 写完测试脚本之后，可以和利益相关者（项目经理、产品经理、开发等）讨论一下，请他们校验一下测试脚本。
  
  界面： 
  
 a)当前界面有什么？
  
 b)每个东西用户觉得是什么？
  
 c)可以操作吗？
  
 d)用什么手势操作方式？
  
 e)操作之后会怎么样？
  
 f)界面显示的内容足够吗，有没有缺少什么东西？
  
  流程： 流程的测试就是根据任务来进行的。把产品的需求文档罗列出来，然后给每个需求配上一个合适的场景，当然也会出现一个场景覆盖多个需求的情况，这也是允许的。然后让用户在场景下去进行任务，观察用户，然后随时提问用户，随时准备回答用户的问题。
  
 以上两点适合所有的可用性测试，但是对于版本更新类的可用性测试，我们还需要了解这个更新对于用户来说的接受度如何，所以需要增加一些对比性的问题：比如说：新旧版的操作流畅度、界面表达对比感受。
  
 最后需要注意的是，一次可用性测试能涵盖的范围有限，所以要限制脚本问题的数量，以及对脚本的问题进行优先级的排序。
  
 举个例子，之前做过一个微信端的众筹平台。我就可以设定以下任务：
                                          
 可用性测试的原型一般是高保真的Demo，可以用Prott，Flinto，proto，墨刀等来制作，制作力求真实还原应用的最终实现效果。制作高保真Demo是一件耗时耗力的工作，所以在制作的时候可以适当忽略一些动效、界面等。不过做出来的Demo最终也可以给开发参考，所以辛苦也是值得的。甚至于，可以请求开发人员制作原生的程序Demo（针对安卓平台），程序Demo体验会更加好。
  
  
 当然，纸面模型也是另外一种非常好的工具。纸面模型需要把纸面模型都只做出来，然后把所有的弹出窗口、下拉菜单等控件也制作出来。然后设计师充当wizard of oz来辅助用户完成任务。即用户对着纸面模型来操作，然后设计师实时反馈用户的操作。这样子要求设计师非常熟悉测试的应用，同时，测试的时间也会大大增长。同时，动效作为设计的一环在这里无法表现出来，所以结果可能会不如高保真Demo来的好。总之各有利弊，根据实际情况来考虑。
  
 测试环境是指测试的时候需要使用的记录设备，通过把测试过程记录下来可以更好地分析用户的行为，特别是用户自己都没有觉察出来的一些东西。
  
  
 首先，最最重要的一点是录音，录音一方面是在整理访谈记录的时候可以帮助设计师回忆访问的场景，然后填补一些缺失的笔记。另一方面，录音也可以作为一种存档的材料。同时，录音也存在简单、易操作、隐蔽等特点，使用录音笔或者现在随处可见的智能机即可完成录音。所以强烈推荐进行可用性测试的时候一定至少要录音。
  
 录音之外就是录像，如果有录像的话，录音的步骤就可以省略。录像主要是记录用户的表情和动作。有时候，用户的表情和动作可以传达很多东西，通过把这些信息记录下来可以，设计师偶尔可以挖掘到一些闪光的设计点。
  
 除此之外，用户的屏幕记录也是一种方式，通过用户的屏幕、加上用户操作的动作，表情，可以真实还原用户的使用场景，方便后期的分析。
  
 录像和录屏的操作比较难进行，主要的设备可以参考如下【5】，具体可以查看相关的链接：
  
 ·摄像机：记录动作和部分表情
  
 ·眼动仪：可以追踪眼球的焦点轨迹，不适合移动端
  
 ·鼠标轨迹记录：记录鼠标轨迹，只适用于PC端
  
 ·QuickTime (iOS)：仅记录屏幕
  
 ·Mobizen (Android)：记录屏幕、手势
  
 ·Display Recorder (iOS)：手势、声音
  
 ·SCR (Android)：记录屏幕、手势、表情、声音
  
 ·Magitest (iOS)：记录屏幕、手势、表情、声音
  
 ·Mobizen +AirDroid (Android)：现场观察并记录手势、表情、声音
  
 预测试是正式实施可用性测试前的一次模拟， 模拟有助于发现问题，这时候邀请同事即可。把正式测试的流程走一遍，包括设配的调试、访谈切入、问题的提问、记录者的记录等，然后把记录的录音、视频等放出来看看效果如何，效果不如意的时候再进行调整。
  
 总之，预测试可以帮助发现问题，包括以下几个方面的问题：
  
 ·设备的问题。举个例子，录音设备放置的位置会影响录音的效果。
  
 ·测试脚本的问题。测试问题是否足够清晰。
  
 ·访谈的切入以及问题的提问。
  
 ·记录者的记录。
  
 发现问题之后去解决问题，才能使正式测试的时候达到更好的效果。
  
 测试前的接待工作是测试人员对公司的第一印象，给测试人员留下一个好印象、一个好心情有利于可用性测试的进行。所以在这里将一些注意点说一下。
  
 首先，可以事先确认一下用户的行程。遇到刮风、下雨、下雪等恶劣天气的时候可以事先送上问候短信。
  
 其次，遇上用户迟到的情况下，也要保持克制。在迟到五分钟到十分钟之后再给用户电话询问情况，如果用户因故取消测试，也要保持友好的态度。
  
 在接到用户之后，送上一杯温水或者温热的饮料，然后让用户等待一下。最后可以有专门的人员先和用户聊聊天，可以打听一些事情。
  
 正式开始之前有个暖场介绍。首先主持人做一下自我介绍，然后介绍一下测试的目的和时间，需要向用户强调测试的对象是系统，希望用户可以畅所欲言。如果有录音或者录像，需要向用户告知会有此类行为，但是结果完全保密。最后还需要签署保密协议。
  
 正式提问分两个部分：个人信息的小问题和可用性测试任务问题。
  
 小问题主要是为了让用户有个适应的过程，可以迅速进入状态。一般可以询问产品使用习惯、产品偏好、上网情况等，之后的测试问题就是主要的可用性测试的问题。这里需要把问题放入到场景中，让用户在场景中去完成任务。或者可以询问用户的使用习惯，然后引导到脚本中的问题。需要注意的是，不一定要按照脚本的顺序提问，可以随机应变，所以主持人要非常熟悉脚本的内容。除了询问，聆听之外，主持人还要观察用户的神情以及动作，遇上用户有疑问的表情的时候可以适当穿插新的问题，但是尽量不要提供帮助，也不要指出用户的错误或指责动作太慢，但是可以询问用户“为什么这么操作”，必要的时候可以选择停止任务。
  
 测试过程中还需要有一个记录人员，记录人员需要记录：用户做了什么动作和步骤（重点）、用户说了什么、写下自己的疑问（适当时候可以进行提问或者让主持人提问）。
  
 测试结束之后，主持人可以问一下用户的想法，同时让记录人员补充提问，所有问题结束之后，需要对用户表示感谢。送上礼品并接受用户的一些交通费报销票据等。最后要把用户送到公司门口。
  
 测试结束之后，如果有时间可以立马进行整理，因为时间越短，整理出来的内容就越丰富。必要的时候，可以用录音或者录像来辅助。在撰写测试脚本的时候还有一份总结大纲，根据大纲来整理内容。大纲要具备灵活性，可以记录一下测试现场发现的新问题。
  
 记得只是整理而已，每个测试结束都会有一份整理的资料。最后需要汇总多份可用性测试总结，最终出具一份可用性测试结果，根据这份结果进行相应的改进工作。
  
 我们可以从如下几个维度去分析我们的可用性测试【8】（维度之间可能有交叉）：
  
 a)任务完成度。每个测试任务都对应一个目标，只有当用户达到目标之后，我们才认为他们完成了任务。对于每个任务，用户完成的情况如何？有多少用户最终没能完成任务？多少用户需要在主持人提示下完成任务？多少人可以自行完成任务？这些都是很重要的指标
  
 b)致命错误。严重错误指那些阻碍用户完成任务的错误，这些错误非常重要，每一个都要得到足够的重视。
  
 c)非致命错误。非致命错误是指用户能完成任务，但是某些地方会有一些阻滞，会停顿或者思考的错误。这些错误相对来说没那么重要，不过如果发生的次数较多，该类错误也需要得到重视。
  
 d)完成任务的时间。每个任务需要完成多少时间，决定了交互设计流程和界面的设计是否足够友好。
  
 e)主观情绪。用户对于任务的主观感受，比如是否足够简单，是否容易找到信息，可以让用户衡量一下。
  
 f)偏好和建议。可以让用户说出产品中哪些地方很喜欢？哪些地方不喜欢？或者让他们提一下建议。
  
 
  
  
 【1】Adaptingyour usability testing practise for mobile http://www.userfocus.co.uk/articles/testing-for-mobile.html 
  
  
 【2】移动可用性测试(一):概述 – 腾讯ISUX–社交用户体验设计 http://isux.tencent.com/mobile-usability-testing-one.html 
  
 【3】网易公司用户访谈活动招募问卷 http://survey.askform.cn/51194-79597.aspx 
  
 【4】用户访谈心得总结– 腾讯CDC http://cdc.tencent.com/?p=5690 
  
 【5】移动可用性测试（三）：现场测试– 腾讯ISUX– 社交用户体验设计 http://isux.tencent.com/mobile-usability-testing-three.html 
  
 【6】用户研究经验谈-采铜学心录-博客大巴 http://xuexinlu.blogbus.com/c4061443/ 
  
 【7】简单快速的可用性测试|网易用户体验设计中心 http://uedc.163.com/4151.html 
  
 【8】Planninga Usability Test Usability.gov  http://www.usability.gov/how-to-and-tools/methods/planning-usability-testing.html

8. 「方法」如何进行“可用性测试”

 作为初入行的产品经理，在研发过程中，我们是不是经常会遇到下面这些问题：
   为了改善产品，让产品更容易使用，我们常常会使用一种高效的方法——可用性测试。   我们通过观察有代表性的用户完成产品的典型任务，从而找出产品可用性问题，并解决这些问题。
   下面，让我们来看一下这种方法的具体操作步骤。
   可用性测试主要有两种形式，分别为形成式和总结式。
                                            注意：可用性测试和优化越早越好，这是一个不断迭代演进的过程。 
   输出物：测试方案、测试脚本
   前期准备：准备工作越充分，测试结果越有说服力
   在测试前，我们需要明确本次工作的目标是什么，梳理清楚重点要关注的问题，提前做好计划，然后再将测试目标和关注点转化为测试任务和访谈问题。
   常见的测试目的有以下几类：
   当确定了目标以后，就要开始撰写测试方案了。提前准备好测试方案，有利于后续工作的高效开展。
   一般，一份完整的可用性测试方案由以下几大板块组成：
   和剧本一样，我们要提前设计好脚本，给用户找点事儿做，通过观察、提问等方式，获得我们想要的信息。
   下表只是一场测试的基本脚本概要，可供大家参考。
                                           脚本中的测试任务是重点板块，任务最好融入场景。场景是经过前期调研得出的，符合真实用户使用场景，而不是“想象中的”。
   任务的设计要场景化，从用户的角度出发，明确任务起点和终点，并且，尽量让用户锁定在主要的任务上。
   在正式开始前，我们需要根据测试目的来确定招募什么样的用户，找出与测试目标有关的筛选维度，特别考虑用户使用行为相关的特征，例如竞品使用经验、使用产品的目的、用户的活跃程度等。
   从这些维度中挑选出最核心的几项，转化成用户招募的条件，并尽量客观化、具体化、可衡量，避免设置交叉条件过多，导致样本代表性降低。   另外，我们要学会辨别真假的用户信息。
                                           ①待测试产品素材
   ②辅助测试工具，如：
   ③设备：笔记本、手机、纸笔、摄像机、录音笔、桌椅
   如果对测试质量要求比较高，旁听和观察人数比较多，需要采集丰富的数据，那么最好到专业的测试实验室进行。
                                           如果测试时，观察人数较少，公司条件有限，也可以在普通会议室进行测试。
                                           为了保证测试流程顺畅，在正式测试前，我们一般还会找个人来进行预测试。按照方案设计的流程进行走查，记录可能出现的问题，并及时调整测试流程。
   输出物：测试记录、录像录音
   测试参与人员：
   有了充分的测试准备后，我们只要严格按照测试方案，引导用户进行产品的使用测试，并详细记录问题点，一般只需要1个小时左右，就能完成一场正式测试。
   输出物：测试报告
   在测试完一个用户后，要给自己留出半小时做一次小结。测试结束的当天，要与产品团队或设计师当场讨论重要问题，之后再总结分析报告。
   报告中主要分析的内容有以下4点：
   除此之外，还可以围绕关注的问题，对未满足的需求进行补充分析。
   发现了这些可用性问题后，我们需要对这些问题进行分类和优先级排序，以便安排之后的修改迭代。
   可用性问题优先级的衡量维度一般可以分为：影响程度、频率、持续性、产品优先级等。
   最后，我们要对分析的结果进行报告撰写，报告的呈现形式视项目大小而定，如PPT、Excel等。
                                                                                   最后再来总结一下。
   可用性测试的操作步骤：    第一步：测试准备。 准备的越充分，测试结果的可信度就会越高。    第二步：正式测试。 在测试过程中，尽量让用户在放松的情况下使用产品，根据方案脚本引导用户执行操作。    第三步：结果分析。 写报告之前，一定要跟团队成员商讨问题点，避免信息盲区而导致的分析偏差。
   根据以上步骤，产品经理可以从真实用户中快速收集可用性问题，优化产品。
   如果大家在执行过程中有任何疑问，欢迎留言交流。