【分享】BUG从诞生到灭亡——处理BUG的流程

1、什么是bug
软件的BUG，一般是指软件程序的漏洞或缺陷，广义还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差别的功能实现等。

2、bug的生命周期
生命周期中的缺陷状态：新建-->指派-->已解决-->待验-->关闭
发现BUG -> 提交BUG -> 指派BUG -> 研发确认BUG -> 研发去修复BUG -> 回归验测试BUG -> 是否经过测试 -> 关闭BUG

一、发现bug
1）按照测试用例进行操做，发现和测试用例的预期结果不一致的能够称为bug。
2）成本问题，没有充足的时间编写测试用例，致使出现的bug。
3）测试用例是没法穷尽的，或者误操做出现的bug。

二、提交bug
在提交一个缺陷的缺陷，首先尽可能描述这个缺陷的属性。Bug重现环境，bug类型，bug等级，bug的优先级以及详细的重现步骤，结果与指望等。
固然，咱们在提交一个问题以前首先应该保证，这个缺陷是没有被提过的，以避免形成重复缺陷单。

三、指派bug
这一步不是必须的，跟项目模式有关，有些公司测试部门与开发部门独立，那么测试人员就不肯定本身测试的模块是由哪位开发人员负责的，在这种状况下，测试人员统一把问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员。
有些测试人员是穿插到不一样研发团队中的，因此对不一样的开人发员负责的开发模块很是清楚，这个时候就能够将问题直接指派给相应的开发人员。
也有一种状况，原本此问题应该由A开发人员负责，但因为A开发人员的调离或辞职，些问题为转交给其它人员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。

四、确认缺陷
当开发人员接到一个缺陷时，首先是对其进行分析与重现，若是对其进行分析发现不是缺陷（可能因为测试人员不了解需求）或没法对此问题进行重现，那么就须要将此问题反回给测试人员，并注明缘由。若是确认为缺陷则须要对其进行处理。
五、修复BUG
推迟处理
在处理问题以后，还须要进行一次判断，是否须要推迟处理，有些需求已经确认了是问题，因为其可能在极端状况下才会出现，或须要对系统架构进行改动，或其优先级很是低，因此暂时不须要对此问题进行处理（或到下个版本进再进行修复）。
固定
对于推迟处理的问题能够暂时进行固定（“固定”为QC中的叫法。）通常固定的问题须要通过项目经理与测试经理协商后才能固定。
处理缺陷
开发人员在确认完一个问题须要处理时，那么就对其进行处理工做。（例如，redmine 是支持处理人时时更新问题处理进度的，如 已处理30% ，已处理80% 等，固然，对于短期内能够修复的问题就不必时时的去更新处理进度。）

六、回归验证BUG
回归缺陷对于测试人员来讲是很是重要的工做，其有三个入口两个出口。
确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或没法重现，而后直接转交给测试人员回归。测试人员再次确认，若是真如开发人员所说，则将问题关闭。若是非开发人员所说，是因为问题描述模糊或其它缘由喂重现问题，则再次注明缘由转给开发人员。
确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不经过，将问题再次打开并转给开发人员。
确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。

七、关闭缺陷
对于已经修复的缺陷进行关闭，这也是一个缺陷的最后一个状态。

3、使用工具
合适的工具能够有效缩短BUG处理流程，提升工做效率。我使用的是Eolinker接口管理系统，是个国产Saas工具，测试功能和权限管理分配功能都比较完善，对咱们开发团队帮助也挺大的。
使用地址：www.eolinker.com