**修订历史
| 版本号 | 作者 | 内容提要 | 发布日期 |
|---|---|---|---|
| V1.0 | 内部测试方案初稿 | 2019/09/17 | |
| V1.1 | 新增测试计划、测试工具包，细化测试执行 | 2019/09/20 | |
| V1.2 | 调整方案目录，优化模糊描述 | 2019/09/23 | |
| V1.3 | 输出测试报告 | 2019/10/09 |
1 测试目标
通过对 Handy2.0 Android 版本进行内部测试，评估本次改版是否达到预期，产品设计是否符合用户使用习惯，是否存在使用障碍，以期优化用户体验。
2 关注点
- 产品整体印象：新老用户对改版后的 Handy 2.0 使用情况的整体满意度。
- 用户使用习惯：由 1.0 的横屏操作切换至横竖屏兼容模式，用户是否能够较为平滑的迁移使用习惯。
- 功能逻辑和页面跳转：对整个产品的功能逻辑是否存在认知障碍或者学习成本过高；页面跳转是否能让用户清晰理解，并能够自然的操作。
- 页面布局：测试目前的页面布局是否合理，重要信息、操作项是否突出，是否存在认知歧义或偏差。
- 交互流程：操作过程是否顺畅，不存在太多干扰和障碍。
3 研究方法
为了科学量化用户体验，我们引入了一些用户研究中的通用方法和经验：系统可用性量表、**协作启发式评估**。
如果您想了解更多用研方法的选择过程，推荐阅读本文附录中的相关内容。
4 用户招募
- 招募方式：公司内部招募
- 招募要求：使用安卓手机（Android 版本6.0以上）的用户
- 样本数量：
- 根据尼尔森关于可用性测试的经典理论，6-8人便可以找到产品80%以上的可用性问题
- 8个人可以80%的概率发现发生可能性大于18%的问题
- 总体规模10万以上和10万所需要的样本量并没有什么区别
- 扩展阅读 谈谈样本量选择背后的科学道理
5 测试计划
| 时间 | 事项 | 交付物 |
|---|---|---|
| 2019/09/17 | 制定测试方案，设计典型任务流程 | 测试方案；典型任务流程 |
| 2019/09/18 | 讨论测试方案，招募用户及沟通 | — |
| 2019/09/19 | 细化测试流程 | — |
| 2019/09/20 | 测试准备，预测试 | 测试工具包 |
| 2019/09/23 | 测试执行，记录收集，邮件致谢 | 用户体验问题记录表；系统可用性量表 |
| 对问题进行汇总分析，评估优先级，讨论解决方案 | — | |
| 测试报告撰写 | 最终测试报告 |
6 测试准备
6.1 测试工具包
在测试过程中，除了测试方案，还需要一些辅助材料。
- 测试场地（会议室）
- 软件安装包（ Handy2.0 和录屏工具）
- 典型任务流程、评估原则表
- 备用测试机（预装 Handy2.0 和录屏工具）
- 纸质量表、笔
6.2 预测试
邀请身边同事预演测试计划，根据问题调整测试计划。
7 测试执行
测试执行包括接触测试者，进行宣讲，用户自行评估，收集测试结果。
| 流程 | 项目 | 内容 | 时长 | 注意点 |
|---|---|---|---|---|
| 1 | 暖场 | 打招呼、简单介绍产品背景和测试目的 | 2min | 强调只是测试产品，测试者无需紧张； 录屏留存的一些操作技巧，打消测试者对于隐私的疑虑 |
| 2 | 测试说明 | 测试流程和注意点说明，宣讲评估原则 | 10min | 鼓励用户尽可能多的反馈信息； 强调评估原则是更好的协助，而非限制 |
| 3 | 简单试用 | 测试者进行简单使用，了解一下产品的总体印象（如未预先安装录屏工具的测试者，可由发起人现场协助） | 3min | 只询问测试者的第一印象，避免展开细节讨论 |
| 4 | 测试阶段 | 测试者完成典型任务 | 20～30min | 测试者可现场完成评估，也可自行评估后将结果返回 |
| 5 | 问题收集 | 对测试者完成的问题记录表、评分结果、录屏数据命名编号，整理归档 | ||
| 6 | 测试结束 | 对测试者邮件致谢，感谢对方的参与与支持 |
8 测试总结与报告
*扩展阅读：
通过SUS系统可用性量表知道产品的整体体验处于什么水平。 通过协作启发式评估知道产品的用户体验存在哪些问题。 通过可用性原则知道了如何避免出现体验问题。 通过问题归类分析知道哪些模块迫切需要优化。
系统可用性量表（System Usability Scale）
什么是SUS
SUS（系统可用性量表）最初是 Brooke 于1986年编制，量表由10个题目组成，包括奇数项的正面陈述和偶数项的反面陈述，要求参与者在使用系统或产品后对每个题目进行5点评分。
何时使用
- 同一产品或系统，新旧迭代版本的对比。比如：某 App 改版后，新旧版本的对比。
- 同一产品或系统，不同终端之间的对比。比如：某产品的PC端、App端进行比较。
- 同类型竞品之间的比较。
为什么使用SUS
- 量表公开且免费。
- 量表题目陈述简单，只需参与者打分，实施起来很快。
- 测量结果是介于0-100之间的分数，容易理解。
- 可测量多种用户界面，比如网页、手机、平板等。
如何使用
- 当测试者完成一系列任务后，就可以快速对SUS进行打分。
- 收集得分后需要对每个题目的分值进行转换，奇数项计分采用“原始得分-1”，偶数项计分采用“5-原始得分”。由于是5点量表，每个题目的得分范围记为0~4（最大值为40），而SUS的范围在0~100，故需要把所有项的转换分相加，最终再乘以2.5，即可获得SUS分数。
- 除了获得SUS量表总分之外，还可获得分量表得分。SUS中，第4和第10项构成的子量表为“易学性”（Learnability），其他8项构成的子量表为“可用性”（Usability）。为了使易学性和可用性分数能够与整体SUS分数兼容，范围也是0~100，需要对原始分数进行转换：易学性量表转换分数的总和乘以12.5，可用性量表乘以3.125。
如何通过评分看出一个产品的好坏？
上图是一个评分参考，通过数据得出，系统可用性量表最终算出的评分达到70分左右，就可以比市面上一半产品可用性要好，也就是说这个产品的用户体验算是合格了**。
协作启发式评估
为什么是协作启发式评估而不是启发式评估？
启发式评估是一种简易的可用性评估方法，由几名交互专家以角色扮演的方式，来完成设置的任务给出评估结果。优点是成本低、便捷，缺点是我们团队中往往缺乏交互专家。
我们决定用协作的形式来进行评估，不需要交互专家，可以是用户、需求、设计、测试、前端、运营等，只要愿意参与测试即可。我们将尼尔森的十大可用性原则扩展衍生出了更加浅显易懂的21条可用性原则，以此对照，任何没有用户体验知识的人都可以参与到协作启发式评估中。
**
尼尔森的十大可用性原则 — 21条可用性原则
尼尔森的十大可用性原则是用户体验设计的重要参考标准。从1995年提出到现在，互联网世界发生了巨大的变化。为了针对当前产品提出更加全面的启发，我们借鉴京东设计团队在用户体验提升模型中的实践经验，将其抽象成视觉呈现、界面设计、导航设计、信息设计、交互设计、信息架构、功能规格、内容需求八个维度的通用准则，更易理解和掌握。
如何使用
- 为了使测试环节更加灵活高效，我们借鉴了异步远程可用性测试的方法：现场宣讲或邮件告知背景信息及评估原则，测试者根据典型任务流程进行操作评估，且通过录屏工具，将自己的操作记录下来，评估完成后，将评估结果邮件发送发起人。（测试者亦可填写纸质表格，由发起人统一收集）
- 问题汇总后，通过小组讨论进行归类分析，研究解决方案，评估优先级后纳入后续迭代环节。
若有收获，就点个赞吧
0 人点赞
