自己动手做可用性测试---------读书笔记--《妙手回春：网站可用性测试及优化指南》

把书通读了一遍，书中主要讲了两个大的方面，一个是阐述作者对可用性测试的立场和观点，一个就是介绍这种快速的可用性测试方法。

作者的观点是应该尽早进行可用性测试，在开发过程的早起就可能发现严重的可用性问题，哪怕这个时候可以展示的东西很少；并且是尽一切可能让单位内部更多的人参与进来亲临现场观看测试。

 

文中没有讲各种测试方法，只介绍了一种简单、非正式、小样本的DIY可用性测试方法，也称打折的可用性测试。

 

对网站或者产品进行可用性测试，无非有两个目的：1 让自己的产品变得容易使用；2 证实自己的产品确实容易使用。而DIY可用性测试，并不是为了发现绝大部分的问题，而是只想发现一些可以修复的问题。

 

书中给出了整个测试工作各个环节的详细介绍，具体如下：

 

一：招募测试参与者

 

（1） 用什么样的人进行测试？（有一定常识、善于表达和交流的人）

在可用性测试初期，网站或者产品可能存在大量严重问题，这些问题几乎任何人都会遇到，因此开头可以非常宽松的招募参与者，等到产品逐步完善的时候，再想办法招募贴近目标用户的参与者。

选择能够代表目标用户的人进行测试并没有看起来那么重要，而且招募起来此类用户也没有那么简单。

很多最严重的可用性问题与领域知识毫无关系，而与导航、网页布局、视觉层次等相关----就是那种几乎任何人都会遇到的问题。

 

（2） 需要多少参与者进行测试？（每轮测试3名）

      前三位参与者就很可能会遇到测试任务里面最重要的那些问题；

         与最大限度的利用每一轮测试相比，多做几轮测试要重要的多。每次3名参与者，更容易多做几次测试；

          测试三名参与者可以使测试和总结的工作在一天内完成；

         

（3） 到哪里寻找参与者？（到要找的人经常活动的地方去）

      网站、朋友、家人、同事、邻居，甚至是网上的陌生人，主要看测试的任务和类

型是什么样子的。

  

（4） 发出邀请

      将测试的主题、测试地点、测试时间的长短，以及招募者的联系方式（最好是

邮箱）、姓名、合适的联系时间都发布出来。

 

    （5） 遴选最合适的参与者（通过电话简短交流）

      核实测试当天他们有没有时间参与测试；

      核实他们是否具有所需的资质；

    测试期间录像，时间大约是多少；

　　告诉他们将会获得什么报酬；

    判断他们是否是优秀的参与者：能不能接受发声思维？是否善于表达？

   

（6）后续措施

     给核实的参与者发送招募邮件，确定时间安排并提供详细信息：

     前来测试地点的行车路线（自驾和公交线路）；

     在哪里停车；

     测试房间的具体位置；

     因突发事件不能前来时能联系到负责人的电话或者联系方式；

     保密协议（如果有的话）在测试之前阅读。

 

（7）储备备用参与者

     可以到场的任何人：公司另外一个部门的人或者其他公司的员工；

     可以远程测试的“真实用户”；

 

 

二：挑选测试任务并撰写测试场景

 

（1）制定一个任务清单（要反应用户的实际目标）

     拿出纸笔；

     列出访问者需要在你的网站中完成的5~~10件最重要的事情。

 

（2）确定测试哪些任务

     决定因素：哪些任务至关重要?

               哪些任务让你晚上睡不着？

               其它用户研究表明哪些功能可能不容易使用？

 

（3）将任务变成场景

     就是将有关任务的简单描述转换为参与者能够阅读、理解并遵循的脚本；它指

定了参与者的角色、动机、需要做的操作及一些细节；

     场景的措辞必须清晰、明确、易于理解，而且不要使用生僻的语言；

     编写场景的真正困难只有一个：就是在场景中不要提供线索。

 

（4）设置约束条件

     为了保证测试工作的效率和质量，要限制参与者进行与测试任务不相干的操作

：比如不能离开本网站、不能使用网站内部导航等。

 

（5）对场景进行先导性测试

     确保场景清晰、完整、明确。

     通常，在正式测试前一两天进行先导性测试。

 

（6）将场景打印出来

     每张纸一个场景，供参与者使用；

     将所有的场景打印在一张纸上，供负责人和观察者使用；

 

 

三：测试工作前后需要核对的清单

 

    在主持诸如可用性测试这样的活动时，有很多事情必须在特定时间进行，而且有

很多细节需要跟踪；而检查列表可以让你不会错过每一个事项，尤其是那些每个人都

可能忘记的东西。

 

