走在自动化测试的道路上(二) --我们应该做什么?

引用

前言:
• 自动化测试不只是测试的自动化,应当是流程的自动化
• 自动化测试是一种软件开发交付过程
• 自动化测试成败在于自动化项目的质量与可维护性

自动化测试对于在黑盒与手工测试工作的大部分人来说,都会比较向往,因为自动化测试很有成就感; 对于直接在自动化测试行业工作的新人来说,会比较迷茫,因为这个较为新生的领域不像开发行业那么成熟;
其实,自动化测试和手工测试一样,是一种测试方法,只是你智力与思维转化的结果; 关键看你是否适合,心态是否正确.
同时,它的发展前景不亚于任何开发行业,你既可以接触专业的自动化测试技术,又可以掌握相关的开发技术,并且可以接触专业的测试专家.


自动化测试的范围

一般我们很难直接限定自动化测试的内容,但以我的理解,先从不适合的方面排除之,你可以试着看一下.

在混乱的项目流程中,不适合推广和试行自动化测试. 自动化测试也是一种项目交付过程.
如果被测项目流程不明确,过程责任不清,没有准确公平的数据度量,

• 开展了自动化测试效果难于评估,做也白搭
• 没有清晰的交付测试流程,自动化测试经常的变更成本,以及没有开发支撑的自动化只能从表面下手,导致维护成本过高.
• 自动化测试能够将流程工具化,这点体现的效果易于得到整体研发的认可与支撑,效果也是极显著的.

打个比方,本来是在公路上(不完善的流程)运行汽车,你非要改进效率跑火车(自动化),适得其反.

自动化测试的关键点之一,在于流程,流程在于人去完善,去改进.然而流程在年少时人的性格,在年长时也改变不了太多,我们自动化要符合流程去做,需要完善的我们去补充完善.而完善流程,不是一味的提要求,而是合理的惯力的要求,更多的时候应该建设平台来支撑流程,让人做到最简化.

一旦流程的完善,自动化随之正规化,可量化的自动化需求,项目成员明确自动化的成本与成果,以及相关自动化约束(例如某个自动化接口实现). 自动化的成功自然随之而然.

所以,自动化测试不只是测试的自动化,而应当是整个流程的一种自动化与完善.

在实施自动化的时候,处理流程相关,最好遵寻:

完成相关自动化项目显示效果 -> 要求改进流程 -> 实现流程过程的自动化

这样带来的项目压力较小,容易获得所需的资源.


自动化测试的过程

有了流程不代表我们肯定会成功,更何况一般需要我们通过自动化测试的成功来带动流程的推进.

自动化测试首先是一种软件开发与交付过程,无论最后的执行与维护是谁!

自动化测试与软件开发过程基本相同,也要经历: 需求->设计->编码->交付 四个核心过程. 与普通的开发过程不一样的是,

• 自动化需求并不是实际的强制性需求,能够有弹性,最关键的是自动化项目所定下的效果,各利益相关者必须在自动化项目效果期望上达成一致.
• 一般自动化设计过程相对较为简单,如果有可伸缩好的框架,这个设计过程可以在很短时间搞定.
• 自动化的维护周期会比较长,所以设计高维护的自动化脚本是必然的.

在实际中,从手工测试过程中学习自动化的人,甚至有对版本管理工具如何管理代码不清楚,那么他去做自动化必然是失败的.
当项目经理对自动化效果期望很高时(这点可以理解,一般人对自动化期望都比较高),而你没有将实际的风险与效果评估展现与说服给他时,就算自动化再成功,这个项目依然得不到所得的效果.
我们在统计自动化成本时,往往发现执行维护阶段最终会超过自动化项目开发阶段.

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

看下我们的目标:

• 快速开发与交付
• 高可用维护

选择一门语言:
根据实际自动化需求,我们选择了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/?uid-293557-action-viewspace-itemid-247194

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