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

因为入手自动化测试时间有限,在这里记录下近期的想法与实践,如有思想碰撞,请多多指教.

我们在上一篇已经探讨了我们要做哪些事?

这里就我个人最近的感悟,把我们最容易忽略的东西提出来.并且尝试探计一种高效的自动化模式.

以下几点是我这里引出怎么做自动化的几个关键点:

引用

                极强的定制性使得引入自动化成为难事
                预言性的需求设计使得自动化需求变化极快,同时要求开发周期越短越好
                软件流程往往成为自动化道路中的拌脚石

根据以上几点与个人自身经历

拥抱开源社区

"HI,我们要做跨平台的web页面自动化,支持ie6,7,8,9",小李提出了自动化需求;
"你好,升级平台多不胜举,我们需要尝试升级环境的自动化,怎么办?", 某部门做设备产口的项目经理说.
"每次打新包手工验证这些功能,点QQ,点网页,点应用,费时死了,弄不好被测试经理打回来",某开发人员报怨.

一个考虑在哪个层面开展自动化的例子:

单元级自动化速度快,无须复杂的环境清理,无环境依赖,但缺乏真实用户场景(user-like-less)
功能级自动化速度慢,复杂的环境清理,环境依赖严重,具备完全的用户场景.

以上几个场景想必做我们开发行业的兄弟姐妹们经常遇到类似的场景,我们做自动化的当然要主动出击帮助解决问题.可是难题来了,各种复杂的应用,如何才能自动化?

而且,各公司的流程也各不一样,都有自己的特色,我们不能强加修改.

我想有两种方法可以实施:
1. 去购买自动化测试工具回来用
2. 自己研发
买工具固然可行,但经常遇到的问题正是自动化中的难事:
但以下场景...
HI,这个工具产生的报告不适合我们!! 去找服务商定制
OH,no,这个工具无法对我们的这种控件处理!! 定制额外的工具
God,我们需要一个新的检查工具结合之前的工具!! 找服务商买吧

但自己研发? 成本太高,公司也不会轻易批准,除了微软这种超级帝国...

我们还有一种办法: 加入开源

目前有众多的开源工具供我们使用,我们正在使用:

Ruby 一门让你编程funny与happy的语言,我们使用它做自动化脚本与框架的基础语言,其恐怖的开发效率让你害怕
Watir 十分优秀的web自动化测试框架,跨平台跨浏览器,我们用它结合其他框架做web相关操作.
patron 一个模拟浏览器请求的工具,在更需要速度与稳定性时使用它代替watir
Rails 国外十分热的WEB框架,使用它做一些基础工具的web展示与自动化平台建设.

加入开源社区的优势:
1. 各种优秀的工具和低的维护成本,自动化成本大大降低
2. 可以很容易融入定制到我们的自动化建设中

但不是说加入后就万事大吉,更不是说使用就可以了.
我们要持续不断地共同改进工具,push我们的补丁. 可以开发周边的工具,供自己与其他人使用.
例如,我们也push一些watir的bugfix,
我们改进watir封装自己的api.
开放ruby_proxy,提供popup弹框处理项目.

在如今开放的互联网领域,利用开源,贡献开源,是我们自动化测试的最好出路.

加入敏捷阵营

自动化项目面临,快速开发,迭代需求; 需求随时可能会变(例如用例变更,模块需求变更均严重影响自动化的开展) 各种通常在"不严谨"的项目过程中.

事实上,我们也不便限制这些改变,一旦限制过死或要走的流程过多,自动化就失去了自动化带来的自动化的优势,我们总在评审自动化需求,忙于自动化接口实现,忙于修改自动化失败的用例.

我想我们的最终目的只是改进项目过程,提高项目质量,提高项目发展速度,那中间的过程能省则省,应当:
快速迭代, 自动化项目本身形成每日迭代,每日验收.每天的脚本质量得到控制,随时都可以交给产品线项目组验证.

拥抱变化, 无须等待项目完全需求确定即可开始自动化,越早的提交自动化测试,产生的效果越明显. 拥抱变化,要求我们有勇气是不断调整需求,有魂力是重构或是放弃某个功能自动化,这都没有关系,只要我们拥有完美的自动化测试验证与快速高效的自动化开发效率.

高效团队, 高效率的任务执行能力,畅通快速的团队沟通,"三人行必有我师"的学习氛围. 良好的反馈与经验汲取.

这正是我们团队需要的"敏捷"思想.

关注项目过程而不是技术本身

要有人专注于技术,但不是所有;

项目过程的一次小而有效的改进往往会比团队提的自动化需求完成带的收益更多.既然我们自动化测试目的就是提高团队效率,我们就需要有人关注这里.

关注于每一次流程变更带来的影响, 例如,我们团队要求每个包发布前需要进行各种杀毒扫描,我们为什么不去提供一个一键发布扫描的工具呢? 更进一步的想,自动去发布版本的目录去搜索,自动扫描并反馈报告.

当流程要求我们每一次需要提交测试报告的时候,版本经理和每个团队成员都忙于准备各种文档,忙于整理格式的时候,我们在想,为什么不会有一个智能化的平台来实时分析测试情况并根据我们需求生成我们想要的资料呢?

有人担心我们的工作会不会太大了,会不会过于主动担当过多的事情了?

引用

团队, 流程, 人 的关系:

其实不然,
1. 我们拥有比其他团队成员更广阔的视野,我们熟悉的自动化更多,要充分利用我们的视野看法来改变提高大家的效率.
2. 拥有开源的后盾,许多东西想到了就可以很快做出来,更何况我们采用Ruby与rails如此高效简洁的工具框架,只要有想法就可以快速转化为代码与项目.从今年Ruby技术大会上获悉,事实确如此:

• robbin分享一个类似google邮件列表的项目,2个人2周完成开发.
• zheye.org有想法到开发上线只花了一周时间. 2个人.
• 另外,自己也简单试着写一些公司内部需求,
一个文档索引服务器,花费周期不过5小时左右,可以避免大量的手工编辑与维护成本. 1个人.

引用

服务器的微图,涉及隐私,只截了表头

如某个偶像级人物所言:

我们在这个领域大有可为.