关于开发软件测试方法进行修改和补充

开发一套软件不是一件容易的事情，做过开发的人都知道，出品一套软件，需要经过需求分析，概要设计，详细设计，编码，测试，软件交付，验收，维护等8个过程。在这些过程，测试是必不可少的。如果没有经过测试就直接把软件卖给客户，相信这家开发公司不久就要倒闭啦。这个世界上不犯错的人是不存的。为了确保软件的完整性，一般都要对软件进行测试。关于软件测试的有关概念相信大家也看过不了的文章介绍，这里我就不再重复提了。今天主要想给大家分享一下软件测试方法进行修改与补充方面的深入知识。

较早的语言，例如c语言，叫做面向过程的语言，这可以通过20世纪70年代出版的一本书的书名很好地表现出来《算法+数据结构一程序》。

这些程序设计语言都是以算法为核心的，把程序看做是由算法驱动的，跟踪算法的执行从开始到结束，如图9．1所示。数据是一种由算法操作的外部实体。从本质上看，这类程序设计语言可以刻画为：

(1)数据被认为是与操作或程序独立的。

(2)算法是驱动者，数据是算法的补充。

从测试的角度看，测试传统面向过程的系统可归结为测试算法，把数据看做是测试算法流程的附属。

面向对象语言和程序设计中有两个基本的范例转换：第一，语言是以数据，即以对象为核心的；第二，如图9．2所示，在数据和操作数据的方法之间没有分离。数据和操作数据的方法一起构成一个不可见的单元。

类形成面向对象系统的基本构建块。类代表现实世界的对象。每个类(也就是类所代表的现实世界对象)由属性，也就是变量和操作变量的方法组成。例如，叫做矩形的现实世界对象可用两个属性，即长和宽。面积和周长是可以对矩形对象运算的两个操作，也就是方法。变量和方法结合在一起定义一个rectangle类。

现在不要过于关注例9．1给出的代码段的语法和语义。像例9．1中的类定义只是给出一个模板，指出一个对象的属性和方法。这些属性和方法(即模板)适用于那个类的所有对象。对象的一个具体实例由一个新的实例化创建。对象是类的动态实例化。使用一个给定(静态)类定义可以实例化多个对象。这种具体的实例化通过使用构建器函数完成。大多数类都有一个方法(例如叫做new)，用来创建类的新实例。创建了新的实例后，使用适当的参数通过向已实例化的对象传递消息，可以调用类的各种方法。例如：rectl．area()或rect2．new(11，b1)。对于rectl．area()，叫做area的方法不需要任何参数，而在rect2．new(11．b1)中，创建一个新的矩形需要描述其长和宽。

例9．2构建器函数。

在上面的例子中，new是一个构建器函数。每个类都可以有多个构建器函数，取决于所传递的参数，也就是函数的标志，要调用正确的构建器。

因此，在程序中可以有很多rectangle类的实例，因为有不同的rectangle，这意味着实例rectl的length，breadth，area和perimeter与实例rect2对应的变量和方法不同。因此，引用的方式是(例如)rectl．1ength，rect2．area等。

有人可能会问，“面向对象”有什么好处，为什么不能用传统的程序设计语言定义两个叫做area和perimeter的函数(或子进程)，并从代码的任何其他地方调用这些函数呢?基本的差别是，对于面向对象的语言，函数area和perimeter(以及变量length和breadth)如果没有类rectangle的实例rectl是不能生存的。而对传统程序设计语言，如果把area和perimeter定义为两个函数(把变量length和breadth定义为某个全局数据结构的部件)，那么这两个函数的存在不依赖于对象rectangle的实例。这可能导致不可预料的结果。例如，变量length和breadth可能会以未料到的(并且是不正确的)方式操作，函数area和perimeter也有可能被不恰当的对象调用。对于面向对象的语言，由于变量和方法是对象的特定实例专属的，因此可以获得对变量和方法的更好保护。

并不是所有的数据，也不是所有方法都在类之外公开可见的。有些数据、方法封装在类的内部。这保证对方法的实现是私用的数据和方法不能被外部世界访问。这样就提高了数据项转换的可预测性。此外，公共方法只提供能够用于对象内容的操作，这进一步降低了意外或者恶意修改对象内容的机会。

方法是贴在对象上的，并不独立存在。因此，方法只提供可以对该对象进行的操作。换句话说，类的用户只知道面积或者周长计算的外部接口，不知道有关方法实现的细节。也就是说，方法对用户是隐藏的。这使得编写方法的人可以优化实现而不改变外部行为。这叫做封装性。

面向对象系统的一个主要的优点就是能够通过已有的类定义新的类，新类的有些属性与已有的类类似，有些属性不同。这种能力叫做继承性。原来的类叫做父类(或者超类)，新类叫做子类(或导出类)。

面向对象测试的差别

上一节介绍了面向对象程序设计的各种突出特点，下面讨论这些特点如何对测试产生影响。

从测试角度来看，这意味着测试面向对象系统应该将数据和算法紧密联系起来，推动面向过程语言测试类型的数据和算法的分离。

面向对象系统测试大概有以下内容：类的单元测试、把类放在一起运行(类的集成测试)、系统测试、回归测试、面向对象系统的测试。

1．一组类的单元测试

这个类是在“发布”给其他程序使用之前构建的，因此要对类进行测试，检查是否已经可以使用。类是整个面向对象系统的构建块。就像面向过程系统的构建要在组装之前进行行单独的单元测试一样，类也要进行单元测试。本节要介绍对这些面向对象构建块甚至更彻底的单元测试的特殊因素，然后介绍适用于面向对象系统的传统测试方法，最后介绍针对面向对象系统的独特测试技术和方法。

(1)类必须首先进行单独测试的原因。对于面向对象系统，对构建块(类)进行彻底的单元测试甚至更重要(与面向过程系统相比)的原因是：
1)类通常要大量重用。因此，类的残留缺会影响重用的所有实例。
2)在定义类(即属性和方法)时会引入很多缺陷。延迟发现这些缺陷会使其进入这些类的客户中。因此，对缺陷的修改会在多处反映出来，产生不一致性。
3)类可能有不同的特性，类的不同客户可能使用类的不同片段。没有一个客户能够独自使用类的所有部分。因此，除非先把类作为一个测试单元，否则会有类的一些片段永远也得不到测试。
4)类是数据和算法的一种组合。如果方法和数据不能在单元测试级同步工作，就有可能产生以后很难查找的缺陷。
5)与过程语言构建块不同，面向对象系统具有像继承这样的特性，这些特性把更多的“背景”放入构建块中。因此，除非单独彻底地测试构建块，否则缺陷会在生命周期的后期从这些背景中露出来，并放大很多倍。

