阅读 IBM 的“Ready-for-Rational”合伙人，Arsin 如何利用 IBM Rational Functional Tester 以及 Arsin 自己的产品为 SAP 集成应用软件提供测试解决方案。
　

 在假设您需要可以像配置并定制 SAP 全景那样迅速地配置并定制的测试解决方案的情况下，随着环境的变更，SAP 集成应用程序允许您快速地配置并定制业务流程。在本文中，我们将向您展示如何使用 IBM® Rational® Functional Tester 工具集和来自 IBM Ready-for-Rational 合伙人，Arsin，的工具。Arsin 的 QA Mapper、Effecta Validation Engine，和 Arsin Support 及升级工具包允许您开发面向 SAP 全景的可复用的、可重复的，并且很容易维护的 SAP Test Automation 回归库，包括定制的应用程序和进入或输出（Inbound/Outbound）接口。

我们将讨论：

1. 结构化的 SAP 测试方法
2. SAP 当前的测试自动化范型及其挑战
3. 用于 SAP 测试自动化的新解决方案的需求
4. 与 IBM Rational Functional Tester（RFT）集成的 Arsin Packaged Test Automation for SAP 如何帮助解决这些难题。

我们将分析 QA Mapper、Effecta validation Engine 和 Arsin Support 及升级工具包，连同 RFT 的功能，从而收集测试需求、定义并构建测试用例、构建测试规程，并执行和分析报告。使用 RFT 和 Arsin 的工具能让您大大地扩展测试范围，较大地压缩测试进度，并减少测试成本。

结构化的 SAP 测试方法

涉及了超过 45000 个表，超过 100000 个字段，以及它们之间上百万的关系，SAP 实现提出了一些 QA 领域最引人兴趣且最困难的挑战。网络密集的系统是极度集成的，并且一般与企业中的每个业务流程都相连。要处理这样一个极广大的系统，QA 工程师必须谨慎地处理 SAP 应用程序。

利用十多年来为无数行业中的大型客户基础测试 SAP 系统的经验，我们已经开发了测试成熟度评估及改进框架，以提出一种有组织的，结构化的 SAP 测试方法。该框架有三种方法，它们提供过程改进、知识管理和测试自动化，如下所示：

1. 过程改进。过程改进处理当前测试成熟度模型的评估，并且开发计划来将测试成熟度模型提高到下一层，并实现它。拥有标准化的模板、定义良好的过程、清楚的协议，并且没瓶颈的成熟的测试过程为完整的且全面测试过的 SAP 系统做准备。通过将当前的测试成熟度模型与行业标准进行比较，并且识别差距并着重于它们，可以改进测试成熟度。
2. 知识管理。知识管理处理随时收集的 QA 知识的制度化。传统的 SAP 系统测试依赖于 SAP 系统的功能及技术顾问，了解关于主题的专家经验，从而处理各种各样的实例。在此阶段，为关键的业务流程构建测试工件库，用于回归。以下的测试工件被编制为：
   • 测试需求
   • 测试用例
   • 测试规程
3. 测试自动化。在知识管理阶段，当在回归库中编制了测试工件之后，就准备好将它们自动化。然而，在将它们自动化之前，对这些测试工件进行自动化可行性，自动化所需的工作、业务流程使用的频率，及业务的寿命的分析。在决定利用 Arsin 的 QA Mapper 作为测试工件存储库进行自动化之后，就利用 RFT 开发执行组件，并且利用 Arsin 的 Effecta Validation Engine 配置验证组件来自动地执行它们。

本讨论的其余部分着重于结构化的 SAP 测试方法的测试自动化方面。我们相信 RFT 结合 Arsin 的 QA Mapper 和 Effecta Validation Engine 令 SAP 测试彻底、全面、简单，且节省成本。

SAP 实现中测试自动化的重要性

SAP 全景在不断地变更，这是由于对来自 SAP 的 SAP 模块的变更、客户公司中的业务流程变更、对系统环境的变更、对与 SAP 连接的应用程序的变更，以及许多规章法令。

图 1 例举了在 SAP 环境中不断运转的相关性。

图 1：SAP 环境中的相关性

为了跟上这些变更，必须对 SAP 系统进行彻底地测试。对于每个变更，都有需要确保稳定性而执行的测试用例的回归库。当手动执行时，每个测试需要时间和努力，比较起来，执行自动的测试需要非常少的时间和努力。自动化还帮助让大多数测试资产可复用。

当前的 SAP 测试解决方案及其局限性

如今，市场上的现有 SAP 测试模型初步地使用自动化，涉及以下方面：

验证：在大多数情况下，可用的 GUI 工具用于将测试执行自动化，这只占总测试工作的大约 25%。验证占该工作的 75% 以上，而且利用 GUI 测试自动化工具去除数据是很困难的。通过基于测试自动化工具的特定级别的验证是可能的，然而，撰写该验证的脚本要花费很长时间，并且任何的变更都需要在首次实现之后的许多编码工作。

数据管理：传统上，用于测试的数据是在电子表格中获取并维护的。通过该数据进行搜索和排序是困难的，因为是维护跨用户和位置的数据一致性。这种困难在随着要维护的大量测试数据的增加而增加。此外，SAP 元数据与其相应的测试数据之间不存在智能的联系。

管理变更：对 SAP 实现的变更发生在重新配置或添加定制构建的组件（程序）的过程中。在这些情况下，需要定期地变更用于自动的测试执行的脚本，这是很困难的。此外，当将 GUI 工具用于自动化时，需要经常地重做 75% 的工作，从而跟上对 SAP 系统的变更。

处理这些局限性

