最近在工作中做了不少的可用性测试，抽空闲的时间总结一下自己的心得，以下是我们团队展开可用性测试的步骤与方法。
列举任务清单并排序
这是可用性测试的第一步，你需要根据产品的功能列举出需要进行测试的任务，列举完后再回头与功能进行对比，看列举出来的任务是否覆盖了需要测试的所有功能。以短信举例，列举 的任务如下：
发一条短信
查看一条短信并找到短信的详细信息
删除一条短信
接下来对列举的测试任务进行排序，测试任务的顺序要尽量符合典型用户的典型行为习惯，还是以短信举例，人们对短信的一般操作流程是，打开短信—查看短信—删除短信。测试任务的顺序也需要按照这样的行为习惯来。
设计测试任务
设计测试任务是整个可用性测试过程中最重要的一步，任务描述的合理性会直接影响到测试结果的真实性，那么到底怎么来设计测试任务呢？下面以短信来举例的测试任务描述：
1.发一条短信
描述：今天是你妈妈的生日，你现在想给她发一条短信表达你的祝福之情。
2.查看一条短信并找到短信的详细信息
描述：你妈妈昨天给你发了一条短息但是你没有看到，现在你想要找到那条短信并看看是什么时候给你发的。
3.删除一条短信：
描述：收件箱短信太多了，导致你手机内存满了，你需要删除一部分垃圾短信。
设计任务时需要注意的几点：
弄清楚用户的需求以及产生该需求的场景：设计测试任务时必须先弄清楚用户的需求以及需求的场景，这样你设计出来的任务才能将被测试的用户带入实际的场景中去。比如说一个客户经常到偏远的地方出差，这些地方的网络条件很差，几乎无法访问你的产品，于是你为该用户提供了一个离线访问的功能。客户的需求就是能在网络较差的情况下访问产品，而产生该需求的场景就是客户经常到偏远的地方出差。
根据需求场景来描述测试任务：描述任务的时候需要根据实际场景和需求来给任务加一些剧情，剧情不要太复杂和啰嗦，这样会增加测试者的理解和记忆负担。
设计测试任务时尽量避免基于功能的任务描述：还是拿短信来举例，如果你这样描述“请你用这个工具发一条短信”，这样的描述看起来并没有什么不合理的地方，但实际上它把测试的重点指向了发短信这个功能上了，它不包含实际场景，不能反映出用户的实际需求与目标。必须记住，任何需求都是产生在某些具体的场景中，在设计任务时你必须反复拿这个任务来问自己，“这个任务是否反映出了实际用户的目标与需求呢”。
在任务中不要包含任何会引导用户操作的线索：产品中的术语，操作行为等等都会给用户提供任务线索。“你妈妈今天生日了，你现在打开短信创建一条新信息发送给你妈咪，祝你妈咪生日快乐”，“打开短信创建一条新信息”就成为了明显的任务线索。
将你认为用户可能出错的任务做一个特殊标记：为什么要这样做，因为有时候用户完成一项你认为比较难以理解的任务可能是由于巧合，这项任务虽然做对了，但是他的理解可能与你设计的本意相差甚远，这个时候你必须追问他为什么会这样做，他是怎么理解的。
总结
设计测试任务时必须要抓住“人”、“情景”、“目标”这三个要素，这三个要素一定要在你的测试任务中体现出来，最终的描述形式就是“谁在在什么情况下要做什么”。
寻找合适的受试用户
在设计好测试任务后，现在就该去找参与测试的用户了，众多研究表明（当然我还没有研究过.5个测试用户就能发现80%的可用性问题，我们公司在做测试时一般都是12个，原因是因为我们需要把这些定性的数据量化成数字，这样有助于帮助我们判定什么问题比较严重，什么问题必须得改。这样也能有效地避免团队间意见分歧的问题。如果说没有量化的需求，建议5个就够了。
什么是合适的受试用户：如果是新产品就得根据用研时创建的persona去寻找合适的用户了（我还没做过一个完整新产品的测试，这里就不多讲了.。对于已经有用户量的产品来讲，测试者应该由真实用户和对产品陌生的目标或者非目标用户来组成。为什么会有对产品陌生的用户以及非目标用户呢？
其一，在大环境下，人的行为存在着惊人的一致性，如果说你的设计存在严重问题那么谁都能测出来。
其二，对产品熟悉的用户已经掌握了产品的某些行为，他们的行为习惯完全不同于新手用户，在测试这些人时他们可以凭借自己使用该产品的经验克服一些可用性问题，所以说某些问题测试他们是测试不出来的，不熟悉产品的目标用户或者非目标用户就能弥补这一块的问题。当然，如果你测试的任务必须要该产品的专业用户才能理解的话就必须找实际用户了。
展开可用性测试
1.资源配置
如果资源足够，测试过程中一个人扮演主持者，一个人扮演记录者，如果资源不够，这两个角色由一个人来扮演也是可以的。测试的过程必须得录屏和录音，在条件允许的情况下还可以对测试过程进行录像，以便后面对用户的行为进行分镜式分析。当然，还有更加专业的测试工具，比如说眼动仪，还有一些可以记录用户行为并将其转换成热力图的软件。这些工具和软件中小型公司一般都不会配置。
2.调节测试氛围
大部分的测试者在参加测试时都是紧张的，他们会担心自己无法完成测试任务等等。比如说前几天进行了一个测试，在把测试者请来时他就一直在不停的说“哎呀，找我测试呀，我做不来怎么办呀，我很笨的”。所以说，展开测试的第一步是缓和测试的氛围，消除被测试者的紧张情绪，你需要向他表明本次测试的目的。
3.开始测试
这个过程中需要做到“一看”、“二记”、“三问”、“四听”
看与记：整个过程中需要认真观察用户的操作过程，对用户有疑问、迟疑、困惑的地方进行记录。
问与听：用户完成一项测试任务后，需要问他在这个任务的过程中有没有碰到难以理解的地方，如果有，需要追问用户为什么难以理解，他最后是怎么理解的。如果你观察到用户在某个地方产生了迟疑 ，需要问用户为什么会产生迟疑，比如说，“我刚刚看到你在点击发送短信时犹豫了很久，你为什么会在这里犹豫呢”。在这个过程中你需要认真倾听用户的意见，并肯定用户的提议，这样会让他得到一种成就感，有利于接下来的测试。
测试过程中需要注意的问题：
测试过程中用户如果有什么想要表达的，邀请他表达出来，如果他太善于表达，需要进行适当的制止，让他回到测试任务上来。
不要以任何方式（手势、表情、语言等.表现出用户正在犯错或者操作太慢，需要明白这不是他的错，是你设计的问题。
用户遇到困难时尽量不要提供帮助，可以适当鼓励用户，比如“你可以在尝试一下”。
多问用户几个为什么，比如“为什么你刚刚会这样操作”、“为什么你会这样理解呢”等等
测试结果统计整理（填入指标表.）
测试过程完成后，这个阶段就是统计测试结果了，如何统计测试结果呢？不同的团队会有不同的统计方式，这得根据自己团队所制定的可用性测试规范来，我们团队是这样统计的（如下图）
分为5个指标进行统计：
“完成情况”
“流畅度”
“具体问题”
“问题严重程度”
“用户预期”
其中最重要的就是具体的问题了，统计时不要只记录一个干瘪瘪的问题，用户遇到问题的具体场景一定要记录下来，这有利于你去分析用户究竟为什么会产生这样的问题，对问题的改进有很大的帮助。
另外，统计时需要注意一下几点：
不要靠自己的回忆去统计，一定要回头去看测试时录制的视频
对用户行为有疑问的地方及时回访，把问题弄明白。
有些问题是你通过观察用户行为发现的，但它似乎不能被计入指标中的话，这时需要另外记录这些问题，在团队讨论的时候提出来（如下图）：
确定需要修改的问题
在将指标统计完后，接下来就是确定什么问题需要修改了。
统计问题产生的概率（如下图）：
将所有的问题列在一个excel表格中，谁出现了这样的问题就在谁下面打勾，然后计算出问题出现的概率，如果有及时的方案，在备注列添加一下。
确认什么问题需要修改（如下图）：
上图是一套判定问题严重性的规范，这个有助于去判定什么问题需要修改以及什么问题可以暂时不用修改。当然这并不能作为唯一的标准，因为它只是一个数据性的参考，实际过程中还需要进行定性的分析，比如说有的问题只有一个用户出现了，但是经过分析这的确是个问题；有的问题大部分的用户都出现了，但是这些问题只是出现在了用户第一次使用的过程中，后面就没有出现过了，改动起来的成本较高，这种问题我们称为可接受的学习成本问题。
修改问题并准备下一次的测试
这个过程就没多少可说的了，修改确定后的问题，然后准备下一次的测试，直到产品方案满意为止。
