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

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

软件测试中敏捷:系统测试的噩梦

发布: 2010-10-12 11:13 | 作者: 网络转载 | 来源: 领测软件测试网采编 | 查看: 216次 | 进入软件测试论坛讨论

领测软件测试网

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

首先敏捷测试是敏捷的一种,原有测试定义中通过执行被测系统发现问题,通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。   敏捷测试是遵循敏捷宣言的一种测试实践:   1、强调从客户的角度,即使用系统的用户的角度,来测试系统。   2、重点关注持续迭代的测试新开发的功能,而不再强调传统测试过程中严格的测试阶段。   3、建议尽早开始测试,一旦系统某个层面可测,比如提供了模块功能,就要开始模块层面的单元测试,同时随着测试深入,持续进行回归测试保证之前测试过内容的正确性。


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

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

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

不断增加的新功能导致测试结果失效。
既然是敏捷,当然是时刻适应需求的变化,于是功能不断的改变。系统测试的结果在一次次的代码变化之后失效,比如测试应用的稳定性,跑了两天,内存和其他参数都没问题,然后开发人员在下一个sprint对代码做了很多修改,你说要不要重测??通常这种回归测试都是在系统测试的最后阶段,拿到最后的build的之后再测,现在呢,不得不测,如果说系统测试的工作量少也就算了,但事实上,系统测试的压力特别大,搞的大家身心疲惫。
发现问题,开发人员无法适当处理。
如果在测试中发现了问题,按理说开发人员应该尽快解决,但在敏捷开发模式下,开发人员每一个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备2023014753号-2
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

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