软件测试是如何跟进和管理bug？

　　问题：一个软件每个版本存在的bug或多或少数百个。有的重复出现，有的新发现，有的一直没修复。真不知道测试部门是如何去管理和跟进这些bug...

　　精彩回答：

S e_%[/Ww0　　吕书茹：

　　理论上：

3xy{;o&M)C\O0　 　所提的BUG有版本号；稳定复现的BUG，下一个版本的时候回归已确认修复则可以关闭；不是稳定复现的问题需要观察连续3个版本未复现的可以关闭；偶然 性的问题可以置成观察状态，持续观察。由于种种原因未能解决的问题，定期讨论做处理（修改或者pending）。复现的BUG只能reopen了

　　实际上：51Testing软件测试网7t WT@+K.@

BlYG:g6b~%L l0　　BUG管理应该一直是QA很头疼的问题，不同的管理人员有不同的解决策略吧。很难做到尽善尽美吧。51Testing软件测试网1}Z]pp n

(mMb[+w3y G0　　抽屉（chouti）：51Testing软件测试网bw
[4GY~:p0B"@

uT"R]{/j0　　对于Bug的跟踪，一般来讲会采用 Bug tracking system 比如 Bugzilla， Bug free， 或者其他的任务管理系统中集成的相关模块。

0\qW4Kf0　　当然，我也见过一些公司采用 Excel 甚至是邮件来管理、跟踪 Bug 的状态。51Testing软件测试网j3^!NCrB

yQ)L6N~K?0　　一般来讲，一个 Bug 的生命周期经历了新建 - 被指派（修复/Backlog）/不修复/判断为非Bug - 已修复（待测试确认）- 确认修复/确认未修复 这样的一些阶段。

　　缺陷跟踪软件一般会在缺陷的状态产生变化（或者有人添加了评论，虽然没有变更状态）时发送邮件告知相关各方（包括测试人员）。测试人员对这些变化做出相关的反应。51Testing软件测试网Bb~#S"RN

　　在缺陷得到修复之后，测试人员负责对新版本进行确认，如果确认修复了，则关闭缺陷，如果证实没有修复，则重新打开Bug，配合开发人员继续调查原因。51Testing软件测试网z]y-~n,m[Ie

　 　这里，对缺陷的管理有一个难点，既当系统内积累了相当数量的缺陷报告之后，新发现一个问题后，如果去系统内检索是否这是一个已知的问题（包括过去出现 过，但是已经修复了的问题）的过程会耗费测试人员很大的精力，这一步最好需要做，在时间紧迫的情况下，我认为以报告缺陷为高优先级，即新建一个缺陷报告， 而不是一味地去检索原先的那个。