质优价廉的可用性测试DIY

一如往昔的简洁干练风格，《妙手回春：网站可用性测试及优化指南》甚至连书名的命名方式都与《点石成金——访客至上的网页设计秘笈》相似。而与其他指南类的动则几百页可以当枕头用的书籍不同的是，《妙手回春》甚至可以被归类到“小人书”一类，轻薄的厚度以及相对较大的文字，花上一两个小时就可以的看完，简明的叙事风格、极少的专业术语以及手把手式的教法，即使是非专业测试人员也可以很轻松的理解并执行。

相较于大公司而言，很多中小公司不具备也没有能力去对网站开展专业性的可用性测试，然而也并不是说做不到最好就不去做，没有眼动仪还可以用录屏软件，质优价廉简单明了的可用性测试还是可以获得有帮助的数据。

一个网站的诞生，需要经历从草图到原型到视觉到开发再到上线的过程，当然这中间可能还会在上线前穿插一个测试的环节。但是就是这个叫做“测试”的环节，往往可能会成为整个项目的转折点，各种问题各种BUG在这个环节被曝露出来，而曝露出来的问题可能会造成推翻前面的某一阶段的工作，进而造成整个项目的延期。

那么应该在什么时候开始“测试”呢？


为了避免“集中测试”造成的问题，应尽量将“测试”拆分成始终随着项目一同前进的行为，并不是说时刻都在测试，而是如书中所说，每月拿出一个上午的时间来进行测试，每个上午测试三名参与者，参与者的身份不能与项目有任何关系，以此来提高可用性测试数据的准确率。

越早开始测试，就能越早的发现一些细微的问题，越早发现问题就能越早的修正。当项目开始草图阶段时，试着就开始介入可用性测试，避免在最后时刻的集中测试曝露出积累的过多问题。

做可用性测试时，应尽量邀请与项目相关的人参与，尤其是对项目有着控制权的BOSS！

每次进行可用性测试前，需要先设定场景、任务等一系列的内容，有针对性的测试才能得到更重要更有帮助的信息。每一次测试结束后，都需要产出一个总结报告，当然不是指又臭又长的报告，而是召集参与了可用性测试的相关人员，对他们在观看中发现的问题做一个列表排序，排出问题的优先级，下一步就是着手改造。

当然，下一次的测试就没有必要再进行相同场景与任务以验证问题是否得到修正。

而对于通过可用性测试得出的问题，有时可能需要涉及到很大的改动才得得以修复问题，但在改造前试着分析最小成本的修复方式，面对曝露出来的问题需要的是尽快的修复而不是尽完美的修复，因为没有人有足够的时间和资源来修复所有问题。