码迷,mamicode.com
首页 > 其他好文 > 详细

关于自动化测试的一些思考(三)

时间:2015-04-06 15:35:40      阅读:178      评论:0      收藏:0      [点我收藏+]

标签:

之前在一个项目组,写了两次粗浅的自动化方面的思考

关于自动化测试的一些思考(一)http://www.cnblogs.com/tobecrazy/archive/2012/12/18/2824248.html

关于自动化测试的一些思考(二)http://www.cnblogs.com/tobecrazy/archive/2013/06/10/3131338.html

这两份都是刚做自动化测试的时候能够想到的,回顾一下,令人唏嘘。之前做的主要是基于server端的自动化,并且是Linux平台,

所以做自动化相对来说比较容易。因为不需要考虑gui变化,关键字驱动就可以实现测试框架。

现如今做的web端测试,主要基于selenium测试框架的二次开发的框架。现在将项目中遇到的实际问题和一些思考分享一下。

接下来会详细介绍项目背景,团队以及自己的一些思考总结。

项目背景:B/S架构的web网站,属于长期产品,不断迭代(可参考淘宝),较复杂的业务逻辑测试框架比较完善,基于selenium二次开发深度定制。

团队:Global Team,做自动化的和做手工测试的严格分开,相对独立(专职的automation QA和manual QA)。

做手工测试的熟悉业务逻辑,主要参与设计case;做自动化的主要把manual QA的case

翻译成自动化的case,每个release不停的run

遇到的实际问题:分为团队方面和测试框架的一些问题

首先说一下团队方面:

  以前的团队里manual QA 和automation QA没有严格区分,case是我们自己写的,由于业务逻辑没有那么复杂可以说是得心应手,手到擒来。

现在的团队,由于automation QA focus在写自动化和跑Case,出现的最大的问题如下:

  a.不懂业务逻辑,测出问题不能断定是不是bug,反而要经过manual QA去二次确认。

  思考:automation QA要不断学习,充分熟悉业务逻辑,并且能站在customer角度考虑问题,留心一些不合理的设计。

      b.如果case 比较久远,而case缺乏维护,这要已经被自动化的case维护起来比较难,逻辑已经不清楚。

  思考:需要经常花时间和manual QA沟通,定期更新case

      c.绩效考核不够科学,考核的一个重要的指标,code coverage, 由于case是manual QA设计的,code coverage 不是说提高就能提高。

   考核的另外一个指标,翻译成自动化的case的数目,如果某个component被新增或者废弃,都不能做相应的调整,因为这个指标是年初制定。

     这点还是管理团队思考吧

     当然,以上都需要花费太多的时间,当然我们的时间主要花费在翻译case、跑case并分析。

 下面是框架的问题:

  首先自动化框架已经很完善,有专职的architect维护,我说的问题并不是真正架构上的,而是维护起来的实际问题。

      a. 页面变化

      页面变化几乎是每个做web自动化头疼的问题,因为原来的页面元素和业务逻辑都会有相应的变化,以前所有的验证点都失效。而web 产品版本迭代免不了

页面变化。框架是一个好框架,关键是用的人,由于水平的原因,导致后期维护苦不堪言。上个图描述一下框架,以前的case,没有把 page action组装起来

直接在每个case里写,这要代码重用性和可维护性比较差。如果页面元素变化了,要修改到每个case里边。

如果使用actions,直接修改page和page action这要case不需要变化啦

技术分享

思考: 要增加case的可维护性和代码的可重用性,就要进一步吧相应的共性的东西抽象出一个个方法,让容易变动的部分放在最底层

  b. 因为整个框架是基于selenium(testng)的,开源的框架,好处多多(省钱,知道源代码可以二次开发深度定制),但是缺点也不少。

case 不够稳定,常常出现找不到Web element的现象。可能网速太差,或者本身某些方法不够科学,wait时间太短。也可能是xpath写的不够科学。

 

     思考:增强case的稳定性,需要在case里边设置科学的wait time和重复刷新,另一方面xpath写的时候要考虑到页面万一有微调的时候不受影响。

以上就是我对项目的一个初步总结。

接下来是我自己的一些想法:

  1.自动化测试和手工测试

    自动化和手工测试各司其职,由于我们框架比较成熟,在java代码技巧上没有特殊的要求,因为方法都是封装好的,这要对成长不利。

当然手工测试也很厉害,需要懂业务也要设计case,私以为测试能力主要体现在设计case的能力上。所以,在做自动化测试的同时,要思考为什么

case这么设计,要试着设计case去cover那些manual QA考虑不到的地方。

     2.测试开发和移动自动化测试

       这也是我极为纠结的,以后的趋势是往移动方面走,未来是往移动方面走还是做测试开发?

 

 

     

 

  

关于自动化测试的一些思考(三)

标签:

原文地址:http://www.cnblogs.com/tobecrazy/p/4395932.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!