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

网易杭州 QA Team

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

 
 
 
 
 

日志

 
 

敏捷测试的疑惑  

来自宵宵   2013-04-25 15:23:37|  分类: 测试理论 |举报 |字号 订阅

  下载LOFTER 我的照片书  |

我理解的敏捷测试:

敏捷测试,一个在互联网项目中非常流行的词汇,引用百度百科的说法:敏捷测试是遵循敏捷宣言的一种测试实践:
1、强调从客户的角度,即是从使用系统的用户的角度,来测试系统。
2、重点关注持续迭代的测试新开发的功能,而不再强调传统测试过程中严格的测试阶段。
3、建议尽早开始测试,一旦系统某个层面可测,比如提供了模块功能,就要开始模块层面的单元测试,同时随着测试深入,持续进行回归测试保证之前测试过内容的正确性。
按照我的理解就是:项目时间很紧迫,如何在最短的时间测试好项目,就是一种敏捷。不用再等到完完整整的开发交付,而是当某个独立的模块能够提交了之后,我们就可以进行测试了。这样减少了项目初期测试的等待,也缩减了开发交付完整产品后等待测试提交bug的缓冲时间。

敏捷测试的优点:
最近接触过几个移动项目,大多是采用scrum的开发模式。这样的模式强调短迭代,在每个sprint任务必须干干净净的收尾,尽量将风险不强遗留到下个sprint。
scrum中每日站会、bug bash、sprint回顾等都较以前老的项目模式有很大的优点。个人的成长也是很大的,比如每天的站会让我们能够快速了解到各个角色当天正在进行的、已经完成的任务,然后可以非常有计划的估算自己当天的工作。还有就是沟通,因为项目很紧凑,需要我们充分地把握需求、开发的进度,以及各个功能点的进展,所以我们需要不断地沟通。对于任何有疑问的地方要马上找相关人员沟通。还有就是每个sprint带来的收益也是很大的,在每个sprint结束时,项目经理会组织大家进行一次sprint回顾。优点、缺点,全部都可以谈,这个时候我们就可以回顾自己整个sprint一路走来有什么好的值得以后借鉴的,有什么不好的,怎么以后去规避。

再来谈谈我在测试过程中遇到的疑惑吧。

回归测试过于频繁。每个sprint要回归,最后个sprint要回归,到项目尾期开发每天一个版本都得回归。同样的手工回归都是会疲劳的,刚开始几轮回归我会正儿八经地按照回归用例跑几次,然后到后面就凭感觉象征性地点几个地方。其实到最后,哪些功能能够信心满满地说绝对没问题呢?我心里也不一定有谱。
后来我就尝试在每个sprint结束时做个该sprint任务相关功能的回归,将所有产品的回归放到项目尾期。这一定程度减少了回归次数,可是项目尾期的频繁回归还是没有办法。
自动化,很多人肯定这么想。我也想到这个方法。碍于技术薄弱,移动产品的自动化,我还不能在非常短的时间将代码写出来。UI自动化,基本是不可取的,因为移动版本一次修改,基本都大修界面。有文章说每次将该版本不涉及的功能修改写成脚本,然后就跑这一部分脚本。可是我们目前的产品版本一个紧接着下一个,那我不是每个版本都要维护一批的用例。成本之大!
后来我想到了用市场上流行的一些脚本录制软件,如itestin。每次回归简单跑跑上次录制的脚本,该没问题吧。可是像itestin这样的软件要求ios越狱,对自己的机器就不高兴这么折腾了。何况我每个版本的机器总不该都进行越狱吧。
再后来想到接口测试。接口测试的好处我也不多说了,可是进行怎样层面的接口测试?单单是后端请求吗?个人感觉不是很全面,最好能够有个涉及APP自身逻辑的一些自动化脚本。这个目前还在探索中,求相关人士指点迷津。

  评论这张
 
阅读(562)| 评论(2)
推荐 转载

历史上的今天

评论

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

页脚

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