1、2018 可用性测试方法工作总结百度百科对可用性测试的定义：让一群具有代表性的用户对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。该产品可能是一个网站，软件，或者其他任何产品，它可能尚未成型。测试可以是早期的纸上原型测试，也可以是后期成品的测试。 定义可以说是很贴切了，近期对移动端的售后功能改版进行了可用性测试，借此机会进行下总结，反省下不足，吸收下学习到的经验。 1.适合可用性测试的场景 产品的开发前、中、后期，产品上线后，都可以用可用性测试做支持，大致能使用到的场景如下： 新的产品，需要验证是否符合用户需求 功能发生变更，包括不限于操作路径、功能入口、视觉变化 此次移动端
2、售后改版主要是基于此种类型，交互、视觉、部分功能页等与之前版本均有较大的差别，为了解用户的体验感知进行了此次体验调研 新增了比较复杂的功能，需要看用户的接受度和完成度 存在争议的问题，交互、视觉、功能等；或多种方案不能确定使用哪一种的 2.可用性测试前期准备 需求收集 可用性测试之前，需要和业务方、系统设计者（产品经理）、运营等角色收集需求，我们自己也会有需求，收集各方意见后，下一步要做到的是整理需求，考虑到可用性的测试时间长度和任务难度，需要将重点、难点问题梳理。 不能覆盖全部问题的情况下，要有侧重点，我认为全部问题点都测试并不好，需要用户关注的点特别多，用户就会产生混乱。下面会详细讲。 任
3、务设计 任务设计是整个过程中非常重要的一环，整个测试是围绕着设计的任务展开的，设计任务需要注意的包含下面内容： 结合需求及目的设计场景化任务： 不能简单粗暴的问用户 XX 功能您觉得怎么样，要把用户放到实际的场景中，让用户去解决问题，让用户在模拟的真实测试环境中再去吐槽他发现的问题。比如告诉用户已经买了 XX 商品，收到压坏了，需要在 APP 上申请换货 任务覆盖范围： 在需求收集时有提及，可能有很多需求、测试点；本次测试中，虽然已经精简了任务，但是需要用户操作的依然内容多，所有任务又是围绕售后单一类型进行操作的，存在的问题是，一方面前面的任务训练了用户，对后面的操作产生了已经熟悉的影响；另一
4、方面，用户发现的问题点重复，习惯了的操作可能不会再提出其他有效建议。 所以一定要控制好测试任务数量，需要有取舍。这次测试为了让同一对象，体验全过程，设计了 9 个任务，时长 90 分钟，觉得可以尝试缩短时长，减少任务量；任务数量实在多的话，分成两场，增加测试人数或许不错。明确场景化任务中关注细节点： 关注重点有主有次，在设计任务时，调研者需要了然于心关注点，在用户操作或吐槽时，对用户行为或想法进行深挖 资料准备 会议室：因为现在的职场没有专业的访谈室，需要提前预定固定的、比较安静的环境与用户沟通 测试机及网络：安卓与苹果手机各准备一部，尽可能减少环境变量，与用户使用手机系统保持一致。网络需要留
5、意，测试机要调试好网络，本次测试第一场就出现了测试机连不上网的情况；录音笔也要提前准备好，有遗漏信息录音笔可以会听，也可以用来分享 测试环境：这个环境不是指真实环境，而是指与测试任务匹配的 APP 实际场景环境，或者打印还原的场景，这个动作可以放在完成任务设计后再开始准备。 测试环境需要创造，比如这次售后测试，因为需要分别创造刚提交未审核服务单、可以催促的售后单、查询售后退款等环境；服务单提交后要与客服沟通不能审核、尽量减少对客服指标的影响；可以催促的单子难控制，必须超过一定时效，要匹配约到用户的时间提前申请等等，需要把任务和时间表高度结合来创造合适的环境 礼物准备：目前部门内部主要是赠送用户
6、京东 E卡，后续可以考虑比较有特色的礼品，比如等值音响等；另外觉得礼品的发放顺序可以提前，先让用户签收，可能会让用户更放松。 保密协议：可能会涉及关键信息，需要用户与我们签订保密协议 测试脚本及记录表： 脚本中包含任务场景及访谈内容，脚本需要把任务场景顺序、测试关注点、研究员执行的工作、需要追问用户等等细节点梳理清楚，帮助研究员理清思路，也帮助记录员了解测试详情。记录表按照操作顺序及关注点设置就行。 用户招募 首先要明确的是，招募的对象应该符合什么条件，比如性别、职业、年龄、经历等，一般招募的是实际用户。 这次招募招募的途径主要是： 微信公众号投放招募问卷 各种朋友圈、同事的人际圈、朋友的人际
7、圈招募 已经招募到的用户再次推荐 各种微信群 招募的人数怎么定？可以看下尼尔森集团从 83 个可用性测试项目中汇总的数据，5 个用户能发现 85%的产品可用性问题，12 人发现的问题基本能覆盖全部，随着人数的增加，发现的问题数量并没有随之增加。所以一般测试招募 5-12 人差不多。 预测试 预测试也是在测试开展前很重要的一环，按照真实与客户沟通的场景，执行预测试，预测试能起到的作用很多： 调整测试顺序：设想的任务操作和实际可能不一致，预测试能帮助发现顺序问题 控制测试时间：预测试的时间过短多长都能反馈我们测试任务数量及细节方面的问题，需要根据预测试的时间取舍任务或者分场次执行 测试任务设计的环
8、节：可以通过预测试参与者反馈的不通畅、不舒服的环节进一步调整任务，修改访谈脚本。 时间和对象允许的话，尽量多做几场预测试。 3. 实际测试执行 参与人员 一般情况下，需要主持人、记录员、被访者 3 人，也就是测试员最好 2 个，最多不要超过 3 个。围观用户可能会让用户紧张而表达不顺畅。 可用性测试整个过程是主持人和被访者沟通的过程，有其他工作人员在场有被打断或插话的风险，如果有其他产品经理等参加，一定要提前沟通好只能旁听。 其他部门有多人旁听的需求的话，也是建议轮流来，不能全部去参加。 暖场 可以基于接下来的测试场景，询问用户的基本情况、使用场景。 要让用户知晓，并不是要对用户测试，他反馈的
9、体验问题无关对错，我们希望多听听他的意见。 测试执行 用户在具体场景操作时，可以让用户遍操作，遍描述自己的行为、发现的问题 研究员需要注意，不能立即对用户的行为和疑问进行解答。用户不知晓怎么操作时，需要鼓励用户去尝试；用户有疑惑时，需要做的是挖掘用户觉得有疑问的原因。注意观察用户，多听用户发声、多看用户操作；当用户吐槽、惊讶、出现重复操作等情况时，若用户没有主动表达，切记主动询问用户原因。在操作过程中，用户若是给出好的意见和建议，要及时鼓励和夸奖用户，给用户正向的反馈。即使用户任务失败，也不要让用户产生挫折感。 场景化评分：由于测试任务是实际场景，可以请用户在每次任务结束后对整体体验的满意度、
10、费力度、易用性进行打分。（提前准备打分表） 测试记录 用户行为： 包括是否完成、操作费力情况、操作路径、有没有出现错误或重复动作。 用户的反应也很重要，比如用户的惊讶，可以去了解一下原因。 切记，不要引导用户，尽量多观察和记录。 用户意见； 可以让用户遍操作边说出自己的想法，发声思考。 若是用户是静默操作，研究员需要去询问用户在看什么想什么为什么这么评分满足自己的需求了吗等问题，让用户把想法尽可能表达出来 4. 结果分析及报告输出 分析时间 最好趁着访谈完，花半小时的时间将记忆犹新的东西整理处理。 结果内容 现状描述 通过满意度、费力度、完成度评分可以了解产品的可用性水平，操作路径、用户日常行为习惯可以对比产品易用性 问题总结 总过可用性测试，发现的问题，可以通过统计问题频次严重等级，将问题进行优先级排序，把问题罗列和表达清楚 以上是这次做完可用性测试的简单总结吧，有自己感受到的、有学习前人的经验的，仅供参考。
