您现在的位置是:首页 >其他 >我叫缺陷,也叫Bug,下面介绍一下我的生命周期网站首页其他
我叫缺陷,也叫Bug,下面介绍一下我的生命周期
我叫缺陷,从被创建至关闭,到最后做缺陷分析,这是我的完整生命周期。我的整个生命周期贯穿着整个项目的项目周期,因此,掌握我的生命周期,不止是测试人员必修的课程,也是测试人员的灵魂。
缺陷的定义
对于软件的缺陷来说,一般人都把我说是Bug,但正确的来说,应该是Defect,这两者的区别是:
Bug是编程错误的结果;
Defact是与需求的偏离。
Defect不一定表示代码中存在Bug,它可能是尚未实现但在软件要求中定义的功能。实际上,无论是测试人员还是开发人员,还是习惯把我叫为Bug。
缺陷的属性组成
我一般由标识(ID)、标题、类型、优先等级、严重程度、状态、指派人组成,这些为项目最基本的、必要的属性。
然而为了后面的一些数据便于跟踪和分析,测试经理或项目经理更喜欢我的其它一些属性,比如:我(缺陷)产生的根本原因、发现的阶段、我(缺陷)所在系统、发现我(缺陷)的阶段等。这些属性,对整个项目的跟踪与分析,起到非常重要的作用。
缺陷的描写
我的整个描述非常重要,很多测试人员觉得这是件很简单的事,然后把我写得一塌糊涂。导致开发人员看到我后,完全不知道哪里出现了问题,得再去找测试人员沟通确认,浪费大家的时间及精力。
而项目最后为了跟踪和分析要收集的信息,我的一些属性更重要,开发人员和测试人员在选择时,需要根据实际情况来做筛选,要不分析的结果就不正确了。
标题
总结出现问题的模块和错误的信息。重点在于总结,很多测试人员把详细描述里面的内容直接贴到标题中,以为这样子搞定了我,但这样子的标题没有存在的意义。
描述内容
1、需要把操作的步骤和过程详细的描写清楚;
2、把预期结果和实际出现的结果也需要描写出来;
3、测试的环境、测试使用的数据也描写清楚。
上传截图
如果存在可以上传截图的路径,尽量把出现问题的地方截图上传。
缺陷的流程
1、我一般被测试人员所创建,然后由测试经理做审核。
2、如果我被测试经理审核通过,我则被测试经理指向给系统应用的项目经理;如果测试经理审核我不通过,则把我指回给测试人员,让测试人员进行修正。
测试人员修正后,再提交给测试经理审核。
3、项目经理收到我之后,进行分析,如果确认是需要修改的,则指派给对应的开发人员,如果确认我不是问题,或是我太不影响业务但太难修改,则把我指回给测试经理;
4、测试经理在收到由项目经理指派的我后,如果同意遗留,则把我指回给项目经理,然后状态置为遗留,留着下个版本进行跟踪。
如果根据需求,不同意遗留,则再把我指回给项目经理,进行修改;如果测试经理确认我不是问题,则把我进行撤消,指定提我的那个测试人员。
5、开发人员收到我之后,对我描述的内容进行分析修改,修改完成后,把我指回给测试人员,让测试人员在版本更新后,进行验证。
6、测试人员在版本更新,进行验证我里面所描述的问题,如果验证问题不存在,就关闭我;如果验证问题仍然存在,则把我再提回给开发人员,让他再进行排查及修改,直到问题修复完成,把我关闭。
特别说明:当一个项目没有单独的测试经理,由项目经理或测试组长兼任测试经理时,那测试人员创建的缺陷,则由他们来审核。
最后:
可以到我的个人号:atstudy-js,可以免费领取一份10G软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享!其中包括了有基础知识、Linux必备、Mysql数据库、抓包工具、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试持续集成、测试架构开发测试框架、性能测试等。
这些测试资料,对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!