(2)适用于类测试的传统方法。前面讨论的有些单元测试方法可以直接用于类测试。例如：

1)每个类都包含变量。在讨论黑盒测试时介绍的边界值分析和等价类划分都可以使用，以保证使用最有效的测试数据发现尽可能多的缺陷。
2)前面已经介绍过，并不是所有方法都要由所有客户执行。可以使用在讨论白盒测试时介绍过的功能覆盖方法，以保证每个方法(功能)都能执行。
3)每个类都拥有具有过程逻辑的方法。在讨论白盒测试时介绍的条件覆盖技术、分支覆盖技术、代码复杂性分析等都可以使用，以保证尽可能多的分支和条件，增加代码的可维护性。
4)由于类要由不同的客户实例化很多次，前面讨论的各种压力测试都是可以使用的，以尽早发现与压力有关的问题，例如内存泄露，进行系统测试和验收测试。

基于状态的测试尤其适合测试类。由于类是数据和对数据进行操作的方法的组合，有些情况下可以把类可视化为不同状态的对象。传递到类的信息是触发状态转移的输入。在设计阶段获得这种视图是很重要的，因为测试可以更自然。可以用于测试的一些准则包括：

·每个状态是否至少到达一次?
·是否生成和测试了每个消息(即引起状态转移的输入)?
·每个状态转移是否至少出现过一次?
·是否测试过非法的状态转移?

(3)类测试的特殊考虑。以上方法是来自面向过程系统的通用方法。针对被类实例化的对象性质(这些对象必须通过消息传递测试)，如何在单元级测试这些实例?

为了测试这些经过实例化的对象，必须将消息传递给各种方法。以什么顺序把消息传递给对象?一种达到这个目的的有效方法就是a一∞方法。这种方法遵循以下原则：

1)“从生到死”全面测试对象的生存周期(即从实例化到销毁)。实例通过构建器方法进行实例化，然后变量被赋值。在执行过程中，可能会修改这些值并执行各种方法。最后，该实例将被销毁器方法销毁。
2)首先测试简单方法，然后测试更复杂的方法。由于构建面向对象系统的原理是构建一些可重用的对象，因此更复杂的方法很可能是在简单方法的基础上构建的。因此，测试复杂方法之前首先测试简单的方法是很明智的。
3)先测试私有方法，后测试公共方法。私有方法是不能被对象／类的外部看到的方法。因此，私有方法是面向实现的方法，负责处理方法的逻辑，是整个系统的构建块。另外，私有方法与调用方(即客户)是隔离的，这会降低测试的依赖性，使构建块在客户使用前更具健壮性。
4)给每个方法发送消息至少一次。这样保证每个方法至少被测试一次。

Ot一∞方法通过以下步骤可以达到以上目标：

1)首先测试构建器方法。每个类都可能被多个构建器消息根据标志构建。这些是创建类的实例的不同途径。如果有多个构建器，则需要单独测试所有的构建器方法。
2)测试get方法或accessor方法。accessor方法检索对象中的变量值供发出调用的程序使用。这个方法可以保证类定义中的变量可以被合适的方法调用。
3)测试修改对象变量的方法。有些方法测试变量的内容，有些方法设置／更新变量的内容，有些方法循环处理各种变量。可以推测，这些方法越来越复杂，请记住前面说过的原则。
4)最后，对象必然被销毁。当销毁对象后，不能对该对象进行意外访问。另外．被这个对象实例使用过的资源都应该释放。这些测试结束了被实例化对象的生命。

还有一些问题是类测试独有的。下面讨论这些问题。

前面已经介绍过，封装是对类的用户隐藏类细节的手段。从实现和使用的角度看这是很好的，但是从测试的角度看却会增加难度，因为被封装的部分的内部行为对测试人员的可视性降低。对于面向对象的语言，人们可以进入实现的内部，能够更清楚地看到程序的行为。没有了这种便利，带有封装的类的白盒测试会变得很困难。

前面已经介绍过，类实际上可以是类层次的一部分。类可以：从父类继承一部分变量和方法；对父类的一部分变量和方法进行重新定义；定义自己专用、父类不能使用的变量和方法。

由于类由所有以上3类变量和方法组成，因此严格地说，每个新类都必须测试所有的变量和方法。在第一次引人类的时候，必须使用已经讨论过的传统单元测试手段全面测试所有的变量和方法。以后，每次类被从父类导出时都需要测试一下内容，因为它们是第一次出现：对基类变量、方法和属性的修改必须再次测试，因为已经发生变化；引入到继承类的新变量和方法需要再次测试。

对于第一种情况，也就是经过修改的属性，用于父类的现有的测试用例可能可以重用，也可能不能重用。在前面讨论的平面图形的例子中，即使圆的面积和周长已经测试过，但是对于针对矩形的同一个方法却不能说明任何问题，尽管两者都是从同一父类中导出的。

很显然，在子类中对类属性的所有修改和补充都必须进行单独测试，但问题是，如何处理从父类继承且没有子类修改的属性?严格来说，不需要再次测试，因为理论上内容没有改变。但是这些没有改变的变量和方法在与一些变更混合后，可能有一些不期望的副作用，因此(没有修改过的)父类元素要和导出类一起有选择地进行重新测试。那么如何确定应该重新测试的为改变元素呢?以下给出一些可能的选择：1)只要未改变的变量在新的类或已变更的方法中引用，则针对该变量的测试用例就是重新测试时候的候选测试用例。这可以发现任何未改变变量的非有意使用。

2)只要未修改方法在新的或修改过的方法中调用，则可以考虑对这个未修改方法进行重新测试。如果新的或修改过的方法没有得到正确的结果，则可能说明未修改方法也许要在包含该方法的新方法的子类中重新定义。也可能要生成原来的方法，以便适应新子类的需要。

在创建时彻底测试所有变量或者更新内容，有选择性地重新测试其他未改变的属性，这种方法叫做增量式类测试。这种方法既考虑了穷尽测试，也考虑了与风险相关的不测试(表面)没有改变的内容。

虽然继承使通过已有对象定义新对象更容易一些，但是继承也是一种潜在的缺陷源。请考虑一个多层嵌套的类，最内层的类只可能有少量代码，但是可能继承类层次结构内上层类的大量变量和方法。这意味着由大量背景内容构成了这个子类，而这种背景内容不能通过孤立地检查这个类来确定。这与在面向过程语言中使用全局变量的情况相似。由于被嵌套的类可以随意访问其父类的方法和变量，因此测试嵌套类就需要访问其父类的信息。还有其他两种形式的类和继承对测试带来特殊挑战——抽象类和多重继承。

