随着企业集成解决方案的出现，验证每个系统组件的可操作性变得前所未有地重要。在对已经投入生产应用的系统进行故障排除时，操作团队面对着各种各样的挑战：
- 要测试跨越多个物理节点和位置的分布式系统组件的可操作性，通常需要每一方团队的联合工作。
- 系统组件可以使用不同的技术来实现，并部署在不同的软件和操作系统平台上。组建一个熟练的操作团队，其成员位于不同的位置，并具备完整的必需技能集，这是富有挑战性的任务。
- 对生产环境的访问通常同时受到物理和过程约束的限制。这些限制没有为生产环境中的问题诊断提供足够的权限。
- 要验证总体系统对服务级别协议的遵从性和验证目标服务质量，将要求解决方案为提供此类措施做好准备。
与解决方案的基础实施部分不同，单独使用系统管理工具无法在功能级别验证自定义应用程序的这些方面。解决方案提供商必须提供某种方法，以测量和报告其系统组件的操作和功能方面。
除了面对所有这些挑战，操作团队通常还不止负责一个系统。为了简化其工作，需要将操作团队与系统的细节隔离，以便他们能够集中于一般操作任务。开发团队可以提供某种方法，用于通过遵循一组与组件内部细节无关的已定义的说明，从而以“黑盒”方式测试系统组件的可操作性。
 |
