冗长的Bug跟踪

发表于:2013-6-09 09:28

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:未知    来源:51Testing软件测试网采编

#
Bug
分享:

  这是一个典型的Bug跟踪过程,设计者笃信只有完整的检查才会保证修改一个Bug的时候不会产生另外一个Bug。但是现实好像总是跟他作对,Bug返回率一直居高不下。于是设计者修订了流程,增加了几个步骤。他希望问题能够通过复查被发现出来。但是增加了流程以后Bug返回率反而提高了。

  “这是人的问题!”流程设计者认为。

  这不是人的问题,这是流程的问题。我说。

  另外一个团队,并没有采用这样的模型,Bug返回率却很低,而且修改的时间明显的要短于前一个团队。他们采用的是这个流程:

  这个流程和前一个流程的最大区别在于测试是自动进行的,而且由开发团队自己进行管理。这是开发团队的内部流程,由测试团队提出的Bug,将会被首先整理成一组测试用例来进行复现,自动测试中的代码可以自由修改,所以,问题定位要快的多,并且修改了代码以后,可以马上对测试用例进行回归测试。很快就可以知道是否修改完毕。并且,对于有影响的模块,由于已经有了大量的测试用例,可以全部回归,从而避免了因为影响性分析不充分而造成的Bug返回,所以大大的降低了Bug的返回率。

  我们为一家大型电信公司做咨询的时候,他们采用了比图1更加复杂的流程,还有上传修改代码和确认的过程,但是效果没有得到改善,而且所耗时间更长。在采用了我们帮助其完善的新流程以后,Bug修改时间和效果上都得到了大大的改善。

  注:Bug返回率是指,开发团队将修改后的代码提交给测试团队以后,测试团队验证Bug修改状况,对于没有修改正确的Bug返回到开发团队的情况称作返回。返回个数占修改个数的比例称作Bug返回率。

《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号