随着数字化转型的到来，用户体验也成为了一个银行人不可忽视的方面。不知道你作为业务经理、程序猿或者设计狮时，会不会困惑于系统的功能操作是否合理，交互是否流畅，视觉提示是否能够引起足够注意等问题？
由于这些人员对自己的产品和功能的流程、设计等方面过于了解，往往无法客观判断其可用性，这时候就需要对实际用户进行可用性测试。
那么什么是可用性测试呢？请跟着我们一步一步来看~
什么是可用性测试？
可用性测试，虽然是一种测试，但并不是传统意义的测试人员来做，而是让一群具有代表性的用户对产品进行典型操作，同时用户研究员和其他与系统相关的人员（开发、设计、测试人员等均可）在一旁观察，聆听，做记录的方法。这里我们提炼出它的3个特征：
1、邀请真实用户使用原型或成品：通过真实用户的使用来评估产品的技术。
2、观察、记录用户的感受和体验：挖掘改善及提升产品可用性的方法。
3、适用于产品发展的各个阶段：包括前期设计开发阶段到后期优化改进阶段。做可用性测试价值在于能够在不同的阶段更加高效的发现问题，从而提高问题解决效率。
可用性测试的步骤?
可用性测试包含了3大阶段16个小步骤：他们分别都是什么呢?
别着急，我们举个栗子来告诉你~
一、准备工作
1、制定测试范围、测试目标及目标用户
（1）定义测试目标和范围
——确定需要测试的产品（服务）及测试范围
小农小银准备优化手机银行理财产品购买的功能，希望看看目前的原型构想是不是符合用户体验。
在这次可用性测试中，理财产品的首页、购买、赎回等功能是此次的重点，小农小银想看看用户是否可以顺利找到相关功能并流畅操作。
（2）定义目标用户（此处举例：比如手机银行的常用用户）
小农小银分析了后台数据，根据用户的年龄、学历、收入、理财习惯等方面，进行了用户分类，分为了重度使用的用户、轻度使用的用户以及潜在使用的用户。
2、招募测试用户
大量的可用性测试实践证明，5名参与者即可发现75%以上的问题。通过增加参与者数量来发现更多的问题意义不大，所以我们基本选择5-7名参与较为合适。（也可根据实际情况少量上下浮动）
小农小银找到了95599的小伙伴，帮自己搜罗了2个忠实的理财购买用户，2个总买农银时时付的用户，又找了2个自己的朋友作为小白用户。
3、选择测试任务、拟写任务测试脚本
小农小银针对这次可用性测试立刻制作了手机银行理财功能可用性测试协议书；提问者大纲（包含测试前声明、基本信息提问、发声练习、正式测试任务、体验访谈等内容）；记录者大纲（依据提问者大纲同步整理，观察并记录用户完成任务的过程）；还有满意度问卷。
4、确定可用性测量维度
小农小银决定要用上定量、定性两个维度来测量。定量上，他们准备记录用户们操作任务完成时间、任务操作成功/出错次数；定性上，他们准备访谈用户对测试的整体评价及满意度情况。
5、准备测试物资、组建测试团队
小农小银打印好步骤3里的相关材料，准备好了测试使用的手机银行。因为我们还没有可用性测试实验室，所以他们就选择了普通的会议室和录像设备。
小农是资深的用户研究员，他主要负责与用户沟通、拟写测试脚本和数据分析；而小银资历稍浅，他主要负责协助记录测试要点、招募用户并且进行一些测试现场的支持。而业务员、程序猿、设计狮和测试等项目相关的小伙伴们就等着新鲜出炉的录像啦。
二、实施测试
终于要开始测试了，小农和小银如何成功的执行这次测试呢？
1、预测试环节
小农小银检查了全部的访谈脚本，对测试手机和录像设备也进行了进一步的确认，看看是否存在什么问题，做好了各类风险的初步预估。
2、接待用户
小农小银终于见到了6名被测者，他们核对清楚了用户信息后，引导他们进入休息区等待测试的开始。在等待的期间，他们发放了可用性测试协议书，让用户仔细阅读并签字，告诉他们此次测试的目的、告知个人信息保密性及同步测试后可获得的积分权益。然后被测者就一个个开始测试啦。
3、测试前声明
小农作为资深的用研，深知在可用性测试开始的时候，要帮助用户卸下紧张。他用亲切的语气和笑容对第一个被测者说：
“你好，李明，我是小农，我会和你一起进行这个测试。你可能已经知道了，不过还是让我解释一下为什么今天让你来这里吧。我们正在测试手机银行的理财购买功能，因此想看看真正有人使用它的时候会是什么样子。
我现在要明确的是，我们在测试这个功能，不是你本人，在这里你不会犯什么错误，实际上，这是一个你完全没必要担心自己会出错的地方。我们想知道你是怎么想的，所以请别担心会伤害到我们的感情，我们想要改进这个APP，因此我们想知道你真实的想法。
一会儿我们进行测试的时候，我会要求你把心里的想法说出来，告诉我们你是怎么想的，这对我们有很大帮助。”
4、发声练习
被试者往往在开始的时候不习惯边操作边说出自己的想法，所以小农小银，会先带他们做一个简单的发声练习。
小农：“请在执行每一步操作时，尽量用言语描述出你当前的感觉和想法。比如:你准备要做什么，你正在找什么和你做了什么决定等等，任何想法都可以说出来。用自然的方式就可以，就像日记里写流水账，不需要刻意去思考或者思考太多。最后在您认为任务已完成或者您觉得无法完成的时候，告知我“完成”或者放弃“我放弃”
你的回答没有对错之分，希望你能充分表达自己体验产品时的感受。如果你有问题，就尽管问。我也许不能马上回答这些问题。因为我们想知道如果没有别人在旁边的时候，你会怎么做，但是测试结束以后，我会设法回答任务你还不明白的问题。
我们有很多任务要做，我会尽量保证进度，不过我们也会尽量保证让这过程生动有趣。”
5、正式测试任务
在正式测试任务中，我们要做到任务解释清晰到位、任务节奏和内容要良好掌控。不要让用户随意尝试。对任务的难易程度要有初步的评估，并给到心里预期，如果用户遇到了问题，在测试结束后要及时沟通，找到发生的原因。让我们来看看测试中的小片段：
小农：如果你打算买一笔理财，你会先做什么？
李明：我想先看看上面这排理财类型
小农：然后你会怎么做？
李明:我不太明白这个结构化的意思，（在犹豫点击哪个），我现在不太肯定该怎么做，我觉得还是点定期保险一点,但是我不知道这个定期和我在银行存的定期存折一样不一样。
小农：那么你觉得你会点击哪个?
李明:我还是点这个定期先看看吧。
小农：点它试试看。
6、体验访谈
体验访谈的目的在于对测试做一个补充提问。此外，对任务执行过程中遇到的问题也可以进一步沟通，定位发生的原因并做好记录。
7、用户填写满意度问卷
测试结束后，需要邀请用户填写满意度问卷，对测试进行简单的评价，做好信息反馈与总结。
小农：李明，你已经完成了所有的测试任务，非常感谢!最后，希望通过几个问题了解一下你在整个过程中的感受如何:
请阅读下表中的描述，并判断这些描述是否符合你的感受，在对应的符合程度下打钩。你可以使用1-5之间的数值来表示你对这些描述的认同程度(1代表”非常不同意，5代表“非常同意”)。
8、核对测试收录的内容及信息
在用户离开前，需要确认是否所有任务都已完成，测试记录的相关信息是否都已完整收录，尽可能的避免出现任何的遗漏。
三、总结分析
1、信息整理
测试结束后，首先需要对测试结果进行数据处理与分析，及问题的归纳总结。
2、结果总结与分析
用户找不到需要的功能或字眼？——信息框架、内容分类要不要调整？
用户对体现的内容不明白？——没有使用用户理解的词汇？
用户总是在同样的地方操作错误?——提供的操作控件太复杂或不符合用户习惯？
……
3、测试结果沟通与反馈
可用性测试的最后就是与需求、开发等各方做进一步的沟通：给出具体的改进方案和后续规则。至此，一次可用性测试才顺利完成。
以上就是可用性测试的大致介绍，或许目前仅仅在C端产品使用的会比较多，但实际有很多B端产品也应该使用可用性测试，帮助我们更好的了解用户的真实困惑与需求，从而让项目相关人员提出更优的方案，提升产品的效率。希望我们的银行产品在这些方法下越来越贴近用户的感受，成为更温暖的产品。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
