内容

• 前言
• 软件质量、敏捷开发和可用性
• 可用性测试的执行
• 总结
• 参考资料

前言

近年来有两个词语在软件行业迅速“走红”，一个是敏捷开发，另一个则是软件可用性。在 IBM 内部 2009 年的 QSE（Quality Software Engineer）大会上，这二位“当红明星”也是备受全球 IBMer 们的推崇，成为演讲场数最多的其中两个话题。

相对于这样“走红”的现象，作者更关心背后的原因和本质。究竟为什么这两个方法近年来会相续被推崇？这二者之间有什么关系？怎样能够强强联合，把二者结合起来实现在实践中使用？有没有 Best Practice 或流程帮助开发团队让这二位“明星”为团队服务？

几位作者具有丰富的敏捷开发经验，可用性经验，以及在敏捷开发中使用可用性的经验。在这篇文章中，几位作者就经验和体会和大家一起来探讨敏捷开发，软件可用性，以及如何在敏捷开发中进行可用性测试。

软件质量、敏捷开发和可用性

在介绍敏捷开发和软件可用性之前，有个铺垫需要先进行介绍，那就是软件质量。我们认为不管是敏捷开发，还是软件可用性，有个共同的目标是实现高质量的软件产品，即对终端客户有价值的产品。换句话说“软件质量”的诉求是敏捷开发和软件可用性二者“当红”的驱动力，所以很有必要先谈谈软件质量。

软件质量

什么是软件产品质量呢？一些同仁可能会认为软件质量是指系统的 Bug 数量，作者认为这样的理解是不够全面的。软件质量应该从使用者的角度去衡量其真正价值。正如大师温伯格在《 质量 . 软件 . 管理 : 系统思维》说到：“质量就是软件产品对于某个 ( 或某些 ) 人的价值”。软件质量包含两个层次的质量含义，即“正确的软件”及“软件运行正确”：

第一、“正确的软件”是指一个软件要能够满足用户的需求，为用户创造价值。此处的价值可以体现在两个方面，即为用户创造利润或者减少成本。如果一个软件能够满足需求的用户群体越大、创造的利润越大或减少的成本越大，则该软件产品的质量越高。反之，一个产品尽管运行良好，没有 Bug，扩展性很强，性能很好，但如果没有服务的用户人群，没有为用户创造价值，则这样的软件尽管运行良好，也无任何质量可言。

第二、“软件运行正确”是指软件没有或很少 Bug，扩展性很强，性能良好，易用性高等。这样的软件是一个运行良好的软件，但还不能称之为高质量的软件。只有在软件符合用户的需求的基础上，运行良好的软件，才是一个高质量的软件。当然，如果软件完全符合用户需求，但不易使用，经常出错，性能很差，这样的软件也不是一个高质量的软件。

“正确的软件”及“软件运行正确”二者相辅相成，前者关系到软件的成败，后者关系到软件的好坏。在现实的很多开发团队中，特别是偏技术的开发团队中，往往过分注重后者（软件的 Bug 率，性能，可扩展性，架构等），经常陷入在软件开发过程的细节之中，而忽略了前者（软件需要符合用户的需求），开发出的软件经常能用但无用，不是最终用户期望的软件，这样的软件是能用但无用的零质量软件。

不管是敏捷开发，还是软件可用性，都更加注重软件质量，即用户的价值。

敏捷开发

敏捷开发的定义为：通过一系列迭代，利用 User Stories 和持续关注利益干系人（Stakeholder）的反馈，驱动开发高质量、高可用性的软件。可以从下面三个方面来看敏捷开发，如下图所示：

首先是对象，也是利益干系人，随着企业组织结构的不断壮大，企业信息化的全面开展，一个软件产品或项目，面向的用户越来越多，典型的有：开发人员，企业业务人员，CIO/CEO，运维部门，甚至来自开发企业的领导等等。不同的部门和人员，由于工作和业务关系，关注的价值和重点都不一样。而软件的核心价值要能够符合最主要的利益干系人的价值目标和财务目标，该软件才会获得市场生命力。

其次是目标，这里的目标一定要是利益干系人的目标，敏捷开发和任何好的方法论或者新兴事物一样，如果要有持久的生命力，归根到财务上，就是要能带来利润，或者减少成本。敏捷开发就是这样的一种方法，能够通过高效率迭代和敏捷机制，为客户开发出能够符合业务发展需求，能为企业带来业务价值，并最终能为企业创造效益的方法。

