• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

敏捷是否是系统软件测试的噩梦?

发布: 2009-7-15 10:44 | 作者: 不祥 | 来源: 领测软件测试网采编 | 查看: 70次 | 进入软件测试论坛讨论

领测软件测试网

敏捷是否是系统软件测试的噩梦? 系统测试工具

很早就听说过敏捷软件开发的概念,觉得是个新生事物,挺好玩,现在IT的炒作已经太多了,后来发现敏捷的思想越来越深入人心,大大小小的公司开始使用敏捷的模式进行软件开发。终于,敏捷来到了我的身边。

  在传统的软件开发模式中,系统测试属于软件开发过程的较后阶段,基本是在所有开发代码全部完成,开发人员拿出所有精力修改bug时才会正式进行系统测试,包括安装啦、稳定性啦、负载啦等等。

  这次项目开始大约半年了,是一个小版本的升级,采用了scrum模式,我切实的感觉到敏捷系统测试不太对劲。在scrum中,根据开发的实际情况,设定一个时间间隔(比如每两个周)为一个sprint周期,每个周期都有需求跟踪和实现,然后在进入下一个sprint阶段。

  目前,我发现了几个敏捷系统测试的主要问题:

  1. 不断增加的新功能导致测试结果失效。

  既然是敏捷,当然是时刻适应需求的变化,于是功能不断的改变。系统测试的结果在一次次的代码变化之后失效,比如测试应用的稳定性,跑了两天,内存和其他参数都没问题,然后开发人员在下一个sprint对代码做了很多修改,你说要不要重测??通常这种回归测试都是在系统测试的最后阶段,拿到最后的build 的之后再测,现在呢,不得不测,如果说系统测试的工作量少也就算了,但事实上,系统测试的压力特别大,搞的大家身心疲惫。

  2. 发现问题,开发人员无法适当处理。

  如果在测试中发现了问题,按理说开发人员应该尽快解决,但在敏捷开发模式下,开发人员每一个sprint都有相应的需求要实现,精力有限,于是他们对于细微的bug根本置之不理,一般都会拖到最后才解决,这就导致了一个问题,这些bug在若干次build之后会不会重现,可能在报完bug之后3个月,开发人员才开始考虑这个问题,此时这个bug报告还有效吗??是不是需要重新测试??于是我们测试人员之前的测试工作根本没意义了。另一方面,对于严重的bug,开发人员也无法集中全部精力来处理,三心两意,你说bug能解的顺利吗?后果就是开发人员和测试人员都满心抱怨。

  在我看来,这种紧跟敏捷的系统测试不是完全没有意义,有些严重bug可以提早发现,开发人员可以尽早解决,但是体现了帕累托现象:我们用80%的努力得到了软件质量20%的提高,的确,从公司老板的角度看,这样值得,反正软件质量提高了,但对于开发和测试人员来说确实非常痛苦。我记得敏捷的思想来自于计算机界的各位大牛,他们在设计软件开发模式时,没有考虑过系统测试的特殊性吗?还是他们从没把系统测试包含在敏捷思想里面,只是某些人狂热的把敏捷错误的用到了系统测试当中?

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: 噩梦 系统测试工具 系统软件


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网