到目前为止讨论过的例子都假设子类可以只由紧邻的父类导出。有些语言支持所谓的多重继承，即子类通过两个或者更多个父类导出，很像人可以从双亲那里得到遗传。这种多重继承性质为测试带来很有意思的东西。例如。如果子类A有两个父类P1和P2，很可能P1和P2都有名字相同但是功能完全不同的变量和方法。假设P1和P2都有一个叫做X的方法(完成不同的功能)，当子类A从这两个父类继承的时候，子类可能使用P1或者P2中的X，或自己修改X，使用修改后的X作为X的默认含义，取代来自P1和P2的X。

第二种情况类似在单继承中经过变更的类，因此可能需要测试。对于第一种情况，X没有改变，但是可以考虑重新测试。由于多重继承，所以产生副作用的可能性倍增，缺陷范围更大。因此从测试角度看，多重继承需要更彻底的测试。

有时候必须存在特定的带有公共接口的方法，以重新定义类，但是这个方法的具体实现则完全留给实现者。例如，考虑对数组进行排序，并在另一个数组中返回已经排序好的列表的方法。对排序例程的接口明确定义：一个输入整数数组和一个输出整数数组。这种方法叫做虚方法。具有虚方法的类叫做抽象类。对父类继承每个新子类都要实现虚方法。

抽象类和虚拟函数给测试带来了什么意义呢?抽象类不能直接实例化。因为抽象类不完整，只有虚拟函数的位置。必须通过抽象类定义没有虚函数的具体类，要测试这些具体类的实例。由于对不同的具体类同一个虚函数可以不同地实现，因此针对抽象类不同实现的测试用例一般不能重用。但是，虚函数和抽象类为测试带来的好处是，提供了函数应该满足的接口定义。这种接口对于不同的实现应该是不变的。因此，这种接口提供了测试具体类的一个很好的切人点。

2．将类组合在一起——集成测试

以上所有讨论都是在类的层次上进行测试。面向对象系统不是分离对象或者类的集合，这些对象或类应该共存、集成并相互通信。由于面向对象系统在设计上有较小的只对重用(经过必要的重新定义)的组件或类构成，因此一旦基本类本身已经彻底测试，类是否能一起运行就成为了下一步测试的内容。更多的情况是，不是一个单独的类作为一个单元进行测试，而是一组永远都能在一起运行的有关的类。这与面向过程语言没有多大区别，对于面向过程语言，单元可能不总是一个源文件，而是完成相关功能的一组相关文件作为一个单元测试。对于面向对象系统，由于测试的重点是重用和类，因此测试这种集成单元是至关紧要的。

对于面向过程的系统，测试是通过给出不同的数据检验控制流路径完成的。这些控制流路径自始至终是由程序调用的函数决定的。如前所述，在面向对象系统中，类相互之间通信的各种方式都通过消息。消息具有以下格式：<实例名>．<方法名>．<变量>

对于有名称的实例调用具有指定名称的方法，或通过合适的变量调用(合适类的)对象。因此，不能通过列出执行要经过的函数名来描述要测试的流程。事实上，在测试面向对象系统时，方法名没有唯一地确定控制流。前面已经介绍过，这种函数或者操作符的含义随背景的不同而变化，同一个操作在不同的条件下行为各异的属性叫做多态性。从测试的观点看，多态性是一个很大的挑战，因为多态性推翻了代码覆盖和代码静态审查的传统定义。例如，如果有两个分别叫做square和circle的类都有一个叫做area的方法．即使函数在两个类中都叫做are—a，即使两个函数都只接受一个参数，但是取决于调用方法的背景，参数的含义是不同的(对于圆是半径，对于正方形是边长)。方法的行为对于这两个类也是完全不同的。因此，如果针对正方形测试了方法area，并不意味着area方法对于圆也是完全正确的，需要单独测试。

多态性的一种叫做动态绑定的变种也为测试带来了很大的挑战。在程序代码中，如何显式的引用square．area和circle．area，那么测试人员显然知道这是两个不同的函数，因此只需要根据所使用的背景条件进行测试。对于动态绑定，要接受消息的类在运行时描述。这对于允许使用指针(例如C++)的语言来说，是对测试的一个很大挑战。假设指向一个特定对象的指针存在叫做ptr的指针变量里．那么ptr一>area(i)要在运行时解析由ptr指向的合适对象的area方法。如果ptr指向一个square的对象，那么调用的就是square．area(i)(i就是正方形的边长)。如果ptr指向一个circle的对象，那么调用的就是circle．area(i)(i就是圆的半径)。这意味着像代码覆盖这样的白盒测试策略在这种情况下就没有什么用了。在上面的例子中，通过用指向一个square对象的ptr指针就可以达到对ptr一>area(i)的代码覆盖。但是，如果ptr没有测试过指向circle对象的情况，那么计算圆面积的那部分代码就完全没有测试，尽管调用程序中的代码已经被测试用例覆盖过了。

除了分装和多态性，另一个问题就是以什么顺序将类放到一起测试?这个问题与在面向过程系统集成测试中遇到的问题相似。像自顶向下、自底向上、大爆炸等集成测试方法对于面向对象系统都是用。在面向对象系统集成测试需要额外注意的几点是：

(1)面向对象系统本质是要通过小的、可重用的组件构成。因此，集成测试对于面向对象系统来说更重要。
(2)面向对象系统下层组件的开发一般更具并行性，因此对频繁集成的要求更高。
(3)由于并行性提高，集成测试时要考虑类的完成顺序。也需要设置桩模块和驱动器来模拟还没有完成的类的功能。

3．面向对象系统的系统测试与互操作

面向对象系统从设计上要通过较小的可重用组件(也就是类)构建。这种对现有构建块重用的强调使系统测试对于面向对象系统比传统系统变的更重要。这是因为：

(1)类可能有不同的部分，不是所有的部分都同时使用。当不同的用户开始使用某个类时，他们可能使用类的不同的部分，这可能在以后的阶段(系统测试)引人缺陷。
(2)不同的类可以由客户组合在一起，这种组合可能导致还未发现的新缺陷。
(3)实例化后的对象可能没有释放所分配的所有资源，导致内存泄漏的问题，这些问题只能在测试阶段显露出来。