最后是方法，即通过什么方法才能达到利益干系人的价值。这里强调的是敏捷中应用迭代的开发方式，以及敏捷开发中以人为中心，最大化发挥出团队的积极性和效率的开发及管理模式。

可用性

可用性设计（Consumablity）则是 IBM 提出的一个概念和方法论，可用性的定义为：软件可用性是客户端到端的体验，通过提高产品的可用性，可以增加对客户的价值。所以终归来说，可用性也是关乎终端客户的价值。（刚接触这种概念和词的时候，多次怀疑自己写错 Consumablity 这个词，这个词是 IBM 新发明的词，在词典中找不到，在 Word 和邮件系统会提示这个词不存在“红线”）。 可用性包含两个层面的含义，即有用和好用。如下图所示：

从上图可以看出，产品是产品开发团队和客户之间的沟通载体。产品承载着所有开发团队的理念、业务需求、设计、使用方式等，而客户则是试图通过产品来满足自身的业务需求，并且通过使用产品来达到满足需求的目的。

可用性中的“有用”是指，产品是能满足客户的业务需求，能给客户带来价值。而可用性中的“好用”是指，客户能够非常容易的使用产品来满足业务需求，客户使用产品是一个过程，包括从如何能容易的获得产品，容易安装，容易使用，容易升级和维护，文档清晰等。作者们认为可用性更多是一种以“一切设计从用户的角度出发”的思维方式来思考问题和设计产品。抱着这种思想，产品开发的方方面面，处处都是可用性设计问题，处处都值得改进。

敏捷开发中的可用性测试流程

不管是敏捷开发还是可用性，都是真正“以客户为中心”的方法，目的是开发出对客户有价值的好用产品。

目前，在国内的软件开发流程中，还较少有系统的可用性测试阶段和流程。在逐渐被广泛使用的敏捷开发过程中，更是较少的系统地包含这一测试阶段。作者们所在的产品开发团队，在敏捷开发的过程中引入了可用性方法论，并逐步地在敏捷测试中，系统地引入可用性测试流程和方法论，站在客户的角度，对产品的功能、用法、文档、安装等各方面进行全面的测试和改进，并取得了良好的成效。所以希望能和大家一起分享我们的改进，并一起继续探讨敏捷开发中的可用性测试。

下图是包含可用性测试的敏捷开发流程：

（查看图 3 的 清晰版本。）

上图是敏捷开发的一个迭代过程，可用性测试是产品测试流程一个很重要的环节。具体的可用性测试用例，可用性测试场景，可用性测试范围，衡量指标和方法等在下文会详细和大家介绍。

可用性测试的执行

软件可用性的衡量指标

软件产品可用性主要体现在帮助客户管理和提高使用软件产品所带来的价值。软件产品可用性的衡量指标总体上包括五个层次：

• 第一，便捷有效的业务实施。高可用性的软件可以保证软件可以帮助客户实现业务目标。
• 第二，积极的首次体验。好的开始试成功的一半，高可用性的软件可以保证客户顺利完成有重要意义的初始功能。
• 第三，与客户环境的便捷集成。客户环境千差万别，高可用性的软件可以便捷地与客户环境进行集成。
• 第四，对客户需求的适应性。客户需求差异大，变化快，高可用性的软件可以在很小的成本控制内最大化的满足客户的需求。
• 第五层次，简便的操作与使用。操作的简便与快捷影响用户的体验，高可用性的软件可以充分保证简便的操作使用，省级管理。

具体到每个层次又可以分为多个具体要求，详细内容如下表描述。

以用户为中心的场景设计

在敏捷开发过程中，以用户为中心的场景设计可以从两个关键词去理解：用户和场景。当我们有效理解这两个关键词之后，以用户为中心的场景设计的概念，价值以及方法也随即能得到深刻有效的理解。

用户概念可以扩展为四个方面：关键决策者、内部用户、合作用户以及最终用户。

