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

　　例如，某软件产品的核心初始化模块需要开发一个配置文件内容的引用功能。我们如何来以用户为中心设计一个有价值的场景呐?

　　第一步，我们将该功能的用户进行区分，发现该功能非常具体且细化，而与此功能有实际联系意义的用户主要是基于此软件进行二次开发的软件开发技术人员和软件生产环境下的运营维护人员。基于对用户分类的定义，发现他们分别属于最终用户和合作用户。所以，通过结合软件二次开发技术人员的视角，我们得出第一步的结论：使用该产品的二次开发的技术人员可以在系统初始化过程中使用配置文件的引入功能，将其他的配置信息引入到主配置文件之中;通过结合运营维护人员的视角，我们得出第一步结论：使用该产品的运营维护人员可以在系统初始化过程中使用配置文件的引入功能，将其他的配置信息引入到主配置文件之中。

　　第二步，明确指出该用户场景分别能够给他们带来的价值。通过结合软件二次开发技术人员的视角，我们得出第二步的结论：使用该产品的二次开发的技术人员可以在系统初始化过程中使用配置文件的引入功能，将其他的配置信息引入到主配置文件之中，最有效地实现配置信息的复用，避免配置信息的重复使用，提高组件的模块化，并且不会对初始化过程产生性能影响。通过结合运营维护人员的视角，我们得出第二步结论：使用该产品的运营维护人员可以在系统初始化过程中使用配置文件的引入功能，将其他的配置信息引入到主配置文件之中，实现配置文件的分级分层管理，避免大量配置信息在单一文件中的堆积，优化配置文件的管理效率。

　　可用性测试的范围

　　在实际的软件开发过程中，测试人员是产品的第一个使用者，可用性测试包括从需求调研到产品设计开发到文档和安装等多个环节。这小节作者介绍可用性测试的范围，并根据所参与产品 (WebSphere Multi-channel Bank Transformation Toolkit , BTT) 开发过程中的一些实践所得和体会，介绍软件可用性测试包含哪些方面以及内容。

　　作者从从四个方面介绍可用性测试：需求的可用性测试，设计的可用性测试，开发的可用性测试，安装的可用性测试，配置的可用性测试，以及文档的可用性测试。

　　需求的可用性测试

　　作者认为需求的可用性是最重要的一项，因为这是后面所有其他可用性的前提。没有正确的需求，就犹如路和方向就是错误的，那尽管在这条路上走的多好，多稳，也不会通向理想的目的地。所以，可用性测试就是要注重 Identifying the right product，也强调 outside-in development。做正确的事情，说起来简单，但做起来是最为困难和艰险的一件差事。在这里一步走错，就会导致整个产品全盘皆输，因为产品定位和需求都错了，那再如何努力开发和测试也是枉然的。

　　设计的可用性测试

　　设计的可用性包括架构和设计的可用性以及界面设计的可用性。架构和设计可用性是指架构和设计方法的逻辑性和合理性，并且是否符合主流的架构模式和设计模式。良好的架构，应该是采用标准，结构清晰，一目了然，并层次分明的。架构逻辑性、层次性依赖于架构师的功力，业内有一些最佳实践和标准，是值得大家去遵循。

　　界面设计可用性是指系统和用户进行很好的交互。根据作者经验，界面设计的可用性测试至少要验证系统符合下面这些点：

　　信息清晰原则。尽量少用缩写，除非你的缩写已经众人皆知，比如像 PPT 这样的词语。但像 VC=Verification Code，这样的缩写应尽量避免。

　　可视性的设计原则。用户界面的操作尽量让人一看就知道如何操作，而不用记忆或查阅文档。如，界面中隐含操作顺序而不用用户牢记;用星号标记出必选项等。产品界面是否好用用户第一次使用，或者用户很长时间不使用后重新使用，他是否能够很方便的进行使用很关键。好的设计无需用户记忆，在设计中隐含着可视性的提示，便于用户完成操作。

　　限制性原则。尽量限制在界面上的用户错误操作。界面上应屏蔽用户当时不能输入的输入框等，尽量不让用户操作会引起错误的界面元素。限制错误的操作，指示正确的操作，只给用户一条正确的路，用户就能无需去判断错误，容易的完成操作。

　　反馈原则。反馈是控制科学和信息理论中的一个常用的概念， 其含义为： 向用户提供信息， 使用户知道其某一操作是否已经完成以及操作产生的结果。在界面设计时用户输入信息时，界面上应该能验证输入信息的正确性，并提供反馈信息给客户。

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