平时的积累，有来自论坛的，有来自书本的，也有自己胡诌的：）
1. 2004-2-20 BUG的定义
Bug不仅仅是代码级别的错误，而且可以是在设计和测试阶段发现的缺陷。无论什么时候，任何有助于改善产品质量的提议、任何需要引起注意、值得跟踪的问题、任何可能潜在的错误，都可以而且应该作为一个Bug。
所以说，在软件开发流程中，对Bug的管理是至关重要的。科学的做法是由工具来记录、跟踪、管理Bug的后继变化和处理方案。
1) 及时的分派和修复bug
仅有bug的录入是不够的，pm或dev lead应*及时*根据bug的description和stack trace，把bug分派给corresponding developer去fix，同时规定一个fix by when的期限。
2) 详细的bug description
在这一点上，也对tester们提出了一定的要求。在测试过程中，光发现软件本身的问题还不够，当错误（有时可能是memory crash, a/v, assert,等），应把call stack也记录下来并写入“bug跟踪系统”。有些bug很难repro，但一个详细的bug description可为bug的fix带来帮助。
2. 2004-2-20 BUG的处理
从管理这个层次上讲，一旦BUG被发现后，最困难的并不是如何去记录，分派人员去解决，并予以追踪。最困难的是决定对某些BUG推迟解决，甚至不予解决。这样的BUG往往是在产品开发的中后期发现的，而且是由于最初架构设计的缺陷所造成的，解决这样的BUG需要大量的人力和时间，影响面大，可能会引入新的BUG。对于这样的BUG，PM要与客户端的其他部门和人员联系，比如市场部门，技术支持部门，甚至于早期介入的客户。如果从他们的反馈中，确认这种BUG对决大多数客户和决大多数的使用(scenarios)没有影响，就要果断决定推迟，或不予解决。
对于这些已决定推迟，或不予解决的BUG，还有一些后续工作非常重要。首先要祥细的记录，以便在下一个版本中解决；其次要让有关技术支持人员深刻理解，准备应对方案。
3. 2004-2-20 微软的经验
在微软，当编码人员在实现某个功能遇到困难的时候，一般地说会经历以下的程序：
（1）编码人员自己想方设法去解决，包括向有关同事咨询。
（2）编码人员向本部门的技术带头人请教。
（3）编码人员在项目的例会上提出讨论。
（4）由项目经理组织专家及相关其他部门人员汇诊。
（5）由项目经理听取市场部门和顾客的意见。
一般地说经过（4）和（5）了以后，问题就比较复杂了，不是简单的措施能解决得了。这时有两种可能，一是要实现的功能对顾客影响不大，在这种情况下多半会取消这个功能（应该说把它留给下一个版本）。这样决定的目的是为了让项目按计划进行，让产品尽快投放市场。市场如战场，尽快的占领并获得应有的利润比技术完美更重要。另一个可能是要实现的功能对顾客影响很大，没有这个功能产品将失去很大的市场。在这种情况下多半会调整项目计划，集中人力物力攻克这个难关，在问题没解决的情况下项目的其他部分可能暂缓进行。这样决定的目的是确保不会生产出一个没有市场竞争力的产品。
这两种决定的准确性都是建立在对市场的充分把握和对顾客的充分认识的基础上的。这是中国的软件企业的又一弱点。在中国有多少软件企业像重视项目开发一样重视市场和销售，像重视技一样重视顾客，售后服务和技术支持？
4. 2004-2-20 BUG关联
微创的BMS系统定义了bug之间的关联，有5种：
依赖关联、重复关联、相关关联、文件关联、附件
依赖关联：一个Bug的解决依赖于其他的Bug，例如，程序员B的Bug只有等到程序员A的Bug解决后才能解决，一个版本中的某个Bug依赖前一个版本中的Bug，甚至一个产品的Bug依赖于其他产品的Bug。依赖关联的处理确实比较复杂，不过就我个人经验而言一般使用的比例比较小。如果Bug间存在依赖关系，那么处于被依赖（或者父依赖）的Bug应尽快加以解决。
重复关联：如果其中一个缺陷实际上是另一个缺陷的重复缺陷，就需要在这两个缺陷间建立起重复关联。我们要求测试人员尽量不要File重复的Bug，如果一旦File了重复的Bug，则在这组重复的Bug间建立“重复关联”，一旦主缺陷解决了，所有的其它重复缺陷（从缺陷）也就都得到了真正的解决。
相关关联：相对于依赖关联和重复关联，相关关联的概念要简单很多。同一个数据库中，当一个缺陷与其它缺陷存在一定的关系，但却并非依赖关系或重复关系时，就可以为它们建立相关关联。相关关联着的各个缺陷之间，不存在任何的依赖关系，这意味着可以独立地处理各个缺陷。
重复关联和附件：前者是因为各个test很有可能会登记了重复的bug，后者是因为有时候文字描写不清楚，直接上传一张图片效果可以好很多。当然了，给个文件的链接也是好的。
有些功能更加强大的Bug管理工具甚至将Bug和相应的Test Case关联起来，将Bug与源代码管理中的Change Number (或者文件号)关联起来。当然，一个Bug管理工具最基本的操作就是New, Resolve, Close, Assign以及Query查询。能把这些最基本的操作做好，软件产品的质量已经会有很大的提升了。
5. 2004-2-20 BUG管理工具
Rational ClearQuest不错，流程、操作、Bug信息等等都可以自定义，可以制定不同的查询、图表等，且可以根据预先定义的E-mail Rules 自动发出E-mail。最好的就是她自己带有一个教程（英文版的，但极容易理解）
