注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

网易杭州 QA Team

务实 专注 分享 做有态度的QA

 
 
 
 
 

日志

 
 

我的自动化测试小结【1】  

来自尘泥   2011-10-07 21:45:47|  分类: 自动化测试 |举报 |字号 订阅

  下载LOFTER 我的照片书  |
历史:
加入公司后先后做过UI自动化测试(基于Selenium),HTTP接口测试(基于DWR)和自动化的测试数据准备,面向的产品都是Web应用。

现状:
UI自动化:为P项目投入的时间和精力最多,但使用频度和收益最小,早已不再维护用例了。后续加入P项目组参与日常测试,发现P项目的开发相当敏捷,频繁提交和部署,而跑一轮UI自动化用例须要一个半小时,实在是等不起啊==!为A项目搭建的UI自动化个人认为是比较成功的,先是在A项目组做了2周左右的功能测试,熟悉产品。再来写用例就得心应手了,也容易抽取主要功能点,把自动化用例运行时间控制在30分钟以内。这套用例在每次上线前都会跑,效果不错,后续是由功能测试人员在维护。
HTTP接口测试:P项目组前段时间投入了部分人力写出为数不少的接口测试用例,目前,只有W业务相关用例最完善,使用频率高,其他的用例虽然写出来了,但用的比较少,这一点后续要好好改进。
自动化数据准备:同样用于P项目,主要通过看开发代码 or 使用在写HTTP接口测试中积累起来的API写一些准备数据的脚本。从目前看,确实可以节约不少人肉测试时间。

思考和展望:
结合我在P项目组的功能测试经验,有以下想法:
一:Web产品最常见的是前端页面错误(页面排版错误,JS错误,链接跳转错误。。。),这种错误要么依靠人肉发现,要么就依靠UI自动化发现,接口测试是发现不了的。而且,这一层是产品用户直接接触的层级,上线前最好做一次全面回归,但单凭人肉是很枯燥的,而且容易遗漏。这时候,UI自动化就很有用了!但,UI自动化用例应该少而精,专注于最关键的核心功能,把执行时间尽量压缩,至多不超过半小时吧。
二:HTTP接口测试运行速度快,稳定性高,可以设计复杂的业务流程,检验一些使用UI自动化无法触及(如:绕过前端JS限制输入非法字符)或很难触及(运行耗时长又不稳定)的功能点。另一方面,一个附带的结果,在写接口测试用例的时候往往可以发现一些隐蔽的历史遗留bug。
三:开发和测试是有节奏,总有一段时间是开发很忙而测试在等待提交测试的。我认为可以把这段时间利用起来,或阅读开发代码,或编写测试用例,或写数据准备的脚本。测试开始以后,一方面使用之前准备的自动化脚本准备测试数据,方便手动测试,一方面,每隔一段时间(若干小时,根据开发提交代码的频度)执行HTTP接口测试,跑一轮控制在15分钟,保证功能不出问题(功能出问题,改Bug相对比较麻烦,尽量做到早发现早解决)。接近上线的时候,跑1-2轮UI自动化,单轮时间控制在30分钟,比较全面地回归一下主干功能(这个时候如果还出问题,很可能只是页面显示问题,改Bug也比较快)。结合手动测试,自动化数据准备,UI测试和HTTP测试,发挥各自的长处,把自动化用起来。效果未必立竿见影,但我相信长久坚持在潜移默化间是有效果的!另外,无论是UI自动化还是HTTP自动化,它们积累的API稍加改造就可以拿来准备数据,呵呵:)

更多话:
对于自动化,我的路还很长,接触的东西也还很少,经验也少,也只能在我接触和经历过的范围和深度内提出我认为的最佳方案。对于将来,一方面要多调研,多尝试,这一点小云的安卓自动化很好,开辟一条新路出来。走过的路多了,才更知道什么是最合适自己的路;一方面要和自动化针对的产品亲密接触,多多了解,贴合项目需求的自动化更容易取得较高的收益。
  评论这张
 
阅读(1076)| 评论(5)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2016