• 关键决策者是指对软件产品的存在，市场需求以及发展方向起到关键的决定作用的人物或组织，如软件产品的投资商或股东，产品架构师，核心客户等等。他们的决策和视野首先决定了软件产品的生存权。在得以生存的基础上，软件产品的供给与需求也是其进一步发展的关键因素。
• 内部用户包括软件产品的开发人员，测试人员，产品维护人员，技术支持人员，销售人员和市场团队。其中开发人员和测试人员往往是软件产品的第一批用户，他们对软件产品的理解往往决定了产品功能和质量的根基。
• 合作用户使得软件产品真正意义上的运行在客户环境，为客户带来价值。例如运营人员，业务伙伴，系统集成商等等。
• 最终用户是指软件产品真正意义上的使用者。

从以上概念的理解可以看出，以用户为中心的软件产品，不仅仅要考虑开发人员或者是最终用户的感受，更是要从全方位的用户角色出发，尽可能全面地考虑到各个层次用户的需求与体验。从真正意义上，将用户的视野纳入到开发人员的视野之中，并以此为中心。

场景概念的理解需要建立在对用户用例和用户价值场景的有效区分的基础之上。

• 用户用例是指一系列用以描述“什么角色能做什么事情”的定义的集合或者组合。
• 用户价值场景则是以用户用例为基础，重点强调该场景给用户带来的价值。从经济学的角度考虑，场景是载体，价值才是软件产品真正带给用户的效用。也正是这种价值保证了我们的软件产品能够顺利的成为能用且有用的高质量产品。

综上所述，以用户为中心的产经设计方法需要两个部分：第一，区分用户的角色，应用不同角色思考问题的角度结合需求来进行场景的设计。第二，需要明确指出该用户场景能够给用户带来的价值。

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

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

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

可用性测试的范围

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

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

需求的可用性测试

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

设计的可用性测试

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

• 界面设计可用性是指系统和用户进行很好的交互。根据作者经验，界面设计的可用性测试至少要验证系统符合下面这些点：
• 信息清晰原则。尽量少用缩写，除非你的缩写已经众人皆知，比如像 PPT 这样的词语。但像 VC=Verification Code，这样的缩写应尽量避免。
• 可视性的设计原则。用户界面的操作尽量让人一看就知道如何操作，而不用记忆或查阅文档。如，界面中隐含操作顺序而不用用户牢记；用星号标记出必选项等。产品界面是否好用用户第一次使用，或者用户很长时间不使用后重新使用，他是否能够很方便的进行使用很关键。好的设计无需用户记忆，在设计中隐含着可视性的提示，便于用户完成操作。
• 限制性原则。尽量限制在界面上的用户错误操作。界面上应屏蔽用户当时不能输入的输入框等，尽量不让用户操作会引起错误的界面元素。限制错误的操作，指示正确的操作，只给用户一条正确的路，用户就能无需去判断错误，容易的完成操作。
• 反馈原则。反馈是控制科学和信息理论中的一个常用的概念， 其含义为： 向用户提供信息， 使用户知道其某一操作是否已经完成以及操作产生的结果。在界面设计时用户输入信息时，界面上应该能验证输入信息的正确性，并提供反馈信息给客户。
• 分类原则。这点当界面上的信息多时，尤为重要。把所有信息分类，并把同类的信息显示在一个区域，能非常方便用户浏览信息。
• 差异性原则。用颜色和和字体体现不同的界面元素，如必选项用红色标记，字体用粗体。颜色和心理学和公司或国家常规是相关的，否则会适得其反。
• 逻辑性原则。逻辑上两种元素的结构关系，可以通过界面上的视觉结构体现出来。中的层次结构，如层次包含结构，在界面上应该用缩进、层级菜单等结构体现出来。

开发的可用性测试

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

• 代码结构可用性在于开发人员不断重构，把代码按照逻辑结构分成不同的包。
• 代码格式可用性一般可以通过编辑器的代码模板和格式器来控制。
• 注释可用性即符合 Java doc 或 .net 的注释格式书写注释。

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

安装的可用性测试

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

• 安装的操作简单，尽量通过鼠标点击就可以完成安装；
• 安装的说明准确并易于理解；
• 安装过程中应有帮助说明，在用户不明白的情况下给与足够清晰的指导和说明；
• 安装完尽量已经完成配置，免去用户配置的复杂性；
• 安装中有依赖其他软件的，应给与提示，并可以提供所依赖软件的安装，或者提供足够的安装信息。

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

配置的可用性测试

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

