51Testing软件测试论坛

标题: 有效控制BUG的问题！！急！！ [打印本页]

作者: feng_j20 时间: 2006-3-20 16:14
标题: 有效控制BUG的问题！！急！！
大家好：
   我们公司的测试流程是：一个产品定版之后，交给测试人员进行测试，测试出BUG后交给开发人员修复，开发人员修复并提交后，经测试此功能已经修复。关闭BUG
问题：
   当开发人员改好一个BUG后，把其它的功能(经测试已经通过的功能)改出问题来了，这个问题怎么进行有效的避免呢？
   我想测试人员不可能在改好一个BUG，对所有的功能进行测试的，可是如何有效的避免这种情况的发生呢，请大家从开发、配置、测试三方面提供一些宝贵的意见
   不胜感激！！！

作者: wzb521 时间: 2006-3-20 22:36
这种问题很正常，不管你用了再好的开发人员也无法避免。
1、经验
2、开发流程
3、开发方法
4、开发模式
5、编程约束
6、单元测试
7、自动测试

作者: luoyear 时间: 2006-3-20 23:36
召开ＣＣＢ会议　把Ｂｕｇ纳入对代码的变更　分析这个ｂｕｇ的波及范围　从而避免错上改错

作者: feng_j20 时间: 2006-3-21 11:22
二楼的：你能不能把你的想法细化？？
三楼的：在版本刚出来的时候BUG是最多的，不可能对于每个BUG都开变更会议吧？

作者: luoyear 时间: 2006-3-21 17:29
1)为什么版本刚出来就该这么多缺陷？多到什么程度？版本交付到测试不是不是应该有标准？
2)可以成批的周期性的开会。比方2－3天一次？

作者: feng_j20 时间: 2006-3-22 08:37
1)版本经过开发单元测试后，就交给我们做集成测试及功能测试，这个时候BUG每天2个左右是非常正常的，有时候会达到4、5个也不为过
2)假如2~3天开一次会议，是不是延误了开发人员修改BUG的时间，开CCB会议的主要议程是什么？

作者: 平和地面对一切 时间: 2006-3-22 09:51
各位公司的开发水平都很高了，版本提交初期BUG数都在个位数，佩服！
我们的至少都是2位数的BUG。。。。。。。

作者: chenkangone 时间: 2006-3-30 11:58
要想彻底解决这个是不可能的,关键是如何减少这样的错误,这要靠编码人员对业务的熟悉程度,在改问题时不能只考虑如何将此这个问题解决,还要考虑对其他地方的影响.

作者: kai_top 时间: 2006-3-30 18:47
我也遇到这类问题：修复一个BUG，引发其它BUG；
我想，我们功能测试人员，或许只能从业务流程方面进行考虑，越熟悉业务流程特别是逻辑流程，各组件模块之间的关系，越能防范，这就要求对软件的架构有充分了解；
我当时建议在BUG提交单上多设置一项“代码修改的功能范围”，就是程序员在修复BUG时，修改了哪些部分的原代码，所涉及的功能，大致列一下，这样会给我们一个很好的指导；

作者: atce 时间: 2006-3-31 16:51
0。区分BUG等级，高优先级/严重性的要求在BUG提交单上多设置一项“代码修改的功能范围”。
1。设立产品进入集成测试及功能测试标准，一旦发现高严重性BUG，立即停止测试，返回开发。
2。记录因开发人员改好BUG后改出问题的案例并反馈开发。

作者: milu 时间: 2010-8-3 00:08
RD修改了一个BUG后，要说明下影响范围。便于我们测试。通常改了一个BUG，常常也引起了其他问题

作者: ryan_en 时间: 2010-8-23 16:02
我们是先确认所有bug是否修复，修复了的话，会全部回归一遍。不过我们的项目都不大，回归测试起来比较快

作者: ruirui。 时间: 2011-4-27 10:47
怎么样让开发人员意识到修复Bug 所引起的其他Bug 带来的严重后果？

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)