敏捷开发中的可用性测试(5)

　　分类原则。这点当界面上的信息多时，尤为重要。把所有信息分类，并把同类的信息显示在一个区域，能非常方便用户浏览信息。

　　差异性原则。用颜色和和字体体现不同的界面元素，如必选项用红色标记，字体用粗体。颜色和心理学和公司或国家常规是相关的，否则会适得其反。

　　逻辑性原则。逻辑上两种元素的结构关系，可以通过界面上的视觉结构体现出来。中的层次结构，如层次包含结构，在界面上应该用缩进、层级菜单等结构体现出来。

　　开发的可用性测试

　　开发规范可用性是在开发的过程中，开发人员编码规范和编码习惯的可用性。好的编码机构清晰，读起来毫不费力，是一种享受。开发规范可用性测试的范围包括：程序代码结构可用性，代码格式可用性，注释可用性，包结构和命名可用性，类名和方法名可用性，变量名可用性等。

　　代码结构可用性在于开发人员不断重构，把代码按照逻辑结构分成不同的包。

　　代码格式可用性一般可以通过编辑器的代码模板和格式器来控制。

　　注释可用性即符合 Java doc 或 .net 的注释格式书写注释。

　　这里强调一点是命名的可用性，不管是包命名，类命名还是变量命名，命名时应该采用能够让人看懂的名字，名字长一些往往更好，尽量少用不清晰的缩写。如：People 对象，应该用 “people” 等能够一目了然的命名，而不是“p” 或 “pe” 等简短不清晰的命名。

　　安装的可用性测试

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

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

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

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

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

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

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

　　配置的可用性测试

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

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

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

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

　　文档的可用性测试

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

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

原文转自：http://www.uml.org.cn/Test/201007084.asp