软件测试的重要环节—Bug管理流程
2004-03-07

软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。

错误跟踪管理系统

为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录输入制定的错误跟踪管理系统。

目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软件）、Mozilla公司的Buzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能上各有特点，可以根据实际情况选用。当然，也可以自己开发缺陷跟踪软件，例如基于Notes或是ClearQuese开发缺陷跟踪管理软件。

作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，错误记录的当前状态。

正确的数据库权限管理是错误跟踪管理系统的重要考虑要素，一般要保证对于添加的错误不能从数据库中删除。

软件错误的状态

新信息(New)：测试中新报告的软件缺陷；
打开 (Open)：被确认并分配给相关开发人员处理；
修正(Fixed)：开发人员已完成修正，等待测试人员验证；
拒绝(Declined):拒绝修改缺陷；
延期(Deferred): 不在当前版本修复的错误，下一版修复
关闭(Closed)：错误已被修复；
Bug管理的一般流程


　　测试人员提交新的Bug入库，错误状态为New。

　　高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。

开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。

对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。

测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。

软件错误流程管理要点

为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。
每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug状态。
拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。
错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误
加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。

微软专家蔡培谈BUG管理
51CMM.COM原创:马映冰

狭义地讲，BUG是写程序过程中造成的错误，广义地讲，BUG是影响客户正常使用的任何问题，就是说，BUG不仅仅是编程中出现的问题，还包括了客户功能规范等方面的问题。
　　BUG在我们的工作中具有五大危害：降低产品质量；无法预计和控制产品发布日期；损害团队的积极性；损害未来的产品版本;降低工作效率。
　　BUG的来源是多方面的，主要来自于：项目期限的压力；产品的复杂度；沟通不良；开发人员的疲劳、压力和受到干扰；缺乏足够的知识、技能和经验；不了解客户的需求；缺乏动力。
　　怎样减少BUG？开发中要为质量工作留足时间；程序越简单越好；改善团队内部、团队和客户的沟通；重视和避免开发人员的疲劳、压力和受到干扰；增加知识、技能和经验；对客户深入了解；把项目质量和个人利益挂钩，任务的目标包括完成任务的期限和保证的BUG下限；树立正确的BUG观。在微软,开发与测试平行进行,开发人员不完全依赖测试人员，单元测试(Unit Test)要程序员自己做,程序员一定要保证程序的所有路径自己都走一遍。程序设计要遵循一定的规范和原则，如函数和变量的命名规则，函数和算法追求简单，不为一点点效率的提高而牺牲程序的易读性。为程序员提供一个安静的开发环境，不把程序员推到客户面前，避免受到外界干扰，与客户的交流和沟通由专门的程序经理（Program Manager）来完成。
　　开发过程中使用一套BUG管理软件也非常必要，目前微软还没有向市场提供这样的软件，但可以找到第三方的产品，软件公司也可以自己开发一套简单的系统供自己使用，微软也是这样做的。这个软件其实很简单。测试人员或者开发人员发现一个BUG，就向系统登记，记录使用的测试试例，发现的问题，能解决这个问题的开发者等等，这个开发者就会收到一个邮件，通知他这些信息，如果的确属于他的问题，那么他答应解决，解决后再测试，再把处理结果和原因登录到系统中，如果不是他的问题，那就要把他认为能解决问题的人再填上去，如果解决不了就要把球传给程序经理或者项目经理，任何时候，每个人都可以看到自己必须要解决的BUG，程序经理和项目经理都可以看到自己团队里存在的BUG和解决情况，整个开发过程就是BUG数从少到多，再到少的过程，从BUG数量的变化，也可以推断软件产品的成熟性，推断产品的发布期。


蔡培小传：
　　在微软总部工作6年，先在OFFICE团队参加EXCEL97的开发，后来进入MSN负责社区项目，负责中间层到数据库的设计，2001年8月回国在微软中国工作。