由于类之间交互的复杂性可能是很微妙的，重要的是保证在进行系统测试之前完成合适的单元测试和组件测试。因此，要在系统测试之前确定各种测试阶段合适的进入和退出规则，以最大限度的提高系统测试的有效性。

4．面向对象系统的回归测试

将集成钡0试的讨论再进一步推进，回归测试对面向对象系统非常的重要。作为面向对象系统强调依赖可重用组件的结果，对任何组件的变更可能对使用该组件的用户引入潜在的副作用。因此，对于面向对象系统测试来说，频繁运用集成和回归测试用例是十分必要的。此外，由于继承等特性导致的变更级联效应，对于尽可能早地捕获缺陷是很有意义的。
5．面向对象系统的测试工具

有一些工具可以帮助面向对象系统的测试，包括：用例、类图、序列图、活动图、状态图。

(1)用例。用例表示用户在与系统进行交互时完成的各种任务。用例给出用户完成每个任务的具体步骤细节，以及系统对每个步骤的响应。这符合面向对象范例，因为任务和响应都是通过消息传递给各种对象的。
(2)类图。类图表示不同的实体和实体之间的关系。由于类是面向对象系统的基本构建块，因此类图是以系统的类为基础的。类图有几个部件，这里从测试的角度介绍几个重要的部件。

1)方块。每个矩形方块代表一个类。类的各种要素在类矩形内的间隔处表示。
2)关联。通过连线表示两个类之间的关系。关系可以使一对一，也可以是一对多、多对一等。任何一般的都显示在关联连线上。
3)通用化。表示从父类导出的子类。

(3)序列图。序列图主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。很象类图，开发者一般认为序列图只对他们有意义。然而。一个组织的业务人员会发现，序列图显示不同的业务对象如何交互，对于交流当前业务如何进行很有用。除记录组织的当前事件外，一个业务级的序列图能被当作一个需求文件使用，为实现一个未来系统传递需求。在项目的需求阶段，分析师能通过提供一个更加正式的层次表达，把用例带入下一层次。那种情况下，用例常常被细化为一个或者更多的序列图。组织的技术人员能发现，序列图在记录一个未来系统的行为应该如何表现中，非常有用。在设计阶段，架构师和开发者能使用图，挖掘出系统对象间的交互，这样充实整个系统设计。

序列图的主要用途之一，是把用例表达的需求，转化为进一步、更加正式层次的精细表达。用例常常被细化为一个或者更多的序列图。序列图除了在设计新系统方面的用途外，它们还能用来记录一个存在系统(称它为“遗产”)的对象现在如何交互。当把这个系统移交给另一个人或组织时，这个文档很有用。

序列图的主要目的是定义事件序列，产生一些希望的输出。重点不是消息本身，而是消息产生的顺序；不过，大多数序列图会表示一个系统的对象之间传递的什么消息，以及它们发生的顺序。图按照水平和垂直的维度传递信息：垂直维度从上而下表示消息／调用发生的时间序列，而且水平维度从左到右表示消息发送到的对象实例。

在序列图中，时间流逝方向为自顶向下。
序列图在以下方面对测试有帮助：
1)确定个点的端到端信息。
2)跟踪端到端事务中的中间点，因此能够更容易地缩小问题的范围。
3)提供多种典型的消息调用序列，包括模块化调用和非模块化调用等。序列图对测试也是有局限性的：即使可能，描述复杂交互也会很乱，很难表示动态绑定。

(4)活动图。序列图主要表示消息序列，而活动图主要表示所发生的活动序列。活动图主要对应用程序中的典型工作流建模，描述手工和自动过程之间的交互要素。由于活动图表示活动序列，因此．它与流程图相似，与传统的流程图的大多数要素对应。

由于活动图表示控制流，因此在以下方面有助于测试：

1)通过执行导出各种通路的能力。与流程图相似，活动图也可以确定程序代码的代码复杂程度和独立路径。

2)确定活动和对象之间的可能的消息流的能力，因此使前面介绍的基于消息的测试更加健壮、有效。

(5)状态图。本章前面已经介绍了状态转移图对测试的帮助。如果对象可以建模为一个状态机，那么白盒测试以及有关状态的测试技术就可以直接使用。

可使用性和易获得性测试

可使用-陛测试的定义

“可用性”一词最早出现在1382年，而第一次以近似于现在的含义被应用则是在1842年左右出版的《布莱克威尔杂志》(Blackwell’SMagazine)上。在20世纪80到90年代大约20年的时间里。产品设计的专业术语经历了从“功能性”到“可用性“，再到“可用性工程”，再到“以用户为中心的设计”的转变。到了21世纪，“用户体验工程”这样的词语开始在招聘广告中出现。传统的可用性包含易学习性和效率等方面，而PatrickJordan和DonNorman等杰出的同行开始鼓励可用性从业者跳出传统的可用性关注点，用更加宽阔的视角关注与用户相关的各个方面，例如审美、协作、可达性、可信性、说服力和愉悦等。

可用性是用来衡量产品质量的重要指标，从用户角度来判断产品的有效性、学习性、记忆性、使用效率、容错程度和令人满意的程度。可用性概念从20世纪80年代随着计算机技术发展由人因工程(HumanFactorsEngineering或Ergonomics)领域提出，人因工程主要研究人在某种工作环境中的解剖学、生理学和心理学等方面的各种因素；研究人和机器及环境的相互作用；研究在工作中、家庭生活中和闲暇时怎样统一考虑工作效率、人的健康、安全和舒适等问题。

关于可用性的定义和概念也在不断发展。1983年的国际标准ISO9241第11部分中对可用性的定义是指特定用户在特定的使用情景下，使用某个产品达到特定目标的有效性、效率和满意度的大小。有效性(Effectiveness)：用户达到某特定目标的正确度和完成度；效率(Ef—ficiency)：当用户在一定的正确度和完成下达到特定目标时所消耗的与之相关的资源量；满意度(Satisfaction)：使用产品的舒适度和可接受程度，该定义强调特定用户在特定目标和特定情境下的产品使用过程。

随着可用性在实践过程中的不断应用和发展，可用性概念转向更具操作性和更为具体的参数指标以及设计原则。Shneiderman在20世纪80年代，凭借开发经验和可用性的优秀案例，提出的普遍适用用户界面设计的八条交互设计原则，至今仍被开发人员看作是可用性设计的最高原则而广泛运用；同时代由Card等人提出的GOMS(GoalsOperationsMethodsSelec—tionrules)模型提供了可以量化可用性的方式，并且将可用性研究从实验心理学引入了认知心理学；Lund在90年代提出了更加细致的可用性原则，这20条原则始终强调用户在可用性概念中的重要地位，要求开发人员对用户的需求、背景和评价有深入的了解；同时代的苹果公司，将可用性概念融人人机界面设计指南，用以指导设计开发图形界面系统。在这之后，可用性研究主要关注于影响可用性的众多因素，包括用户背景、任务设置、环境条件、用户情绪、可用性的测试方法等。

