我叫缺陷，从被创建至关闭，到最后做缺陷分析，这是我的完整生命周期。我的整个生命周期贯穿着整个项目的项目周期，因此，掌握我的生命周期，不止是测试人员必修的课程，也是测试人员的灵魂。
缺陷的定义
对于软件的缺陷来说，一般人都把我说是Bug，但正确的来说，应该是Defect，这两者的区别是：
Bug是编程错误的结果；
Defact 是与需求的偏离。
Defect不一定表示代码中存在Bug，它可能是尚未实现但在软件要求中定义的功能。实际上，无论是测试人员还是开发人员，还是习惯把我叫为Bug。
缺陷的属性组成
我一般由标识（ID）、标题、类型、优先等级、严重程度、状态、指派人组成，这些为项目最基本的、必要的属性。
然而为了后面的一些数据便于跟踪和分析，测试经理或项目经理更喜欢我的其它一些属性，比如：我（缺陷）产生的根本原因、发现的阶段、我（缺陷）所在系统、发现我（缺陷）的阶段等。这些属性，对整个项目的跟踪与分析，起到非常重要的作用。
缺陷的描写
我的整个描述非常重要，很多测试人员觉得这是件很简单的事，然后把我写得一塌糊涂。导致开发人员看到我后，完全不知道哪里出现了问题，得再去找测试人员沟通确认，浪费大家的时间及精力。
而项目最后为了跟踪和分析要收集的信息，我的一些属性更重要，开发人员和测试人员在选择时，需要根据实际情况来做筛选，要不分析的结果就不正确了。
标题
总结出现问题的模块和错误的信息。重点在于总结，很多测试人员把详细描述里面的内容直接贴到标题中，以为这样子搞定了我，但这样子的标题没有存在的意义。
描述内容
1、需要把操作的步骤和过程详细的描写清楚；
2、把预期结果和实际出现的结果也需要描写出来；
3、测试的环境、测试使用的数据也描写清楚。
上传截图
如果存在可以上传截图的路径，尽量把出现问题的地方截图上传。
缺陷的流程
1、我一般被测试人员所创建，然后由测试经理做审核。
2、如果我被测试经理审核通过，我则被测试经理指向给系统应用的项目经理；如果测试经理审核我不通过，则把我指回给测试人员，让测试人员进行修正。
测试人员修正后，再提交给测试经理审核。
3、项目经理收到我之后，进行分析，如果确认是需要修改的，则指派给对应的开发人员，如果确认我不是问题，或是我太不影响业务但太难修改，则把我指回给测试经理；
4、测试经理在收到由项目经理指派的我后，如果同意遗留，则把我指回给项目经理，然后状态置为遗留，留着下个版本进行跟踪。
如果根据需求，不同意遗留，则再把我指回给项目经理，进行修改；如果测试经理确认我不是问题，则把我进行撤消，指定提我的那个测试人员。
5、开发人员收到我之后，对我描述的内容进行分析修改，修改完成后，把我指回给测试人员，让测试人员在版本更新后，进行验证。
6、测试人员在版本更新，进行验证我里面所描述的问题，如果验证问题不存在，就关闭我；如果验证问题仍然存在，则把我再提回给开发人员，让他再进行排查及修改，直到问题修复完成，把我关闭。
特别说明：当一个项目没有单独的测试经理，由项目经理或测试组长兼任测试经理时，那测试人员创建的缺陷，则由他们来审核。
测试进阶
在智能驾驶发展得如火如荼的今天，软件测试行业也随之衍生出车载测试的岗位需求。对比其它在招岗位，车载测试的薪资也更加可观。
你是否对车载测试感兴趣，想转行车载测试却无从下手呢？现在私聊恬恬圈/甜甜圈，或识别下方二维码，添加天天圈，了解车载测试入门吧↓↓↓
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
