我叫缺陷，从被创建至关闭，到最后做缺陷分析，这是我的完整生命周期。我的整个生命周期贯穿着整个项目的项目周期，因此，掌握我的生命周期，不止是测试人员必修的课程，也是测试人员的灵魂。

缺陷的定义

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

Bug是编程错误的结果；

Defact 是与需求的偏离。

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

缺陷的属性组成

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

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

缺陷的描写

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

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

标题

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

描述内容

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

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

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

上传截图

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

缺陷的流程

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

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

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

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

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

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

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

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

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

测试进阶

在智能驾驶发展得如火如荼的今天，软件测试行业也随之衍生出车载测试的岗位需求。对比其它在招岗位，车载测试的薪资也更加可观。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取