您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 其他相关 > 正文

可用性测试的实施详解

发表于:2019-04-08 作者:当前位置出发 来源:简书
  可用性测试是通过观察有代表性的用户,完成产品的典型任务,从而界定出可用性问题并解决的过程。通俗地讲就是“观察用户使用产品”。
  可用性测试到底测的什么?
  a 有效性(独立完成任务的比例)
  b 完成任务的时间
  c 满意度(用户主观评价操作难易/好感/是否再次使用的意向)
  d 发现可用性问题(如,用户使用中表现出的挫败感/没有看到该看到的内容/说自己完成任务但实际并没完成/偏离成功的操作)
  可用性测试的类型
  a 形成式:让用户出声思考;小样本;不作定量对比;适用短平快地发现问题
  b 总结式评价:评价目标达成率、任务完成时间、用户主观满意度;大样本;可对比评估;适用多在上线后的、大个版本的对比
  可用性测试要趁早
  纸面原型,axure,低保真或者高保真都可,甚至可以拿竞品作可用性测试。
  破除完美主义或者靠后期大数据的内心OS, 忌拖延或者不使用可用性测试。早发现问题,能让产品少走弯路。
  可用性测试可解决的问题:
  发现体验上的问题;
  检验期望的设计目的是否实现,是否满足用户期望;
  了解用户的使用习惯,了解用户的认知;
  对产品进行评估,用户是否满意
  如何进行可用性测试
  1. 确定测试任务
  也就是给用户找点事做。测试任务反应用户的实际目标,而不是我们期望用户做的事。
  1.1确定任务清单,来自产品or交互提出的需要测试的任务点
  1.2把任务转化为场景,用用户的语言,有一些情景的细节,以便让用户融入测试中。eg:“周末在家无聊,你想在云阅读上逛逛,看看最新有没有感兴趣的书籍”
  1.3 在每个场景下列出具体的用户任务和探寻点。要注意的是,这写任务不能框定得太死,直接告诉用户具体的操作步骤,而是观察用户会注意到哪些信息点,会进行哪些操作。
  如:任务1 打开云阅读,浏览首页 ;任务2  在书城里寻找一本自己感兴趣的书籍
  2. 招募用户——典型而有代表性
  确定招募标准,想要招募什么样的用户,要有什么产品的使用经验、用户的细分和配比、人口学特征、所需的态度(有使用需求)和行为特征(eg 性格外向,最近没有参见过相关调研等)
  筛选方法:可以通过问卷来筛选用户。
  用户数量:五个用户能发现大多数可用性问题
  哪里招募:公司内部,亲戚朋友,用户池,现有用户,产品论坛
  邀请用户:正式的邀请的短信
  约定时间:列好时间排期表
  3.预实验
  测试用户测试本身。检查访谈指南的台词、用户完成的时间,以及任务说明是否包含暗示(是否有非常容易完成的任务)
  4.测试前准备
  会议室/测试机/问卷/demo/ 记录纸/便签
  5. 测试流程
  暖场-测试前访谈-执行-测试后问卷-感谢酬劳-初始化
  5.1 暖场:自我介绍;解释测试的目的和时间;强调测试的对象是产品而不是用户;请用户尽量“发声思维”;告知用户会录像;签署保密协议
  5.2 测试前访谈:了解用户的职业、上网情况、产品使用情况、平时的产品偏好
  5.3 测试执行:宣读任务,整个过程中不纠正错误,不提供帮助,适当鼓励,仔细观察和聆听用户的建议,适当简单追问“为什么刚才这样操作”(帮助用户习惯出声思考)
  观察重点:用户是否独立完成任务;若独立完成,则是否在过程中做了无效操作或者有不知所措的情况;是否有不满的情况,用得不舒服的页面。
  记录重点:行为和动作;用户的想法(通过操作步骤来反应);问题(用户说的)。要记录问题,而不急于寻求答案
  问题探讨:在测试过程中打断用户或者在最后询问用户。询问整个过程中想深入但没有问的问题;询问观察的同事关心的问题
  及时记录:趁记忆犹新记录下来。可以巧用便利贴,每张便利贴记录一个独立的现象(用户操作/建议/抱怨),在左上角写任务编号,右上角写用户编号,此现象对用户完成任务的影响写在最下方。
  尽可能地把有话语权的人参与进来。做到隐形的观察者,只观察页面发生了什么或者用户说了什么,不动、不说、不看,不把观察等同于分析。
  5.4 测试后访谈
  如果在操作用的提问会对操作产生较大影响,就要避免中途打断,而在事后访谈补全信息。另外还可用use量表(共30项)和as形容词量表对用户的满意度进行评估。
  5.5 感谢
  5.6 初始化,后一个用户不要受到之前操作的影响。
  6. 测试分析和测试报告
  找出要马上要修复的问题。召集相关人员召开会议,可以用便利贴贴在白板上进行讨论,并准备存有录像的笔记本,在存有争议的时候调取录像。
  6.1 便利贴的张贴并且分类  可根据关键词/相关性/位置/任务等进行分类
  6.2理清不清晰的区域
  6.3给问题评优先级。只对严重的10个问题修复
  问题的严重性可以通过以下四点进行衡量:是否产生严重的后果?可克服程度?出现的频率?是否是重要任务或者步骤?
  6.4结果存档,确定要修复哪些问题
  记录问题出现的页面/元素、截屏、问题名称、问题描述和分析、建议、问题维度、优先级等级、出现该问题的用户。