我叫缺陷,也叫Bug,下面介绍一下我的生命周期

上一篇 / 下一篇  2023-05-23 17:03:47 / 个人分类:Bug缺陷管理

我叫缺陷,从被创建至关闭,到最后做缺陷分析,这是我的完整生命周期。我的整个生命周期贯穿着整个项目的项目周期,因此,掌握我的生命周期,不止是测试人员必修的课程,也是测试人员的灵魂。加我VX:atstudy-js 回复“测试”,进入 自动化测试学习交流群~~

缺陷的定义

对于软件的缺陷来说,一般人都把我说是Bug,但正确的来说,应该是Defect,这两者的区别是:

Bug是编程错误的结果;

Defact是与需求的偏离。

Defect不一定表示代码中存在Bug,它可能是尚未实现但在软件要求中定义的功能。实际上,无论是测试人员还是开发人员,还是习惯把我叫为Bug。

缺陷的属性组成

我一般由标识(ID)、标题、类型、优先等级、严重程度、状态、指派人组成,这些为项目最基本的、必要的属性。

然而为了后面的一些数据便于跟踪和分析,测试经理或项目经理更喜欢我的其它一些属性,比如:我(缺陷)产生的根本原因、发现的阶段、我(缺陷)所在系统、发现我(缺陷)的阶段等。这些属性,对整个项目的跟踪与分析,起到非常重要的作用。

缺陷的描写

我的整个描述非常重要,很多测试人员觉得这是件很简单的事,然后把我写得一塌糊涂。导致开发人员看到我后,完全不知道哪里出现了问题,得再去找测试人员沟通确认,浪费大家的时间及精力。

而项目最后为了跟踪和分析要收集的信息,我的一些属性更重要,开发人员和测试人员在选择时,需要根据实际情况来做筛选,要不分析的结果就不正确了。

标题

总结出现问题的模块和错误的信息。重点在于总结,很多测试人员把详细描述里面的内容直接贴到标题中,以为这样子搞定了我,但这样子的标题没有存在的意义。

描述内容

1、需要把操作的步骤和过程详细的描写清楚;

2、把预期结果和实际出现的结果也需要描写出来;

3、测试的环境、测试使用的数据也描写清楚。

上传截图

如果存在可以上传截图的路径,尽量把出现问题的地方截图上传。

缺陷的流程

1、我一般被测试人员所创建,然后由测试经理做审核。

2、如果我被测试经理审核通过,我则被测试经理指向给系统应用的项目经理;如果测试经理审核我不通过,则把我指回给测试人员,让测试人员进行修正。

测试人员修正后,再提交给测试经理审核。

3、项目经理收到我之后,进行分析,如果确认是需要修改的,则指派给对应的开发人员,如果确认我不是问题,或是我太不影响业务但太难修改,则把我指回给测试经理;

4、测试经理在收到由项目经理指派的我后,如果同意遗留,则把我指回给项目经理,然后状态置为遗留,留着下个版本进行跟踪。

如果根据需求,不同意遗留,则再把我指回给项目经理,进行修改;如果测试经理确认我不是问题,则把我进行撤消,指定提我的那个测试人员。

5、开发人员收到我之后,对我描述的内容进行分析修改,修改完成后,把我指回给测试人员,让测试人员在版本更新后,进行验证。

6、测试人员在版本更新,进行验证我里面所描述的问题,如果验证问题不存在,就关闭我;如果验证问题仍然存在,则把我再提回给开发人员,让他再进行排查及修改,直到问题修复完成,把我关闭。

特别说明:当一个项目没有单独的测试经理,由项目经理或测试组长兼任测试经理时,那测试人员创建的缺陷,则由他们来审核。

最后:

添加微信:atstudy-js  或者扫描下方二维码,备注“博客”邀请你进入Python自动化测试学习交流群~


TAG:

 

评分:0

我来说两句

Open Toolbar