测试目的
明确做本次可用性测试是为了验证或者获取什么信息，以目标为导向，首先确定要测试的产品是什么，希望得到什么样的结论或预期，并确定产品测试的范围。
举例本次真实可用性测试场景。
本次作业产品可用性测试的目标是：为了验证作业模块的用户体验是否能满足老师在工作中轻松获取作业学情，是否有违反用户交互体验的问题，是否可以在日常工作中常态化使用，帮助用户降本提效。
新用户的用户目标是全新产品带来的学习和使用成本，包括两类：
- 没经验：对类似产品0使用经验，新手学习成本足够低；
- 有经验：对类似产品有使用基础但没用过我们的新产品，使用成本不比竞品高。
对于老用户的用户目标：用过类似产品，不可忽视且必须额外要考虑对老用户使用习惯的改变。
原则：
- 功能完整性：模拟用户任务流，主流程和常见分支流程有支撑不阻塞；
- 产品易用性：流程走通的前提下，操作步骤尽量少，认知成本尽量低。
确定参与测试的工作人员，有的公司有专业用研，可以用研同学带着相关产品和设计一起进行。若没有专业用研，负责该项目的产品和设计同学也可以独立进行，周期在1-2周，可以空出独立时间，也可以穿插在日常工作中。
由于我们公司没有专业用研同学，每次可用性测试都是产品和设计一起主导并完成，整个测试工作安排如下：
- 第一天：产品同学负责联系运营寻找样本，并分配给各个组，平均一组4-5位用户；设计同学撰写测试评估样本和任务卡片。
- 第二天：每个小组收到分配到自己手里的用户进行拉群，和用户沟通并确认时间，熟悉测试流程和测试任务。
- 第三、五天：开始进行测试，一组两人，一个担任主持人，一个担任观察者。平均一天2-3位用户，一位用户用时30分钟-1个小时，访问结束及时进行总结整理。
- 第六天：大家分模块进行总结梳理。
1. 测试脚本
为了防止在测试访谈过程中迷失方向，要提前制定好访谈大纲的结构和关键要点，增强对整个访谈的把控感。提前写好测试评估脚本，标注任务流程、任务要关注的重点以及预估时间，可以保证我们在进行测试中更好把握测试节奏。
测试脚本包含：主持人大纲（测试前访问热身、基本信息提问、正式测试任务、体验访谈）；观察者大纲（根据主持人大纲同步整理，观察并记录用户完成任务过程）。
2. 招募用户
用户数量在6-10名用户参与，一般这个数量就能够发现测试里的80%的问题，继续找更多的人结果也是差不多的，需要确定使用你产品的用户群体，选择用户尽量选择沟通意愿强、愿意思考发声的用户。
招募用户的途径可以找公司内部渠道资源进行招募，像B端产品用户是特定属性，通常可以联系公司和用户的接口人进行招募。也可以自行在社会上招募，C端产品可以在公开平台发放招募问卷，或者找自己身边的亲朋好友进行测试。