对可用性进行总结，其包含着4方面特点：

(1)可用性既是用来评估用户界面和产品是否易用(ease—of—use)的质量参数，也是在设计过程中提升产品综合质量的方法。用户对不同产品的易用性要求并不相同，可用性也需要根据不同产品有所改变，而作为提升质量的方法是指可用性包含的一些研究手段，如用户测试和专家评估等。
(2)可用性与用户使用产品的功能紧密联系，用户使用产品功能的目的是不同的，这时可用性成为是否符合用户目的，满足用户行为需要、认知需要的评判指标。
(3)可用性关注特定用户在特定情景下满足特定目的这一个过程，这反映可用性不是固定不变的，而是需要根据具体的产品、用户、环境情况灵活变化的。
(4)可用性贯穿于整个产品周期之中，为了保证产品的可用性，在产品设计之初就应考虑并投入到可用性工作中，针对已有产品、相似产品的测试评估，或采用原型方式进行测试评估，完善新的设计。

可用性测试是指，让一群有代表性的用户尝试对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。该产品可能是一个软件系统，软件。或者其他任何产品，它可能尚未成型。测试可以是早期的纸上原型测试，也可以是后期成品的测试。

可使用性测试的时机

确保可使用性的最佳时机是实施两个阶段的可使用性测试。第一阶段进行设计确认，第二阶段作为测试周期中的组件和集成测试的一部分进行可使用性测试。

早在开发周期策划测试时，就应该并行地策划可使用性需求，这与其他类型的测试相似。但是一般来说，可使用性测试往往被忽略(或者分配很低的优先级)，并没有从项目的开始就进行策划和执行。如果有两个缺陷。一个是功能缺陷，一个是可使用性缺陷，通常功能缺陷会有处理规程。这种方法是不对的，因为可使用性缺陷可能导致用户失去对软件的兴趣(即使完成了所需的功能)，如果用户失去兴趣，换句话说用户放弃了当前产品，那意味着给产品公司造成了巨大的经济损失。事实证明，在产品测试周期中退后可使用性测试会有很高的代价，因为大量的可使用性缺陷最终需要修改设计，需要修改多个屏幕，会影响不同的代码路径。如果尽早进行可使用性测试则可以避免这些情况的出现。图9．3给出可使用性测试的阶段和活动。产品的可使用性要通过设计实现。只考虑功能的产品设计不能得到用户的认可。针对功能的产品设计还需要大量的培训，如果设计时既考虑功能又考虑可使用性就会最大限度地降低培训要求。在可使用测试的第一阶段，要确认可使用性设计的这个方面。

可使用性设计可以通过多种手段验证，包括：

(1)风格单。风格单列出用户界面设计要素。使用风格单可以保证多个屏幕设计要素的一致性，测试风格单可保证测试基本的可使用性。风格单还包括帧，每个帧都被用户认为是一个单独的屏幕。要对风格单进行审评，检查其是否规定了字体大小、颜色模式等，这些都会影响可使用性。
(2)屏幕原型。屏幕原型是可使用性的另一个测试方法。屏幕设计成与提交客户的一样，但是没有与产品的其他模块集成。因此这种用户界面不与其他功能模块集成，需要单独测试。原型是用户对产品发布后的屏幕的确切外观和功能有直观印象。测试团队和一些真实用户测试这种原型，并把改进意见吸收到用户界面中。当这种用户界面彻底测试后再与其他的功能模块进行集成。
(3)书面设计。书面设计利用确认可使用性设计的最早机会，早在产品的实际设计和编码还有完成前就可以实施。屏幕、布局和菜单的设计被画在纸上，提交给用户等待反馈意见。使用风格单需要进一步编码，原型需要二进制代码和资源来验证，但是书面设计却不需要任何其他资源。书面设计可以通过电子邮件发送或者打印，并采集反馈信息。
(4)布局设计。风格单保证一套用户界面要素被组织起来，并一起反复使用。布局有助于动态地在屏幕上安排不同的要素，保证要素、空白、字体尺寸、图片、排列风格等在屏幕上的安排。这是可使用性设计的一部分，也需要进行测试。在第二阶段，要运行产品，测试可使用性。在执行测试前，要挑选一部分用户(第一次接触产品和特性)使用产品，收集他们的反馈意见。并解决所提出的问题。有时很难请到产品的实际用户进行测试。在这种情况下，可以从产品开发团队外挑选一些用户代表，例如支持、市场开发以及销售人员。

什么时候实施可使用性测试还取决于所开发产品的类型。例如，针对局域网环境设计的客户应用程序(Windowsclient32)通常有很丰富的特性，每个屏幕都尝试完成各种任务，并提供大量信息。Web服务则不同，每个屏幕的信息和任务量很有限，以快速装载web页面。对这些类型的应用程序要在不同阶段完成可使用性测试活动。表9—1对比了客户和web服务的一般开发和测试方法。如表9—1所示，Web界面要在设计功能前设计。这为实施两个阶段(第1阶段、第2阶段)的可使用性测试留下了充足的时间。而在客户应用程序中，用户界面只能在确定了功能以后确定，因为用户界面编码是最后一项活动，设计确认没有多少工作要作为一个单独阶段完成。因此，将第1、2阶段合并。同时，没有硬性和严格规定客户应用程序不能在功能设计之前设计用户界面。随着越来越多的关注可使用性，这是唯一可以改变的公共实践。

可使用性的质量因素

在实施可使用性测试时有些质量因素是非常重要的。前面介绍可使用性是主观的，并不是可使用性的所有需求都可以清楚的写入文档。但是关注以下质量因素可以提高可使用性测试的客观性。

