一、缺陷的基本概述

1、缺陷的定义（重要）：

①软件未实现产品说明书要求的功能
②软件出现了产品说明书指明不该出现的功能
③软件实现了产品说明书未提到的功能
④软件未实现产品说明书虽未明确提及但应该实现的目标
⑤软件难以理解、不易使用、运行缓慢或者（从测试角度看）最终用户会认为不好

2、缺陷属性

1、缺陷的类型：
功能、用户界面、文档、软件包、性能、系统/模块接口

注意：需求分析、设计阶段，文档类型缺陷多；
集成测试阶段，一般接口类型的缺陷多一些；
系统测试阶段，功能、界面类型的缺陷多一些；
验收测试阶段，更多地关注性能缺陷；
实施过程，可能会遇到一些软件包的缺陷。

2、缺陷的严重程度：缺陷的故障对软件的影响，每个公司和团队的分类标准略有不同。

①致命：系统任何一个主要功能完全丧失，用户数据收到破坏，系统崩溃、悬挂、死机，或者危及人身安全。

②严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的的功能或服务收到明显的影响。

③一般：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题。

④较小：是操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等小问题。

注意：结合缺陷的影响，结合软件的具体功能（业务或者流程）

3、缺陷的修复优先级：很大程度上取决于缺陷对测试工作的影响程度。有以下等级：立即解决、高优先级、正常排队、低优先级。
例如：电商系统的用户注册功能无法使用（导致无法登录、购买、结算、支付、下单、物流跟踪、收获、评论等功能无法进行），就必须立即修复。但是电商系统中关于用户购买流程帮助说明的网页链接点击404页面，就比较次要。

注意：优先级的衡量，一般可以根据测试的软件系统的全业务流程划分，软件的基本功能的缺陷，优先级高，甚至需要立即解决。软件的备选流、基本功能测试中的反向测试的内容，优先级较低，甚至有些可改可不改。

缺陷的严重程度和优先级有什么关系？
1、没有任何直接的关系，严重程度是指缺陷对软件的影响，而优先级是指缺陷对测试的影响。
2、不要认为严重的缺陷，修复优先级就高；
3、如果碰到，优先级和严重程度都高的缺陷，也只是偶然。例如，QQ的帮助按钮，会有经常闪退的现象。严重程度很高，但是优先级就很低。又例如企业logo错误，不影响任何功能，但是必须优先修复。

提交缺陷时能不能夸大或降低缺陷的严重程度或者优先级？
不能，不能搞“狼来了”，也不能搞私人关系，"帮"好朋友减少不良影响。要公正、客观。

4、缺陷的状态：
缺陷状态指缺陷的处理进度。
发现缺陷时缺陷处理的前提，但是还没有进入缺陷的处理流程。

①激活/打开（新建）：由测试人员进行标注。
②确认：确认新提交的缺陷是一个真实有效的缺陷。一般由测试主管或者质量保证、产品经理进行确认。经确认后，有效的缺陷会指派给相关人员进行处理。
③已修复/修正。缺陷修复，一般由开发人员进行。
④关闭/非激活。缺陷被修复完成后，经过测试人员的验证后，没有问题。
⑤重新打开。经过测试人员的验证后，缺陷没有修复成功，需要重新打开进行再次处理和修复。
⑥推迟。缺陷现在不修复，推迟到下一个版本或阶段。测试要跟开发或者其他相关管理人员进行确认。
⑦保留。缺陷暂时修复不了，一般也是由开发人员去设定。也需要测试人员进行确认。
⑧不能重现。开发按照缺陷的复现步骤不能再次发现缺陷。一般闪退、崩溃类型的缺陷具有类似的特征。或者由于操作系统的差异，浏览器的缓存等信息，出现的问题。所以作为测试人员，提交bug之前，要再三确认bug。
⑨需要更多信息。作为测试人员，提交bug的时候，要尽可能把所有相关的文件一起提交（图片、视频）。
⑩重复。测试中，一定要避免这种情况的出现。尤其在软件的某个功能频繁被多个模块（由不同的测试人员测试）调用的情况下。
⑪不是缺陷。一定不要在测试工程师的工作生涯中被开发标注缺陷状态为不是bug。
⑫需要修改软件规格说明书。缺陷不是技术原因造成的，而是由于需求不明确或设计不明确。

5、缺陷的起源：

缺陷起源是指缺陷引起的故障或事件第一次被检测到的阶段。

缺陷起源有：需求、构架、设计、编码、测试、用户。

6、缺陷的来源：

缺陷来源指缺陷的起因。缺陷被发现的阶段，直接原因。

缺陷来源有：需求说明书、设计文档、系统集成接口、数据流（库）、程序代码。

7、缺陷的根源：

缺陷根源指发生错误的根本因素。一般发生在总结阶段。

缺陷根源有：测试策略、过程/工具和方法、团队/人、缺乏组织和通讯、硬件、软件、工作环境。

二、缺陷的生命周期（重要）

类似于面试官提问：针对你工作中发现的一个bug，说说这个bug的处理过程。其实就是要说明缺陷的生命周期中，每一个环节由谁做什么。

1、发现缺陷。由测试人员发现。开发人员也能知道自己哪里写错了，但是不会广而告之。

2、提交缺陷。由测试人员提交。

3、确认缺陷。一般由测试主管、质量保证、产品经理进行确认。

4、分配缺陷。经确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁分配。分配的对象可能是开发，也可能是UI、产品经理。

5、修复缺陷。主要由开发修复，也有可能产品经理、UI修复问题。

6、验证缺陷。测试去验证缺陷有没有修复成功。

7、关闭缺陷。只能是测试人员进行，否则出现了问题，测试人员一律不背锅。

三、缺陷的识别

依据：需求文档、设计文档、产品原型、测试用例，都是客观的依据。

同行业类似的成熟软件，和开发人员沟通，和有经验的测试人员沟通，同行业隐式需求。这些都是带有主观色彩的依据。

测试人员在识别缺陷的时候，要很灵活地对待。

四、缺陷报告

1、缺陷报告模板：

缺陷编号。Bug_项目名称_模块名称_功能名称_0001
所属模块。一级模块/二级模块/三级模块
优先级。缺陷的修复紧急程度。P1>P2>P3>P4
严重程度。S1>S2>S3>S4。
缺陷概述。用一句话描述缺陷的基本情况（时间、地点、人物、事件）。
缺陷描述。将缺陷的复现步骤、预期结果和实际结果列出来。缺陷描述的准则：可再现，除了类似闪退、崩溃等不可再现的缺陷。不做评价，不对缺陷出现的严重程度和缺陷表现出来的效果进行主观臆断。
提交人。
备注。一般写产生该缺陷的特殊情况。将Bug的截图作为备注信息。