51Testing软件测试论坛

标题: 系统测试一定要所有的bug都解决才可以退出吗 [打印本页]

作者: 肚皮 时间: 2004-11-3 17:00
标题: 系统测试一定要所有的bug都解决才可以退出吗
2004-11-03 16:41:34 肚皮/rose
系统测试一定要所有的bug都解决才可以退出吗

2004-11-03 16:42:58 小涛涛
这个看你们公司怎么定义

2004-11-03 16:43:15 肚皮/rose
由我来定义

2004-11-03 16:44:21 小涛涛
那你安看着办啊，重要满足定出来的东西你有能力作到

2004-11-03 16:44:22 肚皮/rose
如果不全解决就退出，那么又以什么方式来跟踪那些bug

2004-11-03 16:45:29 小涛涛
那这个就要通过工具,还是其他方式了

2004-11-03 16:45:48 肚皮/rose
如果我的测试工作全做了，但是有一个bug，要拖很久才可以解决，我不是要被拖死了

2004-11-03 16:46:48 小涛涛
是的啊，所以一般不会等所有的bug都解决了测试才腿出

2004-11-03 16:47:32 肚皮/rose
但是那些没有解决的bug又是怎么去跟踪的

2004-11-03 16:48:41 肚皮/rose
如果，开发人员解决了那些bug，确又由于解决了那些bug导致了新的bug，我以什么方式记录呢

作者: skinapi 时间: 2004-11-3 17:39
个人觉得测试的退出并不需要所有的Bug都解决，但可以肯定的是所有提交的Bug都必须得到开发人员的明确答复，到底是修复还是延期解决还是忽略，否则测试不能退出。

作者: 肚皮 时间: 2004-11-3 20:05
如果，开发人员解决了那些bug，确又由于解决了那些bug导致了新的bug，我以什么方式记录呢

作者: 肚皮 时间: 2004-11-4 10:24
在测试以后，那些没有解决的bug又泠泠落落的提交上来，再测试，如果发现bug再等待解决，那就太繁琐了

作者: 肚皮 时间: 2004-11-4 10:25
在测试以后，那些没有解决的bug又泠泠落落的提交上来，再测试，如果发现bug再等待解决，那就太繁琐了

作者: paradoxer 时间: 2004-11-4 10:50
标题: 看你怎么定义“解决”这个概念了
一般我们认为，“解决”并不是说一定要完全修改过来，有时候是这个bug要延期修改，有时候是程序员认为修改这个要重新修改需求或设计，伤筋动骨，或者其他原因导致bug修改成本太高，那么可以延期，或者干脆不修改。这些都算是解决办法。
重要的一点是，这些情况我们要得到开发组长的答复，并且我们要能认可这样的解决办法，取得这样一个共识。确定了每一个bug的解决办法的时候，我们就可以说，这些bug都解决了。
如果和开发组长对于某一个bug的解决办法有分歧，则提交给项目经理，由他裁决。

关于测试完成后其他bug的跟踪问题：
其实我们现在做的测试是开发阶段的测试，那么后期的测试是维护阶段的事情。而现在的bug库我们是要一直保留下去的，后期出现bug，修改bug，跟踪Bug，其实流程和这个是一样的，只是由维护阶段的测试人员（可能还是我们^_^）完成。

作者: Lighthouse 时间: 2004-11-4 11:28
首先：bug是分类的。
其次：在测试计划中应该有系统测试完成的标准。
一般情况下：优先级高的bug没有解决，不能退出。优先级低的bug没有解决，可以考虑退出。

作者: 肚皮 时间: 2004-11-4 21:27
我总是觉得很混乱

作者: 森林一木 时间: 2004-11-20 13:13
等bug全部找出那就要到下个世纪了，需要一个评判的标准，测试计划制定的时候有个优先级，在RTM前根据优先级进行处理，而且需求用例中也有优先级的

作者: 鹿鸣 时间: 2004-11-22 09:05
我们的做法是：只要剩下的没有严重的错误（以不影响软件使用为界限），而且每个bug开发人员都给出了相应的不修改理由，经过测试部门负责人和项目经理的确认，程序就可以算测试完毕。

作者: orange1997orang 时间: 2004-11-25 14:34
BUG的分类评级原则
BUG 的大小、严重性在不同的系统中相差很多，最严重的BUG 会让开发者立刻放下手中的其他事来改正它们。不太严重的则是在时间和资源允许的情况下才去理会它们。
BUG按其严重性可以分为以下几类：
表1 按严重性划分BUG
严重等级描述
A极严重 1）可能有灾难性的后果或是会出人命的
2) 故意留有程序后门
B严重产生错误的结果，导致系统不稳定的问题
1）造成数据库不稳定的错误；
2）系统崩溃，无法继续操作
3）列在说明中的需求未在最终系统中实现
4）业务流程不正确
C中等的不正确的，但不会影响系统稳定性的
1）过程调用或其它脚本错误；
2）打印错误或打印出来的结果与用户的要求不一致
3）系统刷新错误；
4）产生错误结果，如计算结果错误等
5）功能的实现有问题。如在系统实现的界面上，一些可接受输入的控件点击后无作用；对数据库的操作不能正确实现
6）编码时数据类型、长度定义错误的；
7）对用户的使用有操作顺序上的限制
8）虽然正确性不受影响，但系统性能和响应时间受到影响
D一般性的不正确的，但是没有特别损害的输出，或者使系统使用起来不太方便的错误
1）系统的提示语不明确，不简明
2）滚动条无效
3）可编辑区和不可编辑区不明显，
4）光标跳转设置不好，鼠标（光标）定位错误；
5）对库记录指针，方向键无效时没有变灰
6）界面不一致，或界面不正确
E轻微的 1）日期或时间初始值错误（起止日期、时间没有限定）
2）按钮或标签上有拼写错误的单词、不正确的大小写

国标中有关BUG数量的描述
向用户提交软件进行验收时，对于软件中存在的BUG数量有如下的规定：
1．程序中不存在未改的A、B级BUG；C级BUG的数量每千行源代码（KLOC）中不超过1个；D、E级BUG的数量每千行源代码（KLOC）中不超过2个；对于随机出现的BUG的数量也必须考虑。
2．在交付给用户的文档资料中，允许存在的BUG数量按以下方法计算：用程序的千行源代码（KLOC）数量除以25，所得数加上3即为文档中允许存在的最大BUG数量。例如，如果程序的千行源代码（KLOC）的数量是1000，即该程序有1 000 000行源程序，则与该程序相关的文字资料中允许的最大BUG数就是（1000/25+3=）43个。

作者: limei 时间: 2004-11-25 14:38
哎呀,真麻烦!

作者: 小蛮 时间: 2004-11-26 15:16
谢谢

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