安装的可用性测试

　　安装现在是大多产品一个很大的问题，由于计算机业分工越来越细，一般来说一个产品很难单独使用，需要其他一系列的产品辅助才行。这就造成了安装上的极大困难，甚至出现几天才能搭建一个环境的情况。安装的可用性测试就是验证产品安装对用户来说是否足够简单，包括：

　　* 安装的操作简单，尽量通过鼠标点击就可以完成安装；

　　* 安装的说明准确并易于理解；

　　* 安装过程中应有帮助说明，在用户不明白的情况下给与足够清晰的指导和说明；

　　* 安装完尽量已经完成配置，免去用户配置的复杂性；

　　* 安装中有依赖其他软件的，应给与提示，并可以提供所依赖软件的安装，或者提供足够的安装信息。

　　如果产品安装非常简单，在 1 分钟内安装完成后，环境也自动配置好了，包括所有所需软件的环境，那肯定会受到用户的好评。

　　配置的可用性测试

　　现在产品越来越多的配置，有基于 XML 的，基于 Property 文件的，基于编辑器的。配置带来产品灵活性的同时，也带来了可用性问题。配置的可用性测试是验证产品配置对用户来说是否足够简单易用，包括：

　　* 配置集中化。现在产品配置步骤繁多，大都需要配置多个地方，多个文件，如果其中一个没有配置就会导致所有的配置不起作用。建议能用一个配置，尽量不用两个配置；能在一个文件，尽量不要分散在多个文件中。

　　* 配置向导化。配置也好，调整也罢，你需要告诉客户都要做哪几步配置，在哪里配置，怎么配置。现在大多数的配置需要在成千上万页的文档中查阅，然后一一对应，有时候配置的顺序还有关系。建议如果有多步的配置，采用向导的方式，一步一步的指导用户完成正确配置。

　　* 配置验证性。用户配置了许多的配置，配置完了，大多产品不给用户足够的反馈结果，提示配置是否出错，出什么错，哪里出错。而需要用户在运行环境按经验去找错，看 log, trace。结果好不容易找到了，兴许也就是一个很小的大小写的错误。用户兴许会想，都是自己不小心，怪自己疏忽。但作者认为这是设计开发人员的可用性错误，不注重可用性的今天，用户帮着承担了。建议：用户的配置应及时甚至当场就提供给客户反馈信息，提示用户配置的结果，如果配置错误，应提供足够的错误信息，哪里错误，出什么错，有什么解决方法。

　　文档的可用性测试

　　文档的目的是让人学会使用产品，可用性的最高境界莫过于连文档都不需要了，如傻瓜相机，虽然也带了文档，但由于其易于操作，用户无须知道光学原理，焦距，曝光就可以使用，而很少有人去查阅文档。对于文档的可用性测试，应该保证文档尽量简单易读。下面是文档可用性的几个实践：

　　1. 能用视频少用图片，能用图片少用字。现在用 Flash 视频教学是非常流行的一种教学方式，尽量多用一些 Flash 视频的教学方式，如果没有视频，也尽量多一些图片，产品截图等。

　　2. 多一些例子，比如 Struts 框架提供了 show case 等一系列例子，教导用户如何开发和使用技巧，这些比纯文字的文档形象直接，效果更是不可同日而语。

　　3. 文档中尽量少用缩写，除非是人尽皆知的缩写，如 IBM, EJB 等词语。如果需要使用缩写，需要在一些地方标记出全名。