1、缺陷的定义：

软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug。

2、软件缺陷的判定标准：

1）少功能：

软件未实现需求（规格）说明书中明确要求的功能。

2）功能错误：

软件出现了需求（规格）说明书中指明不应该出现的错误。

3）多功能：

软件实现的功能超出了需求（规格）说明书中指明的范围。

4）隐性功能错误：

软件未实现需求（规格）说明书中未明确指明但应该实现的要求。

5）不易使用：

软件难以理解不易使用，运行缓慢，用户体验差。

3、缺陷产生的原因：

1）需求文档阶段：

需求描述不易理解，有歧义、错误。

2）架构设计阶段：

设计文档存在错误或者缺陷。

3）编码实现阶段：

代码出现错误。

4）运行阶段：

软硬件系统本身故障导致软件缺陷。

4、软件缺陷的生命周期：

1）在需求、设计、编码阶段都可能会注入缺陷。

2）在测试阶段发现缺陷。

3）在故障分类、故障隔离、故障解决阶段清除故障。

4）但在故障解决阶段可能会注入新的缺陷。

5、软件缺陷的核心内容：

1）缺陷的标题：

描述缺陷的核心问题。

2）缺陷的预置条件：

缺陷产生的前提。

3）缺陷的复现步骤：

复现缺陷的过程。

4）缺陷的预期结果：

希望得到的结果。

5）缺陷的实际结果：

实际得到的结果。

6）缺陷的必要附件：

图片、日志等信息（证据）。

6、缺陷提交要素：

1）缺陷报告编号：

缺陷的唯一标志。

2）严重程度：

①严重（S1）：主功能。
②一般（S2）：次要功能。
③微小（S3）：易用性、界面。
④建议（S4）：建议性问题。

3）缺陷优先级：

①priority 0：24h之内解决。
②prioritr 1：发布器必须修复。
③priority 2：可以在下一个版本中修复。

4）bug类型：

①代码错误。
②兼容性问题，
③设计缺陷。
④性能问题。

5）缺陷状态：

①New：新建。
②Open：打开。
③Closed：关闭。
④postponed：延期。

7、软件缺陷类型：

1）功能错误。
2）UI页面错误。
3）兼容性。
4）数据（数据库）。
5）易用性。
6）改进建议。
7）架构缺陷。

8、缺陷报告编写：

1）缺陷ID。
2）缺陷标题。
3）缺陷状态。
4）严重程度。
5）优先级。
6）所属模块。
7）缺陷描述。
8）附件备注。

9、缺陷的跟踪流程：

1）由测试人员提交缺陷，并分派缺陷。
2）开发拿到缺陷之后，先判断缺陷是否重复。如果缺陷重复，直接关闭缺陷。如果不重复，根据测试提交的复现步骤，利用复现数据确定是否为bug。如果不是，则关闭缺陷。
3）当确定为bug后，开发处理bug，然后回归测试。
4）测试验证缺陷。如果缺陷通过，关闭缺陷。如果缺陷不通过，重新打开。

10、提交缺陷的注意事项：

1）可重现：

缺陷可以重现。

2）唯一性：

一个缺陷可上报一个问题。

3）规范性：

符合公司或项目要求。

11、缺陷编写规范：

1）准确：
描述的信息是正确的。

2）具体：
有细节且是真实特定的。

3）简洁易懂：
描述简单，容易理解。

4）次序清晰：
描述缺陷过程有条件，有先后顺序。