问题描述：

　　软件产品发布后的遗留缺陷如何跟踪和处理？

　　出自51Testing论坛每周一问活动，详情请见：http://bbs.51testing.com/forum-157-1.html

会员jiangxk：

　　遗留的也要处理，必须的。

　　要回答这个问题，需要弄明白几个要点：

　　1、什么是遗留缺陷？

　　这有两个关键词：遗留、缺陷。首先，它是缺陷，即表明产品还存在不足、不完善、需要改进的地方；其次，它是遗留的，即表明这些缺陷不影响产品的正常使用或者尚未被发现。由此我们把遗留缺陷分为两大类，一类是已知的，不影响产品的正常使用，这些缺陷是轻微的或者是产品的边缘功能，因此才可能在存在缺陷的情况下发布产品；另一类是未知的，产品交付时未发现的缺陷，可能会被用户发现或者产品团队的后续测试中发现，这些缺陷有可能是严重的，甚至致命的。

　　已知的遗留缺陷可以尽量避免，但是未知的遗留缺陷是避免不了的。

　　2、遗留缺陷的处理方式？

　　因为两类遗留缺陷的差别很大，我们不能一概而论采用统一的处理方式，建议分类处理。

　　对于已知类的遗留缺陷，首先是它们必须被记录下来，可以作为后续研发周期的参考，也可以是产品支持的问题库；其次，在考虑成本、研发周期的情况下，可以进行部分缺陷的修复，并作为补丁发布；第三，如果后续研发使用了不同的技术和业务模式，某些缺陷不再是新产品中的缺陷了，它们将停留在以前的研发版本中（仍然被记录着）；第四，这些缺陷可能永远不会被修复，就让它们呆在那里好了，我们仍然可以在缺陷库中查询到它们。

　　对于未知类的遗留缺陷，首先是当发现它们时，记录下来，根据严重程度、优先级进行分类；其次，根据优先级和严重程度的高低进行处理，低优先级轻微的缺陷可以转为已知的遗留缺陷；第三，暂时处理不了的重要缺陷记录下来，并告知相关客户原因和临时处置办法（比如临时屏蔽或者手动维护），这些缺陷将在后续研发周期优先考虑；第四，已处理的缺陷作为补丁发布；第五，测试人员和开发人员审视这些缺陷，找出它们被遗漏的原因，以便在今后的工作中尽早发现和解决这些类的缺陷。

　　3、修复后如何发布？

　　缺陷修复后一定是通过补丁包发布，但不同客户的情况不同，发布方式也需要仔细考虑。

　　第一，对于公共的常见缺陷，可以通过主动发送或者网站下载的方式升级；

　　第二，对于公共的不常见缺陷（同一功能，不同客户使用的程度不同，因此某些缺陷对于一些客户是未发现的），通过定向发送来升级，不建议统一升级的主要理由是升级也有成本，无论是客户还是我们自己；

　　第三，对于特定功能的缺陷，因为这些功能只有部分客户使用，通过定向发送来升级。

会员yolander：

　　这个话题我很喜欢，缺陷管理既涉及到测试，又涉及到管理和统计学的问题，所以非常有意思，那么针对缺陷比较合理的处理办法是怎样的呢，我们公司目前也还在摸索当中，下面是我个人的一点点看法：

　　1、按以往的测试经验，你会发现从单一的角度其实很难去评价缺陷，需要先定义缺陷的评价维度，例如：严重程度、再现频率、对用户的影响，很有可能，最终我们得到的是一个二维、三维，甚至多维的缺陷评价系统。

　　2、在这么复杂的评价系统里，有时很难找到缺陷的位置，无法以直观的表格呈现缺陷的分布情况，所以我们还要制定一组打分制度，如：严重程度，可以从对用户或者环境造成严重危害——微不足道的问题，分别给予从高到低的分数等级，为了方便操作，每个分数等级还要伴随相应的语言文字表述，以便于测试人员区分和判断。

　　3、根据缺陷在不同维度上的评价分数的乘积，得到缺陷的最终级别，再从最初我们制定好的不同级别缺陷的处理办法上判断该问题是否在允许遗留的范围内。

　　如果是处在允许遗留的范围，那么项目就可以照常发布，这类问题可以在产品的后续生命周期维护计划里进行处理，例如：打patch，加notice或者releasenote等，提醒用户或操作人员如何避免此类问题出现。

　　如果是在不允许遗留的范围，那么无论如何，都要将问题彻底解决才可以发布，以免在发布后造成不必要的损失甚至其他不可预期的伤害，尤其是需要关注与系统安全相关的问题。

版权声明：本文出自51Testing软件测试网，感谢会员jiangxk,yolander在每周一问（09-06-01）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

原创作品，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。