1.0 缺陷
1.1 定义
软件在使用的过程中存在的任何问题（错误、异常等），都叫做软件缺陷，简称Bug
案例
订单完成后----->付钱 10支笔
total = 90
total = 9
付款成功
发货
改进：
给id----->查询单价
number = 10
后台数据库查询单价
1.2 软件缺陷的判定标准
- 软件未实现需求说明书中明确要求的功能
- 软件出现了需求说明书中指明的不应该出现的错误
- 实现了超出需求说明书中的功能
- 软件未实现需求文档中未指明但应该实现的功能
- 用户体验不好（界面美观性、易用等）
1.3 软件缺陷出现的原因
- 编码：代码出错
- 运行系统：软硬件系统本身故障导致的软件缺陷
- 设计问题：设计文档出现错误或者缺陷
- 需求阶段：需求描述有歧义
- 软件本身很复杂
1.4 软件缺陷的核心内容（重点）
| 标题 | 描述软件缺陷的基本信息（例如：用户名5位，只展示4位） |
|---|---|
| 前置条件 | 描述缺陷出现依赖的相关基础条件 |
| 复现步骤 | 测试用例里的执行步骤 |
| 实际结果 | 执行测试用例的执行步骤，系统给出的结果 |
| 预期结果 | 参照需求说明书，在测试用例中设计的预期结果 |
| 附件 | bug截图或者出错的日志信息，方便定位bug |
1.5 缺陷的基本要素（重点）
1、ID：唯一
2、模块：根据产品进项具体的划分（支付模块、订单模块等）
3、缺陷状态：
new 新建
open 打开
fix 5已经修复
postpone 延期
reject 拒绝
close 关闭
reopen 重新打开
1.5.1 缺陷的严重程度
从技术上衡量bug的破坏力
- 1、致命 critical 5
- 2、非常高 major 4
- 3、高 medium 3
- 4、中 minor 2
- 5、低 tiny 1
1.5.2 缺陷的优先级
处理缺陷的优先程度(团队的工作进度)
紧急 5
非常高 4
高 3
中 2
低 1
1.5.3 缺陷类别
功能错误
UI界面错误
兼容性错误
易用性
改进意见
1.5.4 提交缺陷的注意事项
1、唯一性，一个缺陷只需要提交一次
2、保证可复现性
3、规范性，描述需要准确，有细节真实
1.6 缺陷的跟踪流程
1.7 场景
测试new---->开发open---->开发fix---->测试close
测试new---->开发open---->开发fix---->测试reopen
测试new---->开发open---->开发postpone
测试new---->开发open---->开发reject
