第四章：缺陷管理【重点】
4.1 软件缺陷简介
缺陷不等于 bug
bug 仅仅是缺陷中的很小的一个部分而已
什么是缺陷：只要让测试人员感觉不爽，那么这个就是缺陷
软件缺陷判定标准
1. 软件未能达到需求规格书中的要求
2. 软件的功能超出规格书中的要求
3. 软件出现了规格书中明确指定不能出错的地方
4. 软件出现了规格书中未明确指定，但是不应该出现的错误
软件缺陷产生的原因【缺陷只能减少、不能完全避免】
1. 对于需求文档等文等文件解释、理解错误【需求说明会】
2. 设计文档本身有错误
3. 程序代码错误
4. 硬件和软件系统有错
软件缺陷的类型
1. 功能错误：软件没有达到需求文档的功能要求，或者功能异常
2. 界面错误：软件功能正常，但是界面不好看或者未达到规格说明中的要求
3. 兼容性错误：软件和系统中的其他的程序冲突，导致软件无法运行
4. 易用性错误：软件用起来不好用
5. 改进建议：改了更好，不改也没事 4.2 软件缺陷管理
4.3 提交缺陷注意实现
可重现：
发现缺陷可以在开发的电脑上再次出现
唯一性：
每个缺陷有一个唯一的编号，也就是缺陷的 ID
缺陷报告每行是一个缺陷
规范性：
提交的缺陷需要符合公司定制的规范要
缺陷报告的规范
ID ：
标题：
重现步骤
期望结果
实际结果
4.4 处理缺陷的流程
4.5 缺陷相关概念
缺陷状态
new ：测试人员提交新 bug ，这个 bug 状态是新建 open ：处理 bug 的开发，打开测试提交的哪个 bug ，这个状态是打开
fifix ：开发已经将 bug 处理完成，这个状态 fifix 、 fifixed
close ：将处理完成的 bug 关闭掉，这个状态的 bug 就是 close 、 closed
reopen ：开发处理过，但是回归测试没有通过的 bug ，状态就是 repoen
reject ：开发拒绝处理 bug
postpone ：不是紧急 bug ，不需要马上处理，延后处理
结合状态写工作流程：
流程 1 ：确认 bug 处理
70-80%
测试【 new 】 => 开发【 open 】 => 开发【 fifix 】 => 测试【 close 】
流程 2 ：开发处理 bug 后，但是未通过回归测试
10-20%
测试【 new 】 => 开发【 open 】 => 开发【 fifix 】 => 测试【 reopen 】
流程 3 ：延后处理
10%
测试【 new 】 => 开发【 open 】 => 开发【 postpone 】
流程 4 ：拒绝处理
5%
测试【 new 】 => 开发【 open 】 => 开发【 reject 】
缺陷的严重等级
critical ，致命， 5 ：系统级别的故障，例如系统宕机。
major ，非常高， 4 ：严重的 bug ，系统可以运行，但是核心业务受影响。
medium ，中等， 3
minor ，低， 2
tiny ，非常低， 1
缺陷的优先级
等级 5 ：紧急的
等级 4 ：非常高
等级 3 ：高
等级 2 ：中
等级 1 ：低
补充内容：公司的基本组成
产品部门：产品经理
研发部门：程序员、项目经理
测试部门：测试
产品经理： 对接客户，将客户的需求整理成文档
对接开发 / 项目经理，讨论项目实现的细节【编程语言、数据库、编码、服务器 ... 】
项目经理
将讨论的结果整理成项目文档
将整个项目分成一个一个模块，并分配给不同的程序员进行开发
最后将各个程序员开发的模块合并起来
程序员：
写代码
测试：
测试代码
