假如在版本发布前一天发现重要BUG应该怎么处理？

snail_huang

如题~

macdull

如果 你还想在 公司里 活着 就 装作什么都不知道！

sundyhui0322

哈哈，有意思！
我还是那个观点，问题还是要报，但问题是否在这一版解决是另外考虑的事情。

逍遥剑客

再补充一句事后的注意事项：
在以后的项目或升级版本的测试用例中，要特别加入针对性的测试用例。要特别加强问题发生模块的测试工作。

逍遥剑客

通常的解决方法和概要步骤如下：
１、实事求是的纪录ＢＵＧ，并提交至ＢＵＧ管理库
２、想办法（打电话或直接面谈）第一时间通知上司（一般是项目经理）
３、向上司详细描述ＢＵＧ的出现步骤，出现机率，严重程度等相关重要的ＢＵＧ说明
４、联系研发方面的负责人，同项目经理一起开个临时会议，评估ＢＵＧ保留或修改带来的风险。
５、最后把ＢＵＧ的风险评估报告和紧急解决方案纪录在案，三方签字
６、按照紧急解决方案实施解决

补充说明：整个过程时间控制在２０分钟左右

逍遥剑客

原帖由 Giomy 于 2008-6-11 17:50 发表
干嘛不能做到尽早发现BUG呢？
如果前期管理好，测试工作做的细致，就不会出现这样紧急情况。
如果面试的时候面试官问我这个问题，我就会告诉他，你们的测试管理有问题，赶快录用我，我帮你改善测试管理，包你软件发 ...

到了实际工作的时候这位同学就明白理想和现实之间的差别了。

顺便问一句：

在培训的时候有没有学过： 就算前期的管理再好，测试工作做得再细致，这类紧急的情况也不是一定能够避免的。

[ 本帖最后由 逍遥剑客 于 2008-7-4 16:12 编辑 ]

limengyun326

报告上级
上头说发布就发布,说不发布就不发布
1. 报告BUG是测试人员职责
2. 即使有严重BUG,也要让上级判断是否影响发布. 上级会根据利弊,选择适合的方案.
3. 即使提交BUG可以更早得修正.大家不要急,维护这个阶段又不是摆着看的.
4. 即使必须发布,也可以和用户先提出,让他们尽可能避免使用该功能,减少用户损失.

以上,请补充.

zhang_jun_

吹牛不上税吗？

meng0819

太过于简单,这样大家看不到具体的原因,还是需要看另外的帖子.浪费你自己的时间,也浪费我们的时间.

baizhudan

要知道改一个BUG意味着什么？意味着一个从未测试的新版本的诞生～！而明天就要发布。

再细化一点，如果这个BUG是个用户就能发现，那没办法，比如，启动软件就CRASH。那肯定是不行的。如果说同样是CRASH，但必须在用户操作了若干复杂步骤后或者说是一个概率性的CRASH，那在去冒着风险诞生一个新版本那无异于自杀。

比如这就有一个类似的BUG：http://bbs.51testing.com/thread-117301-1-1.html

[ 本帖最后由 baizhudan 于 2008-6-17 16:13 编辑 ]

baizhudan

原帖由 Giomy 于 2008-6-11 17:50 发表
干嘛不能做到尽早发现BUG呢？
如果前期管理好，测试工作做的细致，就不会出现这样紧急情况。
如果面试的时候面试官问我这个问题，我就会告诉他，你们的测试管理有问题，赶快录用我，我帮你改善测试管理，包你软件发 ...

得了吧，人无完人，BUG永远是不可知的我们永远是被动的。

baizhudan

同意2楼的，职场这东西就是这样。

tuzanwu

要看具体情况咯，在版本发布前一天发现BUG，我觉得应对BUG进行分析，看BUG出现在什么模块中，如果有必要就把存在BUG的的那个模块先关闭不发布或暂缓发布，待BUG修复后重新打开那个模块。

livehome2008

我想这样在最后才发现的Bug，一是说明之前的测试做地不够全面， 二也有可能是，这个Bug不是那么容易能被发现，很可能是偶尔发生的缺陷，在特定的条件或环境下，才会触发；像这样的Bug要发现，已经是不容易，即使 找到后要确诊这是一个Bug，也需要一定时间，对于明天就要发布的软件，项目组要和时间竞赛，看看大家的身体素质如何？，不过昨天听了一段“山上有个坑”的故事，听完后觉得要是遇到这样的事情，还是要做个有心人，至少也要插个牌子什么的，以免死的人更多。

电脑这个东西，是让人类前进了一大步，但同时也可能给地球带来灭顶之灾，你想吧！要是一个军事软件发生了严重的bug,或是被骇客了，那些导弹、核弹乱飞...
我以前的老师这么说过， Why HCI?------->To save the planet.
改一改就是: Why testing? ------->To be safe.

好像有这么个电影是说这个的，哈哈，我能当导演了！

sundyhui0322

其实测试中这种问题还是不少发生的。隐瞒不报，你会死的更馋，因为测试是要有追溯性的，若你这个版本发现切是很严重的问题，那么上一个版本毕竟要对这个问题进行验证，因为这样开发才好排出是否是因为这次的改动而带来的bug，这样bug的root course寻找就排除了一个危险可能性。
所以对于测试人员来说对上版的验证是必要的，若这时你说你也发现了，那么我只能很遗憾的告诉你，不仅外边钉你 ，你老板也钉你。
但你若及时发现及时上报，至少这时你老板对外还能帮你抗。当然了，谁也不期望这种事情发生。可是谁也不能保证你的case能100%覆盖所有可能出现bug的路径。只能是从这一次的教训中吸取经验，来完善你的测试case。
当然，楼上有人已经说了你汇报bug的态度。这里就不重复，重要的一点，你要事先分析为什么你之前的测试没有发现这个bug，这个问题的发生机率有多大，是否是属于应该较容易发现的bug。其实分析这些也是给你自己开脱的机会，你要让老板知道这些分析，他才有话对外减轻责任。所以冷静的头脑是很重要的。

xfde51

强烈建议连夜赶写辞职报告。。。我是老大一定杀无赦！！

Giomy

干嘛不能做到尽早发现BUG呢？
如果前期管理好，测试工作做的细致，就不会出现这样紧急情况。
如果面试的时候面试官问我这个问题，我就会告诉他，你们的测试管理有问题，赶快录用我，我帮你改善测试管理，包你软件发布顺顺当当！！！

jeffrey_yan

我也觉得应该婉转的告诉项目经理或者老板，让他们应该知道，这应该是职业操守吧！

red-hat

论坛里有过类似的文章，自己搜索一下

livehome2008

当然要赶紧告诉，不过注意语言的艺术，说话镇定点，语速稍慢，
不要让人觉得有因突发事件而引起的局部恐慌，
要让你的老板觉得你对此项目的高度认真负责的态度。

如果老板应压力过大，而急躁情绪，我看你和开发们就尽一切可能，不睡觉也要把bug除掉，做个尽全力的姿态也是必要的嘛！
宗旨：把损失降到最低，尽全力去处Bug。