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

默默巫

软件产品发布后，如何对遗留缺陷进行跟踪以及处理？

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	jiangxk	当当购物卡50元	22#
二等奖	yolander	300论坛积分	9#
三等奖	yhfeifei	100论坛积分	19#

qxhc

值得借鉴....

上线后发现的重大遗留问题后果应该由who来承担呢？

zpzs

宝贵经验。宝贵经验。

bjwj

不错，有些处理方法值得学习！

8596991

学习了，遗留问题需要经过讨论，分类处理

zllzh

原帖由 jiangxk 于 2009-6-11 15:10 发表
要回答这个问题，需要弄明白几个要点：
1、什么是遗留缺陷？

    这有两个关键词：遗留、缺陷。首先，它是缺陷，即表明产品还存在不足、不完善、需要改进的地方；其次，它是遗留的，即表明这些缺陷不影响产品的正 ...

请问定向发送是什么意思？？？没看明白～
对于没有使用而无发现BUG的，暂不用升级，我个人有点疑问，如果后期用户发现了BUG，而且造成更大损失的话怎么办，应该说是严重BUG要立即升级，微小的BUG可暂缓～

[ 本帖最后由 zllzh 于 2009-11-17 16:34 编辑 ]

快乐的布丁

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

chengxq

产品发布之后，对遗留缺陷首先要和客户说明，最好给出处理bug 的进度，这中间需要关注的是版本管理

jiangxk

要回答这个问题，需要弄明白几个要点：
1、什么是遗留缺陷？

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

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

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

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

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

3、修复后如何发布？

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

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

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

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

shandanjue

遗留缺陷如何处理
我认为从软件发布后,会存在发布前和发布后出现的遗留bug,在此简称下几个方面进行处理:
  1. 用户UAT或测试阶段:
     即系统开发或用户UAT时出的bug.
    a 涉及到用户需求或是功能的bug需处理完毕;
    b 如标签或是字段整体长度的统一,需整个系统进行统一调整,但不影响用户使用,此轻微类型的bug,可放在整个系统投入使用后,进行统一修改;
  c 测试或用户UAT出现的异常bug,只出个一次,以后无重现或出现的bug,在以后更新版本后,没出现的bug,将进行备注,并remind
  d 用户提出新需求,将导致当前使用的系统出现功能或逻辑的错误,将等到
  下一个阶段进行修改
2.Realse
   a. 由于用户服务器性低导致系统运造成的问题,建议用户更换服务器硬件配置,需用户购置或更换服务器后才能解决,此类bug 将closed
  b. 用户提出修改的方案,在最终又未确认修改或是系统已具备类似的功能,将closed
c. 如客户使用出现的bug,需即显示处理
d.测试或用户UAT出现的异常bug,只出个一次,以后无重现或出现的bug,在以后更新版本后,没出现的bug,将进行备注,并remind,完成后统一处理

ganhuiping

看缺陷的优先级，会不会影响用户使用。处理的时候最好做好跟踪记录。

yhfeifei

软件发布后可能会产生的bug有两种情况
1.客户发现 :在使用过程中,经由售后人员接受客户反馈后得到或者软件中提供报错日志得到.
2.内部发现:公司内部同事发现,包括公司内任何使用过该软件的成员
那么我们应该分别对这两种情况进行处理
1.客户发现的bug:能让客户投诉上门的bug一般是很严重的,毫无疑问需要马上修改.售后或支持人员将bug通过缺陷管理工具进行提交,项目质量工程师将定义bug修改时间和修改方案,通过升级包给客户升级.
2.内部人员发现的bug:也统一提交到缺陷管理系统上,项目质量工程师和项目经理共同决定bug的等级缺陷.若bug比较严重,会存在影响客户使用的隐患,需及时将bug进行修复,若bug等级评定为低,则项目测试经理,项目经理和质量经理统计bug并,商议修改方案及时间,使用升级包升级,若人手足够,可采用定期升级策略.

缺陷管理工具上应该专门开辟项目发布后的bug提交的专栏(不与发布前的bug混淆).项目质量工程师和项目经理每天跟踪

这个过程牵扯到项目的管理策略和对项目主要参与者对项目的关注程度.如果哪个环节出现迟滞,有些bug可能永远都得不到修复

需要全员参与那!!!!

[ 本帖最后由 yhfeifei 于 2009-6-11 12:09 编辑 ]

diewuyezi

维度的东西看着好像很复杂呢！

reshma

这要综合各方面考虑决定啊，问题的严重性，客户的认可度，修改成本以及时间成本。

木木妹

根据缺陷严重性，选择是否继续修改，跟踪关闭。剩余缺陷分为两类
1 对程序运行留有隐患或阻碍使用，这部分一定要跟踪关闭，并尽快给客户更新。
2不影响使用，建议改善。这部分建议暂缓修改，如果有下一版本的开发，需求讨论时提出，得到用户确认后再修改。没有确认的全部放过，不做修改

kenny1898

项目进行到后期，项目经理和开发、测试组长针对已发现版本存在的缺陷经过综合评估风险可控度与项目紧急程度，而最终确定部分风险可控（对用户影响小、出现几率很低且出现后易恢复）的问题做遗留处理，该类问题一般通过发布补丁或在后续版本中解决，版本发布后要有专人负责跟踪了解遗留问题对用户的实际影响，确认与所做风险评估是否存在偏差，以决定是否有必要发布缺陷补丁或后续版本，当然根据实际情况也要尊重到用户意见。所谓版本发布时未发现问题应不属于版本遗留缺陷，而属于遗漏缺陷，至于遗漏问题应视缺陷严重性、对用户影响程度以及出现频率确定是否立即采取相应补救措施。

天空下下雨

我认为产品发布后，遗留缺陷在风险上应属于可控的。
可以按风险处理机置来处理。
适当的告知客户，并提供处理方法。
与客户协商解决的方法和解决的时间。

xuemeili1216

个人见解
产品发布后　安排项目中专人跟踪　期间可以自行测试（如发现缺陷　也要向客户说明）

yolander

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

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

君星

下次一定占个好楼层。
关于遗留的缺陷
1、测试不可能找出所有的缺陷
2、不可能在有限的时间里修正所有缺陷
3、做好遗漏缺陷产品发布后管理