bug单的生命周期

测试工程师发现了软件的缺陷(bug)，那修复bug的整个流程是怎么样的呢？

1、发现bug

2、和开发确认是否是bug

3、如果是bug则提bug单到测试经理，如果不是则放过

4、测试经理把bug单走到开发经理

5、开发经理分问题单到开发工程师手中定位

6、测试工程师定位完成后，把定位结论写到bug单中，然后走到开发经理处，让其审核定位

7、开发经理审核完成后把bug单走到开发工程师手中

8、开发工程师进行修改后，走到其他开发工程师中进行审核修改

9、审核完成后，走到开发经理处

10、转测试版本后，开发经理把修改的bug单走到测试经理处

11、测试经理把问题单分派到测试工程师手中，进行回归测试

12、回归bug单的过程中，有可能出现bug单回归不通过的情况，这个时候需要把bug走回到开发手中，回归通过关闭bug单

通过上面的12步骤，发现修复一个bug单的流程貌似很复杂，这个是一个标准的流程，很多小公司或者小团队，他们的bug单流程没有这么复杂，可能测试人员直接把bug单走到对应的开发工程师手中，开发修改完成转测试版本后，直接走回给测试工程师进行回归测试，这样步骤就减少了很多。

上面的流程都是理想状态，但是还有很多其他异常的情况,如下面所列举的：

1、bug单是偶现的，开发工程师和测试工程师都不能够复现，这种问题应该怎么样进行处理呢？公司中一般是这样处理的，连续三个版本不复现，bug单降级处理，如果是提示级别，连续三个版本不复现，这直接关闭。

2、开发工程师由于在确认bug单的时候不清楚需求，确认是问题，但是后面定位过程中发现不是问题，这种问题单怎么处理呢？这种比较特殊各个公司处理可能都不相同， 一般建议按问题解决处理，而不是非问题打回，因为在确认的时候是问题，这种问题不应该是测试承担。

3、bug单在回归测试发现修改不彻底或者修改老问题引入了新问题，这种都是bug单修改不通过。

4、在由于大多数情况下，开发对自己模块的bug都比较抵触，确认bug单