我们在统计自动化成本时，往往发现执行维护阶段终会超过自动化项目开发阶段。

　　我们应该怎么做自动化项目

　　看下我们的目标：

　　● 快速开发与交付

　　● 高可用维护

　　选择一门语言：

　　根据实际自动化需求，我们选择了ruby作为基础开发语言。 实际运用中，推荐使用ruby或python具备完备的模块管理与纯面向对象，，有助于建设高复用的框架与平台。

　　实现快速迭代：

　　每天日结，自动化代码要有完备的单元测试，这点通过ruby很容易实现，通过极简洁的单元测试框架让任何人都愿意做自动化代码的单元测试，这点很重要，因为你的代码再也没有人去手工测试了。

　　实现DRY与业务逻辑分离

　　DRY即Don‘t Repeat Yourself（不要重复自己）， 永远不要让相同的逻辑代码复写两次。 一旦出现，将其分离封装，如果是公共代码（可能大多数项目会用），将其独立为gem包等形式。

　　业务逻辑分离，将用例业务层为独立，逻辑处理再次封装，MVC的思想作为参考点。

　　实际上，自动化项目更适合做敏捷模式的开发过程，如果自动化项目都没有“敏捷”， 你的被测项目又如何“敏捷” ？

　　我们应该关注什么？

　　除了自动化项目完成时间是重点外，我们要去关注：

　　1、质量问题

　　2、可维护性

　　质量关乎自动化项目的生命，

　　一旦自动化项目的经常跑失败，失败的原因经常是由于脚本引发，并且不收敛，那后果可想而知：

　　● 没有人再相信自动化的运行结果

　　● 没有人再愿意尝试不断的投入执行与分析一个无法发现有效bug的自动化测试项目中

　　● 没有人再愿意投入下一个自动化过程中

　　可维护性是指后续的产品变更引起的自动化脚本更新快捷方便，做的好的自动化是超前完成维护的，做的烂的自动化是无法维护的。

　　可维护性表现可在于1，修复一处代码即可完成相关所有逻辑的处理 2，便于增加新用例与复用代码。

　　我们谁也不愿意将自动化的脚步陷入不断的无限的维护分析的泥潭中。

　　总结

　　上面一些感悟，例子不多，但将我认为重要的东西表达出来了，很多东西并不是死板的，呆滞的。

　　自动化领域更讲究创新思维。

　　能够将你所看到繁琐，无聊的事情通过自动化解决了，这是做好自动化项目的核心思想。

　　但自动化之路不是一朝半夕可以掌握，很多弯路也许你是必须要走过。 <异类>一个观点叫 1万小时规律， 你不去认真做一万小时的事情，你是不可能成为高手的。 （1万小时大概需要5-6年）

　　在这里共享一些心得，也与刚入门的兄弟姐妹们共勉之。 共同进步。

　　后推荐一个近文章<测试技术专家之路的成长>，我想自动化专家的发展也与此类同：http://www.51testing.com/html/09/n-247209.html

　　多实践，找出与自己公司合适的自动化发展之路，而不是好高鹜远，更不是以技术牛人自居，只有这样，才能脚踏实地，一步步走好适合自己的发展历程。任何行业不都这样吗？