我叫缺陷，从被创建至关闭，到最后做缺陷分析，这是我的完整生命周期。我的整个生命周期贯穿着整个项目的项目周期，因此，掌握我的生命周期，不止是测试人员必修的课程，也是测试人员的灵魂。
缺陷的定义
对于软件的缺陷来说，一般人都把我说是Bug，但正确的来说，应该是Defect，这两者的区别是：
Bug是编程错误的结果；
Defact 是与需求的偏离。
Defect不一定表示代码中存在Bug，它可能是尚未实现但在软件要求中定义的功能。实际上，无论是测试人员还是开发人员，还是习惯把我叫为Bug。
缺陷的属性组成
我一般由标识（ID）、标题、类型、优先等级、严重程度、状态、指派人组成，这些为项目最基本的、必要的属性。
然而为了后面的一些数据便于跟踪和分析，测试经理或项目经理更喜欢我的其它一些属性，比如：我（缺陷）产生的根本原因、发现的阶段、我（缺陷）所在系统、发现我（缺陷）的阶段等。这些属性，对整个项目的跟踪与分析，起到非常重要的作用。
缺陷的描写
我的整个描述非常重要，很多测试人员觉得这是件很简单的事，然后把我写得一塌糊涂。导致开发人员看到我后，完全不知道哪里出现了问题，得再去找测试人员沟通确认，浪费大家的时间及精力。
而项目最后为了跟踪和分析要收集的信息，我的一些属性更重要，开发人员和测试人员在选择时，需要根据实际情况来做筛选，要不分析的结果就不正确了。
标题
总结出现问题的模块和错误的信息。重点在于总结，很多测试人员把详细描述里面的内容直接贴到标题中，以为这样子搞定了我，但这样子的标题没有存在的意义。
描述内容
1、需要把操作的步骤和过程详细的描写清楚；
2、把预期结果和实际出现的结果也需要描写出来；
3、测试的环境、测试使用的数据也描写清楚。
上传截图
如果存在可以上传截图的路径，尽量把出现问题的地方截图上传。
缺陷的流程
1、我一般被测试人员所创建，然后由测试经理做审核。
2、如果我被测试经理审核通过，我则被测试经理指向给系统应用的项目经理；如果测试经理审核我不通过，则把我指回给测试人员，让测试人员进行修正。
测试人员修正后，再提交给测试经理审核。
3、项目经理收到我之后，进行分析，如果确认是需要修改的，则指派给对应的开发人员，如果确认我不是问题，或是我太不影响业务但太难修改，则把我指回给测试经理；
4、测试经理在收到由项目经理指派的我后，如果同意遗留，则把我指回给项目经理，然后状态置为遗留，留着下个版本进行跟踪。
如果根据需求，不同意遗留，则再把我指回给项目经理，进行修改；如果测试经理确认我不是问题，则把我进行撤消，指定提我的那个测试人员。
5、开发人员收到我之后，对我描述的内容进行分析修改，修改完成后，把我指回给测试人员，让测试人员在版本更新后，进行验证。
6、测试人员在版本更新，进行验证我里面所描述的问题，如果验证问题不存在，就关闭我；如果验证问题仍然存在，则把我再提回给开发人员，让他再进行排查及修改，直到问题修复完成，把我关闭。
特别说明：当一个项目没有单独的测试经理，由项目经理或测试组长兼任测试经理时，那测试人员创建的缺陷，则由他们来审核。
感谢每一个认真阅读我文章的人！！！
作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。
软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。
视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。
