走在自动化测试的道路上

大纲:
   自动化测试的现状
   自动化测试的发展
    1. 包含的领域
    2. 发展的思路
    3. 观点: 自动化测试是一种软件开发交付过程
             自动化测试成败在于自动化项目的质量与可维护性
             自动化测试不只是测试的自动化,应当是流程的自动化
       自动化的难点:
             1. 极强的定制性使得引入自动化成为难事
             2. 预言性的需求设计使得自动化需求变化极快,同时要求开发周期越短越好
             3. 软件流程往往成为自动化道路中的拌脚石
   我在自动化测试的计划
   未来的自动化测试在哪里?

引用

rubywindy说前面的路:
软件行业算得上是高科技行业,"零成本"缔造了N多帝国公司的神话.

这也从侧面说明软件业还不够"成熟",因为在"传统"的眼里,很难出现一家独大的局面.

在软件业中,自动化测试要算是一个很小的分支了.

然而软件测试往往花费了50%以上的项目周期,而自动化测试正像传统的自动化流水线工厂一样,试图解决这个关键问题.

我在这个领域不长时间,算上入手开始到现在,大概有1年半有余.一直有一种想分享一些想法的冲动,然而总是感觉时机不成熟,毕竟这个领域在中国是新兴的,而我也是一种新入门的感觉,然而,测试领域的混乱状态与最近越来越清晰的思想使得我也借Ruby大会后的时间梳理一下我的想法.

自动化测试包含的理念是什么?
看了许多51testing上的文章贴子,很多人对此不清楚,我想简单几句表达下我的观点.
为什么出现自动化测试? 因为手工测试效率低下,回归成本高昂,许多在前期应当控制的代码质量由于手工测试介入过晚导致测试成本过高. 自动化测试的出现要求提高整体测试效率,极大降低回归成本,通过单元自动化,接口自动化,自动化代码检视,编译自动化构建,冒烟构建等立体动态的方案从而可以尽早从测试手段控制版本开发质量,降低后续测试成本,并快速集成回归.
我想提供一个图看下变化过程:



这是一个传统的,也是我们一般人使用的软件开发模式,国外有个好听的名字: 瀑布开发模式(你坚着看,很形象吧?)

而自动化测试应当提供什么呢?
看下图:







我们今天不讨论敏捷,这里的自动化模式是基本不改变开发模式的方式下的开展过程.(我想大部分公司很难强推行大规模的开发模式转变:大部分原因被冠名风险与人)
这个图是以自动化云层(叫平台也行)依靠,提供全方面的自动化测试过程.

• 自动化测试的手段: 以自动化测试代码为依托,提高高可用的测试方案与立体的测试体系.
• 自动化测试的目的: 让软件测试无事可做!

解释下目的,充足的快速的立体多方位的自动化测试加之规范的开发流程,bug既在编码中与之前被发现,何来传统的测试工作?
也许较真的兄弟们会说,软件测试覆盖的面可多了,黑盒,模糊,场景,发散等,你怎么取代? 我说的测试工作是特指我们平时花费最长最无味的系统测试.

解释了自动化测试的所在的领域与基本理念后,下一个问题,
如何发展?
这里就我在工作过程中的一些思路谈一谈,
我们知道自动化测试不具备通用性,明白这点很重要.我再解释下,
假如你在华为的路由器测试,你会使用cli操作命令进行自动化,你的平台很可能依托在复杂的资源管理平台上.
而如果你在人人,你会使用selenium等UI工具进行自动化,你可能直接使用了selenium与hudson作集成自动化.
如果你是做企业金融的公司,你会使用flash测试工具,autoit,甚至商业化的RFT等
另外,自动化还有一个特点,投入成本高,产出可能很缓慢. 如果你在预算投入不足时,千万不要貌然启动自动化,不要对其报有任何幻想.

如果明白这两点,你们公司应该会成立专门的自动化团队了,并且逐步的形成自动化测试的框架与相关的自动化效果产出了.
最后我想重点谈谈技术在自动化测试发展中的作用.

问题一: 选择商业工具还是自主开发?

商业工具一般很强大,常见的如QTP,RFT,Robot,SilkTest等,并且带有脚本录制与快速回放.那我们直接选好了??
No,我的建议是不要去选,至少不要轻易的去选,并不是说你家有钱不让你去花,因为要知道,自动化测试不具备通用性,我们的产品很难说能适应测试工具,而是应该让工具去适应产品.
自主开发? No,我的建议也是No,世界上有一批优秀的程序员(测试员),他们开发了一批优秀的开发的自动化工具供我们使用,我们只需要动动手,整合一个框架出来就ok了. 你会担心,谁帮我维护?有bug找谁? 你要记住,如果你的技术不足于达到维护这个自动化测试工具时,你的自动化测试基本也宣告失败了,那么,发现bug提交给相关社区,或者自己去修改并push请求.达到技术共享的目的.

