在开发面向服务的体系结构（Service-Oriented Architecture，SOA）应用程序时，您的组织很可能会存在需要进行大量的实现和测试工作的非功能需求（NonFunctional Requirement，NFR）。Shiv Asthana 在本文中介绍了在测试作为 SOA 环境的一部分构建的应用程序的非功能需求时需要遵循的最佳实践。

引言

SOA 是一种 IT 体系结构风格，支持将您的业务转换为一组相互链接的服务或可重复业务任务，可在需要时通过网络访问这些服务和任务。这个网络可以是局域网、Internet，或者一组不同位置提供的分散各处且采用多种技术，但以类似于安装在本地桌面的方式交互的服务。可以对这些服务进行结合，以完成特定的业务任务，从而让您的业务快速适应不断变化的客观条件和需求。也就是说，SOA 遵循查找、绑定并执行的关键原则工作，非常适合用于满足请求/响应类型的业务需求。

当由能够解决难点或实现特定手动任务的自动化的策略业务目标和需求对 SOA 实现进行引导时，就可以实现业务转换。这样能够带来诸多好处，包括：

• IT 与业务的一致性。
• 最大限度地重用 IT 资产（不采用拆除和替换方法）。
• 手动和重复性任务的自动化。
• 遵循行业标准和法律法规。
• 填补组织的 IT 竖井 (Silo) 间的空白。
• 持续更改能够方便地映射为新服务的业务流程。

不过，只有在将功能需求和非功能需求包含到应用程序中并无缝集成到生产环境中，才能够实现 SOA 承诺的好处。因此，理想的实现和测试在关键时刻是必不可少的。

NFR 测试的主要挑战出现在 SOA 应用程序在实验室环境中开发或作为软件供应商的新产品投资组合的一部分开发时，在这些情况下，大多数时候生产环境都不可用。其他的挑战包括：

• SOA 应用程序具有大量的内部和不可见组件。
• 要进行测试，需要创建存根，用于替代生产环境中的遗留应用程序。
• 互操作性期望非常高。
• SOA 应用程序在重型中间件堆栈或平台上运行。
• 性能和负载承载能力非常依赖于中间件堆栈和遗留应用程序（在生产环境中）。
• 由于实现 SOA 的目的是为了填补企业级的空白，因此 NFR 的数量可能非常多。
• 早期技术 (SOA) 适配器具有对测试自动化工具的有限访问。
• 根据所解决的业务问题不同，用于应用程序部署的体系结构和组件可能会有所变化。
• NFR 比功能需求的变化频率高。
• 在实验室环境中进行测试需要在测试基础设施方面进行大量的投资。

最佳实践

虽然没有测试软件的最佳万能方法，但可以参考下面根据我的经验给出的列表。除了应对上面的一些挑战外，这些建议还可能会带来其他优势：

• 首先组建测试团队，此团队需要具有在计划使用的目标操作系统和中间件组件上工作的足够技能。
• 仔细分析需求，并找出自相矛盾的需求。
• 了解系统上下文关系图，以确定对存根的需求。
• 确保在项目开始时创建可测试性表格。确定能够测试的 NFR、不能测试的 NFR，以及哪些测试能够实现自动化。
• 创建了可测试性表格后，确定能够通过任何行业标准工具（如 IBM® Rational® Performance Tester）进行测试的需求，或者确定实现测试自动化是否需要自定义软件程序或脚本。
• 尽早规划测试基础设施。可能会需要在各个平台上测试应用程序，如 Microsoft® Windows®、Linux®、IBM AIX® 等。要在以后采购服务器可能会比较困难。
• 估算测试数据需求并确定创建足够的有效测试数据量以进行容量和负载测试。
• 对于您的 SOA 应用程序，请至少对表 1 中所给出的非功能方面进行测试。

注意： IBM Rational RequisitePro、IBM Rational Test Manager 和 IBM Rational ClearQuest® 可分别用于进行需求管理、测试用例管理和缺陷管理。

标识为测试创建存根和模拟器的需求

正如前面提到的，SOA 测试中的一个挑战是创建存根和模拟器。存根和模拟器替代生产环境中的遗留应用程序和其他外部应用程序（在生产中作为后端系统）。除了业务领域的知识外，还可以通过分析所开发的应用程序的系统上下文来创建存根和模拟器（请参见图 2）。

在图 2 中，需要模拟遗留生产系统（蓝色）和外部系统（粉红色）作为存根，以测试新应用程序（功能和非功能测试都需要）。

测试团队可以首先从了解这些系统的功能入手，然后寻找模拟这些系统进行测试的简单方法。在大多数情况下，一个简单的数据库就可以帮助解决问题，但其中应该包括支持所要测试的业务事务的所有表格和示例数据。

这些最佳实践在实际工作中的应用

IBM 名为 Global Business Solutions Center (GBSC) 的团队开发并测试了名为组合业务服务（Composite Business Service，CBS）的 SOA 应用程序，此类应用程序在 IBM SOA Foundation 和中间件堆栈（如 IBM WebSphere® Process Server、IBM WebSphere Application Server、IBM WebSphere Business Services Fabric、IBM WebSphere MQ 和 IBM DB2® 产品）上运行。CBS 是相关的集成业务服务的集合，能提供特定的业务解决方案，并支持在 SOA 上构建的业务流程。

通常，CBS 与客户环境中的其他应用程序和/或服务集成，从而为客户提供所需的业务解决方案。业务解决方案由编排在一起的业务服务组成。也就是说，CBS 不是独立解决方案，而是能够使用一个或多个 CBS 创建的解决方案。

使用 CBS 创建的端到端解决方案的客户目标是银行、医疗、保险和零售等行业及政府部门。考虑到这些行业的本质和规模，您可以发现，SOA 的角色是支持大容量和任务关键型业务事务的处理，以及支持异类环境中的持续业务更改。

