测试易访问性

    RUP将测试描述为一种在软件开发生命周期中不断地确保质量的方法。及早测试可以减少完成和维护软件的成本。测试最初源于需求，但它们也源于其他来源。例如，在您发现并纠正具体错误情况之后进行测试。对于当今的复杂软件应用程序，自动化工具对生成测试数据并运行和分析测试是必要的。

    如果您已经利用整合到用例和情境中的具体角色来获取易访问性需求，如我们上面描述的，那么您可以使易访问性测试成为您继续的生命周期测试活动中的完整部分。IBMRational的JimHeumann描述了一个方法，由用例和情境生成测试用例。如我们早期注意到的，每个用例都有一组分别表示主要的和次要的事件流的情境。测试人员可以为每个情境获得一个或多个测试用例并将数据值附上。

    对于根据功能需求评价产品来说，这些测试用例是有用的。它们还为用例提供具体的用户界面，这使得您对照易访问性需求来评估产品，您可以让您的测试基于源自一组角色的易访问性评估点。

    如我们所见，您可以为每个用例和其人类参与者指派一组角色，来为易访问设计生成整合的方法。不论您在测试用例中使用的角色是什么，测试数据都将是一样的，因为对于主要和次要角色来说事件流是一样的。然而，此要角色扩展并增强了情境的可用性需求，且这些额外的需求要得到检查。

    要运行测试用例，构建基于主要角色的测试数据，然后根据次要角色检查附加的易访问性就足够了。例如，如果您的主要用户使用鼠标和键盘进行可视化交互，使用屏幕阅读器和键盘导航的次要角色会添加以下需求：

    通过平台的易访问性API，要显露出所有单元。

    图像要有文本的等价物。

    通过键盘要能访问所有单元。

    对于听力损伤的次要角色，您会确保为声音输出提供音量调节功能，为视频剪辑提供字幕，等等。对于无语言或学习能力的次要角色（也许看不见），您要对产品的易用性、在线帮助文本的阅读级别等等特别关注。

    利用自动和手动测试来验证易访问性

    同大多数测试一样，将您对易访问性需求的测试自动化是有利的。用自动测试工具，您可以在开发生命周期中重复运行回归测试，以确保在您进行变更之后，系统体系结构和用户界面仍然健全并且易访问特性仍然完好无缺。理论上，您甚至可以生成能够自动实现测试用例（或一部分）的脚本。然而，易访问性不是所有方面都支持自动测试。很重要的是不要严重依赖那些适合此种测试的方面。

    RUP的测试建议由单元测试、整合测试、系统测试和试点测试组成。对易访问性需求的测试技术在这些领域大概是一样的（除了试点测试，其涉及了真人用户的测试）。尽可能早地开始测试是合适的。由开发人员所执行的单元测试使您在早期辨别并修改问题，这样做既降低了成本又降低了项目风险。改正您通过随后的测试所发现的问题要涉及不只一个人——因此，更多间接营业成本。

    在许多项目中，开发人员在书写代码的同时书写单元测试——或者有时甚至提前（如在测试驱动开发中）。如果单元测试相当小并且只覆盖必要的功能需求的话，这种方法是可行的。如果开发人员不得不为每个测试用例中的易访问性评估点书写代码，那样会添加许多工作。幸运的是，易访问性需求对运行在同一平台上的测试用例和功能单元是公共的。大多数易访问性需求与用户界面设计有关，并且对拥有类似用户界面的用例是一样的。因此，开发人员可以在项目测试用例和用例上复用评估点，利用当前的测试工具来自动地生成代码并根据易访问性评估点验证产品。

    此外，用于易访问性检查的专门的商业和免费工具可以帮助简化并自动化测试过程。大多数工具以指导方针和规则为基础评估Web页面。一些工具允许您配置评估点集合来应用到应用程序中。

    易访问性评估点是具体到特殊平台的检查点的最小单位，不幸的是，不是所有的点都可以由计算机进行测试。例如，计算机可以测试文本等价物对图像是否可用，但不能测试文本的质量或者甚至确定文本是否是无意义补白。

    然而，一旦人类做出了决策，计算机就会接管，执行统一的，重复的任务。例如，如果一个测试人员手工地验证具体图像所对应的具体文本，那么他可以安排计算机来验证应用程序中对应图像副本的同样的文本。然后，在后继的测试运行中，测试人员将不需要再观察文本等价物了，除非从最近一次测试运行开始图像或文本改变了。

    不幸的是，很少有工具关注图形用户界面，并且大多数没有我们提到的成熟。然而，该情况应该随着对生产力工具的需求而改进，以支持易访问设计的增加。

    从角色中得到易访问性评估点

    确定易访问性评估点不是微不足道的事。这些点应该基于用例所涉及的角色和使用的上下文（参见图3）。如果您向一些或所有用例中添加角色，那么您也应该向相关的测试用例中添加检查点，以确保系统对新角色是具有易访问性的。

    图3：测试用例源于用例情境，评估点源于角色并包含于测试用例中 

    理论上说，您可以使用自动化工具取得基于角色和使用的上下文的易访问性评估点。要使其可行，您需要角色和易访问性测试工具之间的无逢连接。该方法也会提出关于评估点所出自的标准和指导方针的具体需求。出于讨论的目的，我们将假设指导方针和标准由一组开发人员用于产品检查的评估点组成。当然，真正的标准和指导方针实际上包含了需要由开发人员转化为具体平台上的评估点的一般易访问性原则。

    让我们再假设指导方针和标准阐述了每个评估点如何影响不同类型用户（角色）的可用性，并将用户利益分为：基本的、重要的，或者有益的。如果系统没有满足基本的评估点，角色根本不能够使用该系统。如果没有满足重要评估点，角色可以使用产品，但只能付出很大努力，而以效率低下的方式。如果系统实现了有益的评估点，产品对角色会更有用，尽管产品在不满足标准的情况下仍旧具有功能。

    在某些情况下，评估点实际上会使特殊的角色更难使用产品。我们还可以定义三个程度的劣势：排除、阻碍，和不便。排除意味着如果满足了评估点，角色根本不能使用产品。阻碍意味着角色可以使用产品，但只有付出相当大的努力。不便意味着产品对角色的可用性较小，但角色可以在没有重大困难的情况下使用产品。