开始之前
Rational Functional Tester 是一个基于 GUI 的自动化和回归测试工具，用于对跨各种组织的许多产品的测试场景执行自动化。测试团队使用它创建一组自动化脚本。这样一组脚本也称为一个自动化套件。然后，测试团队会使用各种自动化框架运行这些自动化套件。一些人使用在 Rational Functional Tester 中构建的标准框架，另一些人则根据需要创建自己的框架。
在不同框架上工作并使用 Rational Functional Tester 的团队有时会遇到问题，这些问题要么是其框架中所独有的，要么是大多数框架中普遍存在的。但是，一些问题非常普遍，以至于它们的解决方案可为其他组织的人提供帮助。一个示例是手动合并不同时区和地区的不同成员在自己的工作区依照自己的对象映射创建的自动化脚本。
合并脚本看起来是一个简单的过程，但在没有配置管理工具的情况下，它会成为一项困难的工作。您必须让每个脚本按预期方式运行，并且不需要更改自动化套件的现有文件夹结构。但是，如果您需要更文件夹结构，该怎么办？
本文将帮助您了解并克服在手动合并自动化文件夹或调整其结构时会遇到的问题。通过在自动化 Rational Software Architect 产品期间捕获的真实示例，我们将解释这些技巧的使用。这是使用 Rational Functional Tester 进行测试的这些场景中所测试的一个应用程序。当 Rational 软件系统验证测试 (SVT) 团队遇到此问题时，他们必须浏览各种论坛来查找有效的解决方案。本文以解决了该问题的研究结果作为基础。
通过分析真实的示例，本文将帮助读者轻松地与其场景相联系起来，进而帮助他们使用手动合并 Rational Functional Tester 脚本或调整自动化文件夹结构的技巧/诀窍。
本文还将展示如何使用 Rational Functional Tester 应用编程接口 (API)，避免在合并期间携带包含脚本的测试对象映射文件的麻烦。
从本文中受到的启发
Rational Functional Tester 已成功用于自动化 Rational Software Architect 的开发场景。该自动化套件是在整个测试团队的帮助下创建的。因为 Rational Software Architect 拥有众多要测试的功能，所以创建来自动化 UI 场景的测试人员脚本形成了一个包含 250 多个脚本的测试套件。测试团队中几乎每个人都有一些功能并完成了自己的部分工作。这增加了覆盖面，但也增加了脚本格式的不一致性。一些脚本遵循使用某种确定的文件夹结构的规则，而一些脚本稍微进行了更改。
创建 Rational Functional Tester 脚本后，任务很简单：将新脚本合并到现有的自动化套件中。事实证明，这个看似简单的任务是最大的挑战，这激发了我们编写这个案例分析。现有的自动化套件是在一种预定义的文件夹结构中创建和维护的。当我们尝试将新脚本与旧套件合并时，出现了许多问题，这迫使我们尝试了多个解决办法来让合并生效。
严格的时间限制和工具经验的缺乏导致我们生成了主要基于对象映射的脚本，只要对象分层结构发生任何变化，这些脚本就很容易出错。所以我们必须返回去检查所有脚本，引入 Rational Functional Tester find() API 来查找几乎所有对象。这成为了我们撰写本文的第二个动机。
在以下各节中，我将使用我们对 Rational Software Architect 自动化套件的案例分析，介绍如何克服在手动将 Rational Functional Tester 脚本合并到现有的自动互框架中时遇到的任何阻碍。
问题和解决方案
在本节中，我们介绍每个问题，然后介绍避免该问题的解决方案或途径。
问题 1. 无法将新创建的脚本导入自动化套件中的一个已定义的文件夹中
Rational Software Architect 示例
Rational SVT 团队有一个文件夹结构，它将所有脚本保存在此分层结构中的 testcases 下： ...\com\ibm\xtools\rsa\testcases\
对于新添加的功能，我们在 Rational Functional Tester 中的同一级别上创建了新的文件夹，我们还尝试在此级别导入了新创建的脚本。但是，Rational Functional Tester 仅允许在根级别导入脚本，不允许将脚本导入到特定的文件夹中（如图 1 所示）。
图 1. 尝试将 Rational Functional Tester 脚本导入一个特定的文件夹中
查看本栏目更多精彩内容：http://www.bianceng.cnhttp://www.bianceng.cn/Programming/extra/