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

yolander

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

yolander

原帖由 tails82 于 2009-6-5 21:48 发表
我认为这是一个很常规的做法，关键在于每个维度的权重如何确定。这需要长期的实验摸索。并且不能仅局限于缺陷本身的属性来制定评价维度，还要考虑到时间成本，商业先机等众多方面。而且要达到如此精密的评价体系要求 ...

是的，所以说我们目前还在摸索中，如果有好的建议不妨说来听听