金融企业软件测试中心筹备书-自动化测试

上一篇 / 下一篇  2017-08-06 15:44:28

八、自动化测试

有些东西像树上的苹果,好看而诱人,大家都说好,于是大家都去摘,只是有人家里的苹果已经红透,摘下来时鲜美可口,有的人家苹果刚刚成长,强行摘下苦涩异常。自动化测试就好像这个苹果。

8.1、被神化的自动化测试

每家公司都要搞自动化测试,这也确实是整个测试行业的整体趋势,但往往好大喜功,不管目前自身条件是否具备,声势浩大开场,而又往往虎头蛇尾结束。真正搞过自动化的人,经常开玩笑称自动化测试已经被神化了,脱离了实际,人为有意无意的忽视了任何测试技术手段都有他的边界,并非完全普世,而自动化脚本的维护成本,更是经常被忽视,而这其实是自动化测试的一个致命短板。

造成这种被神化的现象,究其原因,往往是团队主管急与向领导表忠心,表能力,表态度,自动化测试的意义不知不觉中逐渐变成了面子工程、献礼工程,华而不实。而身居高位的领导,则由于多年不接触基层,只是知道自动化的概念,再一看别的公司也在搞,自身当然也要搞,大手一挥“开干”,开始时锣鼓喧天、鞭炮齐鸣,煞是有人民公社初期的高涨革命热情,人力财力都大幅倾斜,但实际一测试,发现坏了,界面大面积变更,脚本需要大规模维护,环境版本不稳定,需要人为频繁干预,各种弊端显露无疑,当年吹过的牛,自己挖过的坑历历在目,再也无法填平,一次项目之后,无人敢再提实施,但牛还要继续吹,于是开始转向自动化测试理论,各种华而不实的自动化测试方案漫天飞舞。

任何技术、模式、方法都有自身的优势与约束,单方面强调优势,可以回避劣势,只能华而不实,被神化的自动化测试,以行业历史发展的眼光看,自动化诚然是未来的趋势,例如现在业界发展的自动化运维一样,随着技术的指数型发展,基础软硬件设施的不断完善,自动化开发的概念相信也会在不久的将来横空出世,但从业人员要像《月亮与六便士》一样,随仰望星空,却一定要脚踏实地,清晰认识到自动化测试的优势与约束,才能有效发挥自动化测试的威力。

8.2、效果与趋势

自动化测试的理想效果是想通过少量的人员投入,通过系统自动测试的方式,来达到较好的测试成果。在笔者所在公司(200余个重大项目群,5000余人IT从业者),历时近10年的时间里,曾前后三次大规模推广自动化测试,经过不断的摸索与实践,总结出相对**的自动化实施方案,并在如支付结算、存贷款等大型项目中取得显著成果,在这两个项目中积累自动化脚本3000余份,曾经需要80人天的测试工作,自动化测试则只需要5个人工,跑24小时既能轻松完成。可谓效果显著,但反之,在企业现金管理项目中实施的自动化测试项目,则效果不明显,其投入的总人工成本甚至比纯人工成本还要高。面对如此大的效果差异,笔者曾牵头组织进行过详细分析,发现这两个项目的主要区别在于以下两点:

1、前者界面十分稳定,自动化测试脚本维护工作量不大,一次编制可以应用两年甚至几年以上,后者界面变化十分频繁,维护调试工作量巨大

2、前者的测试环境和版本要比后者稳定的多,每次跑脚本都比较顺畅,基本不需要人工干预,而后者版本十分不稳定,经常需要人工调整。

