简介：自动化测试技术是保证产品质量的重要手段。随着敏捷开发方法的盛行和产品发布周期的缩短，产品对测试的要求也相应提高，因此自动化测试也变得比以前更加重要。冰冻三尺非一日之寒，和产品开发一样，产品的自动化测试系统也需要通过迭代开发不断强化，逐步解决效率瓶颈，更广泛、更灵活的支持产品开发的需求。那么，如何从无到有建立图形用户界面（GUI）产品的自动化测试系统？GUI 产品自动化测试每一阶段的目标是什么？在逐步演化的过程中，我们可能会面对哪些问题？这些又可以如何解决呢？本系列文章希望能够结合我们团队的经验，一一解答。在本文中，您将了解我们如何看待自动化测试，又是如何通过 RFT 来实现简单的测试目标。

　　踏上自动化测试之路

　　在中国，大多数开发者并不会太关心测试，保证产品质量似乎更多是测试者应该关注的问题。所以，当只写过单元测试代码的我告诉面试经理我认为“自动化测试如何重要”的时候，我可以明显感觉到他很开心。

　　当然，我最终还是去做了开发而非测试。我们的团队把 Lotus Notes 这一至今有 21 年历史的 Lotus 的拳头产品从 Windows 平台成功的移植到了 Mac 平台。如果您熟悉 Lotus Notes，您会明白我们的不易。这个的产品的软件架构非常庞大，8.0 版以上的 Notes 基于 Eclipse 平台，而其部分核心逻辑和界面组件仍是由 C 完成的。（如果您希望进一步了解这个产品，欢迎您到 Lotus 专区转转）

　　随着项目的顺利进行，测试团队找到了我们：我们是否有方法在 Mac 上进行自动化的测试呢？如果能够在每天的最新版上自动跑一轮冒烟测试，那么我们将不再需要浪费一个测试者每天半小时的时间来痛苦的重复。

　　这是我们和自动化测试的第一次亲密接触。其后，随着敏捷方法的在项目中的推行和产品发布周期的缩短，我们对自动化测试的要求也越来越高，我们参与了更多系统改进的工作，也接触了更多领域的专家。从一群菜鸟开始，步步走来，我们理解了建立自动化测试系统的不易：和产品开发一样，产品的自动化测试系统也需要通过迭代开发不断强化，逐步解决效率瓶颈，更广泛、更灵活的支持产品开发的需求。往事历历在目，在从本文开始的五篇系列文章中，我们希望和您一起来分享我们的心得和感悟：

　　● 在本文中，您将了解我们如何看待自动化测试，又是如何通过 RFT 来实现简单的测试目标。

　　● 在第二篇文章中，您将看到我们如何像做产品一样去经营测试，构建易于维护的基础系统。

　　● 在第三篇文章中，我们将给您展示我们是如何通过完善的日志功能和使用规则提高分析测试结果的效率的。

　　● 在第四篇文章中，您将看到一些高阶使用技巧，包括如何支持自定义控件、如何实现测试脚本的跨平台以及如何通过开发新的工具来自动的创建自动化测试脚本。

　　● 在第五篇文章中，您将看到我们如何通过 LA 灵活的使用我们的测试资产，实现自动部署自动化测试环境以及分布式测试的目的。

　　好了，现在，让我们正式启动我们的探索之旅。如果您也对 GUI 产品的自动化测试感兴趣的话，请加入我们！

　　了解自动化测试

　　和产品开发一样，构建自动化测试系统同样需要人力物力的持续投入。所以，在我们开始考虑实施之前，需要对自动化系统有所理解，以帮助我们调整预期并设定合适的目标。那么，自动化测试到底是什么？能够为我们带来哪些好处？实施的切入点在哪里？又应该如何持续改进呢？百度百科的“自动化测试”词条对这些方面做了概要性的介绍，推荐您阅读。在此基础之上，我们还希望您能够理解以下一些内容：

　　● 自动化测试如何改善产品质量

　　首先，通常说来，受限于人力资源、产品规模和发布周期，任何大型产品都很难在发布之前对产品的各个方面进行全面的测试。我们只能根据新版本中的代码变更预测影响的功能和行为，并围绕这些影响区域进行重点测试，而对于其他区域测试完整性将大打折扣。这就为产品缺陷的滋生留下了隐患。另一方面，很多的测试都需要机械性的重复执行，比如冒烟测试、回归测试、性能测试、和长期运转测试（Long Run），这些测试的手工执行将占用大量的人力。由于缺乏充足测试的支持，开发者对产品结构性问题修正的风险将大大增加，从而使得开发者更倾向于针对问题的表象“打补丁”而不敢触及根本。

　　通过自动化测试，测试团队可以从这些繁冗的机械重复中解放出来，集中精力加强重点区域的测试力度，也有余力通过制定更完善的测试计划，设计合适的测试用例，改进自动化测试脚本来提高测试的整体覆盖率；从开发者的角度看，随着回归测试成本的降低，开发者也更有信心对产品进行结构性的调整。