• 配置集中化。现在产品配置步骤繁多，大都需要配置多个地方，多个文件，如果其中一个没有配置就会导致所有的配置不起作用。建议能用一个配置，尽量不用两个配置；能在一个文件，尽量不要分散在多个文件中。
• 配置向导化。配置也好，调整也罢，你需要告诉客户都要做哪几步配置，在哪里配置，怎么配置。现在大多数的配置需要在成千上万页的文档中查阅，然后一一对应，有时候配置的顺序还有关系。建议如果有多步的配置，采用向导的方式，一步一步的指导用户完成正确配置。
• 配置验证性。用户配置了许多的配置，配置完了，大多产品不给用户足够的反馈结果，提示配置是否出错，出什么错，哪里出错。而需要用户在运行环境按经验去找错，看 log, trace。结果好不容易找到了，兴许也就是一个很小的大小写的错误。用户兴许会想，都是自己不小心，怪自己疏忽。但作者认为这是设计开发人员的可用性错误，不注重可用性的今天，用户帮着承担了。建议：用户的配置应及时甚至当场就提供给客户反馈信息，提示用户配置的结果，如果配置错误，应提供足够的错误信息，哪里错误，出什么错，有什么解决方法。

文档的可用性测试

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

1. 能用视频少用图片，能用图片少用字。现在用 Flash 视频教学是非常流行的一种教学方式，尽量多用一些 Flash 视频的教学方式，如果没有视频，也尽量多一些图片，产品截图等。
2. 多一些例子，比如 Struts 框架提供了 show case 等一系列例子，教导用户如何开发和使用技巧，这些比纯文字的文档形象直接，效果更是不可同日而语。
3. 文档中尽量少用缩写，除非是人尽皆知的缩写，如 IBM, EJB 等词语。如果需要使用缩写，需要在一些地方标记出全名。

可用性测试的最佳实践

实践一：Persona

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

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

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

实践二：观察法

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

• 效率 – 用户要花多少时间，多少个步骤才能完成一个任务。比如注册用户，查找一篇文档。
• 准确 – 在操作的执行过程中，用户犯了多少错？测试人员要时刻记住，用户在使用产品中犯错，是设计人员的错，而不是用户的错。
• 无需记忆性 – 用户第一次使用是否能容易的使用产品？或者用户多长时间不用后，还能记得如何操作产品？好的产品设计是无需用户记忆，一切使用规则是隐含在设计中。
• 情感反映 – 用户完成任务后的感觉是什么？是放松，还是紧张，该用户是否会推荐产品给用户。用户使用产品，就犹如和设计师对话，好的设计师处处为用户考虑，用户使用完产品后会很放松甚至兴奋，会迫不及待的推荐产品给其他用户。

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

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

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

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

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

• 潜规则 （特殊用法或默认值类等）
• 不连贯 （如生成的项目却没有生成足够的默认文件或 jar 包等）
• 易用性 （如常用的功能不在最容易发现的位置等）
• 其他

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

总结

本文中，几位作者根据自身的经验和体会，从可用性测试的衡量标准，测试范围，最佳实践的多个方面和大家一起探讨了敏捷开发，软件可用性，以及如何在敏捷开发中进行可用性测试。

参考资料

学习

• 查看文章 Agile Methodologies，了解各种敏捷方法。
• 查看文章 UCD for different project types, Part 1，以用户为中心进行设计的开发人员指南。
• 查看 可用性测试的衡量指标：了解业界对可用性测试的衡量指标。
• 查看 IBM WMBTT Information Center：了解更多关于 WMBTT 产品的信息。
• 查看 IBM WMBTT Education Assistant：了解更多关于 WMBTT 使用方面的介绍。
• “敏捷测试的最佳实践，第 4 部分：自动化测试的 ROI”（developerWorks，2009 年 10 月）：有效的自动化测试很大程度上取决于合理的规划；相反，超出成本规划的自动化测试只能带来负担而不是效率的提高。本文从自动化测试脚本的开发维护成本量、测试周期长度等指标来估算自动化测试的投入产出比（EROI）。并讨论如何在敏捷开发、敏捷测试中应用该模式，及阐述几点点笔者对敏捷环境下自动化测试的原则。
• 技术书店：浏览关于这些和其他技术主题的图书。
• developerWorks Java 技术专区：数百篇关于 Java 编程各个方面的文章。

讨论

• 加入 developerWorks 社区。
• 查看 developerWorks 博客 的最新信息。