（1）三周前

     确定要测试什么：网站、线框图还是原型？

     制定要测试的任务清单；

     确定要用什么样的参与者进行测试；

     发出招募参与者的广告；

     预定一个测试房间：能上网、一张办公桌、两把椅子、免提电话、一上午的时间

     在测试房间附近找一间休息室，供参与者到达后就坐并等待。

     预订一个观察室：能上网、一张办公桌、多把椅子、免提电话、屏幕和投影仪；

     预定一个会议室，供总结和午餐使用。

 

（2）两周前

     从项目小组和相关人员那里获取有关任务清单的反馈；

     准备参与者的报酬，例如订购礼券、申请现金等；

     开始遴选参与者并为他们安排测试时间；

     发送带“日期安排”的邮件，邀请小组成员和相关人员参加测试。

 

（3）一周前

     给参与者发邮件，其中包含行车路线、如何停车、测试间的具体位置、迟到或

者迷路时与谁联系（电话号码和姓名）以及保密协议（如果有的话）等信息。

     安排备用参与者以防有参与者缺席；

     如果是第一轮测试，安装并测试屏幕录制软件和屏幕共享软件。

 

（4）一两天前

     致电参与者再次核实，并询问他们是否有问题；

     发邮件提醒观察者；

     完成场景的撰写工作；

     对场景进行先导性测试；

     获取测试所需的用户名/密码和样本数据，即账号和网络登录名、虚构的信用卡

号或测试账户。

     复印要分发给参与者的材料：录像许可表、场景、保密协议；

     复印要分发给观察者的材料：可用性测试观察者指南、场景清单、测试脚本；

     招募参与者接待人员；

     招募观察室管理员，并提供观察室管理员指南；

     确保准备好了给参与者的报酬；

     确保配备了USB麦克风、外置扬声器、延长线以及用于存储屏幕录像文件的U盘；

     为观察者订购点心和饮料；

     核实测试房间和观察间没有被他人预定；

     找一位专门的接待员，负责接待参与者领他们休息、等待或者去测试间。

（5）测试当天（第一场测试前）

     订购总结会午餐；

     将观察者需要的材料放到观察室；

     确保将要测试的东西安装到了测试计算机上，或者能够通过网络进行访问，并

且运行正常；

     测试能否与观察室共享屏幕（包括视频和音频）；

     关闭测试计算机中任何可能会打断测试的程序：如电子邮件、即时通信、日历

活动提醒、病毒扫描等；

    为测试期间要打开的所有网页创建书签；

    确保知道可能需要用到的电话号码：观察室、测试房间、接待员、开发人员（

以防遇到原型方面的问题）、IT部门（以防遇到网络或者服务器方面的问题）；

    确保观察室和测试房间的免提电话正常。

 

（6）每场测试前

    删除浏览器历史记录；

    在web浏览器中打开一个中立网页，如google。

 

（7）参与者在录像许可表上签字时

    启动屏幕录制软件。

 

（8）每场测试结束后

    退出屏幕录制软件；

    保存录制文件；

    如果必要，结束屏幕共享；

    记录观察到的一些问题；

    如果最后是当天最后一场测试，且使用的是台式机，将屏幕录像文件复制到U盘

 

 

四：主持测试（共60分钟）

 

     （1）主持人的职责

          导游—--负责吩咐参与者做什么，但是不会回答关于网站的任何问题；

          治疗师----负责让参与者在执行任务时用语言描述其思维过程。

         

          通过观察参与者如何使用产品并了解他们的思路，可借助别人的眼睛来看待自

己的网站，而这些人并不像你那样了解网站；这让你能够获得通过其他任何方式都

无法获得的设计洞察力。

 

    主持人避免怯场的方法：

练习宣读脚本、

                          在没有压力的情况下练习测试。

 

    （2）欢迎环节（4分钟）

     宣读脚本的第一部分作为开始，它解释了接下来的测试将如何进行。

 

（3）提问环节（2分钟）

     通常在测试前后，都可以问参与者几个问题，

目的：让参与者放松；

      向他们表明你将仔细倾听；

      获取相对评分法需要的知识。

 

（4）主页观光（3分钟）

     让参与者首先浏览主页，是判断网站的特征是否明显.

 

（5）执行任务（35分钟）

     执行每项任务前，需要把场景描述递给参与者，并逐字宣读；

     参与者开始执行任务后，尽可能不要打断他们。只需要让他们将精力集中在任

务上，并进行发声思维，直到进入下一项任务为止。

 

    如何判断什么时候进入下一项任务：

            参与者完成当前任务了吗？

            参与者是否情绪低落？

            还剩下多少时间？其他任务重不重要？

            还能得到有价值的信息吗？

 

（6）问题探讨（5分钟）

     在参与者执行任务期间，是可以让参与者做些简要的澄清，但是更深入的问题

