遗留缺陷如何处理？（09-06-01）（获奖名单已公布）

tails82

我认为这是一个很常规的做法，关键在于每个维度的权重如何确定。这需要长期的实验摸索。并且不能仅局限于缺陷本身的属性来制定评价维度，还要考虑到时间成本，商业先机等众多方面。而且要达到如此精密的评价体系要求，也需要有稳定的技术团队，成熟的度量体系等。

yolander

这个话题我很喜欢，缺陷管理既涉及到测试，又涉及到管理和统计学的问题，所以非常有意思，那么针对缺陷比较合理的处理办法是怎样的呢，我们公司目前也还在摸索当中，下面是我个人的一点点看法：
1、按以往的测试经验，你会发现从单一的角度其实很难去评价缺陷，需要先定义缺陷的评价维度，例如：严重程度、再现频率、对用户的影响，很有可能，最终我们得到的是一个二维、三维，甚至多维的缺陷评价系统
2、在这么复杂的评价系统里，有时很难找到缺陷的位置，无法以直观的表格呈现缺陷的分布情况，所以我们还要制定一组打分制度，如：严重程度，可以从对用户或者环境造成严重危害——微不足道的问题，分别给予从高到低的分数等级，为了方便操作，每个分数等级还要伴随相应的语言文字表述，以便于测试人员区分和判断
3、根据缺陷在不同维度上的评价分数的乘积，得到缺陷的最终级别，再从最初我们制定好的不同级别缺陷的处理办法上判断该问题是否在允许遗留的范围内
如果是处在允许遗留的范围，那么项目就可以照常发布，这类问题可以在产品的后续生命周期维护计划里进行处理，例如：打patch，加notice或者releasenote等，提醒用户或操作人员如何避免此类问题出现
如果是在不允许遗留的范围，那么无论如何，都要将问题彻底解决才可以发布，以免在发布后造成不必要的损失甚至其他不可预期的伤害，尤其是需要关注与系统安全相关的问题

zyp_test

长期合作伙伴的话 等下期再进行改进 修改
如果下期开发工作不继续合作的话就应该和客户好好谈谈
是继续修改还是……

zhangzhimei1004

软件遗留缺陷大部分都是通过制作补丁包修复的，但其中也有不同的情况。遗留缺陷有一部分是软件发布以前已测试出的Bug，包括一些很皮毛的Bug和一些很难修改的Bug，由于要尽快发布，并提交给客户，所以这样的Bug就等在以后的补丁包修改；另一部门是发布以后发现的，包括软件本身功能的Bug、不符合客户行业操作习惯的Bug以及客户使用后觉得操作不方便等等类似的Bug，这部分Bug就和客户商量，要如何修改，如果是本身功能的Bug，那就为客户制作补丁包；如果是功能以外的就要请销售去和客户谈，看是否在合同要求范围之内的或和客户关系不错，可以为他们免费做一部分，使他们方便使用。至于其他的就要看情况定了。

cagemm

对遗留问题详细说明遗留原因，需要再下一版本修改的，需要在下一版本进行验证。

kiyu

在升级版本中修改

kuailederen

占楼层，然后再回答，专业级的哟

知秋落叶

遗留缺陷的解决办法是在升级版本中修改，建议用户方式绕过，或者干脆不再进行修改，都应该有一个明确的答复，而且还需要指派专门的人员跟踪问题的解决情况，并进行报

[ 本帖最后由 知秋落叶 于 2009-6-1 21:18 编辑 ]

farmertester

个人觉得遗留缺陷可以分为两类，一类是在系统测试阶段已经发现但是由于项目时间紧张并且缺陷的影响范围很小所以遗留的缺陷，这类缺陷可以通过下发补丁程序来解决；
另一类是测试阶段没有发现而产品发布后用户在使用过程中由用户发现的，这类缺陷就需要先建立用户使用情况跟踪体系来及时了解到用户发现的bug，可以有专人来负责收集用户反映的bug，并且在产品发布的时候就明确告知用户发现缺陷该如何反馈给厂商。通常情况下只要系统测试做的比较好都不会出现需要回收重新开发这么严重的问题，所以最终的解决方法基本上还是靠发补丁来解决。