bug生命周期(bug单包括的内容)

大家好，我是讯享网，很高兴认识大家。

生命周期中的缺陷状态:新–>:分配–>已解决–>待测试–>:关闭

发现Bug –>:提交BUG –>分配BUG –>:R&D BUG确认–>:R&D修复BUG –>:回归BUG –>:已验证–>关闭BUG

1.查找bug

1)如果按照测试用例操作，发现与测试用例的预期结果不一致，可以称之为Bug。

2)测试用例无法穷尽。总有出乎你意料的因素，或者是上帝操作造成的bug。

3)成本问题，编写测试用例的时间不足，发现的bug

2.提交一个错误

提交缺陷时，首先尝试描述缺陷的属性。Bug重现环境、bug类型、bug级别、bug优先级、详细重现步骤、结果和期望等。

当然，在提交问题之前，首先要确定这个缺陷没有被提及，以免重复缺陷。

3.分配bug

这一步不是必需的。与项目模式有关。在一些公司，测试部门是独立于开发部门的，所以测试人员不确定哪个开发人员对他们测试的模块负责。在这种情况下，测试人员统一将问题分配给项目负责人或经理，项目负责人(或经理)确认问题后再分配给相应的开发人员。

一些测试人员穿插在不同的R&D团队中，所以负责不同开发人员的开发模块非常清晰。这时候问题可以直接分配给相应的开发人员。

还有一种情况是开发商A应该对这个问题负责，但是由于开发商A的调动或者辞职，把一些问题转移给了其他人。“分配”强调上级对下级；“转移”强调的是同伴之间。

4.确认缺陷

当一个开发人员收到一个缺陷时，第一件事就是分析并重现它。如果发现不是缺陷(很可能是因为测试人员没有理解需求)或者问题无法重现，那么就需要将问题返回给测试人员并注明原因。如果确认是缺陷，就需要治疗。

5.修复bug

推迟处理

在处理完问题后，需要对是否需要延迟治疗做出判断。一些需求已经被确认为问题。因为它们可能只在极端情况下出现，或者需要改变系统架构，或者优先级很低，所以暂时不需要处理这个问题(或者在下一个版本中修复)。

固定的；不变的

延期的问题可以暂时修复(“修复”是QC中的叫法。)一般来说，修复的问题只有在项目经理和测试经理协商后才能修复。

处理缺陷

当开发人员确认某个问题需要处理时，他就会去处理。(比如redmine支持处理人员不定时更新问题的处理进度，比如30%处理，80%处理。当然不需要更新短时间内可以修复的问题的处理进度。)

6.回归验证错误

回归缺陷是测试人员非常重要的工作，有三个入口和两个出口。

确认无缺陷问题:对于提交的缺陷，测试人员会将其视为无缺陷或无法重现，然后直接转给测试人员进行退货。测试人员再次确认，如果如开发者所说属实，问题将被关闭。如果非开发人员表示，由于问题描述模糊或其他原因，问题没有重现，应再次说明原因，并转给开发人员。

确认问题:再次确认开发者修复的问题。如果确认可以通过，关闭问题。如果没通过，再把问题打开，转给开发商。

确认已修复的问题:有计划地确认已修复的问题。一些固定的问题可能会随着时间的推移而更新或者不复存在，这类问题要及时关闭。一些固定的问题依然存在，变得迫切，这些问题要及时开放给开发者。

7.关闭缺陷。

关闭已修复的缺陷，这也是一个缺陷的最后状态。