SOA 是一种 IT 体系结构风格，支持将您的业务转换为一组相互链接的服务或可重复业务任务，可在需要时通过网络访问这些服务和任务。这个网络可以是局域网、Internet，或者一组不同位置提供的分散各处且采用多种技术，但以类似于安装在本地桌面的方式交互的服务。可以对这些服务进行结合，以完成特定的业务任务，从而让您的业务快速适应不断变化的客观条件和需求。也就是说，SOA 遵循查找、绑定并执行的关键原则工作，非常适合用于满足请求/响应类型的业务需求。
图 1. 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 中所给出的非功能方面进行测试。
表 1. 非功能特征类别
测试类型 测试定义 可访问性 验证访问应用程序功能的能力。 审核与控制 验证检查历史工作流和审核记录的便利性。 可用性 验证应用程序是否能提供服务水平协议（Service Level Agreement，SLA）中规定的高正常运行时间。 兼容性 验证应用程序是否适合之前已有（较旧）的环境。 文档 验证用户指南是否提供了正确的说明。 安装 验证应用程序是否能在所定义的中间件堆栈上工作。 互操作性 验证在更改环境中的重要组件后应用程序是否能正常工作。 负载/容量 验证给定时间应用程序是否能完成所需处理的事务数量。 可维护性 验证在应用程序投入生产环境中后进行维护的便利性。 性能 验证响应时间、吞吐量、并发性等等标准是否满足需求。 可靠性 验证应用程序在与生产环境类似的负载压力下是否能正常工作。 可伸缩性 验证应用程序是否能满足业务不断增长的需求。 安全性 验证应用程序是否具有足够的安全措施，能够防止信息被盗。 服务能力 验证是否能够在不对业务造成任何影响的情况下对应用程序进行调试。 可用性 从最终用户的角度验证应用程序是否可用。
表 2. 可以促进 SOA 应用程序的 NFR 测试的工具综合列表
工具 功能 IBM Rational AppScan 支持以集中方式进行 SOA 应用程序安全性评估，并提供了完全集成的解决方案集。Rational AppScan 能够随着企业体系结构伸缩，支持同时扫描多个应用程序。 IBM Rational Functional Tester 为测试人员提供用于功能和非功能测试、回归测试、GUI 测试和数据驱动测试的自动化测试功能。工具的测试自动化功能也允许进行负载和压力测试。 IBM Rational Performance Tester 捕获响应时间、页面吞吐量和并发性。此性能测试创建、执行和分析工具供团队用于在部署前验证复杂 SOA 应用程序的可伸缩性和可靠性。 IBM Rational Performance Tester Extension for SOA Quality 扩展 SOA 应用程序的性能和可伸缩性测试。这是负载和性能测试与问题分析工具，除了 Rational Performance Tester 的标准功能外，还能够帮助寻找性能瓶颈。它支持进行 SOA 效率问题确定，并为支持部署的 Web 服务提供了广泛的平台监视支持部署，且支持服务器资源数据的收集和可视化。 注意： IBM Rational RequisitePro、IBM Rational Test Manager 和 IBM Rational ClearQuest® 可分别用于进行需求管理、测试用例管理和缺陷管理。
正如前面提到的，SOA 测试中的一个挑战是创建存根和模拟器。存根和模拟器替代生产环境中的遗留应用程序和其他外部应用程序（在生产中作为后端系统）。除了业务领域的知识外，还可以通过分析所开发的应用程序的系统上下文来创建存根和模拟器（请参见图 2）。
图 2. SOA 应用程序的示例系统上下文关系图
在图 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 10000 20000 30000 40000 50000 1000 1000 2000 3000 4000 5000 10000 100 200 300 400 500 100000 10 20 30 40 50 1000000 1 2 3 4 5 随后，进行了应用程序开发之后，处理少量的文件，并根据得到的数据进行推断。可以上载 100 个批次，每个文件中包含 100 个请求，根据其处理此数目所需的时间，可以评估处理表 3 中所示的文件排列和组合所需的时间。
根据可用时间和资源以及确信度，您可以决定基准确定工作的开始和结束时机。检查根据表 3 创建的采样计划（请参见表 4）。
表 4. 采样计划，第 1 部分：测试所推断出来的目标值在示例中以粗体显示文件中的事务请求数量 上载的单个批次中的文件数量 100 10000 20000 30000 40000 50000 1000 1000 2000 3000 4000 5000 10000 100 200 300 400 500 100000 10 20 30 40 50 1000000 1 2 3 4 5 尽管这些目标值可能会在确定基准的过程中失效，但可以帮助规划这个级别本身的测试方法。例如，如果采用 100*40000 个文件的测试用例失败，那么如何进行相关工作呢？可行且实际的做法是，仅仅以预先规划的方式进行处理；例如，如果 100*40000 失败，则尝试 100*37500，然后 100*35000，以此类推。请参见表 5 中给出的更多示例。
表 5. 采样计划，第 2 部分：针对最初目标值的测试失败的情况下的测试方法文件中的事务请求数量 上载的单个批次中的文件数量 尝试-1 尝试-2 尝试-3 尝试-4 尝试-5 100 40000 37500 35000 32500 30000 1000 3000 2750 2500 2250 2000 10000 300 275 250 225 200 100000 20 18 16 14 12 1000000 2 1 - - -
在采用 SOA 的过程中，完全有可能发掘出现有 IT 系统的全部潜力。但中间件堆栈中使用的各个组件可能会造成一些限制，而在运行生产环境中的 SOA 应用程序和遗留应用程序时需要中间件堆栈。为了便于理解，让我们以使用规则引擎为例，该引擎在给定时间只能处理 X 个事务。如果此规则引擎挂钩到 SOA 应用程序，就会造成约束，使性能级别不高于 X。
希望通过本文能够给您组织的 SOA 采用之旅带来一定的帮助。虽然这些最佳实践的应用取决于您当前的 SOA 成熟度级别和改进机会，但上面列表中给出的挑战、非功能特征、工具、实际实现示例能够帮助您确定如何着手进行此工作。而且，NFR 的成功实现最终将在 IT 和业务流程之间形成一个关联关系，而这就是我们的主要目标。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14780828/viewspace-584511/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14780828/viewspace-584511/
扫一扫
1778
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
