系统测试一定要所有的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

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

肚皮

如果，开发人员解决了那些bug，确又由于解决了那些bug导致了新的bug，我以什么方式记录呢

肚皮

在测试以后，那些没有解决的bug又泠泠落落的提交上来，再测试，如果发现bug再等待解决，那就太繁琐了

肚皮

在测试以后，那些没有解决的bug又泠泠落落的提交上来，再测试，如果发现bug再等待解决，那就太繁琐了

paradoxer

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

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

Lighthouse

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

肚皮

我总是觉得很混乱

森林一木

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

鹿鸣

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

orange1997orang

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

哎呀,真麻烦!

小蛮

谢谢