，应该记录下来，等到探讨阶段再问。

    并且还要打电话询问观察室的观察员有没有什么想问的。

 

    （7）道别（5分钟）

     向参与者表示感谢、询问他们是否有问题、给报酬并将他们送到门口。

 

（8）准备下一场测试（10）

     在休息时间：

做些记录；

重置计算机设置；

根据上一场的测试情况考虑要不要调整测试方案。

 

（9）关于远程测试

     为什么进行远程测试-----方便：

                     招募参与者更容易；

                     无需往返；

                     更容易安排时间；

                     效果几乎相同；

 

　　 如何进行远程测试：远程测试跟的各个方面几乎与现场测试相同；

 

             不同之处：脚本需要修改；

                       报酬需要寄给参与者；

                       必须决定共享谁的屏幕；

 

     效果：相当于提供现场测试80%的好处和70%的效果；

     用途：常规的可用性测试；

           非常适用于需要快速回答却不值得包含在月度测试中的问题；

           非常适用于急需知道答案的问题；

           适用于在修复问题后进行的重新测试，因为脚本已经写好，很方便。

                 

 

五：总结和交流

 

   （1） 总结的目的：测试中发现的最严重问题的清单

                     下个月测试前要修复的问题清单

 

             总结会应该在测试完毕后立刻进行，此时每个人都还对测试过程记忆犹新

，并且只有前来参加了测试工作的人才有资格参加总结会议。

   

   （2）现实要面对的状况

    任何网站都存在可用性问题；

    任何单位为了修复可用性问题而投入的资源都是有限的；

    总是有问题因为资源有限而无法修复；

    现实工作中，很容易因为去解决那些容易解决但是并不严重的问题，而导致了最

严重的问题得不到解决。

    因此，必须集中火力解决最严重的问题。

 

（3）如何判断问题的严重性？

             很多人都会遇到这个问题；

             给访问者带来严重的后果，还是只会带来不便？

 

（4）如何主持总结会？

           首先阐述总结会如何开---就是选出10个最严重的可用性问题，然后确定

它们的优先级，并就下个月要修复哪些问题达成一致。

    让每个人从记录的问题清单中，选出三个自己认为最严重的问题；

    让每个人把自己的选择大声念出来；

    将每个人选择的问题贴到白板上，然后大家投票从中选出10个问题；

    讨论解决这10个问题的优先级，必将解决方案记录下来；

    让小组讨论下个月如何修复每个问题，并且尽可能的要简单；

    讨论到下个月可以用来修复问题的资源已经排满了。

  

   （5）撰写测试总结报告并将报告邮件给相关人员

               测试的对象；

               参与者执行的清单；

               根据会议讨论决定下个月要修复的问题清单；

 

 

六：关于可用性问题的修复工作

 

（1）       修复问题时，尽量以少的改变达到最大的修复效果

原则：微调，而不是重新设计

                   微调的费用低；

                   微调的工作量小，能更快的完成；

                   细微调整得以实现的可能性更大；

                   大刀阔斧的修改，可能会破坏其他原本运转正常的东西；

                   大多数人都不喜欢变化，重新设计会让人感到气愤；

                   重新设计意味着同时做大量的修改，必将增加复杂度和风险；

                   重新设计涉及到大量的人，需要开很多的会，牵扯更大的资源。

 

            做减法

                  删除分散用户注意力的内容，效果会更好。

 

（2）得出的可用性问题为什么没有得到修复？

               管理层变更、发展方向变更或者两者都有；

               工作被推迟----修复的工作量比预期的多；

               没有获得所有相关人员的足够支持；

               心有余而力不足---不切实际的选择了过多要修复的问题；

               问题有更深层次的原因----着手修复时，出现更严重的冲突；

               最重要的是各种干扰：处于各种原因，可能没有时间、资源和决心。

 

 

有一种将可用性测试进行分类的方法，看它是定性的还是定量的；

 

定量测试中，目的是为了证明某个结论,由于要进行证明，因此定量测试有点像科学实验：必须严谨否则结果将不可信。这意味着定量测试必须制定完备的测试方案，并且要严格按照测试方案测试所有参与者；必须仔细收集数据；必须有足够大的参与者样本，以确保结论具有统计意义。

 

而DIY可用性测试是定性的，它不是要证明什么结论，而是让你获得用来改善产品的洞察力。DIY可用性测试不用那么正式，也不用那么科学。只需要主持人和参与者坐在一起执行测试任务并进行发声思维就可以了。

 

我们采用的工作方式是敏捷开发，每个月就有两个迭代周期；按照书中的理论，每个迭代都应该进行对本迭代完成的产品功能进行可用性测试，并对上个迭代修复的可用性问题进行验证测试.

简洁、高效的可用性测试工作，将为我们的软件开发工作保驾护航，是打造完美软件产品的必不可少的工作之一。