一、缺陷的基本概述
- 缺陷的定义
- 缺陷的属性
- 缺陷类型：缺陷的类型包括功能(Function)、界面(UI)、文档(Documentation)、软件包(Package)、性能(Performance)、接口(Interface)
[注意]
需求分析、设计阶段，文档类型的缺陷多;
集成测试阶段，一般接口类型的缺陷多一些;
系统测试阶段，功能、界面类型的缺陷多一些;
验收测试阶段，更多的关注性能缺陷;
实施过程，可能会遇到一些软件包的缺陷- 缺陷严重程度：缺陷严重程度是指缺陷对软件的影响程度，一般包括致命（Fatal）、严重（Critial）、一般（Major）、较小（Minor），不同公司有具体的分类
- 缺陷被修复的优先级：优先级取决于缺陷对测试工作的影响程度，例如：电商系统中的用户注册功能无法使用（无法注册，购买，收藏，加入购物车等）就需要立即修复
【面试提问】缺陷的严重程度和优先级有什么关系?
1)没有直接的关系
2)缺陷严重程度是指缺陷对软件的影响程度，缺陷被修复的优先级取决于缺陷对测试工作的影响程度- 缺陷的状态：表示缺陷的处理进度
- 激活/打开(新建)：由测试人员进行标注。确认。确认新提交的缺陷是一个真实有效的缺陷。一般由测试主管、或者质量保证(QA)、由产品经理进行确认。经确认后，有效的缺陷会指派给相关人员进行处理。。
- 已修复/修正。在缺陷被修复后，一般由开发人员进行。
- 关闭/非激活。缺陷被修复完成后，经过测试人员的验证后，没有问题。
- 重新打开。经过测试人员的验证后，缺陷没有修复成功，需要重新打开进行再次处理和修复。v
- 推迟。缺陷现在不修复，推迟到下一个版本或者阶段。测试要跟开发或者其他相关的管理人员进行确认。。
- 保留。缺陷暂时修复不了。一般也是由开发人员去设定。也需要测试人员进行确认。
- 不能重现。开发按照却显得复现步骤不能再次发现缺陷。一般闪退、崩溃类型的缺陷具有类似的特征。或者由于操作系统的差异、浏览器的缓存等信息,出现的问题。所以作为测试人员,提交 bug 之前,要再三的确认 bug。需要更多信息。作为测试人员，提交 bug的时候，要尽可能的把所有相关的文件一起提交。(图片、视频)。
- 重复。测试中，一定要避免这种情况的出现。尤其在软件的某一个功能频繁被多个模块(由不同的测试人员测试)调用的情况下。
- 不是缺陷。一定不要在测试工程师的工作生涯中被开发标注缺陷状态为不是 bug。
- 需要修改需求说明书。缺陷不是技术原因造成的，而是由于需求不明确或者设计不明确造成。
- 缺陷的起源、来源、根源：一般关注较多的是缺陷的来源（直接原因）；在测试总结的时候，关注缺陷的根源。
二、缺陷的生命周期
- 发现缺陷。由测试人员。开发也能知道自己哪里写错了，但是不会广而告之。
- 提交缺陷。由测试人员。开发更不可能提交 bug。
- 确认缺陷。一般由测试主管、或者质量保证(QA)、由产品经理进行确认。
- 分配缺陷。经确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁分配。分配的对象可能是开发、也可能是、也可能是产品经理。
- 修复缺陷。主要由开发修复，也有可能是产品经理修复问题，也有可能是UI修复问题。
- 验证缺陷。测试去验证缺陷有没有修复成功。
- 关闭缺陷。只能是测试人员进行。否则出了问题，测试认识一律不背锅。
【面试问题】针对你工作中发现的一个 bug，说说这个bug 的处理过程？
答：缺陷的生命周期中，每一个环节由谁做什么
三、缺陷的识别
- 通过测试用例中的预期结果进行识别
- 通过需求规格说明书进行识别
- 通过用户手册及其他文档进行识别
- 通过同行业相类似成熟的商业软件来识别
- 通过和开发人员的沟通进行识别
- 通过和有经验的测试人员沟通进行识别
- 参照同行业隐式需求进行识别
四、缺陷报告
- 缺陷编号：Bug_项目名称_模块名称_功能名称_0001。
- 所属模块：一级模块/二级模块/三级模块
- 优先级：缺陷的修复紧急程度。P1>P2>P3>P4，例如基本流可以用P1，P2，备选流可以用P3，P4
- 严重程度：缺陷对软件的影响程度，S1>S2>S3>S4
- 缺陷概述：用一句话描述缺陷的基本情况。
- 缺陷的描述：将缺陷的复现步骤、预期结果和实际结果列出来。
- 提交人：是谁就写谁的名字。
- 备注：一般写产生该缺陷的特殊情况。将 bug的截图作为备注信息。
五、缺陷跟踪系统
- 禅道：国产、项目、产品、测试齐全，对个人和组织开源免费
- QC（ALM）：外国软件、英文，功能齐全
- JIRA：国外软件、JAVA环境、主流（商业）
- TAPD
