从事IT行业工作也有两年多了,其中一年是大四实习,也接触了正规的项目,和测试人员打过交道,提BUG,改BUG,对BUG的生命周期也算比较熟悉了。最近参与一个重大项目,天天开会评审缺陷,我们现在共有3万多个测试用例,每天能够执行6-700个。所以作为开发人员对缺陷深恶痛绝,现在我就来介绍一下BUG的生命周期,IT从业者估计都比较熟悉,所以本文适合在读大学生,可以了解一下,说不定在以后面试的时候能用到。

BUG的生命周期

缺陷是指测试人员在执行测试用例的时候,发现得到的结果与预期结果不同,与预期结果不同的原因有很多种,测试人员就可以发起流程来处理这个问题。

打开:发现缺陷后发起流程,先由测试人员初步定位错误原因,并指定处理人,一般为该功能对应的开发人员,如果不知道具体的开发人员,可以把处理人指定为测试负责人,项目经理等。并详细描述重现缺陷的步骤,截图等。选择好缺陷的优先级,重要性并提交。

已修复:开发人员接到缺陷任务后,就要对缺陷进行定位分析,找到程序的Bug,如果能够成功找到,并把Bug修复了,那么就可以把缺陷状态更新到已修复,同时要更新缺陷的错误定位,因为测试人员初步定位不一定准确,经过开发人员定位分析修改后,就能明确错误原因了,比如环境问题,程序Bug,等等。

已否决:开发人员接到缺陷任务后,认为该错误是由测试人员操作不当,或者实际结果符合需求,等原因引起的问题,开发人员认为这个不是缺陷,不需要做认为修复操作。那么可以将缺陷否决掉。不过需要注意的是,不要随便否决缺陷,因为测试人员被否决缺陷是非常郁闷的事,尽量要在否决前与测试人员做好沟通。

推迟处理:开发人员接到缺陷任务后,暂时没有方案解决该问题,就需要推迟处理。推迟处理需要经过测试人员和业务的同意。

重新打开:当缺陷状态为“已修复”的时候,测试人员就需要做一次回归操作,就是重现这个Bug,如果发现Bug却是被修复了,那么可以把缺陷状态改为“关闭”,这个Bug的生命就到此结束了。但是测试发现Bug仍然存在,那就需要将状态改为“重新打开”,再让开发人员进行排查和修复。

关闭:测试人员对“已修复的”缺陷进行回归测试之后,发现缺陷已经被修复了,错误不再出现,就可以把缺陷状态改为“关闭”,Bug的生命周期就结束了。

 

对于开发人员来说,需要关注的是“打开”和“重新打开”状态的缺陷,需要分析原因并修复。

对于测试人员来说,需要关注的是“已修复”的缺陷,需要进行回归测试。

希望本文能对初入IT行业的人有所帮助,爱撸小杰