少量推荐的开源项目:
watir: http://watir.com/ Wiki社区: http://wiki.openqa.org/display/WTR/Project+Home
优秀的web自动化工具,采用ruby作为底层语言. API堪称完美. 维护速度很快
selenium: http://seleniumhq.org/ 

当然,采用开源并不是成功的必然条件,你还要根据实际的产品需求逐步的形成适合的自动化测试解决方案而不仅仅是一个工具.
这个解决方案应该能适合绝大部分自动化需求,而且根据DRY原则,做到最简洁,最易用,最稳定.

问题二: 先开发框架还是先作自动化项目?

有些人上来就想做一套框架搞自动化,生怕技术生锈了,实际上我的建议是:
先有自动化测试代码,形成简单的结果报告,代码复用规范,将自动化效果展示出来.
第二步摸清需求后,进而设计一套合适的框架,这里可充分利用开源的优势,一个技术好的人甚至花不超过1周可搞定一个框架.我们的ATT框架当时仅花费了20*3人天完成.(一套关键字驱动框架,目前还没有开源) 另外一个单元级框架花费3天完成,具备脚本规范,日志输出,等作用.
第三步,设计框架要考虑可扩展性,要有预言性的设计在里面,比如ATT框架对外的接口是一个xmlrpc协议的接口,后来我们花了半年开发了平台管理项目,与ATT框架完美对接.
最后,从流程上对自动化云层进行整合,梳理各项流程点,把能够简化的流程步骤全部由云层处理.(就像乔布斯那样把iphone的开关都去掉了,因为实在对用户没有必要)

问题三: 人,我的人应该具备什么样的能力?

<自动化软件测试实施指南>这本书讲的很好, dangdang链接: http://product.dangdang.com/product.aspx?product_id=20827265&ref=search-1-pub
我就简单总结下,
1. 技术上不要求太精,但一定要广,并且对新技术具备很高的热情,我以后如果去面试,会第一个问题问,是否在业余时间开发过项目,如果用到了rails,erlang,云技术,甚至喜欢研究flex,敏捷,那么是我的首选.
2. 创新思维,凡事不是第一感觉为否定,而是用研究来验证自己的想法是否可行,能否做到把不可能自动化的东西也自动化掉.
3. 团队交流与协助,这点不用多说了.
4. 改进意识,不甘于不断的重复工作,如果没有这点就没有自动化.
当然,这样的人有少量就够了.


最后就我的里程,作一个回顾,也会以上理论的东西作一个实质的归纳,就当听听故事吧

大学玩了一半学了一半,学业成绩称不上优秀,但也算不错.(至少没有挂课~)
毕业的时候,我直接投了深圳这边公司的简历,当时当然是一心投的开发职位,然而,对开发倒是一种不舒服的感觉,因为毕业设计的时候设计的那个邮件服务器始终存在一个bug,让我决定可以试试测试职位,最终通过了现在的公司的面试.( 主要是动手能力强, 嘿嘿)
随便说一下,当时腾讯来过,我去面准备不足(第一次面),直接被一面bs,我就暗下决心,你bs我,我就以后bs你,所以现在听有人进了腾讯,我就不由分说bs一番.(现在只是说说了,虽然心里知道它现在的霸主地位) 等我以后再真正bs你吧.
那时候,华为还没有过来,但早就听说华为的速度(无论面试还是offer)最慢,我是那种不喜欢条条框框的人,直接不等它了.

进了公司后,开始做测试,我的性格里只有两种事情划分,要么做好做么不做,开始的测试工作还是蛮有意思的,学习也真的很快,期间也收获了同事们的认可,然而时间一长,测试的重复工作和无力的成就感使得我不得不重新考虑以后的计划,以后的几天,我向我导师反映了我的心态与计划,转岗or离开. 然而,在那时候我坚持了下来,半年后我们的测试主管确定成立自动化测试部,在10年4月的某一天,我全职投入自动化,从基本上是零一直到现在.
因为公司的自动化发展特殊性,我们的自动化投入基本上是:

投入自动化项目 -> review效果 -> 剥离框架 -> 投入自动化项目

目前效果产出比较明显,好几个版本ROI超过了2,直逼3. 在这里我建议投入的项目是:

基本功能bvt -> 易于实现的自动化功能 -> 提高部分模块自动化率, 期间不断优化框架与平台,整合出我们的自动化云端.

目前我们有5个人全职自动化,马上会有新人继续加入.


写在这里,这篇已经很长了,接下来就自动化实施的难点加以分析与说明.为自己留下些成长中途的记忆.