项目中Bug的一些事

  项目中，测试最开始一段时间，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，之后的状态改变，可以用下图表示。

收到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；所有操作都有记录，谁在何时做了什么，便于追溯。这些都有效的防止了人为因素导致的问题。