上面介绍的局限性需要可以处理这些问题的新解决方案。我们提供了包含以下组件的解决方案：

• Arsin QA Mapper
• Arsin Effecta Validation Engine
• IBM Rational Functional Tester

如图 2 所示，解决方案的主要组件是 QA Mapper（测试工件存储库）、RFT（自动地执行测试用例的引擎），及 Effecta （自动验证引擎）。用于 SAP 程序和事务的元数据作为执行组件（Execution Component）存储在 QA Mapper，RFT 读取它们来执行事务。RFT 推动执行组件用使用来自 QA Mapper 的元数据的包装脚本来执行测试用例。当执行测试用例时，该脚本拿出与测试用例相连接的测试规程，并执行组件或事务。对于验证，关键的信息，例如销售订单数或交付数，被传递给 Effecta 验证引擎，然后拿出与那些来自 SAP 数据库的键相应的实际值，然后将它们与期望结果进行比较。

图 2：Arsin SAP 测试解决方案的主要组件

图 2 中展示的解决方案处理了早期模型所带来的局限性。现在我们将详细地分析此解决方案。

测试数据管理

在 QA Mapper 产品中，测试数据是在关系数据库中进行管理的，这使得跨多用户的搜索、排序，和一致性维护都很容易。QA Mapper 还根据可能复用的数据集对数据进行维护。这些数据集是分别创建的，以便可以在各种测试用例中复用它们。QA Mapper 能够创建可以通过基于 web 的接口简单地维护的具体工程的且安全的测试数据集。此外，输入测试数据的创建是通过对来自在测系统的主数据的自动导入来加速的。

管理变更

该解决方案提供了不需要任何脚本变更的完全可定制且可配置的组件。使用实际数据之上的包装脚本和元数据意味着，对于屏幕上任意的附加的字段，只有元数据需要添加到数据库中。该特性节省了许多时间和工作量。

验证

Arsin 的验证测试引擎，称为 Effecta（参见右边图 2），推动了 QA 团队需要执行的每个测试用例的自动化的验证。验证令差不多 75% 的测试工作在手工场景下进行。通过 Effecta 的自动化减少了这一时间，并且生成了关于哪些验证失败了的详细报告，因而简化了失败情况下的调试过程。该工具还生成审计可追踪、可重复，且可伸缩的 QA 测试结果。

业务对象的配置和定制

将验证自动化的规程涉及业务对象及验证组件的创建。业务对象是在 SAP 中的事务中使用或受到影响的所有表，以及这些表通过字段建立的关系的聚集。它构成了可以确定来自一个表的哪些字段与另一个表中的字段相关联的连接平台。业务对象是容易配置且可扩展的。当事务必须具有新功能或包含新表时，可以通过添加必需的表和新的关系来扩展基本的业务对象，如图 3 所示。

图 3：通过添加必需的表和新的关系来扩展基本的业务对象。

验证组件的创建、配置，及定制

验证组件是规则的集合，这些规则参考了必须被验证，从而确保 SAP 系统的稳定性和一致性的字段。验证组件使用业务对象来构成关联底层的 SAP 表的平台。这些组件中的验证规则将表字段中的数据与来自不同数据源的预期数据进行比较，包括表字段和不变值。

验证组件通过配置进行维护，并且不涉及任何脚本。定制涉及变更规则，它们是选择要验证的表字段，以及选择对于每个字段的预期源的操作。

在完成验证时，Effecta 引擎提供详细的报告，如图 4 所示，它精确地指出哪些字段没有遵守验证规则。这有助于故障跟踪和修复。

图 4：精确地指出哪些字段没有遵守验证规则的详细报告。
点击此处放大

进入或输出接口验证

除了为 SAP 中的事务提供验证以外，Effecta 还提供进入和输出接口验证。这些接口中的传输通常是 Intermediate Documents（IDocs）、文本文件，等等的格式。当要验证它们时，Effecta 从它们中析取数据并根据 SAP 中的表和字段验证它们。

产品支持及支持包验证

当在升级过程中测试产品支持及支持包时，有两个场景：一个是进行变更之前的场景，一个是变更之后的场景。在这些情况下的测试的目标是确保由于变更，系统仍旧稳定。

在这些情况下，当执行事务时，更新表，创建文档及 IDoc。在变更前后要对这些文档、表，及字段进行比较。对于一个事务，例如销售订单的创建，可能有十五个表，以及将要在每个表中进行比较的十到十五个之间的字段。手工比较这些需要相当多的时间和努力。Effecta 拥有自动的工具来比较表、IDoc 和文档，这有力地减少了这些情况下的时间和工作。这些工具还向测试人员提供描述结果的详细报告。

Arsin 目前正致力于为 Oracle 和 Sterling 平台构建 Effecta 验证引擎。

结束语

在 SAP 测试中使用自动化的好处有很多。测试自动化增加了测试覆盖面，从而减少了循环时间，并且在开发周期早期进行有效的故障检测。由于测试自动化为复用性而设计，所以消除了日常的任务，并且减少了所有权的总成本。测试自动化更精确且更一致，并且是标准化的特性报告，能够跨 QA 环境进行清晰的测试分析。测试自动化可以通过最小的努力进行部署。

参考资料

• 参与论坛讨论。
• 您可以参阅本文在 develperWorks 全球网站上的 英文原文。
• 现在开办了一个特别为 Rational Edge 的文章创办的 新论坛，现在您就可以分享您对本文或本期杂志或以前杂志中的其他文章的想法。阅读世界各地您的同行们所说的内容，生成您自己的讨论，或者加入正在进行的讨论。单击 这里 开始。
• 全球 Rational 用户组社区