51Testing软件测试论坛

标题: 遗留缺陷如何处理？（09-06-01）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2009-6-1 17:25
标题: 遗留缺陷如何处理？（09-06-01）（获奖名单已公布）
软件产品发布后，如何对遗留缺陷进行跟踪以及处理？

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

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

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

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

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

作者: kuailederen 时间: 2009-6-2 09:59
占楼层，然后再回答，专业级的哟

作者: kiyu 时间: 2009-6-2 14:28
在升级版本中修改

作者: cagemm 时间: 2009-6-2 20:22
对遗留问题详细说明遗留原因，需要再下一版本修改的，需要在下一版本进行验证。

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

作者: zyp_test 时间: 2009-6-4 15:47
长期合作伙伴的话等下期再进行改进修改
如果下期开发工作不继续合作的话就应该和客户好好谈谈
是继续修改还是……

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

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

作者: 君星 时间: 2009-6-7 00:18
标题: 这次没占到好楼层，
下次一定占个好楼层。
关于遗留的缺陷
1、测试不可能找出所有的缺陷
2、不可能在有限的时间里修正所有缺陷
3、做好遗漏缺陷产品发布后管理

作者: yolander 时间: 2009-6-8 09:50

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

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

作者: xuemeili1216 时间: 2009-6-8 11:29
个人见解
产品发布后　安排项目中专人跟踪　期间可以自行测试（如发现缺陷　也要向客户说明）

作者: 天空下下雨 时间: 2009-6-8 17:46
我认为产品发布后，遗留缺陷在风险上应属于可控的。
可以按风险处理机置来处理。
适当的告知客户，并提供处理方法。
与客户协商解决的方法和解决的时间。

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

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

作者: reshma 时间: 2009-6-10 09:37
这要综合各方面考虑决定啊，问题的严重性，客户的认可度，修改成本以及时间成本。

作者: diewuyezi 时间: 2009-6-11 12:00
标题: 回复 9# 的帖子

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

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

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

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

需要全员参与那!!!!

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

作者: ganhuiping 时间: 2009-6-11 13:08
看缺陷的优先级，会不会影响用户使用。处理的时候最好做好跟踪记录。

作者: shandanjue 时间: 2009-6-11 13:20
遗留缺陷如何处理
我认为从软件发布后,会存在发布前和发布后出现的遗留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,完成后统一处理

作者: jiangxk 时间: 2009-6-11 15:10
标题: 遗留的也要处理，必须的
要回答这个问题，需要弄明白几个要点：
1、什么是遗留缺陷？

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

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

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

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

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

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

3、修复后如何发布？

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

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

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

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

作者: chengxq 时间: 2009-6-19 14:49
产品发布之后，对遗留缺陷首先要和客户说明，最好给出处理bug 的进度，这中间需要关注的是版本管理

作者: 快乐的布丁 时间: 2009-6-25 17:41
对遗留问题详细说明遗留原因，需要再下一版本修改的，需要在下一版本进行验证。

作者: zllzh 时间: 2009-11-17 16:30

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

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

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

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

作者: 8596991 时间: 2010-5-16 10:30
学习了，遗留问题需要经过讨论，分类处理

作者: bjwj 时间: 2010-6-29 18:00
不错，有些处理方法值得学习！

作者: zpzs 时间: 2010-7-28 15:51
标题: 宝贵经验。
宝贵经验。宝贵经验。

作者: qxhc 时间: 2010-10-27 14:23
值得借鉴....

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

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)