前一篇文章中，提到了测试流程中关于bug定义，流程方面的一些争论。

　　我之所以选择这个话题作为blog的第一篇文章，因为我也有过类似的体会。

　　这里把这三个问题再列一下：

　　1、一般来说，在项目准备阶段，会树立一个缺陷等级（bug bar），定义缺陷的严重程度。随着项目的进行，这个缺陷等级应该发生变化呢，还是应该保持不变呢？

　　2、当发现一个bug后，会根据缺陷等级来定义这个bug的严重度，比如1级，2级或者3级。一旦一个bug被发现并且赋予了对应严重等级后，是否存在其他因素导致这个bug的现有等级发生变化呢？比如研究后发现，修复某一个bug可能需要花很多时间，这个发现会导致这个bug的严重度变化吗？

　　3、对于发现的bug，修还是不修，取决于哪些因素？除了bug的严重程度和对用户的影响外，目前团队的进度和资源对做决定是否有影响呢？比如本来有些开始准备修的bug，到了后来发现开发进度滞后了，会不会就决定不去修这些bug了呢？

　　回到上面的话题，我这里先把测试总监的回答帖下来：

　　1、缺陷等级（bug bar）是根据产品质量标准来定义的。在不同的产品周期（milestone），缺陷等级标杆可以是不同的。比如在临近项目结束，已经到了BETA的最后阶段，或者马上就要RTM发布了，这个时候的缺陷等级标杆就会非常的高。这是为了防止项目后期regression的风险。

　　2、bug的严重程度，是把这个bug给客户带来的影响，同缺陷等级标杆比较得出来的。只要这两个因素没有发生变化，那bug的严重程度就不应该变化。对于修复bug所需要的开销，当前项目的进度等，都不应该对bug的严重程度计算有任何的影响。

　　3、一个bug修还是不修，同样是有当前产品周期的缺陷等级标杆所定义的。如果预先已经定义好了哪一个级别以上的bug，必须在当前（milestone）修掉，那就一定要修。如果时间不够，那只有延长当前项目周期。或者极端的时候，会评量是否需要裁减功能。但总的来说，对当前产品周期定义好的质量标杆才是修或者不修的标准。当前bug数量，资源，进度什么的，都不是考虑的因素。

　　上面的回答，是小王和测试总监面谈后，测试总监专门总结下来通过电子邮件发给小王的。

　　小王非常满意测试总监明确利索的回答。但是，这并不等于小王心中的阴霾就以扫而光了。小王接下来又问了这样一个问题：

　　“现在项目比较被动，作为测试人员，我会按照上面的标准，尽量把产品缺陷提前找出来，并且坚持上诉原则，确保产品质量。但是这么多bug都一定要坚持修的话，看来推迟产品发布很难避免了。那到了最后作工作总结的话，作为测试人员，既然我做好了测试工作，也坚持了产品质量原则，那产品延期是不是我就不需要承担责任，反而应该得到奖励呢？”

　　请问，测试总监的第二封email应该怎么回答呢？

　　PS：

　　如同有朋友卡通一下提到的那样，这是没有正解的。看了大家对前一篇blog的回复，发现不同的人看待同样的问题，角度和思维都有不少差异。有的直接去考虑出现这种被动情况的根源在哪里，有的追求解决当前问题的现实可行办法，还有的认为测试人员的基本原则才是最重要的。我觉得这样的讨论非常有意思，同时也想听听各位对于软件测试，有哪些感兴趣的话题？

　　总结一下各位朋友的观点，和网上其它渠道收集到的一些看法：

　　看法1：

　　1、bug等级应该分两种：严重程度和优先程度，严重程度是不会变的，优先程度在不同的阶段是不一样的。

　　2、严重程度和是不是有足够的时间修复是没有关系的，不能说这个人快死了，现在没时间医就说他还好着呢。

　　3、都有影响的，严重程度和进度都会影响到一个bug是不是应该修复，但是不是要修复bug不应该是开发人员自己决定的，也不应该是测试人员单独决定的，应该由开发，测试和PM共同决定，如果这个bug很严重，即使延期也必须修复，不那么严重，则可以推迟到下一个版本再做修复。

　　看法2：

　　如果我是小王，那么此时我到是觉得我必须要尽职尽责，对目前系统存在bug进行归类总结，分出bug的优先顺序以及bug出现所属rootcase，并更具这些归类做一个整体的解决方案，然后尽可能的去和开发人员进行沟通，尽可能做到既不影响当前的开发进度又能解决这些bug，当然解决bug的前提是以及你掌握的优先级的，比如决策性的bug、逻辑混乱的bug等等那是必须需要当即进行修正的。

　　同时了，此时和老板进行交流时，我想就不会是用一堆bug来和老板面谈了，而是说目前系统存在了bug，而现在我制定了解决bug的方案，我也尽力说服大家来对bug做修改了，同时也保证了开发进度。

　　看法3：

　　1、缺陷等级不一定等同于优先级。问题的严重程度并不一定取决于问题的技术性质。很多项目，问题是否能得到及时解决取决于该功能是否常用，影响面是否广大等因素。至于说到缺陷等级是否变更，我觉得要看你这个缺陷等级所要表述的是什么概念。

　　2、看了这个问题，前面的问题，即缺陷等级，可能偏向于缺陷本身的性质这样一个概念。那么，的确存在相关因素会导致这个bug的修改优先级发生变化。例如：形象因素等等。

　　3.1 Bug修改与否，取决于较多因素，常见的是以下几种情况

　　3.1.1 bug本身的性质

　　3.1.2 Bug的影响面，是否会影响现行业务或对业务支撑造成不可弥补的错误

　　3.1.3 不修改会存在巨大隐患么？

　　3.1.4 客户关注

　　3.2 客观而言，不会。有影响的只是项目最终交付的时间和进度计划。当然，随着项目推进，之前的bug可能会被冲叠，造成隐匿，这种情况的隐患极大。所以，必须强调的是Bug修改优先于新功能开发。

　　3.3 这种情况最好不要出现，一旦发生，即意味着项目可能会出现较大的不可控因素，导致质量的急剧下降。除非，这块功能不再使用，或之前的需求存在漏洞需要重新考量。

　　看法4：

　　1、个人认为不应该变化。

　　2、严重等级一般不会发生变化，而发生变化的可能是优先等级，这是两个概念。

　　3、修还是不修，主要是看这个BUG是否在进度的关键路径上或核心功能模块，如果在那么就必须干掉，否则可以postponed；进度和资源当然有影响，这些都是需要项目团队及早的做风险管理规划的，如果协调不好资源和进度，那么非关键路径上的问题可能会成为关键路径上的问题，那么这个时候就对团队的执行决策产生影响；发现的BUG应该都要修的，只不过会根据进度安排，把一些不重要的BUG推迟到下一个版本修复

　　看法5：

　　这件事说明一个问题！测试人员在公司的生存状态！换成我，我也不会妥协，Bug可以pending，但是不能一直拖下去，你们公司如果这样发展下去，迟早要出问题的！我现在会定期去查看Bug状态分析图，如果open的bug多的话，我会要求开发暂停新功能的开发，先处理Bug，我想这样是对公司，对客户，对自己负责，测试有时候要强硬一点！

　　上述的看法我觉得没有谁对谁错。因为不同的公司和不同的项目特点，决定了解决问题的方法会各有不同。从国内的不少技术社区了解到，很多人觉得国内测试水平比较落后，其中例子就有比如没有统一的规范，对测试不够重视等。这里我会尽我所能对测试领域做一些分析和讨论，希望有所帮助。