(1)可理解性。产品应该有简单和有逻辑的特性和文档结构，应该以用户场景和使用为基础。在场景中执行的最常使用的操作应该通过用户界面首先给出。当把特性和组件集成进产品时，应该按用户的术语，而不是按技术或者实现术语。
(2)一致性。产品需要与适用标准、平台外观感觉、基本设施和同一产品的早期版本一致。此外，如果同一公司有多个产品。那么这些产品在界面和感觉上最好有一定的一致性。在不同的底层操作系统上的不同用户界面会使用户不满，因为用户在使用这些操作系统上的产品时，需要对不同的模板和规程感觉到舒服。除非产品在用户界面上有严重的问题，否则当前的界面和用法要与相同产品的较早版本一致。遵循一些可使用性标准有助于满足可使用性的一致性要素要求。
(3)导航。这有助于确定选择产品的不同操作有多容易。隐藏很深的选项需要用户经过多个屏幕或者菜单选项才能执行该操作。执行一个操作所需的鼠标点击或者菜单选择次数应该尽可能减少．以提高可使用性。在用户受阻或者感到困惑的时候，应该有容易的选项取消当前菜单或者回到上一级菜单，以便用户选择不同的操作路径。
(4)响应。产品对用户的响应有多快是可使用性的另一个重要方面。不要把可使用性的响应与系统性能测试混淆起来。屏幕导航和直观显现应该在用户操作后立即给出，否则将给用户没有任何进展的印象，使他们不断地重复尝试。只要在产品中进行信息处理，显示出当前操作进行的程度或者剩余时间，让用户耐心等待，这样便可以提高系统的可使用性，当然弹出的窗口不能过多．这会降低可使用性，同时这事实上也会降低系统的响应时间。

在可使用性检查单上加上以上的质量因素，保证在设计和测试中考虑到这些因素，有助于得到好的可使用性产品。

可使用性测试的方法

提升可用性最主要的方式就是采用迭代式设计(iterativedesign)，通过产品前期开发阶段的反复评估，不断的获得用户反馈，进而修改优化产品设计，直到达到可以接受的可用性水平。这其中的评估过程就是进行可用性测试的过程，可用性测试就是选择不同方法测试产品使用质量的过程。它的目的是建立评价标准，尽可能多的发现可用性问题，并指导产品界面的设计和改进。

一般来说，最适合实施可使用性测试的人是：

(1)将使用该产品的实际用户群的典型代表，以便获取典型的用户模式。
(2)第一次接触该产品的人，从一开始就没有任何偏见，能够找出可使用性的问题。多次使用过该产品的人可能会看不到产品可使用性方面的问题，因为他们对产品已经“习惯”了产品的(潜在的不合适的)可使用性。

因此，可以从测试团队之外的客户代表中选择一部分人进行可使用性测试。邀请了解用户想要什么和客户预期的面对客户的团队(例如客户支持、产品市场开发人员)，可提高可使用测试的有效性。表9—2归纳了可使用性测试的不同角色的技能和预期。在研发过程中，常见的可用性测试方法包括以用户为主的测试和以专家为主的测试方式。以用户为主的测试包括用户测试(UserTesting)和有声思维(ThinkAloud)，以专家为主的测试有认知预演(CognitiveWalkthrough)和探索式评估(HeuristicEvaluation)。

1．用户测试
用户测试方法是测试人员要求用户完成一系列设定的任务，用户在操作使用过程中出现的问题和失误将被测试人员记录，在任务结束时对问题和失误点进行追问，从而快速地发现及判断产品中的不足，进而进行修改。测试采用的产品可以是最终完成的，也可以是基于不同保真度原型的非完成产品。该方法的目的是通过在产品设计阶段用户参与设计测试，预测最终产品可能出现的问题，进行修正规避风险。采用用户测试的优点在于可以在特定任务条件下，获得特定用户的客观反馈结果，满足可用性测试的要求。

2．有声思维
有声思维运用于可用性测试过程和心理学、社会学领域研究中，是获取用户数据反馈的有效方法。最初由Lewis在IBM公司提出，之后被Ericsson和Simon进一步修正。该方法要求用户在完成一系列由测试人员设定的任务过程中，VI述出自己所看到的、所想的、所感受的，以帮助观察测试人员可以获得第一手反馈，从最终发现问题。观察测试人员在整个测试过程中被要求，客观全面的记录用户所说的每一句话，不能打断用户的行动和表达。该方法的目的是明确“谁”在完成特定的任务时出现了什么样的“问题”，强调特定的用户和特定的问题。

3．认知预演
认知预演方法，最初在90年代初由Wharton等人提出，在2000年由Spencer优化了该方法，使其更加有效的适应软件开发的要求。该方法将用户行动过程(目的、计划、实施、评价)及系统反馈，按照任务流程进行步骤划分，之后由专家(设计人员和开发人员)对每一个步骤进行一系列检查评估．从而判断可能出现的可用性问题。

该方法因为可以低成本高效率地发掘可用性问题，而被广泛使用于早期开发阶段。但是由于是从专家角度来判断用户的行为，而专家和用户有着本质差别，这导致专家和真实用户所认为的可用性问题存在差异；而且不同专家之间的差异也较大，一般所发现的可用性问题只有20％～30％是一致的．这也使得认知预演方法所得到的结果应用存在一定局限性。

4．探索式评估
Nielsen和Molich在1990年项目合作的过程中提出了探索式评估方法，该方法是非结构化的可用性研究方法，通过研发人员和行业专家，依照可用性原则来评估用户界面中的问题，不需要设定任务和情景，专家根据经验和可用性原则完成评估。

尽管探索式评估可以在很短的时间内发现大部分可用性问题，但是该方法也因为受到专家的背景知识、观点经验等方面的影响而被质疑，这种由专家评估所得到的结果与用户测试相比得到的结果差异性大，可信度不高。

可用性测试中你该注意什么?必须牢记以下4点：

(1)你测试的是产品，而不是使用者。
(2)更多地依靠用户的表现，而不是他们的偏好。
(3)把你掌握的测试结果应用起来。
(4)基于真实的用户体验，找出问题的最佳解决方法。

你测试的是产品，而不是使用者。对一些用户而言，”测试”有负面的涵义。我们要努力确保他们不认为测试是针对他们。我们要让他们明白。他们正在帮助我们测试原型。事实上，我们可以不使用“测试”这个术语。相反，我们是邀请参加者为我们提供帮助，”勇于尝试原型”。当用户难以完成任务时，我们应该改变系统，而不是改变用户。同时我们还应该思考该系统能在多大程度上符合那些典型用户的的目标，而不是关注用户在这个任务做的多好。