另外自动化测试在基础数据准备方面表现也十分优异,对于银行测试来说的基础数据包括客户信息、账号以及存款业务,而这开立这些基础数据如果通过人工来做,每个数据均需要20分钟左右的时间,才能全部准备齐全,而使用了自动化脚本后,效率提升了100倍,笔者曾经安排下属人员详细对比,20分钟内,自动化脚本至少可以开立100条数据,而且不需要人工干预,这样就可以利用晚上时间,设置脚本定时运行,第二天早上测试人员来之后,机器就已经将数据准备充分而妥当。

   随着业界越来越多的公司开始搞自动化测试,其大规模普及的趋势也越来越明显,而伴随着自动化测试相匹配的开发测试模式也在不断调整和创新,如持续集成模式等等。但当前阶段,自动化测试想要在大范围内取代人工测试,则仍不具备条件,尚需要技术再向前发展,相信不久的将来,自动化测试必然会迎来革命性的进展。

8.3、成本与约束

自动化测试的成本体现在脚本的编制和维护上面,脚本的编制一般在测试准备阶段进行,理想情况下,在执行阶段前期进行简单调试工作,在中后期发力,进行脚本的运行工作,而运行期理论上不需要人工进行过多干预,故准备阶段的投入占比较大。

但实际情况中,就项目阶段而言,由于开发情况不一定十分理想,界面随时会进行变化,而自动化技术目前主要依赖于界面识别,每次界面变动都会带来频繁的脚本改动与调试,而在准备阶段想进行充分的调试又是不显示的,详细的调试往往推迟到测试开始各协同方版本都已部署后,而这个时期本来环境版本十分不稳定,所以调试也十分困难,这时测试效果体现不出来,而管理层往往看不到测试进度,测试组压力会由此剧增,投入的人员甚至比手工测试人员还要多,而项目结束之后,也很难形成有效的资产,因为版本频繁变更,界面频繁变更,下次版本可能又会重新编制调试,成本也一直居高不下。

另一方面,基本上规模大一些的公司都需要对自动化工具进行二次开发,建立属于本公司的自动化测试框架,以适应本公司的IT环境条件,以笔者所在公司举例,在10年前就开始做自动化,当时是以业界**而昂贵的QTP最为基础软件,在其基础上进行二次开发自动化测试框架,而笔者有幸参与了框架开发工作,单纯从技术角度看,框架开发是十分成功的,其大幅降低了自动化测试人员的准入门槛,基本上纯业务人员也可以方便的使用,另外优化了脚本输入输出之间的相互关联,并可以联动QC,进行自动化测试案例的自动管理,经过多年的完善,框架本身也越来越丰富了,但这期间也花费了大量的成本,既包括购买软件的成本,也包括二次开发的人工成本投入,因此公司在引进自动化测试时,应对成本进行全方位的预算判断,方能保证最后成功落实。

8.4、边界选择

为了让自动化测试能够切实可行的落地,而不是“此物只有天上有”,一是要上下形成共识,自动化不能取代人工测试,二是要清晰明确自动化测试的边界,不能什么项目不管三七二十一,都要上自动化。

明确边界,其实也就是明确自动化适用的情况,建议如有如下情况,建议适用自动化:

    (1)、项目上线已经有一段时间,核心功能相对稳定,界面变化较低,脚本后续复用率高

    (2)、版本关联方相对稳定,开发计划可控,可预知环境版本相对稳定

(3)、版本需要开展接口测试,接口十分稳定,可做接口层面自动化

(4)、公共数据准备相关交易十分稳定,可用自动化方式准备基础数据

(5)、基础软硬件升级,可使用自动化脚本进行回归测试

(6)、持续集成的开发测试模式,每个版本上线内容少,可考虑做每日重要交易回归测试

除了上述情况外,选择自动化测试要小心谨慎,特别是新项目上线,不建议直接上来就用自动化测试,毕竟“宝剑虽好,双面利刃”!

TAG: 自动化测试

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

我的栏目

日历

« 2017-09-25  
     12
3456789
10111213141516
17181920212223
24252627282930

我的存档

数据统计

  • 访问量: 469
  • 日志数: 3
  • 建立时间: 2017-08-06
  • 更新时间: 2017-08-06

RSS订阅

Open Toolbar