配置驱动

　　随着产品的不断演化，一些新加入的功能很可能会间接影响到现有的功能区域。比如说，Notes 在 852 中加入了对邮件缓存模式的支持，该功能会自动的下载用户最近的邮件列表到本地，从而可能影响到本地的“最近联系人”列表，进而间接影响到我们的联系人名称自动补全功能。除此之外，Notes 的其他一些新功能配置也可能会与现有功能产生交叉影响，比如 LotusLive 工作模式，站点切换，漫游模式等等。

　　因此，有一两个现实的问题是我们必须要面对的：如何保证软件产品在日趋复杂的配置模式组合之下，现有的功能区域不受影响？如何使我们现有的测试脚本在基本不需修改的情况下能够适应各种复杂的配置组合？

　　我们的答案是配置驱动。与直接通过 RFT 执行脚本不同，我们创建了一个脚本调度器来进行测试集的调度和执行，其工作原理如图 4 所示。在每一个测试集的元数据文件中，我们定义了各个功能配置项的配置参数，以及测试集所包含的测试脚本。针对每一个功能配置项，我们均定义了一个配置管理器来负责控制产品功能的具体配置。脚本调度器会在初始化之后，从测试集元数据文件中依次读取配置项，并调用相应的配置管理器来配置产品的实践功能组合。而后，脚本调度器将顺序执行测试集中的脚本，并生成结果汇总。脚本在执行过程中，也可以通过查询配置管理器来获得当前的功能配置，从而进行相应的微调。

图 5. 脚本调度器和配置管理

　　当有新的产品配置需要处理时，我们只需要实现新的配置管理器，并构造新的测试集来测试新配置项和已有配置项的不同组合对现有脚本的影响。而在脚本方面，我们几乎不需要做任何改动。通过配置驱动方法，我们能够更轻松的面对功能组合的变化。

　　远见——全球化和跨平台

　　对于一款成功的产品而言，支持多个操作系统，支持多种语言版本也是一个迟早需要面对的问题。比如 LotusNotes，我们对 Windows、Mac、Linux 平台均提供了支持，并同时提供了数十种语言的软件版本。为了保证自动化测试系统对于产品跨品台和全球化支持的灵活性，最好在系统设计之初就了解在这两个方面将会面对的一些基本问题。

　　对于全球化，我们需要面对的变化包括：

　　● 字符串资源的本地化

　　我们将需要把产品中所有的字符串资源本地化。这意味着我们的自动化脚本中不能包含硬编码的字符串，同样的，我们需要把脚本中需要验证的字符串资源提取出来，和脚本分离。

　　● 快捷键的变化

　　并不是所有语言版本中产品的快捷键都是一样的。对于中文和英文系统而言，“编辑”菜单（Edit）的快捷键都是“Alt+E”，而在意大利语系统中，其快捷键却是“Alt+M”（对应意大利语 Modifica）。因此，快捷键也是我们在应用对象层中需要通过抽象独立出来的对象。

　　● 时间、货币格式变化

　　不同的语言环境下，时间、货币的格式会发生相应的变化。比如“2011 年 6 月 7 日”在英文系统中可能就表示成“2011/6/7”。因此，我们在进行时间和货币的比较时，不能直接使用字符串进行匹配，而要进行适当的转换。

　　● 界面布局的变化

　　一方面，由于不同语言的字符串资源的长度差异，为了更好的显示这些字符串，不同语言版本的产品在界面布局上会有细微的调整。另一方面，如果我们的产品需要支持 Bidi 的话，界面的差异将会更大：在阿拉伯世界中，GUI 界面的布局是从右向左的，和我们常见的中文或者英文系统恰恰相反。因此，我们在编写脚本的时候，最好不要依赖于界面元素的绝对坐标位置。

　　RFT 对全球化提供了良好的支持，在 developerWorks 上，有多篇文章对这一话题进行了讨论，如果您感兴趣，可以参考本文附录中所列举的参考文献。