|
将测试组件嵌入在其他功能性系统组件中，只是为了使整个系统在部署期间（甚至在投入运行之后）可测试。图 1 显示了测试组件与其对应的功能组件之间的关系。
图 1. 将测试组件嵌入其他系统组件
测试组件将在系统范围的测试场景执行过程中进行调用。除了使用系统的功能组件的功能使用者外，嵌入的测试组件还将具有自己的使用者。
图 2 显示每个组件具有两个接口：一个提供系统功能，另一个提供系统可测试性。取决于测试组件如何公开其接口，可以将测试客户机实现为：
- 一组 API 调用——如果将测试接口公开为 API
- 命令——如果将测试接口公开为一个命令行工具
图 2. 通过其功能和测试接口使用组件
对于由您的系统使用的外部操作组件，例如新闻 Feeds 和支付网关，您也许无法在那些组件端添加测试组件。但是，您仍然可以在自己的系统中添加测试客户机，以验证那些外部系统的可操作性。在这种情况下，测试客户机的测试可以基于外部组件的功能接口，或基于可由测试客户机访问的外部系统上的某个基础设施资源。
采用测试组件会在体系结构、实现和操作期间影响项目生命周期。图 3 显示了测试组件在项目进展过程中的发展。
图 3. 测试组件在项目生命周期过程中的发展
标识和布局
在处理某个解决方案时，架构师标识在系统可操作时必须进行测试的关键功能或方面。他们还设计对应的测试组件在整个系统中的布局。
实现
实现阶段按体系结构计划进行，以实现已标识的测试组件。实现将基于测试组件的实现方式，从而提供操作指导以测试特定的系统方面。
操作
在执行操作步骤之后，操作团队可以收集有关测试组件布局、实现和有效性的反馈，以检测系统故障和其他操作影响。将反馈与将来的体系结构整合，或同时维护同一项目的当前体系结构的将来迭代。
下面几个部分将讨论在架构、实现和操作集成测试组件时要考虑的因素。
体系结构决策应该考虑到测试场景、将测试组件布局在何处以及要使用哪些技术。
测试组件的布局应该能够覆盖不同系统组件之间的集成路径。与定义普通测试用例时的情况相似，这些场景应该处理不同的集成故障可能性，例如连接性问题。
验证企业解决方案的连接性非常重要，但是还可以使用相同的组件来验证其他方面。可以覆盖系统组件的某些功能或服务质量属性。取决于系统的性质及其服务级别协议，可以部分或全面地测试每个方面。例如，在 ATM 或销售点（point-of-sale，POS）解决方案中，最常见的故障类型来自于连接问题。相应地，相对于功能，可更多地将重点集中于网络和连接性。
放在系统中的测试组件的数量高度依赖于宿主系统组件中的节点数量，以及物理部署单元的数量。要考虑的一个要点在于，测试组件应该与其余系统组件共处——在相同的运行时条件下——以便它们能够捕获可能导致某些系统组件误操作的故障。
要使测试组件最有效，应该使用与用于实现系统组件的相同技术来实现它们。通过与其他系统组件共享系统资源，测试组件可以检测到系统故障。例如，如果是基于容器的技术，测试组件可以报告宿主容器停止提供的服务。
在实现过程中，务必了解将需要的输入，以及用于支持该实现的工作。
用于实现测试组件的典型输入包括：
-
组件模型
- 指定测试组件的布局和实现技术，以测试系统的功能方面。 非功能需求
- 帮助确定要测试的目标服务质量属性，以确保遵从服务级别协议。 操作模型
- 产生测试组件的适当物理布局，以测试操作故障。
实现团队负责提供相关信息，以告诉操作团队如何在生产环境中验证系统可操作性。
在此情况下，拥有带跟踪矩阵 (traceability matrix) 的文档是非常有帮助的，该文档可表明什么功能、组件、连接或服务质量属性正在由使用哪些测试组件的哪些测试场景进行测试。
测试组件是要实现的附加组件，因此它们将需要附加的设计和代码编写工作。实现团队还应该对操作团队进行培训，使他们了解对所实现的系统进行测试的步骤。
在操作阶段，结果报告、资源使用情况、集成问题和开/关切换功能非常重要。
测试场景应该易于运行，并且应该报告结果，而没有特定于系统甚至特定于技术的知识要求。由于可以使用不同的技术来实现测试组件，因此它们还应该跨这些技术提供一致的操作界面。例如，命令行工具可以运行同一组命令并产生相同格式的日志。
从资源使用角度来看，测试组件应该具有最小的内存占用空间，并且使用尽可能最少的系统资源。处理器、内存和 I/O 不应该由于应用测试组件而受到显著影响。
取决于操作团队使用的系统管理工具，可以将集成测试场景与其他系统检查集成在一起。这要求测试组件提供一个可从系统管理工具中调用的接口。例如，如果系统管理工具允许使用 Java™ 编写用户出口 (user exit)，则测试组件应该提供将从此类用户出口中调用的 Java API。最通用的方法是让测试组件提供一个命令行接口，系统管理工具可以使用该接口而不必进行 API 级别的集成。
有了集成之后，测试组件可以在系统管理工具使用的存储库（例如数据库或日志文件）中报告测试结果。如果需要进一步的报告遵从性，测试组件可以使用公共事件基础设施（Common Event Infrastructure，CEI）在运行时报告测试结果。
此类集成的另一个作用是能够与其他定期系统检查一起计划集成测试场景。
应该根据需要开启和关闭测试组件以节省系统资源。应该只允许从具有受限访问权限的管理域进行切换。切换功能的实现应该是测试组件实现的一部分；它高度依赖于用于实现组件的技术。
例如，在企业应用程序中，它可以是在应用程序启动时加载的属性文件中的一个属性。另一种替代方法是在应用程序服务器级别定义一个环境变量，并根据需要设置该环境变量，以允许应用程序在运行时查询其值。
图 4 显示了一个带有表示层和后端层的简单 Web 应用程序。表示层是一个 Web 模块，由一组网页组成，该组网页由一组控制器所控制。后端是一个 EJB 模块，由一组 Enterprise JavaBeans 组成，该组 Enterprise JavaBeans 由表示层 Web 模块的控制器调用。表示层和后端将部署在两个不同的应用程序服务器节点上。
图 4. 示例嵌入测试组件
测试组件的布局方式允许它们测试每个系统组件，并且还允许将它们打包在其他系统组件中。测试页被实现为简单的 JavaServer Pages (JSP)，并且能够调用其他页面所使用的功能控制器以及一个附加的测试控制器。测试控制器被实现为一个 servlet。它可以调用后端 EJB 和一个测试后端 EJB。
表 1 显示了使用这些组件的可能场景。所有场景都从使用浏览器或诸如 IBM Rational® Functional Tester 等自动化工具来加载测试页开始，其中自动化工具可以对这些场景进行记录。
表 1. 可能的测试场景
| 场景 | 描述 | 使用的组件 | 测试的方面 |
|---|---|---|---|
| #1 | 运行测试页 | 测试页 | Web 容器提供页面的能力 |
| #2 | 运行测试页以调用功能控制器 | 测试页、功能控制器 | 功能控制器可操作性 |
| #3 | 运行测试页以调用测试控制器，其中测试控制器又调用后端 | 测试页、测试控制器、测试后端 | 到后端节点的连接性/EJB 容器提供 EJB 的能力 |
| #4 | 运行测试页以调用测试控制器，其中测试控制器又调用功能后端 | 测试页、测试控制器、功能后端 | 后端可操作性、到后端节点的连接性 |
测试组件的布局和实现可能比这里所示的情况更加变化多样。例如，如果有测试应用程序服务器及其 Web 容器的另一种替代方法，您可能不需要测试页。在这种情况下，可以将测试控制器替换为某个命令行工具，后者充当后端的 EJB 客户端。或者，除非您希望测试无法由功能后端 EJB 捕获的后端节点的某些特性，否则您可能不需要测试后端。例如，您可能在后端节点上跟踪响应时间。
该示例实现显示了从同一点开始的所有测试场景。其他实现可能将每种场景保持独立，以避免在集成测试中发生单点故障。如果发生此类单点故障，则无法执行进一步的场景——从而阻止检测其他系统缺陷。
企业集成解决方案可具有嵌入的测试组件，这些组件可在具有最小操作开销的情况下增强解决方案在生产环境中的可测试性。实现可以具有多种形式。嵌入的测试组件会影响体系结构、实现和操作，因此应该在项目的早期阶段引入，以帮助改进总体开发生命周期。
|
| ||||||||||||
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
