可用性测试的测试的方法
所谓可用性评估，即是对软件“可用性”进行评估，检验其是否达到可用性标准。目前的可用性评估方法超过20种，按照参与可用性评估的人员划分，可以分为专家评估和用户评估；按照评估所处于的软件开发阶段，可以将可用性评估划分为形成性评估和总结性评估。形成性评估是指在软件开发或改进过程中，请用户对产品或原型进行测试，通过测试后收集的数据来改进产品或设计直至达到所要求的可用性目标。形成性评估的目标是发现尽可能多的可用性问题，通过修复可用性问题实现软件可用性的提高，总结性评估的目的是横向评估多个版本或者多个产品，输出评估数据进行对比。网站可用性测试包含的步骤有：定义明确的目标和目的,安装测试环境，选择合适的受众，进行测试和报告结果。
软件测试中什么是可用性测试
可用性测试的概念是：让一群具有代表性的用户对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。
可用性有五个指标，分别是易学性、易记性、容错性、交互效率和用户满意度。
可用性测试适于解决的问题：
1） 确定测试产品的可用性水平
2） 与预期目标、与竞争对手、与老版设计相比的可用性水平
3） 比较不同方案，确定哪个方案更加可行
4） 现测试产品的可用性问题
可用性测试
可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题，通常只能做少数几个用户的测试，看他们怎么做，属于典型的定性研究。
它是UGC理念的一种很漂亮的实践，在目的明确的前提下，简单介绍一下主要过程。
首先要招募测试用户。招募测试用户的主要原则是，这些用户要能尽可能地代表将来真实的用户，比如说，如果产品的主要用户是新手，那么就应当选择一些对产品不熟悉的用户。
然后是准备测试任务，测试的组织者在测试前需要准备好一系列要求用户完成的任务，这些任务应当是一些实际使用中的典型任务。
接下来的重头戏是测试过程。可用性测试的基本过程就是用户通过使用产品来完成所要求的任务，同时组织者在一旁观察用户操作的全过程，并把发现的问题记录下来。
测试结束后：组织者可以询问用户对于产品整体的主观看法或感觉。另外，如果用户在测试的过程中没有完全把思考的过程说出来，此时也可以询问他们当时的想法，询问他们为什么做出那些操作。
最后是研究和分析：在可用性测试结束之后，组织者分析记录并产出一份产品的可用性问题列表，并对问题的严重程度进行分级，使得我们可以根据项目进度来选择哪些优先处理。
可用性测试的常见问题与对策
和用户访谈、调查问卷一样，可用性测试也有其特别需要注意的问题。
第一，如果可用性测试做得太晚（往往在产品将要上线的时候），这时发现问题也于事无补了。
其实，可用性测试在产品的各个阶段都可以做。在尚无任何成型的产品时，可以拿竞争对手的产品给用户做；在产品只有纸面原型的时候，可以拿着手绘的产品，加上纸笔给用户做；在产品只有页面Demo的时候，可以拿Demo给用户做；更多的时候，在产品已经可以运行以后，可以拿真实的产品给用户做。不同阶段不同做法，从中都能发现相应的问题。
第二，总觉得可用性测试很专业，所以干脆不做。
可用性测试，听着很专业，但收益又无法量化，所以对很多老板来说，不太愿意在这个上面投入资源，经常因为项目时间过紧被略过。我们知道，可用性测试通常来说做5 个左右的用户才可以发现大部分的共性问题，前前后后的准备也耗时不少，但只做一个用户，并且简化步骤，也比不做要好。
对一个内部使用的用户管理平台，我自己尝试过一次最轻量级的可用性测试，表现为：一个同事，半个小时，在我的座位上，简单的几个任务，比如“将XXX用户的有效期增加一年”，“将YYY公司的状态设置为冻结”，“查询ZZZ公司的员工数”等。结果发现了十几个问题，效率很高。
第三，明确是测试产品，而不是测试用户。
可用性测试要邀请用户来做测试人员，我们在开始之前，应当明确地告诉用户，这个测试的目的是发现软件产品中的问题，而不是要测试用户是否有能力来很好地使用软件。所以，不要让用户听到“可用性测试”的术语，而是说“来试用一下我们的新产品，提点意见”。清楚地说明这一点将有助于减轻用户的压力，使得他们能像在真实环境一样来使用软件。
第四，测试过程中，组织者该做的和不该做的。
刚开始的时候，可以告知用户大概持续的时间，要做哪些事情，让用户心中有数，轻松愉快地完成任务。
可用性测试中，我们可以要求用户在使用产品的过程中采用一种名为“发声思维”的方法，即在使用产品的同时说出自己的思考过程，比如为了完成某个任务，用户想先做什么，后做什么，为什么要做某个动作，等等。
做测试的过程中千万不要有任何的引导与暗示，而只是观察和记录，因为任何引导都可能使得原本可以发现的问题无法暴露。用户行为和预想的不一样时，可以提问，实在进行不下去的时候，给予提示。记住，一切的错都是产品和我们的错，用户绝对没有错。如果真觉得用户错了，那也是你找错人了，不是这个人错了。
结束之后，如有可能应该送个小礼品，当然在邀请的时候就要告诉用户会有一些对他付出时间的补偿。尽快总结，并且发给用户，一方面让用户感到他做了一件有意义的事，另一方面也是表示感谢，建立长期和谐的“用户参与产品设计”的氛围。最重要的，这份总结要用于指导产品改进，这才是可用性测试的根本目的。
可用性测试篇
刚好最近公司的产品要上线了，上线车间工头指定了测试的任务要我来负责，这下硬着头皮整理一下最近可能后面一段时间长期要进行的这一项任务——可用性测试。
结合之前刘津老师《破茧成蝶》里面对可用性测试的说明解释一下可用性测试，作为上线前的测试工作，一般有 可用性测试和结合灰度上线的A/B测试 ，但我们公司的产品属于B端产品，所以选取了可用性测试为主要的测试方法。
其中的“ 用户 ”即为请来的测试人员，这一类人往往是这一产品的代表使用者，是极具价值的目标人群，从他们操作过程中发现的问题往往更具代表和真实性，能获得更准确的结果。对于这类用户的要求是：
其中的“ 使用产品 ”则是通过我们对产品业务逻辑的理解，把具体的业务目标转述成使用目标，使用目标不能提出具体操作，给出工作目标即可，以我们车间生产的产品为例，如“客户来电欲预订下周二中午的酒席，请操作”，不需要具体的操作方法和功能，完整表达产品的逻辑即可。对使用目标的标准是：
“ 发现并处理问题 ”在用户使用过程中，观察用户的操作行为，在进行具体操作时，用户停顿了，有疑虑了，出现了操作的中断、失误，都有可能是产品的易用性缺失导致的，需要对当时的页面进行完整思考，之后再做出可行性的优化，同时，可能统计出来的问题比较复杂和混乱，就需要对出现的问题进行归纳和整理，做出设计和开发上面优先级的排序，以方便后续的优化，归纳依据如下：
开发次序
以上是我们现在操作可行性测试的大概方法，结合实践了很多前辈的经验，由于车间资源不是很充足，所以都是请其他部门的开发同志操作，因为B端产品的特殊性（针对特定群体，需要一定学习成本，产品具有差异化）最终测试也还是取得了一定的成效，结合PDCA式的优化方案，继续进行测试并改进产品，希望大家都能好好打磨自己的产品，完。
