原文地址：http://www.blogjava.net/qileilove/archive/2012/05/15/378156.html
未来的自动化测试在哪里？
引用
| rubywindy说前面的路： 软件行业算得上是高科技行业，“零成本”缔造了N多帝国公司的神话。 这也从侧面说明软件业还不够“成熟”，因为在“传统”的眼里，很难出现一家独大的局面。 在软件业中，自动化测试要算是一个很小的分支了。 然而软件测试往往花费了50%以上的项目周期，而自动化测试正像传统的自动化流水线工厂一样，试图解决这个关键问题。 |
我在这个领域不长时间，算上入手开始到现在，大概有1年半有余。一直有一种想分享一些想法的冲动，然而总是感觉时机不成熟，毕竟这个领域在中国是新兴的，而我也是一种新入门的感觉，然而，测试领域的混乱状态与最近越来越清晰的思想使得我也借Ruby大会后的时间梳理一下我的想法。
自动化测试包含的理念是什么？
看了许多51testing上的文章贴子，很多人对此不清楚，我想简单几句表达下我的观点。
为什么出现自动化测试？ 因为手工测试效率低下，回归成本高昂，许多在前期应当控制的代码质量由于手工测试介入过晚导致测试成本过高。 自动化测试的出现要求提高整体测试效率，极大降低回归成本，通过单元自动化，接口自动化，自动化代码检视，编译自动化构建，冒烟构建等立体动态的方案从而 可以尽早从测试手段控制版本开发质量，降低后续测试成本，并快速集成回归。
我想提供一个图看下变化过程：
这是一个传统的，也是我们一般人使用的软件开发模式，国外有个好听的名字： 瀑布开发模式（你坚着看，很形象吧？）
而自动化测试应当提供什么呢？
看下图：
我们今天不讨论敏捷，这里的自动化模式是基本不改变开发模式的方式下的开展过程。（我想大部分公司很难强推行大规模的开发模式转变：大部分原因被冠名风险与人）
这个图是以自动化云层（叫平台也行）依靠，提供全方面的自动化测试过程。
● 自动化测试的手段： 以自动化测试代码为依托，提高高可用的测试方案与立体的测试体系。
● 自动化测试的目的： 让软件测试无事可做！
也许较真的兄弟们会说，软件测试覆盖的面可多了，黑盒，模糊，场景，发散等，你怎么取代？ 我说的测试工作是特指我们平时花费最长最无味的系统测试。
解释了自动化测试的所在的领域与基本理念后，下一个问题，
如何发展？
这里就我在工作过程中的一些思路谈一谈，我们知道自动化测试不具备通用性，明白这点很重要。我再解释下，假如你在华为的路由器测试，你会使用cli操作命令进行自动化，你的平台很可能依托在复杂的资源管理平台上。
而如果你在人人，你会使用selenium等UI工具进行自动化，你可能直接使用了selenium与hudson作集成自动化。
如果你是做企业金融的公司，你会使用flash测试工具，autoit，甚至商业化的RFT等
另外，自动化还有一个特点，投入成本高，产出可能很缓慢。 如果你在预算投入不足时，千万不要貌然启动自动化，不要对其报有任何幻想。
如果明白这两点，你们公司应该会成立专门的自动化团队了，并且逐步的形成自动化测试的框架与相关的自动化效果产出了。
最后我想重点谈谈技术在自动化测试发展中的作用。
● 问题一： 选择商业工具还是自主开发？ 商业工具一般很强大，常见的如QTP，RFT，Robot，SilkTest等，并且带有脚本录制与快速回放。那我们直接选好了？
No，我的建议是不要去选，至少不要轻易的去选，并不是说你家有钱不让你去花，因为要知道，自动化测试不具备通用性，我们的产品很难说能适应测试工具，而是应该让工具去适应产品。
自主开发？ No，我的建议也是No，世界上有一批优秀的程序员（测试员），他们开发了一批优秀的开发的自动化工具供我们使用，我们只需要动动手，整合一个框架出来就 ok了。 你会担心，谁帮我维护？有bug找谁？ 你要记住，如果你的技术不足于达到维护这个自动化测试工具时，你的自动化测试基本也宣告失败了，那么，发现bug提交给相关社区，或者自己去修改并 push请求。达到技术共享的目的。
Java代码
| 少量推荐的开源项目: 当然,采用开源并不是成功的必然条件,你还要根据实际的产品需求逐步的形成适合的自动化测试解决方案而不仅仅是一个工具. |
● 问题二： 先开发框架还是先作自动化项目？ 有些人上来就想做一套框架搞自动化，生怕技术生锈了，实际上我的建议是：
先有自动化测试代码，形成简单的结果报告，代码复用规范，将自动化效果展示出来。
第二步摸清需求后，进而设计一套合适的框架，这里可充分利用开源的优势，一个技术好的人甚至花不超过1周可搞定一个框架。我们的ATT框架当时 仅花费了20*3人天完成。（一套关键字驱动框架，目前还没有开源） 另外一个单元级框架花费3天完成，具备脚本规范，日志输出，等作用。
第三步，设计框架要考虑可扩展性，要有预言性的设计在里面，比如ATT框架对外的接口是一个xmlrpc协议的接口，后来我们花了半年开发了平台管理项目，与ATT框架完美对接。
最后，从流程上对自动化云层进行整合，梳理各项流程点，把能够简化的流程步骤全部由云层处理。（就像乔布斯那样把iphone的开关都去掉了，因为实在对用户没有必要）
我就简单总结下，
1、技术上不要求太精，但一定要广，并且对新技术具备很高的热情，我以后如果去面试，会第一个问题问，是否在业余时间开发过项目，如果用到了rails，erlang，云技术，甚至喜欢研究flex，敏捷，那么是我的首选。
2、创新思维，凡事不是第一感觉为否定，而是用研究来验证自己的想法是否可行，能否做到把不可能自动化的东西也自动化掉。
3、团队交流与协助，这点不用多说了。
4、改进意识，不甘于不断的重复工作，如果没有这点就没有自动化。
当然，这样的人有少量就够了。
最后就我的里程，作一个回顾，也会以上理论的东西作一个实质的归纳，就当听听故事吧
大学玩了一半学了一半，学业成绩称不上优秀，但也算不错。（至少没有挂课~）
毕业的时候，我直接投了深圳这边公司的简历，当时当然是一心投的开发职位，然而，对开发倒是一种不舒服的感觉，因为毕业设计的时候设计的那个邮件服务器始终存在一个bug，让我决定可以试试测试职位，最终通过了现在的公司的面试。（ 主要是动手能力强， 嘿嘿）
随便说一下，当时腾讯来过，我去面准备不足（第一次面），直接被一面bs，我就暗下决心，你bs我，我就以后bs你，所以现在听有人进了腾讯，我就不由分说bs一番。（现在只是说说了，虽然心里知道它现在的霸主地位） 等我以后再真正bs你吧。
那时候，华为还没有过来，但早就听说华为的速度（无论面试还是offer）最慢，我是那种不喜欢条条框框的人，直接不等它了。
进了公司后，开始做测试，我的性格里只有两种事情划分，要么做好做么不做，开始的测试工作还是蛮有意思的，学习也真的很快，期间也收获了同事们 的认可，然而时间一长，测试的重复工作和无力的成就感使得我不得不重新考虑以后的计划，以后的几天，我向我导师反映了我的心态与计划，转岗or离开。 然而，在那时候我坚持了下来，半年后我们的测试主管确定成立自动化测试部，在10年4月的某一天，我全职投入自动化，从基本上是零一直到现在。
因为公司的自动化发展特殊性，我们的自动化投入基本上是：
投入自动化项目 -> review效果 -> 剥离框架 -> 投入自动化项目
目前效果产出比较明显，好几个版本ROI超过了2，直逼3。 在这里我建议投入的项目是：
基本功能bvt -> 易于实现的自动化功能 -> 提高部分模块自动化率， 期间不断优化框架与平台，整合出我们的自动化云端。
自动化测试对于在黑盒与手工测试工作的大部分人来说，都会比较向往，因为自动化测试很有成就感； 对于直接在自动化测试行业工作的新人来说，会比较迷茫，因为这个较为新生的领域不像开发行业那么成熟；
其实，自动化测试和手工测试一样，是一种测试方法，只是你智力与思维转化的结果； 关键看你是否适合，心态是否正确。
同时，它的发展前景不亚于任何开发行业，你既可以接触专业的自动化测试技术，又可以掌握相关的开发技术，并且可以接触专业的测试专家。
自动化测试的范围
一般我们很难直接限定自动化测试的内容，但以我的理解，先从不适合的方面排除之，你可以试着看一下。
在混乱的项目流程中，不适合推广和试行自动化测试。 自动化测试也是一种项目交付过程。
如果被测项目流程不明确，过程责任不清，没有准确公平的数据度量，
● 开展了自动化测试效果难于评估，做也白搭
● 没有清晰的交付测试流程，自动化测试经常的变更成本，以及没有开发支撑的自动化只能从表面下手，导致维护成本过高。
● 自动化测试能够将流程工具化，这点体现的效果易于得到整体研发的认可与支撑，效果也是极显著的。
打个比方，本来是在公路上（不完善的流程）运行汽车，你非要改进效率跑火车（自动化），适得其反。
自动化测试的关键点之一，在于流程，流程在于人去完善，去改进。然而流程在年少时人的性格，在年长时也改变不了太多，我们自动化要符合流程去做，需要完善的我们去补充完善。而完善流程，不是一味的提要求，而是合理的惯力的要求，更多的时候应该建设平台来支撑流程，让人做到最简化。
一旦流程的完善，自动化随之正规化，可量化的自动化需求，项目成员明确自动化的成本与成果，以及相关自动化约束（例如某个自动化接口实现）。 自动化的成功自然随之而然。
所以，自动化测试不只是测试的自动化，而应当是整个流程的一种自动化与完善。
在实施自动化的时候，处理流程相关，最好遵寻：完成相关自动化项目显示效果 -> 要求改进流程 -> 实现流程过程的自动化
这样带来的项目压力较小，容易获得所需的资源。
自动化测试的过程
有了流程不代表我们肯定会成功，更何况一般需要我们通过自动化测试的成功来带动流程的推进。
自动化测试首先是一种软件开发与交付过程，无论最后的执行与维护是谁！
自动化测试与软件开发过程基本相同，也要经历： 需求->设计->编码->交付 四个核心过程。 与普通的开发过程不一样的是
● 自动化需求并不是实际的强制性需求，能够有弹性，最关键的是自动化项目所定下的效果，各利益相关者必须在自动化项目效果期望上达成一致。
● 一般自动化设计过程相对较为简单，如果有可伸缩好的框架，这个设计过程可以在很短时间搞定。
● 自动化的维护周期会比较长，所以设计高维护的自动化脚本是必然的。
在实际中，从手工测试过程中学习自动化的人，甚至有对版本管理工具如何管理代码不清楚，那么他去做自动化必然是失败的。
当项目经理对自动化效果期望很高时（这点可以理解，一般人对自动化期望都比较高），而你没有将实际的风险与效果评估展现与说服给他时，就算自动化再成功，这个项目依然得不到所得的效果。
我们在统计自动化成本时，往往发现执行维护阶段最终会超过自动化项目开发阶段。
我们应该怎么做自动化项目
看下我们的目标：
● 快速开发与交付
● 高可用维护
选择一门语言：
根据实际自动化需求，我们选择了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
多实践，找出与自己公司合适的自动化发展之路，而不是好高鹜远，更不是以技术牛人自居，只有这样，才能脚踏实地，一步步走好适合自己的发展历程。任何行业不都这样吗？
======================================================================================小记：写的不错，系统、思考有深度。我们是在人员上打了败仗。现在转向开源，希望在自动化的路上走的更好。
142
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
