3、Reproduce Environment Confirmed，Bug的重现环境被确定，通常由开发人员提交。在这个阶段，在正常的重现步骤之外，开发人员已经可以提供一个最简的环境来复现问题，可能是一段非常精简的代码，也可能是一个很简单的步骤，其特点是这个重现的环境远比QA的按步操作来得简单，甚至可能得以自动化的重现。如果问题可以自动化重现和确定，则可以考虑将自动化脚本作为单元测试保存。

　　4、Reason Found，问题的根本原因被确定，通常由开发人员提交。在这个阶段，开发人员需要描述问题产生的原因，可能是某个业务逻辑的理解有分歧、或者某个第三方产品确实存在Bug、或者某段代码存在着函数使用的错误等。

　　5、Resolution Submitted，解决方案已提交，通常由开发人员进行。在这个阶段，开发人员提交一个完整的解决方案，根据开发人员的思路，这个解决方案确实得以修复该问题。随后同项目级的人员、QA可以对该解决方案进行评估，确定对其他模块不会有影响等。

　　6、Resolution Applied，已经应用了解决方案，通常由开发人员提交。此时开发人员指定一个新的源码版本号，该版本号中的相应代码段应用了第5步中提交的解决方案，问题应当已经修复。

　　7、Resolution Confirmed，问题已经确定修复，由QA人员提交。此阶段QA确定问题已经被修复，并且经过了一定范围的回归测试，确保问题不会对其他模块产生严重影响。在这个阶段，Bug依旧是开放状态，各成员可以对Bug进行参与，作一些总结性的讨论。

　　8、Close，Bug关闭，此时Bug已经锁定，可以作为一个固定的知识项来查看，但不再有修改和讨论的可能性。

　　以上为一个非常周全的Bug生命周期管理，但确实不需要对其进行一个强制的要求。一个Bug平台可以提供这些生命周期，也许只是简单地在“Bug状态”中添加相应的项，而进一步如何引导用户对这些环节进行充分的利用，则可以通过团队的规章、Bug平台本身的界面等方面来进行，强硬地规定只会让Bug追踪过程事倍功半。

　　其他方面的增强

　　上文提的是个人认为Bug平台向知识库整合过程中最重要的一环，即通用型Bug的分类、分享、订阅工作，以此为其他来散布众多点状知识，以期通过所有人员共同参与交流、沟通，再将点状的知识整合成线状甚至是面状的知识体系，补充团队的经验和能力。

　　但是在此之外，其实Bug平台还可以做很多事情，来提高这个“伪知识平台”的使用体验，证知识更加有条理、有结构：

　　● 与源码平台关联

　　一个Bug平台应该与源码平台有着非常紧密的关系，包括一个Bug在哪个版本（A）发现，在哪个版本（B）修复，并可以通过平台找到源码平台中两个版本的diff，比如scm.xxx.com/diff？file=abc&rev=A：B。这要求Bug平台与源码平台都提供相应的接口，可以在两个第三方系统间进行交互合作，现时也要求Bug平台有一个严格的规范，在Bug的open和close操作中提供相关的版本号。

　　● 与知识平台关联

　　Bug是知识的来源，那么Bug提供的知识自然要进入到知识管理平台。这一点需要系统的智能化识别，当一个Bug其信息足够完善，包括了前面提到的Bug生命周期的各个环节应有的信息的时候，Bug平台应该主动与知识平台连接，将这个Bug整理成一份真正的知识文档进入到知识管理平台。

　　我很喜欢看各个产品的Bug追踪系统，比如jQuery的Bug Tracker，因为在Bug系统中总能发现一些非常细节的问题，补充自己的知识，慢慢地自己的代码的兼容性会有很大的提高。

　　但是，在各个Bug系统之中，包括现在公司使用的Trace系统，无一例外地存在一些让我不满意之处，其中最大的原因就是很多Bug系统仅仅是作为Bug的记录系统存在，而没有试图去让一个Bug成为一个知识的积累，让整个Bug系统变成一个丰富充实的知识库。这样的Bug系统，永远都只是提供一个简单的业务流程，不会变成干完人员、产品、甚至是整个团队的进步的天梯。

　　在我看来，一个Bug系统应该更加全面，管理Bug的生命周期的同时，也用于管理一个产品、团队的知识，更可以与周边系统合作，形成一个真正的集成式管理平台。