遗留缺陷如何处理？（09-06-01）（获奖名单已公布）
软件产品发布后，如何对遗留缺陷进行跟踪以及处理？如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
获奖名单奖项获奖名单奖励答案链接一等奖jiangxk当当购物卡50元22#二等奖yolander300论坛积分9#三等奖yhfeifei100论坛积分 19# 个人觉得遗留缺陷可以分为两类，一类是在系统测试阶段已经发现但是由于项目时间紧张并且缺陷的影响范围很小所以遗留的缺陷，这类缺陷可以通过下发补丁程序来解决；
另一类是测试阶段没有发现而产品发布后用户在使用过程中由用户发现的，这类缺陷就需要先建立用户使用情况跟踪体系来及时了解到用户发现的bug，可以有专人来负责收集用户反映的bug，并且在产品发布的时候就明确告知用户发现缺陷该如何反馈给厂商。通常情况下只要系统测试做的比较好都不会出现需要回收重新开发这么严重的问题，所以最终的解决方法基本上还是靠发补丁来解决。 遗留缺陷的解决办法是在升级版本中修改，建议用户方式绕过，或者干脆不再进行修改，都应该有一个明确的答复，而且还需要指派专门的人员跟踪问题的解决情况，并进行报
[ 本帖最后由 知秋落叶 于 2009-6-1 21:18 编辑 ] 占楼层，然后再回答，专业级的哟:lol 在升级版本中修改 对遗留问题详细说明遗留原因，需要再下一版本修改的，需要在下一版本进行验证。 软件遗留缺陷大部分都是通过制作补丁包修复的，但其中也有不同的情况。遗留缺陷有一部分是软件发布以前已测试出的Bug，包括一些很皮毛的Bug和一些很难修改的Bug，由于要尽快发布，并提交给客户，所以这样的Bug就等在以后的补丁包修改；另一部门是发布以后发现的，包括软件本身功能的Bug、不符合客户行业操作习惯的Bug以及客户使用后觉得操作不方便等等类似的Bug，这部分Bug就和客户商量，要如何修改，如果是本身功能的Bug，那就为客户制作补丁包；如果是功能以外的就要请销售去和客户谈，看是否在合同要求范围之内的或和客户关系不错，可以为他们免费做一部分，使他们方便使用。至于其他的就要看情况定了。 长期合作伙伴的话 等下期再进行改进 修改
如果下期开发工作不继续合作的话就应该和客户好好谈谈
是继续修改还是…… 这个话题我很喜欢，缺陷管理既涉及到测试，又涉及到管理和统计学的问题，所以非常有意思，那么针对缺陷比较合理的处理办法是怎样的呢，我们公司目前也还在摸索当中，下面是我个人的一点点看法：
1、按以往的测试经验，你会发现从单一的角度其实很难去评价缺陷，需要先定义缺陷的评价维度，例如：严重程度、再现频率、对用户的影响，很有可能，最终我们得到的是一个二维、三维，甚至多维的缺陷评价系统
2、在这么复杂的评价系统里，有时很难找到缺陷的位置，无法以直观的表格呈现缺陷的分布情况，所以我们还要制定一组打分制度，如：严重程度，可以从对用户或者环境造成严重危害——微不足道的问题，分别给予从高到低的分数等级，为了方便操作，每个分数等级还要伴随相应的语言文字表述，以便于测试人员区分和判断
3、根据缺陷在不同维度上的评价分数的乘积，得到缺陷的最终级别，再从最初我们制定好的不同级别缺陷的处理办法上判断该问题是否在允许遗留的范围内
如果是处在允许遗留的范围，那么项目就可以照常发布，这类问题可以在产品的后续生命周期维护计划里进行处理，例如：打patch，加notice或者releasenote等，提醒用户或操作人员如何避免此类问题出现
如果是在不允许遗留的范围，那么无论如何，都要将问题彻底解决才可以发布，以免在发布后造成不必要的损失甚至其他不可预期的伤害，尤其是需要关注与系统安全相关的问题
回复 9# 的帖子
我认为这是一个很常规的做法，关键在于每个维度的权重如何确定。这需要长期的实验摸索。并且不能仅局限于缺陷本身的属性来制定评价维度，还要考虑到时间成本，商业先机等众多方面。而且要达到如此精密的评价体系要求，也需要有稳定的技术团队，成熟的度量体系等。这次没占到好楼层，
下次一定占个好楼层。关于遗留的缺陷
1、测试不可能找出所有的缺陷
2、不可能在有限的时间里修正所有缺陷
3、做好遗漏缺陷产品发布后管理 原帖由 tails82 于 2009-6-5 21:48 发表 http://bbs.51testing.com/images/common/back.gif
我认为这是一个很常规的做法，关键在于每个维度的权重如何确定。这需要长期的实验摸索。并且不能仅局限于缺陷本身的属性来制定评价维度，还要考虑到时间成本，商业先机等众多方面。而且要达到如此精密的评价体系要求 ...
是的，所以说我们目前还在摸索中，如果有好的建议不妨说来听听 个人见解
产品发布后 安排项目中专人跟踪 期间可以自行测试（如发现缺陷 也要向客户说明） 我认为产品发布后，遗留缺陷在风险上应属于可控的。
可以按风险处理机置来处理。
适当的告知客户，并提供处理方法。
与客户协商解决的方法和解决的时间。 项目进行到后期，项目经理和开发、测试组长针对已发现版本存在的缺陷经过综合评估风险可控度与项目紧急程度，而最终确定部分风险可控（对用户影响小、出现几率很低且出现后易恢复）的问题做遗留处理，该类问题一般通过发布补丁或在后续版本中解决，版本发布后要有专人负责跟踪了解遗留问题对用户的实际影响，确认与所做风险评估是否存在偏差，以决定是否有必要发布缺陷补丁或后续版本，当然根据实际情况也要尊重到用户意见。所谓版本发布时未发现问题应不属于版本遗留缺陷，而属于遗漏缺陷，至于遗漏问题应视缺陷严重性、对用户影响程度以及出现频率确定是否立即采取相应补救措施。 根据缺陷严重性，选择是否继续修改，跟踪关闭。剩余缺陷分为两类
1 对程序运行留有隐患或阻碍使用，这部分一定要跟踪关闭，并尽快给客户更新。
2不影响使用，建议改善。这部分建议暂缓修改，如果有下一版本的开发，需求讨论时提出，得到用户确认后再修改。没有确认的全部放过，不做修改 这要综合各方面考虑决定啊，问题的严重性，客户的认可度，修改成本以及时间成本。
回复 9# 的帖子
:hug: 维度的东西看着好像很复杂呢！ 软件发布后可能会产生的bug有两种情况1.客户发现 :在使用过程中,经由售后人员接受客户反馈后得到或者软件中提供报错日志得到.
2.内部发现:公司内部同事发现,包括公司内任何使用过该软件的成员
那么我们应该分别对这两种情况进行处理
1.客户发现的bug:能让客户投诉上门的bug一般是很严重的,毫无疑问需要马上修改.售后或支持人员将bug通过缺陷管理工具进行提交,项目质量工程师将定义bug修改时间和修改方案,通过升级包给客户升级.
2.内部人员发现的bug:也统一提交到缺陷管理系统上,项目质量工程师和项目经理共同决定bug的等级缺陷.若bug比较严重,会存在影响客户使用的隐患,需及时将bug进行修复,若bug等级评定为低,则项目测试经理,项目经理和质量经理统计bug并,商议修改方案及时间,使用升级包升级,若人手足够,可采用定期升级策略.
缺陷管理工具上应该专门开辟项目发布后的bug提交的专栏(不与发布前的bug混淆).项目质量工程师和项目经理每天跟踪
这个过程牵扯到项目的管理策略和对项目主要参与者对项目的关注程度.如果哪个环节出现迟滞,有些bug可能永远都得不到修复
需要全员参与那!!!!:handshake
[ 本帖最后由 yhfeifei 于 2009-6-11 12:09 编辑 ] 看缺陷的优先级，会不会影响用户使用。处理的时候最好做好跟踪记录。
页:
[1]
2
