1.软件缺陷

1.1定义

软件在使用过程中存在的任何问题（错误、异常），都叫软件缺陷，简称Bug

• 案例

订单完成 ---> 付钱        10支笔   90块钱    
total = 90           
total = 9     --->             
付款成功            
发货  

改进：
给id ----> 查询单价      
number = 10   
后台数据库查询单价

1.2软件缺陷的判定标准

• 软件未实现需求说明书中明确要求的功能
• 软件出现了需求说明书中指明得不应该出现的错误
• 软件实现了超出需求说明书中的功能
• 软件未实现需求文档中未指明但是又应该实现的功能
• 用户体验不好，界面不漂亮，易用等

1.3 软件缺陷的原因

• 编码：代码出错
• 运行系统：软硬件系统本身故障导致的软件缺陷
• 设计问题： 设计文档出现错误或者缺陷
• 需求阶段：需求描述有歧义
• 软件本身很复杂

1.4 软件缺陷得核心内容（重点）

标题	描述软件缺陷的基本信息，例如（用户名5位，只展示3位）
前置条件	描述缺陷出现依赖的相关基础条件
复现步骤	测试用例里的执行步骤
实际结果	执行测试用例得执行步骤，系统给出的结果
预期结果	参照需求说明书，在测试用例中设计的预期结果
附件	Bug截图或者出错的日志信息，方便定位Bug得

1.5缺陷的基本要素（重点）

1.5.1 ID

唯一性

1.5.2 模块

根据产品进行具体的划分，支付模块，订单模块等

1.5.3缺陷状态

New	新建
open	打开
fix	已经修复
postpone	延期
reject	拒绝
close	关闭
reopen	重新打开

1.5.4缺陷的严重程度（重点）

从技术上衡量Bug得破坏力

致命	5	critical
非常高	4	major
高	3	medium
中	2	minor
低	1	tiny

1.5.5缺陷的优先级

处理缺陷的优先程度

紧急	5	critical
非常高	4	major
高	3	medium
中	2	minor
低	1	tiny

1.5.6 缺陷类别

- 功能错误
- UI界面错误
- 兼容性错误
- 易用性
- 改进意见

1.6 提交缺陷得注意事项

- 唯一性，一个缺陷只需要提交一次
- 保证可复现性
- 规范性               
        描述需要准确 有细节真实

1.7 缺陷的跟踪流程

• 场景

    测试new--->开发open--->开发fix--->测试close
    
    测试new--->开发open--->开发fix--->测试reopen
    
    测试new--->开发open--->开发postpone
    
    测试new--->开发open--->开发reject