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

　　精彩回答：

　　吕书茹：

　　理论上：

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

　　实际上：

　　BUG管理应该一直是QA很头疼的问题，不同的管理人员有不同的解决策略吧。很难做到尽善尽美吧。

　　抽屉（chouti）：

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

　　当然，我也见过一些公司采用 Excel 甚至是邮件来管理、跟踪 Bug 的状态。

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

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

　　在缺陷得到修复之后，测试人员负责对新版本进行确认，如果确认修复了，则关闭缺陷，如果证实没有修复，则重新打开Bug，配合开发人员继续调查原因。

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