有关缺陷介绍

1.缺陷定义 

软件中存在的各种问题【注：不仅仅是错误】，都为缺陷，简称bug；

执行结果与用例的期望结果不一致（含义），为缺陷。

用例执行不通过为缺陷，需要进行缺陷管理

---

2.缺陷判定标准

• 软件未实现需求(规格)说明书中明确要求的功能-少功能
• 软件出现了需求(规格)说明书中指明不应该出现的错误-功能错误
• 软件实现的功能超出需求(规格)说明书指明的范围-多功能
• 软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求-隐性功能错误
• 软件难以理解，不易使用，运行缓慢，用户体验不好-不易使用（软件测试人员专业角度）

---

3.缺陷产生的原因

1. 需求阶段：需求描述不易理解，有歧义、错误等。
2. 设计阶段：设计文档存在错误或者缺陷。
3. 编码阶段：代码出现错误。
4. 运行阶段：软硬件系统本身故障导致软件缺陷

---

4.缺陷的生命周期 

扩展：

1、回归测试：
    ①常规项目回归：项目本次发布新增2个模块，最基本要测新增模块功能及新增模块关联的旧模块。
    ②非常规项目（银行、部队、航天）：新增功能，必须全部复测。
2、回归bug：

    ①上一个版本发现的缺陷，开发修复完毕，在下个版本进行重新验证。

---

发现缺陷后如何去描述呢？分为两部分：

（1）缺陷描述：发现缺陷以后如何去描述，让别人能看懂

（2）缺陷提交：指派人、优先级、类型

---

5.缺陷核心内容

• 缺陷的标题：描述缺陷的核心问题
• 缺陷的预置条件：缺陷产生的前提
• 缺陷的复现步骤：复现缺陷的过程
• 缺陷的预期结果：希望得到的结果
• 缺陷的实际结果：实际得到的结果
• 缺陷的必要附件：图片、日志等信息(证据)

---

6.缺陷提交要素

（1）缺陷报告编号：

缺陷的唯一性标志。

（2）严重程度：

• 严重(S0)：主功能
• 一般(S1)：次要功能
• 微小(S2)：易用性、界面
• 建议(S3)：建议性问题

（3）缺陷优先级：

• riority0：24小时之内解决
• riority1：发布前必须修复
• riority 2：可以在下一个版中修复

（4）Bug类型：

• 代码错误
• 兼容性问题
• 设计缺陷
• 性能问题

（5）缺陷状态：

• New：新建
• Open：打开
• Closed：关闭
• Postponed：延期

---

7.缺陷类型 

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

---

工作流程（小结）：

设计用例->执行用例（执行测试）->缺陷（提交、验证、关闭）

• 缺陷定义：任何问题（Bug）
• 缺陷标准：多功能、少功能、错误、缺少隐性功能、易用性
• 描述缺陷重点：缺陷标题、前置条件、复现步骤、预期结果、实际结果、附件备注
• 提交缺陷信息：指派人、缺陷等级、修复优先级、类型、状态（统计缺陷）

---

未完待续。。。