更多地依靠用户的表现，而不是他们的偏好。通过测试我们可以测量到用户的表现，以及他们的偏好。用户的表现包括是否成功完成，所用时间，产生的错误等等。偏好包括用户自我报告的满意度和舒适度。一些设计人员认为，如果他们的设计能迎合用户的喜好，用户在该软件系统上就会有良好的表现。但证据并不支持这一点。事实上，用户的表现以及他们对产品的偏好并非一一对应。一项研究发现，约有百分之七十的用户同意表现和喜好有联系。也就是说，他们在喜爱的软件系统上表现良好，在不喜欢的软件系统上表现欠佳。然而，还有相对比较大比例的人(30％)认为，用户的表现以及他们对产品的偏好并非一一对应。他们在不喜爱的软件系统上可能表现良好，在喜欢的软件系统上也可能表现不佳。关于人们为什么会对自己表现欠佳的软件系统给出较高的评价有多种解释。他们可能会把表现不佳归结到自己，而不是软件系统。或者说，他们可能担心给一个较低的评价会伤害软件系统设计者，也就是我们的感情。或者说，他们可能并没有完成任务，却自认为成功完成了，他们并没有意识到问题所在。基于所有这些理由，建议你：更多地依靠用户的表现，而不是他们的偏好。

把你掌握的测试结果应用起来。可用性测试不仅仅是用于核对项目进度的一个里程碑，要知道，当最后一个参与者完成任务的时候，可用性测试还没有结束。整个团队必须仔细研究结果，设定优先次序，基于结果对软件系统原型进行修改。

基于真实的用户体验，找出问题的最佳解决方法。制造任何产品，包括大部分软件系统和软件，需要考虑许多不同的用户的工作方式、体验、问题以及需要。大多数项目，包括设计或修改软件系统，都要处理时间、预算和资源等方面的限制。平衡各个方面对大部分项目来说都是一个重大的挑战。在你权衡利弊时，最好优先开发那些能使最多用户完成任务的软件系统或软件。有研究表明，产品推出后，用于支持失败客户的花费远远高于开发时对产品修正所付出的花费。你需要认真考虑假定用户、使用场景以及可用性测试的结果，试图找出针对不同客户需求的理想解决方法。找不到最好的解决方法，用户就不能够顺畅地完成任务。有证据表明，即使用户延长在一个不太完美的产品界面完成任务的使用时间，也远不及在一个更好的产品界面带来的成功感。

可使用性工具
在可使用性方面没有多少工具，因为评价可使用性具有很高的主观性。表9—3出了一些可使用性工具。

可使用性实验室的建立
前面已经讨论过，期望用户对可使用性提出意见是不大可能的。产品的开发人员常常忽视可使用性缺陷。当用户面对类似的缺陷并逐渐习惯后，他们也会忽略可使用性缺陷。因此，单凭用户提出意见不会使产品具有可使用性。观察用户的“肢体语言”可以指出产品的可使用性缺陷，否则这些缺陷可能永远也不会被指出。

不仅仅是肢体语言，背景．即用户受阻的屏幕和使用户感到困惑的事件等，也需要与用户的反馈关联起来，以提取缺陷。

以上这些足以成为建立可使用性实验室的充分理由，以便记录、观察有关可使用性的所有信息，并修改缺陷。图9．4给出了可使用性实验室的一些关键元素。

易获得性测试
很多人的听力、视力和移动存在部分或者完全障碍。不考虑他们的需求，产品的可使用性会不被接受。对于这些用户，要提供使用产品的替代方法。有一些工具可以帮助提供替代方法。这些工具通常叫做易获得性工具或者辅助技术。易获得性测试要测试这些使用产品的替代方法．结合易获得性工具测试产品。易获得性是可使用性的一个子集，应该包含到可使用测试策划中。

产品的易获得性可以通过两种手段提供：
(1)利用基本架构(例如操作系统)提供易获得性特性，叫做基本易获得性。
(2)通过标准和指南在产品中提供的易获得性，叫做产品易获得性。

1．基本易获得性

基本易获得性是硬件和操作系统提供的。计算机的所有输入和输出设备和其易获得性选项都属于基本的易获得性。

(1)键盘易获得性。键盘对于视力和移动有障碍的用户来说是最复杂的设备。因此，在易获得性上要特别助于键盘。有些易获得性改进是在硬件上完成的，有些是在操作系统上完成的。硬件易获得性改进的一个例子就是在F键和J键上加了一个小突起。这种小突起有助于视力有障碍的用户通过触觉调整敲键的手指。键盘上的键有不同的大小，以及提供快捷键，都是通过硬件改进易获得性的例子。

类似的，操作系统提供商也在键盘上做了一些改进，包括使用粘贴键、开关键和箭头键控制鼠标。

1)粘贴键。为了说明粘贴键。以％DEL>为例。对视力和移动有障碍的用户来说，最困难的序列之一就是％DEL>。这种键盘序列有很多的用途，例如登陆、退出，加锁和开锁计算机，关机．调出任务管理器。有时对没有障碍的用户来说。键盘序列也很复杂，因为它要求同时按住两个键后在按下第三个键。这种特殊序列要求两只手上的三个手指必须协调。操作系统的粘贴键设置消除了对按下键的要求。如果启用了粘贴键特性，用户可以按下和键一次，在释放，然后再按下键。这样就可以使用一个手指完成序列操作。
2)过滤键。当按键按下并持续一段时间后，就认为是重复键入。有时，这对残疾人是个挑战。有些残疾人不能像正常人那样快速按下和释放按键。过滤键可以完全停止重复或者降低重复速度。
3)开关键声响。启用了开关键后，键人信息可能与用户想要的不同。例如，在典型的字处理包中，％INS>键是一个开关。如果键的正常设置是插人字符，那么当键被按下一次然后释放，就会进入“替换”模式，这时键人的字符会替换已在的字符。有视力障碍的用户很难看到这些开关键的状态。为了解决这个问题，可以启用声响，启用和关闭开关键时会发出不同的音调。
4)声响键。为了帮助视力有障碍的用户，还有一种机制在用户敲击键盘时会放出朗读所键入的字符。在有些操作系统中。这种特性作为朗读器实用程序的一部分，但是很多易获得性工具都具有这种特性。
5)用于控制鼠标的箭头键。移动有障碍的用户很难移动鼠标。通过启用这种特性，这类用户就能够使用键盘上的方向键移动鼠标。鼠标上有两个按钮及其操作也可以通过键盘完成。
6)朗读器。朗读器是一种实用程序，提供声音的反馈。由于提供的声音对应键盘和系统事件，因此这个特性被认为是对易获得性很重要的实用程序，可以提高产品的易获得性。

