图 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 所示。