同样，我们的测试脚本想要支持跨平台的话也有诸多因素需要考虑，比如：
● 界面元素差异
我们的 GUI 产品在不同的操作系统上需要支持系统的原生界面，而这些界面元素又有着显著的差异。比如，在 Mac 系统中，窗体的“最小化 / 最大化 / 关闭”按钮是在窗体的左上角，窗体间共享同一个菜单栏而没有独立的菜单栏，滚动条上的“向上 / 向下”按钮缺省位于滚动条的两侧而非底部，等等。随着现代操作系统的演化，不同系统间的界面差异在渐渐扩大。比如，Windows 中新的 Ribbon 界面在 Mac 上就没有对应的实现。
● 系统对话框
不同系统的系统对话框是不同的，比如说“打开文件”对话框和“打印”对话框。
● 快捷键
相对于全球化而言，不同系统间的快捷键差异更大。
● 系统特性支持
作为一个系统原生产品，我们需要支持一些系统所特有的特性，比如 Mac/Linux 下的 Space，Windows 的 Jump List 或者 Mac 的 Dock Icon 功能。对于这些特性，我们往往需要构建专属的测试脚本进行测试。
跨平台给我们带来了更大的挑战，而 IBM 框架为我们应对这一挑战提供了坚实的基础。在了解平台间差异的基础上，我们在应用对象层对不同平台间的差异进行了封装，包括窗体、菜单、系统对话框、快捷键等等。这使得我们在测试脚本层不用再面对这些差异，简化了脚本的复杂度。
总结
在本篇文章中，我们简要介绍了作为产品测试系统基础的 IBM 框架，编写脚本的注意事项，利用数据驱动和配置驱动技术扩展脚本的支持范围，并讨论了支持跨平台和全球化需要关注的一些要点。以此为基础，您可以开始考虑为您自己的产品构建自动化测试系统了。在本系列的下一篇文章中，我们将讨论自动化测试的另一个要点：如何更高效的记录和分析执行结果，敬请期待。
相关链接：