(2)屏幕易获得性。很多键盘易获得性特性帮助了视力有障碍或移动有障碍的用户。这些特性对有听力有特性的用户没有帮助，他们需要屏幕上的额外视觉反馈。下面这些易获得性的特性使用屏幕提高了可使用性。
1)可视声响。可是声响是声音的“波纹形式”或者“图形形式”。这些可视效果通过屏幕告诉我们系统发生的事件。
2)针对多媒体的字幕特性。所有多媒体语音和声音都可以以文字进行描述，在播放语音和声音的同时，在屏幕上显示文字。
3)软键盘。有些有移动障碍和视力障碍的用户认为使用点击设备比键盘更容易一些。软键盘在屏幕上显示键盘来帮助这样的用户。可以通过点击设备，例如鼠标点击屏幕上的软键盘键人字符。
4)采用高对比度的易读特性。有视力障碍的用户在识别菜单项中的一些色彩和字号上存在困难。操作系统一般会提供一个开关选项，切换到高对比模式。这种模式在屏幕上的所有菜单使用舒适的色彩和字号。

(3)其他易获得性特性。操作系统层还提供了很多其他的易获得性，有视力或者移动障碍的用户可能认为键盘和鼠标都很难使用。在这种情况下，应该还提供其他的设备选项。例如，操纵杆可以作为点击设备的替换设备，这种点击设备可以结合软键盘使用，以满足客户的要求。

以上介绍的一些特性试图满足多种有障碍的用户需求。例如，粘贴键在消除按住键要求的同时，还在屏幕上的计算机工具条上显示所有粘贴键的状态。

2．产品易获得性
在为产品提供易获得性特性，需要很好理解基本的易获得性特性，产品应该尽可能实现这些基本易获得性特性。例如，提供多媒体文件对应的详细文本可保证产品具有字幕特性。

对基本易获得性和具有特殊需要的不同类型用户需求的很好理解，有助于编写一些关于产品用户界面设计方面的指南。在为产品提供易获得性的整个过程中。应牢记这些不同类别用户的不同需求，以及他们的能力和面临的挑战。

在各种网站上有很多关于易获得性标准和需求的信息，可以用于收集易获得性需求。可以参考易获得性标准，例如508和W3C，获得较完整的需求。本节将通过几个需求为读者建立背景环境，并解释概念。

需求举例1：必须为视频、音频和图片影像提供对应的文字字幕。

这种需求说明提供图像影像对应文字、为音频部分提供字幕是很重要。在播放音频文件时，提供字幕可以为有听力障碍的用户提供易获得性。增加音频片段可为不能理解视频和图片有视力障碍的用户提高可使用性。在尽力满足这类需求的时候，要了解已有的易获得性工具。例如，不了解易获得性工具的人可能认为为视频提供对应的字幕没有什么意义，因为视力障碍的用户既看不到视频也看不到字幕。但是，如果用户使用像朗读器这样的工具，相关文字就可以朗读出来，产生语音，从而使视力有障碍的用户受益。图9．5是从某网站上截取的带有文字的图片。

在上面的例子中，即使有视力障碍的用户不能看到图片，左侧给出相关图片标签也会对使用朗读器的用户有帮助。因此音频对应的文字(字幕)、图片和直观表示的音频描述，对于提高易获得性是很重要的。

需求举例2：文档和字段的组织要使得不需要特定的屏幕分辨率和模板(叫做风格单)也能阅读。

视力低的用户在使用产品时希望看到大号字体。因此，期望用特定的分辨率和字号在屏幕上显示所有字段的产品会面临易获得性问题。字段和文本之间应该有足够的空白，使得增大字体时出现在屏幕上的消息不会聚在一起。

通常Web页面上的信息采用叫做风格单的模板显示在屏幕上。有两种类型的风格单：内部风格单和外部风格单。内部风格单采用的硬编码形式。指示字段、尺寸以及在屏幕上的位置。当用户希望调整窗口和字号大小时，这会带来问题。最安全的办法是使用外部风格单，产品的程序不应该影响用户定义的外部风格单。

需求举例3：所设计的界面应该使采用色彩的全部信息在不采用色彩时也能全部传达给用户。

不仅仅是视力不好的用户，即使是视力好的但是有色盲症的用户可能在识别色彩上存在问题。因此，产品不应仅仅依靠色彩传递全部的信息。正确的方法应该保留除色彩以外的必要的描述信息，提高易获得性。

需求举例4：降低文字的移动速度，避免使用闪烁文字。

不同人的阅读速度是不同的。阅读速度慢的用户会对一闪而过的文字感到不满，因为这会进一步影响阅读速度。即使视力很好的用户在浏览快速移动的文字的时候也会感觉到不舒服。一些易获得性标准规定。文字闪烁的频率应该在2Hz和55Hz之间。

有些移动有障碍的用户和有神经方面问题的用户移动眼球的速度没有其他人快，还有其他一些健康问题使人不能像其他人一样地快速阅读。移动和滚动文本时。文本移动速度应该与最低的产品用户的阅读能力有关，否则产品应该调整文本移动速度的特性。

需求举例5：在设计用户界面的时候，应降低对用户身体移动的要求．并为用户留出足够的时间。

在设计用户界面的时候，应该特别注意保证降低对使用产品所要求的身体移动．以帮助有移动障碍的用户。应该避免将界面元素散布到屏幕的角落，因为这要求用户把点击设备移动到屏幕的角落，比较费力。例如，在Web页面上如果将仅有的四个字段散布到屏幕的角落并且中间有足够的空白，那么同样的用户界面如果设计成纵向排列会更好。

不仅仅是单个屏幕，整个屏幕集在设计上也要考虑整体最小移动的要求。当使用多个屏幕完成一组操作(比如说确定多个屏幕的用户信息的时候)．需要提供相应的位置序列响应，例如“退出”等功能按钮在不同屏幕的同一位置上，当屏幕改变的时候，点击设备不必再进行移动。

用户界面的设计要尽可能预期用户使用较少的设备完成常规的操作。例如使用键进行字段间的切换，则可以避免使用鼠标点击来进行输入信息。混合使用多种设备，会增加用户界面的复杂性。

如果要求快速响应，则应该通知用户并用足够的时间告知需要更多的时间，有些用户需要更长的考虑和响应时间，因为可能有某些障碍。如果在页面上显示“在5秒内点击确定”会给用户带来压力，应该避免。

以上给出的样本需要都是提高易获得性的例子。类似这样的需求还有很多，在定义易获以上给出的样本需要都是提高易获得性的例子。类似这样的需求还有很多，在定义易获得性的流行标准中，这些需求一般按照提供用户界面所采用的技术分类。针对界面设计所使用的技术选择合适的标准会长远地提高产品的易获得性。

3．易获得性工具