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

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

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

　　可用性测试的最佳实践

　　实践一：Persona

　　现在产品有功能测试、集成测试和性能测试等阶段。但很少产品有单独的可用性测试阶段，也很少有可用性的 Defect。鉴于可用性的重要性，作者觉得很有必要增加一个产品的可用性测试阶段，用于提高产品的可用性。这个阶段中，测试人员对上面介绍的产品各方面进行可用性测试，并开相应的可用性 Defect。测试人员毕竟不是客户，因此，可用性测试的方法也非常重要。本小节阐述实践方法以提高可用性测试的有效性。

　　首先，要运用上文提到的 Persona 方法来设计合理的 Persona。Persona 可能不止一个，所以需要分析并确认出不同的 Persona，并设定所有 Persona 的背景，需求，期望等。Persona 的简单模板包括姓名、照片、人物简介、工作目标、工作场景描述等。作者的经验中，Persona 的方法论非常有利于理清思路，在设计测试场景和执行可用性测试阶段非常重要。

　　其次，在设计场景时，可以根据 Persona 来定义其相应的角色，功能需求和目标等，然后设计其对应的设计场景，然后在其下面设计具体的功能点。可以运用“我是一个(某角色，如应用架构师)，我想做(某功能)来帮助我实现(某目标)”的模式进行场景设计。如此设计测试场景，测试人员将从客户的角度出发，去分析客户的目标及功能需求，使其更容易发现可用性方面的问题。

　　实践二：观察法

　　可用性测试的执行也与普通的功能性测试不同。对功能性测试来说，对功能熟悉的测试人员更容易发现和定位问题;而对于可用性测试来说，问题反而被新用户发现。因此建议在可用性测试中，测试人员可以互换测试模块进行测试 , 扮演不同的 Persona 去进行测试。在执行测试时，应参照上文提到的测试范围，还要考虑一下几个方面：

　　效率 – 用户要花多少时间，多少个步骤才能完成一个任务。比如注册用户，查找一篇文档。

　　准确 – 在操作的执行过程中，用户犯了多少错?测试人员要时刻记住，用户在使用产品中犯错，是设计人员的错，而不是用户的错。

　　无需记忆性 – 用户第一次使用是否能容易的使用产品?或者用户多长时间不用后，还能记得如何操作产品?好的产品设计是无需用户记忆，一切使用规则是隐含在设计中。

　　情感反映 – 用户完成任务后的感觉是什么?是放松，还是紧张，该用户是否会推荐产品给用户。用户使用产品，就犹如和设计师对话，好的设计师处处为用户考虑，用户使用完产品后会很放松甚至兴奋，会迫不及待的推荐产品给其他用户。

　　从心理学的角度看，人都有归咎于自己的心理倾向。这会给可用性测试带来很大的影响。当测试人员发现操作错误时，容易怀疑是自己操作不当而忽略了其中隐含的可用性问题，其中的问题可能是设计的不合理而使误导用户，文档不够等等。为了避免这样的问题，本文推荐使用一人执行另外一人观察的方法，就是一人进行操作，执行测试，另外一个人观察其操作时的表现，尤其是情感反映。一个可用性优秀的产品，在用户使用的过程中应该非常轻松得手，完成任务后应该是放松而不是紧张。

　　实践三：可用性问题管理最佳实践

　　软件产品的可用性问题是指在可用性测试过程中发现的各种各样的问题，有些问题是软件产品功能相关的问题甚至是软件缺陷，有些则是用户体验相关的问题。可用性问题的管理主要是指如何高效的管理测试过程中发现的可用性问题，并结合软件产品整体质量来维护和提升软件产品的全方位用户体验。

　　可用性问题的管理主要包括可用性问题的分类和处置流程。

　　可用性问题的分类大致分类如下 , 从而有效的对相关问题进行分析和选择处置方案 .

　　潜规则 (特殊用法或默认值类等)

　　不连贯 (如生成的项目却没有生成足够的默认文件或 jar 包等)

　　易用性 (如常用的功能不在最容易发现的位置等)

　　其他

　　可用性问题的管理可以依据下图所示的流程 , 从而和软件产品质量的全面管理形成有效的集成。

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