这篇文章，希望整理一些东西，让大家对快速可用性测试（Guerrilla 可用性测试）有初步的了解。
作为产品经理，真的会、也的确是会遇到用户测试的各种问题，如何针对目标实施巧妙、灵活的用户研究，这一定让不少产品、设计师死了很多脑细胞。
可用性测试这个系列，从第一篇 Whatsapp 相关的可用性测试文章之后，到现在将近两个月的时间，我通过翻译、自己撰写，甚至是自己操作可用性测试，不能说是完全掌握，但入门应该是可以了。
这篇文章，希望整理一些东西，让大家对快速可用性测试（Guerrilla 可用性测试）有初步的了解。当然，如果可能的话，希望你能在工作中运用起来，并形成自己的方法。
什么是可用性测试？
从非严谨的角度来说，可用性测试大多是针对用户对产品“可用”和“好用”的测试，而较少的涉及“有用”的测试。我的理解是：“有用”大多是商业价值和市场研究的重点。
当然，如果你是市场研究院或者是战略计划制订者，使用快速可用性测试来达到目的也是可行的。这里有一些实例，能够帮助你了解可用性测试是什么：《6 个实例告诉你：可用性测试究竟是什么？》
从严谨的角度来说——相对的，而且是我自己的理解——可用性测试涉及产品的各个环节，而且相关方了解可用性测试，并且有意而为之的话，会对各环节的相关方有一定的帮助。你可以从《如何激发益相关者开展可用性测试？》这篇文章，初步了解下利益相关方可用性测试。
可用性测试获得的大多是定性的结果，主要是针对用户任务过程中，使用、操作、体验产品的时候的动作、表达等，总结归纳出对产品的简介，从而为后续调整优化产品简历一定的数据基础。
可用性测试的技巧
可用性测试是一种非常流行的技术，或许产品经理、设计师、UX设计师在以各自的理解实践和运用着。它快速、低成本，而且能获得真实的用户反馈。快速可用性测试的实施要从其自身情况决定，但有一些简单实用的技巧能够确保测试产生更好的结果。
这包括：
- 确定目标；
- 注意偏见；
- 让参加者之情；
- 给予奖励；
- 保持真诚；
- 鼓励用户反馈中；
- 参与而不是主导；
- 随时记录；
- 有一个正式的反馈提取过程；
- 按时完成。
你可以阅读《有了这 10 个技巧，做好 Guerrilla 可用性测试不用愁》来详细了解以上这些技巧。
7 步可用性测试
在《Guerrilla 可用性测试：7 步 DIY 属于你的可用性测试方法》一文中描述了，在开始快速可用性测试前，需要和团队一起了解以下 3 个问题：
- 可用性测试如何起作用？
- 从哪去找合适的测试志愿者？
- 什么时候开始测试？
接下来，你可以用这 7 步实施一次可用性测试：
- 第一步：设计任务列表；
- 第二步：定任务优先级；
- 第三步：将任务设置在场景中；
- 第四步：开始测试；
- 第五步：发现问题；
- 第六步：解决问题；
- 第七步：再次测试、验证，形成常态。
如果你觉得实施过程中依旧存在一些问题，希望你能阅读下《如何像专家一样针对原型进行可用性测试？》。文章中，对原型前的可用性测试、招募用户、撰写任务描述、原型保真度等做了详细的讲解。
可用性测试任务描述
测试过程中任务描述（或者说测试脚本）也对测试有重要的影响，任务描述、尝尽设置的优劣，对测试有不可忽略的影响。如果任务不对，你做什么都是错的，当然可用性测试也不会收到什么有效的反馈。
在《Guerrilla 可用性测试：7 步 DIY 属于你的可用性测试方法》中，你应该对可用性测试的任务有了一定的了解，文中还举了几个什么是好、一般和不好的任务例子。而在如何把可用性测试的任务描述写的更好？中，比较详细清楚的介绍了如何写出更好的可用性测试任务描述，你不想了解下？
具体操作
在实施快速可用性测试的具体操作过程中，需要测试多少用户，才能满足测试的目的呢？
《可用性研究中要测试多少个用户？》和《做可用性测试时，只需要5名用户参与测试就够了》两篇文章中对快速可用性测试用户数量做了阐述，精心设计可用性测试无疑是浪费资源，最佳的结果是测试用户不超过 5 个用户，在测试过程中尽可能多地采用小测试。
在早先的研究中，Tom Landauer 和我表明，在 n 个用户的可用性测试中发现的可用性问题的数量是：N (1-(1- L ) n )。
其中： N 是设计中可用性问题的总数，L 是测试单个用户时发现的可用性问题的比例。 L 的典型值为 31%，在我们研究的大量项目中取平均值。
绘制 L = 31% 的曲线得出以下结果：
曲线中，最引人注目的事实是：零用户给出的洞察数为零。
只要你从一个测试用户那里收集数据，洞察数就会出现，你已经学会了近三分之一的知识来了解设计的可用性——零和即便是一点点数据之间的差异是惊人的。
当你测试第二个用户时，你会发现这个人和第一个用户做了一些相同的事情，所以你掌握的东西有一些重叠，人们是完全不同的。所以从第二个用户那，也会有一些第一个用户那没有的新的东西出现，所以从第二个用户那也会增加一些新的洞察力，但不像第一个用户那么多。
第三个用户会做很多事情，这些事你已经从观察过的第一个用户或第二个用户那观察过了，甚至有些事情你已经看过两次了。此外，第三位用户当然也将产生少量新数据，这些数据仅是第三位用户产生的。
来自《做可用性测试时，只需要5名用户参与测试就够了》。
如果你想了解有关卡片分类测试以及定量研究测试的测试用户数量，推荐阅读以下两篇文章：
《卡片分类法解析：究竟要测试多少用户？》
《定量研究：需要测试多少用户？》
案例
整个系列中的最后一部分是案例，开始的时候我提及了 WhatsApp 的案例，后面我又补充了一些其他的案例，以加深对快速可用性测试的了解和运用。
案例主要有：
《WhatsApp Web 端应用可用性测试》
《Guerilla 可用性测试案例之一：Airbnb 愿望清单功能》
《Guerilla 可用性测试案例之二：Dropbox 照片功能》
《快速可用性测试案例之三：Apple iCloud 照片共享功能》（自测并实施）
《快速可用性测试案例之四：Yelp 提升 Web 体验》
