项目中，测试最开始一段时间，
Bug
总是不断的蹦出来，
Bug
指缺陷或故障，区别在于项目发布之前发现的叫缺陷，项目发布之后发现的叫故障，通常故障会对用户造成伤害，团队里也制订了相应的惩罚机制。这次不妨从
Bug
的角度来说说项目，下图是我们使用过的一份
Bug
级别定义，一般来说对一个
Bug
的描述有以下几个关键点。
缺陷级别（Severity
）
：即上图中的5
级别定义，一般大于等于III
级的Bug
被认为是严重的问题。
所属产品、项目
：有的人需要同时处理很多产品、项目，这个属性可以用来筛选。
Bug
名称
：一个短句，此Bug
的简单说明。
Bug
描述
：写成如下形式，“执行某操作，期望出现什么情况，实际出现什么情况”，还可以添加截图、文档等附件。
其实其他属性还有很多，不过我觉得非必须，经常不填，也就不说了。
我们的测试过程使用了Mercury Interactive
公司的Quality Center
来管理，它是一个基于 Web
且支持测试管理的所有必要方面的应用程序，更小的团队，用Excel
来管理Bug
也未尝不可。作为PD
，也是会经常提Bug
的，PD
做测试的时候主要是模拟用户的身份使用产品，而测试人员会更多的按照TC
执行。当发现一个Bug
以后，我们会提交给相应的开发工程师，如果认为是需求问题也会提交给对应的PD
，这时候Bug
的状态为Open
，之后的状态改变，可以用下图表示。
Bug状态流转图（图中defer拼错了）
收到Open
的Bug
，确认并修复，状态变为Fixed
；否认，也许提出者理解错了，也许不打算修改，状态改为Rejected
；或者认为不是自己的问题，可以把Bug
转交（Assign to
）给别人。
测试验证状态为Fixed
的Bug
，没问题了就Closed
，否则可以Reopened
。看到Rejected
的Bug
，发现是自己理解错了，就可以Closed
，仍然认为是Bug
的可以Reopened
。对于Deferred
的Bug
，意味着本项目中暂不修正，可能是因为技术做不到，时间不允许，性价比太低等，必须慎之又慎，通常由能负责的人，比如是测试经理、项目经理最终同意才Deferred
。
整个过程中，Bug
的每次状态改变都可以添加注释说明，我们更鼓励有争议叫上当事人面对面的交流，而不是在系统里不停的纠缠。
到了项目发布之时，我们要求所有Bug
的状态必须是Closed
或者Deferred
，当然对I
、II
级的Bug
，有时候并没有这么严格。
使用Quality Center
比Excel
的好处，在于每个Bug
重要的状态转换点，系统都会有邮件通知到相关人员，防止遗漏；项目中每个人在系统里的角色不同，权限不同，防止误操作，甚至一些恶意行为，比如开发人员就不能把Bug
状态改为Closed
；所有操作都有记录，谁在何时做了什么，便于追溯。这些都有效的防止了人为因素导致的问题。
PS：很久都不发带图片的文章，是因为picasa，我终于打算放弃，转投flickr了。。。