开发与测试的争执---bug的级别以及bug要不要修改

是不是bug ,bug的级别是不是有点高，这真是开发与测试永恒的话题。

如何定义bug 的级别：

bug的定义每个公司都不一样，在定义级别之前需要查看公司规范。

研发拒绝修改bug时我们的做法：

研发拒绝修改bug时，测试和研发是极有可能发生争执的，但我们应该明确的是能让开发人员解决最多bug 的人员是最优秀的测试人员，在产生争执的情况下我们的正确做法是

 

应该明确的是对于拒绝修改和延迟修改的bug ,需要经过包含测试人员代表和开发人员代表，用户方面的代表（带表用户角度的人）的评审,有时也叫三方评审。

其次，我们对bug的生命周期要有一个了解，因为测试人员应该跟踪一个bug 的整个生命周期，从open到close状态。

下面是一个bug 的生命周期图。

New；发现的新bug，未经评审决定是否指派给开发人员进行修改。(测试进行)

Open；确认是bug,并认为需要进行修改，指派给相应的开发人员。(测试组长，研发经理，测试)

Fixed：开发人员尽行修改后标识成修改状态，有待测试人员的回归测试。（研发）

Rejected：如果认为不是bug,则拒绝修改。（研发）

Delay：如果认为暂时不需要修改或暂时不能修改，则进行延期修改。（研发）

Closed；修改状态的bug 竟过测试人员回归验证通过，则关闭bug.（测试）

Reopen；如果验证bug仍然存在，则需要重新打开bug，开发人员重新修改。（测试）

无效bug ;open->closed   open->rejected->closed

测试人员发现新bug，必须由测试组长评审后才决定是否Open并分派给开发人员，测试人员Open的bug可以直接分派给bug所在模块所对应的负责人，也可以统一提交给开发主管，有开发主管审核后再决定是否分配给开发人员进行修改。

测试人员对每一个缺陷的修改必须重新的取一个包含更改后的代码新版本进行回归测试，确保相同的问题不在出现，才关闭缺陷。