我认为从软件发布后,会存在发布前和发布后出现的遗留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,完成后统一处理
遗留的也要处理，必须的
要回答这个问题，需要弄明白几个要点：1、什么是遗留缺陷？
这有两个关键词：遗留、缺陷。首先，它是缺陷，即表明产品还存在不足、不完善、需要改进的地方；其次，它是遗留的，即表明这些缺陷不影响产品的正常使用或者尚未被发现。由此我们把遗留缺陷分为两大类，一类是已知的，不影响产品的正常使用，这些缺陷是轻微的或者是产品的边缘功能，因此才可能在存在缺陷的情况下发布产品；另一类是未知的，产品交付时未发现的缺陷，可能会被用户发现或者产品团队的后续测试中发现，这些缺陷有可能是严重的，甚至致命的。
已知的遗留缺陷可以尽量避免，但是未知的遗留缺陷是避免不了的。
2、遗留缺陷的处理方式？
因为两类遗留缺陷的差别很大，我们不能一概而论采用统一的处理方式，建议分类处理。
对于已知类的遗留缺陷，首先是它们必须被记录下来，可以作为后续研发周期的参考，也可以是产品支持的问题库；其次，在考虑成本、研发周期的情况下，可以进行部分缺陷的修复，并作为补丁发布；第三，如果后续研发使用了不同的技术和业务模式，某些缺陷不再是新产品中的缺陷了，它们将停留在以前的研发版本中（仍然被记录着）；第四，这些缺陷可能永远不会被修复，就让它们呆在那里好了，我们仍然可以在缺陷库中查询到它们。
对于未知类的遗留缺陷，首先是当发现它们时，记录下来，根据严重程度、优先级进行分类；其次，根据优先级和严重程度的高低进行处理，低优先级轻微的缺陷可以转为已知的遗留缺陷；第三，暂时处理不了的重要缺陷记录下来，并告知相关客户原因和临时处置办法（比如临时屏蔽或者手动维护），这些缺陷将在后续研发周期优先考虑；第四，已处理的缺陷作为补丁发布；第五，测试人员和开发人员审视这些缺陷，找出它们被遗漏的原因，以便在今后的工作中尽早发现和解决这些类的缺陷。
3、修复后如何发布？
缺陷修复后一定是通过补丁包发布，但不同客户的情况不同，发布方式也需要仔细考虑。
第一，对于公共的常见缺陷，可以通过主动发送或者网站下载的方式升级；
第二，对于公共的不常见缺陷（同一功能，不同客户使用的程度不同，因此某些缺陷对于一些客户是未发现的），通过定向发送来升级，不建议统一升级的主要理由是升级也有成本，无论是客户还是我们自己；
第三，对于特定功能的缺陷，因为这些功能只有部分客户使用，通过定向发送来升级； 产品发布之后，对遗留缺陷首先要和客户说明，最好给出处理bug 的进度，这中间需要关注的是版本管理 对遗留问题详细说明遗留原因，需要再下一版本修改的，需要在下一版本进行验证。 原帖由 jiangxk 于 2009-6-11 15:10 发表 http://bbs.51testing.com/images/common/back.gif
要回答这个问题，需要弄明白几个要点：
1、什么是遗留缺陷？
这有两个关键词：遗留、缺陷。首先，它是缺陷，即表明产品还存在不足、不完善、需要改进的地方；其次，它是遗留的，即表明这些缺陷不影响产品的正 ...
请问定向发送是什么意思？？？没看明白～
对于没有使用而无发现BUG的，暂不用升级，我个人有点疑问，如果后期用户发现了BUG，而且造成更大损失的话怎么办，应该说是严重BUG要立即升级，微小的BUG可暂缓～
[ 本帖最后由 zllzh 于 2009-11-17 16:34 编辑 ] 学习了，遗留问题需要经过讨论，分类处理 不错，有些处理方法值得学习！
宝贵经验。
宝贵经验。宝贵经验。 值得借鉴....上线后发现的重大遗留问题后果应该由who来承担呢？
页:
1
[2]
