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

世界的瞭望哨

认识自己 认识世界

 
 
 

日志

 
 

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

2012-05-04 13:16:22|  分类: 测试理念 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

这是本系列的第二篇,第一篇请参阅:

http://qa.blog.163.com/blog/static/19014700220119775947402/ 


世上本没有路,走的人多了,也就有了路。今天不讲技术,只讲感悟。


第一节:质量意识是自动化的前提

任何东西都有个价格,质量也一样,如果在产品的战略定位中,质量不是核心价值,那么质量的价格自然不会高,为质量付出的代价也不会高。

普遍讲,客户端产品的质量要求高于Web产品,客户端出了Bug,用户修复很麻烦,Web产品出了Bug,可以临时上线,或在下次上线修复;Web产品中,涉及money的质量要求高于没有盈利模式的产品,比如:游戏 or 购物类;还有就是用户群体的大小和产品活跃度,等等。


第二节:减轻测试负担是现实动机

古语有云:凡是机器可以解决的,就把它自动化吧!

有代码重构和服务器配置变更等涉及面广大的任务时,须要大量的回归测试,这时候先使用接口测试回归,可以速度得到反馈,确保功能无错,再配合UI测试。

日常工作中,不会天天重构,但做一下每日回归,上线前再密集的多回归几个轮次,应该是比较靠谱的。

自动化脚本尤其是接口测试脚本还可以用于批量准备测试数据,偶尔用用,不亦乐乎。


第三节:结合产品本身的状况是必由之路

额。。。这里的水太深了。简单讲,自动化不贴合一个产品本身的特点,十有八九是举步维艰。

天时:产品刚处于起步阶段,大家都是斗志满满,开发乐意写单元测试,测试乐意写接口,UI测试,领导要求保证质量,这种情况下,自动化是比较容易实现和取得收益的。等到产品老化,代码老化,斗志涣散,积重难反,再想搞自动化就比较困难了。

地利:产品本身要么在市场上取得领先地位,对质量要求较高,要么在公司内占有比较重要的地位,可以获得较多的资源。

人和:产品有一个流畅的流程,策划,开发,测试之间的目标和谐一致,产品的发展思路比较稳定。不然,你懂得==


第四节:持续投入,方可见到效果

无论从哪个角度看,自动化发现的Bug都是很少的,自动化主要是用来回归的。

用例只有十几二十个,不会有太大的收益,没有量的积累不会有质的变化。写很多用例?很大的成本,而且,产品在不断发展,用例本身也要不断维护,这些都是成本,看起来是个无底洞。

一天跑个一次两个,搞个每日回归,收益不见得高,最好是搞成持续集成,密集的连续跑。但是,用例挂了谁来检验?谁来维护?谁来反馈?如何做到及时?这些都须要人力。

所以,做自动化,不做则已,一做就要有花成本的勇气,用例要足够,至少覆盖所有核心的功能点,尽量做到持续集成,毕竟都是敏捷开发模式,代码提交的频度很高,还要有坚持扩充,维护用例库的恒心。

一个优良的自动化框架的价值主要体现在这里:使得用例好写,好维护,运行稳定,运行快。


发现Bug不是我们的目的,保证质量才是。

  评论这张
 
阅读(200)| 评论(0)
推荐 转载

历史上的今天

评论

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

页脚

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