这就是 NFR 为何在对客户的业务进行转换的过程中如此重要的原因。目前在 GBSC 中开发的 CBS 已经针对上面建议的大部分需求进行了测试，在某些情况下具有出众的性能基准，如在单个批处理提交中能处理超过 2 百万个事务的能力，以及所报告的各种任务关键型流程的卓越吞吐量和响应时间。

测试人员使用 Rational Performance Tester、IBM Tivoli® Composite Application Manager 以及自主构建的实用工具程序等工具来创建测试数据和实现特定测试用例的自动化。我在这个列表中忽略了常规的测试和缺陷管理工具，如 Rational Test Manager 和 Rational ClearQuest 等，因为此类常规工具用于同时支持功能和非功能测试。

图 3 显示，在示例应用程序中的业务事务 1 的并发用户数量从 1,000 增加到 1,150 时，平均响应时间从 3 秒增加到了 3.2 秒。

图 4 显示，在示例应用程序中的业务事务 2 的并发用户数量从 1,000 增加到 1,150 时，平均响应时间从 7.9 秒增加到了 10.7 秒。

回顾与 NFR 关联的表格时，请注意参考数据极为关键。如果没有这些数字，就没有意义。例如，如果收集并发布性能相关的基准，至少应该提供以下参考数据：

• 测试环境详细信息，如服务器规范（硬件和软件规范）
• 客户端详细信息或用于执行测试的桌面的规范
• 用于进行测试的工具的详细信息（例如，使用了 Rational Performance Tester 生成图 1 和图 2 中的示例图）。

注意事项

虽然测试 NFR 是成功采用 SOA 应用程序所必不可少的步骤，但请记住，如果没有具体的量化要求（在可能的情况下），则可能会遇到麻烦。在实验室环境中进行测试和开发时，如果并发性和容量/负载需求之类的非功能标准未量化，而测试团队进入了基准确定阶段，则更容易出现这种情况。此时，完成项目所需的时间和工作量都会大幅度增加。

不过，如果创建了采用计划并与所有项目涉众进行了共享，则可以缓解这个风险。接下来让我们了解一下如何为项目制定采样计划，您需要在其中确定 SOA 应用程序能够处理的最大事务量。

首先，将所有可以在测试环境中处理的事务排列和组合添加到表格中。请参见表 3 中的示例。

随后，进行了应用程序开发之后，处理少量的文件，并根据得到的数据进行推断。可以上载 100 个批次，每个文件中包含 100 个请求，根据其处理此数目所需的时间，可以评估处理表 3 中所示的文件排列和组合所需的时间。

根据可用时间和资源以及确信度，您可以决定基准确定工作的开始和结束时机。检查根据表 3 创建的采样计划（请参见表 4）。

尽管这些目标值可能会在确定基准的过程中失效，但可以帮助规划这个级别本身的测试方法。例如，如果采用 100*40000 个文件的测试用例失败，那么如何进行相关工作呢？可行且实际的做法是，仅仅以预先规划的方式进行处理；例如，如果 100*40000 失败，则尝试 100*37500，然后 100*35000，以此类推。请参见表 5 中给出的更多示例。

在实现较高级别的非功能能力方面的限制

在采用 SOA 的过程中，完全有可能发掘出现有 IT 系统的全部潜力。但中间件堆栈中使用的各个组件可能会造成一些限制，而在运行生产环境中的 SOA 应用程序和遗留应用程序时需要中间件堆栈。为了便于理解，让我们以使用规则引擎为例，该引擎在给定时间只能处理 X 个事务。如果此规则引擎挂钩到 SOA 应用程序，就会造成约束，使性能级别不高于 X。

总结

希望通过本文能够给您组织的 SOA 采用之旅带来一定的帮助。虽然这些最佳实践的应用取决于您当前的 SOA 成熟度级别和改进机会，但上面列表中给出的挑战、非功能特征、工具、实际实现示例能够帮助您确定如何着手进行此工作。而且，NFR 的成功实现最终将在 IT 和业务流程之间形成一个关联关系，而这就是我们的主要目标。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
• 通过 developerWorks 的 Rational 专区了解用于 SOA 开发的 Rational 工具。
• IBM developerWorks SOA and Web services 专区提供了大量的文章，以及关于如何开发 Web 服务应用程序的初级、中级和高级教程。
• 使用 IBM SOA 沙箱进行试验！通过 IBM SOA 进行实际的亲手实践来提高您的 SOA 技能。
• IBM SOA 网站提供 SOA 的概述，并介绍 IBM 是如何帮助您实现 SOA 的。
• 了解关于 developerWorks 技术事件和网络广播的最新消息。
• 访问 Safari 书店，浏览有关这些技术主题以及其他方面的书籍。
• 查看快速的 Web 服务按需演示。
• 获取本专区的 RSS Feed。（了解关于 RSS 的更多信息。）

• 使用 IBM 试用软件开发您的下一个项目，可下载或索取 DVD 光盘。

• 参与论坛讨论。
• 参与 developerWorks Blog，从而加入到 developerWorks 社区中来，其中包括以下与 SOA 和 Web 服务相关的 Blog：
  • Sandy Carter 的 Service Oriented Architecture -- Off the Record
  • Ali Arsanjani 的 Best Practices in Service-Oriented Architecture
  • Bobby Woolf 的 WebSphere SOA and J2EE in Practice
  • Eoin Lane 博士的 Building SOA applications with patterns
  • Kerrie Holley 的 Client Insights, Concerns and Perspectives on SOA
  • Simon Johnston 的 Service-Oriented Architecture and Business-Level Tooling
  • Sanjay Bose 的 SOA, ESB and Beyond